While other people are squashing RC bugs I was using this week to fix (or investigationg) some more kFreeBSD issues -- mostly looking at failed build logs and trying to fix the problems and after some nice fish for dinner writing things up.

• First issue this week was #639178 a build failure in tar I had reported earlier and didn't manage to process the response. After sending some findings to the bug I noticed Petr was faster and did actually find out a lot more detail. Short story: success in that test suite requires linux behavior and the failure on kfreebsd is covered by what POSIX allows
• #640156 multiarch related changes resulting in a nonfunctional ldd breaking clutter-gst build
• #640012 postfix is hard-coding kFreeBSD versions up to 7 and therefore won't build on a 8.2 kernel. It also doesn't handle absence of NIS on Hurd and kFreeBSD #545970
• #640159 iozone3 just needed a bit of massaging to combine the FreeBSD backend with the linker flags needed for kFreeBSD
• Installing the build depends for openjdk-* resulted in a installation failure for some time. Looking closer it turned out a minimal testcase was installing menu and python2.6 together. Turned out dash's test builtin wasn't working #640334 because it was relying on the intuitive but not POSIX mandated behavior of the faccessat syscall #640325
• #640341 ed decided not to build on kfreebsd-i386 in the 40 minutes between -2 and -3 upload. Without any actual source changes. Just trying agan tricked it to build again but probably someone should look what went wrong actually
• #640378 leveldb needed enabling the FREEBSD_OS kind of build with the linux style of linker flags (additional -lrt)
• #640385 owfs was failing to some symbol difference (but otherwise building although being a *fs ;))
• the gcc family of packages still has some heisenbug repeatedly failing when doing regular builds on the buildds. Independent which one. Multiple times in a row. Building on my test VM or my notebook doesn't show that problem (but takes ~10h). Building on the same buildd in the same chroot with the same sbuild flags and it's still building fine.

I bought a new PC a few weeks ago and I then decided to renew a bit my Desktop, my Mutt and my Irssi setup. I ve been spending several hours cleaning up old scripts, logs and configuration files but the result definitely seems to reward me the right way. But here they come a few screenshots: Desktop Irssi Mutt If you liked all the above and would like to reproduce everything yourself, you should consider having a look at my GitHub s repository. See you on the next blog post!

[UPDATE 2011-09-05]I received some questions (or saw them), which I tried to answer with a follow-up entry.[/UPDATE] As I tried to explain this a few times in the past to others and had trouble myself, when I started using Linux, I thought I take some time today and write down what parts comprise the Linux graphics stack and how they interact. I'll ignore some parts which aren't too interesting to an average user at the moment, to keep this post as consise as possible. Apart from that, I hope I'm able to put all the relevant data into one spot. Let us start our little journey in the kernel. There, in a directory named gpu you'll find the drm directory, which contains all DRM drivers. In this post, we'll focus on those. The drivers in that directory are the kernel side of the Direct Rendering Infrastructure (DRI) and are responsible for managing concurrent access to the graphics hardware. They also provide interfaces to pass commands and data to the GPU. The DRI wiki explains the three main purposes of the DRM modules. The DRM module is also the part that decides whether KMS or UMS is used. Other acronyms you might hear with regard to graphics acceleration on Linux and are referring to the Kernel part are:

• GEM: an Intel-developed memory management system for GPUs.
• TTM: refers to the memory management system used by almost all non-Intel drivers (e.g. AMD's Radeon drivers). The TTM interface is "GEM-ified", meaning it offers the same API as GEM.

Apart from that, every driver has its hardware-specific parts like utilizing power-saving functions of the respective GPUs, loading firmware, if required, etc. Now we move from Kernel space to user land. We'll ignore any non-X and non-Mesa parts (like acceleration for TTYs). That means, that our next GPU specific part is most likely the DDX. (Please note, that the classic DDX might be replaced by a Gallium3D state tracker, currently that would be the xorg state tracker, but xorg will be replaced by XA. This is only an option if the Gallium driver for your GPU supports one of those state trackers, see the Gallium status page for further details.) The DDX for your GPU offers plain (2D) X acceleration on your hardware. The respective DDX' are generally named xf86-video-[NAME], where [NAME] is replaced by e.g. ati or intel. The DDX decides which X acceleration paths are available. Acronyms you might hear, referring to the DDX part of the graphics stack, are:

• EXA: even though it looks like an acronym, the X.Org wiki Glossary defines it as:

  acceleration architecture with no well-defined acronym

  EXA superseded the older XAA and offers 2D acceleration, often in conjunction with XRender.
• UXA: more or less EXA for Intel GPUs.
• GLX: actually not a part of the DDX, but an extension for X. It provides a way to draw with OpenGL into an window managed by X.
• XRandR: An extension for X which needs to be supported by the DDX to work. It offers a standardized way to set up (multiple) heads (e.g. resolution, position, rotation, etc.).

We're almost through: the last important part is the 3D acceleration offered by a Mesa driver. Mesa drivers come in two flavours: classic (e.g. all Intel drivers which are supported by Intel) and Gallium3D-based (like the drivers for Radeon chips from the R300 onwards). The difference here is, that the Gallium3D drivers try to share as much code as possible (and thus simplify writing a new driver supporting many platforms, systems and technologies), while the classic drivers are specific to certain platforms, chips, and technologies. They share much less code among each other. All parts of Mesa need direct access to the graphics hardware (DRI) The Mesa drivers use the 3D pipeline of the GPUs for accelerated drawing, even for non-3D applications like video acceleration (recently VDPAU, XvMC and VA support were added to Gallium3D, driver support followed quickly). Otherwise the Mesa drivers are mainly used for OpenGL acceleration. Users of OpenGL include scientific programs, CAD and of course games. This concludes our little journey through the various parts of the Linux graphics stack. I hope it helps in understanding the building blocks.

Another cat posting, about 100 KiB worth of images embedded so follow to the main article to read it, I don t want Planet readers to suffer from traffic overuse.

This is my monthly summary of my Debian related activities. If you re among the people who made a donation to support my work (91.44 , thanks everybody!), then you can learn how I spent your money. Otherwise it s just an interesting status update on my various projects. Dpkg work When I came back from Debconf, I merged my implementation of dpkg-source --commit (already presented last month). I continued some work on the hardening build flags but it s currently stalled waiting on Kees Cook to provide the required documentation to integrate in dpkg-buildflags(1). Following a discussion held during DebConf, Michael Prokop has been kind enough to setup a git-triggered auto-builder of dpkg (using Jenkins). You can now help us by testing the latest git version. Follow those instructions:

$ wget -O - http://jenkins.grml.org/debian/C525F56752D4A654.asc   sudo apt-key add -
$ sudo sponge /etc/apt/sources.list.d/dpkg-git <<END
deb http://jenkins.grml.org/debian dpkg main
END
$ sudo apt-get update && sudo apt-get upgrade

On the bug fixing side I took care of #640198 (minor man page update), #638291 (a fix to correctly handle hardlinks of conffiles), #637564 (the simplification logic of union dependencies was broken in some cases) and #631494 (interrupting dpkg-source while building a native source package left some temporary files around that should have been cleaned). WordPress update I released WordPress 3.2.1 in unstable (after having taken the time to test the updated package on my blog!) and fixed its RC bug (#625773). In the process I discovered a false positive in lintian (I reported it in 637473). Gnome-shell-timer package From time to time, I like to use the Pomodoro Technique. That s why I was an user of timer-applet in GNOME 2. Now with the switch to GNOME 3, I lost this feature. But I recently discovered gnome-shell-timer, a GNOME Shell extension that provides the same features. I created a Debian package of it and quickly filed some bugs while I was testing it (two usability issues and an encoding problem) QA Work During DebConf I met Giovanni Mascellani and he was interested to help the QA team. He started working on the backlog of bugs concerning the Package Tracking System (PTS) and submitted a bunch of patches. I reviewed them and merged them but since they were good, I quickly got lazy and got him added to the QA team so that he can commit his fixes alone. It also helps to build trust when you have had the opportunity to discuss face to face. Vacation That s not so much compared to usual but to my defense I also took 2 weeks of vacation with my family. But somehow even in vacation I can t really forget Debian. Here s my son:
Thanks See you next month for a new summary of my activities.

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

over 3 months without a posting about my RC bug squashing activities. that also means I hardly looked at any bugs in packages I'm not (co-)maintaining. anyway, here's the list of fixed RC bugs:

• #533934 pperl: "pperl: FTBFS: tests failed directory"
  upload package prepared by dam (pkg-perl)
• #611361 src:libjifty-plugin-chart-perl: "libjifty-plugin-chart-perl: FTBFS due to failing test"
  bump build dependency (pkg-perl)
• #611368 src:jifty: "jifty: test t/TestApp/t/03-static.t failing"
  upload new upstream release prepared by fsfs (pkg-perl)
• #614086 dates: "FTBFS: undefined reference to symbol 'pango_layout_set_indent'"
  add Ubuntu patch, upload to DELAYED/2
• #627232 src:libpadre-plugin-javascript-perl: "libpadre-plugin-javascript-perl: mkdir /.padre: Permission denied at /usr/share/perl5/Padre/Constant.pm line 119"
  upload fixed package prepared by mxey (pkg-perl)
• #627269 src:libpoe-component-ikc-perl: "libpoe-component-ikc-perl: failing tests"
  upload new upstream release (pkg-perl)
• #627272 src:libdancer-plugin-rest-perl: "libdancer-plugin-rest-perl: failing tests"
  upload package prepared by mxey (pkg-perl)
• #627285 src:libpoe-api-peek-perl: "libpoe-api-peek-perl: failing tests"
  upload new upstream release (pkg-perl)
• #627865 src:libnet-ssleay-perl: "libnet-ssleay-perl: FTBFS due to dependency cycle (Perl 5.12 migration)"
  remove build dependency (pkg-perl)
• #627963 libtest-spelling-perl: "libtest-spelling-perl: Test::Spelling tries to modify constant"
  upload new upstream release packaged by periapt (pkg-perl)
• #628297 src:libautodie-perl: "libautodie-perl: FTBFS: tests failed"
  don't run author tests (pkg-perl)
• #628306 src:gopchop: "gopchop: FTBFS: libtool: Version mismatch error."
  update handling of auto-foo stuff, dh-autoreconf etc.
• #628359 src:libpod-2-docbook-perl: "libpod-2-docbook-perl: FTBFS: tests failed"
  skip a test that needs network access (pkg-perl)
• #628739 libzeromq-perl: "Depends on missing (on some arches) libtask-waken-perl"
  fix typo in depends (pkg-perl)
• #629292 src:libtest-warn-perl: "libtest-warn-perl: FTBFS with perl 5.14: test failures"
  upload new upstream release prepared by periapt and ghedo (pkg-perl)
• #629561 dates: "dates: not installable in sid"
  fixed by the rebuild for #614086
• #629670 src:libpar-packer-perl: "libpar-packer-perl: FTBFS: main.c:79: undefined reference to pthread_atfork'"
  close, perl needed a binNMU for multi-arch (pkg-perl)
• #629724 src:libstring-errf-perl: "libstring-errf-perl: FTBFS: unsatisfiable build-dependency: perl (>= 5.13.4) but 5.12.3-7 is to be installed"
  switch order of build dependency (pkg-perl)
• #629743 src:libwww-google-auth-clientlogin-perl: "libwww-google-auth-clientlogin-perl: FTBFS: unsatisfiable build-dependency: perl (>= 5.14) but 5.12.3-7 is to be installed"
  switch order of build dependency (pkg-perl)
• #629745 src:libcgi-application-plugin-tt-perl: "libcgi-application-plugin-tt-perl: FTBFS: unsatisfiable build-dependency: perl-modules (< 5.12) but 5.12.3-7 is to be installed"
  upload already fixed package (pkg-perl)
• #633742 src:libdbix-class-schema-loader-perl: "libdbix-class-schema-loader-perl: Can't locate Carp/Clan.pm in @INC"
  add missing (build) dependency (pkg-perl)
• #633764 src:starman: "starman: failing tests"
  upload new upstream release prepared by ghedo (pkg-perl)
• #633830 src:libperl-apireference-perl: "libperl-apireference-perl: FTBFS withPerl 5.12.4: doesn't know about 5.12.4"
  add a patch to support perl 5.12.4 (pkg-perl)
• #633973 src:libgtk2-notify-perl: "libgtk2-notify-perl: Needs porting for libnotify 0.7 API"
  add patch from Ubuntu (pkg-perl)
• #634571 src:libmojolicious-plugin-basicauth-perl: "libmojolicious-plugin-basicauth-perl: FTBFS: Can't locate object method "client" via package "Mojolicious::Lite" at t/auth.t line 60"
  upload new upstream release (pkg-perl)
• #634582 src:libhtml-template-expr-perl: "libhtml-template-expr-perl: FTBFS: tests failed"
  patch out version requirement (pkg-perl)
• #634593 src:libpoe-component-client-http-perl: "libpoe-component-client-http-perl: FTBFS: tests failed"
  don't run another test that needs internet access (pkg-perl)
• #636423 src:libgtk2-notify-perl: "FTBFS on various architectures: test suite failures"
  tune test suite (pkg-perl)
• #637033 src:libhash-fieldhash-perl: "libhash-fieldhash-perl: FTBFS: unfullfillable first alternative in build-depends"
  upload package prepared by dam (pkg-perl)
• #637733 libcgi-application-extra-plugin-bundle-perl: "libcgi-application-extra-plugin-bundle-perl: FTBFS: missing (Build-)Depends on libdigest-sha1-perl"
  add patch to use Digest::SHA (pkg-perl)
• #639060 src:xacobeo: "xacobeo: FTBFS: /usr/include/gtk-2.0/gdk/gdktypes.h:55:23: fatal error: gdkconfig.h: No such file or directory"
  add multiarch dir to include_dirs (pkg-perl)

I often hear criticism of "negative campaigning" in the free software movement. For example, in reply to a blog post I once wrote about an FSF campaign, several people argued against, "negative campaigning of any sort, in any realm." Drawing an analogy to political smear campaigns, some members of the free software community have taken the position that negative campaigning in general is not useful and that negativity has no place in our advocacy. First, it is important to be clear on what we mean by a negative campaigns. I believe that there is a fundamental difference between speaking out against policies or actions and smear campaigns that employ untrue claims, ad hominem attacks, and that attempt to avoid a real conversation about issues. I will categorically condemn the latter form of smear campaigning in campaigns for software freedom or for anything else. That said, negativity directed at negativity has had a positive effect in many social movements. I have supported and participated in "negative" campaigns against proprietary software, software patents, DRM, centralized network services, and the firms behind these practices. I've done so because I believe that if one is taking an ethical position, it is justified, and often necessary, to not only speak about the benefits of freedom but against acts of dispossession and disenfranchisement. In some of the most effective social movements, unambiguously negative messages have been central. Should a campaign for abolishing child labor talk only about how valuable adult workers are to their employers or how happy kids are when they don't work? Should a campaign trying to abolish land mines talk only about the benefits of bomb-free fields and intact lower limbs? Should a free speech organization only speak out about the social welfare brought by a free press and never against acts of censorship? These may seem like outlandish comparisons but you can find people writing, only a couple centuries ago, about how slavery should be abolished by arguing in favor of the benefits of paid labor. Even if the economic arguments in favor of paid work are strong, these arguments seems irrelevant and offensive today. Whether slavery is more or less efficient is a moot point. Society has rejected it because it is wrong. We have made important strides toward eliminating injustices like child labor and slavery because activists waged decidedly negative campaigns against them and convinced others to join in opposition. In doing so, activists declared the status quo unconscionable and created an ethical responsibility to find alternatives and to redefine what was "realistic." While I will not suggest that the movement for software freedom is comparable in ethical weight to these other causes, I know that the free software mission is similar in kind. Of course, if one does not think that user control over technology is an ethical issue but is instead merely a matter of choice, one will probably oppose negative campaigns. It is also possible that a particular negative campaign is tactically unwise in that it is unlikely to reach a large audience, unlikely to change people's minds, or be difficult to carry out successfully. But such campaigns are a bad idea because they are ineffective, not because they are negative. Additionally, a movement that is purely negative and offers no reasonable alternative to the stated ill may also be unlikely to succeed. This is why, for example, I believe it is good that the FSF uses the large majority of its resources in the "positive" role of supporting free software. For those that do treat technological empowerment as an ethical ideal, it is both justified and essential to condemn the systematic disempowerment of others through non-free software just as we celebrate the benefits of software freedom. "Negative" campaigns against proprietary software, software patents, and DRM in music have already led our community to important -- if incomplete -- victories. The desire to right wrongs has been a critical part of our movement's success and of many others'. We would be wise not to give it up.

Several modern complex file formats are based on a ZIP container: this is at least the case of OpenDocument and EPUB. However, they are not simply a bunch of files joined into an archive, but they follow some rules in order to be easily recognized by tools such as file. As I had to unpack, modify and repack such a container, here is a recipe to do that.The zip command is flexible enough to allow you to work in place (I am not sure that it is really in place) to add, remove and replace files in the archive, however I find it more convenient to work on the unpacked tree and repack later. Unpack and work To unpack, just unzip, being aware that these containers do not have a root directory, so it is better to extract them to a dedicated directory. Modify as you wish; if you add, remove or replace files, remember that there is a file list to modify accordingly: META-INF/manifest.xml for OpenDocument, OEBPS/content.opf and possibly OEBPS/toc.ncx for EPUB. Repack To repack, you must create a ZIP archive without extra file attributes, and put the file mimetype uncompressed in first position. Its goal is to be visible as plain text at a fixed position, to serve as a magic file type indication. The remaining files can be stored compressed and in random order. For an EPUB, for instance, this gives the following commands:

% zip --no-extra --compression-method store ../book.epub mimetype
% zip --recurse-paths ../book.epub META-INF OEBPS

This could be automated by a dedicated script, but I felt no need to write one yet. By the way, these options can be abbreviated as -X0 and -r.

I have finally managed to setup a blog using handcrafted html and django. Having had the experience to write mloss.org, largescale.ml.tu-berlin.de and mldata.org my homepage here was done rather quickly (one weekend of hacking). If anyone is interested in website design I can really only recommend to use django. Work your way through the awesome tutorial or the book and get inspired by the sources of the many django based websites out there. Finally keep an eye on django code snippets that often contain small but useful functions and are solutions to problems you might have.

(Photo credit: Obey Arthur Liu; originally on Picasa, license.) Three weekends ago, I participated in a Debian bug squashing party. It was more fun than I had guessed! The event worked: we squashed bugs. Geoffrey Thomas (geofft) organized it as an event for MIT's student computing group, SIPB. In this post, I'll review the good parts and the bad. I'll conclude with beaming photos of my two mentees and talk about the bugs they fixed. So, the good:

• Attendance. As Luke put it, when he arrived, there was hardly anyone there. Then people showed up! And then mentorship and pedagogy happened! In all, 14 people attended, seven of whom are active in Debian or its derivatives (Ubuntu, Debathena).
• We took photos. Arthur took a wide panoramic photo, and I snapped a few good ones, too. (Thanks to Jessica McKellar for letting me borrow her camera.) Here's my full photo set.
• Good, free pizza. Props to geofft for ordering from Beauty's, and props to SIPB for picking up the tab.
• We fixed bugs! I mentored two new Debian contributors through their first release-critical bug fix. Both of them said they would attend similar events in the future. One of my mentees is now idling and asking questions in the #debian-mentors IRC channel.
• The Debian Events team republished the event. MadameZou posted the event to debian.org, giving it a nice stable URL.
• geofft made a good list of bugs to work on. He worked from the release-critical bug list, categorized the bugs by expected difficulty, and made somee short notes about how to fix the bug. This turned out quite useful.
• People printed music to the speakers. If this sounds weird, you should read the SIPB documentation for how to use Gutenbach (written by Liz Denys).
• We had a good ratio of developers to newcomers. This was hugely helpful; from what I saw, new people rarely waited very long for their questions to be answered. Thanks to Luke Faraone, Sam Hartman, Obey Arthur Liu, Karl Ramm, and Christine Spang from Debian, and Geoffrey Thomas from Debathena, for sharing knowledge.

The event was a success, but as always, there are some things that could have gone more smoothly. Here's that list:

• We hadn't prepared for people to do Debian development on Ubuntu. In particular, it took Luke and me about half an hour to come up with a pbuilder command line that worked.
• We didn't contribute to Ubuntu, just Debian. I actually think this is fine, but geofft did originally want people to work on both. He was disappointed, and we could have managed to do that if we had done more prep.
• We could have reached more prospective attendees. I know earlier in the year, daf organized a highly popular Debian packaging tutorial elsewhere on campus. I didn't see any of those people at the event, and I think some would have attended if they had known about it.
• Some people wanted a bit more context. In particular, attendees asked me about what makes a bug release-critical and what it means to do a non-maintainer upload. We could have taken some time to explain these to the whole group; instead, we dove right into hacking. Because we had so many mentors, I think people did get their questions answered, but we can't sustain that if the event grows in size.
• Mentees didn't always get high-quality help. geofft suggested Jessica work on one bug, and when she had a question, she asked Luke Faraone. Luke wasn't familiar with the bug, and he skimmed it, not realizing that the bug changed issues midway through the bug log. As a result, his initial help was unhelpful. After Luke, Jessica, and the bug were on the same page (so to speak), Jessica received clear, sound answers to questions.

Still, it turned out well! I did three NMUs, corresponding to three patches submitted for release-critical bugs by my two mentees. Those mentees were: Jessica McKellar is a software engineer at Ksplice Oracle and a recent graduate of MIT's EECS program. She solved three release-critical bugs. This was her first direct contribution to Debian. In particular:

• #636201: While updating the package for multiarch support, the maintainer of wildmidi presumably made a typo. A single character was missing from a "Replaces:" declaration in debian/control. This bug caused upgrades to fail. Sam Hartman uploaded an NMU based on a patch Jessica prepared.
• #626420: The scribus-doc package failed to build from source due to a missing build-depends entry. This one was super easy, and served as a good test package for setting up and using pbuilder.
• #565000: The switch to gcc-4.5 left hubbub unable to build from source due to new GCC warnings that made -Wall fail on the source, although it would succeed with earlier versions of the package. This led to long philosophical discussions about the particularly most reasonable fix: removing -Wall, or adding a more specific exception.

Jessica has since gotten involved in the Twisted project's personal package archive. Toward the end of the sprint, she explained, "I like fixing bugs. I will totally come to the next bug squashing party." Noah Swartz is a recent graduate of Case Western Reserve University where he studied Mathematics and played Magic. He is an intern at the MIT Media Lab where he contributes to DoppelLab in Joe Paradiso's Responsive Environments group. This was definitely his first direct contribution to Debian. It was also one of the most intense command-line experiences he has had so far. Noah wasn't originally planning to come, but we were having lunch together before the hackathon, and I convinced him to join us. Noah fixed #625177, a fails-to-build-from-source (FTBFS) bug in nslint. The problem was that "-Wl" was instead written in all lowercase in the debian/rules file, as "-wl". Noah fixed that, making sure the package properly built in pbuilder, and then spent some quality time with lintian figuring out the right way to write a debian/changelog. That's a wrap! We'll hopefully have one again in a few months, and before that, I hope to write up a guide so that we run things even more smoothly next time.

As a spectator to sporting events, there are times when the ability to read a sport(wo)man's mind would be... interesting. For instance. Yesterday's woman's 1500m final at the world athletics championships in Daegu was won by Jennifer Simpson. This was a surprise to many, including (apparently) Jennifer herself, as evidenced by the look on her face after the finish. See, for instance, this youtube clip (interesting bits around the 4 minute mark) Alternatively, I'd love to know what went through Carlos Berlocq when he won his first game in the match against Novak Djokovic in the third set. I mean, obviously nobody expected the world number one to lose from a relatively unknown 74-ranked argentine player, but that doesn't make it less painful.

Just a quick note to let you know that (like many free software hackers apparently) I have an account on Google+. I m not using it much yet but I like it in general. It s interesting to see how Google transformed Joindiaspora s aspects into circles . When Google will make an API available, I ll probably setup it like my public Facebook page so that new blog posts are automatically announced. In the mean time, it s going to be very quiet on my Google+ profile. That said, I used it twice this week: the first time because I m looking for a French developer with sysadmin skills, and the second time because I have a server to give away (Pentium IV 3Ghz, 4 Gb RAM, 200 Gb of diskspace in RAID1 Hard). If you take the server for a free software project, it can be hosted for free where it currently is (courtesy of Julien Danjou). So if you re also a Google+ user, feel free to add me to one of your circles.

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

The kernel.org compromise has people talking about the security of git's use of sha1. Talking about this is a good thing, I think, but there's a lot of smug "we're cryptographically secure" in the air that does not seem warranted coming from non-cryptographers like me. Two years ago I had a discussion on my blog about git and sha1, that reached similar conclusions to what I'm seeing here: It seems that current known sha1 attacks require somehow getting an ugly colliding binary file accepted into the repository in the first place. Hard to manage for peer reviewed source code. We all hate firmware in the kernel, so perhaps this is another reason it's bad. ;-) Etc. Well, not so fast. Git's exposure to sha1 collisions is broader than just files. Git also stores data for commits, and directory trees. Git's tree objects are interesting because they're a bag of bytes that is rarely if ever manually examined. If there was a way to exploit git such that it ignored some trailing garbage at the end of a tree object, then here's an attack injection vector that would be unlikely to be caught by peer review. If you can change the content of a tree without changing its sha1, you can simply make it link to an older version of a file that had an exploitable problem. Or you can assemble a combination of files that results in an new exploitable problem. (For example, suppose a buffer size was hardcoded in two files in the kernel, and then the size was changed in both -- make a tree that contains one change and not the other.) Now, git's tree-walk code, until 2008, mishandled malformed data by accessing memory outside the tree buffer. Was this an exploitable bug in git? I don't know. It is interesting that the fix, in 64cc1c0909949fa2866ad71ad2d1ab7ccaa673d9 relied on the parser stopping at a NULL -- great if you want to put some garbage after the tree's filename. With that said, the particular exploit I describe above probably won't work -- I tried! Here's all the code that stands between us and this exploit:

        if (size < 24   buf[size - 21])
                die("corrupt tree file");
        path = get_mode(buf, &mode);
        if (!path   !*path)
                die("corrupt tree file");

