I finally got around to book my (train) trip back from Zagreb. The hotline of Deutsche Bahn was interesting. The booking system crashed and I was called back. But in the end it worked and I can print it the next time I get near a vending machine.

I'm worried how I manage to get there from Banja Luka on my own. And the travel to Zagreb together with Joachim Breitner won't be as comfortable as it should be. But meh, I'm going to DebConf again! \o/

So I got my hands on that new machine, somewhere, somehow, and I had to make myself comfortable on it. The biggest difference in that machine and the ones I used before is the RAID controller, an Adaptec 5405, instead of the 3ware ones I used to have before. That means getting used to new tools, messages and all these things which I ll try to document here.Step 1: does vendor deliver?Well, yes, mostly. There is (mainline) kernel support for the controller, Squeeze s kernel will boot up just fine and I just throw my junk into /dev/sda and it will handle the whole raidy thingy itself. But what is when I want to check the health of the disks, to add a spare or modify the caching? Ask the mighty vendor and it will answer Yes, you can! .So I downloaded that asm_debian_x86_x64_v6_50_18570.tgz, unpacked and faced two debs, one i368 and one amd64. Yes, you could have saved half of the bandwidth if someone would have asked for the arch before, but who cares for some additional 60MiB today? So let s see what it does. Oh no, wait, there is a README ASM_IUG_for_Debian_and_Ubuntu.txt:

1. Make sure to be in root level access.
2. Install the ASM storman .deb package. For example, if the package is storman_6.50-18570_i386.deb,
   then install it using the following command dpkg -i storman_6.50-18570_i386.deb
3. Adaptec Storage Manager will get installed at /usr/StorMan
4. Add the line /usr/StorMan to /etc/ld.so.conf. Then run "ldconfig". This is needed for the arcconf
   utility to find the path of the libstdc++.so.5 library

Well, 1 is obvious, so is 2.
For 3: hum, /usr/StorMan? Ever heard of FHS? Don t think so.
For 4: WTF?! I prefer to get libstdc++5 from my local Debian mirror instead.But at least they provide a .deb, right? Uhm, no, it s an RPM converted via alien :( And don t dare to look at preinst, postinst and postrm (it extracts an own copy of Sun JRE 1.6u16, chmods around wildly on install and does rm -rf something on uninstall, did I see that some days ago on the webs?). Let s get rid of that package as soon as possible, I decided, and just keep arcconf (which will be described later), esp because StorMan itself seems to include some call-home functionality which I d like not to have:

cp -a /usr/StorMan/arcconf /usr/local/sbin/
apt-get remove --purge storman

Step 2: does community deliver?You can, by the way, get (better) packages at http://hwraid.le-vert.net/wiki/DebianPackages from Adam C cile (Le_Vert). I didn t test those much, but I currently use the arcconf package from there, which seems to be exactly what I need: proper dependencies and just the arcconf binary, no Java sh*t.Step 3: monitor the controllerAs this post is about monitoring, not ranting, let s continue. As mentioned before, I only have arcconf installed, which is just a cli to do stuff with the controller. If I understood the docs right, the actual StorMan is able to send notification mails when a disk dies or the controller gets eaten by aliens, but as I don t have StorMan, I have to do things myself.Adam has a aacraid-status package in his repository, which includes some minimalistic shell-daemon to monitor the output of arcconf. It didn t perfectly fit my needs (and had some hickups with my disks which refuse to report a vendor, whyever), so I decided to write something myself (slightly based on what Adam has done in aacraid-status, though).The result is on GitHub: https://github.com/evgeni/aacraidAs you can see the code contains (at the time of writing) exactly ZERO comments and there is no README either, but it s actually quite usable already.

• aacraid.py is the main magic inspired by Adam s aacraid-status, basically just parsing arcconf output
• aacraid-status prints all useful info about all controllers, arrays and disks (the output is pretty much like Adam s)
• aacraidd is a small daemon which will monitor all controllers every (per default) 5 minutes and mail you in case of status-change

I am now running aacraidd and get happy mails when something breaks :) [running = running from /etc/rc.local, no init script yet :)]Step 4: monitor the disks via smartmontoolsThere is one little problem I have with arcconf: it s closed source and does magic to the controller.With the old 3ware controller I was able to monitor the disks with smartmontools/smartd using something like this:

/dev/twa0 -d 3ware,0 -a -s L/../../2/01 -m root
/dev/twa0 -d 3ware,1 -a -s L/../../2/03

This is possible with Adaptect controllers too (not through /dev/twaX obviously). You have to have the sg module loaded, which will result in /dev/sg[012] on my machine, with sg0 being the controller itself and sg1/sg2 the both disks attached to it. Having sg loaded, one can now use smartd with:

/dev/sg1 -d sat -a -s L/../../7/01 -m root
/dev/sg2 -d sat -a -s L/../../7/02 -m root

(-d sat is the important option here!)Thanks to Thomas Krenn Wiki: Smartmontools mit Adaptec RAID Controller for the basic info and ostlogd.spenneberg.net: Adaptec-Raid-Controller S.M.A.R.T.-Healthstatus monitoren for the pointer to the sg module!Step 5: relaxYupp, 4 steps are enough, go relax until the next disk dies (you will be doing something REALLY important that moment according to Murphy).

0 comment(s) this blog is flattr enabled

Second speaker at today'sseminar,Vladimir Mojica. He is talking about th legal backing for DRM and TPM as well as laws against circumvention. He quotes USA's DMCA as one of the most complete, advanced and forward-minded laws,inviting the audience to push for such a law here. I hope he gets to my (written)question, as today is a very important day in this regard: The Senate has requested the presidency to reject signing the ACTA treaty!
[Update] The Senate is sending Resolution agreeing to prompt the Federal Executive Power titular to instruct the State Secretaries and other dependencies involved in the Anti-Counterfeiting Trade Agreement not to sign said agreement, as it would hinder free interchange of legal material. It also mentions the ISPs should not become de-facto authorities to define when an intellectual/intangible properties right violation is in course, and that it would be unacceptable for ISPs to monitor the users' activities in the net, or to analize the content of the IP packets. Very good news, in a document very well made, in a precise, legal and coherent(!) way.

