Collabora recently had a problem with a project's ARM build farm. In a nice change of pace it was not that the kernel was crashing, nor indeed any of the software or hardware.
The ProblemInstead our problem was our build farm could best be described as "a pile of stuff" and we wanted to add more systems to it and have switched power control for automated testing.

Which is kinda where the Christopher Alexander quote comes into this. I suggested that I might be able to come up with a better, or at least cleaner, solution.
The IdeaPrevious experience had exposed me to the idea of using 19 inch subracks for mounting circuits inside submodules.

I originally envisaged the dev boards individually mounted inside these boxes. However preliminary investigation revealed that the enclosures were both expensive and used a lot of space which would greatly increase the rack space required to house these systems.

I decided to instead look at eurocard type subracks with carriers for the systems. Using my 3D printer I came up with a carrier design for the imx53 QSB and printed it. I used the basic eurocard size of 100mm x 160mm which would allow the cards to be used within a 3U subrack.

Once assembled it became apparent that each carrier would be able to share resources like power supply, ethernet port and serial console via USB just as the existing setup did and that these would need to be housed within the subrack.
The PrototypeThe carrier prototype was enough to get enough interest to allow me to move on to the next phase of the project. I purchased a Schroff 24563-194 subrack kit and three packs of guide rails from Farnell and assembled it.

Initially I had envisaged acquiring additional horizontal rails from Schroff which would enable constructing an area suitable for mounting the shared components behind the card area.

Unfortunately Schroff have no suitable horizontal profiles in their catalog and are another of those companies who seem to not want to actually sell products to end users but rather deal with wholesalers who do not have their entire product range!

Undaunted by this I created my own horizontal rail profile and 3D printed some lengths. The profile is designed to allow a 3mm thick rear cover sheet attached with M2.5 mounting bolts and fit rack sides in the same way the other profiles do.

At this point I should introduce some information on how these subracks are dimensioned. A standard 19 inch rack (as defined in IEC 60297) has a width of 17.75 inches(450.85mm) between the vertical posts. The height is measured in U (1.75 inches)

A subrack must obviously fit in the horizontal gap while providing as much internal space as possible. A subrack is generally either 3 or 6 U high. The width within a subrack is defined in units called HP (Horizontal Pitch) which are 0.2 inches(5.08 mm) and subracks like the Schroff generally list 84 usable HP.

However we must be careful (or actually just learn from me stuffing this up ;-) as the usable HP is not the same thing as the actual length of the horizontal rails! The enclosures actually leave and additional 0.1 inch at either end giving a total internal width of 85HP (17 inches, 431.8 mm) which leaves 0.75 inches for the subrack sides and some clearance.

The Schroff subrack allows eurocards to be slotted into rails where the card centre line is on HP boundaries, hence we describe the width of a card in the slot in terms of HP
I cannot manufacture aluminium extrusions (I know it is a personal failing) nor produce more than 100 mm long length of the plastic profile on my printer.

Even if full lengths are purchased from a commercial service (120 euros for a pair including tax and shipping) the plastic does not have sufficient mechanical strength.

The solution I came up with was somewhat innovative, as an alternative a M5 bolt into a thread in the aluminium extrusion I used a 444mm long length of 4mm threaded rod with nuts at either end. This arrangement puts the extrusion under compression and gives it a great deal of additional mechanical strength as the steel threaded rod is very strong.

Additionally to avoid having to print enough extrusion for the entire length I used some 6mm aluminium tube as a spacer between 6HP(30.48mm) wide sections of the printed extrusion.

It was intended to use a standard modular PC power supply which is 150mm wide which is pretty close to 30HP (6 inches) so it was decided to have a 6HP section of rail at that point to allow a rear mounting plate for the PSU to be attached.

This gives 6HP of profile, 21HP(106.68mm) of tube spacer, 6HP of profile, 46HP(233.68 mm) of tube spacer and a final 6HP profile summing to our total of 85HP. Of course this would be unnecessary if a full continuous 85HP rail had been purchased, but 6 of 6 HP long profile is only 51 euro a saving of 70 euro.