Any good C programmer would recognise that this magic-constant-laden code needs to be careful about the size of the buffer. It's not as clear though, that it needs to be careful about consuming the entire contents of the buffer. And C programmers involved with git have gotten this code wrong before. tldr: If git is a castle, it was built just after cannons were invented, and we've had our fingers in our ears for several years as their power improved. Now the outer wall of sha1 is looking increasingly like one of straw, and we're down to a rather thin inner wall of C code.

John Layt recently blogged about his adventure with having children use Plasma Active with quite some success. The task I was this evening out at a board meeting in my local scout group, and for such a event you of course need the following

• Agenda
• Treasures report
• Minutes from last meeting
• Various other papers

I ve heard from various people that an iPad is great for such meetings, and produces much less paper waste, so of course, I wanted to try with my brand new Plasma Active tablet. Before meeting So before meeting: Charge tablet & fetch needed documents.
Possible issues: Everything was on a my imap server. Minutes was a plain text file, Agenda was a docx file, treasures report was a xls spreadsheet, and the various other papers were pdf files. For fetching, I ve heard a lot about Kontact Touch and everything using Akonadi. Besides me not being fully able to properly enter my password in the first 10 tries, and a sometimes flaky internet connection, everything here was a breeze. To the three first documents, the answer was Calligra Mobile . Rendered even the docx file better than libreoffice did. And Calligra Mobile was nice and touch friendly and worked pretty well for this. There is also something called Calligra Active , which is supposed to be way cooler, but still misses at least one essential feature to be used for a touchscreen only. It can only open documents passed to it on command line. And I m not yet very comfortable with a onscreen keyboard. For the last, there was Okular. The desktop edition of Okular. I was impressed by *how* usable Okular were for a touch screen device. A quick and dirty edition of a mobile Okular could probably be done with remove all toolbars and menubars and such and if no file is passed on command line, then open a file selector window and open selected file , which shouldn t take a person knowing the Okular code much time. But that s still just the Quick and dirty edition During And during the meeting, everything worked flawlessly, except the internet on site, so I was happy I had prepared in advance. As a extra bonus, Plasma Active offered the nice KDE Games, as John Layt also mentioned, for the parts of the meeting where it was a bit boring. So. At least for me and in this case, Plasma Active did its job, at least to a A. And it is still described as Alpha software. Issues There is, though, a few important usability issues: For QWidget based applications, oxygen s nice desktop feature of being able to move the application by dragging it from almost everywhere is just completely useless on a touch screen device when you are only using full screen applications. Luckily, oxygen-settings can disable this. Update: People tells me that this has already been fixed. The Network Manager Plasma Widget, in case of no network , is very hard to activate in order to select a network. A bit larger touch area here would be very nice. Currently, it feels like it is only slightly larger than a dot: . Future Oh boy, I m looking forward for Plasma Active getting to Beta or RC status. Or Final! And btw, I m looking for a job.

