i've been on an IPv6 kick recently, getting dual-stack systems up and working for a bunch of folks.I'd like to make some of these services reachable by IPv6-only clients. this suggests that i need a range of details sorted out, but i think the one piece left for me is the glue records for the nameservice. i use in-bailiwick nameservers for DNS where possible, which means i want mandatory glue records. that is, the primary namserver for example.org is probably something like ns0.example.org, which means that the org nameservers themselves need to store not only the NS record, but an A record that corresponds to the name pointed to by the NS. But for IPv6-only clients that do their own name resolution, i need AAAA glue records, and i haven't yet found a registrar that will push AAAA glue records for the same names as the existing A glue into the org zone. Do you know of a registrar that will do this?I've tried:

dotster

Dotster seems to only allow IPv4 glue to be entered on their Register Nameserver config page (needs a dotster login to see it). They haven't yet yet responded to my query through their support web form about submitting AAAA glue

gandi

gandi at least offers the opportunity to enter AAAA glue, but apparently can't let me have both AAAA and A glue for the same name. A note to their support team got me a response that this is planned for Q1 or Q2 of 2011.

Any suggestions for reasonable registrars that offer this today? Am i being silly in wanting AAAA and A glue for the same names? i note that the root zone and the org zone both offer A and AAAA records for each of their dual-stack nameservers. You can check for yourself:

 dig @a.root-servers.net ns org
 dig @a.root-servers.net ns .

if i don't go for dual records, i could instead use gandi and go with distinct names for the v6 and v4 servers, like this:

;; QUESTION SECTION:
;example.org.				IN	NS
;; AUTHORITY SECTION:
example.org.      172800	IN	NS	a.ns.example.org.
example.org.      172800	IN	NS	b.ns.example.org.
example.org.      172800	IN	NS	c.ns.example.org.
example.org.      172800	IN	NS	d.ns.example.org.
;; ADDITIONAL SECTION:
a.ns.example.org. 172800	IN	A	192.0.2.3
b.ns.example.org. 172800	IN	A	192.0.2.4
c.ns.example.org. 172800	IN	AAAAA	2001:db8::3
d.ns.example.org. 172800	IN	AAAAA	2001:db8::4

But of course what i really want is this:

;; QUESTION SECTION:
;example.org.				IN	NS
;; AUTHORITY SECTION:
example.org.      172800	IN	NS	a.ns.example.org.
example.org.      172800	IN	NS	b.ns.example.org.
;; ADDITIONAL SECTION:
a.ns.example.org. 172800	IN	A	192.0.2.3
a.ns.example.org. 172800	IN	AAAAA	2001:db8::3
b.ns.example.org. 172800	IN	A	192.0.2.4
b.ns.example.org. 172800	IN	AAAAA	2001:db8::4

My concern about this is if some IPv4-only system gets a list like the first one, and decides to use c.ns.example.org or d.ns.example.org, which doesn't have an A record at all. That would be a silly implementation, of course. but uh, we have a lot of silly implementations of things out there.Feedback welcome!Tags: dns, ipv6

The Debian Release Team has made a status update on Debian 6.0, Squeeze . They are proud to report that Debian is moving towards the release like a glacier: inevitably and unstoppingly .

Squeeze is almost in its final state: testing of the installer and upgrades are welcome. Once the latest version of the Debian Installer is added, a deep freeze will begin, with minimal changes allowed while the remaining bugs are fixed. Your help is welcome in:

• processing installation/upgrade reports,
• translating of the debian-installer, (read latest translation status update)
• and fixing release-critical bugs.

There are two upcoming bug squashing parties you can join: Bern, Switzerland, November 27-28; and Boulogne-Billancourt, France,December 4-5.

