@nobodino:

I wonder if you are on the way to rebuild with gcc10.
For some reason i'm currently re-building a lot of packages from -current, maybe we can share some necessary fixes.
e.g. the following builds need the additional CFLAG "-fcommon" to build:

cpio
dhcp
floppy
gdbm
gnuchess
gnupg
gpm
lilo
netatalk
procps-ng
seyon
sharutils
squashfs-tools
tftp-hpa

Do you have some packages you're stuck on currently?

Well I'm on the way, you can look here to see which packages need extra packages:
https://github.com/nobodino/slackwar...es_for_current

and also here:
https://github.com/nobodino/slackwar...ter/glibc-2.32

Glad to see someone trying SFS. Welcome on board!

sfs-tools-current doesn't build currently, because of glibc. It builds on Slackware, but I can't build new "tools".

1 members found this post helpful.

regression test up to "Wed Dec 30 21:56:42 UTC 2020": (x86_64 version)

4 packages fail totally to build: mlt, seamonkey, firefox and thunderbird (the last two packages should have problems solved with the new rust-1.49).
Some others need patch (mainly "-fcommon" option due to gcc-10.2.0), follow link: https://github.com/nobodino/slackwar...es_for_current
Some others are not compatible with autoconf and automake or both of them: motif, gtk+2, vorbis-tools, hunspell.

regression test up to "Mon Jan 18 13:50:16 UTC 2021": (x86_64 version) with glibc-2.32 and rust-1.49.0.

Everything builds fine with absolutly no regression.

It's like a 'mass rebuild' with glibc-2.32 just before it should happen soon, built in about 27 hours.

I rebooted in this new environment, and it works as 'normal Slackware'.

1 members found this post helpful.

regression test up to "Mon Feb 1 21:53:09 UTC 2021": (x86_64 version) with glibc-2.33.

Everything builds fine with absolutly no regression in one single shot.

It's like a 'mass rebuild' with glibc-2.33, built in about 26 hours.

It's the first time, I've seen a new glibc release that doesn't show any regression in Slackware.

I've rebooted in this new environment, and it works as 'normal Slackware', as usual.

I send this message from that system with glibc-2.33.

Slackware is not dead.

Happy "Slackware" to everyone.
----------------------
--- list-slackware 2021-02-03 04:50:06.855071573 +0100
+++ list-sfs 2021-02-03 14:02:37.660810196 +0100
@@ -35,7 +35,7 @@
a/gawk-5.1.0-x86_64-2.txz
a/genpower-1.0.5-x86_64-4.txz
a/gettext-0.21-x86_64-2.txz
-a/glibc-solibs-2.32-x86_64-1.txz
+a/glibc-solibs-2.33-x86_64-1.txz
a/glibc-zoneinfo-2021a-noarch-1.txz
a/gpm-1.20.7-x86_64-8.txz
a/gptfdisk-1.0.6-x86_64-2.txz
@@ -711,9 +712,9 @@
l/glade-3.38.2-x86_64-2.txz
l/glib-1.2.10-x86_64-8.txz
l/glib2-2.66.4-x86_64-2.txz
-l/glibc-2.32-x86_64-1.txz
-l/glibc-i18n-2.32-x86_64-1.txz
-l/glibc-profile-2.32-x86_64-1.txz
+l/glibc-2.33-x86_64-1.txz
+l/glibc-i18n-2.33-x86_64-1.txz
+l/glibc-profile-2.33-x86_64-1.txz
l/glibmm-2.64.5-x86_64-2.txz
l/glib-networking-2.66.0-x86_64-2.txz
l/gmime-3.2.7-x86_64-3.txz

@nobodino, that is awesome news! Thanks for all the things you are doing for Slackware.

Now I guess we will soon be seeing that second mass rebuild Pat mentioned.

Yeah, x86_64 went great here as well with no apparent problems. So where's that new glibc, you might ask?

Well, the build seemed to go well on x86 with no compile failures, but something about the new glibc kills sshd on 32-bit. I suspect it's a lack of some function or another in the privsep sandbox (it's happened on other architectures with a new glibc before), but have not been able to track down the issue yet. And I'm a bit surprised that Google isn't revealing anyone else running into this yet.

Planning to put the new glibc into /testing with a warning about this situation. As always, any help figuring out a solution is welcomed.

1 members found this post helpful.

Well, I haven't built x86 version for some time now.
I'll see if I've still one system up to date and try to build SFS on x86, but not before tomorrow.

I've found this concerning openssh8.4p1/regress/connect-privsep.sh
----------------------------------------------
# $OpenBSD: connect-privsep.sh,v 1.9 2017/04/30 23:34:55 djm Exp $
# Placed in the Public Domain.

tid="proxy connect with privsep"

cp $OBJ/sshd_proxy $OBJ/sshd_proxy.orig
echo 'UsePrivilegeSeparation yes' >> $OBJ/sshd_proxy

${SSH} -F $OBJ/ssh_proxy 999.999.999.999 true
if [ $? -ne 0 ]; then
fail "ssh privsep+proxyconnect failed"
fi

cp $OBJ/sshd_proxy.orig $OBJ/sshd_proxy
echo 'UsePrivilegeSeparation sandbox' >> $OBJ/sshd_proxy

${SSH} -F $OBJ/ssh_proxy 999.999.999.999 true
if [ $? -ne 0 ]; then
# XXX replace this with fail once sandbox has stabilised
warn "ssh privsep/sandbox+proxyconnect failed"
fi

# Because sandbox is sensitive to changes in libc, especially malloc, retest
# with every malloc.conf option (and none).
if [ -z "TEST_MALLOC_OPTIONS" ]; then
mopts="C F G J R S U X < >"
else
mopts=`echo $TEST_MALLOC_OPTIONS | sed 's/./& /g'`
fi
for m in '' $mopts ; do
env MALLOC_OPTIONS="$m" ${SSH} -F $OBJ/ssh_proxy 999.999.999.999 true
if [ $? -ne 0 ]; then
fail "ssh privsep/sandbox+proxyconnect mopt '$m' failed"
fi
done
--------------------------------------------
I don't know if this indication can help?

I've not tested it myself but this could be related?

Yes, that was the "it's happened on other architectures with a new glibc before". :-)

Is it a problem on multilib? I could throw it on my laptop and see what's up. We've got a number of things to ssh into around here.

I doubt you'd see the issue on multilib unless you're starting the 32bit version of sshd (which openssh, the package including sshd, isn't a package that Alien Bob provides as a compat32 package, although you could always try converting it using convertpkg-compat32 and run the 32bit binary and see if you can replicate the issue).

If I have time this weekend, I'll see if I can reinstall. The laptop was a bit fussy to get a distro on it, to begin with, though. :/

Misunderstood the issue; comment describing connecting *from* a 32-bit VM was therefore useless.

Attempting to connect *to* the VM after the glibc/openssh upgrade gave an immediate "connection closed."