Come to the Portland Debian SOCIAL SCENE. There will be beer and flannel for all. Join us as we hack on software to promote the supremity of Cascadia! Note: neither beer nor flannel guaranteed

Yesterday I became a member of the CNT. Now I just need to buy the tshirt :)

Recently, all relevant packages needed to run mpm (the mancoosi package manager) landed in debian (thanks ralf and zack !). Now it should be a tad easier to run mpm and to play with it. The code of mpm is available on the mancoosi svn repository (user/pass : mancoosi/mancoosi) . To run it, you also need to install python-apt. These are all cudf solvers you can use as mpm backends. They use different solving techniques and were implemented for the MISC competition :

• mccs
• packup
• aspcud

In addition, you need the CUDF solver integration for APT / MPM , that is the component in charge of translating the apt/mpm installation problem to cudf and to provide a solution back to apt/mpm

• apt-cudf

The last (optional) component is the dudf-save that allows you to report an installation problem back to us . mancoosi contest (dudfsave) is avalaible for download at http://mancoosi.debian.net/ the mpm command line is still not very user friendly, but since it is not meant to be used by final users or production systems, I think I'll not spend too much time to add all bells and whistles. enjoy.

This is a frequently asked question: What package manager shall I use? . And my answer is the one that suits your needs . In my case, I even use different package managers depending on what I m trying to do. APT vs dpkg, which one is the package manager? In the Debian world, we re usually thinking of APT-based software when we re referring to a package manager . But in truth, the real package manager is dpkg. It s the low-level tool that takes a .deb file and extracts its content on the disk, or that takes the name of a package to remove the associated files, etc. APT is better known because it s the part of the packaging infrastructure that matters to the user. APT makes collection of software available to the user and does the dirty work of downloading all the required packages and installing them by calling dpkg in the correct order to respect the dependencies. But APT is not a simple program, it s a library and several different APT frontends have been developed on top of that library. The most widely known is apt-get since it s the oldest one, and it s provided by APT itself. Graphical APT front-ends update-manager is a simple frontend useful to install security updates and other trivial daily upgrades (if you re using testing or sid). It s the one that you get when you click in the desktop notification that tells you that updates are available. In cases, where the upgrade is too complicated for update-manager, it will suggest to run synaptic which is full featured package manager. You can browse the list on installed/available packages in numerous ways, you can mark packages for installation/upgrade/removal/purge and then run in one go all the recorded actions. software-center aims to be an easy to use application installer, it will hide most of the packaging details and will only present installed/available applications (as defined by a .desktop file). It s very user friendly and has been developed by Ubuntu. Of the graphical front-ends, I use mainly synaptic and only when I m reviewing what I have installed to trim the system down. Console-based GUI APT front-ends In this category, I ll cite only aptitude. Run without parameter, it will start a powerful console-based GUI. Much like synaptic, you can have multiple views of the installed/available packages and mark packages for installation/upgrade/removal/purge before executing everything at once. Command-line based package managers and APT front-ends This is where the well known apt-get fits, but there are several other alternatives: aptitude, cupt, wajig. Wajig and cupt are special cases as they don t use libapt: the former wraps several tools including apt-get, and the latter is a (partial) APT reimplementation (versions 1.x were in Perl, 2.x are now is C++). You re welcome to try them out and find out which one you prefer, but I have never felt the need to use something else than apt-get and aptitude. apt-get or aptitude? First I want to make it clear that you can use both and mix them without problems. It used to be annoying when apt-get did not track which packages were automatically installed while aptitude did, but now that both packages share this list, there s no reason to avoid switching back and forth. I would recommend apt-get for the big upgrades (i.e. dist-upgrade from one stable to the next) because it will always find quickly a relatively good solution while aptitude can find several convoluted solutions (or none) and it s difficult to decide which one should be used. On the opposite for regular upgrades in unstable (or testing), I would recommend aptitude safe-upgrade . It does a better job than apt-get at keeping on hold packages which are temporarily broken due to some not yet finished changes while still installing new packages when required. With aptitude it s also possible to tweak dynamically the suggested operations while apt-get doesn t allow this. And aptitude s command line is probably more consistent: with apt-get you have to switch between apt-get and apt-cache depending on the operation that you want to do, aptitude on the other hand does everything by itself. Take some time to read their respective documentation and to try them.

Click here to subscribe to my free newsletter and get my monthly analysis on what s going on in Debian and Ubuntu. Or just follow along via the RSS feed, Identi.ca, Twitter or Facebook.

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

