blogTILLuDROP

Augen nach Schwimmen in der Schwimmhalle Brand in Aachen

Die Schwimmhalle Brand wird wohl etwas stärker gechlort als die anderen Hallen in Aachen. Und es gibt keine kalte Dusche im Herren-Duschraum. :-(

Last weekend I attended at the Fedora Activity Day Niederrhein 2010. It was my first FAD and very interesting. I got to know the 6 other Fedora Users here in my federal state ;-) and I believe there were around 12 FOSS users around. On the first day we had a little gpg keysigning party using gpg-key2ps fingerprint stripes. It went pretty well after we got a printer working so everyone else could print his gpg fingerprints cut them using the scissors I brought (Uh, I believe I also forgot to take the scissors home). I also answered some questions about gpg. But I was not sure which gpg keyserver to recommend, since subkeys.pgp.net is not as reliable as it was some years ago. But I know now a better one, it is x-hkp://pool.sks-keyservers.net. I did not expect that much interest in gpg, since there was only one attendee listed on the wiki page, but then everyone took part.

The remaining time, I finally got to review the package submission from the first Fedora packager candidate I was going to sponsor, answered some generic FOSS questions / helped with removing the NVIDIA binary driver from a fresh installation and started to take a deeper look at the package status scripts. Most of the information did not look that interesting to me and since perl scripts seemed to be involved, I started writing/gathering some code to identify EOL packages in CVS, koji and PKGDB. I got it working, but it seems that the only way to do this for PKGDB is to query all packages instead of making it return such a list. The next step is to compare these lists to find packages, that are not marked as EOL in three databases. Another data source is the wiki, where another list needs to be compared. This is then going to be my first new status report script.

I believe the next Fedora meeting in my area will be at  FrOSCon 2010 near Bonn, Germany. I hope I will be able to attend there, as well.

There is a lot of discussion ongoing about how to change Fedora updates and several proposals for an update policy float around. But after I read parts of the FESCo log for the meeting last night, where an updates policy was discussed, I came to another conclusion. Fedora needs more systematic testing. There is a proposal to require at least three positive testing comments in Bodhi (aka 3 karma points) to allow testing updates to become stable. But afaics nobody prepared some statistics about what this would have meant for the previous updates, i.e. how many updates would have been pushed in the past from testint to stable with this policy enabled.

And this leads to a big problem, there is no real knowledge available how well Fedora updates are covered by testing. Looking at the Bodhi metrics, it seems that there is not that much testing going on for testing updates in F11, because the top testers seemed not to improve recently, but the top testers in F12 have already provided more feedback. But even with these comments, there is no way to properly detect how well the testing of a package is covered, e.g. there was an update that was clearly broken that still got positive karma by people who thought using it in a dependent package, but this was not true. I do not want to blame them, because the non-existent dependency was not obvious, but this shows why systematic testing is important. This does not meant that everything has to be tested perfectly, but it should be at least known how well updates are tested to know how to improve it.

My opinion on requiring karma for updates is, that before this is done, it should be made sure that there are enough people willing to test the updates or a automated package behaviour testing should be implemented. E.g. for every package for that a certain karma amount is required, at least one dedicated tester and several occasional testers should sign up. And the required number of the testers should reflect the number of karma points required for an update. If people want better updates in stable, they should imho contribute to testing them, even if they only spend one hour every month on it.

TinyOS is one of the projects I currently use, that still use CVS. Luckily I found a git mirror soon after I started using it, but the one I used is not up to date any more. I asked on the TinyOS-devel mailing list to create such a mirror on Sourceforge.net. I am not sure, whether this will happen soon, the first feedback was not very promising. But at least I was pointed to another git mirror, that is well hidden within a lot of irrelevant (for me) lines on the TinyOS wiki. Nevertheless, currently updated git repositories are as follows:

• git clone git://hinrg.cs.jhu.edu/git/tinyos-2.x.git (TinyOS 2.x gitweb)
• git clone git://hinrg.cs.jhu.edu/git/tinyos-2.x-contrib.git (TinyOS 2.x contrib gitweb)

As other people already found out, the cvs status output sucks pretty much. I found some simple bash scripts to make them a little more useful, but then I quickly wrote a simple MIT-licensed python script that creates an output like modern scms do. It can be downloaded from my Fedorapeople space. Luckily Fedora will anyhow move to git, soon, so I won’t have to use CVS that much anymore then.

It will fail, if files are in a state unknown to the script, but it should cover the most common states (read: the states I found in my cvs checkout). Feel free to report any states that it should handle and I’ll update it.
Here is some example output (I defined an cvss alias for it):

$ cvss
? unknown
O common/Makefile.common
O devel/Makefile
? devel/xz-4.999.8beta
? devel/xz-4.999.8beta.tar.gz
M devel/xz.spec
O EL-5/Makefile


As you can see, it sorts the output and also handles subdirs

Starting tomorrow, the Fedora mailing lists will be migrated from redhat.com to lists.fedoraproject.org. This will mess up everybody’s mailfilters that use the List-Id-Header. I just changed my .procmailrc to use the old and the new List-Ids with a huge sed command. This script can be temporarily downloaded from my Fedorapeople webspace. Maybe it is helpful for you, too. Here is a short excerpt:

#!/bin/bash
# Author: Till Maas
# The sed expressions have been created with:
# sed -e 's/^\(.*\) \(.*\)/-e '\''s!\1.redhat.com!(\1.redhat.com|\2.lists.fedoraproject.org)!'\'' \\/' mlmigration.csv
# mlmigration.csv is a csv version of
# http://jstanley.fedorapeople.org/mlmigration.ods with the first line removed
# and a space used as delimiter
sed -e 's!fedora-announce-list.redhat.com!(fedora-announce-list.redhat.com|announce.lists.fedoraproject.org)!' \
-e 's!fedora-list.redhat.com!(fedora-list.redhat.com|users.lists.fedoraproject.org)!' \
...
-e 's!fedora-trans-fa.redhat.com!(fedora-trans-fa.redhat.com|Trans-fa.lists.fedoraproject.org)!' \
-e 's!fedora-trans-te.redhat.com!(fedora-trans-te.redhat.com|Trans-te.lists.fedoraproject.org)!' \
-e 's!fedora-virt-maint.redhat.com!(fedora-virt-maint.redhat.com|Virt-maint.lists.fedoraproject.org)!' \
-e 's!fedora-trans-as.redhat.com!(fedora-trans-as.redhat.com|Trans-as.lists.fedoraproject.org)!' \
"${@}"

This script might of course break something in your setup, so please use it only if you understood what it does. Also I do not know, whether the new values for List-Id are really accurate, I just assumed the suffix to be “lists.fedoraproject.org” like it is for the logistics mailing list.

Yesterday I started to migrrate my notebook to Fedora 12. First it was all fun, but then the bugs hit me. A currently very annoying commonly known bug is, that on intel notebooks, the display may not get switched on, if the lid was closed. The current workaround is to create a shortcut to call xrandr to reset the output. I wanted this to happen automatically and after I failed to even get a gasp about how to do this with hal. Is there even any documentation or guide that explains this for anyone like “man acpid” explains how to perform actions when the lid is opened/closed? I was first foolished by acpid not wanting to start because hal-addon-acpi already opened /proc/acpi/events, but thanks to the bug report I knew that it is just an problem of the startup order. Hal was already started, but after I stoppped it, I could easily start acpid and then haldaemon again.

Now here is the configuration to get the he workaround xrandr calls run automatically:

cat /etc/acpi/actions/reset-display.sh
#!/bin/bash
PATH="/bin:/usr/bin:/sbin:/usr/sbin"
export DISPLAY=:0.0
if grep open /proc/acpi/button/lid/LID/state
then
su "$(getent passwd 500 | cut -d: -f1)" -c "xrandr --output LVDS1 --off"
su "$(getent passwd 500 | cut -d: -f1)" -c "xrandr --output LVDS1 --auto"
fi



cat /etc/acpi/events/reset-display.conf
event=button/lid LID 00000080.*
action=/etc/acpi/actions/reset-display.sh


It will only work if the user with uid 500 uses display :0.0. Probably this could be changed to work in all cases, but it works for me. :-)

Argh, leider erstmal zu spät für dieses Jahr habe ich mitbekommen dass vom DLRG-Düsseldorf regelmäßig ein Rheinschwimmen veranstaltet wird. Dieses mal am 16.02

Nach dem Big Jump 2009 habe ich schonmal nach Möglichkeiten in NRW im Rhein zu schwimmen gesucht und nur die Veranstaltung vom DUC Köln zu Christi Himmelfahrt gefunden. Es wird wohl mal Zeit eine Liste dafür zusammenzustellen, damit man diese Veranstaltungen leichter findet:

• 16.01.2010 (zweiter oder dritter Samstag im Januar): Rheinschwimmen des DLRG Düsseldorf Mail: Neujahrsschwimmen duesseldorf.dlrg.de (Anmeldung Anfang Dezember des Vorjahres)
• 13.05.2010: Christi Himmelfahrt, Köln DUC Köln, Info 2009
• 19.06.2010: DLRG Bad Honnef/Unkel

Außerhalb von NRW:

• 10.08.10: Basel

Thanks to Alex and Claus, I can now play with an Arduino. My first attempt was to rebuild the Auduino synthesizer. It works, but it needs a lot more improvement. It seems that using a bread board creates some interference and two of the potentiometers I am using are 10.2kOhm instead of 4.7 kOhm. But on the other hand I did not spend an hour to build it and setup the Arduino software.The illumination is provided by Fnordlicht.

Today I wanted to review a package, but lots of review requests I searched, that are not already assigned to somebody are still in an unfinished state. There are already some issues raised that the submitter did not yet address.

There is a way to mark these review requests: Add NotReady to the status whiteboard of the review request. By adding this, interested maintainers can easily filter out review requests, that do not yet need their attention. The cached review requests already filters these review requests out. Once the issues are addressed, the submitter can just remove the entry from the status whiteboard.

So please use the NotReady entry in the future if you found some blocking issues in a review request, to make it easier to find bug reports that need attention by a reviewer.