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.

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

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.

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

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.

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.


$ cat rpmbuild-currentdir.sh
#! /bin/bash

/usr/bin/rpmbuild –define “_sourcedir .” –define “_rpmdir .” –define “_buildir .” –define “_srcrpmdir .” –define “_speccdir .” “$@”

I was also told, that it is possbible to use acpid to run this command when the key is pressed. Nevertheless I wonder, why this out-of-the box since I buyed the thinkpad working button was broken. Asking on the hal-mailinglist did do get me any reply, so if you know anything helpful, please leave a comment. :-)

secure:

ssh fedorapeople.org cat /home/fedora/till/public_html/files/cvspkgsrc-force-tag.gmk >> .cvspkgsrc


insecure:

curl http://till.fedorapeople.org/files/cvspkgsrc-force-tag.gmk >> .cvspkgsrc


Don’t forget to check your .cvspkgsrc afterwards.

Here are the lists:

Unassigned Review Requests – Review Requests in progress – Accepted Review Requests – Rejected Review Requests

Thanks go to Jeff Johnson for motivating me to do this and telling me, that it is ok to modify %__gpg_sign_cmd. And also to Panu Matilainen for backing this up. I normally have a strong aversion against modifying macros that begin with two underlines, but with this encouragement it is not that bad. ;-)

That’s enough talk, here comes the code:

I added this to my ~/.rpmmacros file:

%__gpg_check_password_cmd /bin/true
%__gpg_sign_cmd %{__gpg} gpg --batch --no-verbose --no-armor --use-agent --no-secmem-warning -u "%{_gpg_name}" -sbo %{__signature_filename} %{__plaintext_filename}

Now rpm will still ask for a password, but one can enter anything. If the gpg-agent needs a password to unlock a key, it will just fire up the pinentry command, which will then allow three password entry attempts by default. If entering an empty password for rpm is still too annyoing for you, Aaron Hawley described how to use expect to provide a password to rpm.

But there was the problem, that the because of some timeout, the socket got killed after around 30 minutes. This is of course pretty annoying. One solution is to create some traffic via the control socket every now and then to keep it open. But then one has still to open the control socket.

I did a little “investigation” and noticed that the ssh command is passed to cvs via the environment variable CVS_SSH. This makes it pretty easy to write a wrapper to first test, whether a control socket exists and to create one, if it does not. Here is what I came up with:


$ cat ~/.ssh/config
Host cvs.fedoraproject.org
ControlMaster auto
ControlPath ~/.ssh/sockets/controlsocket-%h-%p-%r

$ echo $CVS_RSH
/home/till/bin/fedora-cvs-ssh.sh
$ cat bin/fedora-cvs-ssh.sh
#! /bin/bash

SSH_USER=”${2}”
SSH_SERVER=”${3}”

/usr/bin/test -e ~/.ssh/sockets/controlsocket-${SSH_SERVER}-22-${SSH_USER} || /usr/bin/ssh -f -N -l ${SSH_USER} ${SSH_SERVER} </dev/null >/dev/null 2>/dev/null

exec /usr/bin/ssh “$@”

If you extend the ~/.ssh/config file for other hosts, it should work out of the box for every cvs over ssh access that uses port 22. If you want to use a different port, you have to edit it a little.


--- /usr/share/doc/gtk-vnc-python-0.3.7/gvncviewer.py 2008-09-05 14:32:15.000000000 +0200
+++ gvncviewer.py 2008-12-09 16:16:10.000000000 +0100
@@ -164,7 +190,13 @@
port = "5900"
print "Connecting to %s %s" % (host, port)

-vnc.open_host(host, port)
+import socket
+domain_sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM, 0)
+domain_sock.connect(sys.argv[1])
+
+
+# vnc.open_host(host, port)
+vnc.open_fd(domain_sock.fileno())
vnc.connect("vnc-pointer-grab", vnc_grab, window)
vnc.connect("vnc-pointer-ungrab", vnc_ungrab, window)