A lot of work has taken place since my last report. First, since my original mentor, Matt Zimmerman, is going to be moving, he helped arrange for Stefano Zacchiroli to fill in for him temporarily. I have had a call with Stefano, and I am looking forward to getting to work with him more over the next couple of weeks. Shortly after my first report, we realized that having the dashboard only display bugs severely limited its usefulness. In our original design, we had it pulling a list of bugs with specific usertags from the BTS. This forced all information to be added to bugs, which we viewed as a good thing since it made the information available to the Debian Maintainers without requiring them to familiarize themselves with DEX. The issue was that when looking back at the ancient-patches project or forward to the big merges project, a large portion of the work will be triaging and determining whether or not the changes are even applicable in Debian. If they aren t, there is no reason for a bug to be filed on the BTS. As a result, I spent a fair amount of time re-writing most of the dashboard. It still supports finding bugs on the BTS that have been tagged with a specific DEX usertag, but it is now task-based rather than bug-based. A task can be a bug number, a package name, a patch name, or anything. It is merely something that needs to be done for a project. Each task will have a name, an assignee, a status, a note, and a bug associated with it. There are two ways to define a list of tasks for a project. The first is to tag bugs on the BTS with a user of debian-derivatives@lists.debian.org and a tag with a format of dex-<distribution>- <project> (i.e. dex-ubuntu-ancient-patches). The script will convert the bugs to tasks and automatically set all of the fields. The second method is to specify the list of tasks in a plain text file on the server the scripts are being run on. Eventually, this list will be able to be specified via a web interface. Currently, you are only able to specify the task name in the file. This means that all of the other fields for a task created in this manner are initially blank. I am still deciding on the best way to specify additional information about each task in the file. Once I decide on a method, it should not be too difficult to modify the script to parse and store that additional information. For the ancient patches DEX project, everyone involved had to update a status file stored in a VCS on alioth. This was rather annoying, so we decided early on that we want to be prevent this from being necessary for future projects. This means that the dashboard needs a way for users to modify the information on it. For tasks that are based on bugs, this is rather easy; you simply use the BTS email interface to adjust the bug. However, for other tasks, we needed the ability to modify them on the dashboard. I have managed to get this partially implemented. Currently, all cells on the table are text input fields (with css being used to hide the boxes). This means that you can click on any cell and edit its contents. Hitting the submit button will execute a script to save these changes. This is the tricky part. The dashboard is a collection of html files generated by a python script. The script is meant to be run by cron every n minutes. When you update something via a web interface, you usually expect to see the changes instantly. This means that we can t wait for the python script to run again and re-generate the html files. As a result, I currently have it setup so that when you submit the form, it will go and modify the html files to reflect the changes. The next time cron runs the python script, the html files will be re-created, and the changes made by the user will be lost. Once I come up with a method for storing additional information about a task, it shouldn t be too hard to make changes made by a user via the web interface permanent. I also did some work on a script to generate graphs. There are two types of graphs I hope to be able to display on the dashboard. One graph will help show which individuals have done the most work on a project. I have not started working on this graph yet. The second type of graph is meant to show the number of open tasks versus time. This will allow people to quickly see the progress of a project, estimate how long the project will take to complete, and notice if things start to slow down. I have some initial code for this graph using matplotlib. However, due to the many changes that were made to the dashboard, I had to hold off a bit on this graph, as it relies on certain information provided by the dashboard. I hope to sort out some of the last few issues with this graph, such as getting the axes to display properly, and then merge it with the dashboard sometime in the next few weeks. Allison Randal approached me a while ago to see if my Summer of Code project might be in a state where it could be used to assist with a Python 2.7 DEX project that she was working on. For a while, I did not think that it would be ready. However, last week, I helped her get the related bugs usertagged appropriately, and they now show up in the DEX dashboard. While the dashboard is still not complete, it does allow her and everyone else working on the project to clearly see the tasks (bugs) that they need to focus on and the current status of each of them. I plan to try and incorporate any feedback I receive from people working on this project into my designs. All of my code is available in a git repository on alioth. Keep in mind that it should not be considered stable at this point. Further status updates will be posted on my blog, and I will try to keep the wiki page updated. I am still trying work out where we will host the actual dashboard. In the meantime, you can try out my testing version of it. During the next few weeks, I will be focusing my efforts on coming up with a method for storing additional task information. That will allow me to support permanently storing changes made by users via the web interface. I also hope to finish the first graph script and merge it with the dashboard. Finally, I hope to find a permanent home for the dashboard, as having it on my personal server is not a viable long-term solution. Finally, if anyone is interested in getting involved with DEX, feel free to join the debian-derivatives mailing list, join #debian-derivatives on OFTC, or contact me via email or on IRC (nhandler).</project></distribution>

Hello, this is the 2nd report regarding my project. I'll offer a brief
summary of how are we doing and then the details, so you don't have to
read everything at all.
I have to start saying that over the last two weeks I made a lot of
progress on the project. The most important part: Debian ARM image
integration with Eucalyptus is now cleared. The work to be done for the
next two weeks is pretty much fully coding to achieve what we've committed:
supporting Debian ARM images for Eucalyptus.
What was done so far
--------------------
- I've have identified and mapped what needs to be modified over the
  eucalyptus source for supporting ARM. I'm puting the details on the
  next section. I think this is the most crucial part that is now
  sucessfully achieved.
- I started a Project Log[1] on the wiki, so anyone can check and
  eventyally use the information I've already gathered. The log is being
  updated constantly. You can also check what I've done and what I'm
  working on.
- We got feeback[2] from Eucalyptus developers and packaging
  team regarding developers and packaging team regarding the ultimate
  source for debian/ packaging bits. This was quite important because
  in the past I've managed to build Eucalyptus from source using the debian/
  included in the upstream tarball. However the people in charge
  told us that they were using a different one, which indeed was
  different and resulted in different output than I expected. I'm
  still working on fixing the bits to get a clean build.
- I've joined the pkg-eucalyptus team and I've been given commit rights
  to the repo[2].
1- http://wiki.debian.org/SummerOfCode2011/BuildWithEucalyptus/ProjectLog
2- http://lists.alioth.debian.org/pipermail/pkg-eucalyptus-maintainers/2011-June/000289.html
What I'll be working over the next two weeks
--------------------------------------------
- Heavily code on the different bits that I've identified and need to be
  changed. They are:
  C code:
  - node/handlers_kvm. c,h  - handles nc creation. nc's are node
  clusters for Eucalyptus, the code is in charge of node creation. It
  prepares the "machine" that is able to run a compatible image.
  - util/data. c,h  - handles instance creation. The code over there
  implements the functions node/handlers_* use, like instance creation
  and libvirt's API parameter passing. Since libvirt's parameters for
  ARM vary from x86's ones, we need to support that.
  Perl code:
  - tools/gen_kvm_libvirt_xml - wrapper tool for creating KVM/QEMU
  libvirt's XML Domain definition. This needs to be heavily
  changed/updated - redesigned, to support ARM architecture.
- Depending on the previous task progress: Modify the Debian packaging
  bits for Eucalyptus and push them to the pkg-eucalyptus's team
  repository. This is not crucial for my project's success but I'd like
  to work with Debian official builds. I've yet to commit the
  Eucalyptus team version to the debian/ dir. I expect to have fixed
  the bits to get a successful and clean build, then commit.
Other plans
-----------
- I expect a slow down on the work pace over the second week due end of
  semester exams on the week from July 3 to July 9. After that week I'm
  on vacations and will be fully dedicated to the project.
