It’s been a while since my last patches for GNU/kFreeBSD, and Christoph kindly took over the kfreebsd-* build daemons from me some time ago, but still: smile of the day. Thanks, Russ.

This is the tenth “Debian XSF News” issue. It is basically meant to be a follow-up to DXN#9.

1. I completed the addition of the Sinhala language, and also dealt with big changes on the xkb-data (a.k.a. xkeyboard-config) side, as explained by Sergey Udaltsov.

Protocol:

• [KiBi] x11proto-core: the upload to experimental was a bit overcautious, so upload again → unstable.

Data:

• [KiBi] xkb-data 2.1: been in experimental for a while, changes were announced to debian-boot@ → unstable.

• [KiBi] xkb-data 2.2.1: new upstream release, which breaks older libx11-6; also announced to debian-boot@ → experimental.

Library:

• [KiBi] libx11: new upstream release, adding support for Sinhala → unstable.

• The Graphical Installer started receiving improved portability. There were a few patches floating around adding udebs for generic drivers for non-Linux architectures. I cleaned them up a bit (especially on the vesa side, getting rid of libdrm entirely), got them test-built on a kfreebsd-amd64 box, while Samuel Thibault was doing the same on a hurd-i386 box. I raised the topic on debian-boot@, debian-bsd@, and debian-hurd@, mentioning the remaining steps.

Drivers (all accepted by ftpmasters after a tiny trip to the NEW queue):

• [KiBi] xserver-xorg-input-keyboard → experimental.

• [KiBi] xserver-xorg-input-mouse → experimental.

• [KiBi] xserver-xorg-video-vesa → experimental.

• Here are some other packages which got updated.

Applications:

• [Julien] x11-xserver-utils: Julien did everything for DSA-2213 → unstable, squeeze-security, lenny-security.

Library:

• [Chris,Julien,KiBi] mesa 7.10.1: long-awaited upload, finally checked, built, and uploaded → experimental.

• Finally, let’s mention migration to testing (from now on I’ll use testing instead of wheezy so that it’s clear it’s about week after week migrations to the testing distribution, rather than our final plans for the next stable release). After a while, and thanks to some hand-holding from our nice release managers (hi, Adam!), linux-2.6, libdrm, mesa, xorg-server, and several dozen drivers migrated to testing. Yay!

• As a consequence, some other packages got updated shortly after the successful britney run (because they were prepared right before, just in case).

Libraries:

• [KiBi] libdrm: replace 2.4.23 with 2.4.24 (which was in experimental previously) → unstable.

• [KiBi] mesa: new stable release, 7.10.2 supersedes both 7.10 in unstable and 7.10.1 in experimental (see above) → unstable.

• [KiBi] pixman: new development snapshot, 0.21.6 comes from experimental and supersedes 0.21.4 → unstable.

Drivers:

• [KiBi] xserver-xorg-input-vmmouse: new upstream release, functionally the same as the last release candidate → unstable.

• [KiBi] xserver-xorg-video-ati: new upstream release, was waiting for the migration to happen, see second bullet of DXN#9 → unstable.

• [KiBi] xserver-xorg-video-intel: new upstream release, same story as for the ati driver → unstable.

(Disclaimer: this post is not about G.I.)

Graphical installer

Josselin posted his thoughts about g-i, and given at least the first parts sound doable, I’m tempted to have a look at dealing with the needed udebs. Never touched anything like this before, but oh well, one learns every day. Time to learn a bit more about X11 as well.

It looks like generating a new mini.iso (using d-i’s trunk) wasn’t that difficult, so hopefully once I’m done with a few udebs, it should be possible to add them to this image and make sure those are usable, at least when loaded manually.

Once that finished, gluing everything together is probably going to be another story, but hopefully that won’t be impossible.

Unrelated stories

• Thanks to DSA (especially weasel), kfreebsd-* now have DSA-admin’d experimental buildds. Aurélien took care of setting them up; they managed to go through all experimental packages, and bugs were filed accordingly. Some were just marked as failed, usually with “Needs porting.”, especially when there were no regressions with respect to what was previously built on those architectures (as a reminder: out-of-date means serious, uncompiled means important).

• On a related note, this buildd.d.o form makes it possible to browse the build logs for various suites. See the dda@ announce for details.

