Search Results: "Bas Zoetekouw"

24 June 2008

Jose Luis Rivas Contreras: New xscreensaver 5.05-3

After some time and various patches there's a new version of xscreensaver that fixes a lot of issues with 5.05 and XineRama. Thanks to all that submitted patches: Bas Zoetekouw, Vincent Crevot, Lionel Elie Mamane and Daniel Dickinson for the desktop file. The deb files are available here along with the dsc, changes, diff.gz and orig.tar.gz files. If you don't use i386 then do:
dget --build \
http://debian.rivco.info/xscreensaver/5.05-3/xscreensaver_5.05-3.dsc

13 March 2008

Christian Perrier: Squashing badly encoded changelog files - task completed

Back in February, I worked on packages providing badly encoded changelog files. With the removal of gmanedit from testing and unstable (Gnome 1.x removal process) and the ack that perl wrongly changelog encoding is mostly upstream's changelog (which will be hopefully fixed), I think its OK, now, to announce that this lenny release goal is achieved. Thanks to Bas Zoetekouw who did the mass bug filing which helped a lot tracking this down. We could now imagine tracking down badly encoded debian/copyright files... PS: above, "badly" means "using national encoding"...which is generally ISO-stoneage^W8859-1.

19 September 2006

Jeroen van Wolffelaar: Utrecht Bug Squashing Party

Tomorrow we'll have the first real-life meeting, together with Thijs Kinkhorst and dr. Bas Zoetekouw, to organize details about the upcoming Debian Bug Squashing party in Utrecht, The Netherlands, on the weekend of September 30th. As a study association, A-Eskwadraat has had Debian Developers for quite some time, from Bas since 2000 until our most recent addition, Thijs, but we've never organized a Debian event – yet. In 2002 though, there was a Mozilla 1.0 release party where also the release of woody was celebrated. The university has been supportive of the initiative, and is offering the location for free, as long as there are not too many people around that they feel the need for (expensive) security to be on-site 24h/day. For that reason, and also for food planning, please do subscribe yourself in wiki. If more than 25 people end up subscribing, we'll let you know how we'll arrange that. We're still not having a definitive deal with a sponsor, so don't know how flexible we are in this regard. At this moment, we've also got a handful of international attendees too, including Debian's "Second in Command", Steve McIntyre. I'm looking forward to it, and to meeting various Debian contributors (mostly again). See you in Utrecht!

4 September 2006

Margarita Manterola: RC bugsquashing days 4 and 5

Following the trend, these are the bugs I squashed yesterday and today As the other day, the last bug was actually fixed twice (Bas Zoetekouw also prepared the NMU). The main problem here is that the BTS is being slow, and it's difficult to know that someone else has already fixed a bug.
So I guess that if you are going to join the the "fix one RC bug per day" movement, you'd better join #debian-bugs on oftc, and say which bug you are working on, so that we don't overlap that much.

15 March 2006

Martin F. Krafft: udev and grey hair

