Of course, otherwise it does not have much sense. In some way pkgtools could install them in parallel, but that would also make a call to that extra script and ask you for action.

I always use "installpg" from the pkgtools package to only add all of the new kernel packages I want and then adjust some symlinks (non EFI, of course):
vmlinuz.bak to the older backup kernel which is reliable working
vmlinuz to the one I want to reboot TO
vmlinuz.new to the one I want to try out, but not make the boot default yet
and then run "lilo". Its config has been set up to use those links.
The same trick with links can be done for the initrd files, of course (I currently do not any, all of my kernels are custom or huge).

Then at the next reboot I can choose in the lilo menu any of those three, but without interaction it will boot to the vmlinuz one.
As they are only links lilo's config doesn't need to know any of the real kernel versions those three are linked to, so normally doesn't have to be changed at all.

Mutt 1.14.0
 

https://gitlab.com/muttmua/mutt/raw/stable/UPDATING
http://www.mutt.org/relnotes/1.14/
ftp://ftp.mutt.org/pub/mutt/mutt-1.14.0.tar.gz
ftp://ftp.mutt.org/pub/mutt/mutt-1.14.0.tar.gz.asc

nfsdcltrack[1167]: Failed to init database: -13
 

I was tinkering with my Current VM today. I noticed the following error message:

nfsdcltrack[1167]: Failed to init database: -13

Resolving the message:

mkdir /var/lib/nfs/nfsdcltrack
/etc/rc.d/rc.nfsd restart

Some time ago there was an rc.nfsd snippet to create /proc/fs/nfsd/nfsv4recoverydir but that was removed. I don't know if creating /var/lib/nfs/nfsdcltrack should be part of rc.nfsd or if that is something that should be left to users.

I'm not sure this thread is the best place to report such a thing, but the last ChangeLog.txt message is not formatted properly in the slackpkg install-new window, is off by about 10 characters, so line endings get truncated.

https://imgur.com/Z0q2eVo.png

Hello,

The lines seems truncated when the text is larger than the window, but you can scroll the text horizontally with left and right keys.

Just for information, the "changelog dialog" is a slackpkg+ feature.

--
SeB

tmux-3.1b is released.

https://github.com/tmux/tmux/release...ux-3.1b.tar.gz

Why not enabling these entries in the kernel? Are very useful (and necessary) to use hugepages for virtual machines and pci passtrough(gaming, but not only).

Right, you need your UEFI loader to match your hardware. Ideally you could use the loader to load anything, but I don't think it's that simple. I've got a 64-bit loader on 64-bit hardware trying to load a 32-bit kernel/initrd. It makes some progress loading the files, then immediately reboots. Legacy boot is the only way I've been able to make it work.

Anyway, none of that has to do with the problem I'm reporting. Section 3.5.1.1 of the UEFI spec says BOOTIA32.EFI is the conventional file name for a 32-bit loader with PE executable machine type 0x14c. The 32-bit usbboot.img has 32-bit elilo (with the 0x14c machine type) installed as BOOTX64.EFI, not BOOTIA32.EFI.

pygobject-3.36.1
https://download.gnome.org/sources/p...-3.36.1.tar.xz

GCC 10.1 is out:
https://gcc.gnu.org/gcc-10/
https://gcc.gnu.org/gcc-10/changes.html
http://ftp.gnu.org/gnu/gcc/gcc-10.1.0/gcc-10.1.0.tar.xz

My apologies if this isn't completely right - I don't have a 32-bit machine or VM available for testing right now, but it seems like the 32-bit samba needs to be rebuilt on top of nettle? I converted the latest samba using convertpkg-compat32 for use on my multilib system, and it seems that samba-4.12.2 wants to use libbnettle.so.7 and libhogweed.so.5, but nettle-3.6 has libnettle.so.8 and libhogweed.so.6.

NetworkManager-1.24.0
https://download.gnome.org/sources/N...-1.24.0.tar.xz

How about some slackpkg hooks for customization of things like the lookkernel function in post-functions.sh? I add my own code there for updating initrd/kernels/grub, but presumably it will be overwritten when slackpkg is updated. Would be nice if I could keep this persistent.

You just need to create your own custom function in /usr/libexec/slackpkg/functions.d/
The custom function will survive package updates.
The technique is described here

FreeType 2.10.2
Change log and download links, https://sourceforge.net/projects/fre...etype2/2.10.2/

Slackware is one of the few distros without openldap-server package.
In my opinion a openldap-server package in testing, is not a bad idea.
The current had all requirements: sasl and krb5.

installer : expert / menu option clarification
 

Dear Slackware Developers,

