I will try to build plasma5 on top of slackware64-current.
Wait and see.

failed on json-glib:
------------------------
json-glib-1.4.2/NEWS
ERROR: Command 'mesontest' not found
json-glib failed to build.

real 208m14,237s
user 1067m9,416s
sys 74m10,851s
------------------------
replaced by json-glib from slackware64-current (1.4.4 and SlackBuild) and it works.

second failure on libindicator:
--------------------
/usr/bin/ld: cannot find -lglib-2.0-lm
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:489: libindicator.la] Error 1
make[3]*: on quitte le répertoire «*/tmp/libindicator-12.10.1/build-gtk2/libindicator*»
make[2]: *** [Makefile:417: all] Error 2
make[2]*: on quitte le répertoire «*/tmp/libindicator-12.10.1/build-gtk2/libindicator*»
make[1]: *** [Makefile:358: all-recursive] Error 1
make[1]*: on quitte le répertoire «*/tmp/libindicator-12.10.1/build-gtk2*»
make: *** [Makefile:288: all] Error 2
libindicator failed to build.
--------------------

I'm not working on Plasma5, but am continuing with SFS.

Slackware-current, 2018-12-21, built perfectly. Tomorrow, I'll see if it works!

Merry Christmas to all and a happy New Year!

regression test up to "Fri Dec 28 00:23:43 UTC 2018": everything builds ok, once more.
It has never been so easy to build Slackware from scratch.

regression test up to "Fri Jan 4 21:44:44 UTC 2019": everything builds ok.
But the time to build increases dramatically:
------------------
on 10/08/2018: 910 mn
on 03/11/2018: 1075 mn
on 06/01/2019: 1500 mn
------------------
any idea?

NUMJOBS used to be hardcoded to 7, but in September was changed to be equal to the number of CPU threads plus one. Perhaps exporting NUMJOBS=7 would restore the previous compile times on your system?

Would it make any sense to make it like this (from Idlemoor's slackrepo):

Skaendo,

I tried your suggestion (from Idlemoor's slackrepo):

It worked OK. Here are the times for the Slackware current builds shown for the below dates:

Date compiled: 20181223 20190110
build1_s.list 299m2.547s 320m7.329s
build2_s.list 654m1.144s 650m46.642s
build3_s.list 489m43.212s 520m19.714s
build4_s.list 944m57.083s 931m59.605s

So two of the times to process a list increased, two decreased. I liked the suggestion, though!

strange behavior of bash-5.0 in prep-sfs-tools.sh (SFS):
-------------------------------
---------------
'return 1' doesn't work anymore. It's stuck, even CRTL-c doesn't allow to kill the script?
'return 0' and 'return 2' are ok.
If I revert to bash-4.4.0023, it works again.
I've read that all functionalities of bash-5.0 are only available with readline-8.0, could it be related to this or something else?

What if I want to build Slackware (From Scratch) for i686 instead of i586?

I am curious about how behaves a "pure" i686 Slackware compared with the official one.

Then, my question: SFS permits me to slightly change the architecture?

I think you may have to edit every single SlackBuild to change ARCH:
-----------
if [ -z "$ARCH" ]; then
case "$(uname -m)" in
i?86) ARCH=i586 ;;
arm*) readelf /usr/bin/file -A | egrep -q "Tag_CPU.*[4,5]" && ARCH=arm || ARCH=armv7hl ;;
# Unless $ARCH is already set, use uname -m for all other archs:
*) ARCH=$(uname -m) ;;
esac
export ARCH
fi
---------
ARCH=i586 to ARCH=i686
If you may do it by hand, with awk/sed it should be possible?

for this specific case (i586 -> i686) consider also this

https://www.linuxquestions.org/quest...9/#post5406886

regression test up to "Fri Jan 18 04:39:25 UTC 2019": pb with liblastfm
---------------------------
liblastfm-1.0.9/demos/demo1.cpp
liblastfm-1.0.9/demos/demo3.cpp
liblastfm-1.0.9/demos/demo2.cpp
liblastfm-1.0.9/CMakeLists.txt
liblastfm-1.0.9/README.md
CMake Error: No source or binary directory provided
make: *** No targets specified and no makefile found. Stop.
make: *** No targets specified and no makefile found. Stop.
---------------------------
same problem on Slackware and SFS.

Is anyone else having troubles with "su" on Slackware-current?

Action in past (as superuser): su - username
Result: logged in as username

Slackware-current as of Friday, 20190118: su - username
Result: if called from terminal, requests password. If called from script stops dead in terminal used.

I can't find this problem on the net and have run out of places to look. Advice needed.

TIA

@worsel

If PAM is involved, this might help:
https://www.linuxquestions.org/quest...ssword-560989/

I only run -current on ARM and need to update it, but first I need to change the SDCard on the test box. Will try to replicate this, although I don't have PAM.

