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.
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.
On numerous requests, I am temporarily deconfiguring my RSS feed from planet.debian.org. Looks like there is an
incompatibility between p.d.o and serendipity which causes dupes to appear on the planet.
Some people think that the dupes are more annoying than my articles are worth reading. So, I am leaving.
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.
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.
Jurij Smakov et al have published the Debian Linux Kernel Handbook, which will help in documenting the internals of the Debian Linux Kernel build process. The document is still work in progress with a lot of sections missing, but it's a giant step in the right direction.
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.
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.
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.
My advice as a new exim4 / debian user myself is to read the documentation first. Then read the documentation. (There is a lot of it.) Read the documentation, or some people might point out that you have not read the documentation.
Thanks, Jeremiah Foster, this has just made my day.
After using the unofficial kde 3.4 packages from alioth for some months, I have migrated back to Debian unstable on the weekend, and my main work machine is now plain sid again. That means that I am running x.org and official transitioned kde 3.4, and can finally report bugs against the official setup again. So, kde and x.org people, brace for impact of bug reports and keep up your excellent work.
