SBo scripts not building on current (read 1st post, pls)

ponce · 02-20-2017, 10:16 AM

hi sombragris, that is already patched on the unofficial repository for current, I have posted you the link at the patch in the other topic (in case you are not already using this repository): the patch is taken from the clamav development repository as the check they do for zlib in the configure has been corrected there.

sombragris · 02-20-2017, 12:52 PM

Quote:

Originally Posted by ponce

hi sombragris, that is already patched on the unofficial repository for current

Thank you ponce!!

bassmadrigal · 02-21-2017, 11:49 AM

Quote:

Originally Posted by BW-userx

Statement: VLC requires ffmpg because it uses its libavcodec (from what I just read elsewhere) but apparently libavcodec is not equal to VLC needs or visa versa.

option: Someone is dropping the ball between the two.

Newer versions of programs sometimes require newer versions of their dependencies. There is nothing new or strange about that. Due to the changes between ffmpeg's ABIs, VLC chose to put limits on what versions it supports rather than do a big cluster of if/then statements

Quote:

Originally Posted by BW-userx

Now someone tells me this, after I have argued many a time over the use of root for the reasons I have argued them, this only being one instance of it. But in this instance being to compile code while being root and I only get feedback from all of the self proclaimed experts is no it is not safe to do. use sudo it is a security rist, blah blah blah is the rest of their justifications for having to use sudo for everything under the sun that is related to linux/GNU.

So here I am being yelled at and told by the self proclaimed powers that be many times before me writing this on how I do not conform to social norms and procedures due to my belief system.

Within my belief system where it once said, it is just fine to use root to compile source code. But they, they being the others that are not me do not believe what I believe so conflict arose and I am tagged the out cast for my beliefs. So I try to circumvent the situation and just play along and fall into the habit of using sudo for everything under the sun even compiling source code because that is what the others said was safer to do and I am welcomed back into the fold for now having changed a few things within my belief system to conform to the others that think they know it all. With glasses of wine and beer and pats on the back to congratulate me for conforming to their ways.

Then you come long and contradict every one of them as I have done so prior to.

conclusion?
A dilemma arises again as a result of it.

[snip]

I can remember way back when Sack was just a baby and I never had these issues. it was root and be happy. even though sudo too was around during that time as well. I never used it, ever, always root. rip sudo out of Slack and be done with it.

thanks for your input.

There is some misunderstandings going on. Root usage in Linux is required. There is always going to be times that you need to run something as root. Compiling software typically isn't one of them (unless the compilation folders are owned by root, which is typically the case when you compile something from SBo). You can compile software as any user. However, depending on the location you install that software to, you will probably need to be root to actually install it.

Now, running certain required things as root is vastly different than running everything as root. Linux guidelines are to follow the principle of least privilege (PLP), meaning that you should only run things as root when it's required. There is almost never a requirement to run a DE/WM as root. Doing so will cause each and every program that the DE/WM starts to run as root. That goes directly against PLP. This opens you up to a large amount of potential issues due to bugs, exploits, etc.

Now, since we've covered that there are times when root is required, you already know there's two programs that can provide that to you: su and sudo. Both essentially provide you the ability to do things as root, but how they do that is a bit different. su is basically just logging into a shell as root. Everything you do in that shell (until you logout or exit) is done as root, so any mistakes in your commands can have drastic effects on your system. sudo works a bit differently. sudo allows the administrator (typically the one who logs in as root) to allow certain unpriviliged users or groups to execute certain commands that are authorized to them (it can also be all commands, but this wasn't the original intention and didn't become popular until the *buntus started doing it). The idea behind sudo is if you, as an administrator, have a user that needs to be able to create a filesystem using mkfs (which needs to be run as root), but they don't need the ability to restart services, install programs, or shutdown the computer, then you can give the user the ability to run just mkfs. Keep in mind, from an adminstrator's position, if you happen to add something that would seem minor, like a text editor (vi(m), emacs, nano, etc), then that user would be able to possibly edit files that could lead to them having full root permissions.

What the *buntus brought with sudo is kinda against the whole reasoning for sudo, which was to provide the administrator the ability to allow some users to run some commands with root privilege without giving that user full access or the root password. There's nothing inherently wrong with providing your user the ability to run all commands with sudo, but many don't like it. I doubt we'll ever see Slackware set up with a user having the ability to run all commands with sudo. It will be something that each "administrator" (you know... you, in this case

) will need to decide for themselves.

