Skip to content

upstream version numbers and uscan

Posted by on

I have just experienced a nightmare with a watch file. The phpmyadmin upstream dumps all released files onto a single web page, and they use version numbering a.b.c-foon, which “foo” being beta, rc, or pl, and of couse a.b.c for a release version.

This has resulted in the following (probably incorrect) watch file

version=3

opts=“uversionmangle=s/0\.tar/0-5.tar/;s/beta/0./;s/rc/1./;s/pl/9./,dversionmangle=s/0\.tar/0-5.tar/;s/beta/0./;s/rc/1./;s/pl/9./” http://prdownloads.sourceforge.net/phpmyadmin/ (?:.*/)?phpMyAdmin-([-0-9\.a-z]+)\.tar.gz$ 2.7.0-pl2 uupdate

As Germans say: “Gesundheit”

Goodbye, Chris Kurz

Posted by on

Christian Kurz, an ex-colleague of mine and one of my mentors who brought me to the Debian project, has recently retired from the project. Actually, he is probably the DD who has spent the most time in educating me about the project - it was easy for me since I only needed to speak up in the office to reach him. He has been sponsoring my first uploads back in 2001.

Chris, thanks, for doing so much for Debian, and for me. You were a great help, and I'm looking forward to getting bug reports from you. It is a great honor to know you.

Personally dropping support for users of debianhowto.de exim configuration

Posted by on

There is a HOWTO on the Internet which has the intention to help new users with creating their allround web-administrated exim mail server on Debian basis, using our pre-compiled packages. Unfortunately, this HOWTO starts with disabling all Debian magic in the exim4 configuration, which I personally think is WRONG to suggest to a newbie, and does not quite mention this in the documentation. The result is a big number of support requests in the Debian-specific and generic exim support mailing lists and IRC channels.

The makers of debianhowto.de do not seem to be quite interested in a peaceful co-existence.

Continue reading "Personally dropping support for users of debianhowto.de exim configuration"

Thoughts about the Debian kernel

Posted by on

I am one of the guys who builds Linux kernels locally, from vanilla sources. What I don't like in this approach is that I do not get the distribution patches and might miss one of the kernel security patches, since I am way too busy to keep track of LKML any more. otoh, I am kind of a version number junkie when it comes to the kernel, so the Debian kernel sources even in sid frequently are not current enough. So, what I want to have is a compromise between a vanilla kernel and the Debian distribution kernels, built in a way that the images integrate well with Debian.

This article contains a few questions and wishes directed towards the Debian kernel team.

Continue reading "Thoughts about the Debian kernel"

Delegates, Communicate!

Posted by on

Today, over the day, access to security.debian.org was intermittent as usual in the last few weeks. But this afternoon, things suddenly got much worse. All my cron-apt installations on and behind firewalls began to yell at me that securiy.debian.org was completely unreachable.

But. Wait. I don't know that IP address. I don't know the host name tartini.debian.org.

Once again, the solution was found in Joey's Blog. Apparently, security.debian.org was moved to the new host, and everything is fine.

Nearly everything.

UPDATE: There has been an Announcement, but not where I would have expected it. The IP address hasn't been mentioned there, though, and that announcement wasn't signed.

UPDATE: There has been one more change to the IP addresses of security.debian.org: It now seems to be round-robin DNS of three hosts. While this is now a real advance compared to the old situation, it has - again - been unannounced to the public. And I get a free trip around my firewalls for the second time in 24 hours. Thanks, guys - I'd surely be twiddling my thumbs otherwise.

Continue reading "Delegates, Communicate!"

Usertags im BTS

Posted by on

Vor einem Monat hat ajt Usertags und User Categories angekündigt.

Damit wird die Behandlung komplexer Packages im BTS einfacher, weil man eigene Struktur in die Bugreports bringen kann. Hoffentlich reicht das Featureset, um meine unabhängig vom BTS im Debian Wiki geführten Webseiten zur Bugklassifikation in die Tonne treten zu können. Die Zeit wird das zeigen.

My daily wtf. today: cron.daily/aide

Posted by on 

if [ -n "$NOISE" ]; then
        NOISETMP=`tempfile --directory "/tmp" --prefix "aidenoise"`
        NOISETMP2=`tempfile --directory "/tmp" --prefix "aidenoise"`
        sed -n "1,/^Detailed information about changes:/p; "$LOGDIR/$LOGFILE" | grep "^\\(changed|removed|added\\):" | grep -v "^added: THERE WERE ALSO [0-9]\\+ FILES ADDED UNDER THIS DIRECTORY" > $NOISETMP2

        if [ -n "$NOISE" ]; then
                < $NOISETMP2 grep -v "^\\(changed|removed|added\\):$NOISE" > $NOISETMP
                rm -f $NOISETMP2
                echo "De-Noised output removes everything matching $NOISE"
        else
                mv $NOISETMP2 $NOISETMP
                echo "No noise expression was given."
        fi
fi

Too bad that a shell doesn't complain about unreachable code. I must have smoked some very strange stuff when submitting that patch to aide years ago.

aide 0.10-9 in experimental

Posted by on

After taking over aide co-maintainership in January and successfully convincing Mike to put the project on alioth, I have done some work on aide and have uploaded 0.10-8 on September 18 and 0.10-9 on September 27 to experimental.

These two versions acknowledge the two NMUs we recently had and fix some issues that I thought would be worth fixing. Please test. I plan on uploading to unstable on a week, if no bad goofs surface during the experimental phase.

Unfortunately, aide's upstream is quite dead, so it is unlikely that any upstream bugs will get fixed without you submitting patches.

Next step will be convincing Mike to allow creation of a pkg-aide-maintainers mailing list for the Maintainer:-Field, so that messages sent to the maintainer field instead of aide@packages.debian.org can reach me as well.

Continue reading "aide 0.10-9 in experimental"

security.debian.org overloaded

Posted by on

The recently released security update of Xfree86 for sarge has made something happen what I have been fearing for years: Gazillions of systems downloading the update have slashdotted security.debian.org, which is now sluggishly responding for the second day in a row.

This doesn't make my cron-apts happy, which in turn bury me under error message e-mails. Ungood, since one might miss an important update in the avalanche of "cannot pull packages.gz from security.debian.org" mails.

This experience has shown that having security.debian.org a single point of failure is not as good of an idea as we thought. I am afraid that the security team will have to reconsider and to finally establish mirrors for security.debian.org to spread the load.

Update: After reading much of the discussion about the topic, I find it strange that nobody besides me blogged about the issue, but we actually have an official announcement about the sdo outage. Very good.

Establishing a mirror network for sdo is not quite easy since unlike for the main archive, we cannot use "randomly offered" mirroring services, but we need the sdo mirrors under our control. Main reason for this is that we need sdo mirrors to be fast, because people would begin to complain that an update has not yet hit the mirrors after the advisory has gone out. Already today, it frequently happens that the cron-apt processes have detected an update quite some time before the release of the actual advisory, and you don't want the process to take even longer. Even push mirroring is way too slow.

I like the idea of not establishing mirrors, but caching proxies distributed around the world, so that the issue of a mirror pulse simply vanishes: The proxy would fetch the update on the first incoming request, and deliver from its local cache for some time before looking on the actual sdo server again whether the file is still current. Neat idea.

Datenschutzerklärung - Impressum