- Code changes to Eucalyptus source will be pushed upstream. I would
  not like to keep a separate repo for this. I'll talk about this with
  Steffen. Changes to Debian bits will be pushed to the appropiate repos.
Other bits
----------
When the project started I noted it was too vague for some people and
it's results/output were unclear. This concerned me. However, while the
project started and we got lot of feedback things got much clear and I'd
like to take the opportunity to explain it a bit.
Currently, developers targeting ARM devices are struggling[1] with having
a development environment. There are missing bits that sometimes are not
in place and result on hard time for them. Also, due mobile devices
growth and vendors using Linux-based[2] operating systems it's a nice
opportunity for Debian to keep it's well known fame of: supporting every
arch over the sun. How this project fits, well by offering the ability
for developers to run ARM-based Debian images over x86/x86_64 CPU's
would impact the way they could be more productive and for Debian to be
more adopted as development environment.
I can say that I'm very enthusiast of this opportunity and I'm
certain that the outcome will result in more adoption. Even the Ubuntu
people is now pushing more and more efforts for ARM official support,
due the facts I've stated.
1- http://lists.debian.org/debian-arm/2011/06/msg00020.html
2- http://events.linuxfoundation.org/events/android-builders-summit/back

Receiving a full rejection for DebConf travel sponsorship reminds me of a time I was asked to nominate members for a corporate board of directors. At the time I replied that I would not be of much help because I value things which are irrelevant to such positions. Sure, I can identify worthless, grandstanding blowhards, but of the people who are not, I am unqualified to guess which ones make good board members and which do not. The person who had asked me was somewhat confused by my answer, because we come from different perspectives on how the world works and possibly how the world should work.

Sometimes there s nothing quite so heartwarming as hearing a 4-year-old that doesn t think anybody is listening. When Jacob is all alone in his room, sometimes he will sing. Maybe it s a song he knows, or fragments of a song he knows. Or maybe it s something he just made up on the fly. It might be about trains, cats, letters, or who knows what. Maybe it will crack him up and he ll keep singing and then laugh. Or maybe it will stop in 30 seconds and he ll go on to something else. Brief and out of tune though it may be, it is still one of the most beautiful sounds I know and I love to hear it. Jacob loves to have other people sing, too. Sometimes I will make up songs while we drive: We are driving, we are driving, we are driving down the road; we are driving down the old country road and we re making some dust, yes a lot of dust Or Jacob likes me to sing the songs in the Winnie the Pooh book he has (the original, pre-Disney version, which has the words for the songs but not a tune, so I make up a little bit different one each time). Very occasionally he will sing with me, but if he does, he doesn t want anybody to comment about it. I sing with the Kansas Mennonite Men s Chorus. We re a group of about 300 singers (all men, though not all Kansan and not all Mennonite) that sing for charity. We ve raised over $600,000 for charity so far. I still remember the first time I went to a KMMC practice 3 years ago. It was my first year singing, and the first practice of the season. We started singing the first song, and wow what a powerful moment. Even at its imperfect first practice state, hearing 300 people sing quietly is a powerful sound and when they get to the top of their lungs, it s indescribable. No CD can ever quite do that justice. Jacob and Oliver come to KMMC concerts sometimes, but this year they took a special interest. Oliver pointed to, hm, perhaps 300 men and said dad for each one. (He was quite far away and probably couldn t pick me out specifically.) Jacob, for the first time, sat quietly engrossed in the concert until we got to Dry Bones (a song involving surprise and lots of homemade instruments) which made him laugh out loud. Then he would hide under his seat from the applause. Last week, KMMC went on tour. This was my first choir tour, and Terah came along while the boys spent time with grandparents in Kansas. We sang in Bloomington, IL, and then in Goshen, IN at the fairly new Sauder Concert Hall. That hall is a few years old, and has been reviewed as once of the best concert halls in the world acoustically. It seats 1100 people and was perfect for this. The 85 or so singers from KMMC that went on tour joined the Indiana and Ohio Men s Choruses to make a combined group of about 200 singers. And what an experience that was. I learned later this was the first event to completely pack Sauder Concert Hall. We ended the concert singing the Mennonite Anthem a souped-up version of the doxology. (You can see a video of a different group singing it to get an idea of what it was). This is often joked about as being part of Mennonite DNA. You can gather a random group of Mennonites and ask to hear 606 (its number in, well, an old hymnbook that we don t use anymore) and you can probably get a fairly well-sounding rendition, from memory, a cappella, complete with 4-part harmony, at the drop of the hat. Mennonite youth have been known to sing it in train stations, airports, soccer stadiums, and with kazoos. At Goshen, we had 200 men on stage, plus a brass band, plus 1100 people in the audience facing us. They were, of course, invited to sing along. (That s one of the rules of 606: you can t exclude anybody because even if you tried, they d still sing, because how can you resist?) So I was up there on stage, singing a song I love, and hearing the 1100 people in the audience sing it to me. I could glance out over the front rows and saw the smiles on so many faces as they sang, and what a moving moment that was. The excitement and thrill of it all hit me so much that I could barely finish the song. The numbers aren t all in yet, but I m guessing that we raised over $15,000 for charity last weekend (the choir members paid their own expenses in advance, so 100% of the money raised goes to international relief efforts.) A 4-year-old singing alone in his room is really heartwarming. I have to say that 1300 people singing a song that touches each one of them is a pretty close second.

Things aren t exactly going as smoothly as expected. Here are some explanations. First collateral damage: non-free fglrx and nvidia drivers. We have to admit we didn t think of those when we moved libGL.so.1 (and friends) from /usr/lib to /usr/lib/<triplet> (that s the move we call adding multiarch support ). In the mesa 7.10.3-2 upload, some Breaks statements were added to prevent users from installing new mesa packages if they still have old (without multiarch support) fglrx or nvidia packages. Solution: Sticking to the mesa packages in testing is the way to go until fixed fglrx and nvidia packages are uploaded. Second collateral damage: xserver-xorg-core in testing. The plan was to rebuild the server in unstable against the new mesa libraries, so that it would look into the new /usr/lib/<triplet> directory for mesa drivers. Since no source changes were needed, we went for a binNMU as explained in the previous blog post. That s the usual way to deal with libraries, and does the job very nicely. But that failed in this special case, for the following reasons:

1. The server only has libgl1-mesa-dri in Recommends, so there s no hard dependency here.
2. Usually, rebuilding a package against a new library means getting a dependency on the new library (typically because the binary compatibility has been broken, so the SONAME got bumped, meaning one depends on libfoo42 instead of libfoo41). And that means going in testing at the same time as the new library.

But in this case, rebuilding against the new library just means having a different search path somewhere in libglx.so. So the rebuilt package (2:1.10.2-1+b1) happily reached testing, which still contains the old mesa packages, which ship their files in the old /usr/lib path! Solution: Stick to 2:1.10.2-1 packages (snapshot.debian.org to the rescue), or wait a bit and get fixed packages. To get fixed packages, two things were needed:

1. Getting the server package fixed in unstable: that means adding Breaks against old (pre-multiarch) mesa packages, as seen in 2:1.10.2-2. This will ensure that new server package built against new mesa will not be co-installable with old mesa packages, and both mesa and the server should migrate together to testing.
2. Getting the server built again within testing, so that it gets built against old mesa, so that both mesa and the server in testing remains without multiarch until the packages in unstable are ready to migrate together.

While taking care of that second step, it was discovered that many buildds are still lacking a testing chroot, so there might be some delay until the server is rebuilt in testing (as 2:1.10.2-1+wheezy1). Eager users can use the time travel machine mentioned above to get stuff working again sooner. (As far as I can tell, the last problematic combination which would remain would be 2:1.10.2-1+wheezy1 server with new mesa, but we ll make sure we update the Breaks in the new mesa to make sure that it can t happen. Since it s not as urgent as getting the server in testing fixed, it s only queued for mesa 7.10.3-3 for now.)

--- cut ---
Vuoden 2007 lopussa Siebrand asetti lokalisointitavoitteet MediaWikille.Tavoitteet olivat todella kunnianhimoisia. N ytt kin silt , ett n ihin ei p st . Emme kuitenkaan aio luovuttaa ilman taistelua. Viel on vajaa viikko aikaa saavuttaa nuo tavoitteet. Sin voit auttaa saavuttamaan tavoitteet suomen kielen osalta.

Yhteisty ss Stichting Open Progressin kanssa pystymme tarjoamaan sinulle kannustusta. Tarjoamme 1000 euroa jaettuna kaikkien k nt jien kesken, jotka ovat tehneet yli 500 uutta k nn st MediaWikiin ja sen laajennuksiin vuoden loppuun menness .

My s muut Betawikin projektit kaipaavat apua. Kiinnostaisiko sinua k nt vaikkapa FreeCol-peli tai Mantis-virheenseurantaj rjestelm . Yst v llinen ja yhteisty kykyinen ymp rist saattaa sinut vauhtiin sek auttaa sinua kehittym n suomentajana parantamalla k nn ksi yhdess .

Betawiki l ytyy osoitteesta http://translatewiki.net.
--- cut ---
(l hde)

Katso my s http://lokalisointi.org/.

Edit Aug 18th: video available (ogv, also on youtube)

Forget AMD, Intel, NVIDIA! Thomas White's incredible work with Neo FreeRunner's puny graphics dec...accelerator, Smedia Glamo 3362 is starting to bear fruits. Not listening to such comments as the chip will never be used anywhere else and why not spend your time doing something more relevant , he has chosen to actually do what he likes and sees as an interesting challenge. And that's often the spirit of free software, so I don't really agree with the naysayers.

The camera shot on the right, running KMS-enabled X.org driver for the glamo chip on my Debian installation (visible software matchbox-window-manager, fbpanel, zhone), is a bit optimistic looking since Zhone happens to draw correctly. A lot of the drawing is not yet synced correctly, which shows as all text and images in eg. GTK applications being garbled. But as little as two days ago one couldn't yet much launch applications without X crashing, so the newest commits by Thomas were a big step forwards. I'm using Debian, and he's not, so I try to find time to help in debugging even though I really can't much help with the driver code.

The driver is not just one piece of code, but consists of a kernel drm driver (direct rendering manager) using GEM, libdrm support for the kernel driver and finally the X.org driver supporting these other components and offering buzz-words like DRI2. There is also a beginning of a Mesa 3D driver, though it is so far just a skeleton driver since the 2D/KMS/EXA/DRM parts are what should be done first before dwelling into the OpenGL realm.

Openmoko the company is basically nowadays just producing new Neo FreeRunners to resellers, but the community of the so far only Free phone is thriving. The final (Openmoko produced, from where gta02-core continues) version of the phone, with the famous buzzing problem fixed, appeared on store shelves some time ago, offering better out-of-the-box phone functionality in addition to all the mini computer features. It was also offered to Debconf visitors on discount.

It's not only cool to have kernel mode-setting, though it is indeed very cool as well. The reason for much sorrow in the whole OM project has been the graphics chip, and some of the problems with the chip are only finally solvable with the kernel doing the mode-setting. So it's both a very modern thing to use KMS, but there are also clear potential benefits of having accurate control over this very sensitive piece of silicon. The current non-KMS X.org driver for example busy loops in order to try to feed the chip at a correct pace, causing CPU usage every time there is any drawing going on.

