Big Changes

There will be a big changes in the next Slackware (11). I can see it from the latest changelog that has been published by Patrick Volkerding yesterday. The first thing is that it will use kernel 2.6.16.x as the base kernel for next Slackware. Next, it will use udev rather than hotplug on a machine which uses kernel 2.6.x and HAL installed. New udev has also been introduced, even though it's not the latest one (Pat prefer stable version than bleeding-edge version and risk the stability that he maintained very well up to now). Here are the full list of the latest changelog :

Mon Apr 24 14:29:50 CDT 2006
a/hotplug-2004_09_23-noarch-6.tgz: Patched rc.hotplug.
On 2.4 kernels use /sbin/hotplug for hotpluging, but on 2.6 kernels use
/sbin/udevsend (if udev is being used) instead. This should work better
on systems using 2.6 kernels with udev and HAL. Among the people pushing
for this change for a while: Jon Grosshart, Piter Punk, and Eugene Crosser.
Blacklisted hw_random after reports that it causes some systems to crash.
Note that rc.hotplug is now installed as rc.hotplug.new, but upgradepkg
will still replace it for one more package iteration. This will cause
hotplug to be made executable on machines where it currently is not, so
be aware of that.
a/slocate-3.1-i486-1.tgz: Upgraded to slocate-3.1.
This uses a new database format, so you'll have to wait for the cron job or
run "updatedb -c /etc/updatedb.conf" as root. Thanks to Piotr Simon and
Erik Jan Tromp for pointing out that the docs for the previous package were
installed with incorrect permissions.
a/udev-071-i486-1.tgz: Upgraded to udev-071.
Set ttyUSB devices to mode 660 so that users in group tty can use them.
Get rid of the 10-udev.hotplug -> /sbin/udevsend symlink in
/etc/hotplug.d/default. This fixes a race condition with using the hotplug
event handling system now enabled by default in the latest udev.rules.
Another nice effect of this is that udevd no longer runs needlessly on 2.4
systems. WARNING: any existing udev.rules file will be overwritten, so save
your old file if you have custom rules you'd like to merge in).
Based on ideas suggested by Eugene Crosser, Piter Punk, and myself.
In /etc/udev/scripts/make_extra_nodes.sh and floppy-extra-devs.sh, use
${udev_root} instead of hardcoding /dev. Thanks to Andreas Schnaiter.
In /etc/udev/scripts/make_extra_nodes.sh, fixed a bug that caused a bad
cdrom -> pktcdvd/control symlink to be created if the pktcdvd driver was
loaded prior to running the make_extra_nodes.sh script.
Thanks to Kenneth Pettersen for the bug report and fix, and to Giovanni
Quadriglio who also reported the issue.
Finally, thanks to Piter Punk for his continued exploration of udev's
bleeding edge. What's going on there is quite interesting, but there are
still some issues that have led me to decide it's best to take small steps
in that direction. For example, it was nice to be able to populate /dev
before checking the partitions and mounting them read-write, and it seems
that won't be possible any longer. I've had other reports of hardware that
wasn't hotplugged correctly, too (and ran into some myself). Mostly it
seems to be a question of figuring out the proper place in the boot process
to put udev, but there are also a lot of things we're left to figure out
concerning the udev rules. We'll get there, but maybe not in the next
release. This upgrade to udev-071 meets the minimum requirement in the
2.6.16.9 Documentation/Changes file, and has been heavily tested here and
found to work well. udev-090 boot the machine faster, but isn't as
reliable (at least in testing here, with how it's called from our init
scripts), and I've never been in favor of trading reliability for speed.
ap/alsa-utils-1.0.11-i486-1.tgz: Upgraded to alsa-utils-1.0.11.
ap/mysql-5.0.20a-i486-1.tgz: Upgraded to mysql-5.0.20a.
d/guile-1.8.0-i486-1.tgz: Upgraded to guile-1.8.0.
I don't think anything in Slackware depends on guile any more, and that the
only thing that ever did was a solitaire game in GNOME. Since the GNOME
distributions for Slackware are already including their own guile packages,
I'm considering this package for removal. How generally useful is it?
Perhaps something like Ruby in the D series instead would be more useful.
l/alsa-driver-1.0.11_2.4.32-i486-1.tgz: Upgraded to alsa-driver-1.0.11,
compiled for Linux 2.4.32.
l/alsa-lib-1.0.11rc4-i486-1.tgz: Upgraded to alsa-lib-1.0.11rc4.
The reason for 11rc4 rather than 11 is that there was a new subsystem added
(src/pcm_rate_linear.c) in 11rc5, that I suspect causes aRts to break on
at least one system using snd-via82xx and/or snd-ac97-codec -- aRts bails
with a message about a CPU overload. The exact chipset is:
VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60)
It would seem to me that rc4->rc5 was kind of a risky time in the release
cycle to introduce such a massive change to the codebase. In any case,
I think it's prudent to stick with alsa-lib-1.0.11rc4 as the default
alsa-lib version until this gets sorted out upstream.
l/alsa-oss-1.0.11-i486-1.tgz: Upgraded to alsa-oss-1.0.11.
l/libungif-4.1.4-i486-2.tgz: Fixed libgif.so* symlinks.
Thanks to Wim Speekenbrink.
xap/imagemagick-6.2.7_0-i486-1.tgz: Upgraded to ImageMagick-6.2.7-0.
xap/mozilla-1.7.13-i486-1.tgz: Upgraded to mozilla-1.7.13.
This upgrade fixes several possible security bugs.
For more information, see:
http://www.mozilla.org/projects/security/known-vulnerabilities.html#mozilla
This release marks the end-of-life of the Mozilla 1.7.x series:
http://developer.mozilla.org/devnews/index.php/2006/04/12/sunset-announcement-for-fxtb-10x-and-mozilla-suite-17x/
Mozilla Corporation is recommending that users upgrade to Firefox and
Thunderbird, but if you're a fan of the style of the Mozilla Suite, I'd
recommend SeaMonkey myself. There's a good chance that Mozilla will not
ship in the next Slackware release, and SeaMonkey will ship in its place.
I'd been wondering which way to go with that, but getting an official
EOL statement about the Mozilla Suite makes it seem like the switch to
SeaMonkey should happen sooner rather than later.
(* Security fix *)
extra/slacktrack/slacktrack-1.29-i486-1.tgz: Upgraded to slacktrack-1.29-1.
testing/packages/alsa-lib-1.0.11-i486-1.tgz: Added alsa-lib-1.0.11. This is
primarily intended for people to verify the issue with VIA sound, look for
a similar issue with other chipsets as well (seems possible, since the issue
isn't in any VIA specific code in alsa-driver), and report any useful
information found to the upstream developers:
https://bugtrack.alsa-project.org/alsa-bug/
I reported the issue via (ha;) email, but not through the bug track system.
The developer I contacted couldn't reproduce the issue and didn't think it
had anything to do with the rate plugin additions. If other folks test
alsa-lib-1.0.11 and run into this, and have the time to jump through the
hoops needed to report the bug at the URL above, I'd appreciate the help.
At least it would demonstrate that it's not just my machine...
testing/packages/linux-2.6.16.9/alsa-driver-1.0.11_2.6.16.9-i486-1.tgz:
Upgraded to alsa-driver-1.0.11 compiled for Linux 2.6.16.9.
testing/packages/linux-2.6.16.9/kernel-generic-2.6.16.9-i486-1.tgz:
Upgraded to Linux 2.6.16.9 generic kernel.
testing/packages/linux-2.6.16.9/kernel-headers-2.6.16.9-i386-1.tgz:
Upgraded to Linux 2.6.16.9 kernel headers.
testing/packages/linux-2.6.16.9/kernel-modules-2.6.16.9-i486-1.tgz
Upgraded to Linux 2.6.16.9 kernel modules.
testing/packages/linux-2.6.16.9/kernel-source-2.6.16.9-noarch-1.tgz
Upgraded to Linux 2.6.16.9 kernel source.
BTW, I think 2.6.16.x, being the first kernel series in the 2.6 series that
has been promised some long-lived support, will be the 2.6 kernel you'll see
in the next Slackware release. If/when 2.6.17 (or 18, etc.) come out, don't
expect to see me chasing after it immediately. I'm looking for a kernel
that can be counted on for stability -- not the bleeding edge. Of course,
once 2.6.16.x is considered tested enough to leave /testing (and it does
seem close), perhaps a newer kernel might take its place here just for fun.
Oh and yes -- I did see that 2.6.16.10 is out, and I know that the test26.s
kernel wasn't yet updated. Due to the Mozilla situation, I can't delay this
update to be a $SUCKER some more, but you'll see 2.6.16.10 soon. That is,
if there isn't a newer one first...