I wholeheartedly support such a move. The only raison d’être for GnuPG 1.4 is for those who need to still be able to decrypt old messages or archives from the 1990s. Everybody else should be using GnuPG 2 (and even those needing GnuPG 1.4 for compatibility should use GnuPG 2 most of the time, and use GnuPG 1.4 only when decrypting old messages).

It would be very nice if invoking gpg on Slackware gave you GnuPG 2.

(Full disclosure: I am a GnuPG contributor.)

But why switch to Wayland and use terminal emulator straight from the dark days of X?

Using xterm as default has the advantage that xterm is installed outside of xfce or kde package series. It is essential that if sway is installed whichever terminal is the sway default is also installed or else the sway DE will be unusable until you manually configure the default to be a terminal that you do have installed (unless you also install a launcher with it like bemenu or dmenu_wayland - but then that package has to be installed and the default sway config must point to it or you still have the same issue). Configuration changes using a text editor in console to sway are simple, but I believe most distros want to ship a DE that usually works immediately post install without a prerequisite of tinkering with config files to start it the first time. Personally my sway slackbuild points at xfce4-terminal as default terminal, but my slackbuild leans toward doing as much as possible in wayland natively. As LuckyCyborg pointed out, going the other way and pointing at xwayland whenever possible yields a better user experience on a lot of hardware.

still there

Hello,

Would it be possible to modify default /etc/inputrc to prevent highlighting pasted text when pasting from middle-click in xterm ?

IMHO it only add confusion: is it the text we selected (old fashion) or is it the text we pasted (new fashion) ?

Old fashion was not confusing, everything selected in xterm was staying highlighted, period.

Line to add in /etc/inputrc:
set enable-bracketed-paste off

BR

Larry

Probably not a bad idea, especially as there seems to be a parameter to disable it at boot-time but not one to enable it. However, this is a significant user visible change in system behaviour that will impact anyone who currently uses nice values to manage system-wide relative task performance in the traditional manner.

Migration actions will be required for such folk, even if it's only to add noautogroup to their boot parameters.

This one is CHANGES_AND_HINTS worthy.

AND, what impact will have this SCHED_AUTOGROUP kernel option on the mode how elogind works?

After all, the elogind uses CGROUPS to do its job. And LXC too.

Remove TokuDB stuff from rc.mysqld?
 

MariaDB no longer builds the TokuDB plugin by default (so it's no longer at /usr/lib64/mysql/plugin/ha_tokudb.so) and it seems it is deprecated in MariaDB 10.5 and will be removed in 10.6, so perhaps the TOKUDB parameter can be removed from rc.mysqld?

Geoff.

None I would expect as elogind uses its own cgroup controller, where as autogroup interacts with the cpu controller, but I'm not much of an expert on cgroups or elogind for that matter, so best if someone else confirms that.

What I'm not yet clear on with AUTOGROUP is how group niceness values (as opposed to thread/task niceness values) interact with the cpu.shares values in the cpu controller. I might have to play sometime.

So I'm revisiting this. While I don't think it's required to have the cache_check binary (provided by thin-provisioning-tools), it probably would be nice to have. Manually deactivating a volume gives this warning message:

(issue 2)
when add more NICs after installation, /etc/udev/rules.d/70-persistent-net.rules was not updated)

i compil 'eudev' without the option '--enable-rule_generator' and it work, without problem here ;)

mcabber 1.5..4 (Bugfix release from january)

With OTR (Off-The-Record messaging) enabled ?

As said before it would just be a matter of adding --enable-otr :)

Since #!/bin/sh has been replaced with #!/bin/bash in slackpkg, it might be worth to mention that /etc/rc.d/rc.S and /etc/rc.d/rc.M contain some commands that use brace expansion and arrays (in rc.S) which are not defined by POSIX. This will make systems that have /bin/sh symlinked to strictly POSIX-compliant shell (like dash) fail to boot. So, either #!/bin/sh needs to be replaced with #!/bin/bash or below changes need to be applied.

Thanks!

