SBo scripts not building on current (read 1st post, pls)
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Community Challenge! Help fix the last few SlackBuilds for 14.2
For anybody not subscribed to the SBo Mailing List, I posted this yesterday. If you have a solution, you are very welcome to post patches into this thread. Thanks for looking!
--------------------------------------
At this time there are only a few packages that fail to build, and all
the git commiters are getting a bit tired, so we would like to
challenge the community to help fix the last few problems. Your
reward will be a nice Thank You in the git repo
Here are the first four ... if you can fix them, there will be some more later!
It looks like an underlinking error, but I can't see anything wrong
with the link. There is a new version 6.4 upstream, I have tried it,
but the same linking problem happens. Maybe its dep
libraries/trilinos is involved -- Guilherme (maintainer of both Xyce
and trilinos) downgraded trilinos soon after it was first added. I
can't find any bug reports. Most other distros don't have Xyce.
If you don't want to register to download the source, there is a copy
of Xyce-6.4 on SlackBuilds Direct Links (Xyce is GPL, so
redistributing it is perfectly legal ) https://sourceforge.net/projects/sla...ks/files/Xyce/
The build was broken by the new version of sigc++. Upstream is quite
active but seems to have stopped tagging proper releases. I tried the
latest git, but it needs its deps also updating to compatible
versions.
Version 1.20.0 complains about postgresql version > 9.4.x but 1.22.1 is OK with pg version 9.5.3
The MD5SUM is 'fake' ( generated locally ).
I could not find one at the home page but there is a .sig file and the source file verified OK:
Code:
# gpg --verify ./pgadmin3-1.22.1.tar.gz.sig
gpg: assuming signed data in `./pgadmin3-1.22.1.tar.gz'
gpg: Signature made Mon Feb 8 04:36:36 2016 CST using RSA key ID 698F1519
gpg: Can't check signature: public key not found
# gpg --no-default-keyring --keyring vendors.gpg --keyserver pgp.mit.edu --recv-key 698F1519
gpg: keyring `/root/.gnupg/vendors.gpg' created
gpg: requesting key 698F1519 from hkp server pgp.mit.edu
gpg: key 698F1519: public key "Dave Page <dpage@pgadmin.org>" imported
gpg: public key of ultimately trusted key 40102233 not found
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: Total number processed: 1
gpg: imported: 1 (RSA: 1)
# gpg --verify --verbose --keyring vendors.gpg pgadmin3-1.22.1.tar.gz.sig
gpg: assuming signed data in `pgadmin3-1.22.1.tar.gz'
gpg: Signature made Mon Feb 8 04:36:36 2016 CST using RSA key ID 698F1519
gpg: using PGP trust model
gpg: Good signature from "Dave Page <dpage@pgadmin.org>"
gpg: aka "Dave Page <pgsnake@gmail.com>"
gpg: aka "Dave Page <dpage@postgresql.org>"
gpg: aka "Dave Page <dave.page@enterprisedb.com>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: E0C4 CEEB 826B 1FDA 4FB4 68E0 24AD FAAF 698F 1519
gpg: binary signature, digest algorithm SHA1
Is there any thoughts for an (unoffical?) plan for python3 versions of programs already available on SBo as python2 versions?
I'm working on generating a SlackBuild for a new python3 based program, and many of the requirements are of programs already available as python2 versions. Some have an if/then statement to catch a python3 install and generate a dual python2/python3 package, but others don't have any such thing.
So far, for the ones that haven't included any catch for python3 within the SlackBuild, I've mirrored everything and changed the package name to python3-$PRGNAM, which seems like the best option (I did it previously with python3-PyYAML). (Once I complete everything, I'll email the maintainers of those python2 packages to see if they want to maintain the python3 versions, if not, I'll maintain them).
However, my question stems from the programs, like python-requests, that have the if/then statement in there to catch whether python3 is installed. If that package was originally built as a python2 only package, and then a person tries to build the dependencies of this program (including python3), the user or some automated tools would skip the already installed python2-only program since it was already installed.
Is there a recommended course of action on how to handle these packages? Should I just mention it in the README that recompilations for those programs that have the checks might be required if they were originally built as python2? Or should I just continue and mirror those programs as python3-$PKGNAM versions?
Last edited by bassmadrigal; 06-02-2016 at 06:00 PM.
Reason: Linkified to SBo
I can't help but wonder if we should split the "python" category into "python2" and "python3" - this would necessitate (or least imply the desire for) separate python2-$app and python3-$app builds, which would make many things better but also carries the possibility of making some things worse, I suppose...
This is kind of off-topic, but I made a SlackBuild for acpi_call. (I needed it for TLP to set custom battery charge thresholds on my Thinkpad.) I see on SlackBuilds.org that the submissions page is down currently in anticipation of 14.2. So should I just wait until that page comes up and then submit it, or would anyone like to test or look at it beforehand?
I can't help but wonder if we should split the "python" category into "python2" and "python3" - this would necessitate (or least imply the desire for) separate python2-$app and python3-$app builds, which would make many things better but also carries the possibility of making some things worse, I suppose...
I really think that separate packages are the best way. It might not even be necessary to put the python2 label on pacakges until Slackware ships python3 as default, but I would think it makes sense to separate the two on SBo. This ensures that when people attempt to build things that require the python3 version, that they'll know for sure that they're good.
I don't think it'll really make things worse except maintainers would need to manage two packages, although, they should be simple to maintain considering there shouldn't be much of a difference between the two (at least that's been the case in my experience with providing python3 packages).
=============================================
On the program I was working on, it ended up with the REQUIRES line containing:
Due to three of those requires having if/then checks for python3, I ended up with a note in the README that stated the below... just to make sure they were aware that if this is their first time installing python3, they may need to recompile them. The others are either reworkings of the python2 versions or freshly developed if they weren't previously on SBo. As I said earlier, prior to me submitting this to SBo (when submissions are open for 14.2), I'll contact the maintainers of any python2 versions I adapted to see if they want to manage the python3 versions. If not, I'll submit and maintain them.
Quote:
NOTE: colorama, six, and python-requests might require rebuilds if they were built prior to installing python3
I also put a note on the python3 versions of programs stating that they were fine to be installed alongside their python2 versions (in case users were wondering/worrying/curious).
Quote:
This builds the python3 version of SQLAlchemy. It is safe to install
this on a system that has SBo's SQLAlchemy (python2) package installed.
I can't help but wonder if we should split the "python" category into "python2" and "python3" - this would necessitate (or least imply the desire for) separate python2-$app and python3-$app builds, which would make many things better but also carries the possibility of making some things worse, I suppose...
I agree with the split: the way it is now might lead to confusion...
what might happen, I think, is that maintainers might not want to support their scripts for the two different versions of python, but let's hope someone else will step in their place if they won't.
A quick search of my local SBo repo shows that there's 46 SlackBuilds that have an if/then check for python3 (although, some developers may have used a different way to check for python3).
scribus vs nxclient conflict + scribus version 1.4.6 is available
SBo Team --
Needed to add scribus to my Current64 + Multilib Laptop.
I previously installed nxclient which makes a mess for scribus ... ( scribus' cmake tries to link against /usr/NX/lib/{libz.so,libjpeg.so,libfreetype.so} ( oops )) ...
The build errors are appended below my .sig
These are the culprits ( note the references to /usr/NX/lib/ ):
Code:
# sh ./scribus.SlackBuild 2>&1 |tee ../scribus.SlackBuild-1.4.5.out
<<build failed after a few minutes>>
# grep NX ../scribus.SlackBuild-1.4.5.out
-- Found ZLIB: /usr/NX/lib/libz.so
-- Found JPEG: /usr/NX/lib/libjpeg.so
-- Found Freetype: /usr/NX/lib/libfreetype.so (found version "2.6.3")
-- Looking for FT_Get_First_Char in /usr/NX/lib/libfreetype.so
-- Looking for FT_Get_First_Char in /usr/NX/lib/libfreetype.so - found
-- Looking for FT_Get_Next_Char in /usr/NX/lib/libfreetype.so
-- Looking for FT_Get_Next_Char in /usr/NX/lib/libfreetype.so - found
Fixed the build error by adding -DCMAKE_LIBRARY_PATH to the scribus.SlackBuild:
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
)
