Requests for -current (14.2-->15.0)

Qury · 02-20-2020, 05:13 AM

I would like to request the addition of the below 2 lines to /etc/request-key.conf.

Code:

create cifs.spnego * * /usr/sbin/cifs.upcall -c %k
create dns_resolver * * /usr/sbin/cifs.upcall %k

(Alternatively a .conf file with the above contents could be added under /etc/request-key.d/ )

Justification:
It is required to mount DFS shares.

See: https://access.redhat.com/solutions/45070

USUARIONUEVO · 02-20-2020, 07:58 AM

Its possible add another request by some people ? "jack" , i say some time ago , jack is required by recordmydesktop to configure extra audio fonts , but ignored ever , now current is adopting some new libs , i request again "jack".

In recordmydesktop "gui" , at least under gtk-gui , you can choose audio font , system or micriphone to record tutorials , but need "jack".

Thanks!

orbea · 02-20-2020, 09:12 AM

Quote:

Originally Posted by GazL

My take from reading those KSH issue threads is that, yes 93u+ is old and bit rotten, but it's the same old and bit rotten version that commercial unixes have been shipping for years. If you want compatibility then it's the version you want. The recent development has stemmed from the incomplete and buggy 93v- (beta) branch which AT&T didn't finish before sacking everyone involved and ceasing development on it. ksh2020 is a descendent of 93v- and while some of the issues from that release have been addressed it seems that many in the community still prefer 93u+ (which is why they rolled the repo master branch back).

Controversy seems to have kicked in because in addition to fixing the issues stemming from 93v- the developers have been changing behaviours of ksh rather than just maintaining/cleaning up the code and some parts of the ksh community really didn't like that aspect.

Now, I'm an outsider so my take is based entirely on what I've read in those issue threads and it's possible I misunderstood something, but I think that's the general gist of it. The whole thing is a mess and it's really sad to see.

looks like freebsd are going to stick with 93u+

There isn't much of a community left, its just a few loud mouth people who don't have anything worthwhile to add that are driving this. They bluntly have 0 chance of resurrecting ksh93u+. Additionally ksh2020 will not move forward unless the two developers who are now alienated continue work on it, its a difficult code base and there are few (Now 0) skilled people willing to work on it. The reality is that they introduced countless regressions, now have a repo that won't even build on current and has an outright appalling build system by today's standards. While maybe there might be more bug compatibility with old, unmaintained and broken scripts, they lost all compatibility with people using ksh in 2020.

Also while Freebsd has gotten it to build by resurrecting old patches, they haven't committed one way or another yet.

https://github.com/att/ast/issues/96...ment-588606205

slalik · 02-20-2020, 10:24 AM

ProFTPD 1.3.6c

camerabambai · 02-20-2020, 01:21 PM

A request for PAM in testing, why not add the pam_krb5 and pam_ldap modules?
They are needed in case of external auth(ad,ldap server)

garpu · 02-20-2020, 03:31 PM

Quote:

Originally Posted by USUARIONUEVO

Its possible add another request by some people ? "jack" , i say some time ago , jack is required by recordmydesktop to configure extra audio fonts , but ignored ever , now current is adopting some new libs , i request again "jack".

In recordmydesktop "gui" , at least under gtk-gui , you can choose audio font , system or micriphone to record tutorials , but need "jack".

Thanks!

http://www.slackware.com/~alien/slackbuilds/jack2/

camerabambai · 02-20-2020, 04:52 PM

A great idea for the kernel package.
Every time the slackpkg tool, or slackyd, or slapt-get upgrade the kernel
only ask for "lilo", but if someone use grub or elilo?
Personally I use this "doinst.sh" which works fine for me(using grub), of course is simple and can be improved may adding some other choices for other "loaders".

Code:

#!/bin/sh
set -e
VERSION=$(ls /var/log/packages/kernel-generic-*-x86_64-* |cut -d - -f 3)
cp  /boot/vmlinuz-generic-$VERSION /boot/vmlinuz
cp  /boot/System.map-generic-$VERSION /boot/System.map
if [ -f /etc/mkinitrd.conf ]
then
mkinitrd -F
fi
grub-mkconfig -o /boot/grub/grub.cfg

