Fixing hardware Thanks to the nice Debian Swiss Knives initiative! Fixing software Besides trying to maintain the whole X stack as usual, and preparing the funky wayland, mesa, and weston trio for experimental, I got myself into other areas. Debugging gzip Jakup Wilk noticed a while ago that some multiarchified packages couldn t be co-installed due to gzipped files being different between architectures. That was reported as #647522 against the gzip package. While some developers consider the lack of determinism (as in: it s not in the gzip specification, and the current implementation generates different packages anyway!) as a dead-end for the multiarch experiment, it didn t look like undebuggable or unfixable. And indeed, as confirmed by a quick analysis: a lack of clean-up when several files are processed at once can lead to different results, depending on the order in which files are specified on the command line; the patch for that is trivial, and was later made smaller and the need for it was explained. Working in the Release Team I reviewed/approved a few packages for squeeze, but also took care of handling or finishing a few transitions (as seen in my hints file), among which the funny iceweasel9/libmozjs ones; release tools are nice, but one gets to learn lots of stuff at once (which isn t a negative aspect). I hacked a tiny collision detector so that packages involved in several transitions can be easily spotted. Given the huge number of ongoing transitions we had lately, that didn t look overkill. Squashing bugs It had been a very long time since my last working on totally random RC bugs. The Bug Squashing Party organized at IRILL was a very nice opportunity to get back to totally crazy bugs in unknown packages, but also to meet with other Debian contributors; sponsoring maintainers with good patches on their first try was nice, but walking other contributors through their first patches sent to the BTS or through their first NMUs was nice too. Waving good bye to yada Back in the M rida QA meeting I attended in 2007, there were already jokes about how bad yada was, and how it should die in a fire etc. When I started looking at the RC bug list, I quickly switched to scrolling it backwards, and I wondered how much work was left. The details can be seen in #660548, and the result is: yada is gone! sanity++; packages.debian.org Both long descriptions and translations for packages in some suites disappeared after the switch to Description-md5. Thanks to a quick and reduced packages.debian.org setup (mostly: en+de for squeeze+sid+experimental), I managed to find my way through Perl and DB files to propose patches for #657557. I m still waiting for a confirmation, but in case it works fine, we could even get a fix for DDTP/DDTSS.

The meeting was as long as the kernel changelog, the decision was as difficult as a Debian release, but in the end Le Camp has won in the voting 5 to 4. It was lucky that one member of the 10 man committee was not present or we could have had a tie, just like there was one in the first round of voting. Well, congratulations to the poor sods of the Swiss team, who will now have to fulfil what they promised and also all the small things that everyone always forgets that also need to be done for every Debconf! I think that I will try again for 2015, but before that we will try to get a few people from Latvian community to go to Debconf13 to get the Debconf and Debian experience and exposure. Meanwhile, it looks like I will be skipping this years Debconf12 it is very far away for me and as I could not find a reasonable business rationale for me being there, it would be a far and expensive vacation for me. I don t think there is enough benefit from me being there to ask for any Debian funds for this either, especially hearing how tight money is this year. So if you re going, make sure to take a camera and take a bunch of pictures, so we at home can see it too

Finally I've found some time to do small cleanup on my websites. First of all I've removed links to my Twitter and Identi.ca profiles as they are dead and I don't think I'm going to make them alive any time soon. I never really got into this business and only used it as one interface to feed posts to Facebook (via Identi.ca's app there). Together my mostly read only Facebook usage, there is nothing going on there. While touching the website code, I also did some cleanup on Wammu website (where Twitter and Identi.ca still stays as announcement media for new versions). Most notable change is that I've reduced usage of external (and in times heavy) javascript and links to social media are now just static HTML, which also nicer fit into website layout. It did indeed remove several options, but I don't think these were worth of the load it introduced.

Filed under: English Gammu 0 comments Flattr this!

A little while ago, we ran into memory problems on mahara.org. It turned out to be due to the GD library having issues with large (as in height and width, not file size) images.

What we discovered is that the PHP memory limit (which is set to a fairly low value) only applies to actual PHP code, not C libraries like GD that are called from PHP. It's not obvious what PHP libraries are implemented as external C calls, which fall outside of the control of the interpreter, but anything that sounds like it's using some other library is probably not in PHP and is worth looking at.

To put a cap on the memory usage of Apache, we set process limits for the main Apache process and all of its children using ulimit.

Unfortunately, the limit we really wanted to change (resident memory or "-m") isn't implemented in the Linux kernel. So what we settled on was to limit the total virtual memory that an Apache process (or sub-process) can consume using "ulimit -v".

On a Debian box, this can be done by adding this to the bottom of /etc/default/apache2:

ulimit -v 1048576

for a limit of 1GB of virtual memory.

You can ensure that it works by setting it first to a very low value and then loading one of your PHP pages and seeing it die with some kind of malloc error.

I'm curious to know what other people do to prevent runaway Apache processes.

Now is the point in the Debian release cycle where I usually try to go through my packages and bring them generally up to date. In case other people are doing the same thing, here are a few new facilities or techniques that I'm rolling out across my packages. (This is apart from the obvious stuff, like multiarch where appropriate and debhelper 9, and the older stuff, like using dh.)

• dh-autoreconf is a new helper tool that runs autoreconf on the package during the build and cleans up properly afterwards. I've started switching all of my packages that use Autoconf and Automake and can use autoreconf over to it. (Some upstreams have more complex scripts that have to be run to regenerate the build system.) It plugs in trivially as a dh add-on, and even adds support for --as-needed (see below). I'm doing this even for packages where I don't patch the build system, on the grounds that rebuilding everything from source, including the build system, is a good idea. It also means that I can patch the build system when I need to without having to add additional machinery at the time.
• Linking with --as-needed. As I build new packages, I'm looking for anything that has warnings about generating unnecessary dependencies and adding --as-needed to the linker flags. The combination of dh-autoreconf and the new dpkg-buildflags support makes this trivial to do for most packages. Just add something like:

      export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed

  to debian/rules. It's worth being aware that --as-needed can break some unusual uses of special cases around shared library loading, but I've not run into any of those cases with any of the software that I package.
• dpkg-buildflags comes essentially for free with debhelper 9, but it's worth mentioning that, as mentioned above, it's a really easy way to add additional flags. And if you have to pass in flags via some other mechanism, use dpkg-buildflags to get the default flags.
• Once you're up to debhelper 9 and are using dpkg-buildflags, adding hardening flags is easy. You get the default ones for free, and that's a pretty good start. (Install hardening-includes and use hardening-check to check the status of the binaries built by your package.) I always add at least hardening=+bindnow to DEB_BUILD_MAINT_OPTIONS (set with export in debian/rules), since the minor speed hit at startup doesn't matter for anything that I'm packaging. (It might for something like ls that runs all the time.) I usually try to also add +pie, but be careful of that. Libtool will cope correctly with it and switch it back to PIC for shared libraries, but other shared library build processes may not. And it doesn't always work; for example, gnubg (GNU Backgammon) just immediately dies if built PIE, for reasons that I didn't track down.
• If, like me, you maintain your packaging in Git without using a separate tool that exports a patch series, and therefore use the single-debian-patch option, there is new support for applying that option only to your build as the maintainer but not to any other build that people do of your source package. This is good, since it means that any NMU diffs will be kept separate from your maintainer diff because they'll get the version of the NMU package added. To get this behavior, move debian/source/patch-header to debian/source/local-patch-header and debian/source/options to debian/source/local-options (assuming that's your only option; otherwise, you might need to split it). Then the patch header and options won't be included in the generated source package and hence won't apply to NMUs or other packaging changes based on the source package in the archive instead of on the packaging repository.

It's also worth mentioning that Ubuntu was responsible for breaking a lot of ground here. Due to bug reports and patches submitted from Ubuntu, several of my packages already had hardening build flags and --as-needed issues fixed before this round of packaging refresh, which made adding these features much easier than it would be otherwise.

To use an SSH agent, one usually has to:

1. launch the agent;
2. add his key to it.

The first step can be automated in the desktop or shell startup script (this is a typical use case for login shell-only startup scripts, by the way), but the second one cannot if your private key is protected by a passphrase.Opportunistic key loading GNOME Keyring includes an SSH agent which has an interesting feature I call opportunistic key loading : it asks for the passphrase to decrypt the private key the first time it is needed. This feature mimics the behaviour of PGP agents, and eliminates the second step I previously mentioned. Question Do you know if there exists another SSH agent able to do opportunistic key loading?

This is half rant, half warning to others. Relative merrits of the IBM ThinkPad X31 vs the Lenovo ThinkPad X220... Old IBM ThinkPad X31 which I abused for years:

• Built like a tank
• 4:3 screen at 1024x768
• Fell down several times
• Got doused in coffee and coke
• Has been invaded (as in "filled to the brim") by Indian ants which ate out all the coffee and coke over about a week of constant occupation (even while the machine was running; I had no choice) years later
• Got hit by a truck's rear view mirror (~40 km/h)
• Got stepped upon repeatedly (not by me)
• Experienced everything from -25 to +35-40 degrees Celsius
• Experienced very high and extremely low humidity
• Survived uncounted kilometers of very rough off-road driving
• Got sprayed with sea water repeatedly
• Prolonged exposure to various kinds of abrasive sand
• I probably forgot other abuse

I upgraded the RAM, swapped the battery once and the HDD twice. If not for a loose power socket, I would still use it. Contrast my new Lenovo ThinkPad X220 after a few months of pampering:

• You can remap the blue button to something useful (nice!)
• Wide-screen 16:9 at 1366 x 768 with no upgrade option (we are talking 5 years of technological advancement being ignored)
• Cardbus slot, but only one mini and one micro PCI slot so Wi-Fi, UMTS, SSD, and spindle disk at the same time are impossible
• Charge LED can only be seen from the outside which is great when my battery starts running low. Other people do care more about my battery status than myself, obviously! Making the LED visible from both sides would cost next to nothing. This is sloppy/bad design and nothing else. I am unable to understand why anyone who ever used a portable computer would do this. Argh!
• Sleep LED can only be seen from outside
• Use of built-in 3G or GPS can totally lock up device and/or make KDE/X quit and go back to login screen
• Random segfaults of programs that cause high network load via Wi-Fi (Chrome is especially queasy)
• Random ssh disconnects when using Wi-Fi
• Random sound artifacts during high network load via Wi-Fi
• All of the above, but less often, when using wired network
• Random segfaults and other magic issues after more than a few hours of uptime and/or warmth
• Three distinct USB ports (1 x USB 3.0, 1 x USB 2.0, 1 x USB 2.0 with power pass-through) which do or do not work correctly depending on uptime and temperature
• Makes weird noises
• On-desk combined power brick and USB hub broken after a few months of sitting on my desktop and being used once every week

Google tells me there are several people with random issues with their X220, especially when the mini-PCI slot is being used in a machine with USB 3.0. Removing the UMTS/GPS module did help, but still, this means no SSD for me as that's the slot I would have to use. Recently, things have been degrading very quickly to the point where I refuse to do even simple things, like write and push blog posts, on this machine. I am not sure if I am simply unlucky and received a dud, if the X220 is a model with issues, or if this is indicative of a general trend within Lenovo, but it's time to contact Lenovo support. If I had known all of this in advance, I would simply have soldered the power socket back into my X31 and held out for the X221. Or something else, entirely.

Ben mentions he left Google Reader and went back to Liferea, but mentions a series of bugs that keep him from being happy. After pondering it a bit, a couple of months ago I also left Google Reader, but I turned to a free webapp: rssLounge aggregator. Although it does not fully cover Ben's wishlist (I'll get to it now), I am happy using it as it covers my main need: Being able to read my stuff from just about everywhere, without installing even a ssh client (that would make public Windows machines a liability for me, as they could sniff my keystrokes while authenticating to my ssh server). So, for me, a webapp is basically a must. Well, as for Ben's list:

1. MAY be a desktop or web application.
   Check. Well, I don't know what would fail this :)
2. If it's a web application, it MUST be reasonably secure, e.g. it must not be written in PHP.
   Fail. It's PHP. And that's my main reason for not uploading it to Debian I use and enjoy this app every day, but it has some bugs I don't really feel like looking into. And yes, maintaining PHP code is ugly.
3. If it's a web application, it MUST allow for multiple independent users on the same server.
   Don't really remember, I set it up just for myself. But in any case, you could install a different instance per user?
4. If it's a desktop application, it MUST embed a browser engine (presumably Gecko or WebKit) so I can follow links without having to switch windows.
   N/A
5. MUST support organisation of feeds by folders or tags, including combined item lists.
   Pass.
6. MUST keep track of which items have been read.
   Pass.
7. MUST support a global 'unread items' list. SHOULD only remove items from this list when I refresh it, not as soon as I move away from an item.
   Pass. In fact, given that storage is cheap, I have set it to never expire old entries. I don't know if it will ever be useful, but as long as it does not hurt me...
8. SHOULD support a three-pane (folder/list/item) view or something similar. Google Reader's list view with expanding items is perhaps even better, though it means links must be opened in a separate tab.
   It's more like Google Reader's
9. SHOULD support folder and item navigation by keyboard.
   Pass.
10. SHOULD have some way to flag/bookmark items for later attention.
    Pass.
11. If it's a desktop application, it SHOULD have some sort of download manager to support podcasts.
    N/A

So, Ben, with only one (big) fail, it might be a good candidate for you. PS- And hard as it might seem, I am leading an almost-Google-free life now! :) But don't let them hear this, as we want them to keep sponsoring Summer of Code and DebConf.

I switched from Google Reader to Liferea a while back. I was mostly happy with the functionality of Reader but I don't really want my reading history to be recorded or my feed list to be vulnerable to the whim of Google's inscrutable abuse department. I'm still using Liferea but unfortunately it has a lot of problems. Yes I do have bug numbers:

• Calls sync() many times while refreshing feeds (#623619). This is probably related to use of SQLite and not properly batching writes. I work around this by using 'eatmydata' to nullify those calls, but that's not ideal.
• The UI thread also blocks on feed updates. Together with the previous bug, this can make it unresponsive for minutes while updating feeds (#542276).
• It often leaks memory and other resources when I play embedded video (#660593).
• There is no progress or 'busy' indicator for the browser (#660595).
• Error/prompt callbacks are not handled (#660597) - for example, if I follow a link that happens to lead to a PDF, nothing happens.
• There is no progress indicator for downloading 'enclosed' files (typically podcast episodes), and errors are simply ignored (#660599).
• While updating feeds, it may reset the item pane back to the summary (#660602).

So, I'm looking for an alternative again. My requirements are:

1. MAY be a desktop or web application.
2. If it's a web application, it MUST be reasonably secure, e.g. it must not be written in PHP.
3. If it's a web application, it MUST allow for multiple independent users on the same server.
4. If it's a desktop application, it MUST embed a browser engine (presumably Gecko or WebKit) so I can follow links without having to switch windows.
5. MUST support organisation of feeds by folders or tags, including combined item lists.
6. MUST keep track of which items have been read.
7. MUST support a global 'unread items' list. SHOULD only remove items from this list when I refresh it, not as soon as I move away from an item.
8. SHOULD support a three-pane (folder/list/item) view or something similar. Google Reader's list view with expanding items is perhaps even better, though it means links must be opened in a separate tab.
9. SHOULD support folder and item navigation by keyboard.
10. SHOULD have some way to flag/bookmark items for later attention.
11. If it's a desktop application, it SHOULD have some sort of download manager to support podcasts.

During these days, there are various carnivals in Prague. On Saturday I've visited Malostransk masopust, which is probably not the biggest one, but definitely the one in most attractive location, starting at Prague castle and going down to Kampa. This was actually my first visit of this carnival and I quite enjoyed it. Bellow you can find some photos taken during the event to catch the atmosphere:

Filed under: English Photography 0 comments Flattr this!

Intro RAID sucks, and so do all other Free alternatives in the Linux world. Having been in exactly the same situation several times in the past, I have been following Russell Coker's posts regarding data integrity with interest. FWIW, the correct answer to "BTRFS (sic) and Xen" is: subvolumes. Now that Fedora has, once again, decided to postpone their switch to Btrfs as default file system, I decided to write up my own take on this topic. Any and all my considerations are made under the assumption that important data is backed up while semi-important data is at least living on two different machines. Beware, this is a long post, but I do like to think it's well worth reading. RAID Disk failures Let's recap the current situation for "traditional" file systems like xfs, ext 2..4 , etc. In case you need to freshen up on the technical details go here.

• Single disks: Fine for many use cases like Laptops, Desktops, etc, they are what most of us are using for most storage needs.
• RAID 0:If you are using that, you are most likely doing it wrong. Barring increasing caches for SSD-based volumes on machines which you simply take out of your cluster if there is any kind of problem, I don't know of not a sigle valid use case. Other than to get rid of data, that is.
• RAID 1: The default for small servers and important machines which don't need a lot of disk space.
• RAID 5: OK for personal storage servers, avoid once disks become larger than 500GB-1TB, depending on personal preference. To write data, you need to calculate new checksums and thus read all data from all corresponding slices, impacting write performance significantly.
• RAID 6: The RAID 10 people will disagree, but I like this RAID level best. While your write performance will definitely take a hit, you can mitigate this by decreasing your volume sizes. The extra cost in ways of power, disks, controllers, and rack space are a price we gladly pay for the ability to lose two disks and still retain all data.
• RAID 10: Great write performance until the day when two disks in the same RAID position die right after each other and your company's main mail storage dies. Yes, this has happenend to me and it sucks.
• RAID 2,3,4,50,60,foo: Mostly irrelevant in the real world; disregard.

Silent corruption All the RAID levels with redundancy are fine and dandy if you lose a whole disk and put in a new one. Of course, that does not help you the tiniest bit once you get read errors. Controllers which manage RAID 1 or 10 may or may not compare the data while it's being read and may or may not tell you about discrepancies. They can then toss a coin and give you either result. There is no way to determine which is correct. RAID 2, 3, 4, 5, and 6 could, in theory, verify the data as it's being read, but that would limit your read rate to that of a single disk so no one does that. We actually had a massive web presence fail over night, once. No one knew what the cause was as there hadn't been any kind of access logged. As that particular deployment is done directly from a VCS, we simply ran a diff and found one change. We traced the failure down to a syntax error; a one character change made everything fail. Looking at the ASCII table, it was clear that one single bit had flipped. This sucked. A lot. Mitigation So you end up scrubbing your RAID sets on a weekly basis, recovering from silent corruption with the help of your RAID 6's two parity stripes. And even though you schedule the scrubbings with the least priority, you still take a performance hit when randomly seeking a lot. ZFS Some smart people at Sun set out to fix these problems and more, and fix it they did. The "Z" in ZFS is meant to imply that this is the last file system you will ever need and if not for its license, this might have worked. Of course, "last" and "forever" mean "not now" and "10 years" respectively, in computer terms. The limits within ZFS have been chosen so that the entropy needed to create a disk able to max out a ZFS volume would, literally, require our oceans to boil. Let's just say that you won't encounter these limits any time soon. While that is a nice thing to know, it does not say anything about data integrity. There are several mechanisms ensuring data integrity built in ZFS, the most fundamental being extensive checksumming. Checksums are vastly superior to live comparisions which RAID would have to perform as it does not need to sacrifice any significant i/o reading checksum data. With HDD access, you are i/o-bound, and not CPU-bound, anyway, so performing the checksum calculations is laughably cheap when factoring in the added safety. Everything, be data, metadata, inodes, you name it, is checksummed. Every read operation must go through the checksumming functions, ensuring that all data which reaches your user space is correct. If ZFS can't verify the checksum, it will not deliver any data at all, ensuring noticeable, as opposed to silent, corruption. So how does ZFS recover when the checksum does not match the data? copies= 1..3 The easy way is to store several copies of your data within your volume. Mount a ZFS volume or subvolume with copies=2 or 3 and all data that is being written from then on will be copied twice or three times. Trivial in principle, but powerful when built into a file system. RAIDz 1..3 This is where things start to get interesting. RAIDz1, 2, and 3 will allow you to lose 1, 2, or 3 disks respectively while still retaining your data; at the obvious expense of the storage capacity of as many disks. Basically, RAIDz2 is ZFS' variant of RAID 6, but it's so much better than mere RAID 6. Moo! RAIDz will not assign fixed slices and fill them up like RAID does. It will look at the current write speeds and use appropriate slice sizes dynamically. As a direct result, data which has been written at roughly the same time will always be near other data written at the same time. This is very nice for functionality like snapshots, writeable subvolumes and other things and is called COW, ZFS' variant of super cow powers. This also enables ZFS to write data, read it back and verify the checksum and only then point to the new data. Atomic commits done right. Keep rollin' As ZFS has to keep track of what data is still in use in which volumes and subvolumes anyway, it knows which regions are free to be reclaimed. Instead of filling up random places, ZFS will roll over your disks, overwriting unused data on the fly. This bears repeating: Contrary to RAID 5 and 6, ZFS will never need to read old data in order to write new data. Write performance galore and anyone still stuck on RAID 10 can finally enjoy the increased data security. Btrfs To be completely honest, I do not know Btrfs as well as I know ZFS. If I get anything wrong, correct me. If I offend anyone with my outsider's interpretation, that is not my intention. Btrfs has been initiated by Oracle way before it ever even thought about buying Sun or history might have run a different course, for worse or a lot worse. The closing of Java, Solaris, ZFS, Hudson, OpenOffice (since then "gifted" aka thrown away), and others makes me think the latter. As there are few technological developments which caused me as much stress, overtime and pain as OCFS2, I am naturally wary of file systems sponsored by Oracle and their data focus integrity/availability. The fact that there's still no way to fsck a Btrfs volume could be birthing pain or yet another facet of Oracle's stance on this topic, I honestly don't know. Either way, it's a good idea to be wary for now. I can't say too much on Btrfs' technical underpinnings, but I know it uses COW and that it has its own variant of RAID. Toss in snapshots (writeable?), subvolumes and integrated block device management, and you have the building blocks of a decent file system. Still, Btrfs is not ready for prime time. Btrfs has been "one or two years in the future" for a few years now so I will not be holding my breath. And once the first distributions are starting to use Btrfs by default, people will lose data. A year or three after that, I will feel comfortable to use it myself and in production. Commercial solutions You can either hand a lot of money to proprietary vendors who will not tell you a thing about how things work internally (and no way to fix things directly) or you can buy solutions that employ ZFS in the back-end. I prefer my storage hardware to be relatively dumb while keeping the intelligent bits where I can see and poke them so this is not really part of these considerations. So what can you do? Test your disks before deploying them Easy, but vitally important:

disk=/dev/foo
smartctl -a $disk
smartctl -t long $disk
badblocks -swo $vendor_$model_$serial_$timestamp.badblocks.swo $disk
smartctl -a $disk

If you are lazy, get a copy of disktest, a tool I wrote to do exactly this. It should wait for the long self-test to finish, can not read out all vendor names, and does not have a way to document who ran the test, but it's a start. Patches and feedback are, obviously, welcome. And yes, I will package this soonish. Using your disks This list is surprisingly short. You can use

• distinct disks
• RAID as per above
• ZFS-FUSE
• Debian/kFreeBSD
• Nexenta

And that's it. At work, I prefer small RAID 6 volume sets. It sucks, but there is nothing better. For personal use, I have a machine with a FUSE-based RAIDz2 mounted with copies=2. Three disks can fail and my data is still secure. While this setup is slow as molasses due to FUSE, speed is not a consideration for me here; data safety is. A migration to Debian/kFreeBSD in the medium term is still likely. If you have things to add or disagree with me, I would love to hear from you. Update: Jan Christian Kaessens pointed out that, contrary to my experience, zfsonlinux did not bring down his sytem in flames. As zfsonlinux is a kernel module, potential performance is a lot better. Also, it supports ZFS Pool Version 28 as opposed to FUSE-ZFS' 23. While the really nice features are in v 29 and 30 (which are closed thanks to Oracle) v 28 still has some nice changes.

Copyright maximalists, such as MPAA and RIAA, like to say that copyright violations are theft. I don't agree, but if they are, then logically, extending copyright in a way that makes things that were out of copyright to again be in copyright is also theft. And that's happened so much it's grand larceny.

One week delayed due to DVD build problems, we managed today to wrap up and publish the first release candidate for Debian Edu / Skolelinux based on Squeeze. The full announcement is available on the project announcement list. Check it out if you need a software solution for your school.

thanks to the Paris BSP & other activities we're seeing a nice decline in RC bugs. here are my recent contributions:

• #554752 src:gtklp: "FTBFS with binutils-gold"
  add patch from Hideki Yamane, upload to DELAYED/2
• #640613 src:jaminid: "jaminid: FTBFS: xargs: /usr/lib/jvm/java-6-openjdk/bin/javac: No such file or directory"
  build-depend on default-jdk and set JAVA_HOME in debian/rules accordingly, upload to DELAYED/2
• #640630 src:policycoreutils: "policycoreutils: FTBFS: chmod: cannot access /build/policycoreutils-r6ObWS/policycoreutils-2.0.82/debian/policycoreutils/etc/init.d/policycoreutils': No such file or directory"
  apply patch from Ubuntu / Mitsuya Shibata, upload to DELAYED/4
• #640633 src:tunnelx: "tunnelx: FTBFS: xargs: /usr/lib/jvm/java-6-openjdk/bin/javac: No such file or directory"
  build-depend on default-jdk and set JAVA_HOME in debian/rules accordingly, upload to DELAYED/2
• #642686 src:javamorph: "javamorph: FTBFS: /bin/sh: 1: /usr/lib/jvm/java-6-openjdk/bin/javac: not found"
  build-depend on default-jdk and set JAVA in Makefile accordingly, upload to DELAYED/2
• #645493 src:postler: "Will FTBFS with libindicate 0.6"
  apply patch from Evgeni Golov, upload to DELAYED/2
• #646388 speech-dispatcher: "FTBFS due to locally changed files without patch"
  update autotools handling, partly taken from Ubuntu / Luke Yelavich, upload to DELAYED/2
• #646647 src:latex-cjk-chinese-arphic: "latex-cjk-chinese-arphic: FTBFS: The requested file, gbsn00lp.ttf, does not exist"
  apply (modified) patch from Hideki Yamane, upload to DELAYED/2
• #652222 src:sensors-applet: "sensors-applet: FTBFS: Could not parse DTD http://scrollkeeper.sourceforge.net/dtds/scrollkeeper-omf-1.0/scrollkeeper-omf.dtd"
  add patch to use local DTD, upload to DELAYED/2
• #652758 src:policycoreutils: "policycoreutils: FTBFS: cc: error: /usr/lib/libsepol.a: No such file or directory"
  multiarchify, based on patch by Hideki Yamane, upload to DELAYED/4
• #658054 instead: "Can not upgrade package instead, because new package instead-data try rewrite files from old package instead."
  add a comment to the BTS

A few people have been using the license-count tool that I wrote to analyze the breakdown of licenses in Debian and draw some conclusions. Unfortunately, some of those conclusions can't be drawn from the output of this specific tool (which doesn't make them wrong, just unproven). So here are a few cautions. license-count was written for a specific purpose: to see how many references there are to a particular license in Debian so that we had some facts behind our discussion of whether to include it in common-licenses. It was not written to classify packages into particular categories, only to find out how many copies of a license we could save by adding it to common-licenses. This means that using it to determine how much software in Debian is covered by a particular license fails in the following ways:

1. license-count numbers cannot be added. Since the goal is to find every reference to a given license, each package is not classified as under one and only one license. If a package has material under the GPL, the LGPL, and the GFDL, it will add one to each of those counts. This means that you cannot determine, from its output, questions like "how many packages are covered under one of the GPL family of licenses?" You will double- or treble-count packages when you add the numbers together.
2. license-count counts any reference, not just "important" ones. If the license is referenced in debian/copyright, that counts, since the goal is to see how many packages might benefit from being able to reference it in common-licenses. This may not be the license that the package is under, just some small portion of the package. For example, all of my packages that use Autotools add to the GPL count because I include all the source code licensing statements, including the statements for libtool and the Automake helper scripts, which say that the files can be released under either the GPL or the license of the including package. These packages are generally under a BSD-style license (or in some cases the Apache 2.0 license), not under the GPL, but since the reproduced license text has a reference to the GPL, license-count adds one to the GPL column for each of those binary packages. For most purposes for counting GPL-covered software, these are false positives. I don't know how many people are as complete in documenting license statements as I am, but just the binary packages that I maintain probably count for at least 50 false positives because of this alone.
3. license-count numbers include dual-licensing. Whether this matters for your analysis or not depends on what question you're asking, of course. If you're asking whether the package is covered under a copyleft license, including the thousands of packages that are dual-licensed under the Artistic license and the GPL may be okay, since the Artistic license is a sort of copyleft (although it allows you to avoid the copyleft requirement by renaming executables, providing the originals, and documenting your changes). But, for example, one of my packages is dual-licensed under a BSD-style license and the GPL (for reasons that aren't worth getting into). This package is not covered by copyleft under any reasonable definition of the term, but license-count will count it as a package using the GPL.

In order to draw interesting conclusions like "how much software in Debian is protected by copyleft," I'm afraid that you'd have to write a much more sophisticated tool than license-count.

That s sad. Hardware that was supported sometime ago, it s now unsupported.
I have no idea how to install Debian on Sony Vaio laptop.
Tried all possibilities.

I've released version 0.25 of Obnam, my backup application.

• Log files are now created with permissions that allow only the owner to read or write them. This fixes a privacy leak.
• The nagios-last-backup-age subcommand is useful for setting up Nagios (or similar systems) to check that backups get run properly. Thanks to Peter Palfrader for the patch.
• Some clarification on how the forget policy works, prompted by questions from Peter Palfrader.
• New settings ssh-known-hosts (for choosing which file to check for known host keys), strict-ssh-host-keys (for disallowing unknown host keys), and ssh-key (for choosing which key file to use for SSH connections) allow better and safer use of ssh.
• Checkpoints will now happen even in the middle of files (but between chunks).
• The --pretend option now works for backups as well.

BUG FIXES:

• obnam ls now shows the correct timestamps for generations. Thanks, Anders Wirzenius.

<style type="text/css"> @import "/pub/special-css/venk.css"; </style> My friend Venkatesh, pictured above, is going to bike four thousand miles, all the way across the continental US, from Baltimore to Portland. He's doing it to raise money for the Ulman Cancer Fund for Young Adults. I'm writing this because I want you to donate money to his cause. He's a DragonFly BSD developer, loves bikes, and your donation could make a big difference. I first met Venkatesh through the Johns Hopkins computer club, an ACM chapter. I was the head of the club, and he had just started his career at Hopkins. He was looking for advice on running Brickwiki, the LEGO encyclopedia. Quickly, I became his friend; in that time, I've learned the following things about him.

• He is friendly!
• He believes in science; beyond just writing sharp code, he likes to ask questions.
• He is melodramatically attracted to the power and complexity of biology. (The above quote about cancer are his words.)
• He wants to do something to make cancer less of a killer.

In the years since I graduated from Hopkins, I've been impressed by Venkatesh's ongoing curiosity and contributions to open source projects like DragonFly. I'm honored to have this chance to help him bike across the country for a good cause. Here is a quick word about the 4K for cancer effort:

Since 2002, groups of college students have undertaken a 70 day, 4000+ mile summer bike ride across the United States with the goal of offering hope, inspiration and support to cancer communities along the way. This past summer was our 10th year of cycling across the country as 76 volunteers rode along three different routes: Baltimore to San Francisco, Baltimore to Portland, and Baltimore to Seattle. Our riders raised a combined $476,000 to support organizations and individuals in the fight against cancer.

His fundraising goal is $5,000. Anything from $5 to $500 is a donation to an organization that helps young adult cancer surviers and their families get access to information and support resources. Can you help?

When I told people of my plans to move to Montreal, it usually prompted one of two reactions: one was some version of joyful envy, many people exclaiming breathlessly Montreal is one of my favorite cities, one person once even clutching my arm and told me as he looked me straight in the eye: you are so lucky, there is no city quite like Montreal in North America. The second reaction came off as a thinly veiled mixture of disdain and disbelief usually peppered with many reallys: oh wow, really, really you would really leave NYC? I am pretty certain they really were thinking something along the lines of what a fool, how dare she leave a great job, a great university, a world class city (the only city to live) for some Canadian mid-sized city, which is like tundra for a good chunk of the year? The decision to move weighed heavily on me, if for no other reason I had a choice to stay or to go and I honestly have not had a choice, a decision to make about where to go since I got accepted to graduate school (and even then the choice was more obvious than this one). So over a month into my move what is my verdict? In a word, win. I don t miss NYC at all though I get why some people cannot leave the place and know that despite some oddities and difficulties of living in Montreal, it fits my tastes and needs much better than NYC which dwarfed me in so many ways. I never felt I could enjoy it, I grew tired of the cramped living quarters, the noise ate at my soul, and I simply felt more overwhelmed by the fact that I could not even get a handle on the neighborhoods in my vicinity, much less all the other hoods in the area. Instead of dogging NYC anymore, I think I will spend a little time on first impressions, as they will soon be lost to the familiarity borne with time and experience. In essence Montreal is chock full of life but rather intimate, a quirky city with lots of charm but some grit and lacking the way over designed and done feel of cities like Portland. Here are some of quirks: 1. The Hawt Metro: I fell in love with the Metro when I first rode it a few years ago. I just love the powder blue color of the cars and the super sweet 1960s aesthetic of many stations. Even better and unlike NYC, they are just clean and quiet. The downside? The temperatures approximates a sauna during the winter and while you would think this is a good thing, when you are layered with the clothing necessary to survive outside (re: long underwear along with Canada-coat, gloves, hat, and scarf), it is hooooooot down there and you feel like you need to pass out. 2. Spend money, get free stuff: In many establishments you get free stuff (like blueberries or some like sports bar) when you spend over a certain amount of money, like 70 bucks. Quirky local tradition. 3. The culture of negotiation and the kick ass standard lease: Housing is amazing here. There is plenty of it, there are many different styles, and it is rather fun exploring all the different hoods that make up the city. Problem is too that lots of apartments have weird problems and issues and I had to steer clear of anything that could even possibly have mold. I spent weeks day in day out looking for a place, desperate to move out of my corporate apartment very nicely provided by the university but still not my ideal living situation. Finally found a place that fit all my needs in the perfect location and I took it to only find out that places are priced to negotiate and I was faced with the decision to negotiate or not. Sort of did, was not thrilled about it (thinking that I might lose the place) but it sort of worked and I scored the place. If price is up to haggling, the lease on the other hand, is standard (you can buy one at your local bodega ). It is the law to use it and it is like a no nonsense, straightforward lease, which is very protective of renters. 4. Montreal is known for its exceptional food but you know Poutine is just plain gross: Food here is good and I can tell that I will get a handle of restaurants in a way that felt impossible in NYC. The gluten free religion seems to be spreading, thankfully. There are many little Fruiterias! to get your fruits veggies which I am still exploring and right around my house is a crazy supermarket that is so cheap, which is weird because consumer goods generally ain t cheap in Montreal like they are in the states but this place is a gem and everyone agrees (and almost impossible to notice from the street!). Now Poutine is disgusting. Ok it did not help that the first night I went out to eat it, I was still under the clutches of Noro virus, and I think it re-activated the nausea that had been zapped by some strong medicine and the hospital, the day before, which brings me to the next point, the health care system. 5. Healthcare, I had to use it way too early: So last week I came down with the Noro virus and you usually wait it out as it runs through you quickly but I was dehydrated before I even started to vomit to for 8 hours straight, at which point severely tired and so nauseous (I was yelling to make it stop), I went to the hospital. Now I had talked to lot of people about the healthcare system in Montreal as it seems good, really great but a bit over taxed, especially compared to where I had lived in Edmonton where it was like a magic fairy tale dream. I had heard of two things: the care is excellent but the facilities are shocking and the wait times unless dire can be atrociously long. So facilities, yea they are kinda shocking, somewhat shabby but who cares, so long as the care is good, no? Packaging is irrelevant so long as the goods are derived. Before going I was scared of the long wait times (and also the taxi took me by mistake to Montreal General Hospital was looked too much like a HUGE version of the creepy buildings in The Shining for me, and I was supposed to go to Jewish General so left for there). The wait time: nearly none, somewhat as shocking as the facilities first looked to me. I think it was a combination of the time I arrived, with the fact that my lounge was parched and yellowish-gross (sorry, it was gross), indicating I was dehydrated, oh and I was crying bit hysterically, for despite my high threshold for pain, nausea terrorizes me. I was covered by insurance and since I did not yet have my McGill health cards (it takes three months to qualify for the local stuff), I did pay and the price was laughably cheap compared to what I would pay in NYC for the same treatment. 6. Now for my favorite, snow so nice, ice oh Christ: Well this winter has been, by all accounts, weak and warm, the spirit of winter barely making its way from the underworld to the outerworld. But even though it is has been more idle than full throttle, I still got a pretty accurate taste of what winter is like, with a few days of 20- c temps, and having to walk a number of times on a layer of frozen ice that makes it feel like a very dangerous mini-ice age in the making. I do rather love the quiet snow falling and just love love sprinting through the snow with my dog, Roscoe, who has taken a liking for prancing in the white stuff and looks awful cute with his winter man s ice beard. After a sizable snowfall, it is clear they city does not toy with the snow removal although the sidewalk snow plows do look somewhat like very large and dangerous but kinda cute toys. But let s be frank, winters are hard, so hard that I think I would go mad if I had to stay through the entire thing, being born and raised in the tropics So the fact that I am writing this from the southern hemisphere in the height of summer gives me the assurance I can handle the rest of the snow, ice, ice and snow upon my return.

At FOSDEM, John Sullivan delivered an interesting talk titled Is copyleft being framed? to verify alleged claims on the decline of GPL-d software. (Slides are available.) The crux of the talk is the analysis he performed on the Debian archive to discover the amount of software we distribute that is covered by GPL, LGPL, or AGPL ("GPL-d" for short in the remainder). John's talk steps in an interesting and long running debate (a recent summary of which is available in this ITWire article). The most interesting part is the discrepancy among John's results and Blackduck's, which are often used to argue how the popularity of the GPL license is declining. That might be the case. Or not. The more analyses we do to find it out, the better. The underlying assumption on John's work is that Debian is a representative sample of the Free Software out there, which I think is a reasonable assumption. I find the analysis presented in the talk completely satisfactorily from a purely scientific point of view. The same cannot be said about Blackduck's result: both their methods and data are secret, making it impossible to reproduce their experiments. Highly unscientific. Still, John's results are surprising: as much as 87 percent of Lenny's packages and 93 percent of Squeeze's are GPL-d. That seems a lot. Puzzled about that, John discussed with me the issue before his talk, in search for pitfalls in his methods or data. Finding none, I pointed him to the almighty DktrKranz for some extra review; who found nothing either. To stay on the safe side, even during his talk John called for independent reviews of his results. What could be wrong? The tool used to gather the data is license-count from the debian-policy package. Input data are the debian/copyright files of all Debian source packages. If license-count is not bugged, our debian/copyright files might be. One thing that occurred to me only a few days ago is the habit of declaring a different license for Debian packaging (the files under debian/) than the software being packaged itself. That's a bad habit because it might cause unwanted license mixtures via patches that live under debian/ but I've seen several occurrences of it in the Debian archive. For name and (self-)shame: I've also been guilty of it in the past, when I was young . Is that reason enough to skew results and overestimate GPL-d software? I don't think so, I hope not, but ultimately I don't know. It'd be nice to rule out the possibility entirely. So if anyone is willing to do some sampling of affected debian/copyright files and propose patches for license-count to exclude those "false positives", please shout. (As a bonus point: that would also help to take more sound decision for the typical use case of license-count, i.e. deciding when a license should be added to /usr/share/common-licenses.) Other independent reviews of the results are equally welcome. Note: the above, as well as John's analysis, would be a trivial exercise if DEP-5 were already widely deployed in the Debian archive.

---

Update: add link to John's slides
Update 19/02/2012: Russ Allbery, author of license-count, posted a way more likely cause of data skew in John's analysis: double counting among the different types of copyleft licenses