There was another upsurge in discussion of Android GPL issues last month, triggered by couple of posts by Edward Naughton, followed by another by Florian Mueller. The central thrust is that section 4 of GPLv2 terminates your license on violation, and you need the copyright holders to grant you a new one. If they don't then you don't get to distribute any more copies of the code, even if you've now come into compliance. TLDR; most Android vendors are no longer permitted to distribute Linux.

I'll get to that shortly. There's a few other issues that could do with some clarification. The first is Naughton's insinuation that Google are violating the GPL due to Honeycomb being closed or their "license washing" of some headers. There's no evidence whatsoever that Google have failed to fulfil their GPL obligations in terms of providing source to anyone who received GPL-covered binaries from them. If anyone has some, please do get in touch. Some vendors do appear to be unwilling to hand over code for GPLed bits of Honeycomb. That's an issue with the vendors, not Google.

His second point is more interesting, but the summary is "Google took some GPLed header files and relicensed them under Apache 2.0, and they've taken some other people's GPLv2 code and put it under Apache 2.0 as well". As far as the headers go, there's probably not much to see here. The intent was to produce a set of headers for the C library by taking the kernel headers and removing the kernel-only components. The majority of what's left is just structure definitions and function prototypes, and is almost certainly not copyrightable. And remember that these are the headers that are distributed with the kernel and intended for consumption by userspace. If any of the remaining macros or inline functions are genuinely covered by the GPLv2, any userspace application including them would end up a derived work. This is clearly not the intention of the authors of the code. The risk to Google here is indistinguishable from zero.

