That which could be fixed in SBo thread.

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???

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???

higan works properly, detects libananke.so properly, no SlackBuild modifications necessary on Slackware64-14.1.

Hi,

My SlackBuild for squidGuard has just been published. Only problem: the two patches are missing apparently.

You can get them here:

$ git clone https://github.com/kikinovak/slackbuilds

Take a peek in pending/squidGuard/.

Cheers,

Niki

14.1 isn't technically the target. This thread is aimed at -Current due to the fact packages were found to have some issues with -Current and seeing if other patches may be needed to the build scripts and the package sources, pending the next release cycle.

Originally Posted by kikinovak Hi, My SlackBuild for squidGuard has just been published. Only problem: the two patches are missing apparently. You can get them here: $ git clone https://github.com/kikinovak/slackbuilds Take a peek in pending/squidGuard/. Cheers, Niki

Problem solved. The patches provided by squidguard.org are in *.tar.gz format and were ignored by SBo's .gitignore.

The homepage for fish (http://slackbuilds.org/system/fish/) has moved from fisshell.com to fisshell.org.

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.

--- sbopkg.orig	2013-12-09 10:10:35.000000000 -0500
+++ sbopkg	2015-02-07 13:09:09.101133548 -0500
@@ -3460,17 +3460,52 @@
         # See also the comment in /etc/profile.d/lang.sh
         export LC_COLLATE=C
         export TAG=$REPO_TAG
+        
+        CHROOTDIR=/var/lib/sbochroot
+        mkdir -p $CHROOTDIR
+        for d in bin sbin lib lib64 usr opt etc ; do
+	    if [ -d /$d ]; then
+		mkdir -p $CHROOTDIR/$d
+		mount /$d $CHROOTDIR/$d -o bind
+		mount /$d $CHROOTDIR/$d -o remount,ro,bind
+	    fi
+	done
+	for d in $REPO_ROOT $SRCDIR ${LOGFILE%/*} $TMPDIR ; do
+	    if [ -d $d ] ; then
+		mkdir -p $CHROOTDIR/$d
+		mount /$d $CHROOTDIR/$d -o bind
+	    fi
+	done
+	mkdir -p $CHROOTDIR/{dev/pts,proc,sys,run,root}
+	mount /dev $CHROOTDIR/dev -o bind
+	mount -t devpts devpts $CHROOTDIR/dev/pts -o gid=5,mode=620
+	mount -t proc proc $CHROOTDIR/proc
+	mount -t sysfs sysfs $CHROOTDIR/sys
+	mount -t tmpfs tmpfs $CHROOTDIR/run
+        
         if [[ $CLEANUP ]]; then
             # We want to remove all the build residuals after running the
             # SlackBuild script. To do that reliably (i.e. without
             # deleting too much or leaving garbage behind us), a nice
             # approach is to use sbopkg's own temp directory.
             export TMP=$SBOPKGTMP
-            nice -n ${NICE:-10} sh $PKGNAME.SlackBuild.build
+            nice -n ${NICE:-10} chroot $CHROOTDIR /bin/sh -c "cd $REPO_DIR/$PKGPATH ; /bin/sh $PKGNAME.SlackBuild.build"
             echo "Cleaning up..."
         else
-            nice -n ${NICE:-10} sh $PKGNAME.SlackBuild.build
+            nice -n ${NICE:-10} chroot $CHROOTDIR /bin/sh -c "cd $REPO_DIR/$PKGPATH ; /bin/sh $PKGNAME.SlackBuild.build"
         fi
+        
+	umount $CHROOTDIR/proc
+	umount $CHROOTDIR/sys
+	umount $CHROOTDIR/run
+	umount $CHROOTDIR/dev/pts
+	umount $CHROOTDIR/dev
+	for d in $REPO_ROOT $SRCDIR ${LOGFILE%/*} $TMPDIR ; do
+	    umount $CHROOTDIR/$d
+	done
+        for d in bin sbin lib lib64 usr opt etc ; do
+	    umount $CHROOTDIR/$d
+	done
     )
 }

If someone is willing to test it simply download the attached patch and:

cd /usr/sbin
patch -b sbopkg ~/Downloads/sbopkg_fake_chroot.txt

So far it works fine with the good slackbuilds and makes the broken ones fail:

Making install in applications
make[2]: Entering directory `/tmp/SBo/gtkwave-3.3.51/share/applications'
make[3]: Entering directory `/tmp/SBo/gtkwave-3.3.51/share/applications'
make[3]: Nothing to be done for `install-exec-am'.
 /usr/bin/mkdir -p '/tmp/SBo/package-gtkwave/usr/share/applications'
 /usr/bin/ginstall -c -m 644 gtkwave.desktop '/tmp/SBo/package-gtkwave/usr/share/applications'
make  install-data-hook
make[4]: Entering directory `/tmp/SBo/gtkwave-3.3.51/share/applications'
/usr/bin/update-desktop-database
The databases in [/usr/local/share/applications, /usr/share/applications] could not be updated.
make[4]: *** [install-data-hook] Error 1
make[4]: Leaving directory `/tmp/SBo/gtkwave-3.3.51/share/applications'
make[3]: *** [install-data-am] Error 2
make[3]: Leaving directory `/tmp/SBo/gtkwave-3.3.51/share/applications'
make[2]: *** [install-am] Error 2
make[2]: Leaving directory `/tmp/SBo/gtkwave-3.3.51/share/applications'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory `/tmp/SBo/gtkwave-3.3.51/share'
make: *** [install-recursive] Error 1

gtkwave:
Would you like to continue processing the rest of the
queue or would you like to abort?  If this failed
package is a dependency of another package in the queue
then it may not make sense to continue.

(Y)es to continue, (N)o to abort, (R)etry the build?:

Cheers

Some build scripts need special user and/or groups, and to that end we have:

http://slackbuilds.org/uid_gid.txt

But I dislike requiring a certain user to be a certain number. I don't really see why its necessary either.

I run PostgreSQL for example, and the build script has: PG_UID=${PG_UID:-209}

Then it uses sed to set the number into the setup script. The setup script then uses the number useradd. But why? useradd can just use the next available number. The script uses chown with the name, not the number. Its seems overly complex.

I'm not just picking on PostgreSQL build, many others do the same thing.

Is there a reason I'm missing?

Originally Posted by codeguy Some build scripts need special user and/or groups, and to that end we have: http://slackbuilds.org/uid_gid.txt But I dislike requiring a certain user to be a certain number. I don't really see why its necessary either. I run PostgreSQL for example, and the build script has: PG_UID=${PG_UID:-209} Then it uses sed to set the number into the setup script. The setup script then uses the number useradd. But why? useradd can just use the next available number. The script uses chown with the name, not the number. Its seems overly complex. I'm not just picking on PostgreSQL build, many others do the same thing. Is there a reason I'm missing?

It's for the sake of consistency
if it's not standarized, one user can have 209 as UID/GID for postgresql and other can have it for another package

But that's not a mandatory requirements, you can change the UID/GID for your system, but if you are building many packages from SBo repository, the chance that you will end up with a collision is bigger than if you follow the standard UID/GID mentioned on that file.

Originally Posted by dugan The homepage for fish (http://slackbuilds.org/system/fish/) has moved from fisshell.com to fisshell.org.

Fixed in my branch

Thanks

Originally Posted by willysr It's for the sake of consistency if it's not standarized, one user can have 209 as UID/GID for postgresql and other can have it for another package But that's not a mandatory requirements, you can change the UID/GID for your system, but if you are building many packages from SBo repository, the chance that you will end up with a collision is bigger than if you follow the standard UID/GID mentioned on that file.

It'll only collide if you require a number. It wont collide if you just let useradd use the next available number. Why would it matter if I have postgres user as 42 and you have it as 209?

Taken from the FAQ:

We keep a list of recommended UID/GIDs for use with SlackBuilds.org scripts. These do not conflict with default system accounts for Slackware nor with the initial (and subsequent) UIDs recommended by adduser.

Originally Posted by slacktroll rtorrent/libtorrent doesn't need libsigc++ anymore. already mailed maintainer.

Fixed it on my branch

Thanks

Originally Posted by willysr list of recommended UID/GIDs for use with SlackBuilds.org scripts

Why?

Originally Posted by codeguy Why?

Have you tried scripting the necessary combination of getent, groupadd and useradd commands to make the numbers up on the fly? It's not the happiest way of spending an afternoon...