You are here: Home / Archives for dpkg

How to customize dpkg-source’s behaviour in your Debian source package

September 14, 2010 By

dpkg-source is the program that generates the Debian source package when a new package version is built. It offers many interesting command-line options but they are often not used because people don’t know how to ensure that they are used every time the package is built. Let’s fill that gap!

It is possible to forward some options to dpkg-source by typing them on the dpkg-buildpackage command line but you’d have to remember to type them every time. You could create a shell alias to avoid typing them but then you can’t have different options for different packages. Not very practical.

The proper solution has been implemented last year (in dpkg 1.15.5). It is now possible to put options in debian/source/options. Any long option (those starting with “--“) can be put in that file, one option per line with the leading “--” stripped.

Here’s an example:

# Bzip2 compression for debian.tar
compression = "bzip2"
compression-level = 7
# Do not generate diff for changes in config.(sub|guess)
extend-diff-ignore = "(^|/)config.(sub|guess)$"

Notice that spaces around the equal sign are possible contrary on the command line. You can use quotes around the value but it’s not required.

The debian/source/options file is part of the source package so if someone else grabs the resulting source package and rebuilds everything, they will use the options that you defined in that file.

You can also use debian/source/local-options but this time the file will not be included in the resulting source package. This is interesting for options that you want to use when you build from the VCS (Version Control Repository, aka git/svn/bzr/etc.) but that people downloading the resulting source package should not have. Some options (like --unapply-patches) are only allowed in that file to ensure a consistent experience for users of source packages.

You can learn more about the existing options in the dpkg-source manual page. Read it, I’m sure you’ll learn something. Did you know that you can tell dpkg-source to abort if you have upstream changes not managed by an existing patch in debian/patches? It’s --abort-on-upstream-changes and it’s only allowed in debian/source/local-options.

Be sure to subscribe to the RSS feed or to the email newsletter to not miss useful documentation for Debian contributors!

Filed Under: Contributor Documentation, Documentation Tagged With: , , , , ,

How to make 110.28 EUR in one month with free software and Flattr

August 12, 2010 By

Flattr FOSS Logo

  1. Create an account on Flattr.com (mine is here);
  2. Submit the URL of your free software project to the Flattr directory with a good description and the proper tags (here’s my entry for dpkg);
  3. Add a Flattr button on your website (I put one on wiki.debian.org/Teams/Dpkg);
  4. Inform your users and reach out to free software users using Flattr by registering your project in Flattr FOSS.

And I’m not alone, Joey Hess made 25 EUR in one week only.

And right now only 30K people are using Flattr. I expect this number to increase significantly now that invites are no longer required to open a Flattr account (see the announce on Flattr’s blog).

It’s time to spread the word about Flattr FOSS!

Filed Under: News Tagged With: , , ,

Quick news: dpkg, collab-maint, alioth and the future

July 22, 2010 By

Dpkg got rid of Perl

Let’s start with the interesting part and the great news: dpkg 1.15.8 (to be uploaded soon) will no longer need perl! After my changes to rewrite update-alternatives in C, Guillem recently pushed the rewrite of dpkg-divert/mksplit in C. Please test it out (binary package for i386 or .dsc).

This is rather exciting news for those who would like to use dpkg in embedded contexts. And it’s great to see this completed in time for Squeeze. In Squeeze+1, we might go one step further and merge cdebconf, the C replacement for debconf.

I got rid of some recurring administrative tasks

I have been administrating the Alioth server since its inception (see the announce I sent in 2003) but I’m no longer enjoying the day-to-day administrative work that it represents. That’s why I just retired from the team. We recently recruited Tollef Fog Heen so the number of admins is still the same (that said, Alioth could benefit from some more help, if you’re a DD and interested, drop a mail to admin@alioth.debian.org or come to #alioth).

Same goes for the collab-maint project. I have dealt with hundreds of requests to add new contributors to the project since it’s the central repository where all Debian developers have write access and where they put the VCS for their packages that do not belong to a more specialized team. The new administrator that will approve the requests is Xavier Oswald and he’s doing the work under the umbrella of the New Maintainer’s Front Desk.

The future

I will continue to spend the same amount of time on Debian, the time freed will quickly be reallocated to other Debian and free software related projects. In fact, I even anticipated a bit by launching Flattr FOSS last week but that’s a relatively simple project. :-)

The other projects that will never all fit in the freed time: I want to spend more time working on dpkg. I do plan to blog more often too, but I’m sure you’ll notice that yourself soon. I would like to see my Debian book translated into English (another post coming on the topic sometimes soon). In my dreams, I could even start yet another software project, I have some ideas that I really would like to see implemented but I don’t see how that could fit in this year’s planning… unless I can convince someone else to implement them! Maybe I should blog about them.

Filed Under: Debian News Tagged With: , , ,

Rewriting update-alternatives in C

May 27, 2010 By

Among the goals listed in dpkg’s roadmap, there’s the C rewrite of the remaining perl scripts provided by the dpkg binary package (dpkg-dev is not concerned, it will remain a collection of perl scripts). Of the remaining scripts, update-alternatives was the largest piece of code (~1100 lines of perl) and I started converting it to C a few weeks ago (based on preliminary work of Guillem). It’s now 2200 lines of C…

Thanks to the relatively extensive test-suite that I wrote last year, I’m relatively confident that this new update-alternatives won’t break your system. That said, it still needs some real-life usage to ensure everything is really ok (and users actively trying to break it are even better). Thus I would be glad if you could try it out ( binary package for i386 or .dsc) and report back to debian-dpkg@lists.debian.org.

The rewrite of the 2 other remaining scripts is almost completed in a branch of Guillem. Hopefully this can be our last project completed in time for Squeeze as far as dpkg goes. It would be a great achievement for people that would like to use dpkg in embedded environments and avoid perl due to its size.

