That which could be fixed in SBo thread.

Originally Posted by codeguy Why?

That's how SBo tried to manage the UID/GID in order not to conflict with Slackware's adduser command
You can have your own way to manage UID/GID, but that's the recommended way if you are using SBo scripts.

Please note that we are enforcing you to do it since you can change it in the SlackBuild scripts manually if you like

Originally Posted by 55020 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...

I have not. That's why I'm curious. I didn't think the numbers were important. Don't you only need the name? My first install of Postgres was before there was a slackbuild, so my postgres user is not 209, its 1001. My newest install on a new box has the pg user as 209. Never had problems with them as being two different numbers. groupadd, useradd, chown dont require the number. Never used getent.

If its a thing, thats cool. I just don't see it. Seems extra work for no reason. Sorry to be such a pest.

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.

great job, thanks for the work!

Originally Posted by willysr That's how SBo tried to manage the UID/GID in order not to conflict with Slackware's adduser command You can have your own way to manage UID/GID, but that's the recommended way if you are using SBo scripts.

OH! Its because people like to have their services in the range 200-300 (for example), and all their users > 1000?

adduser itself wouldn't have a problem, it just uses next available, right?

Originally Posted by codeguy OH! Its because people like to have their services in the range 200-300 (for example), and all their users > 1000? adduser itself wouldn't have a problem, it just uses next available, right?

From adduser:

# v1.03 - 20/05/02
#       * Support 'broken' (null lines in) /etc/passwd and 
#         /etc/group files <sw>       
#       * For recycling UIDs (default still 'off'), we now look in 
#         /etc/login.defs for the UID_MIN value and use it
#         If not found then default to 1000 <sw>
<snip>
# Determine what the minimum UID is (for UID recycling)
# (we ignore it if it's not at the beginning of the line (i.e. commented out with #))
export recycleUIDMIN="$(grep ^UID_MIN /etc/login.defs | awk '{print $2}' 2>/dev/null)"
# If we couldn't find it, set it to the default of 1000
if [ -z "$recycleUIDMIN" ]; then
   export recycleUIDMIN=1000  # this is the default from Slackware's /etc/login.defs
fi


# This setting enables the 'recycling' of older unused UIDs.
# When you userdel a user, it removes it from passwd and shadow but it will
# never get used again unless you specify it expliticly -- useradd (appears to) just
# look at the last line in passwd and increment the uid.  I like the idea of 
# recycling uids but you may have very good reasons not to (old forgotten
# confidential files still on the system could then be owned by this new user).
# We'll set this to no because this is what the original adduser shell script
# did and it's what users expect.
recycleuids=no

in login/defs as shipped:

# Min/max values for automatic uid selection in useradd
#
UID_MIN             1000
UID_MAX            60000
# System accounts
SYS_UID_MIN          101
SYS_UID_MAX          999

FYI, <sw> is Stuart Winter aka drmozes in this forum.

This is "as shipped", of course you can customize this behavior at will.

Shot in the dark question, but isn't gnash unmaintained currently?

Originally Posted by ReaperX7 Shot in the dark question, but isn't gnash unmaintained currently?

Do you mean me maintaining it, or upstream maintaining it?

Upstream. I'm only curious if gnash is worth keeping since freshplayer is approaching the same goals of gnash as an open source alternative to flashplayer from Adobe, but is more up-to-date in terms of support vectors.

Originally Posted by ReaperX7 Upstream. I'm only curious if gnash is worth keeping since freshplayer is approaching the same goals of gnash as an open source alternative to flashplayer from Adobe, but is more up-to-date in terms of support vectors.

It's still alive. It'd be nice to see a new release, the last one was right about 3 years ago. I think upstream could use some extra support as their server has been down for a while and nobody has had a chance to fix it yet.

Feel free to submit a script for freshplayer. However that doesn't mean gnash should be removed. It's all about choice. For example I've got an older machine without SSE2 support and it can't run the official plugins from Adobe because of it, but gnash works fine.

I'll see about the build instructions for FreshPlayer first before committing it to a script.

Okay, update on FreshPlayer.

It does need some extras from SBO (that I could tell):

libconfig
ragel (source is moved, is available from http://www.colm.net/files/ragel/ )
kelbt (source is gone, last copy of 0.15 I could get off archive.org I uploaded to my Slackworks repo-page. DL here: https://github.com/reaperx7/slackwor...ar.gz?raw=true )

optional dependency is pulseaudio

This should build the package:

mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo -DCMAKE_HAVE_LIBPULSE=0 ..
make
cp -v ../libfreshwrapper-pepperflash.so /usr/lib64/mozilla/plugins

I'll see about getting a SlackBuild crafted on this.

thanks for reporting: kelbt and ragel are fixed in my git branch, will go in the main repository at the next update.

Originally Posted by ReaperX7 freshplayer is approaching the same goals of gnash as an open source alternative to flashplayer from Adobe

No, that is completely wrong.

Fresh player, is a NPAPI wrapper about the PPAPI "Adobe" Flash plugin. It is 100% reliant on Adobe's code, without the PPAPI Adobe Flash plugin (extracted from the Chrome package), Fresh Player does absolutely nothing!

Gnash is a "clean" reimplementation of Flash with no Adobe code, as an NPAPI plugin.

It sucks and will never achieve its end Goal within a useful time period (while Flash remains relevant) but that is beside the point, the only similarity between these two projects is the fact that they allow you to run Flash content in browsers that use NPAPI plugins.

Originally Posted by ponce thanks for reporting: kelbt and ragel are fixed in my git branch, will go in the main repository at the next update.

You're welcome ponce. If any other packages end up in vaporized into the ether, I'll try what I can to toss them into my git for redistribution. Sad to see source code always getting vaporized from time to time.

Yeah ruario, but at the moment anyone could argue for either. Sometimes even the cleanest code isn't the most useful. It's well meaning, but not as useful.

Gnash is open source. Fresh player itself is Open Source but entirely depends on proprietary software. For some this is important. So one is not a replacement for the other for everybody.