• It looks like I’m going to stop dealing with Java at all: #557230. Thanks to Gabriele Giacone for taking care!

• It also looks like I’m done with Python packages as well.

• A new module-assistant package got uploaded, which should fix issues with newer kernel versions (ya can haz detailz). I’m wondering whether backporting it through backports.org from time to time would be of some help to anyone? It is (or should be) directly installable in a lenny environment, but maybe people would like it to be directly available once the lenny-backports repository enabled? Mail/wishlist bug welcome if you want it.

• If you received some signatures from me lately… no, I wasn’t pretending I met you at LCA or whatever, but that was from Cáceres (Hi Penny! ;)). Key rollover being thought of.

Recipe for a smile:

1. Notice digikam's FTBFS on GNU/kFreeBSD.

2. Work on a patch, send it to the BTS.

3. Receive the ACK from the BTS.

4. Receive the upstream commit notification a dozen of minutes later.

Denightening lights or enlightening nights or nightening delights…

Kudos, Luka.

Extremadura

• DebConf’9 timing was really nice, allowing for following talks, getting things done, and meeting people.

• Upper talk room’s speaker’s chairs aren’t as comfortable as they seem; First row seats are OK to sleep on, though.

• Guards actually don’t want people to sleep there, and can even chase people in hacklabs to make sure they go sleep in the right venue; Funny wake-up, with a lot of Spanish, and little to be understood (note to self: try and get some Spanish basics before being in the plane for Spain next time).

• Very sympathetic guard anyway, apparently (read: still in Spanish) saying how sorry she felt for that. And even hugging and kissing when one was leaving. Spanish people, you rock.

• Day trip totally rocked, as well as the formal dinner. Orga-team \o/.

• Totally in love with the Bosnian bid for DebConf’11. Let’s hope they’ll keep on doing a great job.

• Oh, and decided to get another NM. Very funny to sit next to each other and mail NM Q&A every few hours.

Packages

