Debian News – Page 65

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.

DPL election: low participation

April 10, 2008 by Raphaël Hertzog

This year I have not given any vote recommendation because all candidates would be (IMO) good DPL. The participation stats are a bit strange however: when I got the second call for vote I noticed 176 votes in the first week compared to 135 last year. So I thought “good, participation is on the rise”. But then I got reminded that we have shortened the voting period of the DPL election to two weeks. So the comparison doesn’t hold.

The vote close in two days and we have so far only 283 votes, and last year we got 482 in the end. So we’re likely to have much less participation this year… even if you add a percentage for the people who wish to vote but cannot for various reasons (which proves once more how important it is that the next DPL be determined to fix those recurring problems), you won’t get the same numbers.

So my question is: do we have lower participation because all candidates are good and people do not care who gets elected? or do we have so many DD that follow Debian only every 2.5 weeks?

And if you haven’t voted yet, it’s time to do it. 🙂

Debian Documentation Project moved to SVN, webwml might follow

March 3, 2008 by Raphaël Hertzog

The topic of switching from CVS to something else regularly came forward but nobody did anything. The net result is that several documentation are now maintained outside of the debian-doc repository because their respective maintainers didn’t want to stay with CVS.

After noticing that the developers-reference also switched to SVN, I decided to convert the whole debian-doc CVS repository and import it in the new “ddp” SVN repository on Alioth. This is now done.

Hopefully, the Debian Documentation Project can now again become the central place for writing good documentation about Debian. New contributors can be easily added through the DDP Alioth project. Volunteers are welcome to review what’s in the SVN and move obsolete documentation aside. People who moved away are welcome back. 🙂

Another project that also suffers from its CVS usage is the website (and it desperately needs a better design). After yet another round of discussion on #debian-devel, we agreed that discussing endlessly was not an option and that someone had to try the conversion and prepare the scripts for SVN usage. So I proposed to handle the CVS to SVN conversion and ifvoid decided to try to update the scripts. And it looks like things are progressing quite well… we included the CVS revision -> SVN revision mapping in the conversion (option –cvs-revnums of cvs2svn) and this will enable us to script the update of all translations (they encode a CVS revision to know if they are out-of-date or not). Expect to hear from us soon on debian-www@lists.debian.org…

Tags

Recent Posts