That which could be fixed in SBo thread.

Originally Posted by ReaperX7 Any other packages in need of some TLC? One I know of is Higan. Higan still has issues detecting the libananke.so library after installation on the path. The developer seems to also have halted the project as well developmentally. This leaves the software loader/importer inoperable. Does anyone know of any patches other than the pulseaudio removal patch? I know it works on FreeBSD so maybe the ports there have an answer???

Checked Slackware64-current in a VM as well. No problems encountered.

And kelbt is available at http://www.colm.net/files/kelbt/.

Not sure how long until KDM becomes obsolete, but having it in sbo as alternative would be great.
I have tried SDDM in current, I'm not impressed by fancy animations and a lack of configuration options.

SDDM doesn't have the "no theme" and "no compositing" option, or at least I couldn't find any.

SDDM switches my monitor off/on 5 times before displaying a login prompt, for no good reason.
Probably something to do with nvidia binary and a lack of DPMS on my end.

SDDM doesn't support export KDEWM, so I guess it's just plasma+kwin or no KDE at this point.
That one is probably fixable in startkde script, I will try to look into it later this year.

In conclusion, I suggest KDM-legacy, or some sort of replacement for the upcoming SDDM.
Either that, or I guess I'm switching back to XDM as soon as KDM is officially dropped.

Originally Posted by elcore Not sure how long until KDM becomes obsolete

KDM has become obsolete with the end of KDE 4.
That means, it is not obsolete in Slackware for the next one or two years.

Isn't the new KDE/Plasma "Plasma Desktop Manager"?

Originally Posted by ivandi Here is a patch for sbopkg to use fake chroot environment. It modifies only the build_package() function. Uses ro bind mounts for the system folders and rw bind mounts for the sbopkg folders. It can be easily made optional with for example USECHROOT and CROOTDIR variables in sbopkg.conf. It changes nothing in the way SBo works. Everything is run as root.

I like the approach you take with this.

If someone is willing to test it simply download the attached patch and: cd /usr/sbin patch -b sbopkg ~/Downloads/sbopkg_fake_chroot.txt

I read your posts mentioning this method, but hadn't had a chance to test. This patch for sbopkg makes it very easy. I'm testing it now on some updates. Working well, though so far it hasn't caught any targeted issues. I will continue to test it for some time.

While I will probably continue to use fakeroot for various reasons and purposes, this will be a nice option. Thank you for sharing.

Cheers,
John

Fakeroot uses LD_PRELOAD mechanism and can't catch a statically linked binary writing to a system folder. In practice there is a very low probability to have one such binary but in theory that's a flaw.

I also use this approach to quickly clone my installation into a container. I copy only the volatile folders /etc /var /tmp. The rest is ro bind mounts. It takes far less space and the container is always up to date. Saves time. Especially with several containers for testing purposes.


Cheers

Originally Posted by ivandi Fakeroot uses LD_PRELOAD mechanism and can't catch a statically linked binary writing to a system folder. In practice there is a very low probability to have one such binary but in theory that's a flaw.

you mean I can make a package and when the packages builds it links statically against libc and than I make my make call to call that binary so I can by pass the fakeroot environment and write one or more files into the system because I do not want to wait to take over the system until I have installed me I can run with root privileges anyway? wow, I didn't know this.

but I like your chroot env more, having this in a tempfs would be nice also.

when you have 2 so chroot environments and overlay them when required an un-overlay them when done (before packaging) it could possibly be possible to build packages that depend on other packages without even install the other packages on the system.
this could be a very interesting way to test various build constellations ... not that I have an actual need for this at the moment but who knows.

Originally Posted by a4z . . .

Just an example:
Bug#366067: fakeroot doesn't work with statically linked binaries
Not sure what the present situation is.

Here is a hint on LFS about using unionfs (now overlayfs).

Cheers

Originally Posted by ivandi J Here is a hint on LFS about using unionfs (now overlayfs). Cheers

I think that Slax uses something like that for its packaging system.

Originally Posted by Richard Cranium I think that Slax uses something like that for its packaging system.

yes, it uses aufs ("Instead of installing, Slax modules are activated. In technical terms, that means mounted and added to aufs union as a new branch."), also for running the distribution as live, with a RAM layer over the static filesystem on the media (see slax internals).

libbonobo fails to build with or without

autoreconf -fi

being ran.

Output from build test with autoreconf:

utomake: warning: autoconf input should be named 'configure.ac', not 'configure.in'
configure.in:69: installing './compile'
configure.in:13: installing './missing'
automake: warning: autoconf input should be named 'configure.ac', not 'configure.in'
activation-server/Makefile.am:9: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS')
activation-server/Makefile.am: installing './depcomp'
parallel-tests: installing './test-driver'
bonobo-activation/Makefile.am:5: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS')
bonobo/Makefile.am:2: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS')
idl/Makefile.am:51: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS')
monikers/Makefile.am:1: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS')
samples/echo/Makefile.am:56: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS')
tests/Makefile.am:19: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS')
tests/Makefile.am:57: error: using '$(srcdir)' in TESTS is currently broken: '$(srcdir)/test-properties.sh'
tests/test-activation/Makefile.am:76: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS')
utils/Makefile.am:9: warning: 'INCLUDES' is the old name for 'AM_CPPFLAGS' (or '*_CPPFLAGS')
autoreconf: automake failed with exit status: 1
Failures:
  libbonobo: libbonobo.SlackBuild return non-zero

Output from build test without autoreconf:

  CC     client.o
In file included from client.c:33:0:
../bonobo-activation/bonobo-activation-private.h:34:1: error: unknown type name 'GStaticRecMutex'
 extern GStaticRecMutex _bonobo_activation_guard;
 ^
make[3]: *** [client.o] Error 1
make[3]: Leaving directory `/tmp/SBo/libbonobo-2.32.1/activation-server'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/tmp/SBo/libbonobo-2.32.1/activation-server'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/tmp/SBo/libbonobo-2.32.1'
make: *** [all] Error 2
Failures:
  libbonobo: libbonobo.SlackBuild return non-zero

@ReaperX7:

I googled: https://gist.github.com/shadeslayer/1607267

even tho its a different package, the function problem is the same

Since GLib 2.31 GStaticRecMutex has been deprecated and GRecMutex is used instead. We do not need to initialize GRecMutex since it is static
it will need a patch to build against new glib.

you can try to remove the autoreconf -vi line

I did and the second result is what happened. I'll try that patch and report back.

Also, someone should consider putting up automake-1.11.x up as an SBo package I ran across today complained about it missing. I did grab a copy from an older Slackware release so it worked.

i tested in current and it works just by removing autoreconf part