My telco Three have just offered me a deal on getting a new phone a couple of months earlier than my contract was supposed to expire, presumably they have some competition and want to get me locked into another 2 year contract a couple of months before anyone else has the chance.My current phone is a LG U990 Viewty [1] which I am reasonably happy with for the regular phone and camera functionality (apart from it being too slow to take a photo), it s on a $29 per month plan. I also have a 3G modem which is on a $15 per month plan for 1G of data per month for a total cost of $44 per month. As new phones have advanced client functionality (ssh, IMAP, etc) and have Wifi support for providing net access to a laptop there seems to be less need to have a separate phone and modem. So I am considering getting a high-end phone to replace the phone and modem, so while I don t want to pay a lot more than I currently pay, a $49 contract would be quite affordable and a $59 contract is something I can consider.What I need is a system with a good ssh client implementation, a high resolution screen (800*480 or better), preferably a slide out keyboard and an option to use a Bluetooth keyboard.The best option for the OS seems to be Android as it s based on Linux, it s moderately open, and it has a good range of applications. The Nokia N900 has been recommended based on features but a friend had a bad experience with a N900 that broke and didn t get good warranty support. Also the N900 doesn t have a digital compass (so can t do augmented reality). While I m primarily buying a phone for making phone calls, using the net, and being a ssh client I want to be able to do cool things like do Google searches on things that I photograph and have an annotated star map when I point my phone at the sky. Also as I m not using Windows or Apple phones for obvious reasons that leaves Android phones as the only suitable phones that are on offer from my Telco.I have checked some options for buying a grey-market phone, given that I need to get a more expensive phone contract to have the voice and data access I need the cost of buying a grey-market phone and having a no-phone contract would be unreasonable. So selecting a phone that s on offer by Three/Vodaphone seems to be the best option. Moving to another telco would be inconvenient as I would have to convince the relatives that I call often to switch as well (I get free calls to other Three/Vodaphone customers).I previously listed some phones that seemed good without regard as to where I could buy them [2] and some people wrote some really interesting and informative comments (thanks a lot!). But after considering all the options it seems that the costs of the various options force me to choose something that Three offers.Currently the best option from Three for an Android phone seems to be the HTC Desire HD [3]. It has a 800*480 screen, an 8MP camera with face-detection and geo-tagging, wifi, an accelerometer, GPS, and a digital compass. It also runs Android 2.2 (the latest release). Generally it has everything I want apart from a slide-out keyboard. It seems that Bluetooth keyboards are about $100 each, so I could buy such a keyboard and have options of taking just the phone, the phone and keyboard, or phone and laptop depending on how much I can carry and what I expect to be doing.Three PricesThe Desire HD is free on a $59 plan, or costs $15 per month on the $29 plan. So for $44 per month (the same as what I spend now) I can get a Desire HD! The down-side is that the $29 plan only allows 200MB of data per month and has an excess data fee of $0.50 per meg. My average usage has been about 300MB per month, I could reduce this a bit but I do occasionally have a month where I need a lot of data transfer. For an extra $8 per month I can get an additional 500MB of data transfer. That would give me a total cost of $52 per month for my phone, and I could get the same phone for my wife for $44 per month (I doubt that she would use the 200MB of data included). That would take a typical Three bill from $73 to $96.I might just wait a few months. The Viewty and 3G modem combination is working reasonably well, presumably there will be some better deals if I wait a while. At least now after considering all the options I could find and determining that a Desire HD from Three is the best option for me I can now evaluate any new options by comparing them to that.

• [1] http://etbe.coker.com.au/2009/05/31/lg-u990-viewty/
• [2] http://etbe.coker.com.au/2010/10/08/choosing-an-android-phone/
• [3] http://en.wikipedia.org/wiki/Desire_HD

