Sun Jul 22 22:38:36 UTC 2012
Howdy!  Lots of shiny stuff here, including the long awaited Xfce 4.10!
Thanks to Robby Workman for the initial set of build scripts, and lots
of testing (plus some very helpful notes about things such as the proper
build order).  I'm calling this a beta (finally!), and it's really very
close to what we expect to release.  Test away.
BTW, Mercury leaves retrograde on August 8th, position 01:26 Leo.  ;-)
...
...
a/udev-182-x86_64-1.txz:  Upgraded.
       Well, udev in this devel cycle has certainly been interesting!  A fair
       number of odd bug reports have been coming in, and we hadn't really been
       able to get a handle on the source of the issues.  Quite some time ago
       we started testing udev-182, and noticed that it caused some issues with
       the persistent net and cd rules.  There'd sometimes be two entries per
       device, so a machine with a single Ethernet card might come up showing the
       card as eth1, with two rules in 70-persistent-net.rules (eth0 and eth1).
       We tested a lot of udev versions trying to determine where the problem
       started, and it seemed to begin with version 176, the first one that
       used libkmod rather than calling out to module-init-tools to load modules.
       Asking upstream about it, they suggested that we just turn the generation
       of persistent rules off.  They'd already turned it off by default.  "Make
       'em make rules!" seemed to be the answer, and since I remember well why
       the autogeneration of net and CD rules came about, I wasn't really happy
       with that answer.  After deploying the "safe" upgrade to 175, we got a
       couple of reports of this same issue happening (though none of us could
       reproduce the issue with 175).  Robby ended up making some patches to
       the rule writing scripts for udev-182 that were able to stop the doubling
       up of rules, but the devices themselves would still be misnumbered on the
       first boot without rules, and would then be correct after a reboot.
       Last week I sat down determined to figure out where the race condition
       was.  After endless reboots with various tests, I got the idea to put my
       network modules on the initrd and have it shell out so that I could take
       a look at them.  What I found was that the rules were generated correctly
       on the initrd.  Well, that was a surprise, but I must have had some kind
       of hunch to even try a test like that.  On another hunch, I ran
       "pstree -c -p | grep udevd" on the running system.  Heh.  There it was.
       We had been running two copies of udevd, and they were fighting it out.
       At some point along the line, udevd was changed.  It used to be that if
       you tried to start a second copy it wouldn't start, and would exit with
       status 1, and our rc.udev script relied on this behavior.  Fixing the
       problem was considerably easier than finding it...  rworkman and I made
       some changes in rc.udev to check if udevd was already running instead
       of expecting it to check for itself.  Another change was required to
       cause it to write out rules if they didn't exist already, and then to
       read them back in (otherwise optical symlinks were still missing on first
       boot without rules).  There's still one issue that was also present with
       udev-175, which is that a hotplugged optical drive won't get symlinks
       unless it has been in at boot and had rules generated for it then.
       Otherwise, things are looking considerably better.  Firmware is loading
       correctly, rules are autogenerated properly again, and several devices
       that were missing in /dev have returned.
       So, there's the story.  Maybe more than you really wanted to know.  ;-)
       Thanks to rworkman for his help on this.  Please report any new problems.
       And if anyone knows how to get symlinks working for a hotplugged optical
       drive like they did in udev-165, a fix would be most appreciated.