glib-networking-2.68.1
https://download.gnome.org/sources/g...-2.68.1.tar.xz

PipeWire-0.3.26
Many bug fixes and improvements,
https://gitlab.freedesktop.org/pipew...eleases/0.3.26

Postfix install script breaks systems
 

Postfix install script is overwriting aliases file on updates


Pat,

please DO NOT symlink /etc/postfix/aliases to /etc/aliases if/etc/postfix/aliases exists,
every update breaks custom settings.

ap/slackpkg-15.0.2-noarch-1.txz: Upgraded.

revert this.

Try to install some txz , under custom folder ...it fails ever if custom destination not have installed the pkgtools.

As a little example this change breaks the scripts to make liveslak , cuase when try to put some pkg series under custom dir to make separate series this fails ever if not install first pkgtools on our custom folder , and remove it later.

If you make custom settings in /etc/aliases everything should work after an update.
Or set alias_maps in main.cf to where you like.

I am very aware of how postfix works, I've been using and contributing to it since we left sendmail around 2005-6.

Every postfix install ever puts alias file in /etc/postfix

Pat's install makes that a symlink to /etc/aliases which wipes out our /etc/aliases, changing main.cf will make zero difference, since it is already correctly setup

I understand Pat wants to keep it painless for those used to sendmail, but this is one part he has nastily overlooked.

I only picked this up now because we custom source build postfix for our primary mail servers, but tend to use package versions for less important ( web/dns/usenet/etc ) servers since they do nothing but forward root mail to ops people.

gtk+-3.24.29
https://download.gnome.org/sources/g...3.24.29.tar.xz

I am not seeing this. My /etc/aliases was last modified November 20, 2017, it has never been over written since I modified it.

This one is kind of trivial, but may I suggest a minor tweak to the recent rc.S change relating to the conditional mounting of /proc:

Instead of checking /proc/self/mounts which has to resolve and traverse the process specific "self" symlink, I suggest checking ! -d /proc/sys. It's really not a big deal, but avoids a very small amount of unnecessary processing (not that anyone would notice the difference).

Also, IMO it would be nice to have the same style of check for the mounting of /sys to keep things consistent, rather than having to launch grep twice to look in the contents of /proc/filesystems and /proc/mounts.

suggested patch:
The above will assume that the kernel supports sysfs, but at this point I think that is pretty much a given, and even if it didn't, explicitly checking really doesn't serve much of a purpose as the mount will just harmlessly fail.

What about using stat which is a part of coreutils?

One-line check and it also guarantees that it is the correct filesystem type and not just any kind of directory (-d) or "something readable" (-r) at that path.

[ -d ] is a shell-builtin. I always try and avoid using external tools where possible. If you're gonna use an external tool anyway, then /bin/mountpoint might be the thing for the job (assuming it works without /proc being mounted: i'd have to check that).

rtkit-0.13 as dependency of pipewire and pulseaudio packages.
https://github.com/heftig/rtkit/releases/tag/v0.13

Good point about the shell-builtin. But /bin/mountpoint has more dependencies and would only check if "something" is mounted there and not if it is really the sysfs. So if we accept the overhead of an external tool, stat looks like the the better/safer solution to me compared to grep and mountpoint. Both stat and mountpoint work here when used inside a chroot without /proc.

proc is mounted by default on slackware in /etc/fstab

(proc /proc proc defaults 0 0)

How does making a symlink in /etc/postfix wipe out your /etc/aliases? I'm not seeing that happen here.

If what you mean is that you're creating an /etc/postfix/aliases *file* and that gets overwritten by the symlink, yes that's the current behavior. Is there a reason that you can't make your edits in /etc/aliases?

I respect your idea, but while stat does give one more certainty, IMO not needing to call external utilities is worth the trade-off. In my suggested patch, if /sys/kernel/ is not found, it'll mount sysfs on /sys. I'd argue that it's not unreasonable to assume that /sys will be empty if sysfs is not mounted this early in the boot process.

