blogTILLuDROP

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.

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. :-)

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.

Whenever I do somethong new on Fedora, it is normally time to report some bugs and one import part of the bug report is to include the name-version-release string of the affected rpm package. To get this string easily, I created an alias for it:

alias nvr='/bin/rpm --qf '\''%{name}-%{version}-%{release}\n'\'' -q'

When I handle new bug reports, then I often need to request this information, because I handle several bug reports for components in Red Hat Bugzilla, where most reported bugs are there because of a bug iin some other package. E.g. people report bugs against radeontool, but it’s a bug of the radeon driver, which is included in xorg-x11-drv-ati. Therefore it would be nice if people would have this useful alias or shell script installed on their system, e.g. as rpm-nvr. Maybe I should create a package like rpm-query-scripts that also provide some other useful queries, e.g. for package reviews.

There is now some easy to read documentation about conditional builds available at the rpm.org wiki.

Today I published my git repository of the tool I started to write to supply a upstream release monitoring service to Fedora. Some time ago Michał Bentkowski wrote a tool called FEVer to do this, but he became unresposive and did not publish the full code of FEVer. Since I missed this service, I started to write a new tool, that can provide the same service, which is currently called “cnucnu”, because of the lack of a better name. It does not have any bugzilla reporting features yet, but they will be added eventually. At the time of this posting, it only supports to check all packages that are listed on the Fedora wiki page of FEVer and to test regular expressions for easy development of one for a new package.

I just wanted to try out preupgrade to update to Fedora 11, but then I was disappointed that it does not verify securely what it is downloading and installing onto my system. And even worse, this is not even announced by preupgrade. It is so strange, on the one hand all rpm packages are signed and even the algorithms used are updated, but on the other hand the signatures are not used. So please be aware that if you use preupgrade, it will not verify that the installed content came from Fedora.

I just registered for BruCON, because the early bird tickets are only available for two more days. Will you come, too? It would be nice to meet some Fedorians there, but I guess I would have more luck at some generic FOSS conference.