Requests for -current (14.2-->15.0)

chrisretusn · 02-14-2020, 10:07 AM

Quote:

Originally Posted by GazL

Code:

# Ensure that ENV_SUPATH from /etc/login.defs is used for the $PATH when
# 'su' is used. Otherwise /sbin paths will be missing unless 'su -' is used.
ALWAYS_SET_PATH yes

The traditional way su behaves allows a user to run a process with elevated privilege in either the same execution environment as they're currently using (potentially with a custom PATH) or within a new one (appropriate to the su'd to user). This change breaks that.
<snip>

Please, reconsider this one.

Yes, please reconsider.

allend · 02-14-2020, 10:47 AM

I would like to suggest a patch to /usr/libexec/slackpkg/install-new.awk

Code:

--- install-new.awk.orig	2012-07-23 04:21:33.000000000 +1000
+++ install-new.awk	2020-02-15 03:30:03.618555298 +1100
@@ -1,4 +1,4 @@
-/^(a|ap|d|e|f|k|kde|kdei|l|mac|n|t|tcl|x|xap|xfce|y)\/([a-zA-Z0-9_\+.\-]+):.* ([Aa]dded|[Ss]plit|[Rr]enamed|[Mm]oved|[Nn]ame [Cc]hange|NAME CHANGE|[Ss]witched).*/ {
+/^(a|ap|d|e|f|k|kde|kdei|l|mac|n|t|tcl|testing.*|x|xap|xfce|y)\/([a-zA-Z0-9_\+.\-]+):.* ([Aa]dded|[Ss]plit|[Rr]enamed|[Mm]oved|[Nn]ame [Cc]hange|NAME CHANGE|[Ss]witched).*/ {
 	INPUT=$1
 	fs=FS
 	FS="/" ; OFS="/"

I should have followed the procedure in the ChangeLog, but instead I used slackpkg with 'PRIORITY=( testing patches %PKGMAIN extra pasture )' in slackpkg.conf
Without the patch, 'slackpkg install-new' did not offer three new PAM packages, leading to an update where PAM did not allow a login without libpam.so.0
Live and learn!

upnort · 02-14-2020, 11:30 AM

Quote:

The traditional way su behaves allows a user to run a process with elevated privilege in either the same execution environment as they're currently using (potentially with a custom PATH) or within a new one (appropriate to the su'd to user). This change breaks that.

I don't know if this change is related, but in Debian 10 the su behavior drives me batty. Typing su - does NOT inherit the DISPLAY environment variable.

When I type su - I expect a full root environment and not a crippled environment. Whether using X as root is my decision to make and not anybody upstream.

Quote:

the PAM-ified util-linux also needs to provide su, chsh, chfn, nologin, vipw and vigr utilities instead of having them in the shadow package

I think other distros do that too.

volkerdi · 02-14-2020, 12:21 PM

Quote:

Originally Posted by GazL

Please tell me you didn't change this traditional UNIX behaviour just because some users aren't educated enough to use 'su -' or 'su -l'. If the commented explanation in the defaults file is the only reason for this change and you still feel you have to pander to these users then I'd rather you just put /sbin in the default non-root users path.

Actually, the main reason I changed it is because that's the way the upstream shadow defaults for su have worked in Slackware since at least Slackware 13.0. I cling to my own traditions much more closely than I do to those of UNIX, to be honest.

GazL · 02-14-2020, 05:30 PM

Ok, thanks Pat. Somehow I managed to miss that. I still don't like it as a default, but I can't complain if you're just maintaining the status quo. I'll just change the option locally then. Apologies for the noise.

USUARIONUEVO · 02-15-2020, 02:39 AM

Hi , again , first of all , thanks for including finally qt5 to start migration to plasma , i have one question and 2 suggests.

my questions, is arround openal , we habe 1.19.1 , but i see 1.20.1 in the github , reason to provide 1.19 is for some build problem ? or only miss ?
https://github.com/kcat/openal-soft/releases

And my 2 little suggestions , after including qt5 , i think this 2 little tools are good to have

qt5ct , and qt5pluginstyles , this two little packages are similar to qtconfig under qt4

see
http://slackbuilds.org/repository/14.../?search=qt5ct
http://slackbuilds.org/repository/14...-styleplugins/

at least qt5ct , for configurations under qt5.

Thanks!.

Skaendo · 02-15-2020, 03:24 AM

ffmpeg could now be built with "--enable-openal"

Might I also suggest to maybe update the ffmpeg SlackBuild to the one called "ffmpeg4", here:
https://slackbuilds.org/repository/1...search=ffmpeg4
It is just a little more geared towards the 4.x builds of ffmpeg.

And a request, could libmysofa (https://github.com/hoene/libmysofa/) be added with openal-soft and ffmpeg built with it?
libmysofa is autodetected with openal-soft, and with "--enable-libmysofa" for ffmpeg.

Thanks and thanks for qt5, libxkbcommon and openal-soft!!

_gin · 02-15-2020, 03:40 AM

Mr Volkerding, Will you consider removing the htdig package to favor hldig instead?

To my knowledge, there's no more development involved in htdig whereas hldig is a maintened fork.
https://github.com/solbu/hldig

Thanks for Qt5 by the way.

tramtrist · 02-15-2020, 03:52 AM

Now that PAM is in.. how about libfprint?

GazL · 02-15-2020, 05:31 AM

The pam security modules are arch depenendent. Shouldn't they be in /lib64/security on a 64bit Slackware, leaving /lib/security for multilib/32bit PAM implementations?

chrisVV · 02-15-2020, 05:52 AM

Quote:

Originally Posted by GazL

The pam security modules are arch depenendent. Shouldn't they be in /lib64/security on a 64bit Slackware, leaving /lib/security for multilib/32bit PAM implementations?

kernel modules are architecture dependent but are (and as far as I am aware always have been) in /lib/modules. Are PAM plugins relevent to multilib systems: does anything other than PAM actually load them?

GazL · 02-15-2020, 06:46 AM

Quote:

Originally Posted by chrisVV

kernel modules are architecture dependent but are (and as far as I am aware always have been) in /lib/modules. Are PAM plugins relevent to multilib systems: does anything other than PAM actually load them?

I'd expect any 32bit pam-enabled application to need a 32bit pam implementation. Someone please correct me if I am wrong.

GazL · 02-15-2020, 09:40 AM

Running cryptsetup luksFormat with default options on current results in a warning about a missing /run/cryptsetup directory. Can I suggest adding its creation to rc.S.

edit: got the name slightly wrong, sorry.

chrisVV · 02-15-2020, 10:22 AM

Quote:

Originally Posted by GazL

I'd expect any 32bit pam-enabled application to need a 32bit pam implementation. Someone please correct me if I am wrong.

You are probably right.

volkerdi · 02-15-2020, 02:41 PM

Quote:

Originally Posted by USUARIONUEVO

my questions, is arround openal , we habe 1.19.1 , but i see 1.20.1 in the github , reason to provide 1.19 is for some build problem ? or only miss ?
https://github.com/kcat/openal-soft/releases

Any version newer than what we have won't compile, and I see the same issues occurring with other distributions as well.