Search Results: "tar"

3 April 2011

Raphaël Hertzog: March 2011 wrap up

Since I m soliciting donations to support my Debian work, the least I can do is explain what I do. You can thus expect to see an article like this one every month. Multi-Arch work I updated the code to use another layout for the control files stored in /var/lib/dpkg/info/. Instead of using a sub-directory per architecture (arch/package.type), we decided to use package:arch.type but only for packages which are Multi-Arch: same. dpkg is taking care to rename the files the first time it is executed with write rights and then updates /var/lib/dpkg/info/format to remember that the upgrade has been done and that we can rely on the new structure. I filed a few bugs on packages that are improperly accessing those internal files instead of using the appropriate dpkg-query interface. I sent a heads-up mail on -devel to make other people aware of those problems in the hope to discover most of them as early as possible. After that, the work stalled because Guillem went away for 2 weeks and thus stopped his review of my work. I hope he will quickly resume the review and that we will get something final this month. With the arrival of dpkg 1.16.0, it s now possible to start converting libraries to multi-arch even if full multi-arch support has not yet landed in dpkg proper. See http://wiki.debian.org/Multiarch/Bootstrapping for the detailed plan. If you re curious about Multi-Arch, you might want to read this article of Steve Langasek as well. Bug triage for dpkg in launchpad At the start of the month, there was close to 500 bugs reported against the dpkg package in Launchpad. Unfortunately most of it is noise many of the reported bugs are misfiled, they show an upgrade problem of a random package and that upgrade problem confuses update-manager which tries to configure an already configured package. This generates a second error that apport attributes to dpkg and the resulting bug report is thus filed on dpkg. There are literally hundreds of those that have to be reclassified. Michael Vogt and Brian Murray did some triaging, and I also spend quite some hours on this task. It s a bit frustrating as I tend to mark many reports Incomplete because there s no way they can be acted upon and many of them are so old that the reporter is unlikely to be able to provide supplementary information. But in the middle of this noise, there are some useful bug reports, like LP#739179 which enabled me to fix a regression even before it reached Debian Unstable (because Ubuntu runs a snapshot of dpkg with multiarch support). I subscribed to the Launchpad bugs for dpkg via the Debian Package Tracking System (thanks to the derivatives-bugs keyword) and will try to keep up with the incoming reports. Misc dpkg work The ftpmasters came up with a request for a new field (see 619131) in source packages. After a quick discussion and a round of review on debian-policy@l.d.o, I implemented the new Package-List field. This should allow the ftpmasters to save some time in NEW processing, but we deferred the change for the next dpkg version (1.16.1) to ponder a bit more on the design of the field. I also fixed a bunch of bugs (#619541, #605719, #598922, #616096) and merged a patch of Mark Hymers to recognize the new Built-Using field. Developers-reference work The review process for changes to the developers-reference is not working as it should. And I suffered from it while trying to integrate the patch I wrote for the Developer duties chapter (see #548867). We purposely changed the maintainer field from debian-doc to debian-policy in the hope to have more reviews of suggested changes and to seek some sort of consensus before committing anything. But we don t get more reviews and deciding to commit a patch is now even harder than it was (except for trivial stuff where personal opinions can t interfere). In my case, I only got the feedback of Charles Plessy which was very mixed to say the least. I tried to improve my patch based on what he expressed but I also clearly disagreed with some of his assertions and was convinced that my wording was in line with the dominant point of view within Debian. We tried to involve the release team in the discussion because most of what I documented was about helping making stable release happen, but nobody of the team answered. Instead of letting the situation (and my patch) rot, I solicited feedback from the DPL and from another developers-reference editor to see whether my patch was an improvement or not. After some more time, I went ahead and committed it. It was not pleasant for anyone. I don t know how we can improve this. Contrary to the policy, the developers-reference is a document that is not normative, I believe the result is better when we put some soul into it. But it s a real challenge when you seek a consensus and that the interest in reviewing changes is so low. DVD shop listed on debian.org In February, I launched a DVD shop whose benefits are used to fund my Debian work. Shortly after the launch I used the official form to be added to the official listing of Debian CD vendors and offered a few suggestions to deal with vendors who are selling unofficial images (with firmware in my case). A few weeks later, I got no answers: neither for my request nor for my suggestions, I mailed the cdvendors@debian.org team directly asking for a status update and quickly got an answer suggesting that Simon Paillard usually does the work and can t process the backlog due to some injury. At this point no concerns had been raised about adding me to the list. To save some time and some work for the team, I added myself to the list since I had commit rights and I informed them that I did it, so that they can review it. Shortly after I did that, Martin Zobel Helas objected to my addition. I cleared some misunderstandings but the discussion also lead to some changes to please everybody: the listing now indicates that some images are unofficial and I have prepared a special landing page for people coming from the Debian website through this listing. Debian column on OMG! Ubuntu I have always been a firm believer that it s important for Debian to reach out to the widest public with its message of freedom. Thus when Benjamin Humphrey contacted the debian-publicity team to find volunteers to write a Debian column on OMG! Ubuntu, I immediately jumped in. I wrote 4 articles over there. The tone is very different from my articles on my blog and I like that duality. Check out Debian is dying! Oh my word!, Debian or Ubuntu, which is the best place to contribute?, Are you contributing your share? and Ubuntu s CTO reveals DEX: an effort to close the gap with Debian. It s a great win-win situation, OMG! Ubuntu benefits from my articles, Debian s values are relayed further, and OMG! Ubuntu s large audience also helps me develop my own blog. Work on my book I had lots of paperwork to do this month (annual accounting stuff for my company) and I did not have as much time as I hoped for my book. Still I have a updated a few more chapters of my French book and I certainly hope to complete the update during April. This means that the work on the English translation could start in may. Work on my blog Just like for my book, it has been relatively difficult for me to cope with my policy of two articles every week. But I still managed to get quite some good stuff out. I interviewed Christian Perrier (Debian s translation coordinator) and also Bdale Garbee (chair of Debian s technical committee). I finished my series of Debian Cleanup Tips with 2 supplementary articles: The removal of firmware is causing troubles to quite some users so I wrote an article explaining how to deal with the problem. A regular reader also asked me to write an article about Jigdo, I executed myself because it was a good idea and that he has been very nice with me: Download ISO images of Debian CD/DVD at light speed with Jigdo. Last but not least, I shared my package maintainer pledge which inspired my developers-reference patch (see discussion above). Thanks Many thanks to all the people who showed their appreciation of my work. The 324.37 EUR that you gave me in February represented 2 days and a half of my time that I have spent working on the above projects. See you next month for a new summary of my activities.

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

Rog rio Brito: Running GRUB2 on PowerPC Macs

Here I write a little bit about my experiences running GRUB2 with a PowerPC Mac (actually, an iBook G4), since the current documentation is lacking in many places (outdated, incorrect, etc.). Some of what I say is platform agnostic, though, and may be of interest to users of GRUB in general.

Basics using GRUB2 with PowerPC First of all, it is important to understand (at least superficially) how botting on a Mac works. One of the first programs that run in your Mac is the OpenFirmware. It works with more or less the same purpose of a BIOS in a regular x86 system. The basic idea is the same: get the computer running with whatever programs you want it to run. The implementation, though, differs quite a bit. First of all, OpenFirmware (OF) usually presents itself as a command-line interface that is programmable, differently from the common day BIOSes from x86 boxes. As it is programmable, it is more flexible, but this flexibility comes at the price of an increased complexity. I may write some things more in a future article, if there is any interest. For now, it just suffices to say that to get to the OF prompt in a Mac, you have to press a combination keys during the time that your Mac gives a chime when you turn it on. At that moment, you have to press (simulaneously) Cmd + Option + O + F. (Note: the Cmd key is the key that has an Apple drawn on it, usually on the side of the space bar).

