mirror of
git://slackware.nl/current.git
synced 2025-01-28 08:02:25 +01:00
05ec45c9c9
a/kernel-firmware-20231024_4ee0175-noarch-1.txz: Upgraded.
a/kernel-generic-6.1.60-x86_64-1.txz: Upgraded.
a/kernel-huge-6.1.60-x86_64-1.txz: Upgraded.
a/kernel-modules-6.1.60-x86_64-1.txz: Upgraded.
a/shadow-4.14.1-x86_64-1.txz: Upgraded.
d/kernel-headers-6.1.60-x86-1.txz: Upgraded.
k/kernel-source-6.1.60-noarch-1.txz: Upgraded.
Hey folks, if you've been following LQ you know I've talked before about
dropping the huge kernel and moving the distribution to use only the generic
kernel plus an initrd. After mulling this over for a few months, I think I
was looking at the problem in the wrong way. First of all, it's clear that
some Slackware users have been using the huge kernel all along, without an
initrd, and are (to say the least) unhappy about the prospect of a new
requirement to start using one. I've been recommending the generic kernel for
some time, and a major reason is that we've been using the same set of kernel
modules with two slightly different kernels. Because of this, there have
always been a few (generally seldom used) kernel modules that won't load into
the huge kernel. These are things that aren't built into the huge kernel, but
because of a difference in some kernel module dependency, they won't load.
The conclusion that I've come to here is that rather than drop the huge
kernel, or slap a LOCALVERSION on it and provide a whole duplicate tree of
kernel modules especially for the huge kernel, it would be better to make the
generic kernel more huge, and minimize the differences between the two kernel
configs.
That's what I've done here.
Shown below are the differences between the previous generic kernel config
and the one shipping in this update. You'll notice that most of the popular
filesystems are built in. At this point the main difference it that the huge
kernel has a couple of dozen SCSI drivers built into it. The modules for those
drivers won't load into the huge kernel, but they're fully built in so that
doesn't matter. If you find any other modules that will not load into the huge
kernel, please make a note about it on LQ and I'll see what can be done.
So, tl;dr - what does this change mean?
Unless your root device is on SCSI, if you were able to use the huge kernel
without an initrd previously, you should now be able to use the generic
kernel without an initrd. The kernel is a bit bigger, but we probably have
enough RAM these days that it won't make a difference.
Enjoy! :-)
-CIFS_SMB_DIRECT n
9P_FS m -> y
9P_FSCACHE n -> y
BTRFS_FS m -> y
CIFS m -> y
CRYPTO_CMAC m -> y
CRYPTO_CRC32 m -> y
CRYPTO_XXHASH m -> y
CRYPTO_ZSTD m -> y
EFIVAR_FS m -> y
EXFAT_FS m -> y
EXT2_FS m -> y
EXT3_FS m -> y
EXT4_FS m -> y
F2FS_FS m -> y
FAILOVER m -> y
FAT_FS m -> y
FSCACHE m -> y
FS_ENCRYPTION_ALGS m -> y
FS_MBCACHE m -> y
HW_RANDOM_VIRTIO m -> y
ISO9660_FS m -> y
JBD2 m -> y
JFS_FS m -> y
LZ4HC_COMPRESS m -> y
LZ4_COMPRESS m -> y
MSDOS_FS m -> y
NETFS_SUPPORT m -> y
NET_9P m -> y
NET_9P_FD m -> y
NET_9P_VIRTIO m -> y
NET_FAILOVER m -> y
NFSD m -> y
NLS_CODEPAGE_437 m -> y
NTFS3_FS m -> y
NTFS_FS m -> y
PSTORE_LZ4_COMPRESS n -> m
PSTORE_LZO_COMPRESS n -> m
PSTORE_ZSTD_COMPRESS n -> y
QFMT_V2 m -> y
QUOTA_TREE m -> y
REISERFS_FS m -> y
RPCSEC_GSS_KRB5 m -> y
SMBFS m -> y
SQUASHFS m -> y
UDF_FS m -> y
VFAT_FS m -> y
VIRTIO_BALLOON m -> y
VIRTIO_BLK m -> y
VIRTIO_CONSOLE m -> y
VIRTIO_INPUT m -> y
VIRTIO_MMIO m -> y
VIRTIO_NET m -> y
VIRTIO_PCI m -> y
VIRTIO_PCI_LIB m -> y
VIRTIO_PCI_LIB_LEGACY m -> y
VIRTIO_PMEM m -> y
XFS_FS m -> y
ZONEFS_FS n -> m
ZSTD_COMPRESS m -> y
+NFS_FSCACHE y
+PSTORE_LZ4_COMPRESS_DEFAULT n
+PSTORE_LZO_COMPRESS_DEFAULT n
+PSTORE_ZSTD_COMPRESS_DEFAULT n
kde/plasma-workspace-5.27.9.1-x86_64-1.txz: Upgraded.
l/glib2-2.78.1-x86_64-1.txz: Upgraded.
l/netpbm-11.04.03-x86_64-1.txz: Upgraded.
l/newt-0.52.24-x86_64-1.txz: Upgraded.
n/gpgme-1.23.0-x86_64-1.txz: Upgraded.
n/p11-kit-0.25.1-x86_64-1.txz: Upgraded.
n/php-8.2.12-x86_64-1.txz: Upgraded.
This is a bugfix release.
For more information, see:
https://www.php.net/ChangeLog-8.php#8.2.12
x/xorg-server-21.1.9-x86_64-1.txz: Upgraded.
This update fixes security issues:
OOB write in XIChangeDeviceProperty/RRChangeOutputProperty.
Use-after-free bug in DestroyWindow.
For more information, see:
https://lists.x.org/archives/xorg-announce/2023-October/003430.html
https://www.cve.org/CVERecord?id=CVE-2023-5367
https://www.cve.org/CVERecord?id=CVE-2023-5380
(* Security fix *)
x/xorg-server-xephyr-21.1.9-x86_64-1.txz: Upgraded.
x/xorg-server-xnest-21.1.9-x86_64-1.txz: Upgraded.
x/xorg-server-xvfb-21.1.9-x86_64-1.txz: Upgraded.
x/xorg-server-xwayland-23.2.2-x86_64-1.txz: Upgraded.
This update fixes a security issue:
OOB write in XIChangeDeviceProperty/RRChangeOutputProperty.
For more information, see:
https://lists.x.org/archives/xorg-announce/2023-October/003430.html
https://www.cve.org/CVERecord?id=CVE-2023-5367
(* Security fix *)
xap/mozilla-thunderbird-115.4.1-x86_64-1.txz: Upgraded.
This release contains security fixes and improvements.
For more information, see:
https://www.mozilla.org/en-US/thunderbird/115.4.1/releasenotes/
https://www.mozilla.org/en-US/security/advisories/mfsa2023-47/
https://www.cve.org/CVERecord?id=CVE-2023-5721
https://www.cve.org/CVERecord?id=CVE-2023-5732
https://www.cve.org/CVERecord?id=CVE-2023-5724
https://www.cve.org/CVERecord?id=CVE-2023-5725
https://www.cve.org/CVERecord?id=CVE-2023-5726
https://www.cve.org/CVERecord?id=CVE-2023-5727
https://www.cve.org/CVERecord?id=CVE-2023-5728
https://www.cve.org/CVERecord?id=CVE-2023-5730
(* Security fix *)
xfce/thunar-4.18.8-x86_64-1.txz: Upgraded.
isolinux/initrd.img: Rebuilt.
kernels/*: Upgraded.
usb-and-pxe-installers/usbboot.img: Rebuilt.
|
||
|---|---|---|
| .. | ||
| a | ||
| ap | ||
| d | ||
| e | ||
| f | ||
| installer | ||
| k | ||
| kde | ||
| l | ||
| n | ||
| t | ||
| tcl | ||
| x | ||
| xap | ||
| xfce | ||
| y | ||
| buildlist-from-changelog.sh | ||
| make_world.sh | ||
| README.TXT | ||
This is the source used for Slackware. To look for a particular bit of source (let's say for 'cp'), first you would look for the full path: fuzzy:~# which cp /bin/cp Then, you grep for the package it came from. Note that the leading '/' is removed, and ^ and $ mark the beginning and end of the pattern to match: fuzzy:~# grep ^bin/cp$ /var/lib/pkgtools/packages/* /var/lib/pkgtools/packages/coreutils-9.0-x86_64-3:bin/cp From this, you can see that 'cp' came from the coreutils-9.0-x86_64-3 package. The source will be found in a corresponding subdirectory. In this case, that would be ./a/coreutils/. All of these packages have scripts that extract, patch, and compile the source automatically. These are the 'SlackBuild' scripts. Have fun! --- Patrick J. Volkerding volkerdi@slackware.com