Another problem is..if an user reboot and forget to do mkinitrd process and grub update the system is unbootable and is necessary to use live-cd or slackware-cd to use the recovery shell, mount fs
and did the mkinitrd+updatebootloader process.
All distro(Fedora, Debian) make this process automatic after the kernel upgrade.

Didier Spaier · 02-20-2020, 05:36 PM

Quote:

Originally Posted by camerabambai

All distro(Fedora, Debian) make this process automatic after the kernel upgrade.

So does Slint, but the script upgrade-kernel has to be run by the user for now. This certainly can't be applied as is in genuine Slackware as we use utilities not shipped in Slackware, and enhancements are needed and planned, but this works and you get the idea.

saxa · 02-20-2020, 08:05 PM

I do also agree to add a kind of mechanism to improve the bootloader update. I forget it many times.

rworkman · 02-20-2020, 10:51 PM

At least in slackpkg, I don't like the idea of trying to update bootloader automatically, at least not with the present state of -current (I'm not suggesting that anything is in the works, but I also am not ruling out the possibility that future changes to -current would change my preference), so the 2.84.0_beta builds change that up a bit and require a keypress to confirm new kernels. There are quite a few other changes in the beta builds, so check out the changelog, adjust configs as needed, and test it out, please! https://slackpkg.org/

nullptr · 02-21-2020, 02:51 AM

I am against the idea of automatically reconfigure bootloader since I am using EFIStub.

Didier Spaier · 02-21-2020, 03:07 AM

Quote:

Originally Posted by nullptr

I am against the idea of automatically reconfigure bootloader since I am using EFIStub.

But that's exactly what you do when you rebuild your kernel as it loads itself

allend · 02-21-2020, 09:03 AM

Quote:

I do also agree to add a kind of mechanism to improve the bootloader update. I forget it many times.

The mechanism has long been in existence in slackpkg. All that is required is to create a new executable file in /usr/libexec/slackpkg/functions.d/ that lexicographically sorts after the file containing the original code.
For lilo, I have been using my run-mkinitrd-function.sh for many years.
For elilo and lilo, @zerouno recently posted his zlookkernel.sh.
For grub, @drgibbon has posted a patch and supporting config.

I see that @rworkman is maintaining the stance that slackpkg should not, by default, support trying to update bootloader automatically. Given the many bootloaders in use and the subtle problems that arise when trying to automatically update an initrd (are the supporting kernel modules available?, is mkinitrd.conf in use?) as well as other potential use cases I have likely not considered, then I accept this stance.

However, I would like to see the ability made available to the Slackware community. Rather than hunting through this forum, perhaps we could have example scripts for enhanced slackpkg functionality made available in /testing. I am old enough to remember that slackpkg resided in /testing for many releases before it became an official tool.

Alien Bob · 02-21-2020, 09:24 AM

Quote:

Originally Posted by allend

However, I would like to see the ability made available to the Slackware community. Rather than hunting through this forum, perhaps we could have example scripts for enhanced slackpkg functionality made available in /testing. I am old enough to remember that slackpkg resided in /testing for many releases before it became an official tool.

Like slackpkg+, this bootloader related functionality can be created as a slackpkg extension and maintained in a 3rd party repository. The only thing that's required is a person who wants to dedicate himself/herself to this.
What we do not need is an un-maintained solution that eventually breaks and causes more harm than being useful.

Chuck56 · 02-21-2020, 11:00 AM

I support automated updates of bootloaders with a big HOWEVER...

Automated updates of bootloaders require non-standard changes to a few non-slackpkg elements (e.g. mkinitrd.conf, lilo.conf, elilo.conf). Some Slackware users welcome standardization while others welcome freedom of configuring their own systems as they see fit.

A Slackware user that relies on slackpkg leans more toward automation. I'm in that camp and why I released "autoslackpkg" at Slackbuilds.org. It wraps around slackpkg and offers bootloader updates for LILO and ELILO users. It's not for everyone but shows one method to automate bootloader updates.