For those of you were were in the various Debian infrastructure channels, you might have noticed that I was playing around with wanna-build, dak, sbuild, and buildd and friends. [Thanks to everyone who answered questions, btw.] Over the past week, I've been building most of CRAN, Bioconductor, and omegahat for unstable, amd64. I plan to build the same set of packages for i386, and will start a build shortly for stable as well. This effort builds on top of Charles Blundell and Dirk Eddelbuettel's cran2deb, which does most of the heavy lifting. If you're like me, and use lots of different R packages, or already use some of the R packages available on the previous build, you can simply point your sources.list to the [http://debian-r.debian.net] archive, load the appropriate GPG key, and away you go. I have a bit more information available here and I will try to keep that page updated as I build other architectures and build out for stable.

From February 17 to 19th 2012, between 10 to 30 hackers met at IRILL's offices to squash as many bugs as possible for the Wheezy release. Besides about 42 pizzas, more than one hundred bugs (104 to be precise) have been fixed. Among them, 18 of them were fixed by removing old/unmaintained/deprecated packages from the Debian archive. In a great atmosphere, one of the most important achievements of this BSP was that Yada, a deprecated packaging helper, finally passed away thanks to the efforts of Cyril Brulebois. Thanks for all the contributors for making of this week end a success.

I m thinking of rewriting Syn, but this time, with the lessons learned from Syn1, 2, and 3. While I don t want to rewrite it (again), it ll be a nice time to simplify the project, and give it a chance to actually function (well) as a LFS-esque package manager. Hopefully, this can be the final rewrite.

TL;DR link: faulty.lib is on github. Android applications are essentially zip archives, with the APK extension instead of ZIP. While most of Android is java, and java classes are usually loaded from a ZIP archive (usually with the JAR extension), Android applications using native code need to have native libraries on the file system. These native libraries are found under /data/data/$appid/lib, where $appid is the package name, as defined in the AndroidManifest.xml file. So, when Android installs an application, it puts that APK file under /data/app. Then, if the APK contains native libraries under a lib/$ABI subdirectory (where $ABI is armeabi, armeabi-v7a or x86), it also decompresses the files and places them under /data/data/$appid/lib. This means native libraries are actually stored twice on internal flash: once compressed and once decompressed. This is why Chrome for Android takes almost 50MB of internal flash space after installation. Firefox for Android used to have that problem, and we decided we should stop doing that. Michael Wu thus implemented a custom dynamic linker, which would load most of Firefox libraries directly off the APK. This involves decompressing the zipped data somewhere in memory, and doing ld.so s job to make the library usable (please note that on Android, ld.so is actually named linker). There were initially circumstances under which we would decompress into a file and reuse it the next time Firefox starts, but we subsequently removed that possibility (except for debugging purpose) because it ended up being slower than decompressing each time (thanks to internal flash being so slow). Anyways, in order to do ld.so s job, our custom linker was directly derived from Android s system linker, with many tweaks. This custom linker has done its job quite well for some time, now, but has been recently replaced, see further below. Considering Firefox can t do anything useful involving Gecko until its libraries are loaded, in practice, this means Firefox can t display a web page faster than completely decompressing the libraries. Or can it? Just don t sit down cause I ve moved your chair We know that a lot of code and data is not used during Firefox startup. Based on that knowledge, we started working on only loading the necessary bits. The core of the idea is, when a library is requested to be loaded, to reserve anonymous memory for its decompressed size, and that s all. That memory is protected such that any access to it triggers a segmentation fault. When a segmentation fault happens, the required bits are decompressed, and execution is resumed where it was before the segmentation fault. The original prototype was decompressing from a normal zip deflated stream, which means it was impossible to seek in it. So, if an access was made at the end of the library, it was necessary to decompress the whole library. With some nasty binary reordering, and some difficulty, it was possible to avoid accessing the end of the library, but the approach is very much fragile. It only takes an unexpected code path to make things much slower than they should be. Consequently, for the past months, I ve been working on improving the original idea and, with some assistance from Julian Seward, implemented the scheme with seekable compressed streams. Instead of letting the zip archive creation tool deflate libraries, we store specially crafted files. Essentially, files are cut in small chunks, and each chunk is compressed individually. This means a less efficient compression, but it also means random access to chunks is possible. However, instead of stacking on top of our existing custom linker, I started over, from the ground up. First, because it needed a serious clean up (a good part of linker.c is leftovers from the Android linker that we don t use, and APKOpen.cpp is a messy mix of JNI stubs, library decompression handling (which in itself was also a mess) and Gecko initialization code) and most importantly, because it relied on some Android system linker internals and thus required binary compatibility with the system linker. Which, according to Google engineers that contacted us a few months ago, was going to break in what we now know will be called Android Jelly Bean. The benefit of the clean slate approach is that the new code is not tied to Gecko at all and was designed to work on Android as well as on desktop Linux systems (which made debugging much much easier). We re thus releasing the code as a separate project: faulty.lib. It is licensed under the Mozilla Public License version 2.0. Please feel free to try, contribute, and/or fork it. This dynamic linker is not meant to completely follow standard ELF rules (most notably for symbol resolution), and as a result does some assumptions. It s also still work in progress, with some obvious optimizations pending (like, avoiding to resolve the same symbols again and again during relocations), and some features missing (for example, symbol versioning). The next blog post will give some information about how to build Firefox for Android to benefit from on-demand decompression. I will also detail a few of the tricks involved in this dynamic linker in subsequent blog posts.