It won't be long before I grow grey hair if udev keeps pulling tricks on me. Yesterday, an upgrade to 0.087-1 hosed one of my systems. The system is sarge-based, but it is connected a to a cable modem needing the cdc_ether driver, which 2.6.8 does not have. Since I don't expect backports of 2.6.15 to sarge (Update: backports.org has a 2.6.15 backport, but it won't solve my problem it seems), but also don't want to migrate my system to testing, I simply decided to pin linux-image-2.6.15-1-686 and all its dependencies to unstable with APT:
Package: linux-image-2.6.15-1-686
Pin: release a=unstable
Pin-Priority: 600
Package: initramfs-tools
Pin: release a=unstable
Pin-Priority: 600
Package: udev
[...]
The install worked, and off I went to reboot... but the machine did not come back up, and booting 2.6.8 with the new udev also failed. Great. At first, I thought I knew the problem, but at closer inspection, it was something else: udev's ide.agent hung itself up and timed out. It turns out it was looking for hd141 instead of hda, and once I found that out, it didn't take long to put two and two together: 141 is ASCII 97 is 'a'. And if you echo hd\141 just like that, the shell will swallow the backslash. Marco, the udev maintainer blamed a broken shell, and I identified busybox-cvs-static to be the problem; Replacing it with busybox from unstable fixed the issue. Now all that remains is to convince Marco that the bug has nothing to do with initramfs-tools when it occurs in a script provided by udev. initramfs-tools depends on busybox-cvs-static busybox since it works with either. If udev doesn't work with busybox-cvs-static, it has to conflict, which is not really an option though, due to a libc6 upgrade loop. Fortunately, the 2.6.16 kernel will make ide.agent obsolete, so the problem shall vanish in smoke. With one problem solved, I woke up this morning to find another. I use udev's network interface renaming feature to ensure that my interfaces always have the names I expect, and that their names give me a hint as to what they're connected to. Sure, using /etc/modules to ensure a defined load order would work fine, but I have too many machines under my control to want to remember that eth2 on this machine is the wireless LAN. So I use the following udev rules:
wall:~# cat /etc/udev/rules.d/local-interfaces.rules
KERNEL="eth*", SYSFS address ="00:02:8a:80:21:31", NAME="internet"
KERNEL="eth*", SYSFS address ="08:00:46:b1:2d:ee", NAME="lan"
KERNEL="eth*", SYSFS address ="00:50:04:5b:ec:b3", NAME="wlan"
KERNEL="eth*", SYSFS address ="00:04:23:72:4e:6c", NAME="wifibackup"
Update: Bas Zoetekouw suggested to match against something else than MAC addresses, for testing. Thus, I tried PCI IDs (using the topmost SYSFS device entry in the udevinfo output):
KERNEL="eth*", SYSFS device ="0x24c4", NAME="internet"
KERNEL="eth*", SYSFS device ="0x103d", NAME="lan"
KERNEL="eth*", SYSFS device ="0x5157", NAME="wlan"
KERNEL="eth*", SYSFS device ="0x1043", NAME="wifibackup"
The problem remains the exact same. It also remains the same if I completely remove wlan and wifibackup. When I woke up this morning, I found the following mess:
wall:~# ip addr
2: internet: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 08:00:46:b1:2d:ee brd ff:ff:ff:ff:ff:ff
3: eth0_ifrename: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
    link/ether 00:02:8a:80:21:31 brd ff:ff:ff:ff:ff:ff
4: wifibackup: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000
    link/ether 00:04:23:72:4e:6c brd ff:ff:ff:ff:ff:ff
5: wlan: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
    link/ether 00:50:04:5b:ec:b3 brd ff:ff:ff:ff:ff:ff
    inet 192.168.14.129/25 brd 192.168.14.255 scope global wlan
    inet6 fe80::250:4ff:fe5b:ecb3/64 scope link
      valid_lft forever preferred_lft forever
The wlan and wifibackup interfaces are configured correctly (I use wifibackup to hook into the various open WLANs around, when my provider goes down, or I need more bandwidth). But internet was assigned to the LAN interface, and eth0_ifrename, well... that's just whacked. Looking at the udev code, this seems to be due to a patch Marco pulled from Ubuntu, which is to guard against race conditions in the renaming. For instance, if eth0 needs to become eth1 and vice versa, udev renames the first to eth0_ifrename and waits until the other has finished its identity change. The patch, however, is a hack: it tries endlessly to rename the interface to its final target name, which, in my case, obviously goes on forever.
10:18  * Md just copied it from the Ubuntu package
10:18 < madduck> why???
10:19 < Md> because it worked in my artificial setup
Unfortunately, this isn't the first time that Ubuntu's "giving back to Debian" (which requires Debian to go out and fetch) is two steps back rather than one forward. I would hope that maintainers of criticial packages (such as udev) would exercise more care when pulling from Ubuntu. And that Ubuntu would please stop adding hacks to packages and instead concentrate on fixing issues at the root the Debian way. So my problem still persists, and even given Ubuntu's ifrename patch problems, I can't figure out what is actually going on. It does not help that udev also suddenly stopped logging interface name changes. Yes, just like that.
KERNEL="eth*", SYSFS address ="00:02:8a:80:21:31", NAME="internet"
KERNEL="eth*", SYSFS address ="08:00:46:b1:2d:ee", NAME="lan"
How can these two rules actually trigger the rename conflict? The only way I could imagine is that udev gets confused and falsely renames 08:00:46:b1:2d:ee to internet. Then, when it gets to the other card, a name collision occurs, udev chooses eth0_ifrename as temporary workaround, and then tries forever to rename eth0_ifrename to internet, which will never succeed. So why does udev get confused in the first place? Why would it ever name the interface 08:00:46:b1:2d:ee internet? Beats me. But I better end here because the world surely doesn't need just anoAther udev rant. Update: I forgot to mention that the renaming works just fine when I unload/load modules from the command line. It's only during the boot process that things go wild. Update 2: I should not that it does not work fine some of the time if the modules are loaded in quick succession.