Note: nobody sponsored that work. But it’s not too late :-)

Filed Under: Debian News Tagged With: ,

Debian related goals for 2010

January 9, 2010 By

Here’s stuff that I’d like to do this year, more or less by decreasing order of importance:

  • translate my Debian book into English and get it published;
  • finish the cleanup of the perl API in dpkg-dev in order to create libdpkg-perl;
  • create dpkg-buildflags to export default build flags that packages should use (and get rid of the code setting those environment variables in dpkg-buildpackage), needed to properly fix #489771;
  • ensure the new source formats continue to gain acceptance by improving whatever is needed;
  • design a generic vcs-buildpackage infrastructure to be integrated in dpkg-dev. This design will probably happen through a DEP (Debian Enhancement Proposal) to ensure we have had proper discussion before someone gets to the implementation;
  • continue fixing dpkg bugs faster than they are reported;
  • enhance our infrastructure to ease interaction between contributors and to have a better view of how each package is maintained (see my last blog entry on this topic);
  • update the developers-reference where needed and fix some of the numerous wishlist bugs;
  • rewrite in C the last perl scripts provided by the dpkg binary package (update-alternatives/mksplit mainly, for dpkg-divert there’s a preliminary patch available already) so that it’s easier to build a minimal system without perl-base;
  • integrate the 3-way merge tool for Debian changelogs in dpkg-dev;

All of this probably doesn’t fit in my free time (being a father since last month does not help increasing my free time :-) ), so if you’re interested in seeing one or more of those projects completed, and if you know some person/company that could sponsor them, get in touch with me!

Filed Under: Projects Tagged With: , ,

5 years of Freexian

January 5, 2010 By

5 years ago I founded my own company Freexian SARL with the goal to make a living out of my free software experience. I marketed the company as being specialized on the Debian distribution in the hope to combine my Debian work and my professional work.

Given that Freexian is still alive I think I met the first goal. My free software experience allowed me to complete many projects: a large number of development projects for embedded devices running a custom Linux distribution (usually built with debian udebs), the development of a Debian derivative (SLIS) and some recurring tasks of remote system administration.

However, even if I use Debian daily for all my work, very few of the projects that I complete for customers have direct results in terms of improvements for Debian (except some bugreports and some related fixes). And even when I’m able to contribute something back to Debian, it’s usually not in areas that I care about.

My focus within Debian is on the technical and organizational infrastructure of the project: as a dpkg/dpkg-dev maintainer I try to improve the packaging infrastructure, as a QA member I maintain the Package Tracking System to ease collaboration, as an Alioth admin I ensure all DD can host VCS repositories for their Debian related projects, as a developers-reference co-maintainer I try to share good packaging practices, etc. Given this bias, it’s difficult to find customer projects that would let me contribute in those areas. Thus I think I need to try another approach: the simplest solution would be to find sponsors for some of my own Debian-related projects (if you have something else to suggest, please leave a comment — either in the blog or by mail).

That said finding sponsors looks like a difficult task in itself. While I can imagine (for example) a company using Debian on embedded devices that would like to sponsor the rewrite of update-alternatives in C in order to get rid of the perl dependency in the dpkg package (if you know such a company, get in touch with me!), I don’t see who would have an interest in sponsoring the time that I need to contribute new sections to the developers-reference manual. But who knows… maybe I should just try and publicly solicit sponsorship for some of the projects that I care about. In any case, suggestions and comments are welcome!

Filed Under: Stories of life Tagged With: , ,

New source formats allowed in testing/unstable

November 2, 2009 By

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.

Filed Under: Debian News Tagged With: , ,

3-way merge of Debian changelog files

October 8, 2009 By

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.

Filed Under: Debian News Tagged With: , , ,

New source package formats: call for tests

March 16, 2008 By

During the last weeks I’ve been busy working on adding support of new source package formats to dpkg-source (the wig&pen format, a wig&pen variant based on quilt, Joey’s git based format integrated by djpig, …). I just reached the state where I believe the code is mostly ready to be merged in the master branch. Thus I would like some external testing and feedback.

Grab and install the package here and try building packages with dpkg-source "--format=3.0 (quilt)" -b mypackage (or any other new format). You can find more infos in the call for test on debian-dpkg (here and here). If you find regressions, please report them.

If you want to grab the latest sources, use git clone git://git.debian.org/git/dpkg/dpkg.git dpkg; cd dpkg; git checkout -b sourcev3 origin/sourcev3.

Filed Under: Action Tagged With: ,

This time of the year again

March 3, 2008 By

Yes, it’s DPL election time again. On the good side, we’ll spend less time this year than we used to thanks the constitution change. On the bad side, it seems that almost nobody is interested to run for DPL (even HE is not sure yet!).

I’ve been relatively satisfied by the work done by sam (although one can always do better) and it looks like many share this feeling… and when this is the case, we just expect the DPL to run again. But sam clearly said that he won’t run again. What a pity.

I also don’t plan to run this year[1] but I’m always interested in leadership issues and I’d gladly be part of a DPL team. Hopefully someone will provide such an alternative on the ballot this year.

Right now, I’m more in the mood of implementing some real changes (like the symbol based dependencies that I added to dpkg-shlibdeps) instead of trying to convince others to do them. When you associate this to some support of the leadership in place, it can give very good results.

Now back to real work, I still have to test and polish the dpkg-source rewrite which adds support of several brand new source package formats. Feel free to check out our progress in the sourcev3 git branch.

[1] Feel free to convince me otherwise by adding some comments here.

Filed Under: Opinions, Stories of life Tagged With: , ,
Newer Posts »