I very much appreciate your work on Slackware. I would like to suggest an improvement on Slackware installer, or at least ask a question for clarification.
I just would like to ask question about the setup “Select Prompting Mode” step. The menu and the options have been changed, and I think the older version was better.
In an older version of Slackware Install the options and the explanations were these:

menu Choose groups of packages from interactive menus
expert Choose individual packages from interactive menus.

I’m referring to the old installer, please see on the Slackbook webpage 3.4.7:

On the other hand, the newer and current version of Installer says this:

menu Choose individual packages from interactive menus
expert This is actually the same as the “menu” option

I think the old version was better: it was more clear and it offered two genuinely different options: selection of groups of packages vs selections of individual packages. Why it has been changed?
Also, I think it would be better if the users had this option as well. Is it possible to, say, in next release of Slackware (15.0) we’ll get the old install options again with two different and clearly distinguishable options?

In sum, I think the current installer is either a bit confusing or redundant. Also, I don’t see at all an improvement here from the newer version. :)

I think there are two sensible options:

1. If there is currently no real difference between the “menu” and “expert” options, then there is no reason to keep both of them. I would suggest to keep only one of those with the explanation as follows: “Choose individual packages from interactive menus”.

2. If, however, there is or should be a real difference and choice between individual vs groups of packages, then the old version of installer should be used.

I would go for (2), the old version, since the explanation is clear, it offers an extra option and more flexibility in installing.

Thank you for clarification.

For me I say the latter, particularly between menu and expert - hence why perhaps at least menu or expert should have the output changed to terse the very least.

The last version where the maketag and maketag.ez menus were any different was Slackware 11.0.

Granted. So, this change has been implemented almost 14 years ago. However, my main concern wasn't about that which version of the installer is the older one. Slackware isn't the best simply because this is the oldest active Linux distribution. Rather because of its features and principles. My question/concern was about those. ;)

@HPeter82: Why bother?

1. Tagfiles (as package series) are a remnant of the floppy disks era, which is long gone.
2. Why would someone use the expert mode nowadays is beyond me. If you can list the packages you want to install, just type installpkg <list>. Or write a custom tagfile if you really like them.
3. There are things done or named nobody remembers why, that's life. Does anyone remember why the mount point of the root partition of the to_be_installed_Slackware_system is named T_PX?

I install slackware only with tagfiles, I love them :)

That was the variable name used in the old SLS install scripts. My best guess was it meant "target partition".

Re: pango, there has been quite a debacle on the Internet over the past little while about pango 1.44 majorly breaking font rendering in freetype.

I hope Pat holds off on upgrading until it's sorted out. Some people are genuinely angry about this and are calling for a fork.

https://gitlab.gnome.org/GNOME/pango/issues/463

NordVPN has announced they now support WireGuard.
They claim it is "faster" and more "secure."
https://nordvpn.com/blog/major-upgra...ynxIntro_Gold1
It would be nice to have that added to Slackware64-current.
I guess one could build their own 5.6 kernel.
:twocents:

you actually can use wireguard also on older kernels via the wireguard-linux-compat kernel module

https://slackbuilds.org/repository/1...-linux-compat/
https://slackbuilds.org/repository/1...reguard-tools/

FWIW the above packages build just fine on current.

Yes, I was working on that before I placed the previous message.
Downloaded and installed, but couldn't get it to work.
I'm usually up before the chickens, so I'll try tinkering with it again tomorrow morning.
:)

brctl on the slackware install initrd doesn't work. It runs OK, but it can't create a bridge. It gives the error:
Initially I thought I might be missing the bridge module, but it seems it isn't included at:
/lib/modules/5.4.40/kernel/net/bridge.ko

(or anywhere else in the modules directory).

I've been using the NordVPN WireGuard, "NordLynx", on Windows and Mac and it certainly handshakes faster than OpenVPN. Certainly I haven't noticed any worse performance in use than OpenVPN so even if all does is improve set up time that's a win.
My vote is for it to be in Slackware 15.0 in some manner.
See also:
https://nordvpn.com/blog/nordlynx-pr...125.1584305730

1. Udisks2 has a lot of new versions but Slackware ships an old one. Distros without systemd (Void, Crux, Gentoo, Devuan) use most recent version. Maybe there is a way to update it.
2. Why Slackware ships cpufrequtils, but not cpupower?
3. I don't use x3270, but it has a new version