Limitations of Open Firmware Differently from usual BIOSes of x86 computers, Open Firmware can read the contents of a partition in your HD (or other devices), as long as it is formatted in the original HFS format (not in HFS+ or one of its descendents). This is the reason why some older versions of Linux create an HFS partition in your HD, even if you don't intent to run or use anything besides Linux. The yaboot bootloader consists of, among other things, one binary that is understandable by OpenFirmware. That binary is a file called yaboot, after the name of the booloader. As an aside, you have to indicate to OF what is the file that you want it to load during the boot process, so that it knows what to do. The way to indicate this is to "bless" the file (and the folder that contains it). Some ways to bless a file are to, for example, use the bless command in MacOS X or the hattrib -b command from hfsutils. Files in an HFS filesystem have two attributes that many other filesystems don't: a creator ID (the "application" that created the file) and the type ID (which determines what kind of file it is). OpenFirmware, in particular, looks for files with the type tbxi for the bootstrap process. The yaboot binary is loaded by OF into memory and, then, control is passed to the yaboot program, which then reads its configuration file (yaboot.conf) from the same folder where the binary was in. The file yaboot.conf contains instructions for yaboot to do its job. The file yaboot.conf is very similar in construction to configurations of an older bootloader for x86 computers, lilo.conf. Also, in a way similar to what LILO requires, after you install some new kernel, change some parameter in the configuration file, etc., you have to run a program that will set up everything so that the boot process can know of your new configuration. With LILO, this command was called lilo, while with yaboot the command is called ybin (which, essentially, takes care of putting yaboot.conf in the bootstrap/HFS partition and blesses the yaboot binary).

Going to GRUB2 One of the characteristics of yaboot (which is left as an exercise to the reader to determine if it is a drawback or not) is exactly the way that changes in the configuration have to be copied to the special HFS partition: the step of running ybin. GRUB2 (and its older sibling, GRUB legacy) do away with that: during boot-time, it can understand the filesystems that you have in your computer and interactively load whatever you want from there, also from a command-line like OF, before any (regular) operating system has even been started. But how do you start GRUB2? Well, the way that this is performed is copying a binary to that special HFS partition. Here things start to be hairy, because GRUB2 has a lot of functionality, but it comes at the price of it consuming a lot of space (especially if you are using encrypted partitions or some kind of logical volume managements with some journalling filesystem that allows files to be compressed etc. on top of it). The list goes on. Usually, that special HFS partition only has 800KB, which, BTW, is the size of an old 3.5" floppy used with older Macs (note: due to some contraints on partitions and aligments of such partitions on cylinders, it is not uncommon for disk partitioning software to create partitions slighly larger than 800KB, but not much larger than that). A full-featured binary of GRUB2 to be placed on that HFS partition can have much more than those 800KB. But how do you get that binary, in the first place? And how do you fit that in the HFS partition?

