1. Adventures in Debian Packaging
1 /
Adventures in Debian Packaging
Peeling the Onion
Chris Knadle version

2. 2 /
Precis
0: Necessity is the mother of invention 1: The “cheat” Debian package 2: diff, patch, quilt, dpkg 3: Working with existing source packages 4: Making your own private repository 5: Making a package from scratch 6: Debian packaging with Git

3. *My Linux start... 1995, Slackware
3 /
*My Linux start , Slackware
Philosophy: small install, compile other projects yourself. Great to learn on. Upgrade method: wipe + install new

4. 4 /
*Rapid growth
1997: first Desktop use (fvwm95) No browser, no office suite
1998: first real home networking (IPX ?) 4 people, 4 modems, one phone line Shared modem via my desktop, but... getting woken up at 2am to get online
Built a server, family gets online via the network
Now when a new version of Slackware came out, several machines needed reinstalling.
Made decision: reinstallation not sustainable

5. *1999 … Switch distros Got sick of “wipe + reinstall + recompile” work
5 /
*1999 … Switch distros
Got sick of “wipe + reinstall + recompile” work
Debian famed for upgrade-in-place ability but only if you use the packages
Focus changes from compiling work to using the available packages instead
hidden issue: DEPENDENCE

6. Passage of time … Passage of time …
6 /
Passage of time … Passage of time …

7. *Signs of Strain Sometime in 2011, MHVLUG
7 /
*Signs of Strain
Sometime in 2011, MHVLUG
After the talk, friendly discussion with
Mike Kershaw about wireless sniffing:
“Have a look at Kismet – but not the package in Ubuntu, 'cause that package is ancient.”
Check the package in Debian... same thing. Three years old. *sigh*
How do I install a newer Kismet version as a Debian package?

8. changelog in /usr/share/doc/<pkg>
8 /
changelog in /usr/share/doc/<pkg>
4.1 = float: non-maintainer upload
kismet ( R1-4.1) unstable; urgency=low * Non-maintainer upload. * Remove unnecessary build-dep on libglib1.2-dev. (Closes: #523682). * Fix to build with gcc-4.4. (Closes: #545725) Thanks to Alessio Treglia for the fix. * Replace Ethereal with wireshark in README. (Closes: #416104). * Fix symlink for desktop file in kismet.links. (Closes: #499791) Barry deFreese Sat, 17 Oct :44: kismet ( R1-4) unstable; urgency=low * updated the copyright file * changed extra/manuf_update.sh to update the files in /etc/kismet (closes: #416105) * updated the readme.debian (closes: #416107) Francois Gurin Fri, 04 Jul :36:
4 = integer: maintainer upload
bugs can be looked up to get more detail

9. wnpp “Work-Needing and Prospective Packages”
9 /
wnpp
“Work-Needing and Prospective Packages”
This lists packages that are: (# in )
- up for adoption → orphaned → being adopted → packages in need of help → being worked on → requested → 1968
kismet was listed here, so maintainer did the right thing
A significant number of desired packages don't exist yet

10. Debian packaging the “cheat” way
10 /
Debian packaging the “cheat” way
Using 'checkinstall' with source code: ./configure make checkinstall make install #executed as root
Watches files “installed” and makes a Debian package containing the files, and installs the package

11. Issues with checkinstall
11 /
Issues with checkinstall
Requires figuring out the source dependencies [i.e. which '-dev' or other packages are required for the build to succeed.]
Installs whatever files 'make install' does
Might not have a file layout for Debian/Ubuntu (might not conform to FHS)
There are several things 'make install' can't do: – make users and groups – ask setup questions – install a limited set of files

12. Figuring out build dependencies
12 /
Figuring out build dependencies
Read the documentation that comes with the source code, which may state them
Read the documentation on the website for the project, which may state them
Attempt a build, read the error message(s) for what header files are missing, then use 'apt-file search <filename>' to figure out what packages the required missing files are in, and install them

13. *I read “How to do it for real”
13 /
*I read “How to do it for real”
Checkinstall worked to install newer Kismet locally, but the package in Debian is still old
Spent months trying to read documentation about Debian packaging...
Getting bored and putting it down
Picking it up and trying again
Rinse Wash Repeat

14. Lots of documentation to read
14 /
Lots of documentation to read
Debian New Maintainer's Guide → 64 pages
→ which then refers to:
Debian Policy Manual → pages
Filesystem Hierarchy Standards → 52 pages
Debian Developer's Reference → 85 pages
The GNU 'make' Manual → 175 pages
Lots of various manpages … and so on → Lots of reading to do, with no clear path

15. 15 /
Getting going quicker
Found a resource for a shorter path: - The packaging-tutorial presentation (and package) by Lucas Nussbaum 'apt-get packaging-tutorial' or via git: git://anonscm.debian.org/collab-maint/packaging-tutorial.git
A hint it contains:
START NOW. Don't wait to fully understand it all, because the best way to learn is by doing.

16. *First try at a Kismet package
16 /
*First try at a Kismet package
Download upstream source, expand it
Copy over debian/ directory from old package
Run 'dch -i' to add a changelog entry
Try running 'debuild -us -uc' and see what happens
Didn't work out in this case because too much had changed

17. *Start a brand new Kismet package
17 /
*Start a brand new Kismet package
Read some of the packaging-tutorial
Install devscripts, dh-make
Download upstream source, expand it
Run 'dh_make -s -c gpl2'
Copy debian/changelog file from old package
Run 'dch -i' to add a changelog entry
Delete unneeded files in /debian
While updating the new package, use old package /debian files as a guide
run 'debuild -us -uc' and test

18. *Work remaining Kismet package
18 /
*Work remaining Kismet package
Made a working Kismet package, but...
Package still used 'su-to-root -c kismet', needed to figure out a better way to get access to the network device
Old Debian package was in'1.0 format' and had a huge .diff.gz with no comments, so I couldn't figure out if any of the patch applied to the new package
Many outstanding bug reports to consider

19. 19 /
*Wake-up Alarm
June 2012, Mumble package (VoIP program) Upgrade → voice communication broken
Find bug on the problem, but it's closed. ?
No explanation to what's going on. Reopen bug.
Maintainer briefly answers a DD at a high level, but doesn't discuss the issue with bug reporters
Bug closed again without explanation or fix. ?!?
Reopen bug to try to communicate... repeated abusive communication from the maintainer, repeated close again with no explanation.
maintainer OBSTACLE

20. *Desperation Discuss the situation with the DPL.
20 /
*Desperation
Discuss the situation with the DPL.
Send bug to Debian Technical Committee. Two months of arguing.
Maintainer's point: no upstream support for CELT codec, worry about possible security issues. User standpoint: software won't work without CELT.
The tech-ctte rules that the bug should be fixed.
Maintainer refuses to communicate, won't fix it.
The path now: find a DD to work with, fix the bug myself as an NMU, have the DD upload the NMU.
Wheezy got frozen June 30, 2012, so the NMU required minimal changes.

21. 21 /
*get the source
Don't be too tempted to get the Git repo when it comes to Debian packages (you'll see why)
$ apt-get source mumble/sid Reading package lists... Done Building dependency tree Reading state information... Done NOTICE: 'mumble' packaging is maintained in the 'Git' version control system at: git://git.debian.org/users/ron/mumble.git Need to get 3,159 kB of source archives. Get:1 sid/main mumble g315b5f5-2.2 (dsc) [2,532 B] Get:2 sid/main mumble g315b5f5-2.2 (tar) [3,119 kB] Get:3 sid/main mumble g315b5f (diff) [37.6 kB] Fetched 3,159 kB in 2s (1,100 kB/s) ...

22. 22 /
22 /
*Confusion, part 1
Debian source packages in Git don't come with the .orig tarball, which is required to build.
Many repositories use 'pristine-tar' to all re- making the .orig tarball. But... not this one. Trelane:~/src/mumble-git-repo$ pristine-tar list Trelane:~/src/mumble-git-repo$
And no 'upstream' branch either.
Trelane:~/src/mumble-git-repo$ git branch * debian

23. 23 /
23 /
*Confusion, part 2
Unusual: the tarball version used to make the package doesn't exist upstream
mumble g315b5f5 ?

24. 24 /
24 /
*Confusion, part 3
There are several Git helper packages in Debian; git-debimport indicates 'gitpkg' use

25. Questions for the Audience
25 /
Questions for the Audience
If you deal with a Debian-based distro somewhere. (Debian, Ubuntu, Mint, Zorin, etc)
2. If you know of a package that needs attention (“buggy”, removed, etc) and isn't nearing a fix.
3. If you've tried to report a bug but have been frustrated with the results of the attempt.
4. If you're more reluctant to open a bug report now because of your experiences doing so.

26. Packages in Debian Are not always up-to-date
26 /
Packages in Debian
Are not always up-to-date
Are not always actively maintained
Get removed from the archive
“Upgrade to broken!”
Get delayed (10-month Wheezy “freeze”) ...
Lots of discussion on [debian-devel] about how to deal with the problem
The main suggested solution is doing NMUs (Non-Maintainer Uploads)

27. 27 /
Conclusions
If you want your software to work, the only way to guarantee that is to gain the ability to build it yourself
Necessity is the mother of invention
Problems are also opportunities The connections I made working on the problem are still connections today. Some good things came out of something bad.

28. Debian could use more Devs
28 /
Debian could use more Devs
FLAT
Note: Counted DD + DM pub keys in debian-keyring and debian-maintainers keyrings

29. Debian could use more Devs
29 /
Debian could use more Devs
375%
increase

30. Steady drop in bug reporting
30 /
Steady drop in bug reporting
Source: Don Armstrong, Oct

31. Coincidence? Theories as to cause:
31 /
Coincidence?
Theories as to cause:
1. Debian derivaties getting bugs, which don't get back to Debian
2. “the chilling effect”: users feel frustration in reporting bugs, so don't report some at all

32. No policy on DD behavior
32 /
No policy on DD behavior
Debian has no developer “Code of Conduct” (There is a vague CoC for the mailing lists, but it doesn't solve this issue in practice)
The “5 year plan”: agree on a Code of Conduct … Same “5 year plan” existed 5 years ago
The CoC would require a General Resolution to come up with one, but it would be non-binding
Ubuntu developers recognized this problem, so Ubuntu does have a Code of Conduct
Great! Does this solve the problem? No. See next slide.

33. “All paths lead to Debian Sid”
33 /
“All paths lead to Debian Sid”
All new packages in Debian go to Unstable/Sid
Ubuntu wants packages to go through Debian
Mint wants packages to go through Debian
New Pkg
Debian Unstable
Debian Testing
Debian Stable
Ubuntu
~10 days
~2 years
6 months
Mint
Mint Debian
NEW queue ?
Ubuntu Release
freeze every 2 years

34. Tools that help with abuses
34 /
Tools that help with abuses
Best first defense: openly point out the misbehavior, and stop
The Debian Technical Committee: can make technical decisions and override a maintainer
The Debian Account Managers (DAM) is the only authority that can act on maintainer misbehavior (no documentation makes this clear)
The DPL (Debian Project Leader) also historically discusses misbehavior issues and can usually help.

35. 35 /
For inspiration
Recommended reading: “The Tools” by Stutz and Michaels, ISBN

36. 36 /
Debian's “right stuff”
Debian's “Social Contract” – Debian Doesn't Hide Problems (but seem to hide DD reprimands and expulsions)
The DFSG – Debian Free Software Guidelines
Many of the Debian Developers are great to work with
Accessible: lots of opportunities to discuss issues with developers
We non-DDs can get packages into Debian through Debian Mentors:
(Or through getting a DD to sponsor an upload)

37. Why to do a “real” Debian package
37 /
Why to do a “real” Debian package
Fix an existing package in order to make a .diff of the fix to bug ('debdiff' helps here)
Install a limited set of files (i.e binary package)
Install a binary package on several machines
Make packages available in a repository (perhaps your own)
Upload the package into Debian (and Ubuntu, Mint, etc) For Debian: the [debian-mentors] mailing list.

38. 38 /
The 'diff' tool
Standard diff (a bit ugly): 'diff <file1> <file2>'
A prettier “unified” diff: 'diff -u <file1> <file2>'
Unified diff with ANSI color, viewing via Less:
'colordiff -u <file1> <file2> | less -R'
Output a diff to a file: 'diff -u <file1> <file2> > file1-file2.diff' → this is a “diff”, but it's also a “patch”

39. 39 /
The 'patch' tool
'patch' takes in a .diff file and updates the file(s) that are the subject of the .diff
'patch < <.diff file>'
To remove one level of directory in patch: 'patch -p1 < <.diff file>'

40. 40 /
Setting up quilt
Set up the 'dquilt' alias: In ~/.bashrc: alias dquilt="quilt --quiltrc=${HOME}/.quiltrc-dpkg" In ~/.quiltrc-dpkg: d=. ; while [ ! -d $d/debian -a `readlink -e $d` != / ]; do d=$d/..; done if [ -d $d/debian ] && [ -z $QUILT_PATCHES ]; then # if in Debian packaging tree with unset $QUILT_PATCHES QUILT_PATCHES="debian/patches" QUILT_PATCH_OPTS="--reject-format=unified" QUILT_PUSH_ARGS="--color=auto" QUILT_DIFF_ARGS="-p ab --no-timestamps --no-index -- color=auto" QUILT_REFRESH_ARGS="-p ab --no-timestamps --no-index" QUILT_COLORS="diff_hdr=1;32:diff_add=1;34:diff_rem=1;31: diff_hunk=1;33:diff_ctx=35:diff_cctx=33" if ! [ -d $d/debian/patches ]; then mkdir $d/debian/patches; fi fi

41. debian/patches quilt 101 Making a new patch:
41 /
debian/patches quilt 101
Making a new patch:
dquilt new <patch_name>
dquilt add <file_name>
edit the <file_name> file
dquilt header -a
dquilt refresh
un-applying all patches:
dquilt pop -a
applying all patches:
dquilt push -a

42. Adding DEP-3 patch headers
42 /
Adding DEP-3 patch headers
quilt patches can include descriptive header
Example (from 'chirp' package): Description: The author includes a copy of the Copyright, but it's not needed as it's the same as one we can reference. Author: Steve Conklin

43. How to get Debian source files
43 /
How to get Debian source files
If you look in your /etc/apt/sources.list file, you might see some 'deb-src' lines:
deb-src sid main
With these in place (and after an 'apt-get update'), download a source package with: 'apt-get source <packagename>'
If there are deb-src lines for multiple distributions you can specify which you want:
'apt-get source mumble/wheezy'

44. Binary vs Source packages
44 /
Binary vs Source packages
Binary packages: dcc-common_ _amd64.deb dcc-milter_ _amd64.deb dcc-server_ _amd64.deb
Source package (3.0 format): k9copy_ debian.tar.gz k9copy_ dsc k9copy_2.3.8.orig.tar.gz

45. 45 /
Older Source packages
Source package (1.0 format): dcc_ diff.gz # .diff from orig. source dcc_ dsc # package description dcc_ orig.tar.gz # “original” source
download/expand nomally via apt-get source <source package> another option: 'dget <URL_path_to_.dsc>' or to get the package from a VCS: debcheckout <source package name>
if downloaded manually, unpack with dpkg-source -x dcc_ dsc

46. 'native' format Avoid making packages in this format, IMHO.
46 /
'native' format
Avoid making packages in this format, IMHO.
Source package '3.0 (native)' format:
debian-keyring_ dsc debian-keyring_ tar.gz
→ no .orig in tarball name, no .diff
No .diff means no patches.
This is a “Debian internal only” format.
man page for dpkg-source contains the list of source package formats

47. Source format popularity
47 /
Source format popularity
graph by Lucas Nussbaum

48. Source in VCS popularity
48 /
Source in VCS popularity
graph by Lucas Nussbaum

49. 49 /
3.0 (git) and (bzr) format
Not very likely to be accepted by ftpmasters because of the headaches these formats would cause
Looking at a Git repository, how can you know which changes happened since the last release?
Consider a non-redistributable file. How do you remove a file from all of Git history?

50. Existing source packages Pt.1
50 /
Existing source packages Pt.1
dch -i #adds new changelog entry
debuild -us -uc #builds package locally, unsigned
debuild -S -us -uc #builds source package locally, unsigned
debdiff <package1.dsc> <package2.dsc> # get differences between to versions of a Debian source package
mk-build-deps #makes meta package containing source dependencies
apt-get build-dep <package> #install build deps

51. 51 /
cowbuilder
Convenient build for different distro and arch, gets required source dependencies, minimal environment catches source build dependency issues (i.e. build-deps) cowbuilder --create --distribution wheezy -- architecutre i basepath /deb-chroots/i386-wheezy- base.cow/
debuild -S -us -uc #make source package
cowbuilder --build dcc_ dsc -- basepath /deb-chroots/i386-wheezy-base.cow/ --buildresult /deb-choot/cow-result/

52. 52 /
Package signing steps
debsign -k<GPG_key_ID> dcc_ _i386.changes
GPG key ID to sign with can be specified in ~/.devscripts file (instead of -k option):
DEBSIGN_KEYID="0x1E759A726A9FDD74"

53. 53 /
dput
Configurable upload program See 'man 5 dput.cf' example: dput coredump chirp_ _amd64.changes
~/.dput.cf file example: [coredump] login = obscure1 fqdn = lethe.ofobscurity.com method = scp ssh_config_options = port=44 incoming = /home/ftp/debian/incoming run_dinstall = 0 progress_indicator = 1

54. 54 /
Caveats
Packages need not build twice. You shouldn't expect 'debuild clean' to always work correctly
Packages from VCS repositories need not come with the source tarball
A package is a fiefdom – the package maintainer(s) have authority over the package
Source tarballs do not have to match upstream

55. 55 /
snapshot.debian.org
Get any uploaded version of a package that had been uploaded to Debian (since snapshots were started)
Program to retrieve snapshots: debsnap
Import snapshots into git-buildpackage: git-import-dscs --debsnap

56. 56 /
Making your own repo
The standard option is the reprepro package. Works fine for several thousand packages.
Debian itself uses DAK, but DAK is heavyweight, uses a custom PostgreSQL schema, and is not available as a Debian package
The mini-buildd package is another option (mini-dinstall does the repo portion)
See 'man apt_preferences' for setting Pin-Priority for your own repository (more on this in a couple of slides)

57. Making a server repo GPG key
57 /
Making a server repo GPG key
Update ~/.gnupg/gpg.conf (explanation at ) with: personal-digest-preferences SHA256 cert-digest-algo SHA256 default-preference-list SHA512 SHA384 \ SHA256 SHA224 AES256 AES192 AES \ CAST5 ZLIB BZIP2 ZIP Uncompressed
create GPG key for signing the package list: gpg --gen-key

58. Export GPG for keyring package
58 /
Export GPG for keyring package
gpg --output coredump-keyring.gpg \ --export-options export-minimal \ --export 0x14A8E94F344E62E3 \ x1E759A726A9FDD74
Make a debian package containing this gpg keyring, and simply drop the keyring into /etc/apt/trusted.gpg.d/
Chicken-and-the-egg: you need to make a Debian keyring package before knowing how to make a package.

59. reprepro package input
59 /
reprepro package input
All reprepro operations are done via command line. Typical operations:
Add package source to 'unstable' archive: reprepro includedsc unstable *.dsc
Add binary package(s) to 'unstable' archive: reprepro include unstable *.changes
Copy package from 'unstable' to 'testing': reprepro copy testing unstable <packages>

60. gpg-agent setup server-side
60 /
gpg-agent setup server-side
in ~/.bashrc:
# start gpg-agent if it's not yet running GPG_AGENT_CHECK=$(ps -ef | fgrep gpg-agent | \ fgrep -v fgrep) if [ -z "$GPG_AGENT_CHECK" ]; then gpg-agent --daemon --write-env-file \ "${HOME}/.gnupg/.gpg-agent-info" fi if [ -f "${HOME}/.gnupg/.gpg-agent-info" ]; then . "${HOME}/.gnupg/.gpg-agent-info" export GPG_AGENT_INFO fi GPG_TTY=$(tty) export GPG_TTY

61. gpg-agent pinentry setup (required)
61 /
gpg-agent pinentry setup (required)
In ~/.gnupg/gpg-agent.conf:
pinentry-program /usr/bin/pinentry-curses default-cache-ttl 1800
(Make sure pinentry-curses is installed)
Test by making a detached signature on some random file gpg --sign <file>

62. Apt Pinning check repo priority with 'apt-cache policy'
62 /
Apt Pinning
check repo priority with 'apt-cache policy'
Add a file in /etc/apt/preferences.d on your local machine to pin by DNS origin: Package: * Pin: origin “debian-packages.coredump.us” Pin-Priority: or pin by release Label: Pin: release l=”Coredump Unofficial Packages”

63. Making package from scratch
63 /
Making package from scratch
Figure out -dev source build dependencies. 'apt-file search <header filename>' helps.
The 'equivs' package may be useful to make meta packages that depend on the necessary '-dev' packages.
Start Debian packaging with 'dh_make'
The “single binary” or “multiple binary” dh_make question refers to single/multiple binary packages (whether the source package makes one or several .deb files)

64. Making a package from scratch
64 /
Making a package from scratch
Choose a packaging “helper”:
dh (“automatic” debhelper methodology)
debhelper (i.e. individual debhelper calls)
cdbs advanced “make” magic (usually also makes debhelper calls)
none raw shell commands (rare)

65. Packaging helper popularity
65 /
Packaging helper popularity
graph by Lucas Nussbaum

66. CDBS No documentation comes with the 'cdbs' package. :-(
66 /
CDBS
No documentation comes with the 'cdbs' package. :-(
However, there is a decent set of web pages for it at:
Moving on, since I haven't used CDBS yet

67. dh/debhelper compat level
67 /
dh/debhelper compat level
Target your distribution – use a debian/compat level that matches the lowest version of debhelper available for all targets (Stable, Testing, Unstable, Precise, etc)
Debian Squeeze = 8, Wheezy, Jessie, Sid = 9 (squeeze-backports = 9)
Ubuntu Lucid = 7, Oneric = 8, Precice, Quantal, Raring, Saucy = 9 (hardy = 6, hardy-backports = 7)

68. debian/rules file clean #clean generated files build #build source
68 /
debian/rules file
clean #clean generated files
build #build source
install #(optional) install file tree
binary #create binary package(s)
binary-arch #create arch: “any” packages
binary-indep #create arch: “all” packages
get-orig-source #(optional) get newest source
patch #(optional) patch source
→ see section 4.9 of the Debian Policy Manual

69. dh vs indvidual debhelper calls
69 /
dh vs indvidual debhelper calls
These days using 'dh' is recommended along with using 'overrides' if necessary
'dh' makes many individual debhelper calls... but the man page doesn't say what they are because dh's behavior morphs
debian/rules via individual debhelper calls manually are generally trickier, and may need to change with debhelper upgrades

70. dh_make default dh debian/rules file
70 /
dh_make default dh debian/rules file
#!/usr/bin/make -f %: dh
sends build target name as a parameter to dh
tab character
% = wildcard (matches anything)
dh operates on 10 targets:
build-arch, build-indep, build, clean, install-indep, install-arch, install, binary-arch, binary-indep, binary

71. 71 /
what dh does
dh changes behavior depending on the type of package(s) the source package builds
The way to find out it's behavior is to run dh --no-act for each build target within the package's directory. Example: dh build-indep --no-act dh_testdir dh_auto_configure dh_auto_build dh_auto_test
Output changes depending on the features of the package; if all binary package types in a source package are “any”, 'dh build-indep' does nothing.

72. prerm / postinst concerns
72 /
prerm / postinst concerns
A word of warning: if you screw up a package's prerm and/or postinst scripts and install the package, it can leave apt in an unchangeable state
If this happens, modify the prerm and/or postinst script in /var/lib/dpkg/info/ to install or remove the package

73. watch / uscan debian/watch file works with the 'uscan' utility
73 /
watch / uscan
debian/watch file works with the 'uscan' utility
uscan checks if there is a new version of the upstream source available (and can also download the new upstream source tarball)

74. package checkers 74 / lintian Checks for packaging issues
piuparts Checks for binary package installation / removal / purge issues in a chroot
blhc <build_log> Build log hardening checker

75. Package changelog entry
75 /
mumble ( g315b5f5-2.1) unstable; urgency=low
Package urgency is a setting used internally by the Debian Release Team to denote how quickly a package should transition from Unstable to Testing:
urgency
transition delay
low
10 days
medium
5 days
high
2 days
critical
ASAP
emergency

76. Debian packaging with Git
76 /
Debian packaging with Git
git-buildpackage → gbp-clone git-buildpackage gbp-pq … [7 more commands]
git-dpm → git-dpm
gitpkg → git-debimport gitpkg

77. 77 /
pristine-tar
Trickery for Git to allow reforming the orig source tarball
Create delta in Git via: pristine-tar [tarball] [delta_name]
Reform tarball with: pristine-tar gentar [delta] [tarball]
See list of available tarballs: pristine-tar list

78. 78 /
Which to choose?
git-buildpackage: – what most DDs seem to be using – lots of documentation and examples
git-dpm: – documentation comes with examples – good looking man pages
gitpkg: – no documentation in /usr/share/doc – man page example is very short and only shows one gitpkg command – maintainer is the same one as the Mumble package...

79. some initial Git settings
79 /
some initial Git settings
in ~/.gitconfig set color modes:
[user] name = Christopher Knadle = [color] status = auto branch = auto diff = auto

80. git-buildpackage Import current Debian source package git-importdsc
80 /
git-buildpackage
Import current Debian source package git-importdsc
Import Debian package history from snapshot.debian.org git-import-dscs --debsnap
Annotate current changelog using Git shortlog entries git-dch

81. git-buildpackage resources
81 /
git-buildpackage resources
“What git-buildpackage can (hopefully) do for you” from DebConf10

82. 82 /
Git submodules
Some upstream sources in Git use submodules, and when they do certain source directories are empty. The way to tell is to look for one (or several) '.ggitmodules' file(s).
Pull the submodules via: 'git submodules update'
Reference:

83. 83 /
Conclusion
"You can't know **everything** about Debian." – Ana Beatriz Guerrero López,
March 2013