apt-get install debian-wizard

New source formats allowed in testing/unstable

November 2, 2009 by Raphaël Hertzog

The ftpmasters merged my dak branch last week during their meeting and have enabled the support of new source formats “3.0 (quilt)” and “3.0 (native)” in testing, unstable and testing-proposed-updates. I have uploaded 3 packages using the new formats already: logidee-tools using “3.0 (native)”, quilt and ftplib using “3.0 (quilt)”. The latter is arch any and has been successfully built on all architectures even those that still use an old version of sbuild (it looks like the fears that the old version would not cope with the new format were unfounded). For logidee-tools I built it with “-Zbzip2” in order to use bzip2 compression on the native tarball.

I have updated the wiki page and the release goal page with latest information. Feel free to convert some of your packages to give it a try. For ftplib, it led me to discover a Debian specific patch that I completely missed when I took the package over. This is precisely the kind of benefit that I expect from generalizing this format, it will encourage us to have separate documented patches instead of keeping everything hidden inside the usual .diff.gz. Combined with DEP-3 (patch tagging guidelines), we have a better infrastructure to share our patches with the rest of the free software community.

The next step is to fix all bugs listed here and make dpkg-source use the new source formats by default (#553928). Feel free to help by preparing patches (and offering NMUs), it’s a release goal to have all packages buildable with new source formats.

3-way merge of Debian changelog files

October 8, 2009 by Raphaël Hertzog

I’ve been considering for some time now to create a merge tool specifically suited for debian/changelog files. My goal was to let Git use it automatically thanks to gitattributes.

I’ve just gone ahead, so let me introduce you git-merge-dch. Grab it with git clone git://git.debian.org/~hertzog/git-merge-dch.git, you can build a package if you wish. Beware, you need to have a dpkg-dev 1.15.5 that is not yet published (so you need to build dpkg from its git repository, git clone git://git.debian.org/dpkg/dpkg.git) as I rely on features that I introduced recently… you will also need the libalgorithm-merge-perl package.

Using it in a git repository requires two changes:

defining a new merge driver somewhere in the git configuration (in .git/config or ~/.gitconfig for example):

[merge "git-merge-dch"]
        name = debian/changelog merge driver
        driver = git-merge-dch -m %O %A %B %A

defining the merge attribute for debian/changelog files either in .gitattributes in the repository itself or in .git/info/attributes:
```
debian/changelog merge=git-merge-dch
```

Now you can safely maintain two branches of a package with changelog files evolving separately and merge one into the other without creating undue conflicts. Suppose you created an experimental branch for version 2.28 (you use a version 2.28-1~exp1) when 2.26.2 was current stable in the master branch. In the mean time, 2.26.3 got out and was packaged in master. Next time you merge stable into experimental, the changelog entries for 2.28 and 2.26.3 won’t collide despite being at the same place in the changelog file compared to the common ancestor.

Let’s continue with this example, 2.28 is out. Instead of adding a new changelog entry with “New upstream release” without further changes, you keep the current changelog entry and simply change the version into 2.28-1. While preparing this you discover a branch with fixes that was based on 2.28-1~exp1, if you merge it it will reintroduce a 2.28-1~exp1 entry that you don’t want. Fortunately you can use the --merge-prereleases (-m) option of git-merge-dch so that it strip the prerelease part of the version string and considers 2.28-1~exp1 and 2.28-1 to be the same entry really.

The only limitation is that this merge tool will remove any lines which are not parsed by Dpkg::Changelog (and which in theory are not supposed to be there).

Feel free to test, share your comments, report bugs and send patches!

Update: the script has been merged in dpkg-dev (>= 1.15.7) under the name dpkg-mergechangelogs.

Interdependence in Debian, how to suffer less from it

September 1, 2009 by Raphaël Hertzog

Listening to Martin Krafft’s talk at Debconf (related to his PhD) shed some new light on the idea that I expressed last year — I wanted that each maintainer regularly answers a questionnaire so that he has to ask himself whether he does a good enough job with his packages.

When thinking of this idea, I only saw the QA side of ensuring good maintenance on all packages, however I believe that the root problem lies further and this project would not be enough: we are interdependent but we are not equipped to deal with this reality. Martin’s only merit has been to mention that we are interdependent, but it’s worth analyzing a bit.

Our organization is centered around individuals acting as package maintainers, and in theory each package maintainer can work on his corner and all goes well. We know that this model doesn’t hold any more: transitions to testing require coordination of uploads and timely fixes of RC bugs, keeping up with the work frequently requires several volunteers that have to coordinate, etc. More and more of the work requires a level of availability that a single individual can’t offer, yet in our day-to-day work we mainly interact with individuals. Wouldn’t it be better if we could immediately know what we can expect from any Debian developer:

mean time to reply to Debian mail (reading every day or once a week is not the same);
amount/periods of time spent on Debian (knowing that they spend up to 4 hours mainly on Saturday can be useful);
current availability for Debian (if they are currently busy with life, we should be able to know it, if they know when it will end, it would also be good to share);
best way to get in touch for issues (they might have preference between IRC or mail);
kind of relationship they have with packages where they are listed in Maintainer/Uploaders (an active maintainer that uses the software daily is not the same than a passive maintainer that only packaged the software because it was a build-dependency for some other software that they care about);
any other information that the maintainer wants to share (about his habits/constraints/values/goals/whatever).

All this information should be shared by all Debian maintainers (some of it is already available but either not publicly or not in any machine-parseable way) and we should actively use it. Here are some examples of use: for each RC bug report, you could look up if at least one maintainer is available and you could ping him explicitly if needed. When you plan an NMU, you could look up if the maintainer is likely to respond in the next day or not, and possibly adjust the number of days spent in the DELAYED queue. When organizing a large-scale transition, you could extract a list of packages whose maintainers are not available and arrange immediate NMUs.

Furthermore there are many cases where the project’s usual expectation exceed what the maintainer is ready to do. Documenting what part of the job is done (or not) by the maintainer makes it clear for volunteers whether their help is needed and whether they could/would be a better maintainer for a given package.

Designing solutions to all these problems is going to be the scope of the DEP2 that I reserved some time ago. It’s likely to be some sort of dedicated web interface. I would welcome supplementary drivers for this DEP, so if you’re interested, get in touch with me.

Quilt patch management with debhelper 7

May 9, 2009 by Raphaël Hertzog

Since quilt 0.46-7 (see #527255) you can automatically apply/unapply a quilt patch serie with debhelper’s dh command. It’s very practical in tiny rules files:

%:
	dh --with quilt $@

There’s also dh_quilt_patch and dh_quilt_unpatch for those who don’t use tiny rules files.

Enjoy !

Tags

Recent Posts