To provide a flat area on which to mount the power switching, Ethernet switch and USB hubs I ordered a 170 x 431 mm sheet of 3mm thick aluminium from inspiredsteel who, while being an ebay company, were fast, cheap and the cutting was accurate.

Do be sure to mention you would prefer it if any error made the sheet smaller rather than larger or it might not fit, for me though they were accurate to the tenth of a mm! If you would prefer the rear section of the rack to be enclosed when you are finished, buy a second sheet for the top. For my prototype I only purchased a 170 x 280mm sheet as I was unsure if I wanted a surface under the PSU (you do, buy the longer sheet)

Mounting the PSU was a simple case of constructing a 3 mm thick plate with the correct cutouts and mounting holes for an ATX supply. Although the images show the PSU mounted on the left hand side of the rack this was later reversed to improve cable management.

The subrack needed to provide Ethernet switch ports to all the systems. A TP-Link TL-SF1016DS 16-Port 10/100Mbps Switch was acquired and the switch board removed from its enclosure. The switch selected has an easily removed board and is powered by a single 3.3V input which is readily available from the ATX PSU.

Attention now returned to the eurocard carriers for the systems, the boards to be housed were iMX53 QSB and iMX6 SABRE Lite and a Raspberry Pi control system to act as USB serial console etc.

The carriers for both main boards needed to be 8HP wide, comprised of:

• Combined USB and Ethernet Jack on both boards was 30 mm tall
• PCB width of 2mm
• underside components of 4mm
• clearance between boards of 2mm

A wiring loom was constructed for each board giving them a connector tail long enough to allow them to be removed. This was the wrong approach! if you implement this design (or when I do it again) the connector tails on the wiring loom should present all the connections to the rear at the same depth as the Ethernet connection.

The rack cables themselves should be long enough to allow the slides to be removed but importantly it is not desirable to have the trailing cable on the cards. I guess the original eurocard designers figured this out as they designed the cards around the standard fixed DIN connectors at the back of the card slots.

We will now briefly examine a misjudgement that caused the initially deployed solution to be reimplemented. As the design was going to use USB serial converters to access the serial console a USB connected relay board was selected to switch the power to each slot. I had previously used serial controlled relay boards with a USB serial convertor however these were no longer available.

All the available USB relay boards were HID controlled, this did not initially seem to be an issue and Linux software was written to provide a reasonable interface. However it soon became apparent that the firmware on the purchased board was very buggy and crashed the host computer's USB stack multiple times.

Deployed solutionOnce it became apparent that the USB controlled power board was not viable a new design was conceived. As the Ethernet switch had ports available Ethernet controlled relay boards were acquired.

It did prove necessary to design and print some PCB support posts with M3 nut traps to allow the relay boards to be easily mounted using double sided adhesive pads.

By stacking the relay boards face to face and the Ethernet switch on top separated using nylon spacers it was possible to reduce the cable clutter and provide adequate cable routing space.

A busbar for Ground (black) and unswitched 12V (yellow) was constructed from two lengths of 5A chock block.

An issue with power supply stability was noted so a load resistor was added to the 12V supply and an adhesive thermal pad used to attach it to the aluminium base plate.

It was most fortunate that the ethernet switch mounting holes lined up very well with the relay board mounting holes allowing for a neat stack.

This second edition is the one currently in use, it has proved reliable in operation and has been successfully updated with additional carriers.

The outstanding issues are mainly centered around the Raspberry Pi control board:

• Needs its carrier fitting. It is currently just stuck to the subrack end plate.
• Needs its Ethernet cable replacing. The existing one has developed a fault post installation.
• Needs the USB hub supply separating from the device cable. The current arrangement lets the hub power the Pi which means you cannot power cycle it.
• Connect its switched supply separately to the USB hub/devices.

Shopping listThe final bill of materials (excluding labour and workshop costs) which might be useful to anyone hoping to build their own version.

Prices are in GBP currency converted where appropriate and include tax at 20% and delivery to Cambridge UK and were correct as of April 2013.

The purchasing was not optimised and for example around 20GBP could be saved just by ordering all the shapeways parts in one order.

