From milgram at cgpp.com Mon Jun 1 00:21:21 2026 From: milgram at cgpp.com (J. Milgram) Date: Sun, 31 May 2026 20:21:21 -0400 Subject: [Slackbuilds-users] [SOLVED] mutual dependency? [was: sbotools: multiline build options] In-Reply-To: References: <36186d35-1fbe-4fe1-877d-33eface6b8e6@cgpp.com> <70eade69-5d3b-4326-a79b-97ea80e515b7@cgpp.com> <1092fe0a-bcd6-46a7-afd1-3741e4896aa9@slacky.it> <26f00add-96bb-4c82-8891-892c0a55a68e@cgpp.com> <39ddbc8d-203d-49c6-b5b6-3ef25b2e6329@cgpp.com> Message-ID: Basically did a big slash-and-burn of all installed py* packages (python2 and python3,? both distro and SBo) and reinstalled them from scratch. Only reinstalled the things I currently need and their dependencies, so that may have reduced the likelihood of conflicts. Did get a couple of errors along the way but? they disappeared on re-attempt. I don't feel the need to know why. Everything seems to work. I? never could? pin it down on a particular package conflict but that's OK. Thanks to everyone who reached out to help (on and offline) - you know who you are. And BTW the idea of building in a clean chroot did prove to be useful. And not difficult. Going forward, no more running pip as root. Or at all if I can help it, unless in a virtualenv. thanks again! Judah On 5/27/26 21:20, J. Milgram via SlackBuilds-users wrote: > > On 5/27/26 10:33, Erich Ritz wrote: > >> This is the full dependency list required for python-zipp, from my >> local build log (I use slackrepo to build in a clean chroot): > > Thank you Erich. Not sure what to do with it, though. There was never > any suspicion that there was an actual circular dependency coming from > the SBo .info files. I only see it when I try to build python-zipp and > python-importlib_metadata packages manually. (See error messages below). > > FWIW, I have recently rebuilt every one of those dependencies in > versions you list. > > Is there any diagnostic value in running slackrepo on my system to > build python-zipp? Not been a slackrepo user, I'd need to figure out > how to do the clean chroot bit, so any tips appreciated! > > thanks > > Judah > > > > On 5/27/26 10:33, Erich Ritz wrote: >> On Wednesday, May 27th, 2026 at 9:17 AM, J. Milgram via >> SlackBuilds-users wrote: >> >>> python-importlib_metadata and python-zipp really do seem to be pointing >>> at each other: >>> >>> After? removing both packages, and attempting to re-install (with >>> sboinstall or manually): >>> >>> The python-zipp build bombs with: >>> >>> ERROR Missing dependencies: >>> ????????? setuptools_scm[toml]>=3.4.1 >>> ????????? importlib-metadata>=4.6 >>> >>> while python-importlib_metadata seems to need python-zipp, bombing >>> with: >>> >>> ERROR Missing dependencies: >>> ????????? setuptools_scm[toml]>=3.4.1 >>> ????????? importlib-metadata>=4.6 -> zipp>=3.20 >>> >>> I? don't understand why? it's complaining about setuptools_scm ... I >>> seem to have it: >>> >>> /var/log/packages/python3-setuptools-scm-opt-8.3.1-noarch-1_SBo >>> /var/log/packages/python-setuptools_scm-6.3.2-x86_64-1 >>> /var/log/packages/python3-setuptools_scm_git_archive-1.4.1-x86_64-1_SBo >>> >>> ... though not sure which (if? any) of these packages is the one it >>> wants. >>> >>> So I'm stuck? again.? Anyone have a next step? to suggest? >>> >>> At least I got python3-setuptools-opt installed. >>> >>> thanks! >>> >>> Judah >>> >> Hi Judah, >> >> This is the full dependency list required for python-zipp, from my >> local build log (I use slackrepo to build in a clean chroot): >> >> Building python/python-zipp (rebuild for updated deps) 2026-02-03 >> 15:47:51 >> Verifying source files ... >> Installing dependencies ... >> python3-flit_core-3.12.0-x86_64-1_SBo: Simplified pkging of Python >> modules, core b [ 180K] >> python3-installer-0.7.0-x86_64-6_SBo: Library for installing Python >> packages from? [ 1.1M] >> python3-pyproject-hooks-1.2.0-x86_64-1_SBo: Wrappers to call PEP 517 >> build backend [ 120K] >> python3-build-1.3.0-x86_64-1_SBo: a simple, correct PEP517 package >> builder ....... [ 230K] >> python3-packaging-opt-26.0-noarch-1_SBo: Install packaging in /opt >> ............... [ 740K] >> python3-wheel-0.45.1-x86_64-1_SBo: A built-package format for Python >> ............. [ 650K] >> python3-setuptools-opt-80.10.2-x86_64-1_SBo: Install setuptools from >> -current in / [ 9.6M] >> Running python-zipp.SlackBuild ...????????????????????????????????? >> ETA 15:48:?? >> >> ... >> >> Built ok: python-zipp-3.21.0-x86_64-11_SBo.txz 15:47:53 >> Unmounting chroot ... >> Backed up: python-zipp-3.21.0-x86_64-10_SBo.txz >> :-) python/python-zipp Rebuilt for updated deps (-: >> >> >> >> >> Erich >> > -- ===== milgram at cgpp.com 301-257-7069 From dickson.tim at googlemail.com Mon Jun 1 10:12:31 2026 From: dickson.tim at googlemail.com (Tim Dickson) Date: Mon, 1 Jun 2026 11:12:31 +0100 Subject: [Slackbuilds-users] issue submitting new slackbuild In-Reply-To: References: <139461f6-ea9b-40ec-953b-34c4886a6c3b@googlemail.com> Message-ID: it is. that is why it is odd. i haven't had issues before. this tar.gz was created slightly differently from the usual ones I submit, to ensure correct permissions. in my project build script I have tar --mode='644' --exclude="$PKGNAME/$PKGNAME.SlackBuild" -cf $PKGNAME.tar $PKGNAME tar --mode='755' -rf $PKGNAME.tar "$PKGNAME/$PKGNAME.SlackBuild" gzip -f $PKGNAME.tar which ensures the permissions are correct, but the resultant tar.gz is ok. with the elilong.tar.gz in /tmp/ cd /tmp/ tar -xvf elilong.tar.gz gives tree elilong elilong ??? README ??? doinst.sh ??? elilong.SlackBuild ??? elilong.info ??? slack-desc On 31/05/2026 21:54, Arnaud wrote: > The files needs to be inside a directory named by the name of the > package, here : > elilong/elilong.info > etc. > > - Yth. > -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From rizitis at gmail.com Mon Jun 1 10:22:19 2026 From: rizitis at gmail.com (=?UTF-8?B?zpnPic6szr3Ovc63z4I=?=) Date: Mon, 1 Jun 2026 13:22:19 +0300 Subject: [Slackbuilds-users] issue submitting new slackbuild In-Reply-To: References: <139461f6-ea9b-40ec-953b-34c4886a6c3b@googlemail.com> Message-ID: Please install https://slackbuilds.org/repository/15.0/system/sbo-maintainer-tools then cmd: *sbolint* elilong.tar.gz if this print errors then you know what is wrong. If it says all good then it might be a submission form issue. NOTE: you can also cmd: *sbopkglin*t /tmp/elilong-xxxx_sbo.tgz and see if its ok! These tools save a lot of time in real life! ???? ??? 1 ???? 2026 ???? 1:12??.?., ?/? Tim Dickson via SlackBuilds-users < slackbuilds-users at slackbuilds.org> ??????: > it is. that is why it is odd. i haven't had issues before. this tar.gz was > created slightly differently from the usual ones I submit, to ensure > correct permissions. > in my project build script I have > > tar --mode='644' --exclude="$PKGNAME/$PKGNAME.SlackBuild" -cf $PKGNAME.tar > $PKGNAME > tar --mode='755' -rf $PKGNAME.tar "$PKGNAME/$PKGNAME.SlackBuild" > gzip -f $PKGNAME.tar > > which ensures the permissions are correct, but the resultant tar.gz is ok. > with the elilong.tar.gz in /tmp/ > > cd /tmp/ > tar -xvf elilong.tar.gz gives > > tree elilong > elilong > ??? README > ??? doinst.sh > ??? elilong.SlackBuild > ??? elilong.info > ??? slack-desc > > > On 31/05/2026 21:54, Arnaud wrote: > > The files needs to be inside a directory named by the name of the package, > here : > elilong/elilong.info > etc. > > - Yth. > -- > > > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - https://slackbuilds.org/faq/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rizitis at gmail.com Mon Jun 1 10:23:58 2026 From: rizitis at gmail.com (=?UTF-8?B?zpnPic6szr3Ovc63z4I=?=) Date: Mon, 1 Jun 2026 13:23:58 +0300 Subject: [Slackbuilds-users] issue submitting new slackbuild In-Reply-To: References: <139461f6-ea9b-40ec-953b-34c4886a6c3b@googlemail.com> Message-ID: Update correct link: https://slackbuilds.org/repository/15.0/system/sbo-maintainer-tools/ ???? ??? 1 ???? 2026 ???? 1:22??.?., ?/? ??????? ??????: > Please install > https://slackbuilds.org/repository/15.0/system/sbo-maintainer-tools > then cmd: *sbolint* elilong.tar.gz > if this print errors then you know what is wrong. > If it says all good then it might be a submission form issue. > > NOTE: you can also cmd: *sbopkglin*t /tmp/elilong-xxxx_sbo.tgz > and see if its ok! > These tools save a lot of time in real life! > > ???? ??? 1 ???? 2026 ???? 1:12??.?., ?/? Tim Dickson via SlackBuilds-users > ??????: > >> it is. that is why it is odd. i haven't had issues before. this tar.gz >> was created slightly differently from the usual ones I submit, to ensure >> correct permissions. >> in my project build script I have >> >> tar --mode='644' --exclude="$PKGNAME/$PKGNAME.SlackBuild" -cf >> $PKGNAME.tar $PKGNAME >> tar --mode='755' -rf $PKGNAME.tar "$PKGNAME/$PKGNAME.SlackBuild" >> gzip -f $PKGNAME.tar >> >> which ensures the permissions are correct, but the resultant tar.gz is >> ok. >> with the elilong.tar.gz in /tmp/ >> >> cd /tmp/ >> tar -xvf elilong.tar.gz gives >> >> tree elilong >> elilong >> ??? README >> ??? doinst.sh >> ??? elilong.SlackBuild >> ??? elilong.info >> ??? slack-desc >> >> >> On 31/05/2026 21:54, Arnaud wrote: >> >> The files needs to be inside a directory named by the name of the >> package, here : >> elilong/elilong.info >> etc. >> >> - Yth. >> -- >> >> >> _______________________________________________ >> SlackBuilds-users mailing list >> SlackBuilds-users at slackbuilds.org >> https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users >> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ >> FAQ - https://slackbuilds.org/faq/ >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From dickson.tim at googlemail.com Mon Jun 1 10:43:10 2026 From: dickson.tim at googlemail.com (Tim Dickson) Date: Mon, 1 Jun 2026 11:43:10 +0100 Subject: [Slackbuilds-users] issue submitting new slackbuild In-Reply-To: References: <139461f6-ea9b-40ec-953b-34c4886a6c3b@googlemail.com> Message-ID: thanks. I already have installed and run sbolint (it's in my project build script), which halts with a warning if it fails sbolint. Needless to say, it passes sbolint with just a single note. no warnings or errors. i think it is a submit form issue. can anyone confirm or otherwise. if anyone wants the slackbuild to check, I can email it. it's less than 3k regards, Tim From rizitis at gmail.com Mon Jun 1 10:59:28 2026 From: rizitis at gmail.com (=?UTF-8?B?zpnPic6szr3Ovc63z4I=?=) Date: Mon, 1 Jun 2026 13:59:28 +0300 Subject: [Slackbuilds-users] issue submitting new slackbuild In-Reply-To: References: <139461f6-ea9b-40ec-953b-34c4886a6c3b@googlemail.com> Message-ID: I downloaded you slackbuild from https://sourceforge.net/projects/elilong/files/ and rename it from elilong-0.1.9-slackbuild.tar.gz to elilong.tar.gz (which is the correct for SBo) then I run : sbolint elilong.tar.gz elilong: ERR: README must be mode 0644, not 0755 elilong: ERR: slack-desc must be mode 0644, not 0755 elilong: ERR: elilong.info must be mode 0644, not 0755 elilong: ERR: elilong.SlackBuild:28: TAG=${TAG:-_SBo} is required elilong: ERR: doinst.sh must be mode 0644, not 0755 elilong: NOTE: elilong.SlackBuild:55: LIBDIRSUFFIX gets set, but never used. elilong: ERR: doinst.sh must be mode 0644, not 0755 sbolint: elilong: errors 6, warnings 0 Can you upload the original elilong.tar.gz some were ? I dont want to send me a file directly, make it public and we will take a view... ???? ??? 1 ???? 2026 ???? 1:43??.?., ?/? Tim Dickson via SlackBuilds-users < slackbuilds-users at slackbuilds.org> ??????: > thanks. I already have installed and run sbolint (it's in my project > build script), which halts with a warning if it fails sbolint. > Needless to say, it passes sbolint with just a single note. no warnings > or errors. > i think it is a submit form issue. can anyone confirm or otherwise. > if anyone wants the slackbuild to check, I can email it. it's less than 3k > regards, Tim > > > > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - https://slackbuilds.org/faq/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dickson.tim at googlemail.com Mon Jun 1 13:29:23 2026 From: dickson.tim at googlemail.com (Tim Dickson) Date: Mon, 1 Jun 2026 14:29:23 +0100 Subject: [Slackbuilds-users] issue submitting new slackbuild In-Reply-To: References: <139461f6-ea9b-40ec-953b-34c4886a6c3b@googlemail.com> Message-ID: <062a6cf0-40ac-4082-84aa-1591a918f5e0@googlemail.com> that slackbuild is the project slackbuild, rather than sbo slackbuild. The significant differences are the tag and the file permissions the relevant output of the slackbuild for sbo are as follows. ~/elilong# ls -l total 20 -rw-r--r-- 1 root root? 404 May 31 21:17 README -rw-r--r-- 1 root root? 287 May? 3 14:16 doinst.sh -rwxr-xr-x 1 root root 2980 Jun? 1 11:50 elilong.SlackBuild* -rw-r--r-- 1 root root? 307 Jun? 1 11:50 elilong.info -rw-r--r-- 1 root root? 917 May 30 14:48 slack-desc sbolint elilong: NOTE: elilong.SlackBuild:55: LIBDIRSUFFIX gets set, but never used. sbolint: elilong checks out OK sbopkglint /tmp/elilong-0.1.9-x86_64-1_SBo.tgz Using tests from /usr/share/sbo-maintainer-tools/sbopkglint.d Exploding /tmp/changes/tmp/elilong-0.1.9-x86_64-1_SBo.tgz to /tmp/SBo/sbopkglint.3vZRYL ...OK Running pre-doinst test...OK Installing /tmp/changes/tmp/elilong-0.1.9-x86_64-1_SBo.tgz to /tmp/SBo/sbopkglint.3vZRYL ...OK Running test: 05-basic-sanity...OK Running test: 10-docs...OK Running test: 15-noarch... ___ note: package might be a good candidate for noarch OK Running test: 20-arch...OK Running test: 25-lafiles...OK Running test: 30-manpages...OK Running test: 35-desktop...OK Running test: 40-newconfig...OK Running test: 45-doinst...OK Running test: 50-icons...OK Running test: 60-usr_info...OK Running test: 65-python...OK Running test: 70-tmp_path...OK Running test: 75-static_libs...OK Running test: 85-perl...OK === elilong-0.1.9-x86_64-1_SBo.tgz: All tests passed as you can see, the permissions are ok, and both sbolint and sbopkglint pass. Regardless of all that, the submission form should not report Submission failed: Could not find elilong/elilong.info Could not find elilong/README Could not find elilong/elilong.SlackBuild as the tar.gz file is ok. I've uploaded the sbo slackbuild I am trying to submit (to slackbuilds.org) to the sbo subdirectory on the sourceforge site if you want to see the actual elilong.tar.gz sbo slackbuild archive https://sourceforge.net/projects/elilong/files/sbo/ From rizitis at gmail.com Mon Jun 1 13:47:15 2026 From: rizitis at gmail.com (=?UTF-8?B?zpnPic6szr3Ovc63z4I=?=) Date: Mon, 1 Jun 2026 16:47:15 +0300 Subject: [Slackbuilds-users] issue submitting new slackbuild In-Reply-To: <062a6cf0-40ac-4082-84aa-1591a918f5e0@googlemail.com> References: <139461f6-ea9b-40ec-953b-34c4886a6c3b@googlemail.com> <062a6cf0-40ac-4082-84aa-1591a918f5e0@googlemail.com> Message-ID: The tarball has a broken directory permission the execute bit is missing: drw-r--r-- root/root 0 ... elilong/ Without the execute bit, no one can chdir into it, which is exactly what sbolint tries to do hence the "Permission denied". The reason it works on your side is likely that you're running sbolint as root, and root bypasses execute permission checks on directories. Running it as a regular user reproduces the error immediately. For SBo submissions, directories should be 755 sbolint elilong.tar.gz sbolint: chdir(/tmp/sbolint.810376379/elilong): Permission denied tar -tvzf elilong.tar.gz | head -3 drw-r--r-- root/root 0 2026-06-01 13:50 elilong/ -rw-r--r-- root/root 287 2026-05-03 16:16 elilong/doinst.sh -rw-r--r-- root/root 404 2026-05-31 23:17 elilong/README Also worth noting: the tarball was created in two steps (tar + gzip separately) instead of the usual: tar -czf elilong.tar.gz elilong/ This suggests your packaging workflow may not be applying the correct permissions before packing. It's worth double-checking how the tarball is being created. file elilong.tar.gz elilong.tar.gz: gzip compressed data, was "elilong.tar", last modified: Mon Jun 1 10:52:19 2026, from Unix, original size modulo 2^32 10240 ???? ??? 1 ???? 2026 ???? 4:29??.?., ?/? Tim Dickson via SlackBuilds-users < slackbuilds-users at slackbuilds.org> ??????: > that slackbuild is the project slackbuild, rather than sbo slackbuild. > The significant differences are the tag and the file permissions > the relevant output of the slackbuild for sbo are as follows. > > ~/elilong# ls -l > total 20 > -rw-r--r-- 1 root root 404 May 31 21:17 README > -rw-r--r-- 1 root root 287 May 3 14:16 doinst.sh > -rwxr-xr-x 1 root root 2980 Jun 1 11:50 elilong.SlackBuild* > -rw-r--r-- 1 root root 307 Jun 1 11:50 elilong.info > -rw-r--r-- 1 root root 917 May 30 14:48 slack-desc > sbolint > elilong: NOTE: elilong.SlackBuild:55: LIBDIRSUFFIX gets set, but never > used. > sbolint: elilong checks out OK > > sbopkglint /tmp/elilong-0.1.9-x86_64-1_SBo.tgz > Using tests from /usr/share/sbo-maintainer-tools/sbopkglint.d > Exploding /tmp/changes/tmp/elilong-0.1.9-x86_64-1_SBo.tgz to > /tmp/SBo/sbopkglint.3vZRYL ...OK > Running pre-doinst test...OK > Installing /tmp/changes/tmp/elilong-0.1.9-x86_64-1_SBo.tgz to > /tmp/SBo/sbopkglint.3vZRYL ...OK > Running test: 05-basic-sanity...OK > Running test: 10-docs...OK > Running test: 15-noarch... > ___ note: package might be a good candidate for noarch > OK > Running test: 20-arch...OK > Running test: 25-lafiles...OK > Running test: 30-manpages...OK > Running test: 35-desktop...OK > Running test: 40-newconfig...OK > Running test: 45-doinst...OK > Running test: 50-icons...OK > Running test: 60-usr_info...OK > Running test: 65-python...OK > Running test: 70-tmp_path...OK > Running test: 75-static_libs...OK > Running test: 85-perl...OK > === elilong-0.1.9-x86_64-1_SBo.tgz: All tests passed > > as you can see, the permissions are ok, and both sbolint and sbopkglint > pass. > > Regardless of all that, the submission form should not report > > Submission failed: > Could not find elilong/elilong.info > Could not find elilong/README > Could not find elilong/elilong.SlackBuild > > as the tar.gz file is ok. > I've uploaded the sbo slackbuild I am trying to submit (to > slackbuilds.org) to the sbo subdirectory on the sourceforge site if you > want to see the actual elilong.tar.gz sbo slackbuild archive > https://sourceforge.net/projects/elilong/files/sbo/ > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - https://slackbuilds.org/faq/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dickson.tim at googlemail.com Mon Jun 1 22:52:43 2026 From: dickson.tim at googlemail.com (Tim Dickson) Date: Mon, 1 Jun 2026 23:52:43 +0100 Subject: [Slackbuilds-users] issue submitting new slackbuild In-Reply-To: References: <139461f6-ea9b-40ec-953b-34c4886a6c3b@googlemail.com> <062a6cf0-40ac-4082-84aa-1591a918f5e0@googlemail.com> Message-ID: <43327fec-b76f-4de5-9984-72906d80b216@googlemail.com> thanks rizitis for spotting the directory permissions. you are correct in that i did not see it, running as root I had no issues. ?I'm doing dev via kate on windows to a samba share which is also mounted on my dev machine (slackware) which makes permissions 777 which is why I have a less simple tar.gz generation in my integration script for this project. I'll sort that out, and resubmit. ... a few minutes later..... well the directory now has the correct permissions when testing by tar -xzf elilong.tar.gz as a regular user tar -xzf /mnt/smb1/slackware/software/elilongdev/sbo/elilong.tar.gz ls -l |grep elilong drwxr-xr-x 2 tim users? ?4096 Jun? 1 23:47 elilong/ ls -l elilong/ total 20 -rw-r--r-- 1 tim users? 424 Jun? 1 22:32 README -rw-r--r-- 1 tim users? 287 May? 3 14:16 doinst.sh -rwxr-xr-x 1 tim users 3124 Jun? 1 23:32 elilong.SlackBuild* -rw-r--r-- 1 tim users? 307 Jun? 1 23:32 elilong.info -rw-r--r-- 1 tim users? 917 May 30 14:48 slack-desc but the submissions form still gives me Submission failed: Could not find elilong/elilong.info Could not find elilong/README Could not find elilong/elilong.SlackBuild the file can be downloaded from https://sourceforge.net/projects/elilong/files/sbo/elilong.tar.gz/download regards, Tim From chris.willing at linux.com Mon Jun 1 23:22:16 2026 From: chris.willing at linux.com (Christoph Willing) Date: Tue, 2 Jun 2026 09:22:16 +1000 Subject: [Slackbuilds-users] issue submitting new slackbuild In-Reply-To: <43327fec-b76f-4de5-9984-72906d80b216@googlemail.com> References: <139461f6-ea9b-40ec-953b-34c4886a6c3b@googlemail.com> <062a6cf0-40ac-4082-84aa-1591a918f5e0@googlemail.com> <43327fec-b76f-4de5-9984-72906d80b216@googlemail.com> Message-ID: <10745e1c-6905-4d1e-bcca-0a76551fac80@linux.com> On 2/6/26 08:52, Tim Dickson via SlackBuilds-users wrote: > thanks rizitis for spotting the directory permissions. you are correct > in that i did not see it, running as root I had no issues. > > ?I'm doing dev via kate on windows to a samba share which is also > mounted on my dev machine (slackware) which makes permissions 777 > which is why I have a less simple tar.gz generation in my integration > script for this project. > > I'll sort that out, and resubmit. > > ... a few minutes later..... > > well the directory now has the correct permissions when testing by tar > -xzf elilong.tar.gz as a regular user > tar -xzf /mnt/smb1/slackware/software/elilongdev/sbo/elilong.tar.gz > ls -l |grep elilong > drwxr-xr-x 2 tim users? ?4096 Jun? 1 23:47 elilong/ > ls -l elilong/ > total 20 > -rw-r--r-- 1 tim users? 424 Jun? 1 22:32 README > -rw-r--r-- 1 tim users? 287 May? 3 14:16 doinst.sh > -rwxr-xr-x 1 tim users 3124 Jun? 1 23:32 elilong.SlackBuild* > -rw-r--r-- 1 tim users? 307 Jun? 1 23:32 elilong.info > -rw-r--r-- 1 tim users? 917 May 30 14:48 slack-desc > > but the submissions form still gives me > > Submission failed: > Could not find elilong/elilong.info > Could not find elilong/README > Could not find elilong/elilong.SlackBuild > > the file can be downloaded from > https://sourceforge.net/projects/elilong/files/sbo/elilong.tar.gz/download > That's strange. chris at d10:~$ tar xvf /storage/distfiles/elilong.tar.gz elilong/elilong.SlackBuild elilong/README elilong/doinst.sh elilong/elilong.info elilong/slack-desc chris at d10:~$ sbolint elilong/ sbolint: elilong checks out OK I wonder if the submission system isn't processing your latest submission? Perhaps an earlier (faulty) submission hasn't been properly replaced by the latest submission (which "checks out OK"). chris From urchlay at slackware.uk Mon Jun 1 23:58:56 2026 From: urchlay at slackware.uk (B. Watson) Date: Mon, 1 Jun 2026 19:58:56 -0400 (EDT) Subject: [Slackbuilds-users] issue submitting new slackbuild In-Reply-To: References: <139461f6-ea9b-40ec-953b-34c4886a6c3b@googlemail.com> Message-ID: <111267c9-7d94-fb4d-2423-982730c5f922@slackware.uk> On Mon, 1 Jun 2026, Tim Dickson via SlackBuilds-users wrote: > i think it is a submit form issue. can anyone confirm or otherwise. > if anyone wants the slackbuild to check, I can email it. it's less than 3k > regards, Tim Yes, please mail me the tarball. If there's something actually wrong with it, I'll add a check for whatever-it-is to sbolint. If there's nothing wrong with it, I'll have a look at the submit form processing and see what's going on there. From urchlay at slackware.uk Tue Jun 2 00:02:56 2026 From: urchlay at slackware.uk (B. Watson) Date: Mon, 1 Jun 2026 20:02:56 -0400 (EDT) Subject: [Slackbuilds-users] issue submitting new slackbuild In-Reply-To: <43327fec-b76f-4de5-9984-72906d80b216@googlemail.com> References: <139461f6-ea9b-40ec-953b-34c4886a6c3b@googlemail.com> <062a6cf0-40ac-4082-84aa-1591a918f5e0@googlemail.com> <43327fec-b76f-4de5-9984-72906d80b216@googlemail.com> Message-ID: <75557698-ed9d-c8b2-96eb-5ac1a3b9c555@slackware.uk> On Mon, 1 Jun 2026, Tim Dickson via SlackBuilds-users wrote: > the file can be downloaded from > https://sourceforge.net/projects/elilong/files/sbo/elilong.tar.gz/download Never mind my last message, I hadn't noticed this yet. Just to make sure: is the md5sum of this file supposed to be: ea473df1ded7d05d097607dd7f19af97 ...? From urchlay at slackware.uk Tue Jun 2 00:26:01 2026 From: urchlay at slackware.uk (B. Watson) Date: Mon, 1 Jun 2026 20:26:01 -0400 (EDT) Subject: [Slackbuilds-users] issue submitting new slackbuild In-Reply-To: <75557698-ed9d-c8b2-96eb-5ac1a3b9c555@slackware.uk> References: <139461f6-ea9b-40ec-953b-34c4886a6c3b@googlemail.com> <062a6cf0-40ac-4082-84aa-1591a918f5e0@googlemail.com> <43327fec-b76f-4de5-9984-72906d80b216@googlemail.com> <75557698-ed9d-c8b2-96eb-5ac1a3b9c555@slackware.uk> Message-ID: <1514e667-893b-de22-287b-eadb12d535d3@slackware.uk> Here's a thing: $ tar tvf elilong.tar.gz -rwxr-xr-x root/root 3124 2026-06-01 18:32 elilong/elilong.SlackBuild -rw-r--r-- root/root 424 2026-06-01 17:32 elilong/README -rw-r--r-- root/root 287 2026-05-03 09:16 elilong/doinst.sh -rw-r--r-- root/root 307 2026-06-01 18:32 elilong/elilong.info -rw-r--r-- root/root 917 2026-05-30 09:48 elilong/slack-desc There's no entry in the tar file for the containing directory. Normally the first archive member would be elilong/ (the dir itself). If I extract your tarball and then recreate it with a regular "tar cvfz", I get this: $ tar cvfz elilong.tar.gz elilong/ elilong/ elilong/README elilong/elilong.SlackBuild elilong/doinst.sh elilong/elilong.info elilong/slack-desc $ tar tvf elilong.tar.gz drwxr-xr-x urchlay/users 0 2026-06-01 20:17 elilong/ -rw-r--r-- urchlay/users 424 2026-06-01 17:32 elilong/README -rwxr-xr-x urchlay/users 3124 2026-06-01 18:32 elilong/elilong.SlackBuild -rw-r--r-- urchlay/users 287 2026-05-03 09:16 elilong/doinst.sh -rw-r--r-- urchlay/users 307 2026-06-01 18:32 elilong/elilong.info -rw-r--r-- urchlay/users 917 2026-05-30 09:48 elilong/slack-desc I can add a check to sbolint, when it's checking a tarball, which will complain if the tarball's first member isn't a directory, mode 755, named the same as PRGNAM/ (in this case, elilong/). This will let submitters catch and identify (and fix) the problem before submitting... but it's still not an ideal solution. Currently I'm looking at the server-side submission processor, to see why it fails when the enclosing dir isn't present in the tarball. It really shouldn't care... but obviously it does. From dickson.tim at googlemail.com Tue Jun 2 13:54:38 2026 From: dickson.tim at googlemail.com (Tim Dickson) Date: Tue, 2 Jun 2026 14:54:38 +0100 Subject: [Slackbuilds-users] issue submitting new slackbuild In-Reply-To: <1514e667-893b-de22-287b-eadb12d535d3@slackware.uk> References: <139461f6-ea9b-40ec-953b-34c4886a6c3b@googlemail.com> <062a6cf0-40ac-4082-84aa-1591a918f5e0@googlemail.com> <43327fec-b76f-4de5-9984-72906d80b216@googlemail.com> <75557698-ed9d-c8b2-96eb-5ac1a3b9c555@slackware.uk> <1514e667-893b-de22-287b-eadb12d535d3@slackware.uk> Message-ID: <66cdb2fe-3547-4e18-a44b-ca637ab20d51@googlemail.com> thanks B Watson for the extra info. I've modified my tar creation to specifically add the directory entry as the first item, which the form then accepted. At least you have an unexpected edge case. I guess the verifier was looking for permissions on a directory entry and didn't find one because the first entry was a file entry which included the directory which tar -xvf would create. regards, Tim From mrvladislavovich at gmail.com Wed Jun 3 04:59:41 2026 From: mrvladislavovich at gmail.com (=?UTF-8?B?0K7RgNC40Lkg0KHQvtGA0L7QutC40L0=?=) Date: Wed, 3 Jun 2026 08:59:41 +0400 Subject: [Slackbuilds-users] [PATCH] android-tools: drop heavy gtest dependency via inline header mocking Message-ID: Hello everyone! I would like to propose an optimization for the android-tools SlackBuild to eliminate its dependency on gtest (Google Test Framework). Currently, gtest is required to build android-tools, but compiling such a heavy testing framework just to get adb and fastboot feels redundant for everyday users. gtest is only used for upstream development unit tests. If we look closely at the build failure when gtest is missing, the only blocker is a single header include: #include inside libziparchive. It is used solely for the FRIEND_TEST macro, which is completely useless when we are not running tests anyway. Instead of adding a bulky .patch file to the repository, we can elegantly mock this header inline directly inside the SlackBuild script right before the build directory is created. Since vendor/libbase/include is already in the compiler's include paths, the mock header is picked up automatically: --- android-tools.SlackBuild_orig 2025-03-15 06:24:24.000000000 +0400 +++ android-tools.SlackBuild 2026-06-03 08:34:20.808218974 +0400 @@ -87,6 +87,10 @@ # Fix building with protobuf3 version 30 patch -p1 -d "vendor/extras" < $CWD/android-tools-35.0.2-fix-protobuf-30.0-compilation.patch +mkdir -p vendor/libbase/include/gtest && + echo "#define FRIEND_TEST(test_case_name, test_name)" > \ + vendor/libbase/include/gtest/gtest_prod.h + mkdir -p build cd build cmake \ I have successfully tested this on my environment (15.0 x86_64). android-tools compiles flawlessly without gtest being installed in the system at all. Attached is the diff for android-tools.SlackBuild. If this looks good, we can also safely remove gtest from the REQUIRES line in android-tools.info. What do you think? I hope this saves some CPU cycles and disk space for Slackware users. Best regards, MyRequiem. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.willing at linux.com Wed Jun 3 06:51:44 2026 From: chris.willing at linux.com (Christoph Willing) Date: Wed, 3 Jun 2026 16:51:44 +1000 Subject: [Slackbuilds-users] [PATCH] android-tools: drop heavy gtest dependency via inline header mocking In-Reply-To: References: Message-ID: <35c2fa2b-9898-43a0-ae57-eee451d43476@linux.com> On 3/6/26 14:59, ???? ??????? wrote: > Hello everyone! > > I would like to propose an optimization for the android-tools > SlackBuild to > eliminate its dependency on gtest (Google Test Framework). [snip] The main person to convince about a change is the maintainer of the android-tools SlackBuild. We are not really a democracy here such that SlackBuilds are changed by popular opinion. Although a very popular change may ultimately convince a maintainer, it's better form to contact them first. chris From milgram at cgpp.com Wed Jun 3 07:57:00 2026 From: milgram at cgpp.com (J. Milgram) Date: Wed, 3 Jun 2026 03:57:00 -0400 Subject: [Slackbuilds-users] updates to signal-desktop In-Reply-To: <20260513090759.231c3820@tuf15.slackie.org> References: <85bf14f2-5365-40a7-b800-5e3227cafe14@app.fastmail.com> <20260513090759.231c3820@tuf15.slackie.org> Message-ID: <9e567f7a-0c3a-4ca5-a8dd-8af6452196eb@cgpp.com> Thanks. Regarding that, a comment in my /etc/slackpkg/blacklist warns, "aaa_libraries should NOT be blacklisted!" ... Safe to ignore that for the new aaa_glibc-solibs-2.42-x86_64-1_slack15.0? Have the new signal-desktop SBo package installed - was worth the trouble. JM On 5/12/26 22:07, Willy Sudiarto Raharjo wrote: >> Is it as simple as upgradepkg on all of those? No special upgrade >> order? > yes, simple upgradepkg but you need to blacklist them in order not to > revert the process again if you wish to keep using the newer version > otherwise, next time you run slackpkg upgrade-all, you will get the > normal version in 15.0 patches, not from testing > > > -- > Willy Sudiarto Raharjo > > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - https://slackbuilds.org/faq/ > -- ===== milgram at cgpp.com 301-257-7069 From milgram at cgpp.com Wed Jun 3 07:57:53 2026 From: milgram at cgpp.com (J. Milgram) Date: Wed, 3 Jun 2026 03:57:53 -0400 Subject: [Slackbuilds-users] updates to signal-desktop In-Reply-To: References: Message-ID: <3e091760-c8f4-4d64-b7ef-7a44cc4ca980@cgpp.com> It's now beyond merely "uncomfortable" ... I fired it up earlier today and got a message "This version of signal-desktop has expired..." and it refuses to send messages. This is on signal-desktop-legacy version 8.1.0. On 5/7/26 13:36, Greg Tourte wrote: > Hi, > > I am getting more and more uncomfortable with not being able to have > signal-desktop updated. > > I realise that versions above 8.1 do not work with vanilla stable but > they do work with the glibc in the testing folder in -stable (and of > course they will work in -current). > > What I am proposing is to have a new signal-desktop-legacy package > with the latest version working on -stable without the testing glibc > and keep the signal-desktop package fully uptodate and a note in the > README file. > > Does this sound acceptable? > > Cheers > > Greg > > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - https://slackbuilds.org/faq/ > -- ===== milgram at cgpp.com 301-257-7069 From urchlay at slackware.uk Wed Jun 3 08:11:40 2026 From: urchlay at slackware.uk (B. Watson) Date: Wed, 3 Jun 2026 04:11:40 -0400 (EDT) Subject: [Slackbuilds-users] issue submitting new slackbuild In-Reply-To: References: <139461f6-ea9b-40ec-953b-34c4886a6c3b@googlemail.com> Message-ID: <9ab87e75-ca53-ab9d-cc9a-359aa37525f5@slackware.uk> On Mon, 1 Jun 2026, Tim Dickson via SlackBuilds-users wrote: > it is. that is why it is odd. i haven't had issues before. this tar.gz was created slightly differently from the usual ones I submit, to ensure correct permissions. > in my project build script I have > > tar --mode='644' --exclude="$PKGNAME/$PKGNAME.SlackBuild" -cf $PKGNAME.tar $PKGNAME > tar --mode='755' -rf $PKGNAME.tar "$PKGNAME/$PKGNAME.SlackBuild" > gzip -f $PKGNAME.tar OK, I am able to reproduce this: I created a tarball using exactly these commands (except for a different SlackBuild; I chose alsacap since it's small). $ tar tvf alsacap.tar.gz drw-r--r-- urchlay/users 0 2026-06-02 23:46 alsacap/ -rw-r--r-- urchlay/users 114 2026-06-02 23:39 alsacap/README -rw-r--r-- urchlay/users 102 2025-01-23 16:48 alsacap/doinst.sh -rw-r--r-- urchlay/users 72 2025-01-23 16:48 alsacap/douninst.sh -rw-r--r-- urchlay/users 292 2026-06-02 23:46 alsacap/alsacap.info -rw-r--r-- urchlay/users 788 2024-11-29 18:14 alsacap/slack-desc -rwxr-xr-x urchlay/users 2259 2026-06-02 23:46 alsacap/alsacap.SlackBuild The directory does exist in the tarball as the first member, but it has invalid permissions for a directory (0644, aka drw-r--r-). This explains why the submission form can't find the README, .info, .SlackBuild files: it extracts the tarball, then tries to cd into the dir, which files because you need +x permission to cd into a directory. When I submit this file, I get exactly the same errors you got: Submission failed: Could not find alsacap/alsacap.info Could not find alsacap/README Could not find alsacap/alsacap.SlackBuild (your errors of course said "elilong", not "alsacap"...) So now I know what to add to sbolint, to catch this specific problem. Also I may add a more specific error message to the submission form, it could actually say "Permission on alsacap/ directory is invalid (should be 755, not )". From 1.41421 at gmail.com Wed Jun 3 16:24:33 2026 From: 1.41421 at gmail.com (Luveh Keraph) Date: Wed, 3 Jun 2026 10:24:33 -0600 Subject: [Slackbuilds-users] updates to signal-desktop In-Reply-To: <3e091760-c8f4-4d64-b7ef-7a44cc4ca980@cgpp.com> References: <3e091760-c8f4-4d64-b7ef-7a44cc4ca980@cgpp.com> Message-ID: I concur. signal-desktop is not working any more under 15.0. Will it be possible to have it working under 15.0 without having to use glibc testing packages? Quite frankly, having to use them sounds scary. On Wed, Jun 3, 2026 at 1:58?AM J. Milgram via SlackBuilds-users < slackbuilds-users at slackbuilds.org> wrote: > > It's now beyond merely "uncomfortable" ... I fired it up earlier today > and got a message "This version of signal-desktop has expired..." and it > refuses to send messages. This is on signal-desktop-legacy version 8.1.0. > > > > > > > > On 5/7/26 13:36, Greg Tourte wrote: > > Hi, > > > > I am getting more and more uncomfortable with not being able to have > > signal-desktop updated. > > > > I realise that versions above 8.1 do not work with vanilla stable but > > they do work with the glibc in the testing folder in -stable (and of > > course they will work in -current). > > > > What I am proposing is to have a new signal-desktop-legacy package > > with the latest version working on -stable without the testing glibc > > and keep the signal-desktop package fully uptodate and a note in the > > README file. > > > > Does this sound acceptable? > > > > Cheers > > > > Greg > > > > _______________________________________________ > > SlackBuilds-users mailing list > > SlackBuilds-users at slackbuilds.org > > https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > > Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ > > FAQ - https://slackbuilds.org/faq/ > > > > -- > ===== > milgram at cgpp.com > 301-257-7069 > > > > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - https://slackbuilds.org/faq/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.egger at gmail.com Wed Jun 3 21:59:03 2026 From: matt.egger at gmail.com (Matt Egger) Date: Wed, 3 Jun 2026 17:59:03 -0400 Subject: [Slackbuilds-users] packaging question, makefile calls git Message-ID: Hi! I'm finalizing a Slackbuild for libgourou (https://forge.soutade.fr/soutade/libgourou). It has a build dependency on uPDFParser (same author). The makefile calls a script that clones and builds the library before compiling libgourou itself. Should I be generating a tarball for uPDFParser and handle building directly it in the Slackbuild? If so, I'd use system/incus-ui/get-incus-ui.sh as an example. How do I get the tarball hosted on sourceforge? Thanks, Matt From lumin+slackbuilds at etherlight.link Wed Jun 3 22:33:37 2026 From: lumin+slackbuilds at etherlight.link (Lumin Etherlight) Date: Thu, 04 Jun 2026 01:33:37 +0300 Subject: [Slackbuilds-users] updates to signal-desktop In-Reply-To: (Luveh Keraph's message of "Wed, 3 Jun 2026 10:24:33 -0600") References: <3e091760-c8f4-4d64-b7ef-7a44cc4ca980@cgpp.com> Message-ID: Luveh Keraph <1.41421 at gmail.com> writes: > I concur. signal-desktop is not working any more > under 15.0. Will it be possible to have it working > under 15.0 without having to use glibc testing > packages? Quite frankly, having to use them sounds > scary. You can use the following hack, which worked for me. Install the new testing glibc into a root inside /opt/ isolated from the rest of the system, then patch all executable and libraries inside the latest Signal package to use the glibc inside /opt instead of the system one. First, upgrade to the latest Signal package: upgradepkg --install-new signal-desktop-8.11.0-x86_64-1_SBo.tgz Then, get the testing glibc package: lftp ftp://ftp.slackware.com/pub/slackware/slackware64-15.0/testing/packages/binutils-gcc-glibc \ -e 'get -c glibc-2.42-x86_64-1_slack15.0.txz' Install it to a path in /opt (note the --root): installpkg --root /opt/glibc glibc-2.42-x86_64-1_slack15.0.txz Finally, use patchelf to update the runtime linker in all executable files, and use it again to override the linker library search path to use the latest installed glibc libraries: find /opt/Signal/ -type f -executable \ -exec patchelf --set-interpreter /opt/glibc/lib64/ld-linux-x86-64.so.2 {} \; \ -exec patchelf --force-rpath --set-rpath \$ORIGIN:/opt/glibc/lib64 {} \; The $ORIGIN path is required, as a literal string, with $ escaped from the shell; it is not a shell variable. This literal string has a special meaning to the linker to allow the executable, in this case Signal, to search its own directory for libraries. Additionally, do not be alarmed if you see errors about not finding `.interp' sections, they are harmless, and happen because the dynamic linker in shared libraries can not be updated in the ELF binary itself, but is set by the actual executable that requests the library. Now, run Signal as you usually do, it should work. Hopefully :) This is definitely a hacky path, but it is a much more narrow intervention than updating glibc for your entire system. It is also isolated from the rest of the system, so harm is minimized. If you want to revert what we did here, simply run: rm -rf /opt/glibc upgradepkg --reinstall signal-desktop-8.11.0-x86_64-1_SBo.tgz And you're back to a clean slate. Best Wishes, Lumin Etherlight From 1.41421 at gmail.com Wed Jun 3 22:55:11 2026 From: 1.41421 at gmail.com (Luveh Keraph) Date: Wed, 3 Jun 2026 16:55:11 -0600 Subject: [Slackbuilds-users] updates to signal-desktop In-Reply-To: References: <3e091760-c8f4-4d64-b7ef-7a44cc4ca980@cgpp.com> Message-ID: Thanks. I'll take a stab at it in a sandbox over the weekend. On Wed, Jun 3, 2026 at 4:33?PM Lumin Etherlight via SlackBuilds-users < slackbuilds-users at slackbuilds.org> wrote: > Luveh Keraph <1.41421 at gmail.com> writes: > > > I concur. signal-desktop is not working any more > > under 15.0. Will it be possible to have it working > > under 15.0 without having to use glibc testing > > packages? Quite frankly, having to use them sounds > > scary. > > You can use the following hack, which worked > for me. Install the new testing glibc into a root > inside /opt/ isolated from the rest of the system, > then patch all executable and libraries inside the > latest Signal package to use the glibc inside /opt > instead of the system one. > > First, upgrade to the latest Signal package: > > upgradepkg --install-new signal-desktop-8.11.0-x86_64-1_SBo.tgz > > Then, get the testing glibc package: > > lftp > ftp://ftp.slackware.com/pub/slackware/slackware64-15.0/testing/packages/binutils-gcc-glibc > \ > -e 'get -c glibc-2.42-x86_64-1_slack15.0.txz' > > Install it to a path in /opt (note the --root): > > installpkg --root /opt/glibc glibc-2.42-x86_64-1_slack15.0.txz > > Finally, use patchelf to update the runtime > linker in all executable files, and use it again > to override the linker library search path to use > the latest installed glibc libraries: > > find /opt/Signal/ -type f -executable \ > -exec patchelf --set-interpreter > /opt/glibc/lib64/ld-linux-x86-64.so.2 {} \; \ > -exec patchelf --force-rpath --set-rpath > \$ORIGIN:/opt/glibc/lib64 {} \; > > The $ORIGIN path is required, as a literal > string, with $ escaped from the shell; it is not a > shell variable. This literal string has a special > meaning to the linker to allow the executable, in > this case Signal, to search its own directory for > libraries. Additionally, do not be alarmed if you > see errors about not finding `.interp' sections, > they are harmless, and happen because the dynamic > linker in shared libraries can not be updated in > the ELF binary itself, but is set by the actual > executable that requests the library. > > Now, run Signal as you usually do, it should work. > > Hopefully :) > > This is definitely a hacky path, but it is a > much more narrow intervention than updating glibc > for your entire system. It is also isolated from > the rest of the system, so harm is minimized. If > you want to revert what we did here, simply run: > > rm -rf /opt/glibc > upgradepkg --reinstall signal-desktop-8.11.0-x86_64-1_SBo.tgz > > And you're back to a clean slate. > > > Best Wishes, > Lumin Etherlight > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - https://slackbuilds.org/faq/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From willysr at slackbuilds.org Wed Jun 3 23:45:54 2026 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Thu, 4 Jun 2026 06:45:54 +0700 Subject: [Slackbuilds-users] packaging question, makefile calls git In-Reply-To: References: Message-ID: <20260604064554.37aed793@home.slackie.org> >I'm finalizing a Slackbuild for libgourou >(https://forge.soutade.fr/soutade/libgourou). It has a build >dependency on uPDFParser (same author). The makefile calls a script >that clones and builds the library before compiling libgourou itself. > >Should I be generating a tarball for uPDFParser and handle building >directly it in the Slackbuild? If so, I'd use >system/incus-ui/get-incus-ui.sh as an example. How do I get the >tarball hosted on sourceforge? yes please, make a tarball and host it on SF let us know your SF username and i will add you -- Willy Sudiarto Raharjo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 870 bytes Desc: OpenPGP digital signature URL: From milgram at cgpp.com Thu Jun 4 04:03:24 2026 From: milgram at cgpp.com (J. Milgram) Date: Thu, 4 Jun 2026 00:03:24 -0400 Subject: [Slackbuilds-users] updates to signal-desktop In-Reply-To: References: <3e091760-c8f4-4d64-b7ef-7a44cc4ca980@cgpp.com> Message-ID: Re simply upgrading to the new packages: Some might consider it living dangerously, but as the README in the binutils-gcc-glibc directory points out: ===== You can always back them out by upgradepkg'ing to the older versions, but anything that you've compiled since installing these will stop working. ===== (https://mirrors.slackware.com/slackware/slackware64-15.0/testing/packages/binutils-gcc-glibc/README) So basically it was 15 upgradepkg's and done. I also blacklisted them in /etc/slackpkg/blacklist as Willy suggested. The system didn't miss a beat. Built one large-ish numerical app just as a sanity check and it went fine. I did notice that slackpkg upgrade-all offered to reinstall the original gcc-g++-11.2.0 - this, because I neglected to list it as "gcc-g\+\+" in the blacklist file. I'm sure that would have broken lots of things but it was easy just to uncheck it from the upgrade list. Just a report ... not advocating any particular approach. JM On 6/3/26 18:55, Luveh Keraph wrote: > Thanks. I'll take a stab at it in a sandbox over the weekend. > > On Wed, Jun 3, 2026 at 4:33?PM Lumin Etherlight via SlackBuilds-users > wrote: > > Luveh Keraph <1.41421 at gmail.com> writes: > > > I concur.? signal-desktop is? not working any more > > under 15.0. Will it be possible to have it working > > under? 15.0 without? having to? use glibc? testing > > packages? Quite frankly, having to use them sounds > > scary. > > ? ? ? ? You can use the following hack, which worked > ? for me.? Install the new testing glibc into a root > ? inside /opt/ isolated from the rest of the system, > ? then patch all executable and libraries inside the > ? latest Signal package to use the glibc inside /opt > ? instead of the system one. > > ? First, upgrade to the latest Signal package: > > ? ? ? ? upgradepkg --install-new > signal-desktop-8.11.0-x86_64-1_SBo.tgz > > ? Then, get the testing glibc package: > > ? ? ? ? lftp > ftp://ftp.slackware.com/pub/slackware/slackware64-15.0/testing/packages/binutils-gcc-glibc > \ > ? ? ? ? ? ? ?-e 'get -c glibc-2.42-x86_64-1_slack15.0.txz' > > ? Install it to a path in /opt (note the --root): > > ? ? ? ? installpkg --root /opt/glibc glibc-2.42-x86_64-1_slack15.0.txz > > ? ? ? ? Finally, use patchelf? to update the runtime > ? linker in? all executable files, and? use it again > ? to override the linker? library search path to use > ? the latest installed glibc libraries: > > ? ? ? ? find /opt/Signal/ -type f -executable \ > ? ? ? ? ? ? ? ? -exec patchelf --set-interpreter > /opt/glibc/lib64/ld-linux-x86-64.so.2 {} \; \ > ? ? ? ? ? ? ? ? -exec patchelf --force-rpath --set-rpath > \$ORIGIN:/opt/glibc/lib64 {} \; > > ? ? ? ? The $ORIGIN? path is required, as? a literal > ? string, with $ escaped from the shell; it is not a > ? shell variable.? This literal string has a special > ? meaning to the linker? to allow the executable, in > ? this case Signal, to? search its own directory for > ? libraries.? Additionally, do not be alarmed if you > ? see errors? about not finding? `.interp' sections, > ? they are harmless, and? happen because the dynamic > ? linker in? shared libraries can not? be updated in > ? the ELF? binary itself, but? is set by? the actual > ? executable that requests the library. > > ? Now, run Signal as you usually do, it should work. > > ? Hopefully :) > > ? ? ? ? This is definitely a hacky path, but it is a > ? much more narrow? intervention than updating glibc > ? for your entire system.? ?It is also isolated from > ? the rest of the system,? so harm is minimized.? If > ? you want to revert what we did here, simply run: > > ? ? ? ? rm -rf /opt/glibc > ? ? ? ? upgradepkg --reinstall signal-desktop-8.11.0-x86_64-1_SBo.tgz > > ? And you're back to a clean slate. > > > Best Wishes, > Lumin Etherlight > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - https://slackbuilds.org/faq/ > > > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - https://slackbuilds.org/faq/ > -- ===== milgram at cgpp.com 301-257-7069 From matt.egger at gmail.com Thu Jun 4 12:15:05 2026 From: matt.egger at gmail.com (Matt Egger) Date: Thu, 4 Jun 2026 08:15:05 -0400 Subject: [Slackbuilds-users] packaging question, makefile calls git In-Reply-To: <20260604064554.37aed793@home.slackie.org> References: <20260604064554.37aed793@home.slackie.org> Message-ID: Thanks, Willy. Will do. I'm brubarwal on sourceforge On Wed, Jun 3, 2026 at 7:46?PM Willy Sudiarto Raharjo wrote: > > >I'm finalizing a Slackbuild for libgourou > >(https://forge.soutade.fr/soutade/libgourou). It has a build > >dependency on uPDFParser (same author). The makefile calls a script > >that clones and builds the library before compiling libgourou itself. > > > >Should I be generating a tarball for uPDFParser and handle building > >directly it in the Slackbuild? If so, I'd use > >system/incus-ui/get-incus-ui.sh as an example. How do I get the > >tarball hosted on sourceforge? > > yes please, make a tarball and host it on SF > let us know your SF username and i will add you > > > -- > Willy Sudiarto Raharjo > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - https://slackbuilds.org/faq/ > From tonus1 at free.fr Thu Jun 4 20:06:35 2026 From: tonus1 at free.fr (Tonus) Date: Thu, 04 Jun 2026 22:06:35 +0200 Subject: [Slackbuilds-users] updates to signal-desktop In-Reply-To: (Lumin Etherlight via SlackBuilds-users's message of "Thu, 04 Jun 2026 01:33:37 +0300") References: <3e091760-c8f4-4d64-b7ef-7a44cc4ca980@cgpp.com> Message-ID: <87wlwe6pf8.fsf@Baldr.vingolf.info> Lumin Etherlight via SlackBuilds-users writes: > Luveh Keraph <1.41421 at gmail.com> writes: > >> I concur. signal-desktop is not working any more >> under 15.0. Will it be possible to have it working >> under 15.0 without having to use glibc testing >> packages? Quite frankly, having to use them sounds >> scary. > > You can use the following hack, which worked > for me. Install the new testing glibc into a root > inside /opt/ isolated from the rest of the system, > then patch all executable and libraries inside the > latest Signal package to use the glibc inside /opt > instead of the system one. Hi, Thanks a lot for this precise guide ! Works like a charm. -- Regards, Tonus. From lumin+slackbuilds at etherlight.link Thu Jun 4 23:32:28 2026 From: lumin+slackbuilds at etherlight.link (Lumin Etherlight) Date: Fri, 05 Jun 2026 02:32:28 +0300 Subject: [Slackbuilds-users] updates to signal-desktop In-Reply-To: <87wlwe6pf8.fsf@Baldr.vingolf.info> (Tonus via SlackBuilds-users's message of "Thu, 04 Jun 2026 22:06:35 +0200") References: <3e091760-c8f4-4d64-b7ef-7a44cc4ca980@cgpp.com> <87wlwe6pf8.fsf@Baldr.vingolf.info> Message-ID: Tonus via SlackBuilds-users writes: > Lumin Etherlight via SlackBuilds-users > writes: > >> Luveh Keraph <1.41421 at gmail.com> writes: >> >>> I concur. signal-desktop is not working any more >>> under 15.0. Will it be possible to have it working >>> under 15.0 without having to use glibc testing >>> packages? Quite frankly, having to use them sounds >>> scary. >> >> You can use the following hack, which worked >> for me. Install the new testing glibc into a root >> inside /opt/ isolated from the rest of the system, >> then patch all executable and libraries inside the >> latest Signal package to use the glibc inside /opt >> instead of the system one. > > Thanks a lot for this precise guide ! > Works like a charm. You're welcome :) I have some 6 devices for friends and family members that needed their Signal updated, thus I published the explanation on my site[1], and wrote a small rough shell script that installs the hack. Just scp your pre-built SlackBuilds Signal package and the script[2], then run it: sh slackware-signal-glibc-workaround.sh apply [1]: https://lumin.etherlight.link/c/2C2606/mf3gC [2]: https://lumin.etherlight.link/s/2C2606/saNeW/slackware-signal-glibc-workaround.sh Best Regards, Lumin Etherlight From willysr at slackbuilds.org Fri Jun 5 01:23:53 2026 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Fri, 5 Jun 2026 08:23:53 +0700 Subject: [Slackbuilds-users] packaging question, makefile calls git In-Reply-To: References: <20260604064554.37aed793@home.slackie.org> Message-ID: <20260605082353.6928ad98@tuf15.slackie.org> >Thanks, Willy. Will do. I'm brubarwal on sourceforge done -- Willy Sudiarto Raharjo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 870 bytes Desc: OpenPGP digital signature URL: From dickson.tim at googlemail.com Fri Jun 5 13:55:57 2026 From: dickson.tim at googlemail.com (Tim Dickson) Date: Fri, 5 Jun 2026 14:55:57 +0100 Subject: [Slackbuilds-users] issue submitting new slackbuild In-Reply-To: <9ab87e75-ca53-ab9d-cc9a-359aa37525f5@slackware.uk> References: <139461f6-ea9b-40ec-953b-34c4886a6c3b@googlemail.com> <9ab87e75-ca53-ab9d-cc9a-359aa37525f5@slackware.uk> Message-ID: <8f171791-2b58-418c-a8da-6a12509da388@googlemail.com> On 03/06/2026 09:11, B. Watson wrote: > > > On Mon, 1 Jun 2026, Tim Dickson via SlackBuilds-users wrote: > >> it is. that is why it is odd. i haven't had issues before. this >> tar.gz was created slightly differently from the usual ones I submit, >> to ensure correct permissions. >> in my project build script I have >> >> tar --mode='644' --exclude="$PKGNAME/$PKGNAME.SlackBuild" -cf >> $PKGNAME.tar $PKGNAME >> tar --mode='755' -rf $PKGNAME.tar "$PKGNAME/$PKGNAME.SlackBuild" >> gzip -f $PKGNAME.tar > > OK, I am able to reproduce this: I created a tarball using exactly > these commands (except for a different SlackBuild; I chose alsacap > since it's small). > > $ tar tvf alsacap.tar.gz drw-r--r-- urchlay/users???? 0 2026-06-02 > 23:46 alsacap/ > -rw-r--r-- urchlay/users?? 114 2026-06-02 23:39 alsacap/README > -rw-r--r-- urchlay/users?? 102 2025-01-23 16:48 alsacap/doinst.sh > -rw-r--r-- urchlay/users??? 72 2025-01-23 16:48 alsacap/douninst.sh > -rw-r--r-- urchlay/users?? 292 2026-06-02 23:46 alsacap/alsacap.info > -rw-r--r-- urchlay/users?? 788 2024-11-29 18:14 alsacap/slack-desc > -rwxr-xr-x urchlay/users? 2259 2026-06-02 23:46 > alsacap/alsacap.SlackBuild > > The directory does exist in the tarball as the first member, but it > has invalid permissions for a directory (0644, aka drw-r--r-). This > explains why the submission form can't find the README, .info, > .SlackBuild files: it extracts the tarball, then tries to cd into > the dir, which files because you need +x permission to cd into a > directory. > > When I submit this file, I get exactly the same errors you got: > > ?? Submission failed: > ?? Could not find alsacap/alsacap.info > ?? Could not find alsacap/README > ?? Could not find alsacap/alsacap.SlackBuild > > (your errors of course said "elilong", not "alsacap"...) > > So now I know what to add to sbolint, to catch this specific problem. > > Also I may add a more specific error message to the submission form, > it could actually say "Permission on alsacap/ directory is invalid > (should be 755, not )". Great. Of course when actually running tar -xzf project.tar.gz to extract everything, the permissions are fine; because during creation, the addition of the slackbuild to the tar with 755 permissions also sets the directory permissions in the tar to 755, correcting the earlier set 644 perms. :-) I'm not sure how you would verify that easily without actually extracting the files though. regards, Tim From 1.41421 at gmail.com Fri Jun 5 20:15:37 2026 From: 1.41421 at gmail.com (Luveh Keraph) Date: Fri, 5 Jun 2026 14:15:37 -0600 Subject: [Slackbuilds-users] Jellyfin problem Message-ID: This is something that I noticed quite a while ago, but forgot to report. But, since it has bitten me again today, I think it is high time I reported it. The /etc/rc.d/rc.jellyfin file contains (among other things) the following function: start() { if [ -x /opt/jellyfin/jellyfin/jellyfin ]; then if [ "$USER" = "" ]; then echo "Starting Jellyfin Media Server" /usr/bin/daemon --name=jellyfin --pidfile=/var/run/jellyfin.pid -- \ /opt/jellyfin/jellyfin/jellyfin \ -d $DATADIR \ -C $CACHEDIR \ -c $CONFIGDIR \ -l $LOGDIR else echo "Starting Jellyfin Media Server" /usr/bin/daemon --name=jellyfin --pidfile=/var/run/jellyfin.pid -- \ /opt/jellyfin/jellyfin/jellyfin \ -d $DATADIR \ -C $CACHEDIR \ -c $CONFIGDIR \ -l $LOGDIR \ -u $USER:$GROUP fi fi } When I launch this by hand from the command line as # /etc/rc.d/rc.jellyfin start USER is set to root, and therefore the else block of the conditional. When this happens the Jellyfin daemon won't start. Even more. nothing appears in its log file as a result. I notice that GROUP is not set, but setting to it root by hand makes no difference. The only way I have been able to get the Jellyfin daemon to start is to remove that -u $USER:GROUP line - effectively rendering the conditional useless. I am not aware of any tweaks to my Jellyfin or root environments that could account for this, and I have no clue why things don't work for me with that -u line. -------------- next part -------------- An HTML attachment was scrubbed... URL: From 1.41421 at gmail.com Fri Jun 5 20:17:21 2026 From: 1.41421 at gmail.com (Luveh Keraph) Date: Fri, 5 Jun 2026 14:17:21 -0600 Subject: [Slackbuilds-users] Jellyfin problem In-Reply-To: References: Message-ID: I forgot to write 'is executed' at the end of 'USER is set to root, and therefore the else block of the conditional'. On Fri, Jun 5, 2026 at 2:15?PM Luveh Keraph <1.41421 at gmail.com> wrote: > This is something that I noticed quite a while ago, but forgot to report. > But, since it has bitten me again today, I think it is high time I reported > it. > > The /etc/rc.d/rc.jellyfin file contains (among other things) the following > function: > > start() { > if [ -x /opt/jellyfin/jellyfin/jellyfin ]; then > if [ "$USER" = "" ]; then > echo "Starting Jellyfin Media Server" > /usr/bin/daemon --name=jellyfin > --pidfile=/var/run/jellyfin.pid > -- \ > /opt/jellyfin/jellyfin/jellyfin \ > -d $DATADIR \ > -C $CACHEDIR \ > -c $CONFIGDIR \ > -l $LOGDIR > else > echo "Starting Jellyfin Media Server" > /usr/bin/daemon --name=jellyfin > --pidfile=/var/run/jellyfin.pid > -- \ > /opt/jellyfin/jellyfin/jellyfin \ > -d $DATADIR \ > -C $CACHEDIR \ > -c $CONFIGDIR \ > -l $LOGDIR \ > -u $USER:$GROUP > fi > fi > } > > When I launch this by hand from the command line as > > # /etc/rc.d/rc.jellyfin start > > USER is set to root, and therefore the else block of the conditional. When > this happens the Jellyfin daemon won't start. Even more. nothing appears in > its log file as a result. I notice that GROUP is not set, but setting to it > root by hand makes no difference. > > The only way I have been able to get the Jellyfin daemon to start is to > remove that -u $USER:GROUP line - effectively rendering the conditional > useless. I am not aware of any tweaks to my Jellyfin or root environments > that could account for this, and I have no clue why things don't work for > me with that -u line. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex at dcclost.com Fri Jun 5 21:04:14 2026 From: alex at dcclost.com (Alexander Grotewohl) Date: Fri, 5 Jun 2026 21:04:14 +0000 Subject: [Slackbuilds-users] Jellyfin problem In-Reply-To: References: Message-ID: I emailed the maintainer of this slackbuild recently. -u is a parameter for "daemon" not for jellyfin. if you try to run as the user jellyfin in this case jellyfin will also need to own a directory for it's pid file and the script should be adjusted further. ________________________________ From: SlackBuilds-users on behalf of Luveh Keraph <1.41421 at gmail.com> Sent: Friday, 05 June 2026 16:17:21 To: SlackBuilds.org Users List Subject: Re: [Slackbuilds-users] Jellyfin problem I forgot to write 'is executed' at the end of 'USER is set to root, and therefore the else block of the conditional'. On Fri, Jun 5, 2026 at 2:15?PM Luveh Keraph <1.41421 at gmail.com> wrote: This is something that I noticed quite a while ago, but forgot to report. But, since it has bitten me again today, I think it is high time I reported it. The /etc/rc.d/rc.jellyfin file contains (among other things) the following function: start() { if [ -x /opt/jellyfin/jellyfin/jellyfin ]; then if [ "$USER" = "" ]; then echo "Starting Jellyfin Media Server" /usr/bin/daemon --name=jellyfin --pidfile=/var/run/jellyfin.pid -- \ /opt/jellyfin/jellyfin/jellyfin \ -d $DATADIR \ -C $CACHEDIR \ -c $CONFIGDIR \ -l $LOGDIR else echo "Starting Jellyfin Media Server" /usr/bin/daemon --name=jellyfin --pidfile=/var/run/jellyfin.pid -- \ /opt/jellyfin/jellyfin/jellyfin \ -d $DATADIR \ -C $CACHEDIR \ -c $CONFIGDIR \ -l $LOGDIR \ -u $USER:$GROUP fi fi } When I launch this by hand from the command line as # /etc/rc.d/rc.jellyfin start USER is set to root, and therefore the else block of the conditional. When this happens the Jellyfin daemon won't start. Even more. nothing appears in its log file as a result. I notice that GROUP is not set, but setting to it root by hand makes no difference. The only way I have been able to get the Jellyfin daemon to start is to remove that -u $USER:GROUP line - effectively rendering the conditional useless. I am not aware of any tweaks to my Jellyfin or root environments that could account for this, and I have no clue why things don't work for me with that -u line. -------------- next part -------------- An HTML attachment was scrubbed... URL: From 1.41421 at gmail.com Fri Jun 5 21:17:19 2026 From: 1.41421 at gmail.com (Luveh Keraph) Date: Fri, 5 Jun 2026 15:17:19 -0600 Subject: [Slackbuilds-users] Jellyfin problem In-Reply-To: References: Message-ID: Thanks. I have just tested and if the -u option is inserted between daemon and --name then it works. Would this not be something that ought to be changed in the rc.jellyfin file installed by the SlackBuilds installer? On Fri, Jun 5, 2026 at 3:04?PM Alexander Grotewohl wrote: > I emailed the maintainer of this slackbuild recently. > > -u is a parameter for "daemon" not for jellyfin. if you try to run as the > user jellyfin in this case jellyfin will also need to own a directory for > it's pid file and the script should be adjusted further. > > ------------------------------ > *From:* SlackBuilds-users on > behalf of Luveh Keraph <1.41421 at gmail.com> > *Sent:* Friday, 05 June 2026 16:17:21 > *To:* SlackBuilds.org Users List > *Subject:* Re: [Slackbuilds-users] Jellyfin problem > > I forgot to write 'is executed' at the end of 'USER is set to root, and > therefore the else block of the conditional'. > > On Fri, Jun 5, 2026 at 2:15?PM Luveh Keraph <1.41421 at gmail.com> wrote: > > This is something that I noticed quite a while ago, but forgot to report. > But, since it has bitten me again today, I think it is high time I reported > it. > > The /etc/rc.d/rc.jellyfin file contains (among other things) the following > function: > > start() { > if [ -x /opt/jellyfin/jellyfin/jellyfin ]; then > if [ "$USER" = "" ]; then > echo "Starting Jellyfin Media Server" > /usr/bin/daemon --name=jellyfin > --pidfile=/var/run/jellyfin.pid > -- \ > /opt/jellyfin/jellyfin/jellyfin \ > -d $DATADIR \ > -C $CACHEDIR \ > -c $CONFIGDIR \ > -l $LOGDIR > else > echo "Starting Jellyfin Media Server" > /usr/bin/daemon --name=jellyfin > --pidfile=/var/run/jellyfin.pid > -- \ > /opt/jellyfin/jellyfin/jellyfin \ > -d $DATADIR \ > -C $CACHEDIR \ > -c $CONFIGDIR \ > -l $LOGDIR \ > -u $USER:$GROUP > fi > fi > } > > When I launch this by hand from the command line as > > # /etc/rc.d/rc.jellyfin start > > USER is set to root, and therefore the else block of the conditional. When > this happens the Jellyfin daemon won't start. Even more. nothing appears in > its log file as a result. I notice that GROUP is not set, but setting to it > root by hand makes no difference. > > The only way I have been able to get the Jellyfin daemon to start is to > remove that -u $USER:GROUP line - effectively rendering the conditional > useless. I am not aware of any tweaks to my Jellyfin or root environments > that could account for this, and I have no clue why things don't work for > me with that -u line. > > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - https://slackbuilds.org/faq/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From urchlay at slackware.uk Fri Jun 5 23:29:37 2026 From: urchlay at slackware.uk (B. Watson) Date: Fri, 5 Jun 2026 19:29:37 -0400 (EDT) Subject: [Slackbuilds-users] issue submitting new slackbuild In-Reply-To: <8f171791-2b58-418c-a8da-6a12509da388@googlemail.com> References: <139461f6-ea9b-40ec-953b-34c4886a6c3b@googlemail.com> <9ab87e75-ca53-ab9d-cc9a-359aa37525f5@slackware.uk> <8f171791-2b58-418c-a8da-6a12509da388@googlemail.com> Message-ID: On Fri, 5 Jun 2026, Tim Dickson wrote: > Great. Of course when actually running tar -xzf project.tar.gz to extract > everything, the permissions are fine; because during creation, the addition > of the slackbuild to the tar with 755 permissions also sets the directory > permissions in the tar to 755, correcting the earlier set 644 perms. :-) Actually, no. Extracting a tarball with 0644 perms on the enclosing dir, actually creates the dir with 0644 perms and leaves it that way. > I'm not sure how you would verify that easily without actually extracting the > files though. Well, I don't have to. sbolint and the submission form both work by extracting the tarball. I've also made another discovery and a change to sbolint: The script permissions inside a submission tarball *don't actually matter*, so sbolint no longer requires it to be 755. It'll allow either 755 or 644. The submission form never cared about the file permissions inside the tarball, only the existence of the files. It only cares about the directory's perms because it extracts the tarball and then cd's into the dir (which will fail without +x on the dir). Since it fails to cd, it doesn't see any of the other files it's looking for, and gives the rather confusing error message that says it can't find the .SlackBuild, .info, slack-desc, or README files. Probably I'll change it so it still fails, but gives a better error message. In the ancient pre-git days, we wanted +x for the .SlackBuild because we actually served up the submission tarball for download... but we haven't done that in well over a decade now: we have a git hook that sets the perms to 644 when the files are checked into git, and the download tarballs on the website are created from the git repo, and the script that creates them sets the perms explicitly to 755. This means you will be able to create submission tarballs where the script's perms are either 0644 or 0755, and either way it'll be accepted by both sbolint and the web form. It's also worth mentioning... during development, there's no need to set +x on the SlackBuild either. When you test-run it, you can just run "sh foo.SlackBuild" (or "bash foo.SlackBuild") instead of "./foo.SlackBuild". From willysr at slackbuilds.org Sat Jun 6 01:16:44 2026 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sat, 6 Jun 2026 08:16:44 +0700 Subject: [Slackbuilds-users] Updates - 20260606.1 Message-ID: <20260606081644.296e5a0d@home.slackie.org> Hi Just heads-up we have a new meson in -stable, so we will start removing python3-meson-opt in SBo and change all the scripts that depends on it for next week's public update. Sat Jun 6 00:53:04 UTC 2026 audio/dopamine-bin: Updated for version 3.0.5 audio/mpdscribble: Remove redundant doc dir. audio/ocenaudio-bin: Updated for version 3.19.1 audio/vimpc: Update script. desktop/ClamAV-GUI: Fixed script desktop/lxqt-panel: Update for 2.4.1 desktop/naps2: Updated for version 8.2.1 (+new maintainer) desktop/simplenote: Updated for version 2.26.0. desktop/sun: Updated for version 2.5.3. desktop/xss-lock: Fix inappropriate cp -a. development/Kiro: Updated for version 0.12.292. development/SQLAlchemy: Updated for version 2.0.50. development/aws-cdk: Updated for version 2.1126.0. development/claude-code: Upgraded for version 2.1.161 development/composer: Updated for version 2.10.1 development/deno: Updated for version 2.8.2. development/electron-bin: Updated for version 42.3.0 development/forgejo: Switch to nodejs22. development/gcli: Updated for version 2.12.0. development/google-go-lang: Updated for version 1.26.4. development/hoppscotch: Updated for version 26.5.0. development/jujutsu: Updated for version 0.42.0 development/jupyter-notebook: Updated for version 7.5.7 development/jupyterlab: Updated for version 4.5.8 development/kotlin: Updated for version 2.4.0. development/lm-studio-bin: Updated for version 0.4.15.2 development/mkchroot: Updated for version 1.6 development/nccl: Added (GPU Library). development/notepad++: Updated for version 8.9.6.2 development/open-inventor: Apply upstream demo patch. development/openmodelica: fix omcompiler-generated Makefiles. development/php84: Updated for version 8.4.22 development/pnpm: Updated for version 10.34.1. development/poedit: Updated for version 3.9.1. development/sbcl: Updated for version 2.6.5 development/scala3: Updated for version 3.8.4. development/sourcegit: Updated for version 2026.12 development/tiled: Updated for version 1.12.2. development/uncrustify: Updated for version 0.83.0 development/vscode-bin: Updated for version 1.123.0. development/zed-editor-bin: Updated for version 1.5.3. games/Mindustry: Updated for version 158.1 games/emulationstation-de: Updated for version 2.2.1. gis/google-earth: Updated for version 7.3.7.1155. graphics/converseen: Updated for version 0.15.2.5. ham/tqsl: Updated for version 2.8.6. ham/tucnak: Updated for version 4.72. libraries/SDL3: Updated for version 3.4.10 libraries/avm: Added (AOM Video Models). libraries/dav2d: Added (AV2 Decoder). libraries/libavif: Updated for version 1.4.2 libraries/libcoap: Updated for version 4.3.5b. libraries/libfilezilla: Updated for version 0.56.1. libraries/libgav1: Added (Open Video Codec). libraries/libmpdclient: Updated for version 2.24 libraries/librdkafka: Updated for version 2.14.2 libraries/librist: Updated for version 0.2.17 libraries/libslirp: Updated for version 4.9.3 libraries/libxnvctrl: Updated for version 595.80. libraries/libzia: Updated for version 4.72. libraries/python3-plumbum: Updated for version 2.0.0. libraries/swt: Added (SWT Library). libraries/tktray: Added (System Tray Extension). multimedia/tsduck: Updated for version 3.41.4299. network/AdGuardHome: Updated for version 0.107.77. network/betterbird-bin: Updated for version 140.11.0esr. network/brave-browser: update 1.90.128 network/caddy: Updated for version 2.11.4. network/chawan: Updated for version 0.4.2 network/cisco-secure-client-vpn: Updated for version 5.1.17.3394. network/dropbox: Updated for version 254.4.2518. network/filezilla: Updated for version 3.70.6. network/glance: Updated for version 0.8.5 network/grafana: Updated for version 13.0.2. network/halloy: Added (IRC Client). network/halloy: Fix permission. network/helium-browser: Updated for version 0.12.5.1 network/ipscan-bin: Added (IP Scanner). network/jitsi-meet-desktop: Updated for version 2026.6.0 network/landrun: update to 0.1.14 network/librewolf: Updated for version 151.0.2_1 network/microsoft-edge: Updated for version 148.0.3967.96. network/modemu2k: Updated for version 0.2.2. network/nordvpn-gui: Updated for version 5.0.0. network/nordvpn: Updated for version 5.0.0. network/opensmtpd: Updated for version 7.8.0p1. network/opera: Updated for version 132.0.5905.11 network/rclone: Updated for version 1.74.2 network/rustdesk: Updated for version 1.4.7. network/tailscale: Updated for version 1.98.3 network/tor-browser: Updated for version 15.0.15. network/vivaldi: Updated for version 8.0.4033.44. network/waterfox: Updated for version 6.6.14 network/zen-browser: Updated for version 1.20.1b office/hebcal: Updated for version 5.12.2. office/ledger-live: Updated for version 4.6.1 office/libgourou: Added (ADEPT protocol impl). office/python3-mintotp: Updated script. office/qownnotes: Updated for version 26.6.3. office/wps-office-dicts: Updated for version 26.2.4.2 perl/MoarVM: Updated for version 2026.05.1 perl/perl-http-daemon: Switch to Build.PL. python/python3-debugpy: Update for 1.8.21 python/python3-hatchling: Updated for version 1.30.1. python/python3-plotly: Updated for version 6.8.0 python/python3-pypdf: Updated for version 6.12.2 python/python3-trove-classifiers: Updated for version 2026.6.1.19. python/ruff-bin: Upgraded for version 0.15.15 python/ty-bin: Upgraded for version 0.0.42 system/alacritty: Updated for version 0.17.0. system/avfs: Updated for version 1.3.0 system/conky: Updated for version 1.24.0. system/docker-compose: Updated for version 5.1.4 system/dosbox-x: Updated for version 2026.06.02 system/elilong: Added (Boot Manager). system/freeipmi: Updated for version 1.6.18. system/fwupd: Updated for version 2.0.20. system/powershell: Updated for version 7.6.2. system/prometheus: Updated for version 3.12.0 system/squashfuse: Updated for version 0.6.2. system/torrent-file-editor: Updated for version 1.0.3. system/vifm: Updated for version 0.14.4. +--------------------------+ -- Willy Sudiarto Raharjo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 870 bytes Desc: OpenPGP digital signature URL: From willysr at slackbuilds.org Sat Jun 6 14:51:39 2026 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sat, 6 Jun 2026 21:51:39 +0700 Subject: [Slackbuilds-users] broken symlink or owner Message-ID: <20260606215139.38d04e26@home.slackie.org> Hello everyone we have just noticed a few things after observing this week's public update (the issue has persisted for a long time ago, but we never noticed it) that some scripts, despite passed the CI test, resulted in some broken symlinks or owners We urge maintainers to review their own scripts for following things: 1. If you want to copy certain file from your SlackBuild directory ($CWD), please use cat instead of cp. Please see this example: https://git.slackbuilds.org/slackbuilds/commit/?id=2f3b425e3 2. Please review the final doinst.sh. Some scripts has a symlink outside of the resulting package, most likely it linked to the build directory. So far, pghvlaans reported lammps and fonts-redhat (fixed). There might be others. this is an example of lammps (which is incorrect) ( cd usr/share/lammps/potentials ; ln -sf /var/cache/sbopkg/C_10_10.mesocnt C_10_10.mesocnt ) this is an example of fonts-redhat which has been fixed ( cd etc/fonts/conf.d ; rm -rf 60-overpass-fonts.conf ) ( cd etc/fonts/conf.d ; ln -sf ../conf.avail/60-overpass-fonts.conf 60-overpass-fonts.conf ) If you think you found some scripts failing with these same issue which is not your own scripts, please raise and issue in github/gitlab and please provide some evidence (doinst.sh is good example) Thank you -- Willy Sudiarto Raharjo -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 870 bytes Desc: OpenPGP digital signature URL: From zsd+slackbuilds at jdvb.ca Sat Jun 6 17:07:17 2026 From: zsd+slackbuilds at jdvb.ca (Jim) Date: Sat, 6 Jun 2026 14:07:17 -0300 Subject: [Slackbuilds-users] broken symlink or owner In-Reply-To: <20260606215139.38d04e26@home.slackie.org> References: <20260606215139.38d04e26@home.slackie.org> Message-ID: <20260606.170717.GD32068@x360.localdomain> On Sat, Jun 6, 2026 at 21:51 (+0700), Willy Sudiarto Raharjo wrote: > Hello everyone > we have just noticed a few things after observing this week's public update > (the issue has persisted for a long time ago, but we never noticed it) that > some scripts, despite passed the CI test, resulted in some broken symlinks or > owners > We urge maintainers to review their own scripts for following things: > 1. If you want to copy certain file from your SlackBuild directory ($CWD), > please use cat instead of cp. Please see this example: > https://git.slackbuilds.org/slackbuilds/commit/?id=2f3b425e3 ? The link points to an example where CHANGES and TODO are still copied with "cp". Is that example only considered to be partially fixed, or is this "use cat" advice only for certain peculiar files? I'm sort of curious... a lot of SlackBuilds have chown -R root:root . Would it be OK to instead just either do another recursive chown afterwards if there are no non-root owner/group permissions, or maybe change cp -a to cp -a --no-preserve=ownership In those cases where a lot of files are copied, using the above cp seems more expeditious than using a bunch of cat commands (or writing a loop). Thanks. Jim From urchlay at slackware.uk Sat Jun 6 20:09:26 2026 From: urchlay at slackware.uk (B. Watson) Date: Sat, 6 Jun 2026 16:09:26 -0400 (EDT) Subject: [Slackbuilds-users] broken symlink or owner In-Reply-To: <20260606.170717.GD32068@x360.localdomain> References: <20260606215139.38d04e26@home.slackie.org> <20260606.170717.GD32068@x360.localdomain> Message-ID: <6997f17c-5b4b-5c65-c996-25f6ad5ef06@slackware.uk> On Sat, 6 Jun 2026, Jim via SlackBuilds-users wrote: > The link points to an example where CHANGES and TODO are still copied with > "cp". Is that example only considered to be partially fixed, or is this > "use cat" advice only for certain peculiar files? The issue with cp is when copying files from $CWD, not from the extracted source. From fourtysixandtwo at sliderr.net Sun Jun 7 02:00:49 2026 From: fourtysixandtwo at sliderr.net (fourtysixandtwo) Date: Sat, 6 Jun 2026 20:00:49 -0600 Subject: [Slackbuilds-users] broken symlink or owner In-Reply-To: <6997f17c-5b4b-5c65-c996-25f6ad5ef06@slackware.uk> References: <20260606215139.38d04e26@home.slackie.org> <20260606.170717.GD32068@x360.localdomain> <6997f17c-5b4b-5c65-c996-25f6ad5ef06@slackware.uk> Message-ID: "cp -aL" would also fix the problem...dereference the link. On Sat, Jun 6, 2026 at 2:14?PM B. Watson wrote: > > > > On Sat, 6 Jun 2026, Jim via SlackBuilds-users wrote: > > > The link points to an example where CHANGES and TODO are still copied with > > "cp". Is that example only considered to be partially fixed, or is this > > "use cat" advice only for certain peculiar files? > > The issue with cp is when copying files from $CWD, not from the > extracted source. > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - https://slackbuilds.org/faq/ > -- _______________________________________________ SlackBuilds-users mailing list SlackBuilds-users at slackbuilds.org https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - https://slackbuilds.org/faq/ From urchlay at slackware.uk Sun Jun 7 03:01:25 2026 From: urchlay at slackware.uk (B. Watson) Date: Sat, 6 Jun 2026 23:01:25 -0400 (EDT) Subject: [Slackbuilds-users] broken symlink or owner In-Reply-To: References: <20260606215139.38d04e26@home.slackie.org> <20260606.170717.GD32068@x360.localdomain> <6997f17c-5b4b-5c65-c996-25f6ad5ef06@slackware.uk> Message-ID: <9ce47a36-f8eb-a08f-dc1c-ea277950f0f@slackware.uk> On Sat, 6 Jun 2026, fourtysixandtwo wrote: > "cp -aL" would also fix the problem...dereference the link. Just using cp (with no flags) generally would do the same. # mkdir a # cd a # touch a # ln -s a b # ls -l total 0 -rw-r--r-- 1 root root 0 Jun 6 22:53 a lrwxrwxrwx 1 root root 1 Jun 6 22:53 b -> a # cp b c # ls -l c -rw-r--r-- 1 root root 0 Jun 6 22:54 c "c" ends up a regular file, not a symlink. # cp -a b d # ls -l d lrwxrwxrwx 1 root root 1 Jun 6 22:53 d -> a ...with "cp -a", the destination ends up being a symlink. The intent of using "cp -a" is to preserve the timestamp, I suppose. But "cat $CWD/file > $PKG/path/file" doesn't preserve the timestamp either. Six of one, half a dozen of the other. So the rule should be: do not use "cp -a" to copy files from $CWD into $PKG. Not only does it risk creating broken symlinks, but your script doesn't know for a fact that root is the owner of the files in $CWD, and shouldn't make that assumption. From fourtysixandtwo at sliderr.net Sun Jun 7 03:56:17 2026 From: fourtysixandtwo at sliderr.net (fourtysixandtwo) Date: Sat, 6 Jun 2026 21:56:17 -0600 Subject: [Slackbuilds-users] broken symlink or owner In-Reply-To: <9ce47a36-f8eb-a08f-dc1c-ea277950f0f@slackware.uk> References: <20260606215139.38d04e26@home.slackie.org> <20260606.170717.GD32068@x360.localdomain> <6997f17c-5b4b-5c65-c996-25f6ad5ef06@slackware.uk> <9ce47a36-f8eb-a08f-dc1c-ea277950f0f@slackware.uk> Message-ID: True. What I like about cp -aL is being specific about it's operation...no assumption. On Sat, Jun 6, 2026 at 9:06?PM B. Watson wrote: > > > > On Sat, 6 Jun 2026, fourtysixandtwo wrote: > > > "cp -aL" would also fix the problem...dereference the link. > > Just using cp (with no flags) generally would do the same. > > # mkdir a > # cd a > # touch a > # ln -s a b > # ls -l > total 0 > -rw-r--r-- 1 root root 0 Jun 6 22:53 a > lrwxrwxrwx 1 root root 1 Jun 6 22:53 b -> a > # cp b c > # ls -l c > -rw-r--r-- 1 root root 0 Jun 6 22:54 c > > "c" ends up a regular file, not a symlink. > > # cp -a b d > # ls -l d > lrwxrwxrwx 1 root root 1 Jun 6 22:53 d -> a > > ...with "cp -a", the destination ends up being a symlink. > > The intent of using "cp -a" is to preserve the timestamp, I suppose. But > "cat $CWD/file > $PKG/path/file" doesn't preserve the timestamp either. > Six of one, half a dozen of the other. > > So the rule should be: do not use "cp -a" to copy files from $CWD into > $PKG. Not only does it risk creating broken symlinks, but your script > doesn't know for a fact that root is the owner of the files in $CWD, > and shouldn't make that assumption. > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - https://slackbuilds.org/faq/ > -- _______________________________________________ SlackBuilds-users mailing list SlackBuilds-users at slackbuilds.org https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - https://slackbuilds.org/faq/