I'm working on porting FreeGLUT for Android, and FreeGLUT is switching to CMake. I'm more familiar with the GNU Autotools myself, and I'm used to cross-compile with a simple:

./configure --host=arm-linux-androideabi

Can we do that with CMake? Well, it's not well-documented, but yes :) Let's see how to do that for Android (smartphones) and MinGW (.exe for windows).

---

The principle is:

• write a "toolchain" CMake script that defines the cross-compiler,
• mention you're using a "GNU" compiler (a.k.a. GCC) so CMake automatically looks for prefixed cross-compilers tools such as arm-linux-androideabi-cpp or arm-linux-androideabi-ld.
• pass the toolchain script to CMake using the predefined CMAKE_TOOLCHAIN_FILE variable.
• REMOVE all the CMake-generated files when you change anything, CMake does not rebuild its cache when the toolchain script or PATH is modified, this creates misleading errors. Hence, building in a subdirectory is crucial.

Here's a simple toolchain script:

SET(CMAKE_SYSTEM_NAME Linux)  # Tell CMake we're cross-compiling
include(CMakeForceCompiler)
# Prefix detection only works with compiler id "GNU"
# CMake will look for prefixed g++, cpp, ld, etc. automatically
CMAKE_FORCE_C_COMPILER(arm-linux-androideabi-gcc GNU)
SET(ANDROID TRUE)

Note: SET(ANDROID TRUE) is not mandatory for CMake, it's just used to detect an Android build in the particular case of FreeGLUT development. Here's how to invoke it:

PATH=/usr/src/ndk-standalone-9/bin:$PATH
cd /usr/src/freeglut-3.0.0/
mkdir cross-android/ && cd cross-android/
cmake \
  -D CMAKE_TOOLCHAIN_FILE=../android_toolchain.cmake \
  -D CMAKE_INSTALL_PREFIX=/freeglut \
  ..
make -j4
make install DESTDIR=$(pwd)

---

Now here's a slightly more complex toolchain for MinGW. The main issue with MinGW is that there are at least 4 possible prefixes depending on which version and which distro you're using. So I ask the user to specify it with GNU_HOST:

SET(CMAKE_SYSTEM_NAME Windows)
include(CMakeForceCompiler)
IF("$ GNU_HOST " STREQUAL "")
    SET(GNU_HOST i586-mingw32msvc)
ENDIF()
# Prefix detection only works with compiler id "GNU"
CMAKE_FORCE_C_COMPILER($ GNU_HOST -gcc GNU)
# CMake doesn't automatically look for prefixed 'windres', do it manually:
SET(CMAKE_RC_COMPILER $ GNU_HOST -windres)

I wanted to print an error when GNU_HOST is not specified, but the toolchain script is loaded multiple times, and the command-line variables are not always set (CMake is not super-clean in that regard). So I defined a default, that works. Sample invocation:

  apt-get install mingw-w64
  mkdir cross-woe/ && cd cross-woe/
  cmake \
    -D GNU_HOST=x86_64-w64-mingw32 \
    -D CMAKE_TOOLCHAIN_FILE=../mingw_cross_toolchain.cmake \
    -D CMAKE_INSTALL_PREFIX=/freeglut \
    ..
  make -j4
  make install DESTDIR=$(pwd)

---

I used this technique to cross-compile my projects, or other projects that use CMake. mingw-cross-env uses this technique (abeilt with explicit definition of all compiler tools) to provide pre-built windows libraries without altering the existing CMake scripts. Do you people have tips or a better technique to cross-compile with CMake?

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.

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.

_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.

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?

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!

SQLAlchemy, MySQL and sql_mode=traditional As everyone should know, by default MySQL is an embarassing stupid toy:

mysql> create table foo (val integer not null);
Query OK, 0 rows affected (0.03 sec)
mysql> insert into foo values (1/0);
ERROR 1048 (23000): Column 'val' cannot be null
mysql> insert into foo values (1);
Query OK, 1 row affected (0.00 sec)
mysql> update foo set val=1/0 where val=1;
Query OK, 1 row affected, 1 warning (0.00 sec)
Rows matched: 1  Changed: 1  Warnings: 1
mysql> select * from foo;
+-----+
  val  
+-----+
    0  
+-----+
1 row in set (0.00 sec)

Luckily, you can tell it to stop being embarassingly stupid:

mysql> set sql_mode="traditional";
Query OK, 0 rows affected (0.00 sec)
mysql> update foo set val=1/0 where val=0;
ERROR 1365 (22012): Division by 0

(There is an even better sql mode you can choose, though: it is called "Install PostgreSQL") Unfortunately, I've been hired to work on a project that relies on the embarassing stupid behaviour of MySQL, so I cannot set sql_mode=traditional globally or the existing house of cards will collapse. Here is how you set it session-wide with SQLAlchemy 0.6.x: it took me quite a while to find out:

import sqlalchemy.interfaces
# Without this, MySQL will silently insert invalid values in the
# database, causing very long debugging sessions in the long run
class DontBeSilly(sqlalchemy.interfaces.PoolListener):
    def connect(self, dbapi_con, connection_record):
        cur = dbapi_con.cursor()
        cur.execute("SET SESSION sql_mode='TRADITIONAL'")
        cur = None
engine = create_engine(..., listeners=[DontBeSilly()])

Why does it take all that effort is beyond me. I'd have expected this to be turned on by default, possibly with a switch that insane people could use to turn it off.

I ve just started to use it. Next time I m able to show you how stable is Zenbook under Linux. Right now it s not helpful:
fenio@zenbook ~ $ downtimes
Maybe the system has not been down yet?
downtimes: can not open /var/lib/downtimed/downtimedb: No such file or directory
fenio@zenbook ~ $
Next time it will really

With first RC for phpMyAdmin 3.5, we're really close to final release, so let's again look at translations status. Here comes fourth round of translation status update. Since last update we have three new translations at 100%:

• Czech
• English (Great Britain)
• Estonian
• French
• Japanese
• Russian
• Slovenian
• Spanish
• Swedish
• Turkish

There are few which are really close to 100% and I hope they will get there soon:

• Danish
• Dutch
• Italian
• Polish

As you can see, there is still lot of languages missing, this might be your opportunity to contribute to phpMyAdmin.

Filed under: English Phpmyadmin 2 comments Flattr this!

The 13th Debian Conference is just around the corner. DebConf12 will be held in Managua, Nicaragua, July 8-14, 2012, and we need your help! Why should I care? DebConf is the annual conference for Debian contributors and interested users. Previous Debian Conferences have featured speakers and attendees from around the world (DebConf11 had attendees from 46 different countries). DebConf helps share the knowledge and experiences of individual developers with the entire community. It also helps promote enthusiasm for specialized areas of development and encourages discussions about Debian s future. The benefits that DebConf brings to the Debian project as a whole, and the larger Free Software community, will improve Debian and by extension will help improve GNU/Linux for everyone, whether they use Debian (or a Debian derivative), or any other distribution. How can I help? DebConf is a lot to organize and pay for. We invite you to help that this is going to be a successfull event.

• Since DebConf is an event organised by volunteers, its quality strongly depends on effort from these volunteers and as such every help is appreciated. Please check the Volunteering section to obtain more information
• Without money we can not organize a Debconf. Donating is a great way to help us.
• Do you want to be one of our generous sponsors? You can get nice publicity and contribute valuably to this DebConf.

Soile, my fiancee, has had a successful Kickstarter campaign. The minimum requirement has been met. There's a couple more days to go still, so maybe it will go beyond the minimum, even. <iframe allowfullscreen="allowFullScreen" frameborder="0" height="220" mozallowfullscreen="mozallowfullscreen" src="http://player.vimeo.com/video/36767480?title=0&amp;byline=0&amp;portrait=0" webkitallowfullscreen="webkitAllowFullScreen" width="400"></iframe> Maria Eveliina's Valentine from Soile Mottisenkangas on Vimeo. (See https://vimeo.com/36767480 if the embedded video doesn't work.) She's also created some designs for merchandise. Exciting times.

Also this year the Debian Project is running a booth at Chemnitzer Linux-Tage. Unfortunately this year we are lacking a bit manpower compared to the last years. Actually we have 6 persons at our wiki without knowing how much time everybody will be present at the booth. It would be really cool, if we can prevent us from having a D j vu.
So if you want to visit one of the best community focused OpenSource events in germany and can invest some time helping to run our booth, have a look into the report from last year and the organization wiki. If you feel you want to be part of this enjoyable event, please get in touch with me. As the registration for the booth is closing on 28th February, don t wait too long! ;)