• I requested assistance for the src:graphviz package. While being a quite interesting technical challenge back when I started packaging various things, it is currently quite sucking my time, and I would really love someone else step in. I guess the RFH (#536245) will be turned into an RFA quite soon.

• Pabs orphaned Synfig-related packages src:etl, src:synfig, src:synfigstudio. Given I don’t currently plan to dive more into them, I don’t feel like I would do a great job by keeping on maintaining them alone.

• The same goes for src:luxrender. It’s RC-buggy but given I may orphan it as well, I’m not really keen on uploading a new upstream release to fix it. On a related note, I might have spent some time on the src:aqsis package but again, if one is not a very regular user, what’s the point?

• I’m also quite wondering what to do with Blender. Details can be found in my mail to debian-devel@.

It’s quite sad to let some packages go, especially some which are quite popular, and which have made me dream for years (graphics stuff interested me back when I first touched a computer already); But well, time is a scarce resource. :(

GNU/kFreeBSD

• Taking care of buildds is a really interesting experiment.

• The new wanna-build feature called edos-builddebcheck is really appreciated on kfreebsd-*; most of the time, I’ve been setting dep-waits because of missing and/or uninstallable packages. Now it seems that all that stuff is being handled automatically, and I only have to concentrate on the successful build logs, and on the failed ones due to needed porting, broken build systems, etc. EPIC WIN, if you ask me.

• d-i port seems to be on good tracks, and having weekly reports is great.

• We’re still waiting for util-linux in unstable but once that done, we should get hal (thanks to a close cooperation with both its Debian maintainer and upstream), which should make it possible to get a lot of packages from the X11, GNOME, and KDE stacks. Once that done, a status update might be sent to d-d-a@.

In the next hours or even days, I might be quite verbose so that people can have a tiny idea of what porting looks like. Or eventually what being in a bootstrapping phase looks like.

I love it when a plan comes together!

One important goal was trying to get sbuild installable within sid. Of course it is already installed on the buildds, but having it handy should help developers hack on their own boxes.

The chain of dependencies wasn’t very long, but still:

sbuild → libsbuild-perl           [not installable]
libsbuild-perl → schroot          [not built]
schroot → libboost-dev            [not built]
libboost-dev → libboost1.38-dev   [not built]
libboost1.38-dev → libopenmpi-dev [not installable]

First of all, I filed #535202 so that libibverbs can be built on GNU/kFreeBSD, which was needed because libopenmpi-dev depends on one of its binaries. We weren’t sure it was appropriate, though, since it looked like pretty much Linux-specific. So I filed #535225 to get installability issues of libopenmpi-dev on non-Linux architectures fixed (by excluding libibverbs-dev from the Depends on those architectures, matching what was already done for the build dependencies). A fixed package was uploaded in some hours only!

In the meanwhile, I gave mpi-defaults a shot, using the locally-built libopenmpi-dev package. It could have gone flawlessly if I didn’t stumble upon an FTBFS due to a toolchain change. #535230 got filed accordingly, and fixed some hours later too!

Building boost1.38, then boost-defaults, and finally schroot went smoothly, and all the above-mentioned packages are now installable on the porter box. And thanks to the responsiveness of those maintainers, plus some extra bits of wanna-build magic (give-backs using dep-waits), packages got tried (and built successfully) when their build dependencies became available on the buildds.

In the meanwhile, the maintainer of libibverbs confirmed that it’s not worth building useless binaries on non-Linux architectures, so I closed #535202 and opened a bug against buildd.debian.org instead, requesting the addition of libibverbs to the Packages-arch-specific list (aka. P-a-s): #535360.

Now, there are still some issues when trying to use sbuild, but it’s at least installable and people can try it out.

Working on another package also made me noticed that there was a bug in a FreeBSD kernel header: #535243. The fix is already in the repository, and it looks like I’m going to be added to the Uploaders of the kfreebsd-kernel-headers source package so that it gets uploaded quickly.

I hate impromptu toolchain-related FTBFSes

While I’m all for making tools as strict as possible (especially build-related tools), I really think it would be very nice for toolchain maintainers to deliver advance warnings.

GCC folks do that perfectly: File bugs, provide patches, raise severity when the new version is around, NMU if needed.

Dpkg folks prefer making a parser stricter, without caring at all which packages they might break. The previously-mentioned mpi-defaults was one of them.

The list of FTBFSes triggered by dpkg 1.15.3 (at least, the ones I spotted using 3 basic UNIX commands and spending a few seconds in lintian’s lab on lintian.debian.org, see how difficult that was!) follows: #535230, #535276, #535279, #535283, #535284, #535287, #535292, #535297, #535299, #535301, #535303, #535304, #535306, #535310, #535312 (all of them with tested patches because I didn’t feel like being lazy and shrugging over IRC after being notified).

At least it’s not about trying to sneak *FLAGS handling into a frozen testing this time. But that’s still annoying.

Would someone guess the link between:

• What mail client are you using?

• Are you around during the next two weeks?

After answering those, I’ve been offered to take care of the GNU/kFreeBSD buildds, which is yet another experience. \o/

Quite a good timing since I’ve recently tried to get involved with the GNU/kFreeBSD ports again, prodding maintainers, uploading fixed packages (usually thanks to Petr Salinger’s patches), or providing patches myself.

\o/

After some hour spent on the sources, understanding and patching them, a patch against debootstrap 1.0.1 is available, so that debootstrap can handle an extra suite, which is unreleased for GNU/kFreeBSD. It is then possible to specify some packages to fetch from there, along with the mirror for these extras (defaults to the normal mirror) and the suite name (which defaults to unreleased).

What is needed is then to specify the appropriate extra packages. A first guess is to use the Priority: required packages from the unreleased Packages file, pull the dependencies (a tiny script was forged for that) from unreleased (those from unstable aren't considered at the moment, but could be added easily).

The problem is that some packages from unstable depend on packages from unreleased, which implies one has to track them manually. For the time being, spotted packages are the following:

• ifupdown: depends on net-tools
• debian-archive-keyring: depends on gnupg

Once their own dependencies have been added too, one gets the following message but there's still to do.

I: Base system installed successfully.

For example, /etc/apt/sources.list and /dev are empty, and since the base system has been successfully installed, the logs in /debootstrap have been deleted. Time to use the --keep-debootstrap-dir option, and to dig into /debootstrap/debootstrap.log.

Some messages related to work-needing stuff:

Unpacking coreutils (from .../coreutils_5.97-5.3_kfreebsd-i386.deb) ...
Use of uninitialized value in string eq at /usr/sbin/dpkg-divert line 224.
Use of uninitialized value in length at /usr/sbin/dpkg-divert line 224.
Use of uninitialized value in length at /usr/sbin/dpkg-divert line 224.
Use of uninitialized value in length at /usr/sbin/dpkg-divert line 224.
No diversion `any diversion of /usr/share/man/man1/md5sum.textutils.1.gz', none removed
Use of uninitialized value in string eq at /usr/sbin/dpkg-divert line 224.
Use of uninitialized value in length at /usr/sbin/dpkg-divert line 224.
Use of uninitialized value in length at /usr/sbin/dpkg-divert line 224.
Use of uninitialized value in length at /usr/sbin/dpkg-divert line 224.
No diversion `any diversion of /usr/bin/md5sum.textutils', none removed

Setting up makedev (2.3.1-83) ...
Results undefined on non-Linux systems, aborting MAKEDEV invocation.
Results undefined on non-Linux systems, aborting MAKEDEV invocation.
/bin/chmod: cannot access `/dev/tty[0-9]*': No such file or directory
Results undefined on non-Linux systems, aborting MAKEDEV invocation.
Results undefined on non-Linux systems, aborting MAKEDEV invocation.
Results undefined on non-Linux systems, aborting MAKEDEV invocation.
Results undefined on non-Linux systems, aborting MAKEDEV invocation.
Results undefined on non-Linux systems, aborting MAKEDEV invocation.
Results undefined on non-Linux systems, aborting MAKEDEV invocation.
Results undefined on non-Linux systems, aborting MAKEDEV invocation.
Results undefined on non-Linux systems, aborting MAKEDEV invocation.
Results undefined on non-Linux systems, aborting MAKEDEV invocation.
Results undefined on non-Linux systems, aborting MAKEDEV invocation.
Results undefined on non-Linux systems, aborting MAKEDEV invocation.
Results undefined on non-Linux systems, aborting MAKEDEV invocation.
/var/lib/dpkg/info/makedev.postinst: line 47: [: 6.2-1-686: integer expression expected

Setting up initscripts (2.86.ds1-38.1) ...
mount: invalid option -- -
usage: mount [-adflpruvw] [-o options] [-t ufs | external_type]
       mount [-dfpruvw] special | node
       mount [-dfpruvw] [-o options] [-t ufs | external_type] special node

Setting up ifupdown (0.6.8) ...
ifupdown.postinst: Warning: No 'iface lo' definition found in /etc/network/interfaces
ifupdown.postinst: Warning: No 'auto lo' statement found in /etc/network/interfaces

Setting up cron (3.0pl1-100) ...
Adding group `crontab' (GID 101) ...
Done.
Starting periodic command scheduler: crond
Warning: Fake start-stop-daemon called, doing nothing
.

Setting up man-db (2.4.4-3) ...
Building database of manual pages ...
mandb: warning: /usr/share/man/man8/clock.8.gz is a dangling symlink

The whole installation log is also available, along with the installation parameters, stored in a tiny shell script holding all the parameters I used. Note that you'll have to switch from aurel32's mirror to gnuab.

As for the sources.list file, it is sufficient to put there the following, which is also documented on the GNU/kFreeBSD wiki page on the Debian wiki:

deb http://ftp.gnuab.org/debian unstable main
deb http://ftp.gnuab.org/debian unreleased main

The patch certainly needs some polishing (in particular the scripts/debian/sid part, a case would be far better than several if's), and some cleanup (at least one commit was done only to make editing with a buggy Emacs shell-mode easier). A git repository is available: <git://alioth.debian.org/~kibi-guest/debootstrap.git>.

Thanks to Petr, we've got a tiny list of orphaned packages which can be QA-uploaded, so as to fix FTBFS on GNU/kFreeBSD.

debdiffs are available on my personal space on alioth, as well as source packages

FTBFS bugs closed in these QA uploads:

• axel: Debian bug #413856 (and improved copyright file: Debian bug #302948);

• plotmtv: Debian bug #414133;

• wmmemload: Debian bug #415593;

• wmmemmon: Debian bug #415597.