I received a few emails from my blog post about my MythTV dilemma. Suggestions ranged from using VGA to DVI to HDMI adapters, to getting different TVs that still have VGA connectors, to getting an older NVIDIA card off eBay that has lower power requirements. Firstly, VGA is dead. It's time to make the move. I don't think VGA for a TV the size I'm looking at is ideal for HD anyway. I'm pretty much fixated on the Sony TV as well, because I want to get Google TV. So I need HDMI. Similarly, I suspect that the picture quality of something run through a VGA to HDMI conversion will be similarly shite, so I'm not too keen on that option, although it would tide me over initially, so I'll look into that further. Another suggestion was the fit-PC2, which was something I was already aware of, but I'd heard terrible things about the general Linux support for the graphics adapter. I did some more research into the Boxee Box, (it really is new, it's only been out for 6 days) and it appears to have the same video chipset as the fit-PC2, which seems rather unfortunate. But then, if the Boxee Box is running Linux, then they've obviously got a driver, so the question is how easy is it to transplant this driver from the Boxee distro to, say, Debian? I'm curious enough to place an order soon. Anyone got any interesting Poulsbo-on-Linux war stories they want to share? I know it makes Matthew Garrett sad.

I have finished the SCRAM implementation in GNU SASL. The remaining feature to be added were support for the enhanced SCRAM-SHA-1-PLUS variant instead of just the normal SCRAM-SHA-1 mechanism. The difference is that the latter supports channel bindings to TLS, which makes it possible to detect man-in-the-middle attacks even if TLS is not used with server authentication. In GnuTLS we recently added an API for applications to extract channel bindings, which you will need to use in order to use SCRAM-SHA-1-PLUS. I announced the experimental version 1.5.4 release together with a writeup on how to test it. With this, our support for SCRAM should be complete.

I have been experiencing pains and discomfort for some time now due to a cyst inside one of my left sinuses. Next week I am scheduled for an operation to remove it. After that I will have another operation in order to reduce (but hopefully eliminate snoring).

I am a little scared. I am especially scared about the possibility the anestesic would numb me but not turn me unconcious of the pain.

Squeeze is frozen for some time now and will be released when it's ready, of course. Currently, I have at least two packages that have reported bugs, but it seems that they are making no progress. The first package is BackupPC.One of the bugs is #600654 and the other is #601843. Where as the first is just a cosmetic bug displaying filesystem usage of the backup volume, the other seems to have a functional impact: the backup pool doesn't get cleaned up properly each night. Sadly the maintainer seems a little bit absent, so maybe someone else can do a NMU to get BackupPC into shape for release? Would be nice, though... ;-) The other package is spamassassin or more exactly libnetaddr-ip-perl and bug #601601. Whereas the BackupPC maintainer is rather quiet, there's lot of activity for the other bug but still I get these errors when running Spamassassin by cron:

netset: cannot include 0:0:0:0:0:0:0:1/128 as it has already been included
netset: cannot include 0:0:0:0:0:0:0:1/128 as it has already been included