If you need to run a GUI program as root, there's kdesu (included with a full stock install) or gksu (included on SBo). This works better than using su or sudo because it will set some of the environment variables properly and can prevent clobbering your home directories' permissions (if you happen to run firefox using su or sudo, it will still use your regular user's firefox profile, and it will change ownership of several key files, which will break firefox when ran as your normal user again).

So, to break things down. Running everything as root is bad from a security standpoint and goes directly against PLP. The goal is to only run things as root when you need to. To do that, you can run su, sudo (if it's set up properly), or kdesu (gksu). Slackware and Linux are all about customization. You should be able to tailor the system to your needs. If that "need" is for you to run everything as root and go against PLP, then that's your choice. But since running everything as root is not recommended by pretty much everyone, you might not see many people willing to help you troubleshoot problems when doing so (just like the caja developers did). Linux will provide you the gun and the bullets. It will warn you to not shoot yourself in the foot and to keep it pointed downrange, but you're certainly still able to shoot yourself in the foot, no matter how many warnings/recommendations are provided

Hopefully I've cleared that up.

ponce · 02-21-2017, 01:52 PM

Quote:

Originally Posted by sombragris

freeorion 0.46 cannot be built in Slackware64-current.

patch the SlackBuild like this

Code:

From d12fc72eeb66733733ea8a393f6000ed71278435 Mon Sep 17 00:00:00 2001
From: Matteo Bernardini <ponce@slackbuilds.org>
Date: Tue, 21 Feb 2017 20:48:50 +0100
Subject: [PATCH] games/freeorion: Updated for version 20170221_d4924cc.

Signed-off-by: Matteo Bernardini <ponce@slackbuilds.org>
---
 games/freeorion/freeorion.SlackBuild | 9 +++------
 games/freeorion/freeorion.info       | 6 +++---
 2 files changed, 6 insertions(+), 9 deletions(-)

diff --git a/games/freeorion/freeorion.SlackBuild b/games/freeorion/freeorion.SlackBuild
index 7281d05e9b..686014949f 100644
--- a/games/freeorion/freeorion.SlackBuild
+++ b/games/freeorion/freeorion.SlackBuild
@@ -22,10 +22,8 @@
 #  OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
 #  ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

-SRCNAM=FreeOrion
-PRGNAM=${SRCNAM,,}
-SRCVER=${SRCVER:-v0.4.6_2016-09-16.49f9123}
-VERSION=$(echo $SRCVER | cut -c2-6)
+PRGNAM=freeorion
+VERSION=${VERSION:-20170221_d4924cc}
 BUILD=${BUILD:-1}
 TAG=${TAG:-_SBo}

@@ -62,8 +60,7 @@ rm -rf $PKG
 mkdir -p $TMP $PKG $OUTPUT
 cd $TMP
 rm -rf $PRGNAM-$VERSION
-tar xvf $CWD/${SRCNAM}_${SRCVER}_Source.tar.gz
-mv src-tarball $PRGNAM-$VERSION
+tar xvf $CWD/$PRGNAM-$VERSION.tar.xz
 cd $PRGNAM-$VERSION
 chown -R root:root .
 find -L . \
diff --git a/games/freeorion/freeorion.info b/games/freeorion/freeorion.info
index 99ec98ea9c..6034876fdd 100644
--- a/games/freeorion/freeorion.info
+++ b/games/freeorion/freeorion.info
@@ -1,8 +1,8 @@
 PRGNAM="freeorion"
-VERSION="0.4.6"
+VERSION="20170221_d4924cc"
 HOMEPAGE="http://www.freeorion.org"
-DOWNLOAD="https://github.com/freeorion/freeorion/releases/download/v0.4.6/FreeOrion_v0.4.6_2016-09-16.49f9123_Source.tar.gz"
-MD5SUM="2927818ca87834ec7cc6e77b11619186"
+DOWNLOAD="http://ponce.cc/slackware/sources/repo/freeorion-20170221_d4924cc.tar.xz"
+MD5SUM="f85c25675b11ffb0c69eefb57508763f"
 DOWNLOAD_x86_64=""
 MD5SUM_x86_64=""
 REQUIRES="SDL2 OpenAL"
--
2.11.0

sombragris · 02-23-2017, 10:13 AM

Hi there, I'm transitioning my sbopkg setup from 14.2 to -current (about time, since I run -current).

I have some questions:

1. I know that SBo usually releases a changelog on Saturday each week. When are these changes applied to Ponce's repository? (i.e., how many days later?)

2. After swithching repo branches from 14.2 to current, I have zero updates. How can I convert all my SBo packages to SBo-git in an automatic manner?

Thanks in advance

ponce · 02-23-2017, 10:24 AM

Quote:

Originally Posted by sombragris

Hi there, I'm transitioning my sbopkg setup from 14.2 to -current (about time, since I run -current).

I have some questions:

1. I know that SBo usually releases a changelog on Saturday each week. When are these changes applied to Ponce's repository? (i.e., how many days later?)

usually a few hours later, because of the different timezones: when Willy is merging all the stuff and having breakfast in Indonesia on saturday morning here in Italy we are still around one in the night.
if I'm out for the weekend a few days later

Quote:

2. After swithching repo branches from 14.2 to current, I have zero updates. How can I convert all my SBo packages to SBo-git in an automatic manner?

sorry, I haven't understood these last two things...
are you using some automated tool with the repository? in the first post, for example, there is a link with some hints for using it with sbopkg...

sombragris · 02-23-2017, 11:04 AM

Hi ponce! Thanks for the answer!

As for #1, it's all answered.

As for #2, I switched repos, from 14.2 to current. That also meant that I switched tags, from SBo to SBo-git. After switching repos and syncing again, and after going to "Updates" in the menu, it just says "no packages found - It appears that you have no SBo-git packages installed.".

I would like to replace all my SBo packages by SBo-git ones.

Thanks again!

ponce · 02-23-2017, 11:42 AM

Quote:

Originally Posted by sombragris

As for #2, I switched repos, from 14.2 to current. That also meant that I switched tags, from SBo to SBo-git. After switching repos and syncing again, and after going to "Updates" in the menu, it just says "no packages found - It appears that you have no SBo-git packages installed.".

I would like to replace all my SBo packages by SBo-git ones.

you are not telling it, but I suppose you are using sbopkg via the gui, right?

regarding switching repositories sbopkg uses the informations is /etc/sbopkg/repos.d: there the file with the data of the official SBo repository has the tag "_SBo" set for the 14.2 repository

Code:

# Repo Branch Description Tag Tool Link CheckGPG
SBo 14.2 "SBo repository for Slackware 14.2" _SBo rsync slackbuilds.org::slackbuilds/14.2 GPG

while it uses the tag "ponce" for the current branch of SBo-git

Code:

# Repo Branch Description Tag Tool Link CheckGPG
SBo-git current "UNSUPPORTED SBo git repository for -current" ponce git git://github.com/Ponce/slackbuilds.git@current ""

if you substitute in this second file the string "ponce" with "_SBo" like this

Code:

# Repo Branch Description Tag Tool Link CheckGPG
SBo-git current "UNSUPPORTED SBo git repository for -current" _SBo git git://github.com/Ponce/slackbuilds.git@current ""

sbopkg should identify the installed packages as upgradeable with the one of the repository.

note that upgrading your third party packages with whatever has new/different versions if you switch from stable to current usually is not enough: current has different libraries from stable, so if you have built a package on stable and it links to the stable libraries, when you upgrade from stable to current it will link to libraries that won't be on the system anymore and if in the new SBo-git repository the version is the same you won't rebuild it and it won't work.
so, long story short, if you upgrade from stable to current, if you want to be sure that everything will work after the upgrade, rebuild *all* your third party packages using the new repository, not just the changed ones.

P.S. don't forget to delete the repository totally and resync it at every update (more or less once a week), like explained in the link in the first post: the current branch gets rebased so this is the easiest way to sync it correctly.

sombragris · 02-23-2017, 12:21 PM

Thanks ponce, that was exactly what I was looking for!

sombragris · 03-10-2017, 01:11 PM

texlive does not build in -current. The culprit seems to be dvipng.

Compiler output:

Code:

make[5]: Leaving directory '/tmp/SBo/texlive-20160523-source/build/texk/dvipng/help'
Making all in doc
make[5]: Entering directory '/tmp/SBo/texlive-20160523-source/build/texk/dvipng/doc'
echo timestamp >doc-stamp
make  all-am
make[6]: Entering directory '/tmp/SBo/texlive-20160523-source/build/texk/dvipng/doc'
restore=: && backupdir=".am$$" && \
am__cwd=`pwd` && CDPATH="${ZSH_VERSION+.}:" && cd ../../../../texk/dvipng/doc && \
rm -rf $backupdir && mkdir $backupdir && \
if (/usr/bin/makeinfo --version) >/dev/null 2>&1; then \
  for f in ../../../../texk/dvipng/doc/dvipng.info ../../../../texk/dvipng/doc/dvipng.info-[0-9] ../../../../texk/dvipng/doc/dvipng.info-[0-9][0-9] ../../../../texk/dvipng/doc/dvipng.i[0-9] ../../../../texk/dvipng/doc/dvipng.i[0-9][0-9]; do \
    if test -f $f; then mv $f $backupdir; restore=mv; else :; fi; \
  done; \
else :; fi && \
cd "$am__cwd"; \
if /usr/bin/makeinfo -D no-option -D no-env -D no-acronym   -I ../../../../texk/dvipng/doc \
 -o ../../../../texk/dvipng/doc/dvipng.info ../../../../texk/dvipng/doc/dvipng.texi; \
then \
  rc=0; \
  CDPATH="${ZSH_VERSION+.}:" && cd ../../../../texk/dvipng/doc; \
else \
  rc=$?; \
  CDPATH="${ZSH_VERSION+.}:" && cd ../../../../texk/dvipng/doc && \
  $restore $backupdir/* `echo "./../../../../texk/dvipng/doc/dvipng.info" | sed 's|[^/]*$||'`; \
fi; \
rm -rf $backupdir; exit $rc
gettext_xs.c: loadable library and perl binaries are mismatched (got handshake key 0xdb00080, needed 0xdb80080)
make[6]: *** [Makefile:415: ../../../../texk/dvipng/doc/dvipng.info] Error 1
make[6]: Leaving directory '/tmp/SBo/texlive-20160523-source/build/texk/dvipng/doc'
make[5]: *** [Makefile:373: all] Error 2
make[5]: Leaving directory '/tmp/SBo/texlive-20160523-source/build/texk/dvipng/doc'
make[4]: *** [Makefile:906: all-recursive] Error 1
make[4]: Leaving directory '/tmp/SBo/texlive-20160523-source/build/texk/dvipng'
make[3]: *** [Makefile:675: all] Error 2
make[3]: Leaving directory '/tmp/SBo/texlive-20160523-source/build/texk/dvipng'
make[2]: *** [Makefile:901: recurse] Error 1
make[2]: Leaving directory '/tmp/SBo/texlive-20160523-source/build/texk'
make[1]: *** [Makefile:481: all-recursive] Error 1
make[1]: Leaving directory '/tmp/SBo/texlive-20160523-source/build/texk'
make: *** [Makefile:569: all-recursive] Error 1

This looks to be the problem, although I have zero clue on what does it mean:

Code:

gettext_xs.c: loadable library and perl binaries are mismatched (got handshake key 0xdb00080, needed 0xdb80080)

Thanks in advance for any help.

rworkman · 03-10-2017, 02:20 PM

It just built on both 32 and 64 for me in a VM.
EDIT: The VMs were lacking the latest batch of updates to -current. I don't think those will make a difference, but I'm updating and will do a rebuild to be sure.

orbea · 03-10-2017, 03:21 PM

@sombragris, I suspect your perl installation is broken. Try removing and/or reinstalling any third party perl modules, make sure to look in /usr/local/ too.

sombragris · 03-10-2017, 04:04 PM

Quote:

Originally Posted by orbea

@sombragris, I suspect your perl installation is broken. Try removing and/or reinstalling any third party perl modules, make sure to look in /usr/local/ too.

That was exactly the issue. After recompiling perl-libintl from SBo I was able to build it normally. Thanks orbea!!

rworkman · 03-10-2017, 05:16 PM

Yep, good deal. Build was successful for round 2 as well, but you already know that now

RadicalDreamer · 03-10-2017, 10:35 PM

For wine-staging --with-gnutls has to be disabled to get it to compile in current. I have gnutls-compat32-3.5.8-x86_64-1compat32 installed.