How about the repurposing of other code? Naughton's most explicit description is:

For example, Android uses bootcharting logic, which uses the 'bootchartd' script provided by www.bootchart.org, but a C re-implementation that is directly compiled into our init program. The license that appears at www.bootchart.org is the GPLv2, not the Apache 2.0 license that Google claims for its implementation.

, but there's no indication that Google's reimplementation is a derived work of the GPLv2 original.

In summary: No sign that Google's violating the GPL.

Florian's post appears to be pretty much factually correct, other than this bit discussing the SFLC/Best Buy case:

I personally believe that intellectual property rights should usually be enforced against infringing publishers/manufacturers rather than mere resellers, but that's a separate issue.

The case in question was filed against Best Buy because Best Buy were manufacturing infringing devices. It was a set of own-brand Blu Ray players that incorporated Busybox. Best Buy were not a mere reseller.

Anyway. Back to the original point. Nobody appears to disagree that section 4 of the GPLv2 means that violating the license results in total termination of the license. The disagreement is over what happens next. Armijn Hemel, who has done various work on helping companies get back into compliance, believes that simply downloading a new copy of the code will result in a new license being granted, and that he's received legal advice that supports that. Bradley Kuhn disagrees. And the FSF seem to be on his side.

The relevant language in v2 is:

You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License.

The relevant language in v3 is:

You may not propagate or modify a covered work except as expressly provided under this License. Any attempt otherwise to propagate or modify it is void, and will automatically terminate your rights under this License

which is awfully similar. However, v3 follows that up with:

However, if you cease all violation of this License, then your license from a particular copyright holder is reinstated (a) provisionally, unless and until the copyright holder explicitly and finally terminates your license, and (b) permanently, if the copyright holder fails to notify you of the violation by some reasonable means prior to 60 days after the cessation.

In other words, with v3 you get your license back providing you're in compliance. This doesn't mesh too well with the assumption that you can get a new license by downloading a new copy of the software. It seems pretty clear that the intent of GPLv2 was that the license termination was final and required explicit reinstatement.

So whose interpretation is correct? At this point we really don't know - the only people who've tried to use this aspect of the GPL are the SFLC, and as part of their settlements they've always reinstated permission to distribute Busybox. There's no clear legal precedent. Which makes things a little awkward.

It's not possible to absolutely say that many Android distributors no longer have the right to distribute Linux. But nor is it possible to absolutely say that they haven't lost that right. Any sufficiently motivated kernel copyright holder probably could engage in a pretty effective shakedown racket against Android vendors. Whether they will do remains to be seen, but honestly if I were an Android vendor I'd be worried. There's plenty of people out there who hold copyright over significant parts of the kernel. Would you really bet on all of them being individuals of extreme virtue?

comments

Oh well someone came into the #cvs channel on IRC without a clue, again. I ve made a nice picture to show the competition (rival, whatever) to newbies (warning, sarcasm ahead)

Brent S. Elmer reported the Debian bug #640000 on Thursday September 1st, against evolution. Bug #630000 was reported as of June 10th. This time, it took a little bit more than 2.5 months for 10,000 bugs. This #640000 bug was indeed "fixed" very quickly as it turns out it was not a bug..:-).. Congratulations to Corsac for fixing it..:-)

Are you using DEP-5 in copyright file? Are you doing it right? Thanks to the work of Jakub Wilk, Lintian 2.5.3 will spot some of the regular mistakes (including syntax errors) and check if you are using the newest revision. This is far from the only thing Jakub Wilk has added to Lintian in this development cycle. Most of his contributions in 2.5.3 are listed next to a little [JW] in the changelog and I hope to see a lot more of those. Together with Jeremiah Foster, we have created a small POD document that hopefully will help aspiring developers. The file currently explains how the source code is divided, some core concepts and how to run specific tests in the test suite. The plan is to make it available on lintian.d.o along with a link to the git source code (#639974). Last time, I mentioned we have gotten rid of collection/fields by a simple improvement to our Lintian::Collect API. Turns out the same improvement could also be used on collection/source-control-file. This means we no longer create a file per field in the d/control of the source package. To avoid (any more) confusion, Lintian will now inform you if the package carries an override for a non-overridable tag (except if you use --quiet). On a related note, Lintian will now error out if it sees an unknown field in a vendor profile. Previously it would just silently ignore the field. There is one more change I would like to highlight and this one is probably best served with an example:

$ lintian --show-overrides ../lintian_2.5.2.dsc
N: We build-depend on cdbs for the test suite
O: lintian source: unused-build-dependency-on-cdbs
N: We build-depend on quilt for the test suite
O: lintian source: quilt-build-dep-but-no-series-file
N: We don't have a patch system for lintian itself
O: lintian source: patch-system-but-no-source-readme

Lintian will now attempt to extract and print the comment related to the override from the overrides file. The comment will be printed above each tag the override applies to (so you may see some repeated comments). The full documentation for how Lintian finds the comments (or why it does not find the comment) is available in the Lintian User Manual. The exact format of the comments being outputted may change in the near future. Particularly, we may add a marker to assist the tools generating lintian.d.o to find the comments. Hopefully we will be able to close #512901 soon. Beyond the changes above, I am very happy to see the bug count drop below 180 unfixed bugs[1]. We have not been this low there since the 2.5.0~rc1 upload (in February) and I hope we can keep it this time. Finally if you ever wanted to run your own little lintian.d.o , then you may find the Lintian harness proposal interesting. The basic idea the is to clean up the current tools and make a proper frontend out of them. Should you be interested, feel free to come with suggestions or requests. [1] Lintain bug page I use the number next to Outstanding under Status near the bottom. So pending bugs are considered fixed in my numbering.

As part of my development of a backup application, I run benchmarks on it, and that means creating a test data set, running some backups, and then removing the test data set. One of the test data sets I use is a 140 gibibytes of my real data. The benchmark first copies the data to a temporary location. In other words, a fair bit of my current life is spent waiting for files to be copied and removed. The faster that goes, the better. Overnight, I ran a little benchmark on those operations, to compare a couple of ways to do them. The results are below:

  elapsed  cmd
      (s)
    107.2  rm -rf tmp/data
     98.4  find tmp/data -delete
    100.1  find tmp/data -exec rm -rf   +
    116.2  find tmp/data -depth -print0   xargs -0 rm -rf
  elapsed  cmd
      (s)
   3567.5  cp -a tmp/data tmp/copy
   3219.5  cd tmp && mkdir copy && tar -C data -cf - .   tar -C copy -xf -

It is surprising, but it's clear that find is significantly faster than rm in deleting files, by almost ten percent. Since performance is a feature, this would indicate that that feature in rm is buggy. For file copying, the piping of two tars is a common trick, and it really is faster, again by almost ten percent. Obviously, there might also be a problem with the benchmark. I attach the script, which uses benchmark-cmd in extrautils, which I wrote for this kind of thing. If there is a problem with the benchmark, don't hesitate to provide a patch to fix that. There may be other ways to remove or copy files that should be compared, too. rsync? cpio? For file removal, a tool using Linux getdents directly would probably be faster than the portable code in GNU coreutils and findutils. Somebody should write that and compare. In all cases above, the test data set to be removed or copied is 30 GiB. Copies happened to the same disk (that's what happens with my backup benchmarks too). The filesystem used was ext4.

Folkert asks, not without reason, whether my debian-installer support for NBD is available for testing. The answer is: yes, it is! At DebConf11 in Banja Luka, I sat down with Otavio, who helped me get the necessary modules uploaded in the correct way. As such, you can now install debian to an NBD device with a regular debian-installer build although for now, you'll probably still need a daily build to get it to work[1]. To test, you should do the following:

• Download a daily image for your architecture.
• Either boot d-i with the extra boot-time argument modules=partman-nbd, or boot it in expert mode and select the partman-nbd module in the the 'download installer components' menu.

And that's it! Everything else should Just Work(tm). Well, almost. There's some loose ends that I need to fix, which I haven't had the time to look into yet. Hopefully that won't take too long. [1] It's possible that cdimage builds will work too, but I haven't tested that.