Another important scripts that I found using #!/bin/sh but use non-POSIX commands are /sbin/removepkg (extended globbing, pushd, and some other more), /sbin/pkgdiff (brace expansion), /sbin/makepkg (echo flags), /sbin/installpkg (brace expansion), and /sbin/pkgtool (passing arguments with the dot command). Probably need to be changed to #!/bin/bash too.

Thanks!

NFSv4 only server
 

Hi,

could an option to disable starting of these two services from /etc/rc.d/rc.nfsd:

be added? For example to /etc/default/nfs.

They are not required for NFSv4-only setups.

NFSv2 and v3 can already be nicely (cleanly) disabled with:

put in /etc/default/{nfs,rpc}.

To be NFSv4-only super-clean, it should be possible to not start rpc* services from /etc/rc.d/rc.rpc as well.

BTW:

is required and should be left as is in /etc/rc.d/rc.nfsd.

Thanks!

--
Best regards,
Andrzej Telszewski

Setup support for NFSv4
 

Hi,

currently, setup only supports NFSv3.

v3 is forced with:

in usr/lib/setup/INSNFS.

Could the protocol version forcing be removed to allow v4 as well?

--
Best regards,
Andrzej Telszewski

Suggestion (cosmetic)

Change line 20 in /etc/inittab
from:
# 4 = X11 with KDM/GDM/XDM (session managers)

to:
# 4 = X11/Wayland with SDDM/KDM/GDM/XDM (session managers)

or something more appropriate :)


Regards,
Fellype

P.S.: I haven't checked if this was already suggested before

Temporarily, may we revert back to file-5.39?

File 5.40 incorrectly detects XZ compressed data.

This has been noted in other distributions too:

https://bugs.gentoo.org/784773

https://bugs.archlinux.org/task/70261

Cups and usblp
 

Would it be possible to remove the blacklist of usblp from the file /lib/modprobe.d/cups-blacklist-usblp.conf
That would allow the use of the escputil command with "--raw-device /dev/usb/lp0" for getting ink levels etc., without having to copy the blacklist file to /etc/modprobe.d and comment out the blacklist line.

I also read in the CUPS/Troubleshooting ArchWiki web page (https://wiki.archlinux.org/index.php...roubleshooting) the following :

Warning: As of cups version 1.6.0, it should no longer be necessary to blacklist the usblp kernel module. If you find out this is the only way to fix a remaining issue please report this upstream to the CUPS bug tracker and maybe also get in contact with Till Kamppeter (Debian CUPS maintainer). See upstream bug for more info.

Thanks.

I'm going to drag this up one final time: Samba in -current is broken, and it's due to these options in samba.SlackBuild:"--with-system-mitkrb5" prevents Samba from being built against embedded Heimdal. This removes all AD DC functionality unless "--with-experimental-mit-ad-dc" is also specified, but as mentioned earlier in this thread, "experimental" in this case means "broken due to MIT KRB5 bugs, will not be fixed, will not receive security patches".

I don't know of any reason why these two build options can't simply be removed and "--builtin-libraries=heimdal" be put back in.

I've confirmed it on two machines with the latest postfix.

and postfix usually expects /etc/postfix/aliases, those used to postfix will normally be using that location.
slackwares version puts it in /etc and then symlinks it to /etc/postfix - wiping out the real version that postfix expects.

...and if you think I'm going to run around hundreds of servers changing it to /etc just to appease a difference in slackware, I can assure you, you're sadly mistaken

1) what's broken again?

2) let me know when Red Hat quits using those options... that will help convince me.