That's interesting, I just learned that cpufreq is being replaced by cpupower and I'm wondering if cpupower can work/get integrated without systemd (should).
https://www.kernel.org/doc/readme/to...pupower-README
https://lwn.net/Articles/433002/
https://github.com/torvalds/linux/tr...power/cpupower
Arch & Debian:
https://wiki.archlinux.org/index.php...aling#cpupower
https://wiki.debian.org/CpuFrequency...h_cpufrequtils

Systemd isn't needed for cpupower, probably need one rc.cpupower script.

(The cpupower package consists of the following elements:

requirements
------------

On x86 pciutils is needed at runtime (-lpci).
For compilation pciutils-devel (pci/pci.h) and a gcc version
providing cpuid.h is needed.
For both it's not explicitly checked for (yet).)

AFAIK this should be updated with the new XFCE.

Just connected via NordVPN/NordLynx/WireGuard.
It was done via a terminal.
Hopefully, NordVPN will make some protocols available that will work with NetworkManger/OpenVPN.
OTOH, if it is possible to connect to everything I use (yet to be discovered) I can live
with using the command prompt once or twice a day.
:)

Edit in: Cannot connect to the Linux-Kernel Archive or Accuweather and can reach, but cannot sign on to Netflix.

VPNs and tor are increasingly blocked, almost to the point they become useless :(

FWIW, only 3 out of the 25 or more websites I visit on a regular basis is not bad.
:)

Edit in: Netflix worked the second time I tried it (different server).

Heh, I haven't been able to see https://www.kernel.org/ for a long time. And I don't even use a VPN.

@cwizardone
Google and CloudFlare enabled sites are the worst.

@Skaendo
kernel.org works here through tor with Scandinavian exit nodes

https://www.kernel.org works here, with or without a vpn.
It is, http://lkml.iu.edu/hypermail/linux/kernel/ that doesn't connect when using a vpn. It always works without the vpn.

What really surprises me is that sending and retrieving e-mail from gmail via Thunderbird works like a charm with NordLynx/WireGuard. It hasn't worked in the past when using just NordVPN.
When I first subscribed to NordVPN, I spent a great deal of time trying to get e-mail/gmail to work while using the VPN. Never happened, until this morning.

What was the issue you had with wireguard-linux-compat and wireguard-tools out of interest? I've been maintaining both packages on SBo for a bit, if it was anything beyond a configuration problem, it would be good to get it solved.

Thank you for maintaining the packages!

Problems?
Well.... at this point (age) I'm lucky to remember my name. :)
IIRC, yesterday I had trouble starting the daemon.
This morning, I swear I wasn't doing anything different, but it started. From there it was a matter of
running,

nordvpn set technology nordlynx

and signing on with,

nordvpn c

Once done it remembered the "Technology is already set to 'NordLynx'."

It also remembers the user name and password.

One thing. Each time I've signed on it returns the message,
"A new version of NordVPN is available! Please update the application."
I looked for a newer package on their website, but didn't see one.

Other than that, all is well.

Thanks, again, for the packages!
Greatly appreciated.
:hattip:

Edit in: BTW, what is the security risk of letting the user start the rc.nordvpn daemon?

please bump vulkan-sdk

easyrsa - although due to it's nature, perhaps in /extra and not in the main installation

Good security practice is to try to run a service that is exposed publicly (Internet) with a dummy user that has no storage & shell rights on the system.
If possible (accepted by the way the service was designed) user home pointed to /dev/null and shell to /bin/false

Python 3.8.3
https://www.python.org/downloads/release/python-383/

Mesa 20.0.7

The release notes, https://www.mesa3d.org/relnotes/20.0.7.html

f2fs requires crc32 module
 

Just an FYI but, I've been messing around with the installer on a spare laptop (UEFI & elilo) and if I make the root filesystem use f2fs, the system fails to boot because it is missing the crc32 module. If I do "modprobe --show-depends f2fs" nothing shows up (other than f2fs).

This Debian change mentions "crc32 as hidden dependency module for f2fs" so I rebuilt the initrd.gz to include crc32 (mkinitrd_command_generator.sh --run -m crc32) and the system boots OK.

I have been using the f2fs as a root filesystem for quite a while (in fact, have even sent a patch to the kernel so that the xattrs feature is build by default with f2fs, which is required for properly using it on the root).

But I do that using a "huge" kernel, which is by far a much safer option in every respect, since _a single file_ is the only thing that you need to have to make the system boot up to a survivable state, so I definitely recommend just using the "huge" kernel.

(If you search the forum, there I have also posted a report on building a kernel with an initrd appended to it. I wish I had time to finish this.)

Could we have

added to /etc/inputrc ? It is a relatively (a few years old) new addition to readline, but I find it cool.
This binding is also in accord with Emacs's backward-sexp/forward-sexp.