Although I'm confident that #601601 will be solved soon, I don't really know about the BackupPC bugs, except writing additional info mails to those bugs with "add me!" comment. UPDATE 17.11.2010:
libnetaddr-ip-perl (#601601) seems to be fixed now.

The Debian Women project is pleased to announce the -start of a series of training sessions to be held via IRC in the Debian Women IRC channel, #debian-women on irc.debian.org

The first session has been scheduled for Thursday, 18th November at 20:00 UTC. Lars Wirzenius, will give an introductory lesson titled Introduction to Debian Packaging .

The main goal of this initiative is to encourage more people, specifically women, to contribute to Debian while introducing them to different aspects of the Debian Project. Topics will span a wide range of subjects related to daily Debian maintenance efforts as well as advanced tasks and are open to everybody, regardless of gender or previous involvements in the community.

Future sessions will be held on a regular basis, and will cover collaborative maintenance with git, Python modules and applications packaging, and many more. Please visit the Training Sessions wiki page regularly to check the up-to-date agenda and follow our group on identi.ca. You may also refer to the wiki to suggest new topics or sign up yourself as a trainer: we are always looking for more people to share knowledge and complete the schedule, so don t be shy!

For further information about the Debian Women project, please visit the Debian-Women website or send mail to the Debian Women mailing list.

Developers are not usually the right people to write documentation, but in an effort to encourage more Debian folk to consider Emdebian, I'm starting an intermittent series of blog posts to describe how Emdebian works and how it fits with Debian. Emdebian has a variety of ideas and experiments but the principle distribution, to be released alongside Debian Squeeze, is Emdebian Grip. This post, I'll cover the basic stuff. Feel free to let me know if there are particular issues you'd like covered. In particular, if the documentation on the Emdebian Grip website needs improving, let us know.
What's Emdebian Grip all about?
Simply a smaller Debian. Smaller packages, smaller downloads, smaller sets of packages, smaller installation sizes and smaller update sizes; yet always and completely binary compatible with Debian. Every backtrace from an Emdebian Grip device will match the backtrace on a Debian machine of the same architecture, package version etc. Packages can be mixed trivially (with some allowances for strict dependencies like -dbg packages). The name is a derivative of Squeeze - to make Debian smaller, we take a hold of it; Grip it.
Is it cross-building?
NO. Emdebian Grip is not recompiled (natively or cross), it is processed. Packages natively built in Debian are unpacked, files removed and repacked on the server before being included into the Emdebian repositories. dpkg and perl do all the work, not gcc.
What gets taken out?
Translations move out of the source packages and into TDebs (organised by locale) and compiled .mo files are then removed from the binary packages. Manpages and other documentation is lost entirely, copyright is compressed and changelogs are removed. None of the binary files are touched. The SHA256 sum of your /usr/bin/foo executable in Debian will be precisely the same in Emdebian, the same applies to libraries.
How is it done?
The emdebian-grip-server package in Debian processes the package and treats every architecture in the same way. (This allows Emdebian to carry unofficial ports like SH4, armhf etc.)
Why not filter stuff with dpkg?
The straight answer is that there usually isn't room to download the large package first in order to strip it on device. Also, filtering on device is slow. Stripping the package on the server means that the work is only done once. Every Emdebian device is saved the effort of filtering the files one machine at a time. Grip effectively does what dpkg filtering does, just it does it on the server, repacking the results into a new .deb. Instead of every device doing the task again and again, the server does it once.
Why is my pet package not included?
Emdebian restricts the number of packages which are included in the repositories (less than 10% of Debian packages will be included in Emdebian Grip 2.0 which is based on Debian 6.0 "squeeze") but provides tools which can be used (on device or on the desktop) to prepare any other package for installation on an Emdebian Grip device. There is no need for the machine preparing the package to be of the same architecture as the intended device because all processing is architecture-neutral.
Who decides which packages get included?
Me, basically. The merits of adding particular packages is usually discussed on the debian-embedded mailing list. Typical criteria (in rough order) include:

1. Subjectively suitable for an embedded device (so OpenOffice.org does not qualify)


2. most, if not all, dependencies already included in Grip


3. already available in Debian testing


4. not in a state of churn in Debian (rapid upload cycles, frequent library transitions etc.)
   
5. not particularly buggy in Debian

Can I convert Debian to Emdebian Grip
Yes - simply add Emdebian to your apt sources list and watch as your next upgrade releases tens of megabytes of space.
What are these em1 version suffixes?
Emdebian modifies Debian packages, albeit in an architecture-independent manner, by removing files. The resulting packages are therefore different to the originals, albeit containing compatible binaries. Hence, the Emdebian processing adds the em1 version suffix to show which version is installed. Adding the suffix also means that every Emdebian package is considered to be an upgrade compared to the equivalent Debian package, if both exist in your apt sources.
How is Emdebian Grip installed?
It is possible to use Debian Installer (we provide pre-seeding files to help this process) or create a simple tarball using multistrap if that is more suitable for your device.
What about Recommends: ?
Debian defaults to installing all packages listed as Recommends in the package metadata. Emdebian simply drops the entire Recommends field when processing the package. Suggests is also omitted. This dramatically shortens dependency chains and gives developers full control over which packages are installed. It is important here to consider the embedded device user interface. Recommends exists to support those users who need the extra parts of the package, the bells and whistles. Embedded devices strictly control which parts of the package is actually exposed to the user - there is no need for a menu or a desktop. Users can only access the functionality exposed by the device, so no bells and whistles - just the base system and whatever you choose to expose as part of the interface. Rather than require all Emdebian devices to turn off Recommends individually, Emdebian simply drops Recommends at the server and allows the developer to cherry-pick which packages to add.

More to follow . . .

When most people talk about Ubuntu, they usually mean our flagship product, Ubuntu Desktop Edition. Sometimes, they might mean the Ubuntu project, or the community of people who work on it, or various other things. Similarly, Debian might mean the Debian operating system, or the package repositories, or the project, and so on. This gets a little confusing sometimes. When I m talking about Ubuntu, I ve started to use more specific terminology to explain what I mean, and this seems to help people understand better the nature of the whole Ubuntu. In particular, I use the three Ps:

• a portfolio of products, including Desktop Edition, Server Edition, Netbook Edition, Kubuntu and more. These are software bundles which can be downloaded, pre-installed on retail computers, and so on. Each one is designed to meet a certain set of user needs, and to work on a specific form factor of computer.
• a technology platform, which can be used to build a wide range of products. It is primarily of interest to developers, who build derivative distributions, OS products, applications and infrastructure using Ubuntu packages. This platform is the common foundation of the Ubuntu products above, and includes things like the global package repository. Joel Spolsky does a good job of explaining why platforms are distinctly different from products, and should be treated as such.
• an open community project, which collectively produces, distributes, promotes and supports the products and the platform. The Ubuntu project has a philosophy, a government, and various tools and processes to help contributors work together. Canonical supports the Ubuntu project by providing resources and infrastructure, and also directly participates in Ubuntu at various levels.

This breakdown may seem a bit obvious to those of us on the inside , but it s confusing to people who are encountering it for the first time. I m sharing this in the hope that if more people start using the same words, it will get easier for people to understand how these pieces fit together. I ll also be linking to it a lot, to help put things into context using this framework.

Most packages contain files that you don t need: for example translations in languages that you don t understand, or documentation that you don t read. Wouldn t it be nice if you could get rid of them and save a few megabytes? Good news: since dpkg 1.15.8 you can! dpkg has two options --path-include=glob-pattern and --path-exclude=glob-pattern that control what files are installed or not. The pattern work the same than what you re used to on the shell (see the glob(7) manual page). Passing those options on the command-line would be impractical, so the best way to use them is to put them in a file in /etc/dpkg/dpkg.cfg.d/. Beware, the order of the options does matter: when a file matches several options, the last one makes the decision. A typical usage is to first exclude a directory and then to re-include parts of that directory that you want to keep. For example if you want to drop gettext translations and translated manual pages except French, you could put this in /etc/dpkg/dpkg.cfg.d/excludes:

# Drop locales except French
path-exclude=/usr/share/locale/*
path-include=/usr/share/locale/fr/*
path-include=/usr/share/locale/locale.alias
# Drop translated manual pages except French
path-exclude=/usr/share/man/*
path-include=/usr/share/man/man[1-9]/*
path-include=/usr/share/man/fr*/*

Note that the files will vanish progressively every time that a package is upgraded. If you want to save space immediately, you have to reinstall the packages present in your system. aptitude reinstall or apt-get --reinstall install might help. In theory with aptitude you can even do aptitude reinstall ~i but it tends to not work because one package is not available (either because it was installed manually or because the installed version has been superseded by a newer version on the mirror).

Found it useful? Click here to see how you can encourage me to provide more articles like this one.

8 comments Liked this article? Click here. My blog is Flattr-enabled.

This brief announcement was published in the debian-devel-announce mailing list and I repeat it here for your information.
Hi! Since there has been a lot happening in the Debian Multimedia world during the Squeeze release, so we figured we should give you an update on that. Who are we? In the dark old ages, there were two teams involved in multimedia: the Debian Multimedia and Debian Multimedia Packages teams. Please note that neither of them is related to debian-multimedia.org (which is maintained by Christian Marillat, and is known to break current ffmpeg-based applications like mplayer and vlc in Debian Squeeze.). During late 2008, both teams were merged into one, the Debian Multimedia Maintainers team, to avoid effort fragmentation. Since then, there has been a lot of work done: Consumer Multimedia in Debian Consumer Multimedia is about playing and, well, consuming multimedia. Squeeze will feature:

• FFmpeg 0.5.2, finally uncrippled thanks to zack! No mp3/h264 encoder, though. (still in NEW).
• mplayer 1.0rc3, finally with mencoder enabled.
• VLC 1.1.3
• VDPAU hardware acceleration in ffmpeg/mplayer (but feedback is welcome!)
• Guayadeque 0.2.5
• gmusicbrowser 1.0.2

Squeeze will not feature:

• FFmpeg 0.6 (But already available in experimental)
• Hardware acceleration with VA-API (packages also in experimental, for support on Intel hardware).

Producer Multimedia in Debian Producer multimedia is software for producing multimedia. Squeeze will
feature: End user applications:

• Ardour 2.8.11
• Audacity 1.3.12
• Composite 0.006
• Csound 5.12. The QuteCsound frontend is also available.
• FluidSynth 1.1.1
• Hydrogen 0.9.4.1
• Internet DJ Console 0.8.3
• Jokosher 0.11.5
• LiVES 1.3.4
• mhWaveEdit 1.4.20
• morituri 0.1.1
• QTractor 0.4.6
• Rosegarden 10.04.2
• SooperLooper 1.6.14
• Traverso 0.49.1
• X Jack Video Monitor 0.4.13
• Yoshimi 0.058.1

Platforms and technologies:

• JACK versions 0.118 and 1.9.6 (aka, jackd1 and jackd2). You can choose to install any of them (but only one at a time).
• LV2 plugins are supported. Ardour has support for them, and there are a bunch of them provided in Debian.
• LADSPA plugins are still supported.
• DSSI updated to 1.0.0, many plugins are available.
• FireWire sound devices are supported with libffado, and is supported by JACK.

Squeeze will not feature:

• JACK session support.
• Ardour 3 (it s not out yet, so it did not make it in time for squeeze).
• SuperCollider. There is a package in the works, but did not make it to Squeeze.
• Toonloop: This live stop-motion animation editor has been packaged only recently.
• NASPRO: Convenient library to implement LV2 dynamic manifest plugins. It s available in Sid.
• Mixxx: 1.7 series had RC bugs, and 1.8 was too late for squeeze.

Debian Multimedia Blend There is also an effort to start a Debian Multimedia Blend to give a better overview about what multimedia applications are available in Debian. There is a short list for a quick overview as well as a long package list separated in sections to give a more detailed overview (including translations, screenshots, popularity of package etc). You are invited to help improving the tasks either directly in SVN or by sending patches to Andreas Tille <tille@debian.org> or debian-multimedia@lists.debian.org (see below). Note that not all of the packages listed in the tasks pages are maintained by the Debian Multimedia team, since they are aimed at producing useful package sets instead of showing only our own packages. For those who want to squash some bugs in multimedia packages there is also the bugs page generated by the Blends tools, or our team bug page. Other activity The team has seen a lot of growth since the merger. Of the current 52 members of the Alioth team, 20 were added during 2009 and 18 in 2010, many of whom are involved in upstream development as well as the debian packaging. The number of packages has also grown, with 112 of the current 205 git repositories in our team area having its first commit during 2010. Where to reach us The Debian Multimedia Maintainers can be reached at pkg-multimedia-maintainers@lists.alioth.debian.org, should you have any questions. We have also decided to repurpose the old debian-multimedia@lists.debian.org address for user and more general discussion. We would like to invite everyone interested in multimedia to join us there. Interested developers/packagers can also join us at the first address. Some of the team members are also in the #debian-multimedia channel on OFTC.

Regards,

Alessio Treglia on behalf of the Debian Multimedia Maintainers

if I'm not mistaken, more & more people are trying to hunt down RC bugs nice! here are my contributions during the last weeks:

• #591133 src:linux86: "linux86: FTBFS: ncc: illegal label"
  grab patch from BTS and upload to DELAYED/2
• #592546 kernel-package: "kernel-package: does not create bootable image"
  lower severity
• #595397 libsys-sigaction-perl: "libsys-sigaction-perl: FTBFS on armel, unsupported"
  close after verification (pkg-perl)
• #598956 libwebkit-1.0-2: "On kfreebsd going into web pane segfaults Liferea."
  grab patch from BTS and uploaed to DELAYED/5
• #599693 nama: "nama: Startup fails because socket creation fails"
  upload fixed package prepared by bolangi (pkg-perl)
• #600585 vzctl: "vzctl: package fails to purge due to missing line continuation"
  apply patch from BTS (plus two other patches for two other bugs) and upload to DELAYED/7. later uploaded by maintainer
• #601116 liburi-perl: "liburi-perl: FTBFS in squeeze: test failed"
  upload to t-p-u and unstable (pkg-perl)
• #601978 gbonds: "gbonds: file conflict during upgrade from lenny"
  grab patch from BTS and upload to DELAYED/2
• #601979 libcherokee-server0-dev: "libcherokee-server0-dev: file conflict during upgrade from lenny"
  add Replaces and upload to DELAYED/2, later integrated into maintainer upload
• #601988 xfsprogs: "xfsprogs: file conflict when upgrading from lenny"
  add Replaces and upload to DELAYED/2, later fixed by maintainer upload
• #601990 libqdbm3++c2: "libqdbm3++c2: file conflict when upgrading from lenny"
  sponsor maintainer upload
• #601996 uim-applet-gnome: "uim-applet-gnome: file conflict when upgrading from lenny"
  grab patch from BTS and upload to DELAYED/2
• #602171 gdesklets: "gdesklets: won't start"
  propose a debdiff
• #602832 libsocket-getaddrinfo-perl: "libsocket-getaddrinfo-perl: 0.16-1 segfaults on lenny and squeeze"
  raise severity and provide some debug info (pkg-perl)
• #602872 wine: "wine: ftbfs on amd64, needs to build-depend on new ia32-libs-dev"
  upload NMU from mentors.d.n to DELAYED/7
• #602877 dvd+rw-tools: "dvd+rw-tools: apt dpendency problem"
  add a comment to the BTS, closed by maintainer afterwards

some remarks:

• although I was at the bug squashing party during the Paris Debian MiniConf I was more productive at home; I guess there was just to much other stuff to do (like going to talks and meet people) in Paris :)
• still no single complaint for my NMUs; but a few "thank you"s & some friendly requests to delay/cancel an NMU from active maintainers
• enrico sent some "should we remove this package from testing?" mails to several bugs today. IMO that's a great next step that will bring us closer to the release grazie!