Creating the GRUB2 binary To answer the first question, you have to construct it from your grub-ieee1275 package (I'm assuming here that you are using Debian or Ubuntu, but similar instructions may apply to other distributions). Then, a first step would be to create such binary with:
 mkdir /tmp/foo
 cd /tmp/foo
 cp -a /usr/lib/grub/powerpc-ieee1275/* .
 grub-mkimage -O powerpc-ieee1275 -o ../grub.img *.mod
The last command of these create an executable named grub.img that is callable from OF and which contains every module from grub-ieee1275. This executable that I call here grub.img is called, in GRUB2 parlance, the core image and it it seems to be named core.img in many systems. On my system, with those commands, the binary grub.img is about 1208KB, which is 50% larger than that 800KB partition. And you would like it to be much smaller, becase you want to still have your yaboot bootloader by default while you are evaluating your bootloaders (or using it as a backup plan). As GRUB2 follow a modular design, you can mix and match the features that you want. This already hints you to the way we can fit it in the HFS partition, and it is always the same story: just trim the fat.

Creating the configuration file You will also have to have GRUB2 configuration's file (or you will have to play with way more commands than you'd want to). An important distinction here is that you usually have 2 or more partitions on your Mac:
  • the special bootstrap/HFS partition where OF is going to look at (I'll call it /dev/hda2 here);
  • the partition where your / filesystem resides (denoted by /dev/hda3 here);
  • some partition to hold /boot (I don't have one of these, but let's say that it is /dev/hda7 for our discussion purposes), usually containing your kernels and initial ramdisks.
  • other partitions.
With this in mind, you can With Let's say that this last one, in Linux parlance, is /dev/hda3 (as is the case of this author), and optionally a partition where your Linux kernel resides (people usually use it to store the /boot subtree of a Linux filesystem). Let's say that this last one is /dev/hda7. Then, you would compose something like the following as a configuration file for GRUB2 (named grub.cfg):
insmod part_apple
insmod ext2
set root='(hd,apple7)'
menuentry "Linux"  
    linux /vmlinux root=/dev/hda3
    initrd /initrd
 
There are one two important points here that deserve more comments:
  • Note that, differently from a regular x86 system, in a Mac system with only one HD the way that you specify an HD does not have a trailing zero. For instance, in the case above of the variable root, we have (hd,apple7), while in a "common PC" we would have the (hd part replaced with (hd0. That's something that you should make your distribution aware of, if they aren't yet. As an addendum, I don't know how it works with systems with more than one HD, as I only have (PowerPC) Macs that are notebooks. If you can share any experiences, please do.
  • One point of caution here: what GRUB2 calls root is not necessarily the root of your filesystem (i.e., the partition that holds /), but the device that everything that is "not fully qualified" is interpreted as being relative to. The "not fully qualified" above means anything that is not prefixed with GRUB's device notation. As an example, (hd,apple2)/boot/vmlinux if fully qualified for GRUB's purpose, while /boot/vmlinux is not.

Putting it all together The next step is to just copy the files grub.img and grub.cfg to the special HFS partition. You can do that using hmount, hcopy, and humount or you can use the regular Linux hfs module to copy to that partition. Then, boot your system, get into the OF prompt and execute:
boot hd:2,grub.img
Here, the 2 above is a reference to my HFS partition. Substitute that with yours, appropriately. You will then see the common (familiar?) GRUB prompt and, from there, everything else that you know will (hopefully) work.

The list of modules that "Works for Me(TM)" As I mentioned above, I use a subset of all modules that come with grub-ieee1275 to create my grub.img binary. Here is the list of modules that I use and that gives me a reasonably sized bootloader:
bitmap.mod        datehook.mod  gzio.mod         lsmmap.mod      reboot.mod          terminal.mod
bitmap_scale.mod  datetime.mod  halt.mod         memdisk.mod     regexp.mod          test.mod
blocklist.mod     echo.mod      help.mod         memrw.mod       relocator.mod       trig.mod
boot.mod          elf.mod       hexdump.mod      minicmd.mod     scsi.mod            true.mod
bufio.mod         ext2.mod      hfs.mod          msdospart.mod   search.mod          video.mod
cat.mod           fat.mod       hfsplus.mod      normal.mod      search_fs_file.mod  video_fb.mod
cmp.mod           font.mod      ieee1275_fb.mod  part_apple.mod  search_fs_uuid.mod  videoinfo.mod
configfile.mod    fshelp.mod    linux.mod        part_msdos.mod  search_label.mod
cpio.mod          gettext.mod   loadenv.mod      parttool.mod    setjmp.mod
crypto.mod        gfxmenu.mod   loopback.mod     probe.mod       sleep.mod
date.mod          gfxterm.mod   ls.mod           read.mod        suspend.mod
Just for the record, my grub.img file has 624KB, and that can certainly be shrunk.

The command line that "Works for Me(TM)" to create the image Actually, I lied when I told you that I used the lines above to create my grub.img file, because I'm lazy and I don't want to type the .img extension. I also embed my configuration file in the binary that I create with GRUB2, so that I don't have two files to copy to my HFS partition, but only one. I do that with:
grub-mkimage -c grub.cfg -o ../grub -O powerpc-ieee1275 -d . *.mod
OK. No more lies here. The nice aspect of GRUB is that one you install that image, you don't have to touch that HFS partition anymore: you simply update your regular filesystem's /boot/grub/grub.cfg file (which is usually performed when you install a new kernel, at least with Debian) and you're ready to go. The good way to do that is to use a minimal configuration file embedded in your grub binary in your HFS partition that will hook into the system's /boot/grub/grub.cfg to read newer kernels and leave the HFS partition (and your system's NVRAM) alone. Here is what I am using right now:
search --no-floppy --fs-uuid --set=root 35d26869-f7c9-4852-a9b8-100314560c34
set prefix=($root)/boot/grub
configfile /boot/grub/grub.cfg
You will, of course, want to modify the file above as you install newer kernels (perhaps even that unsupported operating system from that fruity company, who knows?). Don't forget to change the UUID's, and partition numbers to fit your needs. Well, that's it. I hope that it helps somebody out there, as the information that I got otherwise was way outdated, incomplete, etc. to keep up with GRUB2 from these days. Now, let's go patch the tools that we have so that not everybody who wants to use GRUB2 have to learn about its workings. Oh, of course, you can now have your kernels in ext4, btrfs, xfs etc. partitions without the fear that your bootloader won't load them.

Cyril Brulebois: Debian XSF News #8

This is the eighth Debian XSF News issue. For a change, I m going to use a numbered list, which should help telling people which item to look for when pointing to a given URL. Feel free to let me know if that seems like a nice idea or whether that hurts readability. Also, it was prepared several days ago already, so I m publishing it (with the needed bits of polishing it still needed) without mentioning what happened in the last few days (see you in the next DXN issue!).
  1. Let s start with a few common bugs reported over the past few weeks:
    • The server can crash due to some X Font Server (XFS) issue as reported upstream in FDO#31501 or in Debian as #616578. The easy fix is to get rid of FontPath in xorg.conf, or to remove the xfs package. It s deprecated anyway.
    • Xdm used to crash when started from init, but not afterwards (#617208). Not exactly fun to reproduce, but with the help of a VM, bisecting libxt to find the guilty commit was quite easy. After a quick upload with this commit reverted, a real fix was pushed upstream; a new upstream was released, packaged, and uploaded right after that.
    • We ve had several reports of flickering screens, which are actually due to upowerd s polling every 30 seconds: #613745.
    • Many bug reports were filed due to a regression on the kernel side for the 6.0.1 squeeze point release, leading to cursor issues with Intel graphics: #618665.
  2. Receiving several similar reports reminded me of the CurrentProblemsInUnstable page on the wiki, which is long unmaintained (and that s why I m not linking to it). I m not exactly sure what to do at this point, but I think having a similar page on http://pkg-xorg.alioth.debian.org/, linked from the how to report bugs page would make sense. Common issues as well as their solutions or workarounds for stable should probably go to the FAQ instead.
  3. As explained in DXN#7, we re waiting for the kernel to migrate to wheezy. The 2.6.38 upstream release was quickly pushed to unstable, which is great news, even if it s not really ready yet (since it s still failing to build on armel and mips).
  4. I ve been using markdown for our documentation, basically since it looked sufficient for our needs, and since I ve been using it to blog for years now, but it had some limitations. I ve been hearing a lot of nice things about asciidoc for a while (hi, Corsac!), so I gave it a quick shot. Being quite happy with it, I converted our documentation to asciidoc, which at the bare minimum buys us a nice CSS (at least nicer than the one I wrote ), and with automatic table of contents if we ask for it, which should help navigating to the appropriate place. A few drawbacks:
    • The syntax (or the parser s behaviour) changed a lot since lenny s version, so updating the online documentation broke badly. Thanks to the nice Alioth admins, the version from lenny-backports was quickly installed and the website should look fine.
    • The automatic table of contents is generated through JavaScript, which doesn t play nicely with wkhtmltopdf (WebKit-based HTML to PDF converter), since the table of contents gets pixelated in the generated PDF documents. We could use a2x to generate documents through the DocBook way, but that means dealing with XSL stylesheets as far as I can tell; that looks time-consuming and a rather low-priority task. But of course, contributions are welcome.
  5. When I fixed missing XSecurity (#599657) for squeeze, I didn t notice the 1.9 packages were forked right before that, so were affected too. I fixed it in sid since then (and in git for experimental). I noticed that when Ian reported a crash with large timeouts in xauth calls, which I couldn t reproduce since untrusted cookies without XSecurity don t trigger this issue. I reported that upstream as FDO#35066, which got marked as a duplicate of (currently restricted) FDO#27134. My patch is currently still waiting for a review.
  6. Let s mention upcoming updates, prepared in git, but not uploaded yet:
    • mesa 7.10.1, prepared by Chris (RAOF); will probably be uploaded to experimental, unless 7.10 migrates to testing first, in which case that update will target unstable.
    • Intel driver: Lintian s been complaining about the .so symlinks for a while, and I finally gave it a quick look. It seems one is supposed to put e.g. libI810XvMC.so.1 in /etc/X11/XvMCConfig to use that library, so the symlinks are indeed not needed at all, and I removed them.
    • Tias Guns and Timo Aaltonen introduced xinput-calibrator in a git repository; that s a generic touchscreen calibration tool.
  7. Here come the updated packages, with uploader between square brackets (JVdG = Julien Viard de Galbert, Sean = Sean Finney). For the next issue, I ll try to link to the relevant entries in the Package Tracking System.
    • [KiBi] libxt: to unstable, as mentioned above, with a hot fix, then with a real fix.
    • [KiBi] synaptics input driver: to unstable and experimental, fixing the FTBFS on GNU/kFreeBSD.
    • [KiBi] xterm: new upstream, to unstable.
    • [KiBi] libdrm: new upstream, to experimental. A few patches to hide private symbols were sent upstream, but I ve seen no reactions yet (and that apparently happened in the past already).
    • [KiBi] xorg-server 1.9.5rc1 then 1.9.5, to unstable.
    • [KiBi] xutils-dev to unstable: the bootstrap issue goes away, thanks to Steve s report.
    • [KiBi] libxp to unstable, nothing fancy, that s libxp
    • [KiBi] keyboard input driver: mostly documentation update, to unstable and experimental.
    • [KiBi] mouse input driver: fixes BSD issues, to unstable and experimental.
    • [KiBi] intel video driver: to experimental, but the debian-unstable branch can be used to build the driver against unstable s server.
    • [KiBi] xfixes: protocol to unstable, and library to experimental (just in case); this brings support for pointer barriers.
    • [JVdG] openchrome video driver: Julien introduced a debugging package, and got rid of the (old!) via transitional package. He also performed his first upload as a Debian Maintainer. Yay!
    • [KiBi] siliconmotion video driver: to unstable.
    • [KiBi] pixman: new upstream release candidate, to experimental
    • [Sean] last but not least: many compiz packages to experimental.

2 April 2011

Gintautas Miliauskas: Amazon Kindle 3

For the past couple years I had been reading very little, two or three books a year.

For the past month my average has been two books per week.

The culprit is the Amazon Kindle 3 I bought during my stay in the US. I just can not recommend it enough. For starters, it is quite affordable at $139. The image quality is wonderful, and reading in daylight or even in direct sunlight is pleasant. This is a welcome change from a backlit screen as the eyes get noticeably less strained. The format of the device is even more convenient than of a real book (the size is perfect for plain text, start thinking about the Kindle DX if and only if you intend to read PDFs). The Kindle is quite thin and convenient to hold (and you do not need to keep it from closing as with paperback bindings). Battery life is on the order of weeks. Extra functionality (e.g., web browsing) is available, but not convenient, but that is almost an advantage as distractions are kept at bay. The Amazon store is great, I have already shelled out over $50 with little remorse (my time is much more expensive than the measly $9.99 a typical book costs). There are quite a few free books around too. And to top it off, the "screensaver" with pictures of writers is a very nice touch.

The Kindle is also useful for going through longer articles you would normally be reading on your laptop. The Chrome extension Send to Kindle has worked well for me, do check it out.

The most important drawback of the Kindle is that it is slow to turn pages, so it is not easy to browse a book. Turning a page takes a second or so. This is extremely annoying when reading in non-linearly, e.g. taking in study material, when you constantly need to go back to check up details of previous material. A PDF interpreter is available, but the screen is too small to show a full PDF page (a Kindle DX or an iPad would probably be better) and scrolling is painful because of the delays. Wireless seems to drain the battery noticeably, there have been a few cases where I forgot to turn it off and found a dead Kindle a few days later. I wish the WiFi connection would manage itself intelligently somehow.

The Kindle drove the point home for me that dead-tree books will be going the way of vinyl soon, much sooner than I had expected. And for good reasons. Go order now if you do not have an e-book reader yet (and do not forget to order a sleeve too, given the time you will be spending carrying the device it will come in very handy).

Niels Thykier: Cross package checks in Lintian

If you have been using Lintian you may also know that it has some limitations. One of these are that Lintian always checks every package isolated from each other unlike other tools like piuparts. It has its advantages (such as not requiring all dependencies being present) but it also has it disadvantages. Currently Lintian emits a binary-without-manpage -tag if the package contains a binary without a manpage. At first glance this appears reasonable, but it really is too simple (#512645). Basically Lintian complains about the missing manpage even if the manpage will always be present. A simple case is package foo depends on foo-data, the binary is in foo and the manpage is in foo-data. A live example of this is gedit and gedit-common[1]. The problem is that Lintian does not know if a given package is going to processed or not. Lintian does have a few cross package checks; namely binary checks can see the source package if it is available. This can be done with a bit of clever sorting (quote from Lintian source code):
# [...] (the sort is to make sure that source packages are
# before the corresponding binary packages--this has the advantage that binary
# can use information from the source packages if these are unpacked)
This works rather well, but its scope is very limited. Particularly it is no help, if we need to check if the manpage missing in foo might be in foo-data. This is what #513663 is all about. In January I branched the Lintian code and started working on grouping packages from the same source together. Yesterday I finished refactoring Lintian to do just that. However, this in itself is not very useful if the checks cannot take advantage of this. So today I sat down and extended our manpages check a bit and posted the results to the Lintian mailing list. [1]http://packages.debian.org/sid/gedit http://packages.debian.org/sid/gedit-common

1 April 2011

Josselin Mouette: GNOME.Asia distribution collaboration session

Today we gathered the representatives of different distributions that are present at GNOME.Asia to discuss what GNOME could do to improve its support for distributions that distribute it, especially in matters of long-term support. It is kind of sad that there weren t any representatives from Canonical nor Red Hat, but the discussion turned out really interesting and we learned a lot about the packaging habits of each other. Furthermore, there were several concrete leads that were explored, which will lead to proposals from the GNOME foundation to all distributions. Helping with long-term support The most widespread GNOME version in the LTS releases that happened recently is 2.30, which is used by Debian squeeze, Ubuntu LTS 10.04, RHEL 6, and Solaris 11. It looks like an accident, but on the other hand: In the future, a decision to use a common GNOME release could, anyway, only come from the distributions themselves, not from GNOME. A proposal that many people agreed upon was to give distribution maintainers commit access to old branches that GNOME module maintainers don t touch anymore. This way they could share their patches more easily and make new releases of these old branches. This would imply, of course, setting up rules about what changes are allowed, that distributions would have to agree upon (how to treat feature additions for example). Managing bugs Currently it is hard to tell, for a distributor, whether other distributions are affected too and whether they have released a fix for that. It was agreed upon that Launchpad s feature of linking bugs between distributions, including version tracking, would exactly fill that need. One of the solutions would then be to add such a feature to Bugzilla, but it is a lot of work since currently it doesn t have any kind of version tracking. Another proposal was to deploy a new Launchpad instance to do serve as a hub between downstream bug systems and the GNOME Bugzilla. The condition for this to work would be to make it extremely easy to clone bugs between it and Bugzilla, and also if possible from the downstream bug systems. On the side-related topic of how not to crawl under bugs, it might be possible to get bugs forwarded with a single command from the Debian BTS to Bugzilla, using the XML-RPC interface. Upstream also considers that bugs sent to Debian are generally of higher quality than those from e.g. Ubuntu, and would be OK with us routing some of them directly to upstream (like we already do for Evolution). Communicating about the availability of patches Currently distributors are hardly ever informed that patches relevant for their distribution have been committed. They often learn of them by sheer luck while lurking on Bugzilla. The distributors-list ML is clearly the relevant media for that purpose, but it is clearly not used enough. It would need to be advertised more among both GNOME module maintainers, and among downstream maintainers as well. On this matter, the disappearance of the x.y.3 GNOME releases (starting with 2.28) was evoked. The problem was that most of those releases were about insufficient changes to justify e.g. stable updates in distributions. The proposed solution is to encourage maintainers of modules with bugs to fix to release new versions (through an annoucement on desktop-devel-announce), and to send a list of modules with new versions to downstream distributors so that they can integrate them. This avoids the GNOME release team the hassle of making a new release, while still giving distributions that use them some bugfixes. Providing a new service to LTS distributions The idea of having the GNOME foundation employ a person to gather, on the GNOME side, all changes that are relevant to older GNOME versions, and prepare new stable versions, was discussed. This would be a new service for which commercial distributions would need to pay a fee. It s not clear how this information would be privately disclosed and the impact on non-commercial distributions. But it doesn t seem likely that e.g. Red Hat would be interested since they employ a lot of core GNOME hackers who are already doing this job.
I don t know what impact these proposals can have on GNOME packaging in Debian, but apart from the last one that I find dubious, it seems that they could greatly improve our support of GNOME in stable Debian releases, be it by having more versions to upload during the freeze, or by having more stuff in point releases. Fr d ric Muller promised to come back to us with more concrete stuff.

Julien Blache: 450 Telcos suck

Due to cockups and/or willful sabotage by the telcos my ISP relies on for its DSL services, I am unreachable by email starting early this morning (UTC) and until further notice. My primary MX is off the net, mail is spooling on my backup MX so nothing should be lost. <expletive deleted> Update 2011-04-05: stupid telco finally rebuilt the line properly. I m back, no mail lost at first glance and I m slowly digging into that pile of mail. If you don t receive a reply by tomorrow, please resend.

Josselin Mouette: GNOME.Asia 2011 hackfest

For the whole week, I ve been in Bangalore for the GNOME.Asia 2011 hackfest. I ve been delegated by Stefano to represent Debian here, and my employer EDF has agreed to cover for travel costs since they are very interested in first-hand information the future of the Linux desktop and sharing our work on scientific computing. It s been a really exciting week; I ve spent quite some time packaging missing pieces of GNOME 3.0 (well, the release candidate versions of course) in experimental, together with Fred Peters. I think it s reaching a usable state now, so we ll probably soon provide metapackages to make it easily installable. The latest developments of the Shell make it a very exciting piece of software, with a strong focus on usability. Many things were written about it, but in the end my main criticism would be that it lacks some functionality - for example, the combined clock/weather/locations applet will be greatly missed. The good news is that it is extremely customizable, and with all the libraries being made accessible through GObject introspection, there are many features that are accessible from it. If you know how to write JavaScript, now is the time to write your favorite extension. On the good news front, Vincent Untz also spent a lot of time improving the so-called legacy mode , which is more and more starting to look like the Shell without special effects, and with all the features from gnome-panel 2.x that are still here. We will try in Debian to cover all uses cases that there were for GNOME 2 with GNOME 3 technology, so that panel lovers are not left behind. I ve also proposed an update to the dh_gsettings proposal, which will provide the same functionality as dh_gconf and allow to easily set distribution-specific overrides. It is still missing a way to set mandatory settings, which might come as a problem for some corporate users, but this is planned for a future version of GSettings. Today, we re having a business track where I and representatives of other companies (Oracle, Lanedo, Dexxa) are sharing experiences about making money with free software. Unfortunately the local organizers didn t manage to gather many people, despite our being in a city with an incredible number of IT industries. Tomorrow, the public conference starts, and this should be the opposite: we re expecting around 1000 people, which is a great achievement for a free software conference. For an unrelated topic, being around so many GNOME hackers has some interesting side effects; I ve been added to Planet GNOME. So, hey, hello Planet GNOME readers!

31 March 2011

Torsten Werner: My Wheezy release goal: JS removal

Debian is preferring feature based releases over time based releases and that is why we currently have some discussion about release goals for our next version that has the codename Wheezy. I want to suggest the full removal of all software written by J rg Schilling who is well known for making trouble in projects that want to redistribute his software.

Jordi Mallach: A tale of Trist nia and its Quadrennial Royal Ball

In one of the corners of what is now know as Europa, there was a rich, prosperous and beautiful kingdom known as Trist nia. In the past, not that long ago, it had been a number of smaller kingdoms and caliphates, all with their own cultures, religions and ways of life. Wars, and series of marriages of convenience eventually configured what ended up being the united kingdom of Trist nia. Throughout the years, some of the unified cultures grew and flourished, while others struggled to survive in their ever-shrinking areas of influence. A required introduction Sometimes, the minor cultures would suffer due to oppression coming from the delegates of the King, who would ban any expression of these cultures, as they were seen as a potential threat to the kingdom's stability and unity. For example, just a few decades before the main subject of this tale, the predecessor of the incumbent King took power by force, after crushing everyone who opposed his uprise during a bloody and hard civil war. His reign was ruthless and he imposed draconian laws uppon his people: usage and teaching of the minor languages was banned, and everyone was forced to use the language of the Centr lia region, in public or private. After four decades, the majority of the Tristanian people were sick enough of the situation to consider standing against their fear of the regime and demand freedom, but repression prevailed until the old general died. His place was taken by the King's grandson even if the people had expressed, just before the Great War, that they had had enough kings and demanded a ruler they could choose directly. Of course, the new King seemed a lot nicer than who they had been suffering for ages, so when asked if they accepted the new situation, an overwhelming majority said yes . However, there was a region, Verd lia, where the majority said no . Things were actually more complicated. Verdalians formed a traditional, proud society, and while the years of oppression had undoubtedly weakened it, they had managed to preserve their very unique culture, language and traditions healthy. The Verdal language was really weird to the ears of Centr lians and even other minor cultures of the Kingdom, and erudites struggled to find its real origins, not being able to reach plausible conclusions. Verdanians, as we already know, were a traditional society, living in a land of deep and poorly connected valleys. Little they knew or cared about the complicated matters of Centr lia and other regions. What made them happy was to take care their sheep and cows, keep a good fire in their living room and, every now and then, enjoy one of their log cutting contests. The impositions of the former dictator were too much for them, and some of them started sabotaging, assaulting and killing some of the dictator's soldiers, agents and officers. This was a huge risk at the time; getting caught meant death penalty for sure, and at first, even people from other regions were in favour of these actions. However, this popular support greatly diminished when the new King took the throne, as these minority continued with the killings, while most of the people saw it was no longer justified. The Royal Ball One of the very first measures the young King introduced was to organise the Royal Ball of Trist nia , a major event through which the people of the different regions would be able to elect their delegates to the Crown. Every four years, a Great Ball contest would happen in Centr lia, and the winners would be able to decide by their own on some of the matters that affected their region. Verdanians would send a few teams of dancers, each of which came from different towns or areas. Some Verdanian teams were happy about the King and the new political situation, but other teams weren't so much. And some others, while being simple non-violent dancers, were known to be supporters of the violent minority who kept on harassing, assaulting and even killing in their struggle for freedom of Verd nia . The Verdanian groups aligned with the different culture of Verd nia (including those who were said to support the violent) tended to get a lot more points in the dancing contest, and a majority of the elected delegates were appointed by them, making it easier to pass laws and edicts that favoured protection of their ways, traditions and language. No matter how hard they tried, the dancing groups closer to Centr lia kept losing to the majority. After many years of dance contests, these groups used their closeness to the King's court to pass the Ball Law of Tristanian, that would ban any dancing group which didn't condemn the assaults and killings that kept happening in Verd nia. The unsurprising result was that, with less dancing groups participating in the following Royal Ball, the Verdanian majority was broken and new delegates, friendly of the Centralian officers, were elected. Many people who had been in favour of assaults and killings began to question this strategy, and this political movement's unity started to break. In the end, the dancers decided to part ways with the violent; they wanted to dance in the next ball, and to do so, they wrote a letter to the King, in which they explicitly expressed their rejection of violent ways, and their embracing of dancing as the only means to drive their political agenda. An objective reading of the new Ball Law clearly showed that this was enough: the text only said the requisite for a dancing group was to disavow all kinds of violence. This wasn't really expected in Centr lia, so they started to add new requirements in an attempt to keep this group from the contest: their decisive majority in Verd nia was at stake. The Royal Ball was nearing and registrations for the contest would soon close. The Centralian government first argued that the dancing group should reject the violence coming from the Verdanian extremists in particular. The dancers did it. Then they argued that the dancers were the same people who had been supporting violence in Verd nia for years, and obviously their violence rejection statement was a lie. The dancers struggled to find new dancers who had not been involved in past dances. But it was not enough. They then claimed that this dance group should be quarantined for four years, until they could prove they really were serious about their new non-violent ideas. The dance group made a plea to the Trist nian Supreme Counsel, a group of sixteen experts in law of the Kingdom, and argued that all of these draconian requirements were not part of the law that was being enforced by the King. Their appeal to the elder counselors was in vain, though. They ruled this dancing group was as criminal as the violent minority they had once supported, and should by no means take part in the Royal Ball. As a last, desperate measure, the dancing group reached an agreement with other Verdanian dancers to join forces. They would adopt a new name and new dancing costume colours. Many feared this would only end up in the ban of the other dancing group. Unfortunately, the end of this story has not been written yet, but it will be completed very soon. Only time will tell if things continue being very sad and unfair in Trist nia, or if the dance contest will once again be impartial, with legitimate results.

Pau Garcia i Quiles: A wish a day 7: make emerge a generic package manager for Windows

A while ago I said Koen from Emweb made an interesting proposal at FOSDEM about emerge, the KDE Windows build tool. Yesterday, Jaros aw Staniek and I reaffirmed our commitment to emerge . Today, I d like to go a bit further: let s bring more developers to emerge by opening it up to other projects. Keep reading! What is emerge, why is it important and what was Koen s proposal? Fact: Microsoft Windows is very different to Unix in regards to development. On Unix platforms -that includes Linux and Mac OS X-, software is usually installed to /usr: applications in /usr/bin and /usr/sbin, libraries in /usr/lib, headers in /usr/include, common resources in /usr/share, etc. Also, dependency management is usually something you can count on: when you install kdelibs5-dev in Ubuntu, it will automatically install libqt4-dev, kdelibs5-data, libfreetype (runtime), etc That makes setting up a development environment a very easy task: look for shared libraries, header files, etc in the common places and you will probably find them. On Windows there is nothing like that. When you want to compile an application, you need to provide (build and install) all its dependencies, and you need to tell Visual Studio where to find everything. Even CMake usually needs some help in the form of a hint for CMAKE_PREFIX_PATH. As you may imagine, building KDE, which has more than 200 third party dependencies and tens of modules (and with the move + split to git, many more) becomes an almost insurmountable task. Emerge to the rescue: inspired by Gentoo s emerge, Ralf Habacker, Christian Ehrlicher, Patrick Spendrin and others (yours faithfully included) developed a tool which downloads the source, configures, builds, installs and packages KDE and its dependencies. It makes a world of difference when building KDE. Actually, it makes building KDE on Windows possible. Once more: thank you very much guys, impressive tool. There are two well-differentiated parts in emerge, the engine and the recipes . The engine takes care of downloading the sources (tarballs, checkouts from Subversion and git clones, etc) , configuring and building for the usual build systems (QMake, CMake, NMake makefiles, etc), installing, bundling packages together and much more. All that for four compilers (MSVC2008, MSVC2010, MinGW32 and MinGW-W64). It s the equivalent to Gentoo s emerge, Debian s dpkg + debhelper/cdbs or Homebrew and MacPorts for Macintosh. The recipes are the package-specific instructions a particular piece of software needs to build: what s the name of the tarball? URL to download from? What versions are available? What build system to use to configure and build? Does it need any Windows-specific patch? They are written in Python using some helper modules emerge provides (the debhelper-like part I mentioned above). Currently, there are about 70 recipes in emerge, organized in our portage tree (bear in mind the names are taken from Gentoo but the internals of the tool are completely different). With those 70 recipes, we are able to build most KDE modules. Problem is to provide all the optional features, we are missing probably 200 to 250 more recipes. Given that KDE on Windows is quite short on developers, we have to decide: either we fix bugs and improve the integration of KDE on Windows, or we keep track of the dependencies. I won t lie: for KDE on Windows, I d rather focus on development than on packaging. Given that writing and maintaining recipes does not strictly require programming skills (although they help :-) ), during my talk at FOSDEM I kept asking people to join the KDE on Windows team as packagers, even if you know little to nothing about software development. If you think about it, that s what we have in Linux distributions: there are hundreds (thousands?) of packagers in Debian, Fedora, openSuse, etc which take care of the recipes to build software developed by someone else ( upstream , in the parlance). What we have in KDE on Windows, where we are the KDE packagers, the KDE developers (upstream) and the emerge developers, is actually an anomaly. Then Koen took the microphone and said: why don t you open emerge to other projects? And I there I realized he was damn right We have developed an awesome tool to download, configure, build, package and install third party software on Windows, to manage dependencies, to update, etc. For four compilers, no less. The engine of emerge is not really tied to KDE. We already have a lot of recipes for software which is not KDE specific: openssl, Qt, bzip2, libpng, mysql, etc. I see no actual reason to disallow Gnome, GStreamer, OpenSceneGraph, LibreOffice and many others in (assuming someone wants to take care of them, of course no, do not look at me! I don t have time!). Currently, the only barrier preventing those recipes in is emerge is developed in the KDE repository and you need a KDE developer account to commit your recipes. That s about it. There is also a perception problem: if emerge is developed in KDE, it s because it s a KDE-thingy, right? . Well, no. One way to avoid that would be to graduate emerge from KDE and make it an independent project, one in which the current developers have accounts, and new developers get an emerge project account instead of a KDE account to commit recipes. Please note graduating does not mean expelling , firing or anything peyorative. It does not mean that emerge developers (engine and recipes) are worse than KDE developers, or less KDE developers than our god David Faure: in KDE, we consider Debian, Fedora, openSuse, etc KDE packagers as equals, they are also KDE developers and many of them are in the KDE eV (funny thing is I am not). My wish for today: think of one application or library you d like to see in Windows and become its maintainer in emerge for Windows. For now, let s do this in the kde-windows mailing list and if this idea succeeds, then we ll talk about graduating. You could also try to add support for a new compiler (OpenWatcom, Intel C++, etc) but that s a lot more more and it s not a priority now. PS: Yes, I know about CoApp, Microsoft s similar effort, with some magic involved. I ve been watching and trying it since day 1. I m really interested. It s just not there yet and I do not have spare time to help Garrett (hey Microsoft, hire me and I ll have all the time in the world! :-) )

Russell Coker: Links March 2011

Cory Doctorow wrote an interesting article for The Guardian about Harper-Collins attempts to make self-destructing books [1]. They claim that a traditional book falls apart after being read 26 times (a claim that Cory disputes based on personal experience working at libraries) and want ebooks to be deleted after being borrowed so often. Really the copy-right fascists are jumping the shark here.Socialogical Images has an interesting archive of adverts for supposed treatments for autism, obsessive-compulsive disorder, asperger syndrome, and attention deficit and hyperactivity disorder [2]. The New York University Child Study Center conducted the campaign of fake ransom notes to describe a psychological difference as something that kidnaps a child. The possibility that parents should to some extent learn to adapt to their child s nature rather than fixing them with medication is something that most people can t seem to understand.William Cronon has written an interesting analysis of the way Conservative , lobby groups work [3]. They are more organised than I expected.The Reid Report has a good summary of some of the corporat issues related to the Japanese nuclear melt-down [4], apparently the company that runs the reactors decided to delay using sea-water in the hope that their investment could be salvaged and thus put everyone at increased risk. I think that this proves that reactors shouldn t be privately owned.Ian Lowe wrote a good summary of the reasons why Australia should not be using nuclear power when we believed that the Fukushima disaster was over [5]. But it turns out that the Fukushima problems were worse than we thought and the melt-down is getting worse.Christopher Smart wrote a good analysis of Microsoft s latest attempt to extort money from Linux users where they assert patent claims over Android [6]. He points out that .NET/Mono is a risk to Linux.Major Keary wrote a positive review of Snip Burn Solder Shred which is a book about Seriously geeky stuff to make with your kids [7]. Sounds like a fun book.The internal network of RSA has been cracked in some way that apparently weakens the security of SecureID, Bruce Schneier s blog comments section has an interesting discussion of the possibilities [8]. I expect that it s a fairly bad attack, if the attack was minor then surely the RSA people would have told us all the details.Hans Rosling gave an interesting TED talk about The Magic Washing Machine [9]. He describes how his family benefited when his mother first got a washing machine and how this resulted in better education as his mother had more time to get library books for her children. It seems that deploying more electric washing machines should be a priority for improving education and food supplies in third-world countries.Paul Root Wolpe gave an interesting and disturbing TED talk about bio-engineering [10]. He catalogues the various engineered animals and talks about the potential for future developments.Ron Rosenbaum wrote an interesting and insightful article for Slate about Maj. Harold Hering who s military career ended after he asked how to determine whether a nuclear launch order is lawful, legitimate, and comes from a sane president [11]. The question never received a good answer, this is a good reason for moving towards nuclear disarmament and for Americans to vote for the sanest and most intelligent candidate in the presidential elections.Eythor Bender gave an inspiring TED talk about human exoskeletons [12]. He had live demonstrations on stage of a soldier using an exo-skeleton to carry a heavy backpack and a woman who suffered a severe spinal-cord injury walking after being in a wheel-chair for 19 years.

30 March 2011

Alejandro Rios P.: Linux guy working in a Windows desktop

After >7 years of working on my own Linux machine, I now have to work on a Windows XP laptop for my new employer.

It's been almost a week and a half now, and I think I'm starting to get used to it (as far as a Gnome user can be), thanks to the following tools, that I had to install in order to survive and not getting mad:


There is also a GEdit for windows, but I seldom use it.

Ingo Juergensmann: Updated: Automatically restore files from lost+found

Today, in an IRC channel near you, the discussion came to recover files from lost+found somehow. Two years ago I wrote some scripts to automatically recover files from lost+found, so this is some sort of a repost. There are two scripts: one that generates some kind of ls-LR file to have all the information needed for the second script, which restores those files in lost+found to their original folders. Here is the information from the original blog post: make-lsLR.sh - call this regularly (cron) to create the needed files that are stored in /root/. Of course you can alter the location easily and exclude other directories from being scanned. check_lost+found.py - The second script is to be run when your fsck managed to mess up with your files and stored them into lost+found directory. It takes 3 arguments: 1) the source directory where your messed up lost+found directory is, 2) the target directory to which the data will be saved and 3) a switch to actually make it happen instead of a dry-run. You can find both files as attachment end the end of this blog post.

I've chosen to copy the files to a different place instead of moving them within the same filesystem to their original place for safety reasons. Primary goal is to retrieve the files from lost+found, not to replace a full featured backup and restore application. Because of this the script doesn't handle hard- nor symlinks correctly. It just copy files.

Of course there's still room for improvements, like handling hard-/symlinks correctly or using inode number instead of md5sums to move data back to its prior location. But it works for me[tm] well enough in this way, so I'm satisfied so far. You're welcome, though, to improve this piece of ugliness if you like.

Maybe someone else finds this usefull as well. Use it on your own risk, of course. :)

Benjamin Drung: First interview

Kristian Ki ling from the Ubuntu User magazine interviewed me at the last Ubucon. You can read the (German) interview in Ubuntu User 02/2011 or on-line. Flattr this

29 March 2011

Ingo Juergensmann: KDE - Login Problems with kdm on Unstable

Some days ago I upgraded my Sid system and when I restarted my X session the other day, I wasn't able to successfully login to KDE via kdm anymore. I'm getting some errors in ~/.xsession-errors:
kdeinit4: preparing to launch /usr/bin/knotify4
Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)knotify(16474) KNotify::event: 1 ref= 0
QMetaObject::invokeMethod: No such method KUniqueApplication::loadCommandLineOptionsForNewInstance()kdeinit4: preparing to launch /usr/bin/plasma-desktop
kded4: Fatal IO error: client killedkdeinit4: Fatal IO error: client killed
kdeinit4: sending SIGHUP to children.
klauncher: Exiting on signal 1
At the user/password prompt of kdm I can login, the KDE splash screen appears and then, suddenly, the connection fails and I'm back at the kdm login again. I tried to look for already existing bug reports, but KDE is quite large and with many programs. Are there any pointers for a bug report or even a solution/fix for the problem, dear LazyWeb? UPDATE 21:51:
Sune suggests in the comments that it might be a Xorg problem. I've attached a xorg.txt logfile to this post. As you can see, there's a backtrace because of a sig11 error. Funny enough, when I connect via remote X from my OSX I can login into KDE, although there are visual errors. Xorg is working fine on the local server with Gnome, though. So, for me it seems related to either KDE or maybe Compiz. UPDATE 2011-03-30:
Problem solved! LL hinted in the comments to reinstall the Nvidia driver and now it works again! Thanks! :-)

Steve Langasek: Multiarch Monomania

So the other day, I was able to do this in an Ubuntu natty amd64 chroot for the first time.
# cat > /etc/apt/apt.conf.d/multiarch-me
APT::Architectures   "amd64"; "i386";  ;
^D
# cat >> /etc/dpkg/dpkg.cfg
foreign-architecture i386
^D
# apt-get update
# apt-get install flashplugin-installer:i386
Reading package lists... Done
Building dependency tree       
Reading state information... Done
[...]
The following NEW packages will be installed:
  flashplugin-installer:i386 flashplugin-nonfree:i386 gcc-4.5-base:i386
  libatk1.0-0:i386 libavahi-client3:i386 libavahi-common-data:i386
  libavahi-common3:i386 libc6:i386 libcairo2:i386 libcomerr2:i386
  libcups2:i386 libdatrie1:i386 libdbus-1-3:i386 libdrm2:i386
  libegl1-mesa:i386 libexpat1:i386 libfontconfig1:i386 libfreetype6:i386
  libgcc1:i386 libgcrypt11:i386 libgdk-pixbuf2.0-0:i386 libgl1-mesa-glx:i386
  libglib2.0-0:i386 libgnutls26:i386 libgpg-error0:i386 libgssapi-krb5-2:i386
  libgtk2.0-0:i386 libgtk2.0-common libice6:i386 libjasper1:i386
  libjpeg62:i386 libk5crypto3:i386 libkeyutils1:i386 libkrb5-3:i386
  libkrb5support0:i386 libnspr4:i386 libnspr4-0d:i386 libnss3:i386
  libnss3-1d:i386 libpango1.0-0:i386 libpcre3:i386 libpixman-1-0:i386
  libpng12-0:i386 libselinux1:i386 libsm6:i386 libsqlite3-0:i386
  libstdc++6:i386 libtasn1-3:i386 libthai-data libthai0:i386 libtiff4:i386
  libudev0:i386 libuuid1:i386 libx11-6:i386 libx11-data libx11-xcb1:i386
  libxau6:i386 libxcb-dri2-0:i386 libxcb-render0:i386 libxcb-shape0:i386
  libxcb-shm0:i386 libxcb-xfixes0:i386 libxcb1:i386 libxcomposite1:i386
  libxcursor1:i386 libxdamage1:i386 libxdmcp6:i386 libxext6:i386
  libxfixes3:i386 libxft2:i386 libxi6:i386 libxinerama1:i386 libxrandr2:i386
  libxrender1:i386 libxt6:i386 libxxf86vm1:i386 x11-common zlib1g:i386
0 upgraded, 78 newly installed, 0 to remove and 3 not upgraded.
Need to get 15.1 MB/15.6 MB of archives.
After this operation, 48.9 MB of additional disk space will be used.
Do you want to continue [Y/n]?
It is a truly heady experience, after so many years of talking about the need to properly support multiarch in Debian and Ubuntu, to see support for cross-installation of packages come to fruition. If you've talked to me any time in the past couple of weeks and noticed it's a little hard to get me to change the subject, well, that's why. Many who have grown accustomed to Debian and Ubuntu's lack of support for installing i386 packages on amd64 (or vice versa) may wonder what the fuss is about. (Whereas others who are well versed in distributions such as Red Hat and SuSE may laugh and wonder what took us so long...) So maybe a few words of explanation are in order. If you've ever installed ia32-libs on an amd64 machine anywhere; if you've ever noticed a bug where ia32-libs didn't work right because of wrong system paths, or had to file a request for another library to be added to ia32-libs because it wasn't included in the set of libraries Debian decided to package up in this grotesque, all-in-one 32-bit compatibility bundle; if you've ever decided not to install a 64-bit OS on your perfectly 64-bit-capable hardware because of concern that you wouldn't be able to run $random32-bitonly_application; multiarch is for you. If you've gotten stuck maintaining a lib32foo "biarch" package in Debian due to popular demand, multiarch is definitely for you. :) If you've ever cross-compiled software for a different Debian architecture than the one you were running, multiarch is for you. If you've ever wanted to run binaries for a different architecture under emulation, and found it awkward to set up the library dependencies, multiarch is for you, too. Because although the .deb world may be a little late to the party, we're also naturally taking things much further than anyone's done with rpm. Multiarch won't just give you the ability to install 32-bit libs on 64-bit systems; it'll give you the ability to install libs for any known architecture on any system. And a whole lot of pain just falls out of the equation in the process. A cross-compiling environment looks the same as a native-compiling environment. An emulated system looks the same as a native system. We can start to seriously consider cross-grading systems from one architecture to another. And all this is happening now. The groundwork is there in Ubuntu natty. Wheezy will be the release that brings multiarch to Debian. When dpkg 1.16.0 is uploaded to unstable real soon now, the bootstrapping will begin. I am immensely grateful to everyone who's helped make multiarch a reality - to Tollef, Matt and others for seeding the vision; Aurelien, Matthias and Arthur for their work to ready the toolchain; David and Michael for the apt implementation; Guillem and Raphael for the dpkg implementation, and Linaro's support to help make this possible; and the many other developers who've helped to refine this design over the years in numerous other BoFs, sessions and mailing list threads. I'm excited to find out what the Debian community will do with multiarch now that it's upon us. Christian, maybe you should start a pool for how long it will take before all the libraries shipped in ia32-libs have been converted to multiarch and we can drop ia32-libs from the archive?

28 March 2011

Charles Plessy: Debian on an iMac

For the second time, I chose an iMac as a computer at work. I like a lot its simplicity. Only one cable, few options, a big screen and that's all. The other manufacturer where it is easy to order has a complex offer. Is the computer for playing ? for the office ? at home or in a company ? A public one, a private one ? I nervously installed Debian as soon as the machine arrived. What if it did not work, would I have to use OS X for the next three or four years ? Luckily, everything went well, and the procedure is much simpler than it looks: install rEFIt, shrink the system partition with diskutil, add two partitions for Debian and its virtual memory with Disk Utility, and restart on the Squeeze installation CD-ROM, be guided by the installer, make sure to install the GRUB on the Debian partition, not on the master boot record. Just in case I would suddenly need it, I also installed the proprietary ATI drivers, that provide graphical acceleration. I then installed Grid Engine, to take the best out of the hyper-threaded four cores of the processor. The README.Debian file is very clear and allows a simple configuration in a couple of minutes. Being a beginner, I still had to try two times, because at the beginning I was using localhost instead of a more proper name for the machine. It also took me some time to find two key parameters: slots for executing multiple jobs simultaneoutly, and priority to avoid the calculations freeze my desktop, because it is still just a desktop computer. I do not know if under OS X recent iMacs heat that much, but in these times of heater restrictions, I can conveniently heat my hands on the aluminum case of the machine. However, I am a bit worried for this summer, when restrictions will be on air conditioning.

Christian Perrier: [life] [running Post Eco-Trail update

So, the first half of my spring challenge is over. I managed to run the 50km version of Paris Eco-Trail on Saturday. 50km, this is what was advertized... The reality was 55km and, believe me, these extra 5K were worth a lot of pain..:-). I managed to complete the whole run in 6h36. As you can see, a lot slower (about 8.5km/h) than marathon races (where I managed to keep a 11.5 km/h pace) but, eh, marathons don't have 1000m positive slope! Eco-Trail is a great race. The start was in Versailles Castle park, with 5 kilometers around the Grand Canal and a few more in the castle's neighbourhood, so that the 1500-runners crowd can be a little bit dispersed before we start the forests' single track trails. Then, after 8K, we enter forests, which we won't leave until km 45, except a few street crossing here or there. Paris forests (Satory, Versailles, V lizy, Meudon, Fausses-Reposes, Saint-Cloud) are great in the springtime. The weather was a little bit "hot", which explains the quite high ratio of non finishers (11% for the 50K trail and nearly 15% for the 80K race). I managed well until KM44 where cramps began to appear. The difference between road races and trail races are rhythm differences: nobody (except the very first runners) is running when climbing hills, that would be virtual suicide. So, you have to manage this as well. My goal was keeping a 6'/km pace on the first 15K, which was quite achieved. Later on, the succession of hills makes it impossible to use one's pace as a reference. The point is mostly keeping things smooth, arrive at first food point on KM26 in very good shape and drink, drink, drink. After a 5mins stop at KM26, I started the hardest part of the trail, until KM44: this part is mostly made of ups and downs and is the real challenge: legs start burning, downhill running becomes harder and harder and you need to save some energy for the final kilometers. The second food point was in St-Cloud park, with a very nice view on the Eiffel Tower, far far away. That one is the Grail to reach...but, when here, we already have more than a marathon in our legs. So, the stop is quite longer (about 10 minutes), just to be sure about "drink, drink, drink" (eating is nearly a no-no at this point). The final 10K along river Seine, from Saint-Cloud to Eiffel Tower were really though. I was alternating walk and running, in attempts to avoid cramps (I still remember my 35K trail back in June, where I completed the last 3K with cramps in both legs, a real nightmare). I still managed to run most of the time, though very slowly. Most of us were indeed looking like zombies when crossing a small park on le Saint-Germain with kids playing football and families hanging around, enjoying the (still nice) weather. Now, even a 3-meter high climbing means walking..:-) The final kilometer was fun: at that point, you know you'll make it and you try to look proud and fine while running among the Eiffel Tower neighbourhood tourist crowd. And the applauses for the final 500meters are the real final gift with dozens of people yelling your name (it was written along with our numbers, of course!). Yay. I finally managed to finish 416th out of 1291 finishers, 50th in my age/gender category. Not that bad for the first test beyond 42K. Now the challenge is "rest, rest, rest" until April 10th and the Paris Marathon. The first marathon of my second half-century. I, of course, know that this one will be really hard. No idea, indeed, what goal I should set. Certainly not my marathon personal best (3h40'). I think I would probably already be happy to finish in less than 4 hours. If I feel really really well, I'll set 3h49' as my goal (that was my time in Paris Marathon last year). We'll see if that's crazy or not. Doh, I really have weird ideas for the gifts I offer myself for my birthday...

Rapha&#235;l Hertzog: People behind Debian: Bdale Garbee, chair of the technical committee

Bdale is a long-time Free Software believer, he has been contributing even before Debian existed in the prehistoric era of free software. :-) Anyone who went to a big Free Software conference has seen one of his colorful t-shirts. Or maybe you have heard the story where he got his beard shaved by Linus Torvalds to raise funds to protect the Tasmanian Devil. More seriously Bdale has played and continue to play a number of important roles in the Debian community. He also represents one of the biggest corporate sponsors (both for DebConf and for the servers that Debian owns): Hewlett Packard. My questions are in bold, the rest is by Bdale. Who are you? I made my first personal contribution of source code to what we now call Free Software in 1979. I started with HP in 1986 and for nearly a decade have served the company as Chief Technologist for Open Source & Linux. I am president of Software in the Public Interest, which is the umbrella organization providing legal and financial existence for Debian in the USA. I also represent users, developers, and Debian interests on a number of boards including at the Linux Foundation and the Freedombox Foundation. I m happily married with two children. Many people in Debian have met some or all of my family. They all joined me for Debconf in Edinburgh, and my daughter Elizabeth also attended in Caceres and New York. I joined Debian in 1994. I ve been responsible for a number of packages essential to our base system continuously since that time. But I ve also contributed to the project in many other ways over the years. I ran the first server that was fully dedicated to Debian. Ideas of mine influenced the development of project infrastructure, from the early design of our mirror network to structuring the archive around a package pool . I started or made significant early contributions to 5 ports of Debian to non-i386 architectures. I served as Debian Project Leader (DPL) in 2002-2003, was acting Secretary for a while, and have served on the Technical Committee for a number of years. Over the years, I ve also had some interesting hobbies. I helped design, build, and program pieces of various amateur radio satellites. I enjoy making physical things, and have many tools for working in wood and metals. My son and I are very active in the world of high power model rockets. And with my partner (and fellow Debian developer!) Keith Packard I m now running a small business making and selling open hardware and open source avionics for hobby rockets. You can read more about that at http://altusmetrum.org. You re the chair of the Debian technical committee. Can you quickly explain the role of this committee? I think many people assume the Technical Committee has a larger role in Debian than it really does. Section 6 of Debian s constitution defines the official role of the Technical Committee. Most importantly, the committee exists as a last resort place to resolve technical conflicts between Debian developers that they are unable to resolve by themselves. Most of the power in Debian is left in the hands of individual developers, who are usually able to collaborate with each other to make good technical decisions. So the Technical Committee s resolution process has only rarely been needed, which I think is a very good thing. From my point of view, the technical committee is not working. In many cases, the committee does not take any (timely) decision and just waits until the underlying situation has evolved to a point where the intervention of the committee is no longer needed. Do you agree with this and how can you explain it? I think it s very important for all of us to remember that everyone working on Debian does so voluntarily, and people who volunteer their time generally deserve a measure of respect and appreciation for their efforts. No issue is brought to the Technical Committee unless resolving it is expected to be really difficult, or at least contentious. And often, the issues brought to the committee have been as much or more about personality than technology. That makes some of them really hard to solve. So I do not agree that the technical committee is not working. It seems to me that the decisions that bog down and take a long time are the ones where arguments start out or become emotional instead of technical. In this context, if committee members can help lead public and private discussions in a way that causes a situation to evolve to the point where a decision is no longer needed, that may be healthier for the project in the long term than a quick vote that satisfies some contributors at the expense of others. The last important change that was made to try to revive the committee was the addition of two new members (Don Armstrong and Russ Allbery). Is there anything else that could be tried? The biggest improvement I could personally wish for is something people sending issues to the committee can help with. As the ultimate technical decision making body for a project whose output is mostly software, the more a request can be put in terms of a decision about source code, the easier it will be for us to make a decision. That won t always be possible, but when we re forced to try and dream up alternatives and then figure out whether anyone would actually be willing to write the code to implement those alternatives, the process takes a lot longer than choosing between competing patch sets or deciding whether a patch should be included. Besides your role in the technical committee, you have held the role of mediator/facilitator/advisor on numerous occasions. Because you re an old wise bearded guy who travels a lot and knows many Debian contributors I would like to thank you for all this work that few people notice. Are there been times where this has been a real burden for you? Thank you for mentioning this. I ve put a lot of my heart into Debian over the years, largely because it s a project and a community that continues to amaze and inspire me. I feel fortunate to have been able to meet and work on Debian with so many outstanding people from around the world. Many are now my friends, with all the silly and serious things being a friend implies. I ve been asked for and have given advice many times. I ve helped celebrate birthdays, marriages, new jobs, and the arrival of children. Sadly, I have also found myself having to try and find the right words to mark the loss of some of these friends The only time any of this feels like a burden is when there s some important problem that many people care about, that I m working behind the scenes to help fix, but can t really talk about publicly without causing more harm than good. It s distressing to have people think you don t care or aren t helping, when really you re doing everything you possibly can just not in a publicly visible way. Of course I understand that this is an impossible situation. If you can t see what s happening, there s no way to know if something is happening or not. That s why I advocate doing as much as possible in Debian, and SPI, and everywhere else I contribute in as open a way as possible. You have been Debian Project Leader and you promoted the vision of Debian as the Universal Operating System. What does universal mean for you? The biggest thing to me at the time was the idea that Debian could be anything. Those who chose to work on Debian would ultimately determine what Debian became. I also wanted to make sure we thought about as broad a set of potential users and collaborators as possible. But this vision provided a framework for pursuing a whole range of worthwhile increases in Debian s scope of utility, some of which I articulated in my DPL platforms, some others put forward. Internationalization, porting to more supported architectures, our inclusive and evolving approaches to accepting new developers and new packages, and so forth. I think this vision has served us well, and it pleases me that it has stayed a part of our collective thinking for so long. We re again in Debian s electoral period, what do you think of the work done by the current DPL? I m very happy with what I ve observed of Stefano s activities during his first year as DPL. He has an obvious enthusiasm for Debian, communicates well both in one to one interactions and in front of a crowd, and I think represents Debian very well. It is interesting that he s running unopposed for re-election this year. I choose to interpret that as evidence he s doing a good job, the project is running well, and nobody feels the need to try and take the job away From him. I m glad he s willing to continue in this role for another year. What s the most important thing that Debian should achieve in the wheezy timeframe? I don t yet have a very crisp personal wish-list for wheezy. But I would certainly like to see multiarch support finally completed! I m also very interested to see what comes from the CUT work. You have been an early supporter of multiarch , a project to allow easy installation of foreign architecture packages. It s on good track for Wheezy. Do you think it s an important milestone? My original motivation for requesting multiarch support was to enable support for 32-bit x86 binaries on ia64 Itanium systems, in the time leading up to the sarge release. I ended up creating the ia32-libs package, which I m not proud of. The emergence of 64-bit extensions to x86 (the amd64 architecture) made this a much broader issue. Today, I run a 64 bit kernel and a 32 bit user space on my notebook. There are problems with just moving entirely to 64 bit but I would like to be able to run some applications that work with large data sets in full 64 bit mode!
Thank you to Bdale Garbee for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Twitter and Facebook.

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

Next.

Previous.