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.
The hosting for tgif-QPL has changed. Host bourbon.usc.edu no longer provides an ftp service.
The DOWNLOAD field for graphics/tgif-QPL/tgif-QPL.info should be updated to "http://bourbon.usc.edu/tgif/ftp/tgif/tgif-QPL-4.2.5.tar.gz" (which is also the location prescribed on the tgif home site's Download page).
sorry for time lost arround plugins-bad ..i found culprit , for some reason im under make-4.3 , was downgraded to 4.2.1 cause some problems building using 4.3 ..i install make-4.2.1 and now builds fine ..sorry.
it has been removed because it's already shipped in Slackware current
Yes, it's there. But it's under the wrong name. So either there needs to be a six package, to satisfy REQUIRES="six", or every REQUIRES="six" needs to be removed.
This would be solved (crudely) by introducing a dummy SBo six package, and installs nothing. That at least avoids changing loads of SBo files to fix the dependency tree.
EDIT: Actually I can see 24 immediately, maybe I'm overestimating the problem:
actually no, because everything that is already provided in a Slackware full installation should not be present in the REQUIRES variable at all.
"six" is still there because the REQUIRES variables of the *.info files will be edited when the repository will be migrated to the next version of Slackware: you probably missed it but I explained this quite a few times, and it's also in the wiki
Nice. I missed this whole discussion and came up with a solution but didn't get a chance to chime in. For meld3-30.20.2, you'll still need a new dependency (python-distro, available on SB0). My patch was similar to upstream and a bit less of a hack 'n slash to the one by ponce et al.
Code:
iff -ur meld-3.20.1-original/meld/build_helpers.py meld-3.20.1/meld/build_helpers.py
--- meld-3.20.1-original/meld/build_helpers.py 2019-03-30 14:54:28.000000000 -0700
+++ meld-3.20.1/meld/build_helpers.py 2020-02-07 19:13:16.977722733 -0800
@@ -29,6 +29,7 @@
import os.path
import platform
import sys
+import distro
from distutils.log import info
@@ -379,7 +380,7 @@
def finalize_options(self):
special_cases = ('debian', 'ubuntu', 'linuxmint')
if (platform.system() == 'Linux' and
- platform.linux_distribution()[0].lower() in special_cases):
+ distro.linux_distribution()[0].lower() in special_cases):
# Maintain an explicit install-layout, but use deb by default
specified_layout = getattr(self, 'install_layout', None)
self.install_layout = specified_layout or 'deb'
I just didn't bother with pre Python-3.8 capatibility.
Also, the more I end up looking at Python and how the project is run, the more I hate it.
Nice. I missed this whole discussion and came up with a solution but didn't get a chance to chime in. For meld3-30.20.2, you'll still need a new dependency (python-distro, available on SB0).
python-distro has been added to -current some time ago.
Also, the more I end up looking at Python and how the project is run, the more I hate it.
It isn't perfect, the whole Python2-3 thing was silly. But this problem is Slackware:
Code:
# installpkg PyYAML-3.13-x86_64-1_SBo.tgz
And then
Code:
# pip install azure-cli
Gives you:
Code:
Attempting uninstall: pyyaml
Found existing installation: PyYAML 3.13
ERROR: Cannot uninstall 'PyYAML'. It is a distutils installed project and thus we cannot accurately determine which files belong to it which would lead to only a partial uninstall.
My solution would be to remove all existing Python packages from SBo, and replace them with an automated generator which puts the pip install command in doinst.sh and contains the wheel and installs it with --no-deps. The removepkg won't uninstall it, but that's OK and suits the Slackware philosophy nicely IMHO. Remove never cleans anything up. At least you end up with a maintainable system, and all these packages can be automatically generated from nothing more than the tested wheel version in a .info file. Things may break in the short-term, but after some fixes, that's the end of Python SlackBuild maintenance and Slackware devs can move on to more interesting things.
I've started to write my own package installer that works around my problems with using Python in Slackware, but it's not fully working yet, even with the relatively small number of packages I need to regularly build. Rather than the above drastic change it introduces the concept of virtual packages where it will check what pip has installed before attempting to install a dependency. At least it gets over the Azure-cli problem by figuring out that PyYAML can be removed from the dependency chain for other stuff that needs it.
Code:
usage: afterpkg [-h] [-s SLACKBUILDS] [-d] [-n NUMTHREADS] [-c] [-o] [-v] [-2]
[-3] [-p] [-b] [-a] [-r] [-g] [-q]
packages [packages ...]
Download, build and install packages from SBo-current. Afterpkg expects a full
install of -current and the SBo repo to be found at ~/.afterpkg/slackbuilds/,
if missing the ponce repo will be cloned there. By default most functionality
is enabled, the options described below mostly DISABLE things.
positional arguments:
packages Package(s) to build
optional arguments:
-h, --help show this help message and exit
-s SLACKBUILDS, --slackbuilds SLACKBUILDS
Specify the slackbuild directory. The default is
~/.afterpkg/slackbuilds. This directory will be cloned
from https://github.com/Ponce/slackbuilds.git if not
present. This will happen regardless of the -d flag
(it's not counted as doing anything). If you want a
different repository make sure this exists before
running.
-d, --donothing Don't actually do anything, just list the steps that
would be run. Note that this doesn't disable
threading: The steps will be output on different
threads, just as any real task would, which means they
can be executed in random order. If you don't like
this don't use -d with -n
-n NUMTHREADS, --numthreads NUMTHREADS
How many parallel operations to allow (default 1). See
also the -g option.
-c, --nocolour Parallel builds are normally coloured. If you don't
like vt100 escape codes in your output, use this
option. You can still distinguish threads by the
output line prefix
-o, --onlydownload This will only download the package sources and not
build, so you can run the build offline
-v, --novirtual Don't include any pip-installed Python packages in
dependency computations (same as -2 and -3)
-2, --nopip2 Don't include pip2-installed Python packages in
dependency computations
-3, --nopip3 Don't include pip3-installed Python packages in
dependency computations
-p, --pipinstall By default Python SBo packages will be built and
installed as required. This option will pip install
them instead. Note that this makes -o somewhat
pointless, as it requires you to be online. You can
always pip install everything first, however.
-b, --before Don't execute any 'before' scripts. These scripts will
get sourced before building the package.
-a, --after Don't execute any 'after' scripts. These scripts will
get sourced after building the package.
-r, --requires Don't execute any 'requires' scripts. These scripts
will get sourced before executing the builds of
dependent packages.
-g, --getinparallel Normally downloads will be one-by-one. This will run
them in parallel (up to --numthreads)
-q, --queue Just print the queue of builds, similar to what sqg
would generate. You can use afterpkg to only compute
dependencies, generate an sbopkg queue and then run
the builds with sbopkg if you prefer.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