Our society is one that is pretty well defined by timeliness. TV programs start at a precise time, down to the second. Schools have elaborate timekeeping systems. Even church services are carefully timed. We know how fast we re going, and our GPS or phones tell us when we ll get there. And we re pretty confident that we will, in fact, get there. Somehow this doesn t apply to our pickup. This pickup, in case you re wondering, is a thing of stories, shall we say. After a particularly frustrating experience with it one week (oh yes, the battle extended several days), I likened it to the Greek gods. And Terah had a good laughing fit when I began a sentence with The reason there s a towel connecting the brake pedal to the steering wheel But I guess the thrifty side of me won out, and somewhere along the line, I relented. My brother fixed up the carburetor. I got it a new battery. The flat tire is repaired. The starter broke, and I got it replaced. And I even got an oil change. Fancy, I know. So today, when I needed to take some backbreaking junk off the yard, I was hoping the pickup would work. I hadn t driven it in months, and any manner of catastrophe could have struck it in that time. So I was mildly relieved when it started on the 6th try. That is, quite seriously, quite the improvement, and shows how skilled a mechanic my brother is. The speedometer, of course, isn t working. The odometer stupidly reads 21531 or something like that (it was only a 5-digit odometer, broke long ago, so who knows how many miles it really has.) And I like to keep things like grease and heavy ancient air conditioners (one of the things I was hauling) away from my watch, so I wasn t wearing it. The result: I have no idea what time it is, how fast I m going, when I ll get there, IF I ll get there, or all those things. I set out, and made it a good half mile before it died as I was rounding a corner at the bottom of the hill. Always a great place for a finicky old stick-shift vehicle to die, right? Anyhow, a few random adjustments to the choke later, and the thing sputtered then roared (and I do mean roared) back to life. A little lurching up the hill and I was back on my way. Now, I was stuck there in the middle of the road, but it was a country road, so I d have probably had a good hour to get it fixed before worrying about blocking anybody s way. My first stop: my great uncle s place. He has a scrap metal for charity project going on. He is looking for old motors, air conditioners, dehumidifiers, etc. He takes them apart, separates out the metals, sells them, and donates the result to MCC, a world relief agency. I knew I had an old dehumidifier in the basement, and thought I remembered seeing an old window air conditioner in the elevator. That thing is probably the single heaviest object I have ever moved without help. I have a bandaid to prove it. It was way too heavy to carry, so I kind of rolled it, side to side, from the side of the elevator on to the pickup. If you were watching, you d have heard me making struggling noises, followed by BANG rattle rattle rattle pause struggling noises . BANG rattle rattle rattle as I rolled it along the ground, and waited for the internal bits to settle after each quarter turn. So anyway, eventually I got it to the pickup, and then had the sickening realization: I have no way to get this thing up there. Oops. I eventually placed it on top of an old tire rim, balanced it there as I knelt down, and somehow still not quite sure how managed to lift the entire thing a few feet until I could get some leverage to shove it onto the pickup. I later commented to my dad that it was a Chrysler brand air conditioner, somewhat to my surprise, and he said that it was probably my great-grandpa s. That was a surprise. Anyhow, back to the pickup. I drove down the few miles to my great grandpa s place, not really knowing how fast I was going. I smelled the familiar smells of the old pickup: exhaust fumes, oil on hot surfaces it shouldn t be on, a touch of hot antifreeze. You never have any doubt about whether the engine is running. It was sort of nice to not know, or particularly care, how fast I was going, or what time it was. Sometimes I d idly wonder, but you know, it didn t really matter and there wasn t a thing I could do about it anyhow. I got to uncle s place, unloaded the junk sorta dropped the air conditioner off the back of the pickup with a terrific BANG, then rolled it all the way to his trailer and got back in. On to town. I hadn t put gas in the pickup in a few years, and I suspected it was getting low. (The gas gauge, you guessed it, doesn t work right either.) Plus we had some large recyclables built up and it was time to get rid of them. And for that, I had to drive on the highway a ways. The speed limit there is 65MPH. I have no idea how fast I was going, but it wasn t 65. Maybe it was 45. I got passed a lot, but nobody looked particularly surprised that a pickup that looks like mine wasn t going 65. Partway there, I smelled a different smoke smell. Not an oil smoke, but more of a grassy or wood smoke. Hmm, I thought. That s odd. Hope it s not coming from the pickup. I didn t really see smoke anywhere else, so I just drove on until I couldn t smell it anymore. I unloaded the recyclables, then went to the gas station. As the pump readout neared $50, I decided: 1) the gas tank really was pretty empty, and 2) I just can t put more gas in it anymore. That would be more than the truck s worth. So I drove home. The drive home was into the wind. My face got pretty cold I always drive with the windows open to prevent carbon monoxide poisoning (remember the fumes?) I got home and prepared to pack up the pickup close the windows, replace the bungee cord holding the brake pedal up, etc. I then thought I d have a look under the hood to see if there was anything, well, on fire. Nope, but there was a packrat nest that fell down as soon as the wind hit it. Source of grassy-smelling smoke identified. It s amazing what difference simple lack of knowledge makes sometimes. Not knowing what time it is or how fast I m going means I don t have to worry about those things. I wonder how society has changed simply because accurate and cheap watches are available. I kind of like driving the old truck. It s a bit of an adventure, a bit of a challenge, a bit of randomness, and a bit of an escape from the normal and predictable. Not a bad deal for a $75 vehicle.