That's where it's always been, just looked at the default source confs which do reference /etc/aliases (back in the day I'm sure they didnt) it's why we (and about 50% others I asked on IRC) use /etc/postfix and not /etc

Perhaps the installer could look to see if /etc/postfix/aliases exists as a real_file, if so, don't create symlink?
That way nothing else would need changing.

Well I don't expect you too. Wow! you have hundreds of slackware servers? Amazing. I wish I had a tenth of that. ;)

I don't have a lot of changes in my /etc/aliases file. I don't claim to be an expert in postfix. Strange though that /etc/aliases is referenced a lot in the documentation.
From the /etc/postfix/main.cf file:
From man 5 postconf:
postconf -d output (-d Print main.cf default parameter settings instead of actual settings.):
From http://www.postfix.org/STANDARD_CONF...ON_README.html [Postfix on a local network]

Tried the new kernel 5.12.0 package in testing/
There'a a change in the config: CONFIG_DM_CRYPT=m, while on 5.10/11 it was =y.
Mkinitrd doesn't automatically add the dm-crypt module in the initrd, so the kernel won't boot anymore from encrypted volumes.

Please either add the module to mkinitrd (around line 650) or change the config back to CONFIG_DM_CRYPT=y; this last option will require some more config change, see this post: https://www.linuxquestions.org/quest...ml#post6236116

Samba AD DC
 

Good day,

According to RedHat documentation here https://access.redhat.com/documentat...pes-of-servers:

Samba can be used as AD DC with MIT KDC https://wiki.samba.org/index.php/Run...T_Kerberos_KDC ; however it still has some issues https://wiki.samba.org/index.php/Roadmap_MIT_KDC

I've been using Samba AD DC for the last 4 years in Slackware current, I rebuild the samba package with internal heimdal KDC and it is working properly on domain controllers and domain members.

I'm thankful having dnspython and krb5. in current :)

open-vm-tools-11.2.5 is essential to be a base package, imo.
https://github.com/vmware/open-vm-tools/releases

You can take Slackbuild from version 10.2.0 as an example, but I do not have enough knowledge to change it for the current version - both in the program and in Slackware itself there have been many changes since then.
https://slackbuilds.org/repository/1...open-vm-tools/

mcelog
 

Package mcelog installs /etc/rc.d/rc.mcelog, but nothing else in /etc/rc.d/* references it. (This was also pointed out here: https://www.linuxquestions.org/quest...mcelog-883391/)

This comment is wrong in /etc/rc.d/rc.mcelog:
It should be:
Currently in rc.local and rc.local_shutdown I have:

Would it make sense to start mcelog from one of the official startup scripts? (rc.S, I guess)

Note: I don't remember if rc.mcelog gets installed with the executable bit set or not. By the principle of least surprise, I think it would make sense to install it without the executable bit (or add it to the list during setup for the user to decide).

kernel-5.12.0 ACPI error
 

Upgrade testing 5.11.16 to 5.12.0
My bios MSI Z370 TOMAHAWK 7B47v19 date 2020-01-08

kernel-5.11.16 all ok

The Active Directory Domain Controller part of Samba. As mentioned, tt's considered "experimental" (link).I haven't checked, but I'd be surprised to learn that Red Hat uses the --with-experimental-mit-ad-dc build option, as their position is that they don't "support" using Samba as a Domain Controller. I'm sure they build Samba against system MIT Kerberos, as again, they don't care about AD DCs on Linux.

I have no idea why Red Hat would commit to a position where they are actively crippling their product in such a way that it cannot offer functionality that would directly compete with Windows Server and Microsoft's AD cloud offerings.

Ah thank goodness... I thought I did something wrong when I upgraded to /testing kernel
Thanks for the report ctrlaltca and the fix PV

Software I would like to see added to Slackware at some point, not necessarily to the next release, since it is imminent.

vile and xvile -- a solid and maintained editor which uses nvi as its vi reference implementation.

arno-iptables-firewall -- activated by default at setup. I do understand that no services run by default out of the box in Slackware, but the minute you install, sync and run sbopkg or sbotools -- as root -- you really do need a stateful firewall to ensure no trickery from sites like Sourceforge, where many of the SBo source files are hosted;

aria2 -- a clever download utility which allows you to download in parallel from multiple sources. Its only dependency is c-ares, which is now in -current.

icewm and openbox (with tint2 and jgmenu) -- for those among us who don't have much time for KDE and are getting increasingly tired of the direction Gnome is forcing GTK desktops like Xfce to move in.

Before you wasted your time on this copy paste you should have read my reply to Pat first :)