@abga

Slackware doesn't use PAM. Thanks for replying.

Worsel: have you seen my post #510?

You're welcome. I know it doesn't that's why I put if in front of the question (not a statement).
Work on PAM has been done:
http://www.slackware.com/~vbatts/pam/
And is still ongoing, unofficially:
https://github.com/Dlackware/pam
I asked about PAM, because of the nature of this thread (development, testing, goofin' around) and unable to "find this problem on the net" myself, but only the link I provided, related to PAM.

Now, I did change the SDCard on my Raspberry Pi running Slackware ARM -current, the old card went read-only - complete failure, updated the system and was unable to replicate your reported issue, whatever I tried, neither in console, nor in a script. Which leads me to believe that you might have some issues on your system: /etc/passwd* or data corruption related.
Try switching the user by also providing the shell type:
and see if it works, if positive, check your /etc/passwd* for inconsistencies.

If negative, I'd suggest to start a new thread dedicated to this, authentication issues are serious issues and need further investigation.

P.S. To exclude bash, as nobodino has apparently found some issues with it, try:

On a clean uptodate slackware-current I do not see this weird "su -" behaviour.

neither "/bin/su - sfs -s /bin/bash"

nor "/bin/su - sfs -s /bin/sh",

nor the old command "su - sfs"

works. It's blocked nowhere (see enclosed screen capture).

root@drakstart64:~/scripts# more /etc/passwd | grep sfs
sfs:x:1000:1000::/home/sfs:/bin/bash

If I revert to bash-4.4.023, everything is ok.

I modified the script prep-sfs-tools so that the operator enter 'su -f sfs' manualy.

nota: liblastfm solved in -current :)

Yes, but somehow didn't relate it to this problem. Mea culpa!

I was looking into this, but hadn't got it to work. Will try it today.

My fault, to entirely exclude bash would have required to start as root with /bin/sh, because otherwise you'd be already using bash...
Your /etc/password entry is valid and I'm happy you found out that bash 5.0 was causing the issue.

Don't know how could bash cause such an issue, by not passing the right arguments to su (which is part of the shadow package)?
Try running a strace as root under bash 5.0:
and see if you can catch something. Prepare a second tty to be able to kill the strace as it might get the tty locked.

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

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.

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

Yes. Scripts were downloaded 2019-01-31. Slackware-current was rsynced on the same date.

Currently, the problem with bash in the tools directory still exists. The build has reached
firefox and is doing fine. Will post when it is finished.

Okay, the latest build just finished here. It looks like everything built, although nothing from X or kde
was saved in /var/log/packages, plus the problem with bash while building tools. Will do further checking and rebuild.

have you looked at: kopete, krfb, ksirk and okular?
kde doesn't stop when it fails.

According to my test program, they did not install. I don't recall if they actually did or not.
I only sampled a few programs that showed as not installing, but actually did. There were several
items outside of X and kde that also showed as not installing, but actually did.

Unfortunately, I started a new build last night and am currently overwriting that partition.
Will check more closely when the current build finishes

Okay, finally got the internet back. Snow storm here yesterday. Don't know what happened,
but I'll bet somebody slid off the road and took out a bunch of cables. The internet was
down until early this morning.

kopete, krfb, ksirk, and okular did not build. Everything else did according to my test program,
although in functions build_kdei and build_calligra, nothing was installed. The packages were
saved in sfspacks/kdei, however.

Also, while running sfs, the internet connection is down, even with the appropriate files copied from Slackware-current
where it works.

Oh, Slackware-from-Scratch and Slackware-current both downloaded 2018-02-02.

re: Problem with kopete, krfb, ksirk, and okular

When trying to build okular from the new sfs partition, I came across the following error(s):

Where did /usr/lib64/lib64 come from? I doesn't seem to exist in Slackware-current and I don't see
a recognizable generator in sfsbuild1.sh.

- libpthread.a is in /usr/lib64, there's a 'lib64' in excess, where does it come from?
- the last time I had a complete build without failure is 04/01/2019

Something happened during that date (04/01/2019 and 01/02/2019) and now? But what?
- I verified every git commit between the 2 dates, nothing that could explain the new behaviour

The question in my last post was somewhat rhetorical. I figured that if you had an
answer, it would already have been fixed.

It's 8 pm here now, so I probably won't get anything done tonight. ( I was gone all day today,
so no progress here :) ). I'll look into it tomorrow.

I've found the culprit its' aaa_elflibs:
- changed on 05/01/2019
- bash-5.0 came in on 11/01/2019
- has double 'lib64'
- the size is not the right size (twice as it should be)

I reverted to bash-4.0.23 and everything is ok.
While building with bash-5.0 in real slackware there's no problem, but in chrooted environment it's a mess...