Debian – Page 82

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 !

Flights for Debconf

March 26, 2009 by Raphaël Hertzog

I have booked my flights for Debconf9 in July. I will arrive in Madrid on July 23th at 10:30 from Lyon Saint-Exupéry (LYS-MAD, flight AF5891) and I will leave on July 31th at 17:40 (MAD-LYS, flight AF5892). I plan to use the train to go to Cáceres but it’s too early to buy tickets on renfe.es. I also have no idea how far the train station is (from the airport) but it looks like I will have several hours transit time anyway. There aren’t so many trains for Cáceres. The train tickets will likely cost around 30 EUR each.

I’m glad that I can attend again this year. I’m sure it will be very productive. At least concerning dpkg it will be good to meet Guillem Jover IRL.

Tags

Recent Posts