I've managed to go for eleven years working on Debian and nearly eight on Ubuntu without ever needing to teach myself how APT's resolver works. I get the impression that there's a certain mystique about it in general (alternatively, I'm just the last person to figure this out). Recently, though, I had a couple of Ubuntu upgrade bugs to fix that turned out to be bugs in the resolver, and I thought it might be interesting to walk through the process of fixing them based on the Debug::pkgProblemResolver=true log files. Breakage with Breaks The first was Ubuntu bug #922485 (apt.log). To understand the log, you first need to know that APT makes up to ten passes of the resolver to attempt to fix broken dependencies by upgrading, removing, or holding back packages; if there are still broken packages after this point, it's generally because it's got itself stuck in some kind of loop, and it bails out rather than carrying on forever. The current pass number is shown in each "Investigating" log entry, so they start with "Investigating (0)" and carry on up to at most "Investigating (9)". Any packages that you see still being investigated on the tenth pass are probably something to do with whatever's going wrong. In this case, most packages have been resolved by the end of the fourth pass, but xserver-xorg-core is causing some trouble. (Not a particular surprise, as it's an important package with lots of relationships.) We can see that each breakage is:

Broken xserver-xorg-core:i386 Breaks on xserver-xorg-video-6 [ i386 ] < none > ( none )

This is a Breaks (a relatively new package relationship type introduced a few years ago as a sort of weaker form of Conflicts) on a virtual package, which means that in order to unpack xserver-xorg-core each package that provides xserver-xorg-video-6 must be deconfigured. Much like Conflicts, APT responds to this by upgrading providing packages to versions that don't provide the offending virtual package if it can, and otherwise removing them. We can see it doing just that in the log (some lines omitted):

Investigating (0) xserver-xorg-core [ i386 ] < 2:1.7.6-2ubuntu7.10 -> 2:1.11.3-0ubuntu8 > ( x11 )
  Fixing xserver-xorg-core:i386 via remove of xserver-xorg-video-tseng:i386
Investigating (1) xserver-xorg-core [ i386 ] < 2:1.7.6-2ubuntu7.10 -> 2:1.11.3-0ubuntu8 > ( x11 )
  Fixing xserver-xorg-core:i386 via remove of xserver-xorg-video-i740:i386
Investigating (2) xserver-xorg-core [ i386 ] < 2:1.7.6-2ubuntu7.10 -> 2:1.11.3-0ubuntu8 > ( x11 )
  Fixing xserver-xorg-core:i386 via remove of xserver-xorg-video-nv:i386

OK, so that makes sense - presumably upgrading those packages didn't help at the time. But look at the pass numbers. Rather than just fixing all the packages that provide xserver-xorg-video-6 in a single pass, which it would be perfectly able to do, it only fixes one per pass. This means that if a package Breaks a virtual package which is provided by more than ten installed packages, the resolver will fail to handle that situation. On inspection of the code, this was being handled correctly for Conflicts by carrying on through the list of possible targets for the dependency relation in that case, but apparently when Breaks support was implemented in APT this case was overlooked. The fix is to carry on through the list of possible targets for any "negative" dependency relation, not just Conflicts, and I've filed a patch as Debian bug #657695. My cup overfloweth The second bug I looked at was Ubuntu bug #917173 (apt.log). Just as in the previous case, we can see the resolver "running out of time" by reaching the end of the tenth pass with some dependencies still broken. This one is a lot less obvious, though. The last few entries clearly indicate that the resolver is stuck in a loop:

Investigating (8) dpkg [ i386 ] < 1.15.5.6ubuntu4.5 -> 1.16.1.2ubuntu5 > ( admin )
Broken dpkg:i386 Breaks on dpkg-dev [ i386 ] < 1.15.5.6ubuntu4.5 -> 1.16.1.2ubuntu5 > ( utils ) (< 1.15.8)
  Considering dpkg-dev:i386 29 as a solution to dpkg:i386 7205
  Upgrading dpkg-dev:i386 due to Breaks field in dpkg:i386
Investigating (8) dpkg-dev [ i386 ] < 1.15.5.6ubuntu4.5 -> 1.16.1.2ubuntu5 > ( utils )
Broken dpkg-dev:i386 Depends on libdpkg-perl [ i386 ] < none -> 1.16.1.2ubuntu5 > ( perl ) (= 1.16.1.2ubuntu5)
  Considering libdpkg-perl:i386 12 as a solution to dpkg-dev:i386 29
  Holding Back dpkg-dev:i386 rather than change libdpkg-perl:i386
Investigating (9) dpkg [ i386 ] < 1.15.5.6ubuntu4.5 -> 1.16.1.2ubuntu5 > ( admin )
Broken dpkg:i386 Breaks on dpkg-dev [ i386 ] < 1.15.5.6ubuntu4.5 -> 1.16.1.2ubuntu5 > ( utils ) (< 1.15.8)
  Considering dpkg-dev:i386 29 as a solution to dpkg:i386 7205
  Upgrading dpkg-dev:i386 due to Breaks field in dpkg:i386
Investigating (9) dpkg-dev [ i386 ] < 1.15.5.6ubuntu4.5 -> 1.16.1.2ubuntu5 > ( utils )
Broken dpkg-dev:i386 Depends on libdpkg-perl [ i386 ] < none -> 1.16.1.2ubuntu5 > ( perl ) (= 1.16.1.2ubuntu5)
  Considering libdpkg-perl:i386 12 as a solution to dpkg-dev:i386 29
  Holding Back dpkg-dev:i386 rather than change libdpkg-perl:i386

The new version of dpkg requires upgrading dpkg-dev, but it can't because of something wrong with libdpkg-perl. Following the breadcrumb trail back through the log, we find:

Investigating (1) libdpkg-perl [ i386 ] < none -> 1.16.1.2ubuntu5 > ( perl )
Broken libdpkg-perl:i386 Depends on perl [ i386 ] < 5.10.1-8ubuntu2.1 -> 5.14.2-6ubuntu1 > ( perl )
  Considering perl:i386 1472 as a solution to libdpkg-perl:i386 12
  Holding Back libdpkg-perl:i386 rather than change perl:i386

Investigating (1) perl [ i386 ] < 5.10.1-8ubuntu2.1 -> 5.14.2-6ubuntu1 > ( perl )
Broken perl:i386 Depends on perl-base [ i386 ] < 5.10.1-8ubuntu2.1 -> 5.14.2-6ubuntu1 > ( perl ) (= 5.14.2-6ubuntu1)
  Considering perl-base:i386 5806 as a solution to perl:i386 1472
  Removing perl:i386 rather than change perl-base:i386

Investigating (1) perl-base [ i386 ] < 5.10.1-8ubuntu2.1 -> 5.14.2-6ubuntu1 > ( perl )
Broken perl-base:i386 PreDepends on libc6 [ i386 ] < 2.11.1-0ubuntu7.8 -> 2.13-24ubuntu2 > ( libs ) (>= 2.11)
  Considering libc6:i386 -17473 as a solution to perl-base:i386 5806
  Added libc6:i386 to the remove list

Investigating (0) libc6 [ i386 ] < 2.11.1-0ubuntu7.8 -> 2.13-24ubuntu2 > ( libs )
Broken libc6:i386 Depends on libc-bin [ i386 ] < 2.11.1-0ubuntu7.8 -> 2.13-24ubuntu2 > ( libs ) (= 2.11.1-0ubuntu7.8)
  Considering libc-bin:i386 10358 as a solution to libc6:i386 -17473
  Removing libc6:i386 rather than change libc-bin:i386

