CUPS 2.3.0 - https://www.cups.org/
https://github.com/apple/cups/releases/tag/v2.3.0

https://imagemagick.org/download/Ima...9.10-62.tar.lz
https://imagemagick.org/download/Ima...-62.tar.lz.asc

https://mesa3d.org/relnotes/19.1.5.html
https://mesa.freedesktop.org/archive/mesa-19.1.5.tar.xz
https://mesa.freedesktop.org/archive...1.5.tar.xz.sig

It seems to be related to a recent change to vgacon that breaks speakup: https://bugzilla.kernel.org/show_bug.cgi?id=204039

1 members found this post helpful.

I have a request for a slight configuration/build change to ntp in slackware current. Would it be possible to configure ntp with these additional options -:

--enable-ATOM \
--enable-GPSD \
--enable-SHM \
--enable-kmem \

and to also have timepps.h (from pps-tools git) in /usr/include/sys before ntpd is built (this step is critical for proper PPS support).

The end result is a slackware package that is 2037KB in size, versus the 1970KB in current. The additional options dont have any effect on the end user with the default ntp.conf (they wont notice a difference), but allow those that want to use GPS or PPS sources to do so without recompiling. Relevant GPS/PPS devices are relatively cheap and plentiful these days, and Slackware already ships with the PPS kernel modules so other aspects are already in place.

4 members found this post helpful.

With the latest usbboot.img (21-08-2019), the command cryptsetup works, and I now have a working installation! :-)

I encountered the following issue when trying to run the installed system the first time: the initrd.gz that was generated by the /sbin/mkinitrd script was lacking the library "libgcc_s.so.1", and when trying to decrypt the harddrive, I received the message:
and the initrd.gz would not decrypt the drive. In order to solve this, I added the line
to the script /sbin/mkinitrd. This is of course an ad-hoc solution, but now the initrd.gz is working!

I also encountered two kind of warnings when installing using the latest usbboot.img of slackware64-current:

(1) When issuing the command "cryptsetup" when running usbboot.img, the warning
appears. This does not appear to be the case when running the same command on the installed system.

(2) I installed from a HTTPS mirror, and the following warning was displayed many times during installation (I was using the "terse" option when installing):

1 members found this post helpful.

GNU Nano 4.4
https://www.nano-editor.org/news.php
https://www.nano-editor.org/dist/v4/nano-4.4.tar.xz
https://www.nano-editor.org/dist/v4/nano-4.4.tar.xz.asc

Any idea what will happen in regards to Python in Slackware 15.0?
I'm just asking because I read in the news today that Python 2 now will be permanently abandoned.

PS. I'm not that interested in Python personally.

1 members found this post helpful.

Me too. My certbot keeps warning me that python 2 is gonna die. I assume certbot will run on python3, but I havent tested it yet. I think python2 could just go away. Problems should be reported up stream.

A few of my upgraded pc's have stopped sending email. They complain that "alias database unavailable". All I need to do is run 'newaliases' and things take off.

I dunno if the installpkg can run that? Or maybe mention it in changes_and_hits?

The postfix install script does run newaliases. I tried upgradepkg --reinstall postfix-3.4.6-x86_64-1.txz here and /etc/aliases.db was rebuilt as expected.

I did some more debugging regarding the missing libgcc_s.so.1 in the initrd: while I was unable to find an executable or library that is dynamically linking to this library in the initrd, it seems that Arch Linux has apparently come across the same problem: https://bugs.archlinux.org/task/56771

In that thread, they hypothesize that the source of the problem is here: https://gitlab.com/cryptsetup/crypts...2/thread.c#L34

Apparently LUKS2 has introduced a new password-hashing algorithm called Argon2, and the implementation of this algorithm depends on pthread_cancel(), which is located in libgcc_s.so. In particular, if one migrates an already existing LUKS1 partition to LUKS2, one is unlikely to encounter this problem, since the password hash function that is used is apparently not Argon2 (at least judging by the comments in that thread).

2 members found this post helpful.

My system didn't boot from a usb drive using a -huge kernel, and only booted after I supplied an initrd with the following modules:

Would it be possible to consider them for inclusion in the -huge kernel as "=y"?
I believe it should make it easier to install Slackware.

1 members found this post helpful.

Maybe other hardware need other modules. Anyway IMHO -huge kernels are a thing of the past in an installed system. Better use a generic kernel and an initrd (as made now easy in -current and its installer). Allo using the file systems' uuid instead of the partitions' names (or even the partitions' uuid as grub 2.04 now allows. You would just need to make sure that the partition table has a label if it's a dos one as then the partitions' uuid are computed appending "-<partition number>" to the label)*

* As an aside this could make easier in the future to boot any installed system even without an associated initrd using os-prober as the kernel knows the partition's uuid (but not the file system's uuid). Alas the grub shell is now able to search by partuuid in case of gpt but not yet in case of a dos partition table. patch welcome to add this possibility

1 members found this post helpful.

Well, now we still have huge kernels, and people use them. Adding a few modules for booting is not going to make things much more complicated, and would be another survival tool in case of an unexpected malfunction.

Admittedly, the kernel has an option
And if it really works, I'd be happy if we had a "small kernel with a huge initramfs built-in, with all modules from /lib/modules". But in any case, having a single-file bootable image is still very important.