what should I try to catch?
I enclosed the first of the 16 trace file containing : "execve("/bin/su", ["su", "-", "sfs"]"

Attached Files

bash-du-trace.11004.txt (156.7 KB, 11 views)

Usually you'll look after errors in a trace.

I did a trace on my own on an up to date Slackware ARM -current, created a dummy sfs user (home in /home/sfs, part of users group, provided a password) and as root ran:
Got 10 trace files that I merged into bash-du-trace-merged.log (412K), which I compared with your merged bash-du-trace.11004.txt (160K)
Couldn't catch any interesting differences other than:
diff0.png - you have the extra bash-completion package installed and I don't, never did, try removing it (install it back after the test)
https://www99.zippyshare.com/v/DtSSbd5k/file.html
diff1.png - we match (meet) with the fortune cookies
https://www40.zippyshare.com/v/bj0I7FpC/file.html

Try to run a strace with bash 4.4 and one with 5.0 and compare them, maybe you can spot something that might trigger the password authentication request.

- remove of bash-completion didn't change anything.
- I enclosed the diff between the trace with bash-4.4 and bash-5.0, I didn't see anything.

Attached Files

bash-diff.txt (153.9 KB, 9 views)

Nobodino,

With latest SFS & 3 day old Slackware-current, the tools will not build.
Gets to bash and dies, with message "Can't find -lcurses, no such file or directory"
Haven't had time to do much investigating. Will keep working on it. Just wondering
if it had anything to do with your latest problem?

I don't think it's related. I built the tools/list1 and it's ok for me this night with the last updates.

regression test up to "Wed Jan 23 22:02:34 UTC 2019": problem with bison, it doesn't build anymore (SFS nor Slackware)
------------------------------
checking for bison... bison -y
checking for ranlib... (cached) ranlib
checking for GNU M4 that supports accurate traces... configure: error: no acceptable m4 could be found in $PATH.
GNU M4 1.4.6 or later is required; 1.4.16 or newer is recommended.
GNU M4 1.4.15 uses a buggy replacement strstr on some systems.
Glibc 2.9 - 2.12 and GNU M4 1.4.11 - 1.4.15 have another strstr bug.
-----------------------------

Can't reproduce - tested here on x86_64 -current, and bison built correctly.

strange same message in SFS and Slackware?
I'll look into it today.
thanks.

I reinstalled every package of the d Slackware series, and it solved the Slackware bison building.
Problem 'disapeared' on SFS at the same time...

Thanks to PV.

strange behavior with bash-5.0.xx, look at the size of the packages:
---------------------------
with bash-5.0.002-x86_64-2:
---------------------
root@drakstart64:/tmp/x11-build# ls -lat *.txz
-rw-r--r-- 1 root root 216 janv. 26 19:16 xorg-server-1.20.3-x86_64-1.txz
-rw-r--r-- 1 root root 660 janv. 26 19:16 xorg-server-xephyr-1.20.3-x86_64-1.txz
-rw-r--r-- 1 root root 844 janv. 26 19:16 xorg-server-xvfb-1.20.3-x86_64-1.txz
-rw-r--r-- 1 root root 748 janv. 26 19:16 xorg-server-xnest-1.20.3-x86_64-1.txz
---------------------
with bash-4.4.023-x86_64-1:
---------------------
root@drakstart64:/tmp/x11-build# ls -lat *.txz
-rw-r--r-- 1 root root 1747312 janv. 27 09:12 xorg-server-1.20.3-x86_64-1.txz
-rw-r--r-- 1 root root 856048 janv. 27 09:11 xorg-server-xephyr-1.20.3-x86_64-1.txz
-rw-r--r-- 1 root root 720504 janv. 27 09:11 xorg-server-xvfb-1.20.3-x86_64-1.txz
-rw-r--r-- 1 root root 597032 janv. 27 09:11 xorg-server-xnest-1.20.3-x86_64-1.txz
---------------------
when you look at the size of the binaries built:
---------------------
root@drakstart64:/tmp/x11-build/package-xorg-server/usr/bin# ls -la
total 2020
drwxr-xr-x 2 root root 4096 janv. 27 09:11 ./
drwxr-xr-x 9 root root 4096 janv. 27 09:11 ../
-rwxr-xr-x 1 root root 18480 janv. 27 09:11 cvt*
-rwxr-xr-x 1 root root 14312 janv. 27 09:11 dmxaddinput*
-rwxr-xr-x 1 root root 14304 janv. 27 09:11 dmxaddscreen*
-rwxr-xr-x 1 root root 14376 janv. 27 09:11 dmxinfo*
-rwxr-xr-x 1 root root 14312 janv. 27 09:11 dmxreconfig*
-rwxr-xr-x 1 root root 14304 janv. 27 09:11 dmxresize*
-rwxr-xr-x 1 root root 14304 janv. 27 09:11 dmxrminput*
-rwxr-xr-x 1 root root 14304 janv. 27 09:11 dmxrmscreen*
-rwxr-xr-x 1 root root 43264 janv. 27 09:11 dmxtodmx*
-rwxr-xr-x 1 root root 14440 janv. 27 09:11 dmxwininfo*
-rwxr-xr-x 1 root root 18440 janv. 27 09:11 gtf*
-rwxr-xr-x 1 root root 30800 janv. 27 09:11 vdltodmx*
-rwxr-xr-x 1 root root 1740008 janv. 27 09:11 Xdmx*
-rwxr-xr-x 1 root root 64640 janv. 27 09:11 xdmxconfig*
-rwxr-xr-x 1 root root 273 janv. 27 09:11 Xorg*
------------------
the binaries are built but not put in the packages ?

update: Once the xorg-server drivers installed, the other packages don't fail to build (in SFS and slackware).

problem with x11-server solved in -current, x11.SlackbBuild modified.
Thanks to PV.

Am now rebuilding SFS (again!)

Have two problems from last rebuild,

1) Snownews would not compile. That may have been caused by the x11-server problem, I'm trying again.

2) While building the tools for SFS, bash would not build. It got to a link stage and gave a message:
ld: Cannot find -lcurses, no such file or library.

I agree that it cannot find libcurses.so. We specifically did not build that library.
Searching the Internet, I found similar problems. Mostly in SUSE. Not much use because the cure was to install the appropriate developmental rpms.
Not much help with Slackware. Maybe I'm misunderstanding the problem. If anyone has seen this on Slackware, I would appreciate hearing what you
did about.

Well that didn't work so well. Not sure what I did, but managed to mess up the edit to my last post.

It was supposed to be:

To compile bash for the tools, In sfs-tools-current.sh, function ncurses_build, I changed the line:

cd /mnt/sfs/tools/lib && ln -sf libncursesw.so libcursesw.so
to
cd /mnt/sfs/tools/lib && ln -sf libncursesw.so libcursesw.so && ln -s libcursesw.so libcurses.so

It worked, maybe fortuitously.

Did you get the last scripts? I had no problem building the tools today.

regression test up to "Fri Feb 1 05:53:41 UTC 2019": glibc-2.29 didn't introduce any show stopper, it's a big surprise to me!
------------------------
I have only 4 kde packages not building with SFS (kopete, krfb, ksirk and okular) but they build normally in slackware64-current.
They weren't building last week before glibc-2.29 arrival.
------------------------
/usr/bin/ld: /usr/lib64/lib64/libpthread.a(libpthread.o): .preinit_array section is not allowed in DSO