This is somehow reminding me about getting the best out of 8-bit computers and other hardware with some specific limitations. The glamo chip is very limited in some ways, but also capable in some other ways like theoretically offering MPEG-4 decoding, OpenGL ES 3D support. It's a mixed bag of things, and I can very well imagine it's indeed an interesting challenge to work on it, if you just have the skills (I don't) and nerves (proper debugging tools help).

It's so nerdy to drool over lines in the X.org log, but I just can help it:

X.Org X Server 1.6.3
Release Date: 2009-7-31
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.28 armv5tel Debian
Current Operating System: Linux neo 2.6.29-GTA02_mydrm #2 PREEMPT Mon Aug 17 18:24:39 EEST 2009 armv4tl
...
II) Using KMS!
...
(WW) Glamo(0): EXA hardware acceleration initialising
(II) EXA(0): Driver allocated offscreen pixmaps
(II) EXA(0): Driver registered support for the following operations:
(II) Solid
(II) Copy
(II) Glamo(0): Initialized EXA acceleration
...
(II) Glamo(0): RandR 1.2 enabled, ignore the following RandR disabled message.
...
(II) Glamo(0): [glamo-dri] Name of DRM device is '/dev/dri/card0'
(WW) Glamo(0): [DRI2] Version 1 API (broken front buffer rendering)
(II) Glamo(0): [DRI2] Setup complete
...
(II) AIGLX: enabled GLX_MESA_copy_sub_buffer
(II) AIGLX: Loaded and initialized /usr/lib/dri/glamo_dri.so
(II) GLX: Initialized DRI2 GL provider for screen 0
(II) Glamo(0): Adding framebuffer....!
(II) Glamo(0): 8 480 640 16 16 960
(II) Glamo(0): rootPixmap = 0x1d0a00
(II) Glamo(0): Done

I'm writing a blog entry instead of just replying to myself on a mailing list, since this subject might be interesting to a largish portion of the community. Most people assume things just magically work out by themselves and then after a release wonder why it wasn't so.

So, I raised a question on ubuntu-devel-discuss mailing list about whether usb-modeswitch should be included in the default Ubuntu 10.04 LTS installation instead of it only being in the universe repository. Reason was simply that firstly, I've read some general wonderings from the community about why it isn't already so. Secondly, without it my 3G modem (Huawei E1552) was first not functional, but right after installing usb-modeswitch package Network Manager worked smoothly with it.

Since I didn't get much discussion going on besides some statements that it doesn't work for everybody and even has caused extra problems for some others (in 9.10), I asked for a small round of comments on the subject on IRC. The channels are logged so I believe I can quote those a bit.

Colin Watson said among else:

"surely we just want the kernel to DTRT [do the right thing] by default ... this is the upstream trend ... it already DTRT for quite a few devices"
"I'd be very concerned about advertising that it's the Way to get things to work, and thus undermining getting things fixed in the kernel"
"I agree that usb-modeswitch is often a way to get otherwise non-working hardware to work ... I'm just not very convinced it's a real properly supportable option"
"but I'm just another user from this point of view, albeit one who ended up in quite a few discussions with various appropriate upstreams last time round :)"

Later on Paul Sladen continued a bit, among else:

"usb-modeswitch is a very long-winded way of sending a single usb-mass-storage command to the device's first profile"
"grep -hr MessageContent usb_modeswitch.d/ sort -n uniq -c sort -rn shows the level of duplication in the configuration files"
"...I do like that it is done in userspace though, as so easy to disable if you wanted something else".

Meanwhile I also IM:d a bit with Antti Kaijanm ki from whom I probably originally coined the idea of following whether usb-modeswitch is integrated into Ubuntu or not. He mainly said that he doubts the feasibility of updating kernel's USB storage quirks in a stable release, compared to having stable release upgrades about the usb-modeswitch-data udev rules. He also proposed discussing maintainability and usability by distros with the Debian maintainer and upstream, although it sounds like Colin might have had some talks already.

So there we are now. Apparently at this point it is hoped that as many quirks as possible are inserted in the kernel, see for example drivers/usb/storage/unusual_devs.h in the kernel. But if you have concerns about if 10.04 LTS will be kept up-to-date regarding 3G modems and want to somehow participate in bringing usb-modeswitch into Ubuntu default installation or simply discuss how to handle the kernel SRUs properly, it's time to stand up and do something.

Should there perhaps be a process with which the usb-modeswitch developers would get the information they are gathering more easily to the upstream kernel _and_ (older) distribution kernels? Is this simply a case of being easier to address an issue with a "hackish" approach, or is the usb-modeswitch actually the right way to go?

Note that I'm no expert in this area, I simply become interested in various subject from time to time :)

-Timo, going to figure out a kernel quirk for his 3G modem

Ever since I blogged about the status of GNOME 3 in Debian experimental, my web logs show that many people are looking for ways to try out GNOME 3 with Debian Squeeze. No GNOME 3 for Debian 6.0 Don t hold your breath, it s highly unlikely that anyone of the Debian GNOME team will prepare backports of GNOME 3 for Debian 6.0 Squeeze. It s already difficult enough to do everything right in unstable with a solid upgrade path from the current versions in Squeeze But if you are brave enough to want to install GNOME 3 with Debian 6.0 on your machine then I would suggest that you re the kind of person who should run Debian testing instead (or even Debian unstable, it s not so horrible). That s what most people who like to run recent versions of software do. How to run Debian testing You re convinced and want to run Debian testing? It s really easy, just edit your /etc/apt/sources.list and replace stable with testing . A complete file could look like this:

# Main repository
deb http://ftp.debian.org/debian testing main contrib non-free
deb-src http://ftp.debian.org/debian testing main contrib non-free
# Security updates
deb http://security.debian.org/debian-security testing main contrib non-free

Now you should be able to run apt-get dist-upgrade and end up with a testing system. How to install GNOME 3 on Debian testing aka wheezy If you want to try GNOME 3 before it has landed in testing, you ll have to add unstable and experimental to your sources.list:

deb http://ftp.debian.org/debian unstable main contrib non-free
deb http://ftp.debian.org/debian experimental main contrib non-free

You should not install GNOME 3 from experimental if you re not ready to deal with some problems and glitches. Beware: once you upgraded to GNOME 3 it will be next to impossible to go back to GNOME 2.32 (you can try it, but it s not officially supported by Debian).

To avoid upgrading all your packages to unstable, you will tell APT to prefer testing with the APT::Default-Release directive:

# cat >/etc/apt/apt.conf.d/local <<END
APT::Default-Release "testing";
END

To allow APT to upgrade the GNOME packages to unstable/experimental, you will also install the following pinning file as /etc/apt/preferences.d/gnome:

Package: *gnome* libglib2.0* *vte* *pulse* *peas* libgtk* *gjs* *gconf* *gstreamer* alacarte *brasero* cheese ekiga empathy* gdm3 gcalctool baobab *gucharmap* gvfs* hamster-applet *nautilus* seahorse* sound-juicer *totem* remmina vino gksu xdg-user-dirs-gtk dmz-cursor-theme eog epiphany* evince* *evolution* file-roller gedit* metacity *mutter* yelp* rhythmbox* banshee* system-config-printer transmission-* tomboy network-manager* libnm-* update-notifier shotwell liferea *software-properties* libunique-3.0-0 libseed-gtk3-0 libnotify* libpanel-applet-4-0 libgdata11 libcamel* libcanberra* libchamplain* libebackend* libebook* libecal* libedata* libegroupwise* libevent* gir1.2-* libxklavier16 python-gmenu libgdict-1.0-6 libgdu-gtk0
Pin: release experimental
Pin-Priority: 990
Package: *gnome* libglib2.0* *vte* *pulse* *peas* libgtk* *gjs* *gconf* *gstreamer* alacarte *brasero* cheese ekiga empathy* gdm3 gcalctool baobab *gucharmap* gvfs* hamster-applet *nautilus* seahorse* sound-juicer *totem* remmina vino gksu xdg-user-dirs-gtk dmz-cursor-theme eog epiphany* evince* *evolution* file-roller gedit* metacity *mutter* yelp* rhythmbox* banshee* system-config-printer transmission-* tomboy network-manager* libnm-* update-notifier shotwell liferea *software-properties* libunique-3.0-0 libseed-gtk3-0 libnotify* libpanel-applet-4-0 libgdata11 libcamel* libcanberra* libchamplain* libebackend* libebook* libecal* libedata* libegroupwise* libevent* gir1.2-* libxklavier16 python-gmenu libgdict-1.0-6 libgdu-gtk0
Pin: release unstable
Pin-Priority: 990
Package: *
Pin: release experimental
Pin-Priority: 150

Note that I used Pin-Priority: 990 this time (while I used 500 in the article explaining how to install GNOME 3 on top of unstable), that s because you want these packages to have the same priority than those of testing, and they have a priority of 990 instead of 500 due to the APT::Default-Release setting. You re done, your next dist-upgrade should install GNOME 3. It will pull a bunch of packages from unstable too but that s expected since the packages required by GNOME 3 are spread between unstable and experimental.

If you want to read more articles like this one, click here to subscribe to my free newsletter. You can also follow me on Identi.ca, Twitter and Facebook.

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

One of our paper has been accepted to The 14th International ACM SIGSOFT Symposium on Component Based Software Engineering (CBSE-2011) happening in June in Boulder, Colorado, USA. This is a joint work with Roberto Di Cosmo, Ralf Treinen and Stefano Zacchiroli.

Abstract

 Software distributions in the FOSS world rely on so-called 
  package managers for the installation and removal of packages on
  target machines. State-of-the-art package managers are monolithic in
  architecture, and each of them is hard-wired to an ad-hoc 
  dependency solver implementing a customized heuristics. In this
  paper we propose a modular architecture allowing for pluggable
  dependency solvers and backends. We argue that this is the path
  that leads to the next generation of package managers that will
  deliver better results, accept more expressive input languages, and
  can be easily adaptable to new platforms.  We present a working
  prototype---called MPM---which has been implemented following the
  design advocated in this paper.

---

More details about the paper are available here

You can see it from my blog activity as well, I simply lack time for lot of things. My Gammu mail folders are horribly full of unread mail, it took me there three months to release a new testing version and there are still some patches pending for review. On phpMyAdmin side I spend most time with my GSoC students, who progress really well, but that's pretty much all I can do there. The good news is that phpmyadmin.cz website has new maintainer and is again getting new content. Hopefully it will stay alive for longer time to bring back lost visitors. My Debian contributions are in still pretty good shape and I manage to fix important bugs, though my MPD related packages are still for sale. Still considering whether to go or not to go to Debconf, my decision will be probably based on fact whether I will get travel sponsorship or not (and when it would happen). Besides these free software activities I began to be more active in Spole n aktivity (in Czech) project for organizing various activities to spend free time. Occasionally I also contribute to OpenStretMap, but it's more or less random time when I notice something is wrong or when I manage to visit some place which is not that good mapped. The good thing is that Prague is pretty good shape there, so it does not motivate me to spend too much time on this :-). And of course there is my work at SUSE, working on usual L3 front and improving our Django based incident tracking tool. Maybe I should step down from some of these, but it would be pretty hard for me to choose which one...

Filed under: Debian English Gammu Phpmyadmin 2 comments Flattr this!