So ultimately the problem is something to do with libc6; but what? As Steve Langasek said in the bug, libc6's dependencies have been very carefully structured, and surely we would have seen some hint of it elsewhere if they were wrong. At this point ideally I wanted to break out GDB or at the very least experiment a bit with apt-get, but due to some tedious local problems I hadn't been able to restore the apt-clone state file for this bug onto my system so that I could attack it directly. So I fell back on the last refuge of the frustrated debugger and sat and thought about it for a bit. Eventually I noticed something. The numbers after the package names in the third line of each of these log entries are "scores": roughly, the more important a package is, the higher its score should be. The function that calculates these is pkgProblemResolver::MakeScores() in apt-pkg/algorithms.cc. Reading this, I noticed that the various values added up to make each score are almost all provably positive, for example:

         Scores[I->ID] += abs(OldScores[D.ParentPkg()->ID]);

The only exceptions are an initial -1 or -2 points for Priority: optional or Priority: extra packages respectively, or some values that could theoretically be configured to be negative but weren't in this case. OK. So how come libc6 has such a huge negative score of -17473, when one would normally expect it to be an extremely powerful package with a large positive score? Oh. This is computer programming, not mathematics ... and each score is stored in a signed short, so in a sufficiently large upgrade all those bonus points add up to something larger than 32767 and everything goes haywire. Bingo. Make it an int instead - the number of installed packages is going to be on the order of tens of thousands at most, so it's not as though it'll make a substantial difference to the amount of memory used - and chances are everything will be fine. I've filed a patch as Debian bug #657732. I'd expected this to be a pretty challenging pair of bugs. While I certainly haven't lost any respect for the APT maintainers for dealing with this stuff regularly, it wasn't as bad as I thought. I'd expected to have to figure out how to retune some slightly out-of-balance heuristics and not really know whether I'd broken anything else in the process; but in the end both patches were very straightforward.

Apparently HTML5 applications are the best thing after sliced bread. HTML5 is the first platform any mobile vendor supports: iPhone, Android, Windows Phone, BlackBerry, Symbian. All of them. Windows 8 is said to promote HTML5 as the preferred application development solution. I used to look kindly at that. But about a month ago I started to get worried: is HTML5 good for everything? Long-lived applications In military, industrial, warehouse management, medical, etc is not rare that bespoke applications are developed and stay in use for many years (and I really mean many: 10, 20 or even more!) with barely an update. It s not rare that those applications only receive very small updates once very 5 years. Those applications, not Angry Birds, are what keeps the world running: troops know what supplies they can count on, iPhones are manufactured, FedEx is able to deliver your package and your doctor is able to check your health. But now that everybody seems to be moving to HTML5 webapps, what happens when my warehouse management application is a webapp and the additions in the newest browsers make the webapp no longer work? Are vain upgrades the future? Say my webapp is released in 2014 and it works fine with Firefox 14.0 and Chrome 26.0, the newest browsers when I release the application in 2014. Fast-forward to 2020 and Firefox 14.0 and Chrome 26.0 do not even install on Windows 10 computer! What s the solution? Should the customer pay for a huge update and redesign to make it work with Firefox 27.1 and Chrome 41.0 in 2020? A virtual machine with Windows 8 and Firefox 14.0? A portable Mozilla Firefox 14.0 on Windows 10 in 2020 to be able to use that line-of-business application that only requires a small update once or twice every 5 years? How are the virtual machine and/or Portable Firefox 14.0 different from or better than a fat client? What s the advantage? I d say none! Native applications usually do not have that kind of problems because APIs are much more stable. You can still run Win16 applications on Windows 7! You don t believe me? We may soon be developing for 76 browsers! While HTML5 may be fine for applications which are updated very often, it makes me feel very uneasy to see it used in environments where applications will be rarely updated, such as SCADAs, warehouse management, control system, medical records, etc. A solution is needed It looks like that choice of technology is going to make those applications much more expensive in the medium and long term, paying for adaptations to new browsers (sorry, I resist to call update or upgrade to something that adds zero value other than being able to run on a newer browser). Or maybe it s about time to define actual HTML5 profiles . ACID3 seems to be too weak of a profile: two very different browsers may pass ACID3 yet a webapp would work with one browser and fail with the other due to bugs, missing features/added features, etc. Something needs to be done.

If you want to use FreeType in your native C/C++ Android app, you'll need to cross-compile it. The Android system uses FreeType internally but it doesn't expose it to native apps. First, prepare the cross-compiler from the NDK:

/usr/src/android-ndk-r7/build/tools/make-standalone-toolchain.sh \
  --platform=android-9 \
  --install-dir=/usr/src/ndk-standalone-9
PATH=/usr/src/ndk-standalone-9/bin:$PATH

Then use it to cross-compile freetype:

tar xf freetype-2.4.8.tar.bz2
cd freetype-2.4.8/
CFLAGS="-std=gnu99" ./configure --host=arm-linux-androideabi --prefix=/freetype \
  --without-zlib
make
make install DESTDIR=$(pwd)

See this discussion for the --std option. --without-zlib uses the internal copy of zlib inside freetype rather than one independently recompiled for Android. Otherwise you'd get errors such as:

./obj/local/armeabi/libfreetype.a(ftgzip.o): In function  ft_gzip_file_init':
ftgzip.c:(.text+0x3c4): undefined reference to  inflateInit2_'
./obj/local/armeabi/libfreetype.a(ftgzip.o): In function  ft_gzip_file_done':
ftgzip.c:(.text+0x43c): undefined reference to  inflateEnd'
./obj/local/armeabi/libfreetype.a(ftgzip.o): In function  ft_gzip_file_reset':
ftgzip.c:(.text+0x514): undefined reference to  inflateReset'
./obj/local/armeabi/libfreetype.a(ftgzip.o): In function  ft_gzip_file_fill_output':
ftgzip.c:(.text+0x780): undefined reference to  inflate'

Then write an Android.mk file in the new freetype/ directory:

#####
LOCAL_PATH:= $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := freetype
LOCAL_SRC_FILES := lib/libfreetype.a
LOCAL_EXPORT_C_INCLUDES := $(LOCAL_PATH)/include $(LOCAL_PATH)/include/freetype2
include $(PREBUILT_STATIC_LIBRARY)
#####

See docs/STANDALONE-TOOLCHAIN.html and docs/PREBUILTS.html in the NDK for details. The CLEAR_VARS bit is not documented, but is necessary to avoid mixed-up paths; it is used in the native_app_glue NDK module. To use FreeType in your project, edit your Android.mk:

...
LOCAL_STATIC_LIBRARIES := ... freetype
...
$(call import-module,freetype)

You will need to specify the freetype directory location as well, using the NDK_MODULE_PATH variable. For instance, you can copy freetype in your project directory and build using:

    ndk-build NDK_MODULE_PATH=. ...

[Latest version of these instructions can be found at the OpenGL Wikibook]

If you install Debian on a computer with an AMD graphic card (an integrated Radeon HD 6310 in my case), you will only get garbage on your screen. Even without X.Org. This is because these graphic card require a non-free firmware to work, even in 2D with free drivers. So, boot with the kernel option radeon.modeset=0 to get a working console, then install the non-free package linux-firmware-nonfree. After that, do not forget to complain to AMD, because that really sucks hard. At the beginning there were microwave network cards unusable without non-free firmware, then wired network cards, and they are even invading graphic cards!

Review: Effective Java, Second Edition, by Joshua Bloch

Publisher:	Addison-Wesley
Copyright:	2008
Printing:	October 2009
ISBN:	0-321-35668-3
Format:	Trade paperback
Pages:	319

Guy Steele, in the forward to this book, writes:

Programs, unlike spoken sentences and unlike most books and magazines, are likely to be changed over time. It's typically not enough to produce code that operates effectively and is readily understood by other persons; one must also organize the code so that it is easy to modify. There may be ten ways to write code for some task T. Of those ten ways, seven will be awkward, inefficient, or puzzling. Of the other three, which is most likely to be similar to the code needed for the task T in next year's software release?