If you use pbuilder, you probably already use cowbuilder too, in order to save on chroot instantiation time. You also probably use ccache in order to save on compilation time. If you do that, the longest time taken by your build is, by far, the time needed to install the build-dependencies, because dpkg likes to fsync() every file it writes. It s a good thing it does that on your main system, but in a disposable chroot you really, really don t care what happens to it if the system crashes. Thanks to Mike, I discovered eatmydata, and tried it with cowbuilder. If you want to try it out, add this to your pbuilderrc file:

EXTRAPACKAGES="eatmydata"
if [ -z "$LD_PRELOAD" ]; then
  LD_PRELOAD=/usr/lib/libeatmydata/libeatmydata.so
else
  LD_PRELOAD="$LD_PRELOAD":/usr/lib/libeatmydata/libeatmydata.so
fi
export LD_PRELOAD

You will also need to install eatmydata in your chroot, unless you want to regenerate it from scratch. And now you can enjoy your super-fast builds.

I ve just release pommed v1.35, adding support for the October 2010 MacBook Air machines. Kernel support for these machines has been submitted during the 2.6.37-rc cycle, so it will appear in 2.6.37 or 2.6.38 depending on maintainers, merge window and patch readiness. The machines have new keyboard assemblies (WellSpring IV and IVa) requiring new quirks in the HID layer, new trackpads, need sound & applesmc configurations of their own and the backlight module needs to know about them. So, make sure your kernel has all of that, otherwise your machine will be hard to use and pommed will not work at all. Update: #603395 filed against linux-2.6 with all the needed patches attached. It looks like we ll have all of this in Squeeze, thanks to our kernel team.