This follows up on a previous post, and tries to summarize the corrections and suggestions I received. First, a reminder: yes, I'm really looking for a filesystem, not a storage system. Even if I only consider the music files use case, there are just too many things that want to access the files, and there's no way I'm going to port these things to use the storage system's API instead of plain old file access. Examples? The Rhythmbox player. The XMMS2 player. The mt-daapd/forked-daapd DAAP server. My script to backup or restore metadata (tags). Ex-Falso, to do mass edits on these tags. abcde, to add new files when I buy a new CD. Any kind of shell one-liners I currently do without thinking because find, xargs, cp, ln, and so on all operate on files. I understand that providing filesystem semantics on top of a storage system is hard, but that doesn't change my requirements, and saying otherwise is patronising. So, on to the meat of the matter. Apparently my understanding of Tahoe-LAFS was mostly correct. It seems that multiple introducers are on their way to become a reality, which would mean the one remaining central point would go away. Most of my other complaints seem to be on their way to be resolved, too, except that it's still targeted as a storage system, and the FUSE/sshfs layer on top still has its drawbacks (quoting from the wiki, Before uploading a file to a Tahoe filesystem, the whole file has to be available , mutable parts of a filesystem should only be accessed via a single sshfs mount [...] data loss may result for concurrently accessed files if this restriction is not followed and so on). From what I read, the position is that nobody publicly uses Tahoe's filesystem integration, therefore there's no need to fix its shortcomings; my understanding is that nobody uses it precisely because of its shortcomings. Ceph: apparently does repair/rebalance automatically contrary to what I thought. However, two persons told me that it's really expecting all nodes on the same LAN, and geographically distributed setups aren't really targeted. XtreemFS: I don't think I got any comments on my evaluation, so I'll assume it still stands. git-annex: storage system, not a filesystem. Yes, the files can be made available in the filesystem, but if I need to manually retrieve them before accessing them, this doesn't work. GlusterFS: I'd like to read more docs on how it works, but I haven't been able to find them. Apart from the installation manuals, the only documentation I found was a very short Concepts page, which described some of the concepts but didn't give me the big picture on how the who thing works. (I'm turning a blind eye on the Red Had advertisements and the requiremets that everything be installed on RH machines; the hardware requirements are also quite out of line with what I want to do.) HekaFS (aka CloudFS): I found even fewer docs about this one than about GlusterFS, and apparently HekaFS is on its way to being merged into GlusterFS anyway. PlasmaFS: I didn't know about this one previously, but the one email I got about it was mainly full of this won't work and this won't work either . I didn't feel inclined to read further docs after that. In summary, I guess the replies I got didn't cause me to change my mind too much. Tahoe-LAFS still seems to be, if not the best solution, then at least the least bad . Hopefully the drawbacks will be fixed soonish; the main sticking point (at least from my point of view) still seems to be the lack of focus on proper filesystem integration. I'll try setting it all up at some point; I may report further if I end up finding interesting things. Thanks to all who responded!

This is my monthly summary of my Debian related activities. If you re among the people who made a donation to support my work (384.14 , thanks everybody!), then you can learn how I spent your money. Otherwise it s just an interesting status update on my various projects. Dpkg and multiarch The month started with a decision of the technical committee which allowed me to proceed with an upload of a multiarch dpkg even if Guillem had not yet finished his review (and related changes). Given this decision, Guillem made the experimental upload himself. I announced the availability of this test version and invited people to test it. This lead to new discussions on debian-devel. We learned in those discussions that Guillem changed his mind about the possibility of sharing (identical) files between multiple Multi-Arch: same packages, and that he dropped that feature. But if this point of the multiarch design had been reverted, it would mean that we had to update again all library packages which had already been updated for multi-arch. The discussions mostly stalled at this point with a final note of Guillem explaining that there was a tension between convenience and doing the right things every time that we discuss far-reaching changes. After a few weeks (and a helpful summary from Russ Allbery), Guillem said that he remained unconvinced but that he put back the feature. He also announced that he s close to having completed the work and that he would push the remaining parts of the multiarch branch to master this week (with the 1.16.2 upload planned next week). That s it for the summary. Obviously I participated in the discussions but I didn t do much besides this I have a mandate to upload a multiarch dpkg to sid but I did not want to make use of it while those discussions remained pretty unconclusive. Also Guillem made it pretty clear that the multiarch implementation was buggy , not right and not finished and that he had reworked code fixing at least some of the issues since he never shared that work in progress, I also had no way to help even just by reviewing what he s doing. We also got a few multiarch bug reports, but I couldn t care to get them fixed since Guillem clearly held a lock on the codebase having done many private changes it s not quite like this that I expect to collaborate on a free software project but life is full of surprises! I ll be relieved once this story is over. In the mean time, I have added one new thing on my TODO list since I made a proposal to handle bin-nmu changelogs and it s something that could also fix #440094. Misc dpkg stuff After a discussion with Guillem, we agreed that copyright notices should only appear in the sources and not in manual pages or --version output, both of which are translated and cause useless work to translators when updated. Guillem already had some code to do it for --version strings, and I took care of the changes for the manual pages. I merged some minor documentation updates, fixed a bug with a missing manpage. Later I discovered that some recent changes lead to the loss of all the translated manual pages. I suggested an improvement to dh_installman to fix this (and even prepared a patch). In the end, Guillem opted for another way of installing translated manual pages. Triggered by a discussion on debian-devel, I added a new entry to my TODO list: implementing dpkg-maintscript-helper rm_conffile_if_owner to deal with the case where a conffile is taken over by another package which might (or might not) be installed. Misc packaging At the start of the month, I packaged quilt 0.51. The number of Debian specific patches is slowly getting down. With version 0.51, we dropped 5 patches and introduced a new one. Later in the month I submitted 4 supplementary patches upstream which have been accepted for version 0.60. This new version (just released, I will package it soon) is an important milestone since it s the first version without any C code (Debian had this for a long time but we were carrying an intrusive patch for this). Upstream developer Jean Delvare worked on this and based his work on our patch, but he went further to make it much more efficient. Besides quilt, I also uploaded dh-linktree 0.2 (minor doc update), sql-ledger 2.8.36 (new upstream version), logidee-tools 1.2.12 (minor fixes) and publican 2.8-2 (to fix release critical bug #660795). Debian Consultants The Debian Project Leader is working on federating Debian Companies. As the owner of Freexian SARL, I was highly interested in it since Freexian contributes to Debian, offers support for Debian and has a strategic interest in Debian . There s only one problem, you need to have at least 2 Debian developers on staff but I have no employees (it s me only). I tried to argue that I have already worked with multiple Debian developers (as contractors) when projects were too big for me alone (or when I did not have enough time). Alas this argument was not accepted. Instead, and since our fearless leader is never afraid to propose compromises, he suggested me (and MJ Ray who argued something similar than me) to try to bring life to the Debian Consultants list which (in his mind) would be more appropriate for one-man companies like mine. I accepted to help animate the list, and on his side, he s going to promote both the Debian Companies and the Debian Consultants lists. In any case, the list has seen some traffic lately and you re encouraged to join if you re a freelancer offering services around Debian. The most promising thing is that James Bromberger offered to implement a real database of consultants instead of the current static page. Book update We made quite some progress this month. There s only one chapter left to translate. I thus decided to start with proofreading. I made a call for volunteers and I submitted one (different) chapter to 5 proofreaders. The liberation campaign made a nice leap forwards thanks to good coverage on barrapunto.com. We have reached 80% while we were only at 72% at the start of the month (thanks to the 113 new supporters!). There s thus less than 5000 EUR to raise before the book gets published under a free license. Looking at the progression in the past months, this is unlikely to be completed on time for the release of the book in April. It would be nice though so please share the news around you. Speaking of the book s release, I m slowly preparing it. Translating docbook files is not enough, I must be able to generate HTML, ePub and PDF versions of the book. I m using Publican for most formats, but for the PDF version Publican is moving away of fop and the replacement (webkit-based) is far from being satisfactory to generate a book ready for print. So I plan to use dblatex and get Publican to support dblatex as a backend. I have hired Beno t Guillon, the upstream author of dblatex, to fix some annoying bugs and to improve it to suit my needs for the book (some results are already in the upstream CVS repository). I m also working with a professional book designer to get a nice design. I have also started to look for a Python Django developer to build the website that I will use to commercialize the book. The website will have a larger goal than just this though ( helping to fund free software developers ) but in free software it s always good to start with your own case. Hopefully everything will be ready in April. I m working hard to meet that deadline (you might have noticed that my blog has been relatively quiet in the last month ). Thanks See you next month for a new summary of my activities.

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

Hello, this is just a quick post to announce some good news. Back in 2004 we ve formed a local Debian group in Peru. We were active and spread the word country-wide. There were good times. As time passed and interests changed things slowed down. Past two weeks we are rebooting it. We ll be working with focus towards mentoring people to contribute upstream and Debian. We ll also host meetings for teaching new users in a more concrete problem solving or the basics . Finally, we will be glad to host Debian Developers, as we have done in the past with people that landed in Peru, and organize either social or technical meetings. We ve set a Wiki page, that will be our official site, and has information regarding our group. Also our mailing list is getting traction. We ll be hosting a social meeting during the Creative Commons Movie Festival this Thursday March 1st. That s it!

Collusion is "an experimental add-on for Firefox and allows you to see all the third parties that are tracking your movements across the Web."
I am very eager to see how this evolves given that things like Adsense, no less, belong to Google, and Google (i believe, and please correct me if I am wrong), is one of Mozilla's biggest, erm, how to put it, "sponsors". Will Chrome get a similar feature? I am very veruy curious. This might be the biggest White Rabbit I've seen in a long time.

Back in October 2011, I blogged about the removal of the sun-java6 package from the Debian archive. Even if Openjdk 7 is just great, some corporations still need to use the non-free sun-java6 packages.
For perform this task, C dric Pineau and I brought back an old package from the archive called java-package. From the upstream release, for example jdk-6u*-linux-x64.bin (which the user will have download since Debian is no longer allowed to redistribute it), the command

make-jpkg ~/Downloads/jdk-6u31-linux-x64.bin

will generate a .deb which can be installed in the packaging system. Obviously, new upstream releases will NOT be automatically updated. This is far from perfect but it is temporary solution until everybody switch to the OpenJDK.

This leap day saw me driving along the river on a rainy, with 4 chickens in the car's trunk, and 3 terabytes of disk (and a half a bale of straw) in the back seat. I may have not been blogging much lately about life, because these situations can be hard to explain. (Or because "joined the Debian haskell team and spent two days working on rebuilds for the ghc 7.4 transition" is not thrilling reading.)

hens in a car

The Light Sussex chickens are my sister's spare flock, which are "too tame". They're now cozily installed into a coop we built last weekend. In return I gave her a 6 foot long APC power strip, which had been mounted on the wall of my office. I'm preparing my house in town to be rented, and have little need for two dozen power outlets here in solar power land. Indeed, today is a gift economy day all around -- when I arrived at the cabin, there on the porch was an unexpected package from Google. Particularly surprising since I never get deliveries here, since the driveway is a mile long and often seems like it could dead-end into the woods at any moment. The combination of technological wackiness (I also debugged a laptop whose USB hub hangs when a particular trackball is plugged in) and in your face country texture (including coal trains, being stuck behind a tractor, and miles of amazing tree-height mist) made this a memorable day.

_Something_ is going to happen at 06:00 GMT on 29th February. I predict a server meltdown ..

==

Product available from RS Components and Farnell.com - both servers not responding. Effectively a worldwide DDOS because of demand 29/2/2012

== 07:20 or so ==

Farnell sold out almost immediately: now taking pre-orders for the next batch
RS may be taking orders later in the week. [Per RaspberryPi Twitter feed]

Update: RS are also taking pre-orders and expressions of interest. Both companies will do their best to get stock to all ASAP.

Please don't blame Eben, Liz or the other RaspberryPi folks for this - they've worked miracles to get this far.

To negotiate proper licensing agreements with the two largest UK electronics distributors and get them to undertake manufacturing and distribution is, actually, a masterstroke for a small non-profit organisation.

* In case of you ve noticed, this blog has new URL: http://0x1f1f.wordpress.com, reading from Planet Debian doesn t harm your feed reader (if any readers left ). * On Debian front, I m mostly helping Debian-IN-Workers team to finish ttf->fonts naming transition and moving rest of packages to Git. Vasudev and Muneeb has done most of these work, well done! Rest of my time with Debian goes to usual updates of packages and in reading debian-devel during weekends. It is still fun, yeah. * And, illumian is born. * On personal side, life is great as usual. It looks that couple of dentist visit is coming soon. I also started jogging/running regularly since couple of months. In case you re interested, I m on dailymile too.

Last Friday, after 5 long years, I have finally submitted my PhD thesis. It was quite a relief, more or less as if an elephant was taken off my back. An English title for my thesis would be Structural Complexity Characterization in Software Systems. Here is an abstract:

This thesis proposes a theory to characterize structural complexity in software systems. This theory aims to identify (i) the contribution of several factors to the structural complexity variation and (ii) the effects of structural complexity in software projects. Possible factors in the structural complexity variation include: human factors, such as general experience of the developers and their familiarity with the different parts of the system; factors related to the changes performed on the system, such as size variation and change diffusion; and organizational factors, such as the maturity of the software development process and the communication structure of the project. Effects of structural complexity include higher effort, and consequently higher cost, in software comprehension and maintenance activities. To test the validity of the proposed theory, four empirical studies were performed, mining data from free software project repositories. We analyzed historical data from changes performed in 13 systems from different application domains and written in different programming languages. The results of these studies indicated that all the factors studied influenced the structural complexity variation significantly in at least one of the projects, but different projects were influenced by different sets of factors. The models obtained were capable of describing up to 93% of the structural complexity variation in the projects analyzed. Keywords: Structural Complexity, Software Maintainance, Human factors in Software Engineering, Mining Software Repositories, Theories in Software Engineering, Empirical Software Engineering, Free/Open Source Software Projects.

Those who read Portuguese can check out the actual thesis text as a PDF file. Most of the studies discussed in the thesis are presented in English in papers I have published during the last years. My defense is going to be on March 23rd. If you happen to be at Salvador at that day, please feel cordially invited.

In the last few days, people on the debian-devel mailing list have been debating again (and again, and again...) how much the ports and architectures used only by an handful of people should influence the direction of the project. With this post I want to briefly summarize my position. The reason we support niche architectures and toy ports is that that some people are interested in doing the work, and that these do not hinder development of the architectures that people actually use. When m68k started inconveniencing too much the real world development, the port was killed and the sky did not fall, notwithstanding the complaints of the few retrocomputing enthusiasts who still used and developed it. I do not mind if some people like to play with kFreeBSD and Hurd as long as they do not inconvenience me too much, both as a user and as a developer. While it is true that targeting multiple architectures helps finding bugs, after we have covered all the useful combinations of endianity, size of variables and char signedness the incremental benefits of adopting a new architecture just for its sake are minimal. I am a Red Hat customer (also because of Debian shortcomings), I do not like it much and I do not want to be one forever: please do not kill my hopes.

Recently, I have been working on a side project for Debian. The goal was to rebuild of the Debian archive (the distribution) with clang, a new C/C++ compiler. clang is now ready to build software for production (either for C, C++ or Objective-C). This compiler is providing many more warnings and interesting errors than the gcc suite while not carrying the same legacy as gcc.
This rebuild has several goals. The first one is to prove (or not) that clang is a viable alternative. Second, building a software with different compilers improves the overall quality of code by providing different checks and alerts. The result are detailed and explained here:
http://clang.debian.net/ Conclusions
When I had the idea to rebuild Debian with a new compiler, I was expecting many issues and bugs caused by clang but I have been surprised to notice that most of the issues are either difference in C standard supported, difference of interpretation or corner cases.
My personal opinion is that clang is now stable and good enough to rebuild most of the packages in the Debian archive, even if many of them will need minor tweaks to compile properly.
In the next few years, coupled with better static analysis tools, clang might replace gcc/g++ as the C/C++ compiler used by default in Linux and BSD distributions.
The clang developers are progressing very fast: 14.5% of the packages were failing with version 2.9 against 8.8% with version 3.0.
Several major steps in the clang adoptions have been made like chromium/chrome being built by default with clang, Xcode providing clang by default, FreeBSD working on the gcc -> clang switch, etc.
However, on the Debian point of view, one of the important step would be to make sure that clang manages all the Debian architecture/kernel (11 official, 6 unofficial)

I'm seeking advice on budgeting. Historically, I've been crap at managing money. Things have improved in recent years. My main tool is Martin Lewis' Money Saving Expert budget planner. It's simply a spreadsheet, into which you feed your income and outgoings. You can supply each line item as either a daily, monthly or annual income or expense. The sheet works out both a monthly and an annual total for each and the difference (be it positive or negative). The monthly summary is a useful benchmark against which you can compare your monthly bank statements, but it's not sufficient. Consider a one-off annual expense, such as a holiday payment. On the budget planner, the expense will be divided up into monthly chunks and deducted from your monthly income. However, the expense won't be on your bank statements, unless you've made a special arrangement to pay out a monthly sum to another account, such as savings account, for every annual expense. Therefore you can't just compare the planner's monthly summary against your bank statement summary and hope the two match. I really need to see what my monthly outgoings should total to, rather than what all my outgoings are, presented monthly, in order to meaningfully compare the two. How should I handle this? Should I do as I suggested there and total up my annual one-offs, divide by twelve and make a monthly payment for that sum to a savings account? I'd still want to be able to quickly look at my main statement and judge the overall figure as either 'good' or 'bad'. Perhaps I should feed my various statements into one place, perhaps a finance tool, in which case, which one? How do you manage your finances?

On the second day, I entered the train to Split early in the morning. The train was a bit crowded, but having a seat reserved helped. Unfortunatly I knew that kind of train already from home (here known as 612), and changing colours didn't make it a better train.
Train from Zagreb to Split in Gra ac After leaving Zagreb, the train went through nice countryside. After some time hills started - with given-up houses, walls, areas. As I learned in the meantime, this track used to be not the main line to Split but a backland-line. However, since the last war (the one from 1991-1995), the shorter and faster direct line is still cut. In Knin one could still see the reminders of the direct line which was electrified.
Landscape from within the train The railway was a mixture of historic operations (with many people, changing switches by going there and by hand and using flags instead of signals) and directly into the 21nd century with electronic signal boxes just being built.
train junction in Perkovi In spite of "the train should be an alternative to cars and busses"-speeches, as there was only one (and overcrowded) train suiteable for going to Split, priorities seem to be elsewhere (not too uncommon for politics on public transport in Europe). Also, there was obviously much more money put into the streets than into the trains. The journey to Split should have taken about 6 hours, but the train in the opposite direction was a bit late, so I arrived late about 30 minutes. Directly on the platform there was a crowd of people trying to let appartments to tourists etc. Ignoring that, I first got rid of my luggage in the train station, bought the bus ticket for the next leg, and as having planned for late trains still had ample of time to see Split. This was my first "southern" target on this journey, so I could say Hi to fig trees (and their smell as they were blooming at that time). Split itself has an historic center (being dated back to the Romans). One could also go up a hill and have an overview over both Split and the Adria. All in all I found Hrvatska being compareable to other nice parts of Europe: Many tourists, overcrowded, and prices similar to Germany. Usage of public transport by tourists seems strange, and mostly only done by interrailers.

I wonder am I the only one who feels that Gnome default thumbnail size is way too small? See the bug report for the background, motivation and a comparison screenshot P.S. The fix is simple dconf write /org/gnome/nautilus/icon-view/thumbnail-size 128; rm -r ~/.thumbnails/* and then close and restart your nautilus file browser.

For some time, we use Pootle as online translation tool for phpMyAdmin. It is indeed great tool, but somehow we seem to be hitting more and more issues with it and I feel it really won't fit nicely once we will want to support translations on two divergent branches. Also it's code base is not something easy to understand so that I would be able to fix bugs myself without major effort. So this is when I started to look for alternatives. Unfortunately there is nothing I could find what would work in way I want. I've looked at Transifex, Translatewiki, Crowdin and others whose names I've forgotten and I still haven't found what I'm looking for. The key feature I want from such system is full integration with git. This means that whatever is changed should be committed to local git branch and merging translations back should be as easy as merging remote branch. I've hacked such thing into Pootle (in quite dirty way), so this is basically workflow we have right now and I'm pretty much happy with that. Another thing (which seems to be existing in some tools) is support for simultaneous translation of more branches - if same string exists in more branches, it should be translated in all of them. And last but not least, it should support import of po files allowing users offline translation. Thinking about this I'm starting to thing that it should be pretty easy to implement something what I want using existing pieces of software without major effort. I'll probably start to play with Django, translate-tookit and GitPython to see if I can come up with something working reasonably well in few days... PS: Anybody working on updated GitPython packages for Debian, looks like I will need them soon :-).

Filed under: English Phpmyadmin Weblate 10 comments Flattr this!

The Debian/Ubuntu games team recently organised a half-day screenshots party for creating screenshots for all the games that are available in Debian/Ubuntu. Unfortunately, only 5 people participated in the screenshots party, I had hoped that we would get more folks turn up. Only one of those was not already involved in the games team and that one person found out via our spam on the #debian-mentors IRC channel. This means that most of our promotion of the event was ineffective. Hopefully for future games parties we can improve this, please let us know if you have any ideas about that. We also had 7 other people on the channel during the party lurking, discussing and or working on other things, in particular Ben Armstrong was working on a games live CD. Over the 7 hours of the party, we uploaded 100 screenshots for 40 different packages. Of the packages, 2 are available only in Debian (auralquiz, cutechess), one is available only in Ubuntu (plasma-widget-tictactoe) and the rest are available in both. I think we got quite a bit done for such a small group. Some of us could not resist filing some bugs on packages that had issues preventing or delaying us from taking screenshots. I also suggested to one maintainer that his package (acm4) be removed from Debian, since it is obsoleted by acm and unusable. If you want to play some games, check out goplay, which is a tool for browsing available games using debtags that displays screenshots from the games-thumbnails package, which has just been updated with the screenshots created during the party. goplay needs some more development, if you would like to help out with that, you would be most welcome. If you are interested to see our screenshots, they are all on the screenshots.debian.net website and the packages are auralquiz, cardstories, londonlaw, cube2font, ardentryst, cutechess, pianobooster, emacs-chess, xye, flare, tmw, garden-of-coloured-lights, flight-of-the-amazon-queen, geekcode, glpeces, fofix, unknown-horizons, klickety, polygen, tictactoe, xscreensaver-screensaver-dizzy, goban-original-games, xjokes, mudlet, xabacus, xtux-client, connectagram, crystalspace, pescetti, purity-ng, qstat, slashem, sudoku, minetest, xscavenger, plasma-widget-tictactoe, xbomb, xfrisk, xpilot-ng and xsok.