Base subrack
Item	Supplier	Quantity	Line Price
Schroff 24563-194 subrack kit	Farnell	1	41.28
Schroff 24560-351 guide rails	Farnell	3	13.65
Schroff rack rear horizontal rail	Shapeways	2	100.00
1000mm length of 4mm threaded rod	B and Q	1	1.48
170mm x 431mm x 3mm Aluminium sheet	inspired steel	2	40.00
PSU mounting plate	Shapeways	1	35.42
PCB standoff	Shapeways	4	22.30
160mm Deep Modular PC supply	CCL	1	55.76
TP-Link TL-SF1016DS 16-Port 10/100Mbps-Switch	CCL	1	23.77
8 Channel 16A Relay Board Controlled Via Ethernet	Rapid	2	126.00
Raspberry Pi	Farnell	1	26.48
USB Serial converters	CCL	10	37.40
10 port strip style USB HUB	Ebay	1	7.00
Parts for custom Ethernet cables	RS	13	26.00
Parts for custom molex power cables (salvaged from scrap ATX PSU)	Workshop	11	11.00
33R 10W wirewound resistor for dummy load	RS	1	1.26
24pin ATX female connector pre-wired	Maplin	1	2.99
Akasa double sided thermal pad	Maplin	1	5.00
Small cable tie bases	Maplin	1	6.49
Miscellaneous cable, connectors, nylon standoffs, solder, heatshrink, zip ties, nuts, washers etc.	Workshop	1	20.00
Total for subrack			603.28

The carriers are similarly not optimally priced as over five GBP each can be saved by combining shipping on orders alone. Also the SSD drive selection was made some time ago and a newer model may be more suitable.

i.MX53 QSB carrier
Item	Supplier	Quantity	Line Price
i.MX53 QSB	Farnell	1	105.52
Intel 320 SSD 80G	CCL	1	111.83
Carrier board	Shapeways	1	30.00
combined sata data and power (15 to 20cm version)	EBay	1	5.00
Low profile right angle 5.5mm x 2.1mm barrel jack	EBay	1	0.25
Parts for 9pin serial cable extension	RS	1	5.00
Miscellaneous solder, heatshrink, nylon nuts, bolts and washers	Workshop	1	5.00
Total for carrier			262.60

i.MX6 SABRE Lite carrier
Item	Supplier	Quantity	Line Price
i.MX6 SABRE Lite	Farnell	1	128.06
Intel 320 SSD 80G	CCL	1	111.83
Carrier board	Shapeways	1	35.00
combined sata data and power (15 to 20cm version)	EBay	1	5.00
Low profile right angle 5.5mm x 2.1mm barrel jack	EBay	1	0.25
Parts for 9pin serial cable modification	RS	1	2.00
Miscellaneous solder, heatshrink, nylon nuts, bolts and washers	Workshop	1	5.00
Total for carrier			287.14

ConclusionThe solution works and in a 3U high 355mm deep subrack ten ARM development boards can be racked complete with local ethernet switching, power control and serial consoles.

The solution is neat and provides flexibility, density and reproducibility the "pile of stuff" solution failed to do.

For current prototype with nine filled slots the total cost was around 3000GBP or around 330GBP per slot which indicates a 100GBP per slot overhead over the "pile of stuff" solution. These figures omit the costs of the engineer and workshop time, which are estimated at an additional 1500GBP. Therefore a completed rack, fully filled with i.MX6 carriers costs around 5000GBP

Density could be increased if boards with lower height requirements were used however above twelve units there issues with Ethernet switch, power switch and USB port availability become a factor. For Example the 16 port Ethernet switch requires a port for uplink, one for each relay board and one for the console server which leaves only 12 ports for systems.

Addressing the outstanding issues would result in a much more user friendly solution. As the existing unit is in full time use and downtime is not easily scheduled for all ten systems, the issues are not likely to be fixed on the prototype and would have to be solved on a new build.

The solution is probably not suitable for turning into a product but that was not really the original aim. A commercial ARM blade server using this format would almost certainly use standard DIN connectors and a custom PCB design rather than adapting existing boards.

Working with virtualisation I find myself occasionally needing to generate a random MAC address for use with a virtual machine. I have a stupid little local script which spits one out, which is all fine and dandy for my purposes. However this week one of my colleagues was writing a wiki page and needed to include instructions on how to set the MAC address on the Arndale board. He wanted to include a shell snippet to generate one and I suggested that there must be websites which will generate you a suitable address. But when I came to look we found that not a single one of the half a dozen site which I looked at handled the locally administered or multicast bits correctly, meaning that they would randomly generate either multicast addresses or addresses using assigned OUI (or both). Using a random OUI may not cause too much trouble in practice but using a multicast address is sure to lead to strange behaviour, and in any case it's kind of lame. So last night I sat down and wrote a quick hack cgi script to generate random addresses and tonight I deployed it at: http://www.hellion.org.uk/cgi-bin/randmac.pl. This is where the world and his dog leaves a comment pointing me to the existing service my searches missed...

As part of the DebConf13 fundraising efforts, Brandorr Group is funding a matching initiative for DebConf13, which will be in place for 4 more days (through April 30th). You can donate here! Please consider donating $100, or even $5 or any amount in between, as we can use all the help we can get to reach our fundraising target. The rules are simple:

• for each dollar donated by an individual to DebConf13 though this mechanism, Brandorr Group will donate another dollar;
• individual donations will be matched only up to 100USD each;
• only donations in USD will be matched;
• Brandorr Group will match the donated funds up to a maximum total of 5000 USD.

This generous offer will only stay in place through the end of April 30th. Please act quickly, and help spread the world!

Wow, my first "Debian day" in 2013, but it's a bit of a misnomer because I didn't do any Debian work tonight. I spent some time poking at geary, Yorba's new email client which looks promising. I haven't managed to get it working much, though. Someone packaged an old version in Debian but it wouldn't work with either my home or my work IMAP/SMTP servers for various reasons. I did get a git checkout to build in March or April but that stopped working on Debian when they dropped "Precise" support (It seems they were backporting various GIR/Webkit bits and pieces into their own code and didn't want to carry that around any more). They've currently got a fundraiser going, they're aiming for $100k and (at the time of writing) need half of that with only 10 hours to go. Recently I've also been trying to fix a rockbox bug on Sansa Fuze v1 which really cripples writing onto the Fuze. The original firmware does not support microsd capacities >32G which rules it out for me. Sadly the v1 version of the Fuze is uncommon enough that I don't think this bug is getting much attention. My investigations have been limited to fairly dumb bisect-like approaches, combined with lots of writing onto a microsd card (which will probably be killed dead by all this). My initial attempts at a bisect have failed as it turns out the problem is the inverse of a regression: it bizarrely seems as if the bug was fixed in a version-branch, rather than stopped working in one, so it has never been squashed in the main branch at all. Furthermore, the commit that seems to fix the problem is a totally benign version bump, and almost certainly hasn't fixed the bug. So with sufficient further testing I'll probably just prove that this bug has never been fixed. It might be time to switch tack and look into diagnosing the bug rather than trying to side-step it. Or perhaps just spend 15 on a Sansa Clip Zip and forget all about the Fuze v1. Either way I hope someone releases a 128G microsd card this year! Every now and then I wonder whether it would make sense to package rockbox in Debian in some way. Probably not.

(Debian) packaging and Git. The big picture is as follows. In my view, the most natural way to work on a packaging project in version control [1] is to have an upstream branch which either tracks upstream Git/Hg/Svn, or imports of tarballs (or some combination thereof, and a Debian branch where both modifications to upstream source and commits to stuff in ./debian are added [2]. Deviations from this are mainly motivated by a desire to export source packages, a version control neutral interchange format that still preserves the distinction between upstream source and distro modifications. Of course, if you're happy with the distro modifications as one big diff, then you can stop reading now gitpkg $debian_branch $upstream_branch and you're done. The other easy case is if your changes don't touch upstream; then 3.0 (quilt) packages work nicely with ./debian in a separate tarball. So the tension is between my preferred integration style, and making source packages with changes to upstream source organized in some nice way, preferably in logical patches like, uh, commits in a version control system. At some point we may be able use some form of version control repo as a source package, but the issues with that are for another blog post. At the moment then we are stuck with trying bridge the gap between a git repository and a 3.0 (quilt) source package. If you don't know the details of Debian packaging, just imagine a patch series like you would generate with git format-patch or apply with (surprise) quilt. From Git to Quilt. The most obvious (and the most common) way to bridge the gap between git and quilt is to export patches manually (or using a helper like gbp-pq) and commit them to the packaging repository. This has the advantage of not forcing anyone to use git or specialized helpers to collaborate on the package. On the other hand it's quite far from the vision of using git (or your favourite VCS) to do the integration that I started with. The next level of sophistication is to maintain a branch of upstream-modifying commits. Roughly speaking, this is the approach taken by git-dpm, by gitpkg, and with some additional friction from manually importing and exporting the patches, by gbp-pq. There are some issues with rebasing a branch of patches, mainly it seems to rely on one person at a time working on the patch branch, and it forces the use of specialized tools or workflows. Nonetheless, both git-dpm and gitpkg support this mode of working reasonably well [3]. Lately I've been working on exporting patches from (an immutable) git history. My initial experiments with marking commits with git notes more or less worked [4]. I put this on the back-burner for two reasons, first sharing git notes is still not very well supported by git itself [5], and second Gitpkg maintainer Ron Lee convinced me to automagically pick out what patches to export. Ron's motivation (as I understand it) is to have tools which work on any git repository without extra metadata in the form of notes. Linearizing History on the fly. After a few iterations, I arrived at the following specification.

• The user supplies two refs upstream and head. upstream should be suitable for export as a .orig.tar.gz file [6], and it should be an ancestor of head.
• At source package build time, we want to construct a series of patches that
  1. Is guaranteed to apply to upstream
  2. Produces the same work tree as head, outside ./debian
  3. Does not touch ./debian
  4. As much as possible, matches the git history from upstream to head.

Condition (4) suggests we want something roughly like git format-patch upstream..head, removing those patches which are only about Debian packaging. Because of (3), we have to be a bit careful about commits that touch upstream and ./debian. We also want to avoid outputting patches that have been applied (or worse partially applied) upstream. git patch-id can help identify cherry-picked patches, but not partial application. Eventually I arrived at the following strategy.

1. Use git-filter-branch to construct a copy of the history upstream..head with ./debian (and for technical reasons .pc) excised.
2. Filter these commits to remove e.g. those that are present exactly upstream, or those that introduces no changes, or changes unrepresentable in a patch.
3. Try to revert the remaining commits, in reverse order. The idea here is twofold. First, a patch that occurs twice in history because of merging will only revert the most recent one, allowing earlier copies to be skipped. Second, the state of the temporary branch after all successful reverts represents the difference from upstream not accounted for by any patch.
4. Generate a "fixup patch" accounting for any remaining differences, to be applied before any if the "nice" patches.
5. Cherry-pick each "nice" patch on top of the fixup patch, to ensure we have a linear history that can be exported to quilt. If any of these cherry-picks fail, abort the export.

Yep, it seems over-complicated to me too. TL;DR: Show me the code. You can clone my current version from

git://pivot.cs.unb.ca/gitpkg.git

This provides a script "git-debcherry" which does the history linearization discussed above. In order to test out how/if this works in your repository, you could run

git-debcherry --stat $UPSTREAM

For actual use, you probably want to use something like

git-debcherry -o debian/patches

There is a hook in hooks/debcherry-deb-export-hook that does this at source package export time. I'm aware this is not that fast; it does several expensive operations. On the other hand, you know what Don Knuth says about premature optimization, so I'm more interested in reports of when it does and doesn't work. In addition to crashing, generating multi-megabyte "fixup patch" probably counts as failure. Notes

1. This first part doesn't seem too Debian or git specific to me, but I don't know much concrete about other packaging workflows or other version control systems.
2. Another variation is to have a patched upstream branch and merge that into the Debian packaging branch. The trade-off here that you can simplify the patch export process a bit, but the repo needs to have taken this disciplined approach from the beginning.
3. git-dpm merges the patched upstream into the Debian branch. This makes the history a bit messier, but seems to be more robust. I've been thinking about trying this out (semi-manually) for gitpkg.
4. See e.g. exporting. Although I did not then know the many surprising and horrible things people do in packaging histories, so it probably didn't work as well as I thought it did.
5. It's doable, but one ends up spending about a bunch lines of code on duplicating basic git functionality; e.g. there is no real support for tags of notes.
6. Since as far as I know quilt has no way of deleting files except to list the content, this means in particular exporting upstream should yield a DFSG Free source tree.

I don't usually blog about work, but this time around, you maxed it. When I specifically ask you to not ship goods, I have good reasons for that. Specifically:

• I'm not at my office all the time. Yes, I'm often there, but I'm also often at a customer's place (you know, so I can actually make money). When I'm not at a customer, I tend to be at the office in a noon-through-evening schedule, rather than a morning-through-late-afternoon one (I hate getting out of bed if I don't have to). Since we don't have any employees, this likely means your logistics partner will find a closed door with nobody answering the bell.
• The result of that is that we'll often find that your shipments end up at your logistics partner's warehouse. Since I have to drive to a warehouse anyway, I might as well choose to drive to the warehouse that is closest yours.
• For this "service" of shipping goods away from interesting locations, you charge 20+.

Not Happy(tm)

By now, Debian ships quite a lot of Haskell packages (~600). Because of GHC's ABI volatility, whenever we upload a new version of a library, we have to rebuild all libraries that depend on that. In particular, if we upload a new version of the compiler itself, we have to rebuild all Haskell library packages. So we have to rebuild stuff a lot. Luckily, Debian has a decent autobuilding setup so that I just need to tell it what to rebuild, and the rest happens automatically (including figuring out the actual order to build things).
I was curious how much we use the buildd system compared to other packages, and also how long the builders are busy building Haskell packages. All the data is in a postgresql database on buildd.debian.org, so with some python and javascript code, I can visualize this. The graphs show the number of all uploads by autobuilder on the amd64 architecture, with haskell uploads specially marked, and the second graph does the same for the build time. You can select time ranges and get aggregate statistics for that time span. During the last four days a complete rebuild was happening, due to the upload of GHC 7.6.3. During these 2 days and 18 hours building 537 packages took 48 hours of build time and produced 15kg of CO₂. That is 94% of all uploads and 91% the total build time. The numbers are lower for the whole of last year: 52% of uploads, 31% of build time and 57kg of CO₂. (The CO₂ numbers are very rough estimates.)
Note that amd64 is a bit special, as most packages are uploaded on this architecture by the developers, so no automatic builds are happening. On other architectures have, every upload of a (arch:any) package is built, so the share of Haskell packages will be lower. Unfortunately, at the moment the database does not provide me with a table across all architectures (and I was too lazy to make it configurable yet).

The first Qt 5 packages have been accepted in Debian experimental.

What's there

• qtbase-opensource-src: lib[concurrent core dbus gui network opengl printsupport sql test widgets xml], examples, development packages and debug symbols.
• qttools-opensource-src: lib[qtlucene designer help], qdbus, development headers and debugging symbols.
• qtjsbackend-opensource-src: libqt5v8-5
• qtxmlpatterns-opensource-src
• qtchooser, which allows to select between Qt4 or Qt5 at build time.

What's not there

I posted the following on Google+, but it is important enough to be reproduced on Planet. I'm editing it a bit, as it is a followup to my previous post. While improving the packaging of MongoDB, there was one thing that caught my attention: that Ubuntu had already done some of the embedded/convenience libraries work, but they had not pushed that work to Debian. Of course, discovered this only after I started working on the improvements of the package. What gives, Ubuntu people? Another thing that I saw is that they have patches enabling mongodb working on armhf. Again, they did not push those to Debian. Why this lack of cooperation? Another thing that I saw is that they had packages for version 2.2 (more precisely, raring has 1:2.2.4-0ubuntu1), while Debian sid just had 2.0 until very recently. Why not push this work and avoid duplication of work? By being a good downstream, I intend to push some of the patches to MongoDB upstream (if they want it), so that we (Debian) have a smaller delta. This will benefit you Ubuntu guys. Why not join forces and help have a world-class set of packages? Please, be good netizens and share the work that you have. I firmly believe that the armhf people will be happy to have one of the fancy "cloud" software available on ARM, especially since the prospects of having ARM machines on datacenters. Oh, just for the record, the kFreeBSD people have sent their contribution and I would love to see (if possible) this running on the HURD.

I have been occasionally working on some Debian-related tasks. Chrony One of those was to get chrony is a slightly better shape, by using, at least, a patch system (indeed, I "modernized" its packaging with the format "3.0 (quilt)"), put it in a git repository and would like to receive some comments on what I have so far. The bug Debian bug #694690 contains a very brief description of my intentions and of the problems that I see in the current package. IMVHO, it is a very nice NTP client and server and it could even be used as the default for Debian, once it gets in shape. There is at least another high-profile distribution, namely Fedora, that switched to chrony as its default NTP software. We can certainly take a look at what they are doing and join forces here. MongoDB Another package where I spent some time was with mongodb: MongoDB is a tricky package that is only built for 2 arches: amd64 and i386. The version in unstable for i386 was 2.0.x (roughly the same as for wheezy), which the version in unstable for amd64 was 2.4.1, which has many features that 2.0 lacks. The packaging of it is a bit tricky, since the source tree has bazillion embedded/convenience libraries (e.g., Google's v8, Mozilla's spidermonkey, BOOST, Google's Snappy, PCRE 3 etc.). Up to version 2.4.1-2, it used all these convenience copies, which is of course, a problem for a distribution like Debian. I changed part of the build process to use the libraries that we already have in Debian and, as Antonin Kral uploaded this newer version, unsurprisingly the binary packages are smaller (especially if you take into account that a handful of the libraries may already be installed on the system). A few hours later, Antonin uploaded a new upstream version, which means that we now have better MongoDB packages to play with. I am, in fact, really playing with MongoDB as my first NoSQL database, since 10gen is giving an introductory course on how it works and my motivation was to get what we have in Debian in shape for the course. You can say that I am a firm believer of the "eat your own dogfood" principle. Regarding MongoDB only being built for i386 and amd64, the BTS has a patch to enable building for kFreeBSD, but the patch is for the 2.0 series and the code has changed so drastically in relation to the 2.4 series that there is no hope of it applying. It would be super nice to have MongoDB working on kFreeBSD and on HURD also, though. nocache There is a very nice command line program called nocache that was packaged by Dmitry Smirnov (and just approved by the FTP masters!) whose packaging I briefly reviewed per Dmitry's request and this is an amazing utility whose purpose is to bypass/minimize file system caching for a program. This is especially useful when you are making backups (reading lots of files that would, otherwise, fill the filesystem cache, even if they are not used frequently) or if you are just streaming one file (possibly larger than the system's RAM) to another computer and you have no need to use the file immediately after that. It performs its job by using the LD_PRELOAD mechanism and using posix_fadvise's flag POSIX_FADV_DONTNEED for the files that will be touched. Post note Oh, just one aside: for the readers of Debian Planet and other aggregation services which are not Debian Developers/Maintainers, I contributed to these packages without being the maintainer of them, just scratching some itches and contributing back what I produced.

(actually, please set your calendars to the day before yesterday I had a mental tab on this, but it seems watching mental tabs is a low-priority task for brain.sched) Ten years ago today, I got that long awaited mail telling me I had passed all of the needed hurdles and was accepted as a Debian Developer. We were at the first third of a very long release cycle, and the general spirit of the project was clearly younger both as in "things moved easier" and "we were much more immature" Try to follow the mailing list discussions we had back then, and even with all the vitriol that's every now and then spilled on debian-whatever@lists.debian.org, it's clear we have more experience working together. And yes, the main change that ten years bring to a group of people is social. I was at DebConf in Oslo when the now-historic presentation that prompted the birth of the Debian-Women group was given Surely, Debian (and Free Software) still is by far predominantly male and white But I fel it's no longer a hostile group, much to the contrary. Over the years, I was first active (as was the norm by then) as a "solo" maintainer. When Joachim Breitner started the pkg-perl group in 2004, I joined, and was part of the group while an important part of my work was based in Perl. I joined pkg-ruby-extras, and slowly migrated my technical work from one to the other. For several years, I also maintained the Cherokee webserver. I started getting involved in DebConf organization in 2005, and (except for 2008, as I took a vacation from many topics due to personal issues). Back in 2009, I became an official delegate! I joined Jonathan McDowell handling keyring maintenance. One year later, another delegation: With Moray Allan and Holger Levsen, the three of us became the DebConf chairs. This last couple of months, I have been quite inactive in most of my Debian work. I took up teaching at the univerity, and have been devoting what amounts to basically a full time job to prepare material. I expect (hope!) this craze to reach back a "workable" level by late May, when the course finishes, and I can retake some of my usual Debian tasks. Anyway 10 years. Wow. This project is one of the longest commitments in my life. I am still very happy I joined, it still thrills me to say I am part fo this great project, it still makes me proud to be accepted as a peer by so many highly skilled and intelligent people But, as I have repeatedly stated, I see Debian more as a social project (with a technological product) than as a technical one. And as such, I am really happy to have made so many good, close friends in this project, to have the opportunity to work and exchange points of view about anything, and have this large, highly disfunctional but very closely regarded family of friends. So, guys, see you this August in Switzerland. I will be among the group celebrating we have been there for half of the project's history!

This next Tuesday, April 23rd, 2013, a few of us Debian people in the Netherlands will get together for beer and keysigning in Belgisch Bier Caf Olivier in Utrecht. If you are in the area, feel free to come, have a beer or two and mingle! Find the exact details in this debian-events-nl mail. See you there!

CALL FOR PARTICIPATION: Shogun Machine Learning Workshop, Berlin, Germany, July 12-14, 2013 Data Science, Big-Data are omnipresent terms documenting the need for automated tools to analyze the ever growing wealth of data. To this end we invite practitioners, researchers and students to participate in the first Shogun machine learning workshop. While the workshop is centered around the development and use of the shogun machine learning toolbox, it will also feature general machine learning subjects. General Information The workshop will include:

• A general introduction to machine learning held by Gunnar Raetsch.
• Introductory talks about e.g. Dimension reduction techniques, Kernel-statistical testing, Gaussian Processes, Structured Output learning.
• Contributed talks and a poster session, and a poster-spotlight.
• A discussion panel
• A hands on session on July 13-14

Do not miss the chance to familiarize yourself with the shogun machine learning toolbox for solving various data analysis tasks and to talk to their authors and contributors. The program of the workshop will cover from basic to advanced topics in machine learning and how to approach them using Shogun, which makes it suitable for anyone, no matter if you are a senior researcher or practitioner with many year's of experience, or a junior student willing to discover much more. Interested? A tentative schedule is available at http://shogun-toolbox.org/page/Events/workshop2013_program. Call for contributions The organizing committee is seeking workshop contributions. The committee will select several submitted contributions for 15-minute talks and poster presentations. The accepted contributions will also be published on the workshop web site. Amongst other topics, we encourage submission that

• are applications / publications utilizing Shogun
• are highly relevant to practitioners in the field
• are of broad general interest
• are extensions to Shogun

Submission Guidelines Send an abstract of your talk/contribution to shogun-workshop2013@shogun-toolbox.org before June 1. Notifications will be given on June 7. Registration Workshop registration is free of charge. However, only a limited number of seats is available. First-come, first-served! Register by filling out the registration form. Location and Timeline The main workshop will take place at c-base Berlin (http://c-base.org/, https://en.wikipedia.org/wiki/C-base) on July 12. It is followed by additional 2-day hands-on sessions held at TU Berlin on July 13-14. About the Shogun machine learning toolbox Shogun is designed for unified large-scale learning for a broad range of feature types and learning settings, like classification, regression, or explorative data analysis. Further information is available at http://www.shogun-toolbox.org.