<?xml version="1.0" encoding="utf-8"?>

<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
<title type="text">madduck's droppings</title>
<subtitle type="html"><![CDATA[
The weblog by martin f. krafft aka. madduck
]]></subtitle>
<id>http://blog.madduck.net/debian/index.atom</id>
<link rel="alternate" type="text/html" href="http://blog.madduck.net" />
<link rel="self" type="text/xml" href="http://blog.madduck.net/debian/index.atom" />

<author>
<name>martin f. krafft (madduck)</name>
<uri>http://blog.madduck.net/debian/index.atom</uri>
<email>comments@blog.madduck.net</email>
</author>
<rights></rights>
<generator uri="http://pyblosxom.sourceforge.net/" version="1.3.2 2/13/2006">
PyBlosxom http://pyblosxom.sourceforge.net/ 1.3.2 2/13/2006
</generator>

<updated>2007-12-18T22:50:15Z</updated>
<!-- icon?  logo?  -->

<entry>
<title type="html">bugscripts and rng
</title>
<category term="" />
<id>http://blog.madduck.net/2007/12/18/2007.12.18_bugscripts-and-rng</id>
<updated>2007-12-18T22:50:15Z</updated>
<published>2007-12-18T22:50:15Z</published>
<link rel="alternate" type="text/html" href="http://blog.madduck.net/debian/2007.12.18_bugscripts-and-rng" />
<content type="html">&lt;p&gt;Yes, &lt;a class=&quot;reference&quot; href=&quot;http://blog.venthur.de/2007/12/18/on-422085-and-417256/&quot;&gt;Bastian&lt;/a&gt;,
there is a way to do what you want. I believe I told you from the very start:
refactor &lt;a class=&quot;reference&quot; href=&quot;http://packages.debian.org/sid/reportbug&quot;&gt;reportbug&lt;/a&gt; and
implement &lt;a class=&quot;reference&quot; href=&quot;http://packages.debian.org/sid/reportbug-ng&quot;&gt;reportbug-ng&lt;/a&gt; on top
of the existing code. But no, you chose to reimplement everything (a typical
thing to do for GUI programmers) and now you are asking us maintainers to
change the way we&apos;ve been doing things for years?&lt;/p&gt;
&lt;p&gt;You also make presumptuous statements about how we deal with bug reports. If
you &lt;em&gt;personally&lt;/em&gt; hate how certain packages prepare bug reports, then maybe you
should &lt;em&gt;personally&lt;/em&gt; suck it up and use different software? Seems like a more
logical and less intrusive way forward, then expecting others to &amp;quot;send
a friendly mail&amp;quot; to ask for more information on a bug report. Maybe you have
all the time in the world, but I don&apos;t. I can work on e.g. &lt;a class=&quot;reference&quot; href=&quot;http://packages.debian.org/sid/mdadm&quot;&gt;mdadm&lt;/a&gt; (which uses an &lt;a class=&quot;reference&quot; href=&quot;http://git.debian.org/?p=pkg-mdadm/mdadm.git;a=blob;f=debian/bugscript&quot;&gt;interactive bug
script&lt;/a&gt;)
only on rare occasions, and then I&apos;d rather fix and close bugs than to indulge
in another iteration of bug submitter ping-pong.&lt;/p&gt;
&lt;p&gt;You are also &lt;em&gt;personally&lt;/em&gt; annoyed by long pre-subject texts, which you doubt
anyone reads? I don&apos;t even bother to challenge that, but let me say that
pre-subject texts are there to prevent stupid bug reports, or bug reports
filed in the wrong place, and to take load off the maintainer. So you chose to
ignore them? Given the projected user-base of your tool, I&apos;d say you should
rather force people to read them by asking them to transcribe the text.&lt;/p&gt;
&lt;p&gt;If you don&apos;t want to pop up a terminal, well, why the heck didn&apos;t you
integrate &lt;a class=&quot;reference&quot; href=&quot;http://packages.debian.org/sid/debconf&quot;&gt;debconf&lt;/a&gt; properly, while
reusing &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;reportbug&lt;/span&gt;&lt;/tt&gt;, and taking a step forward to provide a proper interface
for bug scripts? Why do you even bother to whine about interface issues at
this point?&lt;/p&gt;
&lt;p&gt;Feel free to take over my packages, which make use of interactive bug scripts.
I see &lt;em&gt;zero&lt;/em&gt; reason to change them, and I will not.&lt;/p&gt;
&lt;p&gt;NP: &lt;a class=&quot;reference&quot; href=&quot;http://www.allmusic.com/cg/amg.dll?SQL=The%20Flower%20Kings&amp;amp;P=amg&amp;amp;OPT1=1&quot;&gt;The Flower Kings&lt;/a&gt;: &lt;em&gt;Paradox Hotel&lt;/em&gt;&lt;/p&gt;
</content>
</entry>

<entry>
<title type="html">Rewarding geek^W survey participants
</title>
<category term="" />
<id>http://blog.madduck.net/2007/11/29/2007.11.29_rewarding-geeks</id>
<updated>2007-11-29T07:57:49Z</updated>
<published>2007-11-29T07:57:49Z</published>
<link rel="alternate" type="text/html" href="http://blog.madduck.net/debian/2007.11.29_rewarding-geeks" />
<content type="html">&lt;p&gt;Sooner or later, I will conduct a series of interviews as well as a community
survey among Debian package maintainers as part of &lt;a class=&quot;reference&quot; href=&quot;http://phd.martin-krafft.net/&quot;&gt;my research&lt;/a&gt;. The motivation for my research is to
improve the workflows in the Debian project.&lt;/p&gt;
&lt;p&gt;How could I make you take part in such a survey?&lt;/p&gt;
&lt;p&gt;A key challenge and necessity of a survey is to ensure a high degree of
participation, or else the responses cannot be read as descriptive of the
entire group. Well-formulated questions and a smart way to present them are
prerequisites. For instance, I&apos;d consider it quite counter-productive
(somewhat ironic even) to ask Debian package maintainers to hit radio buttons
on a web form. Instead, participation should require the use of tools with
which we are familiar.&lt;/p&gt;
&lt;p&gt;Another way to get people to respond is by showing how their time will help
the project. This assumes that the research hypothesis is tangible and the
whole endeavour plausible. And that people care.&lt;/p&gt;
&lt;p&gt;A third means of motivation is to reward participants. Commonly, this is done
by way of a draw among all participants at the end of the survey, and a price
given out to the (random) winner. Obviously, the individual&apos;s chances get
slimmer with every additional participant, but if the price is right, it&apos;s
still worth a try.&lt;/p&gt;
&lt;p&gt;I&apos;ve been pondering for a few days on what a right price would be. Previously,
&lt;a class=&quot;reference&quot; href=&quot;http://nokia770.com/383&quot;&gt;Nokia Internet tablets&lt;/a&gt; have been hip, but would
you dedicate your time to a survey where you could win one of those? Or
a &lt;a class=&quot;reference&quot; href=&quot;http://wiki.openmoko.org/wiki/Neo1973&quot;&gt;Neo1973&lt;/a&gt; (thanks Lo-lan-do)? Or
would a game console, such as the &lt;a class=&quot;reference&quot; href=&quot;http://uk.playstation.com/ps3/&quot;&gt;PS3&lt;/a&gt; or
the &lt;a class=&quot;reference&quot; href=&quot;http://wii.nintendo.com/&quot;&gt;Wii&lt;/a&gt; be more exciting? Or is there something
(in the same price range) out there you &lt;em&gt;want&lt;/em&gt; and would, uh, fill for… fill
out the survey I mean…&lt;/p&gt;
&lt;p&gt;Please &lt;a class=&quot;reference&quot; href=&quot;mailto:survey-rewards&amp;#64;pobox.madduck.net&quot;&gt;take a moment and let me know which price you could not resist&lt;/a&gt;. Don&apos;t hesitate to provide me with
a list — I could just as well let the winner of the draw chose her/his
favourite…&lt;/p&gt;
&lt;p&gt;NP: &lt;a class=&quot;reference&quot; href=&quot;http://www.allmusic.com/cg/amg.dll?SQL=Pineapple%20Thief&amp;amp;P=amg&amp;amp;OPT1=1&quot;&gt;The Pineapple Thief&lt;/a&gt;: &lt;em&gt;8 Days Later&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Update&lt;/strong&gt;: Gaudenz Steinlin suggested a &lt;a class=&quot;reference&quot; href=&quot;http://www.thecus.com/products_over.php?cid=11&amp;amp;pid=1&quot;&gt;Thecus N2100&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Update&lt;/strong&gt;: Frans Pop suggested an &lt;a class=&quot;reference&quot; href=&quot;http://eeepc.asus.com/global/&quot;&gt;Asus Eee PC&lt;/a&gt;.&lt;/p&gt;
</content>
</entry>

<entry>
<title type="html">Converting a package to Git
</title>
<category term="" />
<id>http://blog.madduck.net/2007/10/14/2007.10.07_converting-a-package-to-git</id>
<updated>2007-10-14T14:30:10Z</updated>
<published>2007-10-14T14:30:10Z</published>
<link rel="alternate" type="text/html" href="http://blog.madduck.net/debian/2007.10.07_converting-a-package-to-git" />
<content type="html">&lt;p&gt;Previously, I &lt;a class=&quot;reference&quot; href=&quot;http://blog.madduck.net/debian/2007.10.03_packaging-with-git&quot;&gt;demonstrated a Debian packaging workflow using Git&lt;/a&gt; and
I mentioned the possibility of a follow-up post; well, here it is: you want to
use my workflow (or one that&apos;s related) for a package that is currently
maintained with &lt;a class=&quot;reference&quot; href=&quot;http://subversion.tigris.org/&quot;&gt;Subversion&lt;/a&gt; on
&lt;a class=&quot;reference&quot; href=&quot;http://svn.debian.org&quot;&gt;svn.debian.org&lt;/a&gt; and you&apos;d like to keep the history
during the conversion.&lt;/p&gt;
&lt;p&gt;Make sure to read the &lt;a class=&quot;reference&quot; href=&quot;http://blog.madduck.net/debian/2007.10.03_packaging-with-git&quot;&gt;previous post&lt;/a&gt; before this
one.&lt;/p&gt;
&lt;p&gt;I am again using the example of &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;mdadm&lt;/span&gt;&lt;/tt&gt; since its &lt;a class=&quot;reference&quot; href=&quot;http://git.debian.org/?p=pkg-mdadm/mdadm.git;a=summary&quot;&gt;Git packaging repository&lt;/a&gt; is in a state of
shambles and I want to restart to get it right &lt;em&gt;and&lt;/em&gt; import the history from
the previous &lt;a class=&quot;reference&quot; href=&quot;http://svn.debian.org/wsvn/pkg-mdadm&quot;&gt;Subversion repository&lt;/a&gt;.
What better way than to write a blog post as I do so? Well, plenty actually.
This kind of post &lt;a class=&quot;reference&quot; href=&quot;http://etbe.coker.com.au/2007/09/30/blogging-and-documents/&quot;&gt;isn&apos;t really made for a blog&lt;/a&gt;, and I have
started work on setting up &lt;a class=&quot;reference&quot; href=&quot;http://ikiwiki.info&quot;&gt;ikiwiki&lt;/a&gt; on &lt;a class=&quot;reference&quot; href=&quot;http://madduck.net&quot;&gt;madduck.net&lt;/a&gt;, but it&apos;s not yet ready, so I&apos;ll stick with the blog
for now. I will make sure that links don&apos;t break as I move content over, so
feel free to bookmark this…&lt;/p&gt;
&lt;div class=&quot;section&quot;&gt;
&lt;h4&gt;&lt;a id=&quot;importing-the-package-into-git&quot; name=&quot;importing-the-package-into-git&quot;&gt;Importing the package into Git&lt;/a&gt;&lt;/h4&gt;
&lt;p&gt;Thanks to &lt;a class=&quot;reference&quot; href=&quot;http://utsl.gen.nz/talks/git-svn/intro.html&quot;&gt;git-svn&lt;/a&gt;, the
initial step of getting your package imported into Git is a breeze:&lt;/p&gt;
&lt;pre class=&quot;literal-block&quot;&gt;
$ git-svn clone --stdlayout --no-metadata \
    svn+ssh://svn.debian.org/svn/pkg-mdadm/mdadm mdadm
