Alternative view: by date.
This is the tenth “Debian XSF News” issue. It is basically meant to be a follow-up to DXN#9.
I completed the addition of the Sinhala language, and also dealt with big changes on the
xkeyboard-config) side, as explained by Sergey Udaltsov.
- [KiBi] x11proto-core: the upload to
experimentalwas a bit overcautious, so upload again →
- [KiBi] libx11: new upstream release, adding support for Sinhala →
- [KiBi] x11proto-core: the upload to
The Graphical Installer started receiving improved portability. There were a few patches floating around adding
udebsfor generic drivers for non-Linux architectures. I cleaned them up a bit (especially on the
vesaside, getting rid of
libdrmentirely), got them test-built on a
kfreebsd-amd64box, while Samuel Thibault was doing the same on a
hurd-i386box. I raised the topic on
debian-hurd@, mentioning the remaining steps.
Drivers (all accepted by ftpmasters after a tiny trip to the
Here are some other packages which got updated.
x11-xserver-utils: Julien did everything for DSA-2213 →
- [Chris,Julien,KiBi] mesa 7.10.1: long-awaited upload, finally checked, built, and uploaded →
Finally, let’s mention migration to
testing(from now on I’ll use
wheezyso that it’s clear it’s about week after week migrations to the
testingdistribution, 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!),
xorg-server, and several dozen drivers migrated to
As a consequence, some other packages got updated shortly after the successful britney run (because they were prepared right before, just in case).
[KiBi] libdrm: replace 2.4.23 with 2.4.24 (which was in
[KiBi] mesa: new stable release, 7.10.2 supersedes both 7.10 in
unstableand 7.10.1 in
experimental(see above) →
[KiBi] pixman: new development snapshot, 0.21.6 comes from
experimentaland supersedes 0.21.4 →
[KiBi] xserver-xorg-input-vmmouse: new upstream release, functionally the same as the last release candidate →
[KiBi] xserver-xorg-video-intel: new upstream release, same story as for the
(Disclaimer: this post is not about G.I.)
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
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.
Thanks to DSA (especially weasel),
kfreebsd-*now have DSA-admin’d
experimentalbuildds. Aurélien took care of setting them up; they managed to go through all
experimentalpackages, 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:
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
lennyenvironment, but maybe people would like it to be directly available once the
lenny-backportsrepository 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.
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
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.
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
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?
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.
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-waitsbecause 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-iport seems to be on good tracks, and having weekly reports is great.
We’re still waiting for
unstablebut 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
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
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
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
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!
boost-defaults, and finally
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
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
buildd.debian.org instead, requesting the addition of
libibverbs to the
Packages-arch-specific list (aka.
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
kfreebsd-kernel-headers source package so that it gets
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!)
(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.
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.
After some hour spent on the sources, understanding and patching them,
a patch against debootstrap
debootstrap can handle an extra suite, which is
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
What is needed is then to specify the appropriate extra packages. A
first guess is to use the
Priority: required packages from the
Packages file, pull the dependencies (a tiny script was
forged for that) from
unreleased (those from
considered at the moment, but could be added easily).
The problem is that some packages from
unstable depend on packages
unreleased, which implies one has to track them manually. For
the time being, spotted packages are the following:
Once their own dependencies have been added too, one gets the following message but there's still to do.
I: Base system installed successfully.
/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
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.
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
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.
FTBFS bugs closed in these QA uploads: