I was going to put out some of these changes in a 4.5.6 release late last year, but that didn't happen, and then more things kept coming up. So this release is rather large. The major new feature is a new WebAuthCookiePath directive for mod_webauth, which allows path-scoped WebAuth cookies so that different portions of a site can maintain separate authentication credentials. There are various caveats, and support will get better later, but it's a beginning. There are two bug fixes from Benjamin Coddington: WebAuthOptional should now work with Apache 2.4, and internal notes management in the module is now done better, which should prevent some cases where the user was redirected to WebLogin twice. Eventually, the things WebAuth uses notes for should become request context data, but that's for a later change. There are multiple changes to keyring handling to let mod_webauth and mod_webkdc work properly with the ITK Apache MPM, which allows each virtual host to run as a different user. Previously, all virtual hosts shared one in-memory keyring, which meant leaking authentication keys between virtual hosts. Now, each virtual host gets its own, lazily loaded from the keyring on disk when it's first needed. This allows ITK users to configure separate keyrings for each virtual host. To make this easier, keyring files are now locked for write, and writing a keyring preserves the ownership and permissions if possible. WebLogin now supports a new remctl-based password change protocol, which I developed for Stanford to work around some problems with the kpasswd when password change takes too long. All the tools for this will eventually be available outside of Stanford when I have a chance to polish them up and release them. There are a few other, more minor bug fixes. mod_webauth and WebLogin are now more aggressive about telling web browsers to really not cache pages. WebLogin also now uses the authenticated identity returned by the WebKDC for multifactor, since it may have canonicalized the user's identity. The correct template variable is now set when the user doesn't enter a code on the WebLogin multifactor page. Better error messages are returned for invalid principals and unknown realms. The workaround for invalid XML returned by the WebKDC should now actually work. And WebLogin logs a more detailed error message on password change failures. You can get the latest release from the official WebAuth distribution site or from my WebAuth distribution pages.

Today was a very busy day for me. First up, I had my chiropractic adjustment. Then I had my half-yearly dental checkup. Then I got stuck into cleaning the house. Fortunately I'd done a bit the afternoon before, otherwise I'd never have gotten it done before my massage. I'm starting to seriously consider getting a cleaner. I can make much better use of the limited time I get than cleaning the house. Zoe's Kindergarten has a Parent Advisory Group or something like that, which meets monthly. I wasn't able to attend the first one, but the second one was today, about an hour before pickup, so I grabbed a quick lunch after my massage and biked over to Kindergarten early. The meeting wasn't particularly interesting. The majority of it revolved around fund raising. At pickup time, Zoe was fast asleep again, and had another massive meltdown when I woke her up. It took forever to get her out. She wanted to give Megan a hug, but Megan had long gone. Then, rather fortuitously, Megan's Dad texted me to tell me they were in the playground on the neighbouring school grounds, so I managed to use that as an incentive to get Zoe moving. I didn't know until today, but at the foothill of the neighbouring primary school, there's some play equipment. A few of the Kindergarten kids seem to have a play over there after Kindergarten. Megan and Zoe played there for a bit before it was time to go. Once we got home, we unpacked and then walked down to the Hawthorne Garage to get some vegetables, and then, after buying some milk from the corner store and another grumpy meltdown, I figured a quiet afternoon was in order, so Zoe watched a DVD for a bit while I prepared dinner. I'd bumped into the mother of Zoe's friends Eva and Layla from her old day care while I was at the dentist in the morning, and arranged for her to drop by to pick up a copy of the photos I'd taken at their 4th birthday party. I'd hoped that she'd bring the girls with her, and had told Zoe they'd be dropping by, but unfortunately she came on the way to picking them up from day care, so Zoe was a bit disappointed. We did arrange to have them over for dinner next Friday, so I'm sure that will be very exciting. After that, we had dinner, and a fairly uneventful bedtime. It's hot again, so I hope that doesn't mess with her sleep.

What s up? That was the sound of a new Debian Installer release, an early Alpha 1 for the Jessie release cycle. As usual, see the Debian Installer section of the Debian website, in particular the errata page which lists important, known issues. Then give it a try, and report bugs! Let s see if we can keep the debian-boot@ bug count below 1400 for a while, even if we get many new installation reports. Last weeks have been busy: Speaking of which, if you feel like helping with the triaging effort, there s now a bug type called installer bugs on UDD s Bugs Search page. ;)

The lack of journal updates recently is due to a lot of work chaos combined with getting obsessed with various leisure activities (to blunt the work stress) that don't result in public writing. Normalcy seems to be slowly returning, but it will be a while yet. This release of my collection of utility libraries and scripts only has updates to some of the Perl test infrastructure. Testing Perl scripts for strictness, warnings, and syntax errors now supports listing a set of modules required for meaningful script testing. This converts failures to skipped tests if the reason for the syntax check failure is that a required module is not installed. This release also works around two problems with Perl::Tidy 20130922 related to its new log (mis)feature. Perl::Tidy now attempts to create a log file in the current directory whenever it runs unless this is explicitly turned off, and the Perl::Critic policy doesn't know to do that. (Debian bug #742004) I now unlink that file if it exists, after the test completes, and skip the Perl critic testing if the source directory is read-only (since failure to create the log file is treated by Perl::Tidy as a fatal error). You can get the latest version from the rra-c-util distribution page.

It sucks. It annoys me to no end that I can t run my own Linux kernel on an Android device. It s very annoying that the android patches haven t been upstreamed, and it s even more annoying that I can t run a host OS that I build lovingly and work on during the nights. I hate that I can t use my tablet as a porter box with a USB OTG Hard disk. Alas. One day. One day I ll have a proper armhf device that I can run Debian on. But that day is not today.

On responsibilities I feel like in my Debian projects I have two roles: the person with the responsibility of making the project happen, and the person who does the work to make it happen. As the person responsible for the project, I need to keep track of vision, goals, milestones, status. To make announcements, find contributors, motivate them, deal with users and bug reports, maintain documentation, digest feedback. As the person who does the work to make it happen, I need quiet time, I need to study technology, design code, write unit tests, merge patches, code, code, code, ask around about deployment information, more code. I have a hard time doing both things at the same time: the first engages my social skills and extroversion, requires low-latency interaction, and acting when outside things happen. The second engages my technical skills and introversion, requires quiet uninterrupted periods of flow, and acting when inspiration strikes. I never managed to make good use of "gift bugs" or "minions": I often found the phrase "it's easier for me to do than to explain it" sadly relevant. Now I understand that it's not because of the objective difficulty of explaining or doing things, nor about the value of doing or of involving people. It's about switching from one kind of workflow to another. If I rephrase that as "it's easier for me to stay in flux and fix it, than to switch my entire attitude to ask for help". Of course this does not scale: we've all been saying it since I can remember. Looking at the situation from the point of view of those two roles, however, I now wonder if those two roles shouldn't really require two people. In other worlds they are: the project managers, taking responsibility for making the project happen, and the software designers, artists, and all other kind of artisans doing the work to make it happen. Of course I don't want the kind of project manager that shifts responsibilities to artisans, does nothing and takes the credit for the project: not in paid work, not in Debian. Project management is something else. I would be interested instead in having the kind of project manager that takes responsibility for the project, checks how the artisans are doing and communicates what is happening to the rest of the world, deals with the community, motivates more people to help, test, try, use, give feedback on things as they happen. A project manager / community manager. So that while I'm flux there is someone who tags bugs as "gift", mentors people to find code and documentation, and remembers to write an announcement if I implemented three cool things in a row and I'm already busy working on the fourth. So that I don't write cool ideas in my todo list where nobody can read them, but I can share them to a mailing list where someone picks up a relevant one and finds someone to make it happen while I'm busy refactoring old code that only I can understand. So that if I say "sorry, paid work calls, I won't be able to work on this project for a month", I'll be able to completely forget about that project for a whole month, without leaving the community out there to die. That's an interesting job for non-uploading DDs: please take over my projects. Let's share a vision, and team up to make it happen. Give me the freedom of being the craftsman I enjoy being, and take away from me those responsibilities that I've never asked for. The worst project managers are those that never asked to be one, but were promoted to it. Let's not repeat that mistake in Debian. A good part of the credits for this post go to Francesca Ciceri, for the discussions we had on our way back from MiniDebConf Barcelona 2014. P.S. I'm seeing how a non-uploading DD could be in the Maintainer field for one or more packages, with uploading DDs being, well, uploaders. Food for thought.

I'm back home from the MiniDebConf Barcelona 2014 (and I've had a full night of uninterrupted sleep! :) ), so it's time to thank everybody who were there (both in person and via IRC) and especially the organizers who did a great job at creating a welcoming environment and a smooth experience for all of us.

It was my first @Debian community experience (although I had already met a few of the members in various occasions) and it made me glad of my decision to start contributing to the project. (I realize that I've probably met a sanitized and newbie-friendlier version of the community, but it's also made up of people who are working to improve the not-so-friendly parts.)

It was also my first time speaking to an international audience; I believe it went overall well: I'm happy with what I said and how, not so much with what I forgot to say (e.g. mentioning testing and other non-packaging skills in my answer to Enrico's question "what skills are needed in the 3dprinter team", or actually showing the last slide with reference urls at least this one will be available as soon as I'll send the slides to be uploaded to the site).

Random mentions:

We had free software, and also free beer, from one of the sponsors (I didn't catch which one), but the venue had to remain beer free, which encourages bad puns of the kind I love :)

Contrary to what some people was fearing, the cake was real and not a lie! (also, it tasted like banana bread with chestnut flour).

Video team duty is fun and something I'll do again (and try to use in our local community what I learn in the process), but I don't think I'll let the Galadriel in my mind bully me into subtitling stuff, sorry.

To ease worries of package mistreatment, the cows in the arriero slides looked more like they were moving between pastures in transhumance rather than being led to be slaughtered.

There are curves in B ziers, France (and also bad coffee and great pastries: definitely a better place_with_geek_name to have breakfast than Perl, Germany)!

The stickers with "May I sign your PGP keys" were a nice idea, although they didn't work as well as they could (possibly because there was little time and lots of things to do). I did manage to reduce my dependency on Enrico's key to find trustpaths, however, which is nice :)

I like the idea to draw a pentacle on the floor, and forcing speakers to remain inside, as suggested by a meeting of videoteaming italian cabal members.

Lots of other things I'm forgetting to mention, but now it's time to stop writing this and start work on my todolist where a few things received a priority bump during the conf. :)

To provide geolocation-aware answers with BIND, a common solution is to use a patch adding GeoIP support. A client can be directed to the closest (and hopefully fastest) web server: However, an end user does not usually talk directly to authoritative servers. They proxy the query to a third-party recursor server which will query the authoritative server on their behalf. The recursor also caches the answer to be able to serve it directly to other clients. On most cases, we can still rely on the recursor GeoIP location to forward the client to the closest web server because it is located in the client s ISP network, as shown on the following schema:

1. Juan is located in China and wants to know the IP address of www.example.com. She queries her ISP resolver.
2. The resolver asks the authoritative server for the answer.
3. Because the IP address of the resolver is located in China, the authoritative server decides to answer with the IP address of the web server located in Japan which is the closest one.
4. Juan can now enjoy short round-trips with the web server.

However, this is not the case when using a public recursor as provided by Google or OpenDNS. In this case, the IP address of the end client and the source IP address of the recursor may not share the same locality. For example, in the following schema, the authoritative server now thinks it is in relation with an European customer and answers with the IP address of the web server located in Europe: Moreover, caching makes the problem worse. To solve this problem, a new EDNS extension to expose the client subnet has been proposed. When using this extension, the recursor will provide the client subnet to the authoritative server for it to build an optimized reply. The subnet is vague enough to respect client s privacy but precise enough to be able to locate it. A patched version of dig allows one to make queries with this new extension: In the above example, a client located in France gets a reply with two IP addresses located in France. If we now are an US client, we will get IP addresses located in the US: The recursor is expected to cache the two different answers and only serve them if the client matches the appropriate subnet (the one confirmed in the answer from the authoritative server). With this new extension, the authoritative server knows that Juan is located in China and answers with the appropriate IP address: Not many authoritative servers support this extension (PowerDNS and gdnsd, as far as I know). At Dailymotion, we have built a patch for BIND. It only works when BIND is configured as an authoritative server and it doesn t expose no configuration knobs. Feel free to use it (at your own risk). Once installed, you need to register yourself to OpenDNS and to Google to receive queries with the extension enabled.

As announced in the "Bits from the Security Team" (LWN copy) email a couple of weeks ago, it is possible that Debian squeeze will have Long Term Support, primarily in the way of security updates.

The news have made it to Softpedia and reddit and even though it has not been announced how long it would be supported, what use cases are planned, etc., the answer I can give is that it depends solely on people contributing to it.

I'd like to add that no, the LTS announcement is not related to the use of Debian on the ISS laptops, as mentioned in reddit - at least not that we are aware of. And to avoid possible confusion from the Softpedia article, the plan is LTS for the squeeze release.

From the emails we have received in response to the announcement, I do wonder however where are the people who expressed interest and signs of engagement last time there was a discussion about providing LTS for Debian.

Perhaps it wasn't stressed enough in the email, but those who are interested in benefiting from (and therefore contributing to) long term support, please do contact the security team NOW.

After all, the clock keeps ticking and Debian squeeze is going to reach its End of Life in less than two months otherwise.

I was pretty exhausted after yesterday's sustained activities. By the time I'd blogged, done some photo management, gone to yoga class, made dinner and called my girlfriend, it was late, and I'd gotten to that tired point where I couldn't be bothered getting off the couch, so I ended up having a self-inflicted late night. This morning I tried to go for a run, but I died at the 2km mark, half way up Hawthorne Road, so I walked for the remainder of my 5km circuit. I'm going to say it was a combination of tiredness, insufficient hydration, the heat, and my head space. I got home from my "run", and had a shower and cleaned up the kitchen a bit and decided I'd rather get out of the house than work on my taxes, so I headed over to Moorooka to talk to the folks at Northfield about a new car radio. I've been wanting to get a better radio for the car for a while. The factory one has no line in, so I can't play anything off my phone through the car speakers. I've been wanting one that can do Bluetooth and play USB media. That way I can stick all of Zoe's CDs onto a USB stick and give her (and me) more variety than the current 3 track CD from dentist that she's favouring, and with Bluetooth I can listen to Pandora without needing a cable. I got to Northfield, and was pleased that they could do something within the budget I was looking at, and bought the DEH-X6650BT, which they were able to install for me on the spot. They said it'd take an hour and half, so I went for a walk down the road to Moorooka's main street to kill some time. I ended up having lunch at a little Ethiopian cafe where I swear the lady didn't understand English. Moorooka's quite nice and ethnic. After lunch I walked back, with the intention of reading the manual while I waited, and was pleasantly surprised to find they'd already finished the installation. When the guy was walking me through how to use it, I was really pleasantly surprised to discover that it also included Bluetooth hands free for my phone, with a little microphone glued to the top of my windscreen. That really made my day. I don't have to faff around with my little Bluetooth earpiece in the car any more. Then I discovered it had built-in Pandora support. So I'm really happy with this purchase, and really glad I didn't have to make a second trip to get it installed. I scouted around for a small USB thumb drive on the way home, and copied all Zoe's music off my laptop when I got home. By this stage, it was too late to bike to Kindergarten, and I wasn't really feeling like it anyway, because it was too hot, and I wanted to show Zoe the new radio anyway. It was a good call, because Zoe was fast asleep, and didn't take very kindly to being woken up. It took about 20 minutes to get her calm enough to get her back to the car. We got home, and we chilled out on the couch and watched a bunch of Youtube videos on the TV from when she was in the US, and then I showed her some Winter Olympics figure skating and speed skating, and then she watched a bit of DVD while I cleaned up the living room. Sarah picked up Zoe, and then I hosted our Body Corporate's annual general meeting.

When I installed Debian on my MacBookAir4,1 in 2012, there was no way to do it without manual intervention yet. I followed a tutorial on how to boot GRUB from the EFI Boot option in the MacBook EFI Menu. I did not want to fiddle with rEFIt, and I didn't want to boot GRUB by default. When I want to boot Linux, I press the Option key during power up and select EFI Boot from the Apple boot menu. Unfortunately, I neglected to collect notes about how I did it manually. However, Linux 3.2 is getting a bit old, so I finally wanted to replace my manual boot configuration with something handled by the package system. In case you don't have /boot/efi in /etc/fstab yet, you need to mount /dev/sda1 on /boot/efi for the following to work. The documentation I found on the net suggested to just reinstall grub-efi-amd64 and everything should work. That is not quite true. When I do Nothing changes in /boot/efi. I sort of expected that /boot/efi/EFI/debian would be created, and the EFI image should be placed in there. However, that did not happen. Why is that? It turns out that when I installed grub-efi-amd64 manually in 2012, I created /boot/efi/EFI/boot/bootx64.efi which is the EFI fallback location, and apparently exactly what I want on this MacBook which does not support multiple boot options. Matthew Garrett posted an interesting article called Booting with EFI which sheds light on this issue, go and read it. Looking at /var/lib/dpkg/info/grub-efi-amd64.postinst revealed that /boot/efi/EFI/debian needs to be created manually first. If this directory does not exist, grub-efi-amd64 basically does nothing on reinstall. Running grub-install will actually create a new EFI image. However, it is being created in the wrong place for this machine. does the trick. Now /boot/efi/EFI/debian/grubx64.efi gets created. However, since I don't want to make GRUB the default, there is yet another manual step to do: Now I can select EFI Boot after pressing the Option key during startup. GRUB is loaded and Linux 3.13 gets booted. Strike! Looking more closely reveals that there is actually a way to tell grub-install that it should install to the fallback location directly. The --removable option does that. For the faint of heart, what does grub-install actually do on an EFI system? It does not directly write to the disk, therefore it does not need a device specified. It looks for files in /boot/efi and assumes the EFI partition is mounted there. So for my use case, the correct way to upgrade to a current GRUB EFI image should have been: Meanwhile I've been made aware of Bug#708430. I guess it would be nice to have an option in /etc/default/grub which would indicate that installation to the fallback location is desired. While this is a rather ugly hack to work around a stupid limitation, it is still what I'd like on this MacBook. At least since I don't have a triplle boot situation. Fallback location works fine with just two OSes coexisting.

I just wanted to highlight that Muhammad Saied, a volunteer translator of the Debian Administrator s Handbook, is currently running a crowdfunding campaign with Mohamed Amine so that they can complete the Arabic translation that they started. There s only 6 days left to collect the last $2500 click here to help spread Debian to the Arabic world.

No comment Liked this article? Click here. My blog is Flattr-enabled.

Zoe's Kindergarten had a Pupil Free Day today. I think there's only that impacts the days Zoe attends Kindergarten for the whole year. I'd wanted to make the most of the fact that her friend Mackensie wasn't in Kindergarten on a Monday either, and have a play date with her at Southbank, but her little sister was having sleep issues, and her mother wanted her to nap at home today, so we had to scratch those plans. Given the forecast maximum temperature was going to be over 30 C today, I thought ice skating would be a great way to escape the heat, but the rink didn't have their open session until 1pm, so we had to do something in the morning to kill time. I decided we should go shoe shopping. Before we went to Westfield Carindale, we went to Officeworks to print out some more photos. Zoe really enjoys helping me with the self-serve printing kiosk, and is happy amusing herself at the kid's colouring table otherwise. I wanted some unusual size prints, so it involved one of the staff doing some additional faffing around with Photoshop for me. I'm rather amazed they'll spend the staff time doing that, when I only spend a couple of dollars on prints. After that, we headed out to Carindale. Zoe's in that limbo between size 3 and 4 at the moment. I bought her some new size 4 Autumn/Winter clothes the other weekend, and after that, went through her wardrobe and did a big cull of all her size 2 stuff and any size 3 stuff that didn't fit terribly well. That just left shoes and jumpers to sort out, so we concentrated on them today. First things first, we grabbed some morning tea at Muffin Break. They did a nice babyccino in a little china espresso cup, so Zoe enjoyed that, and we split a muffin between us. Zoe took a fancy to some ballerina pumps she saw at Cotton On Kids. We bought a few pairs of socks and a pair of size 10 pumps, and she wanted to wear them from that point on, so we wore them to the shoe shop. Almost as soon as we walked out of the store, she ran into heel problems on one foot, so after a few rounds of taking a couple of steps and needing to refit the heel of one shoe, I convinced her to go barefoot the remainder of the way. At Shoes and Sox she got properly measured for some light up closed-toe shoes. Zoe absolutely loved them, and wanted to wear them from that point on. Next we went to Target, and got a couple of jumpers. The kid's entertainment area was both a blessing and a curse. It was great for keeping her occupied when I needed to dash off and get some socks for myself for ice skating, but it was a negotiation challenge to get her away from it when it was time to leave. Toy Story 3 conveniently finished at just the right time. We dropped into Pumpkin Patch to get some boots. Despicable Me was playing there. Zoe is absolutely hooked on it at the moment. I managed to prime her to leave at the end of a scene though. She did score a couple of stickers while we were sitting there chilling out watching the movie though, so that was nice. I love Pumpkin Patch, but my God, it is expensive. I could have dropped $50 on a dress I really liked there, but I managed to resist. We decided to go back to Cotton On Kids to exchange the ballerina pumps. They didn't have any more of the style she'd chosen in her size, so we switched from gold glittery ones to red ones, which she wore out of the store. Cotton On Kids was also showing Despicable Me, so Zoe was very pleased. Shoes are horrendously expensive in Australia. The Sketchers and the boots set me back $60 each. The pumps were a bit more reasonably priced. I think they were about $20. I hope her feet don't grow too fast. After that shopping extravaganza it was lunchtime, and we split a spinach pide and had a quick fool around in the outdoor kid's play area and by then it was already after 1pm, so it was time to head to the ice skating rink. We got to the rink by about 1:45pm, and I changed Zoe into something a bit warmer. She was so excited, because we've talked about going ice skating on and off for a while, but it's just not something we've gotten around to doing yet, because neither of the two rinks are particularly convenient to home, and they have slightly odd hours. The rink had these slightly shorter than waist-height penguins that you could rent for little kids, so I rented one of them and Zoe pushed it around the rink, and got progressively better on her skates as time passed. We could also turn the penguin around and she could stand on the "feet" and I could push the penguin around by its head, which was fun for her, because we could get more speed up. By the end of the session, she was confident enough to have a few stints without the penguin, and stayed up pretty well. She was pretty buzzed afterwards. Going during the week was great, because there were maybe 20 people on the ice, tops, so it was nice and quiet. Zoe wasn't much of a hazard to anyone. She loved watching a couple of guys speed skate, and a lady do some figure skating. I'd booked myself a cut-throat razor shave at The Emporium Barber as a bit of a splurge, for 4:30pm, so we headed over there next. We got there a bit early, so I had a coffee, and Zoe had a juice while we waited. Then we discovered this dance apparel place a couple of doors down, that also had lots of fairy dresses and dress up dresses and whatnot. I asked on the off chance if they had ballet shoes, and of course they did, so we grabbed a pair of them while we were there, which was most serendipitous. Zoe has a trial dance class on Friday. She wants to do ballet or something of that ilk as her activity next term. Zoe was really good while I had my shave, and kept herself amused with my phone, and then we headed home, where Sarah was waiting to pick up Zoe. So it was really a rather non-stop, but nicely paced day. I'm looking forward to capping it off with a yoga class.

On three Saturdays in April and May, I will be helping run three day-long project-based workshops at the University of Washington in Seattle. The workshops are for anyone interested in learning how to use programming and data science tools to ask and answer questions about online communities like Wikipedia, Twitter, free and open source software, and civic media. The workshops are for people with no previous programming experience and the goal is to bring together researchers as well as participants and leaders in online communities. The workshops will all be free of charge and open to the public given availability of space. Our goal is that, after the three workshops, participants will be able to use data to produce numbers, hypothesis tests, tables, and graphical visualizations to answer questions like:

• Are new contributors to an article in Wikipedia sticking around longer or contributing more than people who joined last year?
• Who are the most active or influential users of a particular Twitter hashtag?
• Are people who participated in a Wikipedia outreach event staying involved? How do they compare to people that joined the project outside of the event?

If you are interested in participating, fill out our registration form here. The deadline to register is Wednesday March 26th. We will let participants know if we have room for them by Saturday March 29th. Space is limited and will depend on how many mentors we can recruit for the sessions. If you already have experience with Python, please consider helping out at the sessions as a mentor. Being a mentor will involve working with participants and talking them through the challenges they encounter in programming. No special preparation is required. If you re interested, send me an email.

I m currently using BTRFS on most systems that I can access easily. It s not nearly reliable enough that I want to install it on a server in another country or an embedded device that s only accessible via 3G, but for systems where I can access the console it s not doing too badly. Balancing and Space Allocation # btrfs filesystem df /
Data, single: total=103.97GiB, used=85.91GiB
System, DUP: total=32.00MiB, used=20.00KiB
Metadata, DUP: total=1.78GiB, used=1.31GiB
# df -h /