Teaching this, as well as how to avoid being awkward, inefficient, or puzzling, is the goal of this book. Clearly communicating effective, idiomatic, and maintainable usage to a newcomer to a programming language is one of the hardest types of programming books to write. Books like this are therefore quite scarce. Most introductory texts do try to communicate some degree of basic usage, but they rarely go far beyond the syntax, and when they do that usage is rarely both well-defended and inobvious. Bloch takes the concept quite far indeed, going deep not only into the Java language but also into object-oriented software construction in general. Effective Java is modeled after Effective C++ by Scott Meyers, a book I've not read (due to the lack of need for C++ in my programming life), but which I've heard a great deal about. This means the book is organized into 78 numbered items, each of which provides specific advice and analysis about one area of Java. Examples include item 16, "Favor composition over inheritance," or item 33, "Use EnumMap instead of ordinal indexing." As you can see, they run the gamut from high-level design principles to specific coding techniques. This sort of book demands a lot of the author. Everyone has a coding style, and everyone can make usage recommendations, but the merits or lack thereof of specific recommendations are often only visible with substantial later experience. More than any other type of programming language book, this sort of usage guide must be written by a language expert with years of experience with both good and bad code in the language. This is where Effective Java shines. Joshua Bloch led the design and implementation of significant portions of the Java core libraries at Sun and is currently the chief Java architect at Google, but even without knowing that background, his expertise is obvious. Every item in this book is backed up with specific examples and justification, and Bloch quotes extensively from the Java core library to illustrate both the advantages of the techniques he describes and the problems that result when they're not followed. This is not an introductory book, which is one of the things that makes it so efficient and concise. It's a book aimed at the intermediate or advanced Java programmer and assumes you already know the language and the basic pitfalls. There are only a few items in here that would be obvious to most experienced programmers, and even there Bloch ties them back to specific issues in Java in ways that are illuminating. I would not have expected to learn something new from a chapter on a hoary old problem like avoiding float and double for precise values, but I did: Bloch discusses the available alternatives within Java and their tradeoffs and then makes useful specific recommendations. If, like me, you're an experienced programmer already but relatively new to Java, you still should not read this book first. You need a general introduction to the language and libraries and a few projects under your belt before you can appreciate it. (I personally started with Thinking in Java by Bruce Eckel and it served me well, although on several points of style Bloch disagrees with advice in Eckel's book, and I find Bloch's arguments convincing.) But I think this is one of the best possible choices for your second book on Java, in large part because Bloch will head off bad design and style decisions that you don't realize you're making and catch them before they become entrenched. I'm glad I read it as soon as I knew the language well enough to absorb it, and it's the sort of book that I'm likely to re-read sections of whenever I work on Java code related to those topics. It's not entirely obvious that you should take my advice about this sort of book, since I'm not a Java expert and don't have those years of experience with it. But I've checked the recommendation with other programmers I know who are experts, and I've never heard anything but praise for it. It's also one of the books recommended in Coders at Work, and Bloch is one of the people interviewed there, which carries a lot of weight with me. And, apart from that, any long-time programmer who cares about their craft builds an internal sense of aesthetics around what a well-written program should look like and finds themselves recognizing a similar sense in other people's code, even in languages with which they're not familiar. Bloch's recommendations and analysis feel right; one can immediately see how they improve maintainability and robustness, and some of the techniques he shows are elegant and beautiful. This is not a general programming book. It's specifically focused on the Java language, and much of it deals with specific suggestions on how to use Java's core libraries and language features. If you're not going to be writing code in Java, I can't really recommend it. But one of the things I loved about it is that, while talking about Java, Bloch also talks about object-oriented software construction: techniques for extending foreign libraries one does not control, API design, and the proper use of inheritance, among other topics.. That advice is some of the best object-oriented software design advice I've ever read. There isn't enough of it to recommend the book to people with no interest in Java, but this book has even made my C and Perl code better, and has helped me grasp the tradeoff between inheritance and composition in a deeper way than I ever had before. It's a lovely side bonus. If you're writing Java, read this book. If you're learning Java, don't read it first, but read it second, and more than once, or alongside a project where you can apply the advice. It's dense and efficient in the information that it conveys, which means there's more in a couple pages here than in thirty or forty pages of some of the sprawling introductory programming books. I did read it cover to cover, which is one of the better ways to get a sense of Bloch's more general advice on software construction, but you'll hit information overload and will want to return to it piecemeal to fully absorb it. And do get the second edition. I'm sure the first edition is available cheap used, but the additions of enums and generics to the Java language are hugely important and provide some of the most elegant and graceful techniques in the book. Rating: 9 out of 10

This is a follow-up to my previous post about the way that Debian's library symbols analysis support interacts with C++ libraries, based on further debian-devel discussion. The primary outcome of that discussion was to point me at the pkg-kde-tools utilities for handling maintenance of these files, which solved a bunch of my problems. As before, this was also posted on debian-devel, which is where I expect most of the discussion to be. First of all, for those who haven't explored the pkg-kde-tools infrastructure for this, it looks like the effective process goes something like this:

1. Do a local build of the package and then generate an initial symbols template for that architecture. So, for example, I did:

       fakeroot debian/rules build install
       pkgkde-gensymbols -plibxml-security-c16 -v1.6.1 -Osymbols.i386 \
           -edebian/libxml-security-c16/usr/lib/*/libxml-security-c.so.*.*
       pkgkde-symbolshelper create -o debian/libxml-security-c16.symbols \
           -v 1.6.1 symbols.i386
   

   This generates an initial symbols file that will work for i386.
2. Build and upload this version of the package. Now wait for all the buildds to fail (because they will, on probably nearly every other architecture than your local one).
3. Download all of the build logs and feed them back into pkgkde-symbolshelper so that it can adjust your symbols template for all of the architecture variations. So, for example, I did:

       pkgkde-getbuildlogs
       pkgkde-symbolshelper batchpatch -v 1.6.1 *_unstable_logs/*.build
   

   This will generate rather nice annotated symbols files with appropriate arch lists and using subst tags where appropriately (such as when an argument to a function is a size_t).
4. Modify your package to use pkg-kde-tools during the build, because subst tags are a really nice way to handle a lot of C++ symbol patterns but #533916 against dpkg-dev is wontfix, so you need the pkg-kde-tools replacement for dpkg-gensymbols. I added a dependency on pkg-kde-tools and then added the (undocumented) pkgkde_symbolshelper add-on to my dh --with flag.
5. Build and upload the package again. Now it will hopefully build on all architectures.

This is, as you might expect, a fair bit of work, but it does work, and what comes out the other end is a symbols file that works across the current buildd architectures and detects any mistakes by upstream that change the symbols exported. However, it does have some problems, some obvious, and some more subtle. Here's a list of the issues that I see:

1. It feels like this symbols file is still likely to be fragile. While pkg-kde-tools detects a lot of template instances and marks them optional, I was still seeing a lot of "leaked" symbols from other C++ libraries that my package build-depends on, and which I suspect may also disappear. There's also the problem of optimizers eliminating some things that are inlined; for example, that appears to be the variation that my package sees on arm. And for a substantial C++ library, the symbols file is HUGE. Over 12,000 lines for one of my libraries. It's kind of scary to think of how many fragility landmines are buried under there.
2. By the nature of this process, it's very sensitive to the current supported architectures. I expect any package with a symbols template built this way stands a good chance of FTBFS on a new architecture. For example, my symbols file has a lot of !armel !armhf patterns, which don't appear to be anything unique to arm except that the C++ compiler behaves slightly differently there due to inlining, and those are the only two architectures in the current set with that pattern.
3. The lack of dpkg-gensymbols support for subst is very unfortunate, since it's used by the pkg-kde-tools utilities and it's the Right Thing To Do for symbols that take, for example, size_t as an argument. I would strongly encourage the dpkg maintainers to accept the work in #533916 except maybe for the vt work, since the alternative is to generate regexes that are significantly worse at capturing mistakes (since they're going to accept either int or long, rather than only whatever one corresponds to size_t, for example), or to embed a lot of specific architecture restrictions listing, for instance, all 64-bit architectures and guarantee FTBFS for every new architecture.
4. It's a little hard on the infrastructure, since adding a symbols file requires uploading a package that's guaranteed to fail to build almost everywhere just so that you can get all the build logs to feed into the machinery. I always feel guilty about doing that.
5. It's still not clear that the benefit is worth the amount of effort, since I expect most C++ libraries to require frequent SONAME changes anyway, which means that the long-term binary compatibility angle of symbols is probably futile. Mostly, all of this is to give you a tool to do ABI checking, which will catch some mistakes but not all of them. And I'm guessing it's going to be substantially more work than maintaining symbols for a C library if one actually does it properly and checks every missing symbol and change in new builds.

I'm going to try this for the Shibboleth packages for a while since I want to see what it's like across a new upstream release, but I'm still very much not convinced that this is a useful use of a packager's time.

All of Gammu and Wammu related projects are slowly dying under my hands in past months (maybe I could even say years). The reason for this is lack of motivation and time to work on that properly. Last year I've managed to collect some bugfixes and to fix some bugs myself what lead to releasing Gammu 1.31.0, which seems to be quite good release. But since then, I've again hardly done any work there and my biggest motivation for working on Gammu is that without my involvement the project would be probably completely dead. This is definitely not the best motivation and the outcome can be clearly seen. The project definitely has it's problems (I could name them, but let's avoid making this blog post too long), but there are quite a lot of users using it. Currently most interesting feature seems to be SMS daemon, which is probably superior to what others provide, because this is where Gammu gets most of it's new users. Unfortunately not much of them are active in development, the biggest contribution I can expect there is to fix issues they face. On the other side bug tracker and mailing list are full of reported bugs. Not speaking of feature requests to support new phone models. Some of them should be easy to support like new S40 based Nokia's, but things like Android, iPhone or Windows Mobile would require much more work. Of course the big question is whether somebody needs anything else than SMSD. In modern phones, you anyway have most of the data on "cloud" as well, being it Google, Apple or Microsoft and possibility of doing backups to the computer are not that important as in past. I'm definitely not using Gammu to backup my phone (anyway MeeGo is not supported) and I don't think I will in near future. Simply there are better and easier ways to get my data out of phone than implementing support for Gammu. Anyway if anybody is willing to help Gammu now or in future, I'm definitely willing to help him.

Filed under: English Gammu 6 comments Flattr this!

Josselin Mouette is one the leaders of the pkg-gnome team, he takes sound technical decisions and doesn t fear writing code to work-around upstream issues. He deserves kudos for the work he has put into packaging GNOME over the years. He can also be very sarcastic (sometimes he even enjoys participating to flamewars on debian lists), and there are quite a few topics where we have long agreed to disagree. But this kind of diversity is also what makes Debian a so interesting place Read on to learn more about the pkg-gnome team, its plans for Wheezy, Josselin s opinion on the GNOME 3 switch, and much more. Raphael: Who are you? Josselin: I am a 31 years old Linux systems engineer. I started in life with physics, which I studied at the ENS Lyon. I started a thesis on experimental and numerical models for optoelectronics, but when it became clear that research was not for me, I abandoned it and accepted a job at the CEA, which holds the largest computing center in Europe. Working on these machines has been the most awesome job ever (except for it being near Paris). After that I worked a bit on system monitoring technologies. I am married, currently living in Lyon, and working for EDF (the French historical electricity company) on scientific workstations using Debian. EDF is using Debian on more than a thousand workstations and holds the fastest Debian supercomputer in the world (200 Tflops), which makes it another obvious place for Debian developers. Raphael: How did you start contributing to Debian? Josselin: I discovered Debian in 1999 while studying at the ENS, which is one of the biggest nests of Debian developers while being a small place, it is producing almost one Debian developer per year on average. After wondering for a while what it could be useful for, hacking on a slink snapshot made me think that it was for, well, everything except for gaming. Later, in 2002, when I was working on optoelectronics computing codes, I started to package them for Debian in order to make them easier to install, for us as well as other labs over the world. I started the NM process, and it was going smoothly but also going to take time. However, at that moment, the frozen-bubble game went out and made quite some buzz. Since I knew a guy who knew the game s developer, he asked me to package it. The package found 3 sponsors in a very short time and was fast-tracked into the archive at a speed that was unseen before. After which the NM process was completed very quickly. At that time, I was a heavy WindowMaker user, but I didn t like the direction the project was taking (actually, I wonder if there was one). GNOME was starting to become attractive, but its packaging in Debian was very ineffective, with many inconsistent packages maintained by people who didn t ever talk to each other some of them didn t speak English, and some of them didn t talk at all. Together with awesome people, among which Jordi Mallach, Gustavo Noronha Silva, JHM Dassen, Ross Burton and S bastien Bacher, we started the GNOME team in 2003, introducing consistent packaging practices, and initiating synchronized uploads. Releasing a completely integrated GNOME 2.8 in sarge was a considerable achievement; proving (together with the Perl team) that a team was the best way to maintain large package sets changed the way people work on Debian.

Proving [ ] that a team was the best way to maintain large package sets changed the way people work on Debian.

Raphael: You re one of the most active contributors of the team which is packaging GNOME for Debian. What would you suggest to a new contributor who would like to help the team? Josselin: There are several ways to contact the team, but the recommended one has always been IRC. We hang on #debian-gnome on the OFTC network, so just come around and ask for us. The real question is what you want to do in the team. Of course, most new volunteers want to help packaging the latest and greatest version of GNOME into unstable as soon as possible, but unless they already have Debian background, this is not the easiest task. Since there are already people working on this, the big packages are usually waiting on dependencies. I used to direct newcomers towards bug triage, but it is a tedious task and I m now convinced that our huge bug backlog will never be dealt with. The most useful thing to do for newcomers now is probably to find a GNOME or GNOME-related package that needs improvement or is lagging behind, and simply try to work on it. You can also come and fix the bugs you find annoying. Find a patch on the GNOME bugzilla, or cook it yourself, propose it, and if it s worthy enough you ll soon get commit access.

Our huge bug backlog will never be dealt with.

At this point I feel worth mentioning that if no one answers in 10 minutes, it doesn t mean that no one will answer in 2 hours, so please stay on the channel after asking. Raphael: There s been some controversy about GNOME 3 and the direction that the project is taking. What s your personal stance on GNOME 3? And what s the position of the pkg-gnome team? Josselin: The controversy is not new to GNOME 3, but the large-scale changes made with it have put it more prominently. The criticism usually boils down to a few categories:

1. General lack of configurability
2. Strange design decisions
3. Red Hat centric development
4. Hardware requirements
5. Change resistance

The lack of configuration options has been an ongoing criticism since GNOME 2.0 has decided to rip off most of them. Of course, when the control center was redesigned again for 3.0, there was a surge of horrified exclamations from people who missed their favorite buttons. On this topic, I fully concur with GNOME developers. The configuration option that is useful for you is not necessarily useful for someone else. Of course, sometimes developers go a bit too far, but the general direction is right. At work, we found that only a minority of users actually configure anything on their desktops: they just want something that works to launch their applications. Apple and Google have sold millions of devices by making them the simplest possible and without any configuration. Design decisions are, on the contrary, individual decisions, and each of them, while having reasons behind it, can be questioned. I remember seeing a lot of complaints when the OK and Cancel buttons were reversed in dialog boxes, something that nobody questions anymore. GNOME Shell is full of such changes; some are easy to get accustomed with, some others just make eyebrows raise. The most obvious example is the user menu in GNOME 3.2, which contains an entry to configure your Google account, but no entry to shutdown the computer. Both decisions were taken independently, each of them with (good or bad) reasons, but the result is simply ridiculous. The default configuration in Debian will contain an extension to make it a bit better, but on the whole we don t intend to diverge from the upstream design, on which a lot of good work has been done.

On the whole we don t intend to diverge from the upstream design, on which a lot of good work has been done.

Point 3 is more complex. Red Hat being the company spending the most on GNOME, it is obvious that their employees work on making things work for their distribution. An example is the recurring discussions about relying on system services that are currently only implemented by systemd. Since there is a lot of (mostly unjustified) resistance against systemd in Debian, and since it won t work on kFreeBSD anyway, someone needs to develop an alternative implementation of these services for upstart and sysvinit. Everything is in place for someone else to do the job but it has to be done, and this can be frustrating. Especially since it can also be hard to integrate changes needed for other distributions . Hardware requirements are mostly a consequence of the previous criticism: there s hardware that most distributions just don t want to bother supporting. We ve seen it in squeeze with the introduction of a hard dependency on PulseAudio. The Debian GNOME team (together with the Gentoo maintainers) made this dependency optional, carrying heavy patches, in order to cover the cases where it does not work. Now that it has gained more maturity, making this effort obsolete, the new tendency is to require 3D acceleration. For various reasons, it is not available to everyone . On this matter, the position of the Debian GNOME team has always been to support as much different configurations as possible with reasonable effort. Thanks to efforts from the incredible Vincent Untz, upstream supports a so-called fallback mode , which is the GNOME panel from 2.x with a lot of its bugs fixed. We intend to support this mode for as long as reasonably possible in Debian, possibly even after upstream ends up dropping it. However, other applications are going to require 3D because GStreamer is moving to clutter too, affecting video playback performance on non-accelerated systems . For epiphany this is not a problem; only embedded video will be affected. But for totem, this is a major issue; because of that we will probably keep totem 3.0 in wheezy. Finally, there is a natural human tendency to dislike change (I have it too), and it applies a lot to desktop users habits. Needless to say a change of such a scale as introducing GNOME Shell can trigger reactions. However, I don t think it is reasonable, because of this resistance, to keep gnome-panel 2.x in Debian. This would be a lot of work on obsolete technology, and would prevent the upcoming removal of a lot of deprecated libraries. This time is much better spent improving gnome-panel 3.x in Debian and keeping the fallback mode great. One of the change that was made in Debian was to make it easier to find, being available as GNOME Classic directly from the login manager, instead of having to find it in an obscure configuration panel. In all cases, I would recommend to actually try GNOME Shell for a few hours before ditching it. I had never been accustomed to a new environment as quickly ever before.

In all cases, I would recommend to actually try GNOME Shell for a few hours before ditching it.

Having seen several of my GDM patches reverted without a warning, I know we are not finished with carrying patches in Debian packages.
Scientific workstations are a non-trivial example, since there is a measurable effect of using 3D in the window manager on heavy 3D applications.
On the other hand, on accelerated systems, this feature should end up improving performance a lot. Raphael: What are your plans for Debian Wheezy? Josselin: The first goal of the GNOME team is, of course, to provide again a great desktop environment to work on. For wheezy it will probably be based on GNOME 3.4. There also needs to be some work on package management interfaces. Upstream bases everything on PackageKit, but it is not as featureful as the aptdaemon Ubuntu technology. If I have time, I would also like to improve HTTP proxy support, since currently it is based on a stack of terrible hacks. Raphael: If you could spend all your time on Debian, what would you work on? Josselin: Obviously I would like to make GNOME in Debian even better. That would imply working on underneath dependencies (what we now like to call plumbing) to make sure everything is working great. This would also imply working more as GNOME upstream to make it more suitable for our needs. I would also work on large-scale improvements on the distribution, like conditional recommends which I d love to see implemented , or automatic build-dependency generation. I would also work on the installer to make it better for desktops machines. The idea is to automatically install language packs, or glues between two packages when both packages are installed. Raphael: What s the biggest problem of Debian? Josselin: The obvious answer is the same as the one most people you interviewed before gave: not enough members in core teams. A lot of developers join Debian to work on a small number of pet packages, and don t necessarily want to be involved with existing teams. It is probably still not obvious enough that the primary way to start contributing to Debian is to join an existing team. But if there is one thing that is preventing Debian from gaining more momentum now, it is a completely different one: the too short support timeframe. 3 years is really not enough for corporate users. One year to migrate from one version to another is too short, and it is not possible to skip a release. It is definitely possible to change that with reasonable effort: the long-term support after 3 years doesn t have to cover the same perimeter as the short-term one. For example, we could upgrade the kernel to the version in the current stable release, and stop fixing all non-remote security holes. The important thing is to cover the most basic needs: companies are ready to take the risk of having less support if it allows skipping a version, but not the risk of having no support at all. And even more important is to say that you do something. Red Hat says they support a release for 10 years, but of course after 5 years the supported perimeter is extremely small.

3 years [of support] is really not enough for corporate users.

Long-term support will not magically fix all problems in Debian, but it will bring more corporate users into the picture. And with corporate users come paid Debian developers, who can work on critical pieces of the system. Debian was built on the synergy between individuals and companies, and in recent years perhaps as a reaction against what happened with Ubuntu we ve kind of forgot the latter. A lot of individuals have joined the project, and they are actively working, for example, on shortening the release cycle, which goes against the interest of professionals. We should embrace again such users and developers, and that means adapting to the current needs of larger entities. Raphael: You re the maintainer of python-support, a packaging helper that was competing with python-central. Both helpers are now deprecated in favor of dh_python2. Does this mean that the situation of Python in Debian is now sane? Or are there remaining problems? Josselin: dh_python2 (and the Python3 version, dh_python3) has a sane enough design. It fixes a lot of issues in python-central and also python-support, at the expense of somehow reduced functionality for developers. However, just like the previous tools, it merely works around design mistakes in the Python interpreter. For example it is not possible to split binary modules, pure-Python modules and byte-compiled modules in different directory trees, like Perl does although PEP 3147 introduces a way to do so. There is still no sane and standardized way to deal with module versions. There is no difference made between the module (which is a part of language semantics) and the file containing it (an information which depends on the implementation). Developers heavily rely on introspection features and make assumptions based on the implementation, that make it impossible to work around problems with module files. Such problems are not restricted to Python. Those who fought against Ruby gems could tell even worse stories. While introducing GObject introspection packages in Debian (they can be used in JavaScript and Python to provide modules based on GObject libraries), I was pleased to see a clear distinction between file and module, but I was again struck by the fact you are not forced to declare API versions in your Python/JS code. In all cases, there is no reliable way to detect runtime dependencies in a given Python or JavaScript file, which leaves the maintainer to declare them by hand, and of course, often be wrong about them. Add to that the fact that most errors cannot be detected before runtime. For all these reasons, and while still being fond of Python for scripts and prototyping, I ve become really skeptical of using purely interpreted languages to write real applications. Some GNOME developers are moving away from Python and JavaScript, mostly towards Vala; I can only approve of that move and hope the same happens to other projects. Raphael: Is there someone in Debian that you admire for their contributions? Of course there is the never-sleeping, never-stopping, Michael Biebl who can upload a whole GNOME release in a single week-end. But there are a lot of awesome people who make Debian something that simply works. I could talk about Cyril Brulebois from the X strike force, Julien Cristau from the release team, Sjoerd Simons for his sound advice and work on plumbing, Luca Falavigna who is so fast at processing NEW, to quote only a few of those I work with frequently. And of course, Jordi and Sam for their humor.

---

Thank you to Josselin for the time spent answering my questions. I hope you enjoyed reading his answers as I did. Note that you can find older interviews on http://wiki.debian.org/PeopleBehindDebian.

Subscribe to my newsletter to get my monthly summary of the Debian/Ubuntu news and to not miss further interviews. You can also follow along on Identi.ca, Google+, Twitter and Facebook .

8 comments Liked this article? Click here. My blog is Flattr-enabled.

As a Linux integration guy at Zend, most of my time is spent in compiling PHP related code or dealing with the variety of Linux distributions we support. With the coming release for PHP 5.4, we (at Zend) had some interesting stuff going on. As part of the RC phase, I got to check the status of the 50-60 PHP extensions we provide, especially the PECL extensions which have different release cycles than the main PHP. With minor versions, this usually doesn t really matter, but for major versions this means that some extensions need a little bit of love and fixes to work well with the new PHP version. This of course with the help of our developers. The changes are usually one-liners due to a variable type change, or finding commits in the extension s SCM and applying/back-porting it to the current versions (e.g. pecl memcache). Our policy regarding the patches we have, is that they should at least be sent to upstream (a core member or a bug report, e.g. #55703). I think I m in the best position to enforce that patch policy, so in a few recent cases, I found myself asking one of our developers if the patch he sent me was already accepted upstream before willing to take it into the build process (in this case they are used temporarily, till we ll work with the next RC or final release).
Filed under: PHP

I was doing some finite element (FE) calculation and I needed the sum of the lowest 7 eigenvalues of a symmetric matrix (that comes from the FE assembly) to converge to at least 1e-8 accuracy (so that I can check calculation done by some other solver of mine, that calculates the same but doesn't use FE). In reality I wanted the rounded value to 8 decimal digits to be correct, so I really needed 1e-9 accuracy (but it's ok if it is let's say 2e-9, but not ok if it is 9e-9). With my FE solver, I couldn't get it to converge more than to roughly 5e-7 no matter how hard I tried. Now what?

When doing the convergence, I take a good mesh and keep increasing "p" (the polynomial order) until it converges. For my particular problem, it is fully converged for about p=25 (the solver supports the order up to 64). Increasing "p" further will not increase the accuracy anymore, and the accuracy stays at the level 5e-7 for the sum of the lowest 7 eigenvalues. For optimal meshes, it converges at p=25, for not optimal meshes, it converges for higher "p", but in all cases, it doesn't get below 5e-7.

I know from experience, that for simpler problems, the FE solver can easily converge to 1e-10 or more using double precision. So I know it is doable, now the question is what the problem is: there
are a few possible reasons:

• The FE quadrature is not accurate enough
• The condition number of the matrix is high, thus LAPACK doesn't return very accurate eigenvalues
• Bug in the assembly/solver (like single/double corruption in Fortran, or some other subtle bug)

When using the same solver for simpler potential, it converged nicely to 1e-10. So this suggests there is no bug in the assembly or solver itself. It is possible that the quadrature is not accurate enough, but again, if it converges for simple problem, it's probably not it. So it seems it is the ill conditioned matrix, that causes this. So I printed the residuals (that I simply calculated in Fortran using the matrix and the eigenvectors returned by LAPACK), and it only showed 1e-9. For simpler problems, it can go to 1e-14 easily. So that must be it. How do we fix it?

Obviously by making the matrix less ill conditioned, which is caused by the mesh for the problem (the ratio of the longest/shortest elements is 1e9) but for my problem I really needed such a mesh. So the other option is to increase the real number accuracy.

In Fortran all real variables are defined as real(dp), where dp is an integer defined at a single place in the project. There are several ways to define it, but it's value is 8 for gfortran and it means double precision.So I increased it to 16 (quadruple precision), recompiled. Now the whole program calculates in quadruple precision (more than 30 significant digits). I had to recompile LAPACK using the "-fdefault-real-8" gfortran option, that promotes all double precision numbers to quadruple precision, and I used the "d" versions (double precision, now promoted to quadruple) of LAPACK routines.

I rerun the calculation ---- and suddenly LAPACK residuals are around 1e-13, and the solver converges to 1e-10 easily (for the sum of the lowest 7 eigenvalues). Problem solved.

Turning my Fortran program to quadruple precision is as easy as changing one variable and recompiling. Turning LAPACK to quadruple precision is easy with a single gfortran flag (LAPACK uses the old f77 syntax for double precision, if it used real(dp), then I would simply change it as for my program). The whole calculation got at least 10x slower with quadruple. The reason is that gfortran runtime uses the libquadmath library, that simulates quadruple precision (as current CPUs only support double precision natively).

I actually discovered a few bugs in my program (typically some constants in older code didn't use the "dp" syntax, but had the double precision hardwired). Fortran warns about all such cases, when the real variables have incompatible precision.

It is amazing how easy it is to work with different precision in Fortran (literally just one change and recompile). How could this be done with C++? This wikipedia page suggests, that "long double" is only 80bit in most cases (quadruple is 128bit), but gcc offers __float128, so it seems I would have to manually change all "double" to "__float128" in the whole C++ program (this could be done with a single "sed" command).

I was just about to start writing own viewer for StarDict dictionaries for Harmattan, when I noticed that somebody already took the effort and the application is available. It's called DictionaryStar and it's developed on gitorious. With the hard part done, I've adjusted packaging of various dictionaries I've made available for StarDict so that it works fine on Harmattan. For now only English-Czech one is completed, you hopefully be able to get it soon at Nokia store. The reason I've started with only one is that this pretty much does not fit into content guidelines for Nokia store and I expect problems when this will be passing their QA. So I've decided to push only one for now and once I get it through, adding others will be easy.

Filed under: English Meego Stardict 0 comments Flattr this!

I never got the craze for the zombie this and zombie that. I saw the premise as thinner than vampire storyline which in my book only had a good day with Buffy franchise. But then I got Kindle and run out of stuff to read and decided to pick up something less lively and more shambling. And you know what I found there are a few great books hiding behind the zombie label. I read them in the worng order, so to help you guys out, here is the way I would recommend to check out if the zombie genre is interesting to you: Start with World War Z: An Oral History of the Zombie War. It is written as a historical book documenting the memories of people that have survived the world wide zombie apocalipse is a series of escalating short stories. This is a perfect bathroom or bus reading. Each story focuses on how people react (or fail to react) to a radical change in their environment. Zombies are a tool to expose the human condition for this book. The next you could read (or you could even skip this if it get a bit boring for you) is The Zombie Survival Guide: Complete Protection from the Living Dead this is a problem solving book, it basically takes a problem ( ZOMBIES! ) a goal ( I want to survive! ) and describes the logical steps needed to reach the goal in the context of the problem. It is very educational on the issue of problem solving, especially with unusual problems. But it can get boring for people if so, don t give up, but just skip this book for now and move on the the best of them all The third is a trilogy, two books are already published, the third is coming soon first books is Feed (Newsflesh, Book 1) and the second is Deadline (Newsflesh, Book 2). This is a rare gem of modern literature. Basically this is a book set in the world long time after a zombie outbreak (with a good reason why and how it happened) where people have already lived a few decades with the problema and the kids are very used to it. So the book is written from a perspective of a young woman and her brother, who were born after Rising and are now into one of the most dangerous profession journalism. Early on they become the first bloggers to be picked to follow a presidential election campagn (book was written before Obama campaign really took off) and it only get wilder from there. I really liked these books. So much so, that I will now explore the other zombie fiction books to see if there possibly is something good there as well. Any recommendations?

I recently came across the pylint error: in code that boiled down to essentially: Unfortunately that message isn't particularly helpful in figuring out what's going on. I still can't claim to be 100% sure what the message is intended to convey, but I can construct something that maybe it's talking about. Consider the following using the above class which gives output of: Now, if you read just about any Python tutorial, it will say something along the lines of:

... the special thing about methods is that the object is passed as the first argument of the function. In our example, the call x.f() is exactly equivalent to MyClass.f(x). In general, calling a method with a list of n arguments is equivalent to calling the corresponding function with an argument list that is created by inserting the method s object before the first argument. [Official Python Tutorial]

The official tutorial above is careful to say in general; others often don't. The important point to remember is how python internally resolves attribute references as described by the data model. The moo.foo() call is really moo.__dict__["foo"](moo); examining the __dict__ for the moo object we can see that foo has been re-assigned: Our Foo.foo(moo) call is really Foo.__dict__["foo"](moo) -- the fact that we reassigned foo in moo is never noticed. If we were to do something like Foo.foo = Foo.foo_override we would modify the class __dict__, but that doesn't give us the original semantics. So I postulate that the main point of this warning is to suggest to you that you're creating an instance that now behaves differently to its class. Because the symmetry of calling an instance and calling a class is well understood you might end up getting some strange behaviour, especially if you start with heavy-duty introspection of classes. Thinking about various hacks and ways to re-write this construct is kind of interesting. I think I might have found a hook for a decent interview question :)

Note to self: when configuring awstats using lighttpd logfiles, you have to use the following log format: LogFormat="%host %virtualname %logname %time1 %methodurl %code %bytesd %refererquot %uaquot" neighter 1 nor 4 will work correctly.

I also posted this to debian-devel, which is where the discussion will be, but I wanted to post it on my journal as well so that others who may be interested will see it on Planet Debian. For those not familiar with Debian, this concerns the implications of a new feature for how Debian tracks shared library dependencies. I'm currently working on the Policy modification to document (and recommend) use of symbols instead of shlibs, but I'd only personally used symbols with C libraries. Today I decided that I should try adding a symbols file to a C++ library, particularly if I'm going to recommend everyone do it. I tried this exercise with xml-security-c, which is, I think, a reasonably typical C++ library. Not the sort of core C++ library that would sit at the center of the distribution, but a random software package that's in Debian because other things use it. The experience was rather interesting, and I ended up uploading the new version without a symbols file and continuing to just use shlibs. That's for the following reasons:

1. The generated symbols file was HUGE. Hundreds of lines. This is a marked difference from the typical C symbols file, which is of quite manageable size. Some of that is that the library provides a lot of different classes, but some of it is that C++ just generates a lot of exported symbols. There's no way that I could do what I would do with a C library and understand those symbols, why they're there, and whether they are likely to have changed between revisions.
2. Generating a reasonable symbols file was a pain. Generating an unreasonable symbols file that just contains all of the mangled symbols is largely mechanical and uninteresting, but that symbols file doesn't seem to me to convey useful information. So I did some scripting to translate the symbols back with c++filt, and add (c++) tags, and then try to understand what I was looking at and figure out whether I should sort the symbols list because the default sort is by mangled name, which is meaningless. This is a rather unappealing process. It's not particularly difficult, but it's very awkward and feels like it's missing vital tools.
3. The resulting symbols file is incomprehensible to someone without strong knowledge of C++. It's full of opaque entries that don't make sense to the non-C++ programmer, which I suspect is a substantial number of people who package C++ libraries for Debian. I know enough C++ from school that I can evaluate security fixes, make simple patches, and review upstream changes, and I think that's all that should be needed to package things for Debian. But I'm deeply uncomfortable producing a symbols file on my own that contains entries for things that I know nothing about and cannot evaluate when they've last changed, like "non-virtual thunk to FooClass::~FooClass@Base".
4. Once I had a symbols file that resulted in a successful build and that I could have uploaded, I started thinking about how I was going to maintain it. With a C program, I would change the symbols file versions when the underlying function implementation changes in a way that may not offer eqiuvalence, similar to bumping shlibs. I realized that I was going to have no idea when that happened, and the only way that I would maintain the symbols file would be to either trust upstream to maintain ABI equivalence and therefore only change the symbols file when upstream changes the SONAME, or not trust upstream to maintain ABI equivalence and therefore change all the versions with each new upstream release. That gives me exactly the same semantics as a shlibs file, so what's the point in having a symbols file?
5. The exported symbols of the library contained many symbols that obviously weren't really from that library, but instead were artifacts of the C++ compilation process, things like instantiations of std::vector. Do those go into the symbols file? Do they change from architecture to architecture? If they disappear again, is that actually an ABI break? How do I know? It's all very mysterious, and while shlibs provides the same semantics as just ignoring this, at least I'm not then including in the package data, generated by me, things that I'm just blindly ignoring.

I came away from this experience thinking that I should revise the Policy amendment to say that symbols files are really for C libraries and for C++ libraries with either a tightly maintained symbol export list or maintained by a C++ expert, and that most C++ library maintainers should just not bother with this and use shlibs, bumping the shlibs version or not based on their impression of how good upstream is at maintaining ABI equivalence. But that feels like a result contrary to what I had previously thought was the intended direction, so I wanted to ask the Debian development community as a whole: am I missing something? Are these symbols files actually useful? Am I missing some trick to make them useful?

Cops in Tennessee routinely steal cash from citizens [1]. They are ordered to do so and in some cases their salary is paid from the cash that they take. So they have a good reason to imagine that any large sum of money is drug money and take it. David Frum wrote an insightful article for NY Mag about the problems with the US Republican Party [2]. TreeHugger.com has an interesting article about eco-friendly features on some modern cruise ships [3]. Dan Walsh describes how to get the RSA SecureID PAM module working on a SE Linux system [4]. It s interesting that RSA was telling everyone to turn off SE Linux and shipping a program that was falsely marked as needing an executable stack and which uses netstat instead of /dev/urandom for entropy. Really the only way RSA could do worse could be to fall victim to an Advanced Persistent Attack :-# The Long Now has an interesting summary of a presentation about archive.org [5]. I never realised the range of things that archive.org stores, I will have to explore that if I find some spare time! Jonah Lehrer wrote a detailed and informative article about the way that American high school students receive head injuries playing football[6]. He suggests that it might eventually be the end of the game as we know it. Fran ois Marier wrote an informative article about optimising PNG files [7], optipng is apparently the best option at the moment but it doesn t do everything you might want. Helen Keeble wrote an interesting review of Twilight [8]. The most noteworthy thing about it IMHO is that she tries to understand teenage girls who like the books and movies. Trying to understand young people is quite rare. Jon Masters wrote a critique of the concept of citizen journalism and described how he has two subscriptions to the NYT as a way of donating to support quality journalism [9]. The only comment on his post indicates a desire for biased news (such as Fox) which shows the reason why most US media is failing at journalism. Luis von Ahn gave an interesting TED talk about crowd-sourced translation [10]. He starts by describing CAPTCHAs and the way that his company ReCAPTCHA provides the CAPTCHA service while also using people s time to digitise books. Then he describes his online translation service and language education system DuoLingo which allows people to learn a second language for free while translating text between languages [11]. One of the benefits of this is that people don t have to pay to learn a new language and thus poor people can learn other languages great for people in developing countries that want to learn first-world languages! DuoLingo is in a beta phase at the moment but they are taking some volunteers. Cory Doctorow wrote an insightful article for the Publishers Weekly titles Copyrights vs Human Rights [12] which is primarily about SOPA. Naomi Wolf wrote an insightful article for The Guardian about the Occupy movement, among other things the highest levels of the US government are using the DHS as part of the crackdown [13]. Naomi s claim is that the right-wing and government attacks on the Occupy movement are due to the fact that they want to reform the political process and prevent corruption. John Bohannon gave an interesting and entertaining TED talk about using dance as part of a presentation [14]. He gave an example of using dancerts to illustrate some concepts related to physics and then spoke about the waste of PowerPoint. Joe Sabia gave an amusing and inspiring TED talk about the technology of storytelling [15]. He gave the presentation with live actions on his iPad to match his words, a difficult task to perform successfully. Thomas Koch wrote an informative post about some of the issues related to binary distribution of software [16]. I think the problem is evenm worse than Thomas describes.

• [1] http://www.youtube.com/watch?v=Xg4ArbQpsIU
• [2] http://nymag.com/print/?/news/politics/conservatives-david-frum-2011-11/
• [3] http://www.treehugger.com/natural-sciences/7-ocean-friendly-eco-cruises-hitting-the-high-seas.html
• [4] http://danwalsh.livejournal.com/48571.html
• [5] http://longnow.org/seminars/02011/nov/30/universal-access-all-knowledge/
• [6] http://www.grantland.com/story/_/id/7443714/jonah-lehrer-concussions-adolescents-future-football
• [7] http://feeding.cloud.geek.nz/2011/12/optimising-png-files.html
• [8] http://www.helenkeeble.com/2011/08/08/repost-what-i-thought-about-twilight
• [9] http://www.jonmasters.org/blog/2011/11/30/on-citizen-journalism/
• [10] http://www.ted.com/talks/luis_von_ahn_massive_scale_online_collaboration.html
• [11] http://duolingo.com/
• [12] http://www.publishersweekly.com/pw/print/20111205/49728-cory-doctorow-copyrights-vs-human-rights.html
• [13] http://www.guardian.co.uk/commentisfree/cifamerica/2011/nov/25/shocking-truth-about-crackdown-occupy
• [14] http://www.ted.com/talks/john_bohannon_dance_vs_powerpoint_a_modest_proposal.html
• [15] http://www.ted.com/talks/joe_sabia_the_technology_of_storytelling.html
• [16] http://www.koch.ro/blog/index.php?/archives/153-On-distributing-binaries.html

Related posts:

1. Links January 2011 Halla Tomasdottir gave an interesting TED talk about her financial...
2. Links January 2010 Magnus Larsson gave an interesting TED talk about using bacteria...
3. Links January 2009 Jennifer 8 Lee gave an interesting TED talk about the...

The next version of Debian Edu / Skolelinux will include a new tool sitesummary2ldapdhcp, which can be used to quickly set up all the computers in a school without much manual labour. Here is a short summary on how to use it to set up a new school. First, install a combined Main Server and Thin Client Server as the central server in the network. Next, PXE boot all the client machines as thin clients and wait 5 minutes after the last client booted to allow the clients to report their existence to the central server. When this is done, log on to the central server and run sitesummary2ldapdhcp -a in the konsole to use the collected information to generate system objects in LDAP. The output will look similar to this:

% sitesummary2ldapdhcp -a
info: Updating machine tjener.intern [10.0.2.2] id ether-00:01:02:03:04:05.
info: Create GOsa machine for auto-mac-00-01-02-03-04-06 [10.0.16.20] id ether-00:01:02:03:04:06.
Enter password if you want to activate these changes, and ^c to abort.
Connecting to LDAP as cn=admin,ou=ldap-access,dc=skole,dc=skolelinux,dc=no
enter password: *******
% 

After providing the LDAP administrative password (the same as the root password set during installation), the LDAP database will be populated with system objects for each PXE booted machine with automatically generated names. The final step to set up the school is then to log into GOsa, the web based user, group and system administration system to change system names, add systems to the correct host groups and finally enable DHCP and DNS for the systems. All clients that should be used as diskless workstations should be added to the workstation-hosts group. After this is done, all computers can be booted again via PXE and get their assigned names and group based configuration automatically. We plan to release beta3 with the updated version of this feature enabled this weekend. You might want to give it a try. Update 2012-01-28: When calling sitesummary2ldapdhcp to add new hosts, one need to add the option -a. I forgot to mention this in my original text, and have added it to the text now.

Since my last SE Linux in Debian status report [1] there have been some significant changes. Policy Last year I reported that the policy wasn t very usable, on the 18th of January I uploaded version 2:2.20110726-2 of the policy packages that fixes many bugs. The policy should now be usable by most people for desktop operations and as a server. Part of the delay was that I wanted to include support for systemd, but as my work on systemd proceeded slowly and others didn t contribute policy I could use I gave up and just released it. Systemd is still a priority for me and I plan to use it on all my systems when Wheezy is released. Kernel Some time between Debian kernel 3.0.0-2 and 3.1.0-1 support for an upstream change to the security module configuration was incorporated. Instead of using selinux=1 on the kernel command line to enable SE Linux support the kernel option is security=selinux. This change allows people to boot with security=tomoyo or security=apparmor if they wish. No support for Smack though. As the kernel silently ignores command line parameters that it doesn t understand so there is no harm in having both selinux=1 and security=selinux on both older and newer kernels. So version 0.5.0 of selinux-basics now adds both kernel command-line options to GRUB configuration when selinux-activate is run. Also when the package is upgraded it will search for selinux=1 in the GRUB configuration and if it s there it will add security=selinux. This will give users the functionality that they expect, systems which have SE Linux activated will keep running SE Linux after a kernel upgrade or downgrade! Prior to updating selinux-basics systems running Debian/Unstable won t work with SE Linux. As an aside the postinst file for selinux-basics was last changed in 2006 (thanks Erich Schubert). This package is part of the new design of SE Linux in Debian and some bits of it haven t needed to be changed for 6 years! SE Linux isn t a new thing, it s been in production for a long time. Audit While the audit daemon isn t strictly a part of SE Linux (each can be used without the other) it seems that most of the time they are used together (in Debian at least). I have prepared a NMU of the new upstream version of audit and uploaded it to delayed/7. I want to get everything related to SE Linux up to date or at least with comparable versions to Fedora. Also I sent some of the Debian patches for the auditd upstream which should reduce the maintenance effort in future. Libraries There have been some NMUs of libraries that are part of SE Linux. Due to a combination of having confidence in the people doing the NMUs and not having much spare time I have let them go through without review. I m sure that I will notice soon enough if they don t work, my test systems exercise enough SE Linux functionality that it would be difficult to break things without me noticing. Play Machine I am now preparing a new SE Linux Play Machine running Debian/Unstable. I wore my Play Machine shirt at LCA so I ve got to get one going again soon. This is a good exercise of the strict features of SE Linux policy, I ve found some bugs which need to be fixed. Running Play Machines really helps improve the overall quality of SE Linux.

• [1] http://etbe.coker.com.au/2011/10/31/selinux-status-2011-10/

Related posts:

1. Status of SE Linux in Debian LCA 2009 This morning I gave a talk at the Security mini-conf...
2. SE Linux in Debian I have now got a Debian Xen domU running the...
3. Debian SE Linux Status At the moment I ve got more time to work on...

It looks like with start of the new year, people started to ask for phpMyAdmin's projects for GSoC 2012. Given that we have no information whether there will be Google Summer of Code this year and whether we will be chosen to participate, these questions look quite premature. On the other side you can start contributing any time and if you are already known in the community, you might have better chance being accepted. So forget speaking about hypothetical GSoC projects for now and start fixing some bugs, which is something much more needed right now (given that 3.5 is in alpha state). If you are looking for more information, we have basic facts for developers on our website, there is also a wiki page mentioning some tasks for junior developers.

Filed under: English Phpmyadmin 0 comments Flattr this!

It is since two days that all my emails, @debian.org included, are in parked somewhere between the sender and my MX, as my server broke at a moment where I strictly had no time (dealine for a grant application). It is an OpenRD Ultimate with a second hand SSD. I was quite happy to have an ARM system available to test some packages like T-COFFEE, but it looks like I will have to do without. Apparently, the machine permanently reboots. I did not manage to access to the USB serial port; there are no 10 seconds where the USB port is not disconnected / reconnected. Both ethernet port LEDs blink together synchronously with the disconnections. Removing the drive did not solve the problem. The SSD itself is fine, and I did not find in the logs hints for software problems. Strange coincidence, the last log file that was modified is daemon.log, which indicates the connection of so-called megumi-PC to our unprotected, but to my knowledge never visited, wireless network. After this, nothing.