A while ago I wrote about the new distcheck tool upcoming in dose3. I've recently updated the proposal on the debian wiki to reflect recent changes in the yaml data structure. The idea was to remove redundant information, to make it easier to read and at the same time include enough details to make it easy to use from a script. I'll write down a small example to explain the format. A package can be broken because of a missing package or because of a conflict. For a missing package we'll have a stanza like this : The first part gives details about the package libgnuradio-dev, specifying its status, source and architecture. The second part is the reason of the problem. In this case it is a missing package that is essential to install libgnuradio-dev. missindep is the dependency that cannot be satisfied is the package libgruel0 , in this case: libboost-thread1.40.0 (>= 1.40.0-1). The paths component gives all possible depchains from the root package libgnuradio-dev to libgruel0 . Notice that we do not include the last node in the dependency chain to avoid a useless repetition. Of course there might be more then on path to reach libgruel0. Distcheck will unroll all of them. Because of the structure of debian dependencies usually there are not so many paths. The other possible cause of a problem is a conflict. Consider the following : This is the general case of a deep conflict. I use an artificial example here instead of a concrete one since this case is not very common and I was not able to find one. To put everything in context, this is the example I've used (it's in cudf format, but I think you get the gist of it): The first part of the distcheck report is as before with details about the broken package. Since this is a conflict, and all conflicts are binary, we give the two packages involved in the conflict first. Packages f and e are in conflict, but they are not direct dependency of package a . For this reason, we output the two paths that from a lead to f or e. All dependency chains for each conflict are together. Again, since there might be more than one way from a to reach the conflicting packages, we can have more then one depchain. Another important upcoming change is distcheck (to be implemented soon) it the ability to check if a package is in conflict with an Essential package. In the past edos-debcheck always check the installability of a package in the empty universe. This assumption is actually not true for debian as all essential packages should always be installed. For this reason, now distcheck will check the installability problem not in an empty universe, but in a universe with all essential packages installed. This check is not going to be fool proof though. Because of the semantic of essential packages, despite is not possible to remove a package toutcourt, an essential package can be replaced by a non essential package via the replace mechanism. For example, poking with this feature I noticed that the package upstart in sid replace sysinit and it is in conflict with it. This is perfectly fine as it gives a mechanism to upgrade and replace essential components of the system. At the same time this does not fit in the edos-debcheck philosophy of checking packages for installation problems in the empty universe (or in a universe with all essential packages installed). At the moment we are still thinking how to address this problem (the solution will be in the long term to add the replace semantic in distcheck), but for the moment we will just provide an option to check packages w.r.t essential packages conscious the this can lead to false positives. This work is of course done in collaboration with the mancoosi team in paris. Dose3 is still not ready for prime time. We are preparing debian packages and we plan to upload them in experimental in the near feature.

There must be other organisations across the world which do a similar job but this is the local one for me and in lieu of actually getting to a Remembrance Day event this year (I'll be at a bug squashing event for Debian Squeeze), I'm using my blog, just this once, to express my own thanks to those who gave their lives that I may be free to do what I enjoy, writing code to make things just work.

Just in passing, if anyone wants to support my work in Debian and/or Emdebian, there is a simple and free way to do it. Send me some patches, especially for documentation, translations and examples.

I have more than enough stuff that I could be doing and I do hear from users who want more stuff done to suit their particular requirements. Sorry, but time is finite and whilst a "thank you" is always appreciated, it doesn't actually generate a 25 hour day. So please don't just tell me what you want or why the current stuff doesn't do what you want it to do. The source code is all just "out-there" and you know more about what you actually want than I ever could.

If any of my code doesn't quite do what you want, please don't moan about it or file bugs that just moan about it, work out why and how and fix it - get involved. That way, the code will develop even if I don't always have time to work on it.