Filesystem	Size	Used	Avail	Use%	Mounted on
/dev/disk/by-uuid/ac696117-473c-4945-a71e-917e09c6503c	108G	89G	19G	84%	/

Currently there are still situations where it can run out of space and deadlock on freeing space. The above shows the output of the btrfs df command and the regular df command, I have about 106G of disk space used by data and metadata in BTRFS while df shows that the entire filesystem (IE the block device) is 108G. So if I use another 2G of data or metadata then the system is at risk of deadlocking. To avoid that happening I have to run btrfs balance start / to start a balance which defragments the space use and frees some blocks. Currently there is a bug in BTRFS (present in all Debian/Unstable kernels) which prevents a balance operation from completing when systemd is used in a default configuration (there s something about the way systemd accesses it s journal files that triggers a BTRFS bug). This is really inconvenient, particularly given that there s probably a strong correlation between people who use experimental filesystems and people who use experimental init programs. When you get to the stage of the filesystem being deadlocked you can sometimes recover by removing snapshots and sometimes by adding a new device to the filesystem (even a USB flash drive will do). But I once had a filesystem get into a state where there wasn t enough space to balance, add a device, or remove a snapshot so I had to do a backup/format/restore. Quota Groups Last time I asked the developers (a few weeks ago) they told me that quota groups aren t ready to use. They also said that they know about enough bugs that there s no benefit in testing that feature. Even people who want to report bugs in BTRFS shouldn t use quotas. Kernel Panics with Kmail I ve had three systems develop filesystem corruption on files related to Kmail (the email program from KDE). I suspect that Kmail is triggering a bug in BTRFS. On all three systems the filesystem developed corruption that persisted across a reboot. One of the three systems was fixed by deleting the file for the Outbox, the others are waiting for kernel 3.14 which is supposed to fix the bug that causes kernel panics when accessing the corrupted files in question. I don t know whether kernel 3.14 will fix the bug that caused the corruption in the first place. Conclusion As I don t use quotas BTRFS is working well for me on systems that have plenty of storage space and don t run Kmail. There are some systems running systemd where I plan to upgrade the kernel before all the filesystem space is allocated. One of my systems is currently running SysVinit so I can balance the filesystem. Apart from these issues BTRFS is working reasonably well for me. I haven t yet had it s filesystem checksums correct corrupted data from disk in any situation other than tests (I have had ZFS correct such an error, so hardware I use does benefit from this). I have restored data from BTRFS snapshots on many occasions, so that feature has been a major benefit for me. When I had a system with faulty RAM the internal checks in BTRFS alerted me to the problem and I didn t lose any data, the filesystem became read-only and I was able to copy everything off even though it was too corrupted for writes.

As I posted some weeks ago, I have been playing with my CuBox-i4Pro, a gorgeous little ARM machine by SolidRun, built around an iMX6 system-on-a-chip. My first stabs at using it resulted in my previous post on how to get a base, almost-clean Debian distribution to run (Almost? Yes, the kernel requires some patches not yet accepted upstream, so I'm still running with a patched 3.0.35-8 kernel). After writing this step by step instructions, I followed them and built images ready to dd to a SD card and start running (available at my people.debian.org space. Now, what to do with this little machine? My version is by no means a limited box: 4 ARM cores, 2GB RAM make a quite decent box. In my case, this little machine will most likely be a home storage server with little innovation. However, the little guy is a power server, at only 3W consumption. I wanted to test its capabilities to do some number crunching and aid some of my friends The obvious candidate is building a Blender render farm. Right, the machines might be quite underpowered, but they are cheap (and look gorgeous!), so at least it's worth playing a bit! Just as a data point, running on an old hard disk (and not on my very slow SD card), the little machine was able to compile the Blender sources into a Debian package in 89m13.537s, that is, 5353 seconds. According to the Debian build logs (yes, for a different version, I tried with the version in Wheezy and in a clean Wheezy system), the time it took to build on some other architectures' build daemons was 1886s on i386, 1098s on PowerPC, 2003s on AMD64, 11513s on MIPS and 27721 on ARMHF. That means, my little machine is quite slower than desktop systems, but not unbearably so. But sadly, I have hit a wall, and have been unable to do any further progress. Blender segfaults at startup under the Debian armhf architecture. I have submitted bug report #739194 about this, but have got no replies to it yet. I did get the great help from my friends in the OFTC #debian-arm channel, but they could only help up to a given point. It seems the problem lies in the Python interpreter in armhf, not in Blender itself... But I cannot get much further either. I'm sending this as a blog post to try to get more eyeballs on my problem How selfish, right? :-) So, slightly going over the bug report, blender just dies at startup: After being told that strace is of little help when debugging this kind of issues, I went via gdb. A full backtrace pointed to what feels like the right error point: I'm not pasting here the full bug history (go to the bug report for the full information!), but it does point me to this being a problem in Python-land: It points to something not found at line 59 of Python/errors.c. And what I understand from that line is that some kind of unknown exception is thrown, and the Python interpreter does not now what to do with it. The check done at line 59 is the if (exception != NULL ** ....: So... Dear lazyweb: Any pointers on where to go on from here? kthxbye.

As of Pygments 1.7, there s support for Hy! http://pygments.org/docs/lexers/ Please report any bugs you find! This is great!

I have just released version 1.7 of Obnam, my backup program. Version 1.7, released 2014-03-15 WARNING: This release has had fairly large parts of the internals re-written. There shouldn't be any externally visible changes due to that, but there is a chance of bugs. Be careful. Make a copy of your backup repository before upgrading, if you can.

• The convert5to6 subcommand has been removed. If you need to convert from a pre-1.0 backup repository, and haven't done so yet, please use Obnam version 1.6.1 or earlier to do so.
• A new backup-finished hook is provided by the backup plugin, so that other plugins may do processing at the end of a backup, such as report the successful backup to a monitoring system. Patch by Enrico Tr ger.
• The FUSE plugin can now refresh its view, by having the user read the .pid file. Patch by Valery Yundin.
• New option --always-restore-setuid to always restore setuid/setgid flags in permissions, even if the restore is not being run by root or the owner of the files (as recorded in the backup).
• New option --exclude-from allows exclusion patterns to be given in a separate file (one per line), instead of in a configuration file or on the command line. Patch by Enrico Tr ger.
• A start of a manual for Obnam. This will gain more content with new releases. The current versions is mainly an edited version of Lars's blog posts about backups, plus the Obnam tutorial from the Obnam homepage. See http://code.liw.fi/obnam/manual/ for rendered versions (PDF, HTML).
• Most of the error messages Obnam produces now have a unique error code: ERROR: R0B15DX: Cannot find requested generation for client havelock for example. More error messages will gain error codes in future releases. The error codes are meant to be easy to search for, and will allow error messages to be translated in the future.
• The obnam-benchmark program got rewritten so that it'll do something useful, but at the same time, it is no longer useful as a general tool. It is now expected to be run from the Obnam source tree (a cloned git repository), and isn't installed anymore.
• The log file now includes information about the transfer overhead to the repository. Overhead is all the bytes that are not file content data: filenames, permission bits, extended attributes, etc, plus Obnam internal bookkeeping.
• obnam verify now shows progress both based on number of files and amount of data.

Bug fixes:

• Obnam now doesn't remove chunks that are shared between clients. Previously, this would sometimes happen, because only the first client would correctly record itself as using a chunk. Now all clients do that.
• Obnam now creates a trustdb.gpg in the temporary GNUPGHOME it uses during encryption operations. From version 2.0.22 (or thereabouts), gpg insists on having a trustdb.gpg in the GNUPGHOME it uses.
• When backing up a large file, and making a checkpoint generation in the middle of it, Obnam would say "continuing backup" after the checkpoint was finished, instead of saying the name of the file. This is now fixed.

Internal changes:

• The obnamlib.Error exception class has been replaced by the obnamlib.ObnamError class, which derives from the new obnamlib.StructuredError class. All new exceptions will need to be derived from obnamlib.Error in the future. Also, due to the way StructuredError works, it is now necessary to create a new exception class for each kind of error. This gives us unique the error codes mentioned above.
• The old obnamlib.Repository class is gone, and replaced with the obnamlib.RepositoryInterface class, which gets implemented for each repository format (there is only one, for now, but there will be more).