&lt;/pre&gt;
&lt;p&gt;Sit back and enjoy. If that command exits prematurely with an error such as
the following:&lt;/p&gt;
&lt;blockquote&gt;
Malformed network data: Malformed network data at /usr/local/bin/git-svn
line 1029&lt;/blockquote&gt;
&lt;p&gt;then you should upgrade to a newer Git version, or have a look &lt;a class=&quot;reference&quot; href=&quot;http://lists.zerezo.com/git/msg623930.html&quot;&gt;here&lt;/a&gt;. If your Git does not know
&lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;--stdlayout&lt;/span&gt;&lt;/tt&gt; then upgrade as well (or use &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;-T&lt;/span&gt; &lt;span class=&quot;pre&quot;&gt;trunk&lt;/span&gt; &lt;span class=&quot;pre&quot;&gt;-t&lt;/span&gt; &lt;span class=&quot;pre&quot;&gt;tags&lt;/span&gt; &lt;span class=&quot;pre&quot;&gt;-b&lt;/span&gt; &lt;span class=&quot;pre&quot;&gt;branches&lt;/span&gt;&lt;/tt&gt;
instead).&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Sam Vilain notes that it is important to &amp;quot;get the attribution right with the
final SVN import - getting the authors map right. I didn&apos;t do that. If you
look at the repository resulting from the above command, you&apos;ll notice strange
commit authors, such as ``madduck&amp;#64;some-unique-uuid-from-svn``. ``git-svn``
allows you to map these to real names with real email addresses, which ensures
that the attributions are good for the whole world to see.&lt;/strong&gt;&lt;/p&gt;
&lt;p&gt;When done, switch to the repository and run &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;git-branch&lt;/span&gt; &lt;span class=&quot;pre&quot;&gt;-r&lt;/span&gt;&lt;/tt&gt;. As you&apos;ll see,
&lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;git-svn&lt;/span&gt;&lt;/tt&gt; imported all SVN branches and tags as remote branches. You need
those if you want to bidirectionally track the Subversion repository, but we
are converting, as you may have guessed by the &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;--no-metadata&lt;/span&gt;&lt;/tt&gt; switch above.&lt;/p&gt;
&lt;p&gt;Therefore, we resort to &lt;a class=&quot;reference&quot; href=&quot;http://ze-dinosaur.livejournal.com/18564.html&quot;&gt;the Dinosaur method of converting branches to tags&lt;/a&gt;, which I&apos;ll simplify for
&lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;mdadm&lt;/span&gt;&lt;/tt&gt;. We also just delete all remote branches after tagging, since
&lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;mdadm&lt;/span&gt;&lt;/tt&gt; never used branches in the &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;SVN&lt;/span&gt;&lt;/tt&gt; repository. Your mileage may
vary.&lt;/p&gt;
&lt;pre class=&quot;literal-block&quot;&gt;
git branch -r | sed -rne &apos;s, *tags/([^&amp;#64;]+)$,\1,p&apos; | while read tag; do
  echo &amp;quot;git tag debian/$tag tags/${tag}^; git branch -r -d tags/$tag&amp;quot;
done

git branch -r | while read tag; do
  echo &amp;quot;git branch -r -d $tag&amp;quot;
done
&lt;/pre&gt;
&lt;p&gt;If that seems to work alright, then you can execute the commands.&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Sam Vilain (again) hints me at ``git-pack-refs`` and then to edit
``.git/packed-refs`` with an editor. This certainly leaves more room for
errors but might be significantly faster.&lt;/strong&gt;&lt;/p&gt;
&lt;/div&gt;
&lt;div class=&quot;section&quot;&gt;
&lt;h4&gt;&lt;a id=&quot;cleaning-up-the-svn-references&quot; name=&quot;cleaning-up-the-svn-references&quot;&gt;Cleaning up the SVN references&lt;/a&gt;&lt;/h4&gt;
&lt;p&gt;Even though we passed &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;--no-metadata&lt;/span&gt;&lt;/tt&gt; to &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;git-svn&lt;/span&gt;&lt;/tt&gt;, it did leave some
traces in &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;.git/&lt;/span&gt;&lt;/tt&gt;, which we can now safely remove:&lt;/p&gt;
&lt;pre class=&quot;literal-block&quot;&gt;
$ git config --remove-section svn-remote.svn
$ rm -r .git/svn
&lt;/pre&gt;
&lt;/div&gt;
&lt;div class=&quot;section&quot;&gt;
&lt;h4&gt;&lt;a id=&quot;setting-things-straight&quot; name=&quot;setting-things-straight&quot;&gt;Setting things straight&lt;/a&gt;&lt;/h4&gt;
&lt;p&gt;You can skip this section unless you want to know a bit about how to fix up
stuff with Git.&lt;/p&gt;
&lt;p&gt;There was actually some nasty tagging errors leading up to the &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;2.5.6-9&lt;/span&gt;&lt;/tt&gt;
release for &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;etch&lt;/span&gt;&lt;/tt&gt; and I could never be bothered to fix those in &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;SVN&lt;/span&gt;&lt;/tt&gt;,
but now I can (I love Git!):&lt;/p&gt;
&lt;pre class=&quot;literal-block&quot;&gt;
$ git tag -d debian/2.5.6-10            # never existed
$ git tag -f debian/2.5.6-8 2.5.6-8~2   # mistagged
$ git checkout -b maint/etch 2.5.6-8    # this is when we diverged
$ git apply &amp;lt; /tmp/mdadm-2.5.6-8..2.5.6-9.diff
$ git add debian/po/gl.po debian/po/pt.po debian/changelog
$ git commit -s
$ git tag debian/2.5.6-9
&lt;/pre&gt;
&lt;p&gt;Now that that&apos;s fixed, there is one other thing to worry about, namely the
very last commit to &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;SVN&lt;/span&gt;&lt;/tt&gt;, which obsoletes the repository and points to the
Git repository. But that&apos;s not all of it. I was also silly enough to include
a fix in the &lt;em&gt;same&lt;/em&gt; commit. Let&apos;s see what Git can do. Since the process of
obsoletion involves all but adding a file, we can simply &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;--amend&lt;/span&gt;&lt;/tt&gt; the last
commit and provide a new log message:&lt;/p&gt;
&lt;pre class=&quot;literal-block&quot;&gt;
$ git checkout master
$ git rm OBSOLETE debian/OBSOLETE
$ git commit --amend
&lt;/pre&gt;
&lt;p&gt;Now the repository is in an acceptable state.&lt;/p&gt;
&lt;/div&gt;
&lt;div class=&quot;section&quot;&gt;
&lt;h4&gt;&lt;a id=&quot;making-ends-meet&quot; name=&quot;making-ends-meet&quot;&gt;Making ends meet&lt;/a&gt;&lt;/h4&gt;
&lt;p&gt;The &lt;a class=&quot;reference&quot; href=&quot;http://svn.debian.org/wsvn/pkg-mdadm/mdadm/trunk/?rev=0&amp;amp;sc=0&quot;&gt;pkg-mdadm effort on svn.debian.org&lt;/a&gt; only
maintained the &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;./debian/&lt;/span&gt;&lt;/tt&gt; directory, separate from the upstream code, and boy
was that a bad idea. Just to give one example: think about what&apos;s involved in
preparing a Debian-specific patch against the upstream code… this has to end,
and we can make it end right here; let&apos;s import upstream&apos;s code (again not
using his ADSL line, but the &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;upstream&lt;/span&gt;&lt;/tt&gt; branch of the &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;pkg-mdadm&lt;/span&gt;&lt;/tt&gt; Git
repository; see the &lt;a class=&quot;reference&quot; href=&quot;http://blog.madduck.net/debian/2007.10.03_packaging-with-git&quot;&gt;previous post&lt;/a&gt; for
details):&lt;/p&gt;
&lt;pre class=&quot;literal-block&quot;&gt;
$ git remote add upstream-repo git://git.debian.org/git/pkg-mdadm/mdadm
$ git config remote.upstream-repo.fetch \
    +refs/heads/upstream:refs/remotes/upstream-repo/upstream
$ git fetch upstream-repo
$ git checkout -b upstream upstream-repo/master
&lt;/pre&gt;
&lt;p&gt;Now we have two unconnected ancestries in our repository, and it&apos;s time to
join them together. The most logical way seems to be to use the last upstream
tag for which we have a Debian tag: &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;2.6.2&lt;/span&gt;&lt;/tt&gt;.&lt;/p&gt;
&lt;p&gt;For this, we branch off the corresponding Debian tag (&lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;2.6.2-1&lt;/span&gt;&lt;/tt&gt;) and merge
upstream&apos;s &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;2.6.2&lt;/span&gt;&lt;/tt&gt; tag into the new branch. This will be a temporary branch
Then, we rebase (remember, nothing has been published yet) the master branch
on top of this temporary branch, before we end that branch&apos;s short life. The
Debian tag stays where it is since it describes the state of the repository at
time of the release of &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;2.6.2-1&lt;/span&gt;&lt;/tt&gt;.&lt;/p&gt;
&lt;pre class=&quot;literal-block&quot;&gt;
$ git checkout -b tmp/join debian/2.6.2-1
$ git merge mdadm-2.6.2

$ git rebase tmp/join master
$ git branch -d tmp/join
&lt;/pre&gt;
&lt;p&gt;It just so happens that the head of the &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;SVN&lt;/span&gt;&lt;/tt&gt; repository, which is identical
to the tip of our &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;master&lt;/span&gt;&lt;/tt&gt; branch, corresponds to Debian release
&lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;2.6.2-2&lt;/span&gt;&lt;/tt&gt;, so we tag it:&lt;/p&gt;
&lt;pre class=&quot;literal-block&quot;&gt;
$ git tag debian/2.6.2-2
&lt;/pre&gt;
&lt;p&gt;We are now also &amp;quot;born&amp;quot; in the sense that maintenance in Git has started. Let&apos;s
mark that point in history. There is no real reason I can foresee for this
yet, but nonetheless:&lt;/p&gt;
&lt;pre class=&quot;literal-block&quot;&gt;
$ git tag -s git-birth
&lt;/pre&gt;
&lt;/div&gt;
&lt;div class=&quot;section&quot;&gt;
&lt;h4&gt;&lt;a id=&quot;turning-dpatch-files-into-feature-branches&quot; name=&quot;turning-dpatch-files-into-feature-branches&quot;&gt;Turning &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;dpatch&lt;/span&gt;&lt;/tt&gt; files into feature branches&lt;/a&gt;&lt;/h4&gt;
&lt;p&gt;We want to turn &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;dpatch&lt;/span&gt;&lt;/tt&gt; files into feature branches and we somehow make it
&amp;quot;proper&amp;quot;. We could branch, apply the patch, delete the patch file, checkout
&lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;master&lt;/span&gt;&lt;/tt&gt; and delete the patch file there as well, but that appears
&amp;quot;improper&amp;quot; to me at least; so instead, we&apos;ll cherry-pick:&lt;/p&gt;
&lt;pre class=&quot;literal-block&quot;&gt;
$ git checkout -b deb/conffile-location
$ debian/patches/01-mdadm.conf-location.dpatch -apply
$ git rm debian/patches/01-mdadm.conf-location.dpatch
$ git commit -s
$ git commit -s $(git ls-files --others --modified)
&lt;/pre&gt;
&lt;p&gt;I should quickly intervene to make sure you are following. I am making use of
Git&apos;s index here. Applying the patch makes the changes in the working tree,
but we did not tell Git that we want those to be part of the commit just yet.
Instead, we delete the &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;dpatch&lt;/span&gt;&lt;/tt&gt; with &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;git-rm&lt;/span&gt;&lt;/tt&gt;, which automatically
registers the deletion with the index. Thus, the first &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;git-commit&lt;/span&gt;&lt;/tt&gt; creates
a commit which deletes the &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;dpatch&lt;/span&gt;&lt;/tt&gt;, while the second &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;git-commit&lt;/span&gt;&lt;/tt&gt;
creates a commit with all the changes from the &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;dpatch&lt;/span&gt;&lt;/tt&gt;, using
&lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;git-ls-files&lt;/span&gt;&lt;/tt&gt; to identify new and modified files.&lt;/p&gt;
&lt;p&gt;But for now, let&apos;s move on. We have two commits in the
&lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;deb/conffile-location&lt;/span&gt;&lt;/tt&gt; branch, and one of those is relevant to the
&lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;master&lt;/span&gt;&lt;/tt&gt; branch, we cherry-pick it:&lt;/p&gt;
&lt;pre class=&quot;literal-block&quot;&gt;
$ git cherry-pick deb/conffile-location^
&lt;/pre&gt;
&lt;p&gt;If you&apos;re confused, let me explain: our goal is to have a number of feature
branches, of which &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;master&lt;/span&gt;&lt;/tt&gt; is the one in which most of &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;./debian/&lt;/span&gt;&lt;/tt&gt; is
maintained. All the branches later come together in the long-living &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;build&lt;/span&gt;&lt;/tt&gt;
branch, so &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;deb/conffile-location&lt;/span&gt;&lt;/tt&gt; will never be merged back into
&lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;master&lt;/span&gt;&lt;/tt&gt;. However, once we applied the &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;dpatch&lt;/span&gt;&lt;/tt&gt; to the feature branch, we
can delete it from there and the &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;master&lt;/span&gt;&lt;/tt&gt; branch. By cherry-picking, we
&amp;quot;import&amp;quot; the deletion to the &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;master&lt;/span&gt;&lt;/tt&gt; branch.&lt;/p&gt;
&lt;p&gt;I repeat the same procedure for &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;deb/docs&lt;/span&gt;&lt;/tt&gt;, merging all the
documentation-related &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;dpatches&lt;/span&gt;&lt;/tt&gt;, but I&apos;ll spare you the details.&lt;/p&gt;
&lt;/div&gt;
&lt;div class=&quot;section&quot;&gt;
&lt;h4&gt;&lt;a id=&quot;and-then-git-let-me-down&quot; name=&quot;and-then-git-let-me-down&quot;&gt;… and then Git let me down&lt;/a&gt;&lt;/h4&gt;
&lt;p&gt;In the next step, I found I had misunderstood Git merging: I thought Git was
smart, but Linus had his reasons for calling Git the &amp;quot;stupid content tracker&amp;quot;
(more on that later). Read on as I am obsoleting &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;dpatch&lt;/span&gt;&lt;/tt&gt; files that
upstream had merged: &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;99-*-FIX.dpatch&lt;/span&gt;&lt;/tt&gt;.&lt;/p&gt;
&lt;p&gt;For consistency, I wanted to cherry-pick each of the appropriate upstream
commits into the &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;master&lt;/span&gt; &lt;span class=&quot;pre&quot;&gt;branch&lt;/span&gt;&lt;/tt&gt; along with deleting the corresponding
&lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;dpatch&lt;/span&gt;&lt;/tt&gt; file. Here is one example: &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;99-monitor-6+10-FIX.dpatch&lt;/span&gt;&lt;/tt&gt; was
obsoleted by upstream&apos;s commit &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;66f8bbb&lt;/span&gt;&lt;/tt&gt;; the &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;-x&lt;/span&gt;&lt;/tt&gt; records the original
commit ID in the log:&lt;/p&gt;
&lt;pre class=&quot;literal-block&quot;&gt;
$ git cherry-pick -x 66f8bbb
$ git rm debian/patches/99-monitor-6+10-FIX.dpatch
$ git commit -s -m&amp;quot;remove dpatch obsoleted by $(git rev-parse --short HEAD)&amp;quot;
&lt;/pre&gt;
&lt;p&gt;I repeated the procedure for the other &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;dpatch&lt;/span&gt;&lt;/tt&gt; files, removed the
&lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;dpatch&lt;/span&gt;&lt;/tt&gt; infrastructure, and then went on to merge it all into &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;build&lt;/span&gt;&lt;/tt&gt; to
build the package.&lt;/p&gt;
&lt;p&gt;The &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;build&lt;/span&gt;&lt;/tt&gt; branch is a long-living branch off &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;upstream&lt;/span&gt;&lt;/tt&gt;, but which
&lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;upstream&lt;/span&gt;&lt;/tt&gt;? I&apos;ll fast-forward you past &lt;a class=&quot;reference&quot; href=&quot;http://marc.info/?l=linux-raid&amp;amp;m=118915389623898&amp;amp;w=2&quot;&gt;a segfault problem with mdadm&lt;/a&gt;, which &lt;a class=&quot;reference&quot; href=&quot;http://marc.info/?l=linux-raid&amp;amp;m=119060815423662&amp;amp;w=2&quot;&gt;upstream
(thought to have) resolved with commit 23dc1ae&lt;/a&gt; &lt;em&gt;after&lt;/em&gt; &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;2.6.3&lt;/span&gt;&lt;/tt&gt;,
but he had not yet released &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;2.6.4&lt;/span&gt;&lt;/tt&gt;. Looking at the commits between
&lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;23dc1ae&lt;/span&gt;&lt;/tt&gt; and upstream&apos;s &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;HEAD&lt;/span&gt;&lt;/tt&gt; at the time, I decided to include them all
and snapshot &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;4450e59&lt;/span&gt;&lt;/tt&gt;:&lt;/p&gt;
&lt;pre class=&quot;literal-block&quot;&gt;
$ git fetch upstream-repo
$ git checkout upstream
$ git merge upstream-repo
$ git tag mdadm-2.6.3+200709292116+4450e59 4450e59

$ git checkout master
$ git merge --no-commit mdadm-2.6.3+200709292116+4450e59
$ dch -v mdadm-2.6.3+200709292116+4450e59-1
$ git add debian/changelog
$ git commit -s
&lt;/pre&gt;
&lt;p&gt;And then I called &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;poor-mans-gitbuild&lt;/span&gt;&lt;/tt&gt;, which merges &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;master&lt;/span&gt;&lt;/tt&gt; and then
&lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;deb/*&lt;/span&gt;&lt;/tt&gt; into &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;build&lt;/span&gt;&lt;/tt&gt;. Here is when stuff blew up.&lt;/p&gt;
&lt;p&gt;I&apos;ll make a long story short (read &lt;a class=&quot;reference&quot; href=&quot;http://marc.info/?l=git&amp;amp;m=119198136508405&amp;amp;w=2&quot;&gt;my description of the problem&lt;/a&gt; and &lt;a class=&quot;reference&quot; href=&quot;http://marc.info/?l=git&amp;amp;m=119198488411957&amp;amp;w=2&quot;&gt;Linus&apos; answer&lt;/a&gt; if you want to know more):
I thought Git was smart to identify merges common to both branches and do the
right thing, but it turn out that Git does not care &lt;em&gt;at all&lt;/em&gt; about commits, it
&lt;em&gt;only&lt;/em&gt; worries about content and the end result. In our case, unfortunately
(or fortunately), the outcome meant a conflict because the upstream branch
introduced &lt;a class=&quot;reference&quot; href=&quot;http://git.debian.org/?p=pkg-mdadm/mdadm.git;a=commitdiff;h=4450e59ffaf75623fa4261e244b0717a7463aa84&quot;&gt;a simple change (last hunk)&lt;/a&gt;
in the lines surrounding the patch we cherry-picked, and Git can&apos;t handle it.&lt;/p&gt;
&lt;p&gt;The solution is &lt;em&gt;not&lt;/em&gt; to cherry-pick, to cherry-pick &lt;em&gt;all&lt;/em&gt; commits touching
the context of the &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;dpatch&lt;/span&gt;&lt;/tt&gt;, or to simply merge &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;upstream&lt;/span&gt;&lt;/tt&gt; into all out
feature branches. In our case, the first is the easiest solution and since
importing &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;dpatch&lt;/span&gt;&lt;/tt&gt; files is a one-time thing (thank &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;$DEITY&lt;/span&gt;&lt;/tt&gt;), I&apos;ll leave
it at that.&lt;/p&gt;
&lt;p&gt;Almost.&lt;/p&gt;
&lt;p&gt;I have spent two days thinking about this more than I should have. And it was
&lt;a class=&quot;reference&quot; href=&quot;http://marc.info/?l=git&amp;amp;m=119203197706666&amp;amp;w=2&quot;&gt;this point Linus made&lt;/a&gt; which
made me appreciate Git even more:&lt;/p&gt;
&lt;blockquote&gt;
Conflicts aren&apos;t bad - they&apos;re &lt;em&gt;good&lt;/em&gt;. Trying to aggressively resolve them
automatically when two branches have done slightly different things in the
same area is stupid and just results in more problems. Instead, git tries to
do what I don&apos;t think &lt;em&gt;anybody&lt;/em&gt; else has done: make the conflicts easy to
resolve, by allowing you to work with them in your normal working tree, and
still giving you a lot of tools to help you see what&apos;s going on.&lt;/blockquote&gt;
&lt;/div&gt;
&lt;div class=&quot;section&quot;&gt;
&lt;h4&gt;&lt;a id=&quot;the-end&quot; name=&quot;the-end&quot;&gt;The end&lt;/a&gt;&lt;/h4&gt;
&lt;p&gt;This concludes today&apos;s report. Importing the changes from the old Git repo,
tagging and merging the branches is all covered &lt;a class=&quot;reference&quot; href=&quot;http://blog.madduck.net/debian/2007.10.03_packaging-with-git&quot;&gt;in my previous post&lt;/a&gt;, or at least
you&apos;ll find enough information there to complete the exercise.&lt;/p&gt;
&lt;p&gt;I would like to specifically thank Sam Vilain and Linus Torvalds for their
help in preparing this post, as well as the &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;#git/freenode&lt;/span&gt;&lt;/tt&gt; inhabitants, as
always.&lt;/p&gt;
&lt;p&gt;If you are interested in the topic of using version control for distro
packaging, I invite you to join &lt;a class=&quot;reference&quot; href=&quot;http://lists.madduck.net/listinfo/vcs-pkg&quot;&gt;the vcs-pkg mailing list&lt;/a&gt; and/or the
&lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;#vcs-pkg/irc.oftc.net&lt;/span&gt;&lt;/tt&gt; IRC channel.&lt;/p&gt;
&lt;p&gt;Also, if you are interested in Git in general, you can find a &lt;a class=&quot;reference&quot; href=&quot;http://git.or.cz/gitwiki/BlogPosts&quot;&gt;list of blog
posts&lt;/a&gt; on the &lt;a class=&quot;reference&quot; href=&quot;http://git.or.cz/gitwiki/&quot;&gt;Git wiki&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;NP: &lt;a class=&quot;reference&quot; href=&quot;http://www.allmusic.com/cg/amg.dll?SQL=The%20Police&amp;amp;P=amg&amp;amp;OPT1=1&quot;&gt;The Police&lt;/a&gt;: &lt;em&gt;Zenyatta Mondatta&lt;/em&gt;&lt;/p&gt;
&lt;/div&gt;
</content>
</entry>

<entry>
<title type="html">Not so chatty
</title>
<category term="" />
<id>http://blog.madduck.net/2007/10/11/2007.10.10_not-so-chatty</id>
<updated>2007-10-11T18:15:10Z</updated>
<published>2007-10-11T18:15:10Z</published>
<link rel="alternate" type="text/html" href="http://blog.madduck.net/debian/2007.10.10_not-so-chatty" />
<content type="html">&lt;p&gt;Since its inception 4458 days ago, the &lt;a class=&quot;reference&quot; href=&quot;http://lists.debian.org/debian-devel&quot;&gt;debian-devel mailing list&lt;/a&gt; has processed only just over
a quarter million messages, 258378 to be exact. That&apos;s a measely 58 messages
per day, not even three per hour, only one every 25 minutes.&lt;/p&gt;
&lt;p&gt;I am gutted! If this becomes public, we might lose larger parts of our
lists-related reputation.&lt;/p&gt;
&lt;p&gt;NP: &lt;a class=&quot;reference&quot; href=&quot;http://www.allmusic.com/cg/amg.dll?SQL=David%20Bowie&amp;amp;P=amg&amp;amp;OPT1=1&quot;&gt;David Bowie&lt;/a&gt;: &lt;em&gt;Station to Station&lt;/em&gt;&lt;/p&gt;
</content>
</entry>

<entry>
<title type="html">Packaging with Git
</title>
<category term="" />
<id>http://blog.madduck.net/2007/10/10/2007.10.03_packaging-with-git</id>
<updated>2007-10-10T19:46:22Z</updated>
<published>2007-10-10T19:46:22Z</published>
<link rel="alternate" type="text/html" href="http://blog.madduck.net/debian/2007.10.03_packaging-with-git" />
<content type="html">&lt;div class=&quot;section&quot;&gt;
&lt;h4&gt;&lt;a id=&quot;introduction&quot; name=&quot;introduction&quot;&gt;Introduction&lt;/a&gt;&lt;/h4&gt;
&lt;p&gt;I gave a &lt;a class=&quot;reference&quot; href=&quot;https://penta.debconf.org/~joerg/events/53.en.html&quot;&gt;joint presentation with Manoj&lt;/a&gt; at &lt;a class=&quot;reference&quot; href=&quot;http://debconf7.debconf.org&quot;&gt;Debconf7&lt;/a&gt; about using distributed version control for
Debian packaging, and I &lt;a class=&quot;reference&quot; href=&quot;http://wiki.debian.org/ContinuingDebianEducation#head-594a2b8eeff72a7b5b10cae59290b12ad6f3c6a1&quot;&gt;volunteered to do an on-line workshop&lt;/a&gt;
about using &lt;a class=&quot;reference&quot; href=&quot;http://git.or.cz/&quot;&gt;Git&lt;/a&gt; for the task, so it&apos;s about time that
I should know how to use Git for Debian packaging, but it turns out that
I don&apos;t. Or well, didn&apos;t.&lt;/p&gt;
&lt;p&gt;After I made a pretty good mess out of the &lt;a class=&quot;reference&quot; href=&quot;http://git.debian.org/?p=pkg-mdadm/mdadm.git;a=summary&quot;&gt;mdadm packaging repository&lt;/a&gt; (which is not a big
problem as it&apos;s just ugly history up to the point when I start to get it
right), I decided to get down with the topic and figure it out once and for
all. I am writing this post as I put the pieces together. It&apos;s been cooking
for a week, simply so I could gather enough feedback. I am aware that &lt;a class=&quot;reference&quot; href=&quot;http://fortytwo.ch/blog/archives/2007/10/#e2007-10-10T08_34_49.txt&quot;&gt;Git is
not exactly a showcase of usability&lt;/a&gt;, so
I took some extra care to not add to the confusion.&lt;/p&gt;
&lt;p&gt;It may be the first post in a series, because this time, I am just covering
the case of &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;mdadm&lt;/span&gt;&lt;/tt&gt;, for which upstream also uses Git and where I am the
only maintainer, and I shall pretend that I am importing &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;mdadm&lt;/span&gt;&lt;/tt&gt; to version
control for the first time, so there won&apos;t be any history juggling. Future
posts could well include tracking &lt;a class=&quot;reference&quot; href=&quot;http://subversion.tigris.org/&quot;&gt;Subversion&lt;/a&gt; repositories with &lt;a class=&quot;reference&quot; href=&quot;http://utsl.gen.nz/talks/git-svn/intro.html&quot;&gt;git-svn&lt;/a&gt;, and &lt;a class=&quot;reference&quot; href=&quot;http://blog.madduck.net/debian/2007.10.07_converting-a-package-to-git&quot;&gt;importing packages
previously tracked therewith&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;I realise that &lt;a class=&quot;reference&quot; href=&quot;http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.html&quot;&gt;git-buildpackage&lt;/a&gt; exists, but imposes a rather
strict branch layout and tagging scheme, which I don&apos;t want to adhere to. And
&lt;a class=&quot;reference&quot; href=&quot;http://packages.debian.org/gitpkg&quot;&gt;gitpkg&lt;/a&gt; (&lt;a class=&quot;reference&quot; href=&quot;http://blog.orebokech.com/2007/10/balance-is-but-shimmering-notion.html&quot;&gt;Romain blogged about it
recently&lt;/a&gt;),
&lt;strong&gt;deserves another look since, according to its author, it does not impose
anything on its user.&lt;/strong&gt; But in any case, before using such tools (and
possibly extending them to allow for other layouts), I&apos;d really rather have
done it by hand a couple of times to get the hang of it and find out where the
culprits lie.&lt;/p&gt;
&lt;p&gt;Now, enough of the talking, just one last thing: I expect this blog post to
change quite a bit as I get feedback. Changes shall be highlighted in &lt;strong&gt;bold
typeface&lt;/strong&gt;.&lt;/p&gt;
&lt;/div&gt;
&lt;div class=&quot;section&quot;&gt;
&lt;h4&gt;&lt;a id=&quot;setting-up-the-infrastructure&quot; name=&quot;setting-up-the-infrastructure&quot;&gt;Setting up the infrastructure&lt;/a&gt;&lt;/h4&gt;
&lt;p&gt;First, we prepare a shared repository on &lt;a class=&quot;reference&quot; href=&quot;http://git.debian.org&quot;&gt;git.debian.org&lt;/a&gt; for later use (using &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;collab-maint&lt;/span&gt;&lt;/tt&gt; for
illustration purposes), download the Debian source package we want to import
(version &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;2.6.3+200709292116+4450e59-3&lt;/span&gt;&lt;/tt&gt; at time of writing, but I pretend
it&apos;s &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;-2&lt;/span&gt;&lt;/tt&gt; because we shall create &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;-3&lt;/span&gt;&lt;/tt&gt; further down…), set up a local
repository, and link it to the remote repository. Note that there are &lt;a class=&quot;reference&quot; href=&quot;http://blog.madduck.net/vcs/2007.07.11_publishing-git-repositories&quot;&gt;other
ways to set up the infrastructure&lt;/a&gt;, but
this happens to be the one I prefer, even though it&apos;s slightly more
complicated:&lt;/p&gt;
&lt;pre class=&quot;literal-block&quot;&gt;
$ ssh alioth
$ cd /git/collab-maint
$ ./setup-repository pkg-mdadm mdadm Debian packaging
$ exit
$ apt-get source --download-only mdadm
$ mkdir mdadm &amp;amp;&amp;amp; cd mdadm
$ git init
$ git remote add origin ssh://git.debian.org/git/collab-maint/pkg-mdadm
$ git config branch.master.merge refs/heads/master
&lt;/pre&gt;
&lt;p&gt;Now we can use &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;git-pull&lt;/span&gt;&lt;/tt&gt; and &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;git-push&lt;/span&gt;&lt;/tt&gt;, except the remote repository is
empty and we can&apos;t pull from there yet. We&apos;ll save that for later.&lt;/p&gt;
&lt;p&gt;Instead, we tell the repository about upstream&apos;s Git repository. I am giving
you the &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;git.debian.org&lt;/span&gt;&lt;/tt&gt; URL though, simply because I don&apos;t want upstream
repository (which lives on an ADSL line) hammered in response to this blog
post:&lt;/p&gt;
&lt;pre class=&quot;literal-block&quot;&gt;
$ git remote add upstream-repo git://git.debian.org/git/pkg-mdadm/mdadm
&lt;/pre&gt;
&lt;p&gt;Since we&apos;re using the &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;upstream&lt;/span&gt;&lt;/tt&gt; branch of the &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;pkg-mdadm&lt;/span&gt;&lt;/tt&gt; repository as
source (and don&apos;t want all the other mess I created in that repository), we&apos;ll
first limit the set of branches to be fetched (I could have used the &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;-t&lt;/span&gt;&lt;/tt&gt;
option in the above &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;git-remote&lt;/span&gt;&lt;/tt&gt; command, but I prefer to make it explicit
that we&apos;re doing things slightly differently to protect upstream&apos;s ADSL line).&lt;/p&gt;
&lt;pre class=&quot;literal-block&quot;&gt;
$ git config remote.upstream-repo.fetch \
    +refs/heads/upstream:refs/remotes/upstream-repo/upstream
&lt;/pre&gt;
&lt;p&gt;And now we can pull down upstream&apos;s history and create a local branch off it.
The &amp;quot;no common commits&amp;quot; warning can be safely ignored since we don&apos;t have any
commits at all at that point (so there can&apos;t be any in common between the
local and remote repository), but we know what we&apos;re doing, even to the point
that we can forcefully give birth to a branch, which is because we do not have
a &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;HEAD&lt;/span&gt;&lt;/tt&gt; commit yet (our repository is still empty):&lt;/p&gt;
&lt;pre class=&quot;literal-block&quot;&gt;
$ git fetch upstream-repo
warning: no common commits
[…]
  # in the real world, we&apos;d be branching off upstream-repo/master
$ git checkout -b upstream upstream-repo/upstream
warning: You appear to be on a branch yet to be born.
warning: Forcing checkout of upstream-repo/upstream.
Branch upstream set up to track remote branch
  refs/remotes/upstream-repo/upstream.
$ git branch
* upstream
$ ls | wc -l
77
&lt;/pre&gt;
&lt;/div&gt;
&lt;div class=&quot;section&quot;&gt;
&lt;h4&gt;&lt;a id=&quot;importing-the-debian-package&quot; name=&quot;importing-the-debian-package&quot;&gt;Importing the Debian package&lt;/a&gt;&lt;/h4&gt;
&lt;p&gt;Now it&apos;s time to import Debian&apos;s &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;diff.gz&lt;/span&gt;&lt;/tt&gt; — remember how I pretend to use
version control for package maintenance for the first time. Oh, and sorry
about the messy file names, but I decided it&apos;s best to stick with real data in
case you are playing along:&lt;/p&gt;
&lt;p&gt;Since we&apos;re applying the diff against version &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;2.6.3+200709292116+4450e59&lt;/span&gt;&lt;/tt&gt;,
we ought to make sure to have the repository at the same state. Upstream never
&amp;quot;released&amp;quot; that version, but I encoded the commit ID of the tip when
I snapshotted it: &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;4450e59&lt;/span&gt;&lt;/tt&gt;, so we branch off there. Since we are actually
tracking the &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;git.debian.org&lt;/span&gt;&lt;/tt&gt; &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;pkg-mdadm&lt;/span&gt;&lt;/tt&gt; repository instead of upstream,
you can use the tag I made. Otherwise you could consider tagging yourself:&lt;/p&gt;
&lt;pre class=&quot;literal-block&quot;&gt;
$ #git tag -s mdadm-2.6.3+200709292116+4450e59 4450e59
$ git checkout -b master mdadm-2.6.3+200709292116+4450e59
$ zcat ../mdadm_2.6.3+200709292116+4450e59-2.diff.gz | git apply
&lt;/pre&gt;
&lt;p&gt;The local tree is now &amp;quot;debianised&amp;quot;, but Git does not know about the new and
changed files, which you can verify with &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;git-status&lt;/span&gt;&lt;/tt&gt;. We will split the
changes made by Debian&apos;s &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;diff.gz&lt;/span&gt;&lt;/tt&gt; across several branches.&lt;/p&gt;
&lt;/div&gt;
&lt;div class=&quot;section&quot;&gt;
&lt;h4&gt;&lt;a id=&quot;the-idea-of-feature-branches&quot; name=&quot;the-idea-of-feature-branches&quot;&gt;The idea of feature branches&lt;/a&gt;&lt;/h4&gt;
&lt;p&gt;We could just create a &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;debian&lt;/span&gt;&lt;/tt&gt; branch, commit all changes made by the
&lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;diff.gz&lt;/span&gt;&lt;/tt&gt; there, and be done with it. However, we might want to keep certain
aspects of Debianisation separate, and the way to do that is with feature
branches (also known as &amp;quot;topic&amp;quot; branches). For the sake of this demonstration,
let&apos;s create the following four branches in addition to the &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;master&lt;/span&gt;&lt;/tt&gt; branch,
which holds the standard Debian files, such as &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;debian/changelog&lt;/span&gt;&lt;/tt&gt;,
&lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;debian/control&lt;/span&gt;&lt;/tt&gt;, and &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;debian/rules&lt;/span&gt;&lt;/tt&gt;:&lt;/p&gt;
&lt;ul class=&quot;simple&quot;&gt;
&lt;li&gt;&lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;upstream-patches&lt;/span&gt;&lt;/tt&gt; will includes patches against the upstream code, which
I submit for upstream inclusion.&lt;/li&gt;
&lt;li&gt;&lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;deb/conffile-location&lt;/span&gt;&lt;/tt&gt; makes &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;/etc/mdadm/mdadm.conf&lt;/span&gt;&lt;/tt&gt; the default over
&lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;/etc/mdadm.conf&lt;/span&gt;&lt;/tt&gt; and is Debian-specific (thus the &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;deb/&lt;/span&gt;&lt;/tt&gt; prefix).&lt;/li&gt;
&lt;li&gt;&lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;deb/initramfs&lt;/span&gt;&lt;/tt&gt; includes the &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;initramfs&lt;/span&gt;&lt;/tt&gt; hook and script, which I want
to treat separately but not submit upstream.&lt;/li&gt;
&lt;li&gt;&lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;deb/docs&lt;/span&gt;&lt;/tt&gt; similarly includes Debian-only documentation I add to the
package as a service to Debian users.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;If you&apos;re importing a Debian package using &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;dpatch&lt;/span&gt;&lt;/tt&gt;, you might want to
convert every dpatch into a single branch, or at least collect logical units
into separate branches. Up to you. For now, our simple example suffices. Keep
in mind that it&apos;s easy to merge two branch and less trivial to split one into
two.&lt;/p&gt;
&lt;p&gt;Why? Well, good question. As you will see further down, the separation between
&lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;master&lt;/span&gt;&lt;/tt&gt; and &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;deb/initramfs&lt;/span&gt;&lt;/tt&gt; actually makes things more complicated when
you are working on an issue spanning across both. However, feature branches
also bring a whole lot of flexibility. For instance, with the above
separation, I could easily create &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;mdadm&lt;/span&gt;&lt;/tt&gt; packages without &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;initramfs&lt;/span&gt;&lt;/tt&gt;
integration (see &lt;a class=&quot;reference&quot; href=&quot;http://bugs.debian.org/434934&quot;&gt;#434934&lt;/a&gt;),
a disk-space-conscious distribution like &lt;a class=&quot;reference&quot; href=&quot;http://grml.org&quot;&gt;grml&lt;/a&gt; might
prefer to leave out the extra documentation, and maybe another derivative
doesn&apos;t like the fact that the configuration file is in a different place from
upstream. With feature branches, all these issues could be easily addressed by
leaving out unwanted branches from the merge into the integration/build branch
(see further down).&lt;/p&gt;
&lt;p&gt;Whether you use feature branches, and how many, or whether you&apos;d like to only
separate upstream and Debian stuff is entirely up to you. For the purpose of
demonstration, I&apos;ll go the more complicated way.&lt;/p&gt;
&lt;/div&gt;
&lt;div class=&quot;section&quot;&gt;
&lt;h4&gt;&lt;a id=&quot;setting-up-feature-branches&quot; name=&quot;setting-up-feature-branches&quot;&gt;Setting up feature branches&lt;/a&gt;&lt;/h4&gt;
&lt;p&gt;So let&apos;s commit the individual files to the branches. The output of the
&lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;git-checkout&lt;/span&gt;&lt;/tt&gt; command shows modified files that have not been committed yet
(which I trim after the first example); Git keeps these across
checkouts/branch changes. Note that the &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;./debian/&lt;/span&gt;&lt;/tt&gt; directory does not show
up as Git does not know about it yet (&lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;git-status&lt;/span&gt;&lt;/tt&gt; will tell you that it&apos;s
untracked, or rather: contains untracked files since Git does not track
directories at all):&lt;/p&gt;
&lt;pre class=&quot;literal-block&quot;&gt;
$ git checkout -b upstream-patches mdadm-2.6.3+200709292116+4450e59
M Makefile
M ReadMe.c
M mdadm.8
M mdadm.conf.5
M mdassemble.8
M super1.c
$ git add super1.c     #444682
$ git commit -s

  # i now branch off master, but that&apos;s the same as 4450e59 actually
  # i just do it so i can make this point…
$ git checkout -b deb/conffile-location master
$ git add Makefile ReadMe.c mdadm.8 mdadm.conf.5 mdassemble.8
$ git commit -s

$ git checkout -b deb/initramfs master
$ git add debian/initramfs/*
$ git commit -s

$ git checkout -b deb/docs master
$ git add RAID5_versus_RAID10.txt md.txt rootraiddoc.97.html
$ git commit -s

  # and finally, the ./debian/ directory:
$ git checkout master
$ chmod +x debian/rules
$ git add debian
$ git commit -s

$ git branch
  deb/conffile-location
  deb/docs
* master
  upstream
  upstream-patches
&lt;/pre&gt;
&lt;p&gt;At this time, we push our work so it won&apos;t get lost if, at this moment, aliens
land on the house, or any other completely plausible event of apocalypse
descends upon you. We&apos;ll push our work to &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;git.debian.org&lt;/span&gt;&lt;/tt&gt; (the &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;origin&lt;/span&gt;&lt;/tt&gt;,
which is the default destination and thus needs not be specified) by using
&lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;git-push&lt;/span&gt; &lt;span class=&quot;pre&quot;&gt;--all&lt;/span&gt;&lt;/tt&gt;, which conveniently pushes all local branches, thus
including the upstream code; you may not want to push the upstream code, but
I prefer it since it makes it easier to work with the repository, and since
most of the objects are needed for the other branches anyway — after all, we
branched off the &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;upstream&lt;/span&gt;&lt;/tt&gt; branch.&lt;/p&gt;
&lt;p&gt;Specifying &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;--tags&lt;/span&gt;&lt;/tt&gt; instead of &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;--all&lt;/span&gt;&lt;/tt&gt; pushes tags instead of heads
(branches); you couldn&apos;t have guessed that! See &lt;a class=&quot;reference&quot; href=&quot;http://marc.info/?t=119168682300005&amp;amp;r=1&amp;amp;w=2&quot;&gt;this thread&lt;/a&gt; if you (rightfully) think
that one should be able to do this in a single command (which is not &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;git&lt;/span&gt;
&lt;span class=&quot;pre&quot;&gt;push&lt;/span&gt; &lt;span class=&quot;pre&quot;&gt;refs/heads/*&lt;/span&gt; &lt;span class=&quot;pre&quot;&gt;refs/tags/*&lt;/span&gt;&lt;/tt&gt;)…&lt;/p&gt;
&lt;pre class=&quot;literal-block&quot;&gt;
$ git push --all
$ git push --tags
&lt;/pre&gt;
&lt;p&gt;Done. Well, almost…&lt;/p&gt;
&lt;/div&gt;
&lt;div class=&quot;section&quot;&gt;
&lt;h4&gt;&lt;a id=&quot;building-the-package-theory&quot; name=&quot;building-the-package-theory&quot;&gt;Building the package (theory)&lt;/a&gt;&lt;/h4&gt;
&lt;p&gt;Let&apos;s build the package. There seem to be two (sensible) ways we could do
this, considering that we have to integrate (merge) the branches we just
created, before we fire off the building scripts:&lt;/p&gt;
&lt;ol class=&quot;arabic simple&quot;&gt;
&lt;li&gt;by using a temporary (or &amp;quot;throw-away&amp;quot;) branch off &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;upstream&lt;/span&gt;&lt;/tt&gt;, where we
integrate all the branches we have just created, build the package, tag our
&lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;master&lt;/span&gt;&lt;/tt&gt; branch (it contains &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;debian/changelog&lt;/span&gt;&lt;/tt&gt;), and remove the
temporary branch. When a new package needs to be built, we repeat the
process.&lt;/li&gt;
&lt;li&gt;by using a long-living integration branch off &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;upstream&lt;/span&gt;&lt;/tt&gt;, into which we
merge all our branches, tag the branch, and build the package off the tag.
When a new package comes around, we re-merge our branches, tag, and build.&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;Both approaches have a certain appeal to me, but I settled for the second, for
two reasons, the first of which leads to the second:&lt;/p&gt;
&lt;ol class=&quot;arabic simple&quot;&gt;
&lt;li&gt;When I upload a package to the Debian archive, I want to create a tag which
captures the exact state of the tree from which the package was built, for
posterity (I will return to this point later). Since the throw-away
branches are not designed to persist and are not uploaded to the archive,
tagging the merging commit makes no sense. Thus, the only way to properly
identify a source tree across all involved branches would be to run
&lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;git-tag&lt;/span&gt; &lt;span class=&quot;pre&quot;&gt;$branch/$tagname&lt;/span&gt; &lt;span class=&quot;pre&quot;&gt;$branch&lt;/span&gt;&lt;/tt&gt; for each branch, which is purely
semantic and will get messy sooner or later.&lt;/li&gt;
&lt;li&gt;As a result of the above: when Debian makes a new stable release, I would
like to create a branch corresponding to the package in the stable archive
at the time, for security and other proposed updates. I could rename my
throw-away branch, if it still existed, or I could create a new branch and
merge all other branches, using the (semantic) tags, but that seems rather
unfavourable.&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;So instead, I use a long-living integration branch, notoriously tag the merge
commits which produced the tree from which I built the package I uploaded, and
when a certain version ends up in a stable Debian release, I create
a maintenance branch off the one, single tag which corresponds to the very
version of the package distributed as part of the Debian release.&lt;/p&gt;
&lt;p&gt;So much for the theory. Let&apos;s build, already!&lt;/p&gt;
&lt;/div&gt;
&lt;div class=&quot;section&quot;&gt;
&lt;h4&gt;&lt;a id=&quot;building-the-package-practise&quot; name=&quot;building-the-package-practise&quot;&gt;Building the package (practise)&lt;/a&gt;&lt;/h4&gt;
&lt;p&gt;So we need a long-living integration branch, and that&apos;s easier done than
said:&lt;/p&gt;
&lt;pre class=&quot;literal-block&quot;&gt;
$ git checkout -b build mdadm-2.6.3+200709292116+4450e59
&lt;/pre&gt;
&lt;p&gt;Now we&apos;re ready to build, and the following procedure should really be
automated. I thus write it like a script, called &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;poor-mans-gitbuild&lt;/span&gt;&lt;/tt&gt;, which
takes as optional argument the name of the (upstream) tag to use, defaulting
to &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;upstream&lt;/span&gt;&lt;/tt&gt; (the tip):&lt;/p&gt;
&lt;pre class=&quot;literal-block&quot;&gt;
#!/bin/sh
set -eu
git checkout master
debver=$(dpkg-parsechangelog | sed -ne &apos;s,Version: ,,p&apos;)
git checkout build
git merge ${1:-upstream}
git merge upstream-patches
git merge master
for b in $(git for-each-ref --format=&apos;%(refname)&apos; refs/heads/deb/*); do
  git merge -- $b
done
git tag -s debian/$debver
debuild -i.git
git checkout master
&lt;/pre&gt;
&lt;p&gt;&lt;strong&gt;Kumar Appaiah spotted&lt;/strong&gt; that &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;-i.git&lt;/span&gt;&lt;/tt&gt; is actually needed in the
&lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;debuild&lt;/span&gt;&lt;/tt&gt; call to make it exclude the &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;.git&lt;/span&gt;&lt;/tt&gt; directory from the generated
&lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;diff.gz&lt;/span&gt;&lt;/tt&gt;.&lt;/p&gt;
&lt;p&gt;Note how we are merging each branch in turn, instead of using the octopus
merge strategy (which would create a commit with more than two parents) for
reasons outlined &lt;a class=&quot;reference&quot; href=&quot;http://lists.madduck.net/pipermail/vcs-pkg/2007-October/000028.html&quot;&gt;in this post&lt;/a&gt;.
An octopus-merge &lt;em&gt;would actually&lt;/em&gt; work in our situation, but it will not
always work, so better safe than sorry (although you &lt;em&gt;could&lt;/em&gt; still &lt;a class=&quot;reference&quot; href=&quot;http://lists.madduck.net/pipermail/vcs-pkg/2007-October/000029.html&quot;&gt;achieve
the same result&lt;/a&gt;).&lt;/p&gt;
&lt;p&gt;If you discover during the build that you forgot something, or the build
script failed to run, just remove the tag, undo the merges, checkout the
branch to which you need to commit to fix the issue, and then repeat the above
build process:&lt;/p&gt;
&lt;pre class=&quot;literal-block&quot;&gt;
$ git tag -d debian/$debver
$ git checkout build
$ git reset --hard upstream
$ git checkout master
$ editor debian/rules    # or whatever
$ git add debian/rules
$ git commit -s

$ poor-mans-gitbuild
&lt;/pre&gt;
&lt;p&gt;Before you upload, it&apos;s a good idea to invoke &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;gitk&lt;/span&gt; &lt;span class=&quot;pre&quot;&gt;--all&lt;/span&gt;&lt;/tt&gt; and verify that
all goes according to plan:&lt;/p&gt;
&lt;div class=&quot;centre container&quot;&gt;
&lt;img alt=&quot;screenshot of gitk after the above steps&quot; src=&quot;http://blog.madduck.net/static/mdadm-git-demo-gitk.png&quot; style=&quot;width: 520px; height: 143px;&quot; /&gt;
&lt;/div&gt;
&lt;p&gt;When you&apos;re done and the package has been uploaded, push your work to
&lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;git.debian.org&lt;/span&gt;&lt;/tt&gt;, as before. Instead of using &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;--all&lt;/span&gt;&lt;/tt&gt; and &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;--tags&lt;/span&gt;&lt;/tt&gt;,
I now specify exactly which refs to push. This is probably a good habit to get
into to prevent publishing unwanted refs:&lt;/p&gt;
&lt;pre class=&quot;literal-block&quot;&gt;
$ git push origin build tag debian/2.6.3+200709292116+4450e59-3
&lt;/pre&gt;
&lt;p&gt;Now take your dog for a walk, or play outside, or do something else not
involving a computer or entertainment device.&lt;/p&gt;
&lt;/div&gt;
&lt;div class=&quot;section&quot;&gt;
&lt;h4&gt;&lt;a id=&quot;uploading-a-new-debian-version&quot; name=&quot;uploading-a-new-debian-version&quot;&gt;Uploading a new Debian version&lt;/a&gt;&lt;/h4&gt;
&lt;p&gt;If you are as lucky as I am, the package you uploaded still has a bug in the
upstream code &lt;em&gt;and&lt;/em&gt; someone else fixes it before upstream releases a new
version, then you might be in the position to release a new Debian version. Or
maybe you just need to make some Debian-specific changes against the same
upstream version. I&apos;ll let the commands speak for themselves:&lt;/p&gt;
&lt;pre class=&quot;literal-block&quot;&gt;
$ git checkout upstream-patches
$ git-apply &amp;lt; patch-from-lunar.diff   #444682 again
$ git commit --author &apos;Jérémy Bobbio &amp;lt;lunar&amp;#64;debian.org&amp;gt;&apos; -s

  # this should also be automated, see below
$ git checkout master
$ dch -i
$ dpkg-parsechangelog | sed -ne &apos;s,Version: ,,p&apos;
2.6.3+200709292116+4450e59-3
$ git commit -s debian/changelog

$ poor-mans-gitbuild

$ git push
$ git push origin tag debian/2.6.3+200709292116+4450e59-3
&lt;/pre&gt;
&lt;p&gt;That first &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;git-push&lt;/span&gt;&lt;/tt&gt; may require a short explanation: without any
arguments, &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;git-push&lt;/span&gt;&lt;/tt&gt; updates only the intersection of local and remote
branches, so it would never push a new local branch (such as &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;build&lt;/span&gt;&lt;/tt&gt; above),
but it updates all existing ones; thus, you cannot inadvertedly publish
a local branch. Tags still need to be published explicitly.&lt;/p&gt;
&lt;/div&gt;
&lt;div class=&quot;section&quot;&gt;
&lt;h4&gt;&lt;a id=&quot;hacking-on-the-software&quot; name=&quot;hacking-on-the-software&quot;&gt;Hacking on the software&lt;/a&gt;&lt;/h4&gt;
&lt;p&gt;Imagine: on a rainy Saturday afternoon you get bored and decide to implement
a better way to tell &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;mdadm&lt;/span&gt;&lt;/tt&gt; &lt;a class=&quot;reference&quot; href=&quot;http://bugs.debian.org/398310&quot;&gt;when to start which array&lt;/a&gt;. Since you&apos;re a genius, it&apos;ll take you only
a day, but you do make mistakes here and there, so what could be better than
to use version control? However, rather than having a branch that will live
forever, you are just creating a local branch, which you will not publish.
When you are done, you&apos;ll feed your work back into the existing branches.&lt;/p&gt;
&lt;p&gt;Git makes branching really easy and as you may have spotted, the
&lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;poor-mans-gitbuild&lt;/span&gt;&lt;/tt&gt; script reserves an entire branch namespace for people
like you:&lt;/p&gt;
&lt;pre class=&quot;literal-block&quot;&gt;
$ git checkout -b tmp/start-arrays-rework master
&lt;/pre&gt;
&lt;p&gt;Unfortunately (or fortunately), fixing this issue will require work on two
branches, since the &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;initramfs&lt;/span&gt;&lt;/tt&gt; script and hook are maintained in a separate
branch. There are (again) two ways in which we can (sensibly) approach this:&lt;/p&gt;
&lt;ul class=&quot;simple&quot;&gt;
&lt;li&gt;create two separate, temporary branches, and switch between them as you
work.&lt;/li&gt;
&lt;li&gt;merge both into the temporary branch and later cherry-pick the commits into
the appropriate branches.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;I am undecided on this, but maybe the best would be a combination: merge both
into a temporary branch and later cherry-pick the commits into two additional,
temporary branches until you got it right, and then fast-forward the official
branches to their tips:&lt;/p&gt;
&lt;pre class=&quot;literal-block&quot;&gt;
$ git merge master deb/initramfs
$ editor debian/mdadm-raid                     # …
$ git commit -s debian/mdadm-raid
$ editor debian/initramfs/script.local-top     # …
$ git commit -s debian/initramfs/script.local-top
[many hours of iteration pass…]

[… until you are done]
$ git checkout -b tmp/start-arrays-rework-init master
  # for each commit $c in tmp/start-arrays-rework
  # applicable to the master branch:
$ git cherry-pick $c
$ git checkout -b tmp/start-arrays-rework-initramfs deb/initramfs
  # for each commit $c in tmp/start-arrays-rework
  # applicable to the deb/initramfs branch:
$ git cherry-pick $c
&lt;/pre&gt;
&lt;p&gt;This is assuming that all your commits are logical units. If you find several
commits which would better be bundled together into a single commit, this is
the time to do it:&lt;/p&gt;
&lt;pre class=&quot;literal-block&quot;&gt;
$ git cherry-pick --no-commit &amp;lt;commit7&amp;gt;
$ git cherry-pick --no-commit &amp;lt;commit4&amp;gt;
$ git cherry-pick --no-commit &amp;lt;commit5&amp;gt;
$ git commit -s
&lt;/pre&gt;
&lt;p&gt;Before we now merge this into the official branches, let me briefly intervene
and introduce the concept of a fast-forward. Git will &amp;quot;fast-forward&amp;quot; a branch
to a new tip if it decides that no merge is needed. In the above example, we
branched a temporary branch (T) off the tip of an official branch (O) and then
worked on the temporary one. If we now merge the temporary one into the
official one, Git determines that it can actually squash the ancestry into
a single line and push the official branch tip to the same ref as the
temporary branch tip. In cheap (poor man&apos;s), ASCII notation:&lt;/p&gt;
&lt;pre class=&quot;literal-block&quot;&gt;
- - - O             &amp;gt;&amp;gt; merge T &amp;gt;&amp;gt;     - - - = - - OT
       ` - - T      &amp;gt;&amp;gt;  into O &amp;gt;&amp;gt;
&lt;/pre&gt;
&lt;p&gt;This works because no new commits have been made on top of O (if there would
be any, we might be able to rebase, but let&apos;s not go there quite yet; rebasing
is how you shoot yourself in the foot with Git). Thus we can simply do the
following:&lt;/p&gt;
&lt;pre class=&quot;literal-block&quot;&gt;
$ git checkout deb/initramfs
$ git merge tmp/start-arrays-rework-initramfs
$ git checkout master
$ git merge tmp/start-arrays-rework-init
&lt;/pre&gt;
&lt;p&gt;and test/build/push the result. Or well, since you are not an &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;mdadm&lt;/span&gt;&lt;/tt&gt;
maintainer (We^W I have open job positions! Applications welcome!), you&apos;ll
want to submit your work as patches via email:&lt;/p&gt;
&lt;pre class=&quot;literal-block&quot;&gt;
$ git format-patch -s -M origin/master
&lt;/pre&gt;
&lt;p&gt;This will create a number of files in the current directory, one corresponding
for each commit you made since &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;origin/master&lt;/span&gt;&lt;/tt&gt;. Assuming each commit is
a logical unit, you can now submit these to an email address. The
&lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;--compose&lt;/span&gt;&lt;/tt&gt; option lets you write an introductory message, which is
optional:&lt;/p&gt;
&lt;pre class=&quot;literal-block&quot;&gt;
$ git send-email --compose --to your&amp;#64;email.address &amp;lt;file1&amp;gt; &amp;lt;file2&amp;gt; &amp;lt;…&amp;gt;
&lt;/pre&gt;
&lt;p&gt;Once you&apos;ve verified that everything is alright, swap your email address for
the bug number (or the &lt;a class=&quot;reference&quot; href=&quot;http://lists.alioth.debian.org/mailman/listinfo/pkg-mdadm-devel&quot;&gt;pkg-mdadm-devel list&lt;/a&gt; address).&lt;/p&gt;
&lt;p&gt;Thanks (in advance) for your contribution!&lt;/p&gt;
&lt;p&gt;Of course, you may also be working on a feature that you want to go upstream,
in which case you&apos;d probably branch off &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;upstream-patches&lt;/span&gt;&lt;/tt&gt; (if it depends on
a patch not yet in upstream&apos;s repository), or &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;upstream&lt;/span&gt;&lt;/tt&gt; (if it does not):&lt;/p&gt;
&lt;pre class=&quot;literal-block&quot;&gt;
$ git checkout -b tmp/cool-feature upstream
[…]
&lt;/pre&gt;
&lt;/div&gt;
&lt;div class=&quot;section&quot;&gt;
&lt;h4&gt;&lt;a id=&quot;when-a-new-upstream-version-comes-around&quot; name=&quot;when-a-new-upstream-version-comes-around&quot;&gt;… when a new upstream version comes around&lt;/a&gt;&lt;/h4&gt;
&lt;p&gt;After a while, upstream may have integrated your patches, in addition to
various other changes, to give birth to &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;mdadm-2.6.4&lt;/span&gt;&lt;/tt&gt;. We thus first fetch
all the new refs and merge them into our upstream branch:&lt;/p&gt;
&lt;pre class=&quot;literal-block&quot;&gt;
$ git fetch upstream-repo
$ git checkout upstream
$ git merge upstream-repo/master
&lt;/pre&gt;
&lt;p&gt;we &lt;em&gt;could&lt;/em&gt; just as well have executed &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;git-pull&lt;/span&gt;&lt;/tt&gt;, which with the default
configuration would have done the same; however, I prefer to separate the
process into fetching and merging.&lt;/p&gt;
&lt;p&gt;Now comes the point when many Git people think about rebasing. And in fact,
rebasing is exactly what you should be doing, iff you&apos;re still working on an
&lt;em&gt;unpublished&lt;/em&gt; branch, such as the previous &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;tmp/cool-feature&lt;/span&gt;&lt;/tt&gt; off
&lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;upstream&lt;/span&gt;&lt;/tt&gt;. By rebasing your branch onto the updated &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;upstream&lt;/span&gt;&lt;/tt&gt; branch,
you are making sure that your patch will apply cleanly when upstream tries it,
because potential merge conflicts would be handled by you as part of the
rebase, rather than by upstream:&lt;/p&gt;
&lt;pre class=&quot;literal-block&quot;&gt;
$ git checkout tmp/cool-feature
$ git rebase upstream
&lt;/pre&gt;
&lt;p&gt;What rebasing does is quite simple actually: it takes every commit you made
since you branched off the parent branch and records the diff and commit
message. Then, for each diff/commit_message pair, it &lt;em&gt;creates a new commit&lt;/em&gt; on
top of the new parent branch tip, thus rewrites history, and orphans all your
original commits. Thus, you should only do this if your branch has never been
published or else you would leave people who cloned from your published branch
with orphans.&lt;/p&gt;
&lt;blockquote&gt;
If this still does not make sense, try it out: create a (source) repository,
make a commit (with a meaningful commit message), branch B off the tip, make
a commit on top of B (with a meaningful message), clone that repository and
return to the source repository. There, checkout the master, make a commit
(with a …), checkout B, rebase it onto the tip of master, make a commit
(with a …), and now &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;git-pull&lt;/span&gt;&lt;/tt&gt; from the clone; use &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;gitk&lt;/span&gt;&lt;/tt&gt; to figure out
what&apos;s going on.&lt;/blockquote&gt;
&lt;p&gt;So you should almost never rebase a published branch, and since all your
branches outside of the &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;tmp/*&lt;/span&gt;&lt;/tt&gt; namespace are published on
&lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;git.debian.org&lt;/span&gt;&lt;/tt&gt;, you should not rebase those.&lt;/p&gt;
&lt;p&gt;But then again, Pierre actually &lt;a class=&quot;reference&quot; href=&quot;http://lists.madduck.net/pipermail/vcs-pkg/2007-October/000021.html&quot;&gt;rebases a published branch in his workflow&lt;/a&gt;, and
he does so with reason: his &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;patches&lt;/span&gt;&lt;/tt&gt; branch is just a collection of
branches to go upstream, from which upstream cherry-picks or which upstream
merges, but which no one tracks (or should be tracking).&lt;/p&gt;
&lt;p&gt;But we can&apos;t (or at least will not at this point) do this for our feature
branches (though we could treat &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;upstream-patches&lt;/span&gt;&lt;/tt&gt; that way), so we have to
merge. At first, it suffices to merge the new &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;upstream&lt;/span&gt;&lt;/tt&gt; into the
long-living &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;build&lt;/span&gt;&lt;/tt&gt; branch, and to call &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;poor-mans-gitbuild&lt;/span&gt;&lt;/tt&gt;, but if you
run into merge conflicts or find that upstream&apos;s changes affect the
functionality contained in your feature branches, you need to actually fix
those.&lt;/p&gt;
&lt;p&gt;For instance, let&apos;s say that upstream started providing &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;md.txt&lt;/span&gt;&lt;/tt&gt; (which
I previously provided in the &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;deb/docs&lt;/span&gt;&lt;/tt&gt; branch), then I need to fix that
branch:&lt;/p&gt;
&lt;pre class=&quot;literal-block&quot;&gt;
$ git checkout deb/docs
$ git rm md.txt
$ git commit -s
&lt;/pre&gt;
&lt;p&gt;That was easy, since I could evade the conflict. But what if upstream made
a change to &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;Makefile&lt;/span&gt;&lt;/tt&gt;, which got in the way with my configuration file
location change? Then I&apos;d have to merge &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;upstream&lt;/span&gt;&lt;/tt&gt; into
&lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;deb/conffile-location&lt;/span&gt;&lt;/tt&gt;, resolve the conflicts, and commit the change:&lt;/p&gt;
&lt;pre class=&quot;literal-block&quot;&gt;
$ git checkout deb/conffile-location
$ git merge upstream
CONFLICT!
$ git-mergetool
$ git commit -s
&lt;/pre&gt;
&lt;p&gt;When all conflicts have been resolved, I can prepare a new release, as
before:&lt;/p&gt;
&lt;pre class=&quot;literal-block&quot;&gt;
$ git checkout master
$ dch -i
$ dpkg-parsechangelog | sed -ne &apos;s,Version: ,,p&apos;
2.6.3+200709292116+4450e59-3
# git commit -s debian/changelog

$ poor-mans-gitbuild

# git push
$ git push origin tag debian/2.6.3+200709292116+4450e59-3
&lt;/pre&gt;
&lt;p&gt;Note that Git often appears smart about commits that percolated upstream:
since upstream included the two commits in &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;upstream-patches&lt;/span&gt;&lt;/tt&gt; in his
&lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;2.6.4&lt;/span&gt;&lt;/tt&gt; release, my &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;upstream-patches&lt;/span&gt;&lt;/tt&gt; branch got effectively annihilated,
and Git was smart enough to figure that out &lt;em&gt;without&lt;/em&gt; a conflict. But before
you rejoice, let it be told that &lt;a class=&quot;reference&quot; href=&quot;http://marc.info/?t=119198137100002&amp;amp;r=1&amp;amp;w=2&quot;&gt;this does not always work&lt;/a&gt;.&lt;/p&gt;
&lt;/div&gt;
&lt;div class=&quot;section&quot;&gt;
&lt;h4&gt;&lt;a id=&quot;creating-and-using-a-maintenance-branch&quot; name=&quot;creating-and-using-a-maintenance-branch&quot;&gt;Creating and using a maintenance branch&lt;/a&gt;&lt;/h4&gt;
&lt;p&gt;Let&apos;s say Debian &amp;quot;lenny&amp;quot; is released with &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;mdadm&lt;/span&gt;&lt;/tt&gt; &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;2.7.6-1&lt;/span&gt;&lt;/tt&gt;, then:&lt;/p&gt;
&lt;pre class=&quot;literal-block&quot;&gt;
$ git checkout -b maint/lenny debian/2.7.6-1
&lt;/pre&gt;
&lt;p&gt;You might do this to celebrate the release, or you may wait until the need
arises. We&apos;ve already left the domain of reality (&amp;quot;lenny&amp;quot; is not yet
released), so the following is just theory.&lt;/p&gt;
&lt;p&gt;Now, assume that a security bug is found in &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;mdadm&lt;/span&gt;&lt;/tt&gt; &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;2.7.6&lt;/span&gt;&lt;/tt&gt; after &amp;quot;lenny&amp;quot;
was released. Upstream is already on &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;mdadm&lt;/span&gt;&lt;/tt&gt; &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;2.7.8&lt;/span&gt;&lt;/tt&gt; and commits
&lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;deadbeef&lt;/span&gt;&lt;/tt&gt; and &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;c0ffee&lt;/span&gt;&lt;/tt&gt; fix the security issue, then you&apos;d cherry-pick
them into the &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;maint/lenny&lt;/span&gt;&lt;/tt&gt; branch:&lt;/p&gt;
&lt;pre class=&quot;literal-block&quot;&gt;
$ git checkout upstream
$ git pull
$ git checkout maint/lenny
$ git cherry-pick deadbeef
$ git cherry-pick c0ffee
&lt;/pre&gt;
&lt;p&gt;If there are no merge conflicts (which you&apos;d resolve with &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;git-mergetool&lt;/span&gt;&lt;/tt&gt;),
we can just go ahead to prepare the new package:&lt;/p&gt;
&lt;pre class=&quot;literal-block&quot;&gt;
$ dch -i
$ dpkg-parsechangelog | sed -ne &apos;s,Version: ,,p&apos;
2.7.6-1lenny1
$ git commit -s debian/changelog

$ poor-mans-gitbuild

$ git push origin maint/lenny
$ git push origin tag debian/2.7.6-1lenny1
&lt;/pre&gt;
&lt;/div&gt;
&lt;div class=&quot;section&quot;&gt;
&lt;h4&gt;&lt;a id=&quot;future-directions&quot; name=&quot;future-directions&quot;&gt;Future directions&lt;/a&gt;&lt;/h4&gt;
&lt;p&gt;It should be trivial to create the Debian source package directly from the
repository, and in fact, in response to a recent blog post of mine on &lt;a class=&quot;reference&quot; href=&quot;http://blog.madduck.net/debian/2007.10.01_pristine-tarballs-and-vcs&quot;&gt;the
dispensability of pristine upstream tarballs&lt;/a&gt;, two
people showed me their scripts to do it.&lt;/p&gt;
&lt;p&gt;My post also caused &lt;a class=&quot;reference&quot; href=&quot;http://kitenet.net/~joey/blog/entry/pristine-tar_followup/&quot;&gt;Joey Hess to clarify his position on pristine tarballs&lt;/a&gt;, before he went
out to implement &lt;a class=&quot;reference&quot; href=&quot;http://kitenet.net/~joey/blog/entry/an_evolutionary_change_to_the_Debian_source_package_format/&quot;&gt;dpkg-source v3&lt;/a&gt;.
This looks very promising.&lt;/p&gt;
&lt;p&gt;Yet, as &lt;a class=&quot;reference&quot; href=&quot;http://lists.madduck.net/pipermail/vcs-pkg/2007-October/000032.html&quot;&gt;Romain argues&lt;/a&gt;, there
are benefits with simple patch management systems. Exciting times ahead!&lt;/p&gt;
&lt;p&gt;In addition to creating source packages from version control, a couple of
other ideas have been around for a while:&lt;/p&gt;
&lt;ul class=&quot;simple&quot;&gt;
&lt;li&gt;create &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;debian/changelog&lt;/span&gt;&lt;/tt&gt; from commit log summaries when you merge into
the &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;build&lt;/span&gt;&lt;/tt&gt; branch. &lt;strong&gt;Guido&apos;s&lt;/strong&gt; &lt;a class=&quot;reference&quot; href=&quot;http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.man.git.dch.html&quot;&gt;git-dch&lt;/a&gt;
&lt;strong&gt;might be a lead.&lt;/strong&gt;&lt;/li&gt;
&lt;li&gt;integrate version control with the BTS, bidirectionally:&lt;ul&gt;
&lt;li&gt;given a bug report, create a temporary branch and apply any patches found
in the bug report.&lt;/li&gt;
&lt;li&gt;upon merging the temporary branch back into the feature branch it
modifies, generate a patch, send it to the BTS and tag the bug report
&lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;+&lt;/span&gt; &lt;span class=&quot;pre&quot;&gt;pending&lt;/span&gt; &lt;span class=&quot;pre&quot;&gt;patch&lt;/span&gt;&lt;/tt&gt;.&lt;/li&gt;
&lt;/ul&gt;
&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;And I am sure there are more. If you have any, I&apos;d be interested to hear about
them!&lt;/p&gt;
&lt;/div&gt;
&lt;div class=&quot;section&quot;&gt;
&lt;h4&gt;&lt;a id=&quot;wrapping-up&quot; name=&quot;wrapping-up&quot;&gt;Wrapping up&lt;/a&gt;&lt;/h4&gt;
&lt;p&gt;I hope this post was useful. Thank you for reading to the end, this was
probably my longest blog post ever.&lt;/p&gt;
&lt;p&gt;I want to thank Pierre Habouzit, Johannes Schindelin, and all the others on
the &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;#git/freenode&lt;/span&gt;&lt;/tt&gt; IRC channel for their tutelage. Thanks also to Manoj
Srivastava, whose &lt;a class=&quot;reference&quot; href=&quot;http://arch.debian.org/arch/private/srivasta/&quot;&gt;pioneering work on packaging with GNU arch&lt;/a&gt; got me started on most of
the concepts I use in the above. And of course, the members of the &lt;a class=&quot;reference&quot; href=&quot;http://lists.madduck.net/listinfo/vcs-pkg&quot;&gt;the
vcs-pkg mailing list&lt;/a&gt; for the
various discussions on this subject, especially those who participated in &lt;a class=&quot;reference&quot; href=&quot;http://lists.madduck.net/pipermail/vcs-pkg/2007-October/000019.html&quot;&gt;the
thread leading up to this post&lt;/a&gt;.
Finally, thanks to Linus and Junio for &lt;a class=&quot;reference&quot; href=&quot;http://git.or.cz/&quot;&gt;Git&lt;/a&gt; and the
continuously outstanding high level of support they give.&lt;/p&gt;
&lt;p&gt;If you are interested in the topic of using version control for distro
packaging, I invite you to join &lt;a class=&quot;reference&quot; href=&quot;http://lists.madduck.net/listinfo/vcs-pkg&quot;&gt;the vcs-pkg mailing list&lt;/a&gt; and/or the
&lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;#vcs-pkg/irc.oftc.net&lt;/span&gt;&lt;/tt&gt; IRC channel.&lt;/p&gt;
&lt;p&gt;NP: &lt;a class=&quot;reference&quot; href=&quot;http://www.allmusic.com/cg/amg.dll?SQL=Aphex%20Twin&amp;amp;P=amg&amp;amp;OPT1=1&quot;&gt;Aphex Twin&lt;/a&gt;: &lt;em&gt;Selected Ambient Works, Volume 2&lt;/em&gt; (at least when I started writing…)&lt;/p&gt;
&lt;/div&gt;
</content>
</entry>

<entry>
<title type="html">Pristine tarballs and VCS
</title>
<category term="" />
<id>http://blog.madduck.net/2007/10/01/2007.10.01_pristine-tarballs-and-vcs</id>
<updated>2007-10-01T09:29:15Z</updated>
<published>2007-10-01T09:29:15Z</published>
<link rel="alternate" type="text/html" href="http://blog.madduck.net/debian/2007.10.01_pristine-tarballs-and-vcs" />
<content type="html">&lt;p&gt;Joey writes about &lt;a class=&quot;reference&quot; href=&quot;http://kitenet.net/~joey/blog/entry/git_archive_as_distro_package_format/&quot;&gt;the difficulty of dealing with the need of pristine
tarballs and version control systems&lt;/a&gt;.
He concludes that it&apos;s best to save the tarballs in the repository and &lt;a class=&quot;reference&quot; href=&quot;http://kitenet.net/~joey/blog/entry/pristine_tarball_generator/&quot;&gt;has
written a tool to store binary differences to save space&lt;/a&gt; to achieve
his goal. This being another piece of software by Joey, it&apos;s probably worth
checking out.&lt;/p&gt;
&lt;p&gt;But I wonder why we actually bother about pristine tarballs. Sure, our Debian
archive scripts require a tarball, but why does that have to be the pristine
upstream tarball?&lt;/p&gt;
&lt;p&gt;As Debian maintainer, I use &lt;a class=&quot;reference&quot; href=&quot;http://git.or.cz/&quot;&gt;git&lt;/a&gt; to keep track of the
software that I package, and if possible, I track the upstream repository
directly (Git makes it very easy to track repositories of the other, popular
version control systems).&lt;/p&gt;
&lt;p&gt;When I decide to upload a new upstream version to the Debian archive, I tag
the upstream tree, sign the tag, and generate a tarball from it:&lt;/p&gt;
&lt;pre class=&quot;literal-block&quot;&gt;
git tag -s -m&apos;preparing release of upstream 1.2.3&apos; upstream/1.2.3
git archive --prefix=foo-1.2.3/ upstream/1.2.3 | gzip -9 \
  &amp;gt; ../foo_1.2.3.orig.tar.gz
&lt;/pre&gt;
&lt;p&gt;Then I merge the tag into my Debian branch and prepare a Debian release, which
I also tag (&lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;debian/1.2.3-1&lt;/span&gt;&lt;/tt&gt;) just before uploading the package to our
archive.&lt;/p&gt;
&lt;p&gt;This is very flexible and allows me to release packages based on software
snapshots, as I just &lt;a class=&quot;reference&quot; href=&quot;http://packages.qa.debian.org/m/mdadm/news/20070929T204715Z.html&quot;&gt;did with mdadm&lt;/a&gt;. Now,
a filename of &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;mdadm_2.6.3+200709292116+4450e59.orig.tar.gz&lt;/span&gt;&lt;/tt&gt; pretty clearly
states that this is &lt;em&gt;not&lt;/em&gt; &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;mdadm-2.6.3.tar.gz&lt;/span&gt;&lt;/tt&gt;, so people would be aware
that this tarball is not &amp;quot;upstream-official&amp;quot;.&lt;/p&gt;
&lt;p&gt;But what about official releases, like &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;mdadm-2.6.3.tar.gz&lt;/span&gt;&lt;/tt&gt;? When preparing
the Debian package, it&apos;s only slightly more effort for me to download the
official tarball and store it as &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;../mdadm_2.6.3.orig.tar.gz&lt;/span&gt;&lt;/tt&gt;, but why do
I need to keep it around after I uploaded Debian package &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;2.6.3-1&lt;/span&gt;&lt;/tt&gt;? I know
I need the &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;orig&lt;/span&gt;&lt;/tt&gt; tarball to prepare the &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;diff.gz&lt;/span&gt;&lt;/tt&gt; for &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;2.6.3-2&lt;/span&gt;&lt;/tt&gt;, but
for that purpose, I can really just &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;git-archive&lt;/span&gt;&lt;/tt&gt; the appropriate tag. The
result won&apos;t produce the same hash (because the &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;tar&lt;/span&gt;&lt;/tt&gt; format stores
timestamps and is thus not really appropriate for the cause), but it provides
the same contents.&lt;/p&gt;
&lt;p&gt;In fact, what I (or someone else) should finally implement is a tool to create
the &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;diff.gz&lt;/span&gt;&lt;/tt&gt; directly from the version control data… or even better, we
should finally get rid of source packages as &lt;a class=&quot;reference&quot; href=&quot;http://blog.madduck.net/debian/2005.08.11-rcs-uploads&quot;&gt;I&apos;ve previously suggested&lt;/a&gt;, long before Ubuntu
came around to &lt;a class=&quot;reference&quot; href=&quot;https://wiki.ubuntu.com/NoMoreSourcePackages&quot;&gt;propose&lt;/a&gt; and
&lt;a class=&quot;reference&quot; href=&quot;https://blueprints.launchpad.net/ubuntu/+spec/no-more-source-packages&quot;&gt;blueprint&lt;/a&gt; the
concept.&lt;/p&gt;
&lt;p&gt;I am aware of some people&apos;s preference to be able to &amp;quot;independently verify
Debian&apos;s &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;orig&lt;/span&gt;&lt;/tt&gt; tarball using e.g. a detached GPG signature provided by
upstream,&amp;quot; but I dare to question the point of this verification. Those who
care enough to verify that the Debian-provided &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;orig&lt;/span&gt;&lt;/tt&gt; tarball is pristine
are hopefully building their own binary packages instead of trusting mine
(another &lt;a class=&quot;reference&quot; href=&quot;http://lists.debian.org/debian-security/2004/09/msg00014.html&quot;&gt;beef I&apos;ve raised in the past&lt;/a&gt;), and then
they might just as well download the source directly from upstream. I&apos;d say
most people (rightfully) don&apos;t do this and just use the Debian-provided
content, which can be assumed to be pristine if you trust me and Debian: my
GPG signature authenticates uploads to the Debian servers, and APT provides
authenticity checks downstream up until the installation on an end-user
system.&lt;/p&gt;
&lt;p&gt;… and if you trust the version control system, and this actually raises an
interesting point for me: how feasible would a man-in-the-middle attack
between Neil&apos;s (the &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;mdadm&lt;/span&gt;&lt;/tt&gt; upstream) repository and mine be, given that
I use the plain-text &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;git&lt;/span&gt;&lt;/tt&gt; transport protocol to fetch new commits. If you
have any comments on that, please let me know. I&apos;ll leave this issue for
another discussion or post.&lt;/p&gt;
&lt;p&gt;NP: &lt;a class=&quot;reference&quot; href=&quot;http://www.allmusic.com/cg/amg.dll?SQL=The%20Beatles&amp;amp;P=amg&amp;amp;OPT1=1&quot;&gt;The Beatles&lt;/a&gt;: &lt;em&gt;Abbey Road&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Update&lt;/strong&gt;: Matej Cepl pointed me to &lt;a class=&quot;reference&quot; href=&quot;https://www.redhat.com/archives/fedora-devel-list/2007-June/thread.html#00855&quot;&gt;this thread&lt;/a&gt;
on the &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;fedora-devel&lt;/span&gt;&lt;/tt&gt; mailing list, where they discuss switching from
&lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;CVS&lt;/span&gt;&lt;/tt&gt; to &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;Git&lt;/span&gt;&lt;/tt&gt; and talk a lot about their needs and how the end result is
much the same as what I am proposing. Thanks!&lt;/p&gt;
</content>
</entry>

<entry>
<title type="html">Counting developers
</title>
<category term="" />
<id>http://blog.madduck.net/2007/09/28/2007.09.28_counting-developers</id>
<updated>2007-09-28T16:11:42Z</updated>
<published>2007-09-28T16:11:42Z</published>
<link rel="alternate" type="text/html" href="http://blog.madduck.net/debian/2007.09.28_counting-developers" />
<content type="html">&lt;p&gt;For &lt;a class=&quot;reference&quot; href=&quot;http://phd.martin-krafft.net/&quot;&gt;my research&lt;/a&gt; I wanted to know how to
obtain the exact number of Debian developers. Thanks to help from Andreas Barth
and Manoj Srivastava, I can now document the procedure:&lt;/p&gt;
&lt;pre class=&quot;literal-block&quot;&gt;
$ ldapsearch -xLLLH ldap://db.debian.org -b ou=users,dc=debian,dc=org \
  gidNumber=800 keyFingerPrint \
  | sed -rne &apos;:s;/^dn:/bl;n;bs;:l;n;/^keyFingerPrint:/{p;bs}&apos; \
  | wc -l
1049
&lt;/pre&gt;
&lt;p&gt;This actually seems enough as I do not recall any new maintainers being added
since the &lt;a class=&quot;reference&quot; href=&quot;http://www.debian.org/vote/2007/vote_004&quot;&gt;last call for votes&lt;/a&gt;,
which gives 1049 as well.&lt;/p&gt;
&lt;p&gt;Andreas told me to count the number of entries in LDAP with GID 800 &lt;em&gt;and&lt;/em&gt; an
associated key in the Debian keyring. Manoj&apos;s &lt;a class=&quot;reference&quot; href=&quot;http://arch.debian.org/cgi-bin/archzoom.cgi/srivasta&amp;#64;debian.org--etch/devotee--devel--0.1--versionfix-3/dvt-quorum&quot;&gt;dvt-quorum&lt;/a&gt;
script also takes the Debian keyrings (GPG and PGP) into account, so I did the
same:&lt;/p&gt;
&lt;pre class=&quot;literal-block&quot;&gt;
$ ldapsearch -xLLLH ldap://db.debian.org -b ou=users,dc=debian,dc=org \
  gidNumber=800 keyFingerPrint \
  | sed -rne &apos;:s;/^dn:/bl;n;bs;
              :l;n;/^keyFingerPrint:/{s,keyFingerPrint: ,,p;bs}&apos; \
  | sort -u &amp;gt; ldapfprs

$ rsync -az --progress \
  keyring.debian.org::keyrings/keyrings/debian-keyring.gpg \
  ./debian-keyring.gpg

$ gpg --homedir . --no-default-keyring --keyring debian-keyring.gpg \
  --no-options --always-trust --no-permission-warning \
  --no-auto-check-trustdb --armor --rfc1991 --fingerprint \
  --fast-list-mode --fixed-list-mode --with-colons --list-keys \
  | sed -rne &apos;s,^fpr:::::::::([[:xdigit:]]+):,\1,p&apos; \
  | sort -u &amp;gt; gpgfprs

$ rsync -az --progress \
  keyring.debian.org::keyrings/keyrings/debian-keyring.pgp \
  ./debian-keyring.pgp

$ gpg --homedir . --no-default-keyring --keyring debian-keyring.pgp \
  --no-options --always-trust --no-permission-warning \
  --no-auto-check-trustdb --armor --rfc1991 --fingerprint \
  --fast-list-mode --fixed-list-mode --list-keys \
  | sed -rne &apos;s,^[[:space:]]+Key fingerprint = ,,;T;s,[[:space:]]+,,gp&apos; \
  | sort -u &amp;gt; pgpfprs

$ sort ldapfprs pgpfprs gpgfprs | uniq -c \
  | egrep -c &apos;^[[:space:]]+2[[:space:]]&apos;
1048
&lt;/pre&gt;
&lt;p&gt;MAN OVER BOARD! Who&apos;s the black sheep?&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Update&lt;/strong&gt;: In the initial post, I forgot the option &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;--fixed-list-mode&lt;/span&gt;&lt;/tt&gt; and
hit a &lt;a class=&quot;reference&quot; href=&quot;http://bugs.debian.org/444451&quot;&gt;minor bug in gnupg&lt;/a&gt;. I have since
updated the above commands. Thus, there is no more black sheep and the rest of
this post only lingers here for posterity.&lt;/p&gt;
&lt;pre class=&quot;literal-block&quot;&gt;
while read i; do
  grep &amp;quot;^${i}$&amp;quot; pgpfprs gpgfprs || echo $i &amp;gt;&amp;amp;2
done &amp;lt; ldapfprs &amp;gt;/dev/null
&lt;/pre&gt;
&lt;p&gt;which returns &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;9BF093BC475BABF8B6AEA5F6D7C3F131AB2A91F5&lt;/span&gt;&lt;/tt&gt; …&lt;/p&gt;
&lt;pre class=&quot;literal-block&quot;&gt;
$ gpg --list-keys 9BF093BC475BABF8B6AEA5F6D7C3F131AB2A91F5
pub   4096R/AB2A91F5 2004-08-20
uid                  James Troup &amp;lt;james&amp;#64;nocrew.org&amp;gt;
&lt;/pre&gt;
&lt;p&gt;… our very own keyring master James Troup.&lt;/p&gt;
&lt;p&gt;So has James subverted the project? Is he actually not a Debian developer?
Given the position(s) he holds, does that mean that the project is &lt;em&gt;doomed&lt;/em&gt;?&lt;/p&gt;
&lt;p&gt;…&lt;/p&gt;
&lt;p&gt;Ha! I am so tempted to end right here, but since my readers are used to
getting all the facts, here&apos;s the deal:&lt;/p&gt;
&lt;p&gt;James is so special that he gets to be the only one to have a key in our GPG
keyring which can be used for encryption, or so I found out as I was
researching this. Now this &lt;a class=&quot;reference&quot; href=&quot;http://bugs.debian.org/444451&quot;&gt;bug in gnupg&lt;/a&gt;
actually causes his fingerprint &lt;em&gt;not&lt;/em&gt; to be printed. Until this is fixed (if
ever), simply leave out &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;--fast-list-mode&lt;/span&gt;&lt;/tt&gt; in the above commands.&lt;/p&gt;
&lt;p&gt;NP: &lt;a class=&quot;reference&quot; href=&quot;http://www.allmusic.com/cg/amg.dll?SQL=Oceansize&amp;amp;P=amg&amp;amp;OPT1=1&quot;&gt;Oceansize&lt;/a&gt;: &lt;em&gt;Effloresce&lt;/em&gt;&lt;/p&gt;
</content>
</entry>

<entry>
<title type="html">Netconf status update
</title>
<category term="" />
<id>http://blog.madduck.net/2007/08/28/2007.08.28_netconf-status-update</id>
<updated>2007-08-28T14:18:29Z</updated>
<published>2007-08-28T14:18:29Z</published>
<link rel="alternate" type="text/html" href="http://blog.madduck.net/debian/2007.08.28_netconf-status-update" />
<content type="html">&lt;p&gt;If you care about &lt;a class=&quot;reference&quot; href=&quot;http://netconf.alioth.debian.org&quot;&gt;netconf&lt;/a&gt; and wonder
what&apos;s the current status, you might want to ingest the &lt;a class=&quot;reference&quot; href=&quot;http://lists.alioth.debian.org/pipermail/netconf-devel/2007-August/000162.html&quot;&gt;status update&lt;/a&gt;
I sent to the &lt;a class=&quot;reference&quot; href=&quot;http://lists.alioth.debian.org/mailman/listinfo/netconf-devel&quot;&gt;netconf-devel mailing list&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;The most important point probably is: if you want to work on netconf, I&apos;ll be
readily available for questions on the mailing list, even though I cannot
expend much time to hack myself over the next four months.&lt;/p&gt;
&lt;p&gt;But I will consider coaching anyone who would like to contribute and wants to
be coached in doing so. So don&apos;t hesitate and &lt;a class=&quot;reference&quot; href=&quot;mailto:madduck&amp;#64;debian.org&quot;&gt;let me know&lt;/a&gt;, and consider telling me a bit about what kind
of projects you have worked on in the past.&lt;/p&gt;
&lt;p&gt;NP: &lt;a class=&quot;reference&quot; href=&quot;http://www.allmusic.com/cg/amg.dll?SQL=Mono&amp;amp;P=amg&amp;amp;OPT1=1&quot;&gt;Mono&lt;/a&gt;: &lt;em&gt;Under the Pipal Tree&lt;/em&gt;&lt;/p&gt;
</content>
</entry>

<entry>
<title type="html">Happy Birthday, Debian
</title>
<category term="" />
<id>http://blog.madduck.net/2007/08/16/2007.08.16_happy-birthday-debian</id>
<updated>2007-08-16T08:12:27Z</updated>
<published>2007-08-16T08:12:27Z</published>
<link rel="alternate" type="text/html" href="http://blog.madduck.net/debian/2007.08.16_happy-birthday-debian" />
<content type="html">&lt;p&gt;You&apos;re 14 today. In Canada you have just reached age of consent and your tarot
card would be Temperance. Yeah!&lt;/p&gt;
&lt;p&gt;(I could hardly wait)&lt;/p&gt;
&lt;p&gt;NP: &lt;a class=&quot;reference&quot; href=&quot;http://www.allmusic.com/cg/amg.dll?SQL=The%20Penguin%20Cafe%20Orchestra&amp;amp;P=amg&amp;amp;OPT1=1&quot;&gt;The Penguin Cafe Orchestra&lt;/a&gt;: &lt;em&gt;A History&lt;/em&gt;&lt;/p&gt;
</content>
</entry>

<entry>
<title type="html">DebConf7
</title>
<category term="" />
<id>http://blog.madduck.net/2007/06/29/2007.06.25_debconf7</id>
<updated>2007-06-29T10:33:09Z</updated>
<published>2007-06-29T10:33:09Z</published>
<link rel="alternate" type="text/html" href="http://blog.madduck.net/debian/2007.06.25_debconf7" />
<content type="html">&lt;p&gt;I am sitting at Frankfurt airport in between flights home from Edinburgh (not
anymore, but that&apos;s where this post was born). It&apos;s been an intense 2.5 weeks
of &lt;a class=&quot;reference&quot; href=&quot;http://debconf7.debconf.org&quot;&gt;DebConf7&lt;/a&gt;, which has been unlike other
DebConfs for me in two respects: this was the first time I actually went to
DebCamp, the week leading up to the conference, which is designated to teams
and individuals with development goals to achieve during the week. And I was
also actively involved in the organisation of the conference, which was
unexpected, but a very good experience I am not going to miss next year.&lt;/p&gt;
&lt;p&gt;Well, it wasn&apos;t unexpected. When I &lt;a class=&quot;reference&quot; href=&quot;http://blog.madduck.net/debian/2007.01.06_on-to-edinburgh&quot;&gt;booked my flights in January&lt;/a&gt;, I had decided
to arrive a day early and leave a day late to be able to lend a hand. In
between then and the conference, &lt;a class=&quot;reference&quot; href=&quot;http://blog.madduck.net/life/2007.04.27_moving-in-pieces&quot;&gt;my life turned somewhat upside-down&lt;/a&gt; and I had
forgotten everything about these noble goals of mine.&lt;/p&gt;
&lt;p&gt;So when I arrived at the conference venue on Saturday morning with thoughts of
&lt;a class=&quot;reference&quot; href=&quot;http://netconf.alioth.debian.org/&quot;&gt;netconf&lt;/a&gt; circling my head, I was
surprised to find everyone buzzing about (how naïve of me) and somewhat
clueless as to how I should merge in: my wrists didn&apos;t really hold up to heavy
lifting, and my knee certainly didn&apos;t enjoy stairs, of which there were plenty
on the way up to the top floor, where DebCamp was taking place.&lt;/p&gt;
&lt;p&gt;After trying and being mostly ridiculed by the other organisers (&amp;quot;friends&amp;quot;...
ha!), I set out to accomplish some other tasks more suited to my bodily
condition, such as wiring the hack lab to accomodate 40 geeks for the first
week. That took me most of the day, but at least the space was ready for
Sunday morning and the official start of the camp.&lt;/p&gt;
&lt;p&gt;My goal for the week was &lt;a class=&quot;reference&quot; href=&quot;http://netconf.alioth.debian.org/&quot;&gt;netconf&lt;/a&gt; and I made good progress until I ran into
a wall on Tuesday and had to back off and rethink my design. Reinhart Tartler
and Enrico Zini dedicated their time to listen to my design and the problems
and helped me clear the mess up and helped me reduce complexity and converge
on a straight-forward, event-based design.&lt;/p&gt;
&lt;p&gt;As the newly appointed DebConf press officer and one of the organisation
volunteers, I did not get any further for a few days, as I was manning the
front desk or preparing and releasing &lt;a class=&quot;reference&quot; href=&quot;http://www.debconf.org/press/2007-06-12.shtml&quot;&gt;my first press release&lt;/a&gt; (with the help of several
others), which lead to a &lt;a class=&quot;reference&quot; href=&quot;http://www.theregister.com/2007/06/12/edinbugh_geeks_debian/&quot;&gt;lovely story on The Register&lt;/a&gt; and doubled
the number of attendees that preregistered for &lt;a class=&quot;reference&quot; href=&quot;http://debianday.org&quot;&gt;DebianDay&lt;/a&gt; (which marks the end of DebCamp and the start of
DebConf). I blame the geeks in skirts, actually. Silly bunch, but not quite as
silly as those attendants who could get a laugh out of &lt;a class=&quot;reference&quot; href=&quot;http://blog.hands.com/2007/06/10#curious&quot;&gt;the underwear question&lt;/a&gt; &lt;em&gt;for two weeks in a row&lt;/em&gt;.&lt;/p&gt;
&lt;p&gt;Up to this point, I had managed to keep a perfect balance between netconf,
orga-team, and sleep. So good, apparently, that when the orga-team t-shirts
arrived, Uncle Steve made it quite clear that I should be getting one, even
though I had spent considerable time on netconf, am sure some of the others
must have worked twice the amount, and I was still quite well rested then. But
they gave me a shirt and thus I became part of the orga-team. And even though
it was rough at times, running around during the day, filling spare minutes
with netconf brain-work, and enjoying nights that got longer with every day of
the conference, I am glad and proud to be a member of this team now.&lt;/p&gt;
&lt;p&gt;It took me until after the official start of the conference to return to the
netconf code, but with the new design, I got most of the framework to a point
where it could obtain static and dynamic addresses from configuration files as
well as DHCP servers in time for &lt;a class=&quot;reference&quot; href=&quot;http://people.debian.org/~madduck/talks/netconf_debconf7_2007.06.18/slides.s5.html&quot;&gt;my presentation on Tuesday&lt;/a&gt;
(the recording of which shall be linked from the netconf homepage as soon as
it&apos;s available). Of course, nothing worked on screen in front of the audience,
but noone really expected that anyway.&lt;/p&gt;
&lt;p&gt;… and then I took it all apart for further simplification, so by the time
night fell, the slides from the talk had already become outdated as I moved to
&lt;a class=&quot;reference&quot; href=&quot;http://git.debian.org/?p=netconf/netconf.git;a=blob;f=doc/design.txt;hb=HEAD&quot;&gt;yet another design&lt;/a&gt;,
which is even simpler and which allowed me to sketch complex scenarios, such
as DHCP after WPA. For two days, I made good progress, but the time available
for hacking decreased noticeably, as I kept volunteering for more tasks that
needed doing, and more and more people turned up.&lt;/p&gt;
&lt;p&gt;Somewhere in between, &lt;a class=&quot;reference&quot; href=&quot;http://loldebian.wordpress.com/2007/06/19/i-has-a-new-xorg-input-driver/&quot;&gt;Keith Packard&lt;/a&gt;
took hostage of (and fixed parts of) my &lt;a class=&quot;reference&quot; href=&quot;http://bugs.debian.org/426548&quot;&gt;broken X40 laptop&lt;/a&gt;, but that&apos;s
the meat of &lt;a class=&quot;reference&quot; href=&quot;http://blog.madduck.net/geek/2007.06.26_60-efficient-minutes-of-intel&quot;&gt;another story&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;And on some other night, our leader Sam, in his official capacity as DPL,
presented me with the instantiation of my innermost desires as consolation for
my hosital stay: a &lt;a class=&quot;reference&quot; href=&quot;http://loldebian.wordpress.com/2007/06/20/now-i-has-a-pony/&quot;&gt;pony&lt;/a&gt;. Just look at
that smile!&lt;/p&gt;
&lt;p&gt;With 400 attendants, this year&apos;s DebConf continued the trend of immense growth
of the event, and while it&apos;s great to witness this increase in popularity
among attendees and sponsors, who make it possible each year to fly more
people to the destination, I am also rather sceptical. The problem is less the
additional load on the organising team — the next 100 people are going to be
easier to accomodate than the previous 100 were. It is more that the
conference is losing focus. More people make you spend less time with the same
folks, and as the number of non-contributors increases, the social element
starts to outweigh the technical element. I am not condemning the social
element, but to paraphrase the words of my favourite Debian developer, it&apos;s
painful to come to DebConf or even IRC with a project and questions just to
find that the people are generally more interested in being social, even to
the point of preventing technical discussions.&lt;/p&gt;
&lt;p&gt;I realise that this is a sensitive subject as the issue of various cabals
keeps coming up frequently and it does not seem right to start limiting the
audience to this conference, but unless we consider the matter, DebConf might
deteriorate similarly to other conferences, which have enjoyed enormous growth
as well before it was too late. I think we must make sure that people
understand that we are, after all, a technical project and must not lose touch
with out roots. Of course, I may also be overreacting, after a week of intense
coding and many other stress factors…&lt;/p&gt;
&lt;p&gt;I continued working hard on netconf and helping with the organisation
throughout Friday, briefly taking time off to prepare &lt;a class=&quot;reference&quot; href=&quot;http://people.debian.org/~madduck/talks/overview_debconf7_2007.06.21/slides.s5.html&quot;&gt;a presentation on my
Ph.D. research&lt;/a&gt;,
which was very well received, as well as &lt;a class=&quot;reference&quot; href=&quot;https://penta.debconf.org/~joerg/events/53.en.html&quot;&gt;a workshop on Debian packaging with
modern (distributed) version control systems&lt;/a&gt;, which yielded around
a dozen new subscribers to the &lt;a class=&quot;reference&quot; href=&quot;http://lists.madduck.net/listinfo/vcs-pkg&quot;&gt;vcs-pkg mailing list&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;But now, back to netconf. All things considered, I was making good progress,
but not getting netconf into a releasable state just yet. I can parse
&lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;/etc/network/interfaces&lt;/span&gt;&lt;/tt&gt; files and get data from DHCP servers, even
configure interfaces with those, but it&apos;s all still work in progress as I have
not yet bothered to implement such basics as default gateways or DNS servers.
But the framework is in place, and I am very happy with it as everything
I keep adding falls into place beautifully.&lt;/p&gt;
&lt;p&gt;To mark the end of my netconf development sprint at DebConf7, I scheduled
a &lt;a class=&quot;reference&quot; href=&quot;https://penta.debconf.org/~joerg/events/208.en.html&quot;&gt;code introduction session&lt;/a&gt; on Friday, where
around 15 people turned out to get a walkthrough of the code and explanation
of some of my design decisions. The session was recorded and will be available
on video shortly. I think it turned out to be a very good idea; I found myself
intrigued by someone else&apos;s code before until that someone took the time to
explain what was going on. I sincerely hope that this introduction helps
bootstrap a few people&apos;s experiences with the code and yields more
contributors!&lt;/p&gt;
&lt;p&gt;Even though we ended almost every single evening of the two weeks in one of
the surrounding pubs, the last few nights were definitely the most enjoyable.
On Thursday, the local team had organised a Ceilidh with a band teaching us
geeks how to dance the Scottish way, and the venue stayed open for two hours
longer than before, causing most people to come out for beer or bouncing
about. On Friday and Saturday, the folks of &lt;a class=&quot;reference&quot; href=&quot;http://www.infoseed.org/&quot;&gt;InfoSeed&lt;/a&gt; let us use their comfy couches (in the basement
of the conference night venue) and we chilled to music and massages, while on
Sunday, after a very tiresome day of cleaning up, the noticably lesser number
of survivors hung out at the &lt;a class=&quot;reference&quot; href=&quot;http://www.theforest.org.uk/&quot;&gt;Forest Cafe&lt;/a&gt; for
some so-so live music, few beers, and an early journey to bed, where a Dutch
Muppet kept us entertained for at least another hour.&lt;/p&gt;
&lt;p&gt;The best about Monday, my day of return, must have been that the airline lost
my backpack, which saved me from having to lug it around in Zurich, and made
for a great moment on the phone with the baggage tracing service, who
announced that my bags would be delivered in about 6 hours between 20:00 and
22:00 &lt;em&gt;just&lt;/em&gt; as the door bell rang and the courier dropped off my bag.&lt;/p&gt;
&lt;p&gt;I&apos;ll be back in Argentina, unless something goes seriously wrong. And I&apos;ll be
on the orga-team again. If you guys stop holding your meetings on Monday
night.&lt;/p&gt;
&lt;p&gt;Thanks to everyone who made DebConf7 possible. I am proud to have been able to
contribute, but the real work was done by a few others. You know who you are.&lt;/p&gt;
&lt;p&gt;NP: &lt;a class=&quot;reference&quot; href=&quot;http://www.allmusic.com/cg/amg.dll?SQL=Solar%20Project&amp;amp;P=amg&amp;amp;OPT1=1&quot;&gt;Solar Project&lt;/a&gt;: &lt;em&gt;Five&lt;/em&gt;&lt;/p&gt;
</content>
</entry>

<entry>
<title type="html">Keysigning in Edinburgh
</title>
<category term="" />
<id>http://blog.madduck.net/2007/06/27/2007.06.27_keysigning-in-edinburgh</id>
<updated>2007-06-27T11:08:31Z</updated>
<published>2007-06-27T11:08:31Z</published>
<link rel="alternate" type="text/html" href="http://blog.madduck.net/debian/2007.06.27_keysigning-in-edinburgh" />
<content type="html">&lt;p&gt;At &lt;a class=&quot;reference&quot; href=&quot;http://debconf7.debconf.org&quot;&gt;DebConf7&lt;/a&gt;, I took part in the &lt;a class=&quot;reference&quot; href=&quot;https://debconf7.debconf.org/~ksp&quot;&gt;keysigning
party&lt;/a&gt;. Since &lt;a class=&quot;reference&quot; href=&quot;http://blog.madduck.net/geek/2006.05.27-keysigning-again&quot;&gt;keysigning is not about
authenticating government-issued IDs&lt;/a&gt;, I took only my
&lt;a class=&quot;reference&quot; href=&quot;http://www.transnationalrepublic.org/&quot;&gt;Transnational Republic&lt;/a&gt; identity
card to the event.&lt;/p&gt;
&lt;p&gt;The reactions I got were multifarious:&lt;/p&gt;
&lt;ul class=&quot;simple&quot;&gt;
&lt;li&gt;some (most) people had heard &lt;a class=&quot;reference&quot; href=&quot;http://blog.madduck.net/geek/2006.05.24-tr-id-at-keysigning&quot;&gt;the story from last year&lt;/a&gt; and joyfully
checked off my name.&lt;/li&gt;
&lt;li&gt;a number of people challenged me to present a &amp;quot;real&amp;quot; ID, which I refused to
do. They then told me they could not sign my key. I asked each to consider
what it is they&apos;re signing: a statement about their perception of my
identity, or a statement about their trust in the governments issuing
&amp;quot;official&amp;quot; IDs. Given a second or two, most people would check off my name
anyway. What&apos;s alarming is that in those cases I had the impression that
they simply succumbed to my pressure without thinking about what I actually
asked.&lt;/li&gt;
&lt;li&gt;several people didn&apos;t need to see my ID and checked off my name after
I answered the question about having checked the hashes (which is also
rather pointless).&lt;/li&gt;
&lt;li&gt;very few people checked off my name without knowing me or questioning the
ID.&lt;/li&gt;
&lt;li&gt;two people smiled and checked the ID, but placed an X or question mark on
their sheet.&lt;/li&gt;
&lt;li&gt;one person refused to inspect my ID and crossed out my name.&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;All in all, I am satisfied with the results and happy to see many more people
questioning the web of trust, or at least the way in which we pretend to
secure it.&lt;/p&gt;
&lt;p&gt;Yet, I have come to the point where I will not take part in keysigning events
anymore. The value of the web of trust is overrated, and with every single
keysigning party, we just make things worse.&lt;/p&gt;
&lt;p&gt;It was a good idea to separate folks into groups around well-connected keys to
speed up the process, but the groups were still too large to allow for
experienced people to pass knowledge to the lesser-experienced ones. Instead
of taking part in the event with a critical eye, I saw people present three
forms of identification (&amp;quot;does that mean you are really you, or just that you
have more money than the other identify fraudsters?&amp;quot;) or asking &amp;quot;trick
questions&amp;quot; to verify the birthdate written on these documents (&amp;quot;someone ready
to deceive an identity who went through the trouble to fake documents will
surely have remembered their data&amp;quot;).&lt;/p&gt;
&lt;p&gt;I shall, in the future, only sign keys of people I already know, and with whom
I&apos;ve interacted before on a level to know bits about their life, personality,
and project involvement. I will not require an ID to be presented. If this
goes against your idea of the web of trust, please edit your trust database
accordingly. My keys are 0x330c4a75 and 0x667c7088 (not yet used).&lt;/p&gt;
&lt;p&gt;NP: &lt;a class=&quot;reference&quot; href=&quot;http://www.allmusic.com/cg/amg.dll?SQL=Proto-Kaw&amp;amp;P=amg&amp;amp;OPT1=1&quot;&gt;Proto-Kaw&lt;/a&gt;: &lt;em&gt;Before Became After&lt;/em&gt;&lt;/p&gt;
</content>
</entry>

<entry>
<title type="html">60 efficient minutes of Intel
</title>
<category term="" />
<id>http://blog.madduck.net/2007/06/26/2007.06.26_60-efficient-minutes-of-intel</id>
<updated>2007-06-26T20:08:10Z</updated>
<published>2007-06-26T20:08:10Z</published>
<link rel="alternate" type="text/html" href="http://blog.madduck.net/debian/2007.06.26_60-efficient-minutes-of-intel" />
<content type="html">&lt;p&gt;I arrived at &lt;a class=&quot;reference&quot; href=&quot;http://debconf7.debconf.org&quot;&gt;DebConf7&lt;/a&gt; with my X40, which
would &lt;a class=&quot;reference&quot; href=&quot;http://bugs.debian.org/426548&quot;&gt;randomly freeze on any video-related event&lt;/a&gt;. I even reinstalled everything &lt;em&gt;without&lt;/em&gt;
copying &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;/etc&lt;/span&gt;&lt;/tt&gt; from the old installation onto a fresh harddisk without
success. I tried various kernels, including Ubuntu kernels which rendered my
system unbootable. I swore, I kicked and screamed, I contemplated throwing it
out of several windows at once and buying a non-IBM replacement, I think
I even had bad dreams about it. I did not cry just yet though.&lt;/p&gt;
&lt;p&gt;I was unable to work on it, neither locally nor via external monitor. In fact,
my solution for the first week was to occupy one of the spare desktop
machines, link up the original laptop harddisk by way of a great PATA/SATA to
USB converter, which Hanspeter gave me for Christmas, boot off the encrypted
filesystems, bring up &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;X&lt;/span&gt;&lt;/tt&gt;, and finally &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;ssh&lt;/span&gt;&lt;/tt&gt; into the laptop, where I did
the actual work. Trust me, it was ugly. But at least I was able to make
progress on &lt;a class=&quot;reference&quot; href=&quot;http://netconf.alioth.debian.org&quot;&gt;netconf&lt;/a&gt;.&lt;/p&gt;
&lt;p&gt;I called Lenovo and they agreed to send a technician out to the venue. Yay for
on-site support. That was Friday though, so I&apos;d have to wait until Monday,
which was of course when my &lt;a class=&quot;reference&quot; href=&quot;https://penta.debconf.org/~joerg/events/45.en.html&quot;&gt;talk on netconf&lt;/a&gt; was to take place.&lt;/p&gt;
&lt;p&gt;Suddenly, or not so suddenly, but it happened in real-time: in walks Keith
Packard, developer of the Intel graphics chips driver for &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;X&lt;/span&gt;&lt;/tt&gt;, and I swear
he had &amp;quot;bring me broken X40s!!!!!!&amp;quot; written on his forehead and BIOS latency
timeout values as pupils like a &lt;a class=&quot;reference&quot; href=&quot;http://en.wikipedia.org/wiki/Uncle_Scrooge&quot;&gt;popular comic character&apos;s&lt;/a&gt; eyes may be made off a dollar
sign when excited. Ask Matthew Garrett if you don&apos;t believe me.&lt;/p&gt;
&lt;p&gt;So I approached him and handed over the X40 and had him even more excited when
I mentioned &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;i855&lt;/span&gt;&lt;/tt&gt; and it was all downhill from there. I left him with
password for &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;root&lt;/span&gt;&lt;/tt&gt; and the encrypted filesystem (he&apos;s a Debian developer
after all, so he has &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;root&lt;/span&gt;&lt;/tt&gt; on all my machines anyway…) and wandered off for
some organisational stuff. It feels great to be at DebConf without your laptop
to come back to.&lt;/p&gt;
&lt;p&gt;So great even that in a moment of genius I decided to do my laundry, and off
I went, back to the hostel. Get stuff from hostel B, convince staff from
hostel A that I am in fact allowed to wash there as hostel B has no laundry
facilities, buy tokens and detergent, dump stuff, find couch and sleep…&lt;/p&gt;
&lt;p&gt;…&lt;/p&gt;
&lt;p&gt;… gosh was I tired, but not anymore, when my phone rings to announce the end
of the washing cycle. Retrieve, return to hostel B, hang stuff all over the
room (we all know each other &lt;em&gt;and&lt;/em&gt; these are clean clothes), return to hostel
A to say thank you (I actually did), fetch lunch at Subway, arrive at venue,
return to desk to find laptop but no Keith.&lt;/p&gt;
&lt;p&gt;Look confused.&lt;/p&gt;
&lt;p&gt;Look around to find Keith smiling at me and that the patch to my problem had
already made it to the upstream repository. Sit, relax, think, breathe, wow.&lt;/p&gt;
&lt;p&gt;60 damn efficient minutes. Let my next machine have Intel chips, please?&lt;/p&gt;
&lt;p&gt;(call Lenovo, &amp;quot;suspend&amp;quot; the call. Lucky for them, or imagine the ripples of
the on-site technician suggesting to try to reproduce the problem with
Windows).&lt;/p&gt;
&lt;p&gt;PS: Unfortunately, the problems aren&apos;t all gone. There still seem to be some
DPMS-related crashes, and suspending to RAM from &lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;X&lt;/span&gt;&lt;/tt&gt; leaves a black display
on resume
(&lt;a class=&quot;reference&quot; href=&quot;http://bugs.debian.org/421888&quot;&gt;some might say it&apos;s good that this is happening to me too&lt;/a&gt;), but I am definitely a lot more peaceful
now. Thanks, Keith.&lt;/p&gt;
&lt;p&gt;NP: &lt;a class=&quot;reference&quot; href=&quot;http://www.allmusic.com/cg/amg.dll?SQL=Threshold&amp;amp;P=amg&amp;amp;OPT1=1&quot;&gt;Threshold&lt;/a&gt;: &lt;em&gt;Critical Mass&lt;/em&gt;&lt;/p&gt;
</content>
</entry>

<entry>
<title type="html">Starting netconf development
</title>
<category term="" />
<id>http://blog.madduck.net/2007/05/08/2007.05.08_starting-netconf-development</id>
<updated>2007-05-08T16:09:20Z</updated>
<published>2007-05-08T16:09:20Z</published>
<link rel="alternate" type="text/html" href="http://blog.madduck.net/debian/2007.05.08_starting-netconf-development" />
<content type="html">&lt;p&gt;&lt;a class=&quot;reference&quot; href=&quot;http://lists.debian.org/debian-devel/2007/05/msg00225.html&quot;&gt;This message&lt;/a&gt;
just went out to the &lt;a class=&quot;reference&quot; href=&quot;http://lists.debian.org/debian-devel/&quot;&gt;debian-devel mailinglist&lt;/a&gt;:&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;Even though &lt;a class=&quot;reference&quot; href=&quot;http://blog.madduck.net/life/2007.04.27_moving-in-pieces&quot;&gt;I am still somewhat physically limited&lt;/a&gt;, my brain today
decided to start on the &lt;a class=&quot;reference&quot; href=&quot;http://netconf.alioth.debian.org/&quot;&gt;netconf&lt;/a&gt;
development. And since we all know that the waterfall model is the One True
Model and that Extreme Programming no solution, I started by drafting
a document, nothing formal, just thoughts on how to implement the various
parts of netconf. And open questions I already know need to be answered.&lt;/p&gt;
&lt;p&gt;I shall be posting this document to the &lt;a class=&quot;reference&quot; href=&quot;http://lists.alioth.debian.org/mailman/listinfo/netconf-devel&quot;&gt;netconf-devel mailing list&lt;/a&gt; sometime
soon and am looking for comments (and answers and helpers). The purpose of
this message is to get interested people to subscribe. Please do so that we
can keep debian-devel free of this and so that I can get more feedback (and
potentially help).&lt;/p&gt;
&lt;p&gt;If you don&apos;t know what I am talking about, check out the &lt;a class=&quot;reference&quot; href=&quot;http://netconf.alioth.debian.org/&quot;&gt;wiki page&lt;/a&gt; and &lt;a class=&quot;reference&quot; href=&quot;http://people.debian.org/~madduck/talks/netconf_fosdem_2007.02.25/slides.s5.html&quot;&gt;slides from my last talk&lt;/a&gt;.
Then subscribe.&lt;/p&gt;
&lt;/blockquote&gt;
&lt;p&gt;Thanks for your attention; that is all.&lt;/p&gt;
&lt;p&gt;NP: Trentemøller: &lt;em&gt;The Last Resort&lt;/em&gt;&lt;/p&gt;
</content>
</entry>

<entry>
<title type="html">A lesson learnt
</title>
<category term="" />
<id>http://blog.madduck.net/2007/05/08/2007.05.08_a-lesson-learnt</id>
<updated>2007-05-08T15:12:45Z</updated>
<published>2007-05-08T15:12:45Z</published>
<link rel="alternate" type="text/html" href="http://blog.madduck.net/debian/2007.05.08_a-lesson-learnt" />
<content type="html">&lt;p&gt;I am installing my first Ubuntu computer, a laptop for a friend who just wants
to use the Internet. Even though I am not entirely sure whether to ridicule
the installation process — it took the installer 2:47 hours to produce the
first user dialog on this PIII 600MHz with 256Mb of RAM, so I had to use the
alternative text-mode installer — or be impressed by the desktop that
eventually filled the screen with more-or-less everything working out of the
box, I think I did learn a lesson today, as trivial as it may sound.&lt;/p&gt;
&lt;p&gt;The screen of this laptop stays blank throughout the boot sequence even though
Ubuntu put so much effort into a flashy splash screen. Thus, I logged on to
&lt;tt class=&quot;docutils literal&quot;&gt;&lt;span class=&quot;pre&quot;&gt;#ubuntu&lt;/span&gt;&lt;/tt&gt; and found someone who had time to help:&lt;/p&gt;
&lt;pre class=&quot;literal-block&quot;&gt;
&amp;lt; madduck&amp;gt; i just installed feisty on a laptop and now when i start, after
           grub, it says &amp;quot;Starting up&amp;quot; and then has a black screen until gdm
           has started
&amp;lt; madduck&amp;gt; where is the fancy splash?
&amp;lt; someone&amp;gt; madduck: the splash screen uses a standard VESA mode which,
           apparently, your system doesn&apos;t support. Remove the &amp;quot;quiet
           splash&amp;quot; options from menu.lst to see boot messages in text mode.
&amp;lt; someone&amp;gt; madduck: you can try fixing the VESA mode with the vga= kernel
           boot option. Start with &apos;vga=ask&apos; and enter &apos;scan&apos; at the prompt
           at boot time.
&lt;/pre&gt;
&lt;p&gt;But I still had no success when someone apparently typed into the wrong window
and triggered the childish area of my brain:&lt;/p&gt;
&lt;pre class=&quot;literal-block&quot;&gt;
&amp;lt; someone_else&amp;gt; ls
&amp;lt; someone_else&amp;gt; clear
&amp;lt; madduck&amp;gt; rm -rf ~
&amp;lt; someone&amp;gt; madduck: what was the purpose of that?
&amp;lt; madduck&amp;gt; someone: EWIN :)
&amp;lt; someone&amp;gt; madduck: I&apos;m not prepared to support you if you go around telling
           people to delete their home directories, however funny you think
           that is.
&lt;/pre&gt;
&lt;p&gt;I apologised (sincerely), and the person went on to help me, pointing me to
more VESA modes and making me try them until I had a lead.&lt;/p&gt;
&lt;p&gt;No wonder Ubuntu gets the users.&lt;/p&gt;
&lt;p&gt;I am not saying that Debian is at the losing end in this scenario.&lt;/p&gt;
&lt;p&gt;Instead, I am preaching to the choir who sings back: &amp;quot;but Debian wouldn&apos;t be
Debian without the flames.&amp;quot;&lt;/p&gt;
&lt;p&gt;And I think to myself: &amp;quot;I wonder who actually engages their brains and
continues to hold that view when they utter it.&amp;quot;&lt;/p&gt;
&lt;p&gt;NP: The Young Gods - Kissing the Sun (Orange Mix)&lt;/p&gt;
&lt;p&gt;&lt;strong&gt;Update&lt;/strong&gt;: without having to be told by anyone, I know there are people in
Debian who try to be equally helpful and reasonable. In fact, Debian has
gotten &lt;em&gt;a lot&lt;/em&gt; better in the last years, in part (but not exclusively) thanks
to &lt;a class=&quot;reference&quot; href=&quot;http://women.debian.org&quot;&gt;Debian Women&lt;/a&gt;. This post does not try to
dis