I mentioned this briefly yesterday, but now I'll try to summarize the story of a great surprise and a big moment for me. All this started when my wife Elizabeth and my son Jean-Baptiste wanted to do something special for my 50th birthday. So, it indeed all started months ago, probably early March or something (I don't yet have all the details). Jean-Baptiste described this well on the web site, so I won't go again into details, but basically, this was about getting birthday wishes from my "free software family" in, as you might guess, as many languages as possible. Elizabeth brought the original idea and JB helped her by setting up the website and collecting e-mail addresses of people I usually work with: he grabbed addresses from PO files on Debian website, plus some in his own set of GPG signatures and here we go. And then he started poking dozens of you folks in order to get your wishes for this birthday. Gradually, contributions accumulated on the website, with many challenges for them: be sure to get as many people as possible, poking and re-poking all those FLOSS people who keep forgetting things... It seems that poking people is something that's probably in the Perrier's genes! And they were doing all this without me noticing. As usually in Debian, releasing on time is a no-no. So, it quickly turned out that having everything ready by April 2nd wouldn't be possible. So, their new goal was offering this to me on Pentecost Sunday, which was yesterday. And...here comes the gift. Aha, this looks like a photo album. Could it be a "50 years of Christian" album? But, EH, why is that pic of me, with the red Debconf5 tee-shirt (that features a world map) and a "bubulle" sign, in front of the book? But, EH EH EH, what the .... are doing these word by H0lger, then Fil, then Joey doing on the following pages? And only then, OMG, I discover the real gift they prepared. 106, often bilingual, wishes from 110 people (some were couples!). 18 postcards (one made of wood). 45 languages. One postcard with wishes from nearly every distro representatives at LinuxTag 2011. Dozens of photos from my friends all around the world. All this in a wonderful album. I can't tell what I said. Anyway, JB was shooting a video, so...we'll see. OK, I didn't cry...but it wasn't that far and emotion was really really intense. Guys, ladies, gentlemen, friends....it took me a while to realize what you contributed to. It took me the entire afternoon to realize the investment put by Elizabeth and JB (and JB's sisters support) into this. Yes, as many of you wrote, I have an awesome family and they really know how to share their love. I also have an awesome virtual family all around the world. Your words are wholeheartedly appreciated and some were indeed much much much appreciated. Of course, I'll have the book in Banja Luka so that you can see the result. I know (because JB and Elizabeth told me) that many of you were really awaiting to see how it would be received (yes, that includes you, in Germany, who I visited in early May!!!). Again, thank you so much for this incredible gift. Thank you Holger Levsen, Phil Hands, Joey Hess, Lior Kaplan, Martin Michlmayr, Alberto Gonzalez Iniesta, Kenshi "best friend" Muto, Praveen Arimbrathodiyil, Felipe Augusto van de Wiel, Ana Carolina Comandulli (5 postcards!), Stefano Zacchiroli (1st contribution received by JB, of course), Gunnar Wolf, Enriiiiiico Zini, Clytie Siddall, Frans Pop (by way of Clytie), Tenzin Dendup, Otavio Salvador, Neil McGovern, Konstantinos Margaritis, Luk Claes, Jonas Smedegaard, Pema Geyleg, Meike "sp tzle queen" Reichle, Alexander Reichle-Schmehl, Torsten Werner, "nette BSD" folks, CentOS Ralph and Brian, Fedora people, SUSE's Jan, Ubuntu's Lucia Tamara, Skolelinux' Paul, Rapha l Hertzog, Lars Wirzenius, Andrew McMillan (revenge in September!), Yasa Giridhar Appaji Nag (now I know my name in Telugu), Amaya Rodrigo, St phane Glondu, Martin Krafft, Jon "maddog" Hall (and God save the queen), Eddy Petri or, Daniel Nylander, Aiet Kolkhi, Andreas "die Katze geht in die K che, wunderbar" Tille, Paul "lets bend the elbow" Wise, Jordi "half-marathon in Banja Luka" Mallach, Steve "as ever-young as I am" Langasek, Obey Arthur Liu, YAMANE Hideki, Jaldhar H. Vyas, Vikram Vincent, Margarita "Bronx cross-country queen" Manterola, Patty Langasek, Aigars Mahinovs (finding a pic *with* you on it is tricky!), Thepittak Karoonboonyanan, Javier "nobody expects the Spanish inquisition" Fern ndez-Sanguino, Varun Hiremath, Moray Allan, David Moreno Garza, Ralf "marathon-man" Treinen, Arief S Fitrianto, Penny Leach, Adam D. Barrat, Wolfgang Martin Borgert, Christine "the mentee overtakes the mentor" Spang, Arjuna Rao Chevala, Gerfried "my best contradictor" Fuchs, Stefano Canepa, Samuel Thibault, Eloy "first samba maintainer" Par s, Josip Rodin, Daniel Kahn Gillmor, Steve McIntyre, Guntupalli Karunakar, Jano Gulja , Karolina Kali , Ben Hutchings, Matej Kova i , Khoem Sokhem, Lisandro "I have the longest name in this list" Dami n Nicanor P rez-Meyer, Amanpreet Singh Alam, H ctor Or n, Hans Nordhaugn, Ivan Mas r, Dr. Tirumurti Vasudevan, John "yes, Kansas is as flat as you can imagine" Goerzen, Jean-Baptiste "Piwet" Perrier, Elizabeth "I love you" Perrier, Peter Eisentraut, Jesus "enemy by nature" Climent, Peter Palfrader, Vasudev Kamath, Miroslav "Chicky" Ku e, Mart n Ferrari, Ollivier Robert, Jure uhalev, Yunqiang Su, Jonathan McDowell, Sampada Nakhare, Nayan Nakhare, Dirk "rendez-vous for Chicago marathon" Eddelbuettel, Elian Myftiu, Tim Retout, Giuseppe Sacco, Changwoo Ryu, Pedro Ribeoro, Miguel "oh no, not him again" Figueiredo, Ana Guerrero, Aur lien Jarno, Kumar Appaiah, Arangel Angov, Faidon Liambotis, Mehdi Dogguy, Andrew Lee, Russ Allbery, Bj rn Steensrud, Mathieu Parent, Davide Viti, Steinar H. Gunderson, Kurt Gramlich, Vanja Cvelbar, Adam Conrad, Armi Be irovi , Nattie Mayer-Hutchings, Joerg "dis shuld be REJECTed" Jaspert and Luca Capello. Let's say it gain:

• Danke
• Thank you
• (RTL or not?) / toda
• Gracias
• / arigat
• / n ndi
• Obrigado
• Grazie
• C m n
• Kadin chey la
• / Efharisto
• Dank je wel
• Tak
• D ngge
• Merci
• Kiitos
• Tika hoki
• / dhanyavaadhamulu
• Thank you and God save the Queen
• Mul umesc
• Tack
• / didi madloba
• Gr cies
• Dakujem
• / Aabhar
• / Dhanyavadagalu
• Paldies
• / kop khun krap
• Terima kasih
• Hvala (hr)
• / Dhanyavad
• / Hvala (sr)
• Hvala (sl)
• / Akun
• / Sukriya
• Takk
• / Nandri
• Maki biyen jianbakik
• D kuji
• / Xiexie
• / Aabhari aahe
• Faleminderit
• / Kam sah ham ni da
• / Blagodaram
• / Xiexie
• Hvala (bs)