From willysr at slackbuilds.org Mon Jul 1 06:34:29 2024 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Mon, 1 Jul 2024 13:34:29 +0700 Subject: [Slackbuilds-users] Updates - 20240629.1 In-Reply-To: References: Message-ID: <414437ad-b310-4624-b071-f5e86203c0f6@slackbuilds.org> > Looks like development/zeal didn't get merged for some reason > (https://github.com/SlackBuildsOrg/slackbuilds/pull/6909). Thanks for reporting i added to my branch already -- Willy Sudiarto Raharjo -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From bru.barwal at SDF.ORG Wed Jul 3 15:13:25 2024 From: bru.barwal at SDF.ORG (Bru Barwal) Date: Wed, 3 Jul 2024 15:13:25 +0000 Subject: [Slackbuilds-users] Guide on how to format github downloads? In-Reply-To: <47003c8c-c2ba-424d-ba44-328e9ef48e2e@slackbuilds.org> References: <08d8f257-e9ae-4ed9-92bd-d03d4be9b6c2@iotib.net> <72a3d16b2d2d745556a1ac223e39b194@iotib.net> <54abf552-ccfa-4cec-91aa-7ef86743fd2c@slackbuilds.org> <47003c8c-c2ba-424d-ba44-328e9ef48e2e@slackbuilds.org> Message-ID: On Mon, Jun 17, 2024 at 11:33:04AM +0700, Willy Sudiarto Raharjo wrote: > > Would it be possible to link all the guides somewhere on the site? They'll > > get posted on this mailing list and then might be forgotten in the future. > > > > I feel like there have been several linked on this mailing list, but the > > only other one I can think of right now is the using git to push updates > > guide that was based on one of my responses. > > > > Also, if there hasn't been one made, I'd love to see a naming guide for > > python packages or have it added to the submission/upload pages. It seems > > most are using the supported python version in the package name and > > separating python2/3 packages, but not all. Having a preferred SBo naming > > standard could help new maintainers make sure they name their packages > > consistently. > > i have updated the FAQ entries to include github, python2/3, > sbo-maintainer-tools, and github/gitlab PR/MR > > please let us know if you wish more info to be added in the FAQ sections Can you add this link (https://slackbuilds.org/SBo-Github-Workflows.txt) to the answer to FAQ #31 "I have experience with git. How do i contribute to SBo project using git?" Thanks! -- Matt Egger bru.barwal at sdf.org From radinc at mail.ru Wed Jul 3 12:00:45 2024 From: radinc at mail.ru (Roman Dyaba) Date: Wed, 3 Jul 2024 22:00:45 +1000 Subject: [Slackbuilds-users] Eclipse checksum mismatch Message-ID: <7b49e908-6321-4316-8a5c-1bc0fc1f77c0@mail.ru> see screenshot -- Roman Dyaba mail-to: radinc at mail.ru mob: +7 924 735 000 7 -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot_2024-07-03_21-51-21.png Type: image/png Size: 217826 bytes Desc: not available URL: From radinc at mail.ru Wed Jul 3 12:37:23 2024 From: radinc at mail.ru (Roman Dyaba) Date: Wed, 3 Jul 2024 22:37:23 +1000 Subject: [Slackbuilds-users] Eclipse checksum mismatch II Message-ID: <98ac5c04-bf49-4092-8fb4-aafce1386c1c@mail.ru> see screenshots -- Roman Dyaba mail-to: radinc at mail.ru mob: +7 924 735 000 7 -------------- next part -------------- A non-text attachment was scrubbed... Name: Screenshot_2024-07-03_22-36-25.png Type: image/png Size: 225462 bytes Desc: not available URL: From willysr at slackbuilds.org Thu Jul 4 02:09:44 2024 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Thu, 4 Jul 2024 09:09:44 +0700 Subject: [Slackbuilds-users] Eclipse checksum mismatch In-Reply-To: <7b49e908-6321-4316-8a5c-1bc0fc1f77c0@mail.ru> References: <7b49e908-6321-4316-8a5c-1bc0fc1f77c0@mail.ru> Message-ID: > see screenshot Fixed in my branch thanks for reporting -- Willy Sudiarto Raharjo -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x3F617144D7238786.asc Type: application/pgp-keys Size: 8363 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From willysr at slackbuilds.org Thu Jul 4 02:12:05 2024 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Thu, 4 Jul 2024 09:12:05 +0700 Subject: [Slackbuilds-users] Guide on how to format github downloads? In-Reply-To: References: <08d8f257-e9ae-4ed9-92bd-d03d4be9b6c2@iotib.net> <72a3d16b2d2d745556a1ac223e39b194@iotib.net> <54abf552-ccfa-4cec-91aa-7ef86743fd2c@slackbuilds.org> <47003c8c-c2ba-424d-ba44-328e9ef48e2e@slackbuilds.org> Message-ID: <168045e3-d723-441a-8a17-debc8506770d@slackbuilds.org> >> please let us know if you wish more info to be added in the FAQ sections > > Can you add this link (https://slackbuilds.org/SBo-Github-Workflows.txt) > to the answer to FAQ #31 "I have experience with git. How do > i contribute to SBo project using git?" Done, thanks -- Willy Sudiarto Raharjo -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x3F617144D7238786.asc Type: application/pgp-keys Size: 8363 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From willysr at slackbuilds.org Sat Jul 6 05:28:07 2024 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sat, 6 Jul 2024 12:28:07 +0700 Subject: [Slackbuilds-users] Updates - 20240706.1 Message-ID: <993ccdd5-6326-4e57-ac11-8590d33fab5c@slackbuilds.org> Sat Jul 6 05:21:11 UTC 2024 academic/qucs: Updated for version 0.0.20. academic/qucsator: Added (Circuit Simulator). audio/audacious-jack: Added (Audacious Plugin). desktop/ansiweather: Update dep. desktop/mint-l-icons: Updated for version 1.7.1. desktop/mint-l-theme: Updated for version 1.9.7. desktop/mint-themes: Update for 2.1.8 desktop/mousam: Update for 1.3.2 desktop/nwg-clipman: Updated for version 0.2.2. desktop/nwg-drawer: Updated for version 0.4.9. desktop/nwg-shell-config: Updated for version 0.5.42. desktop/nwg-shell: Updated for version 0.5.36. development/aws-cdk: Updated for version 2.147.3. development/cargo-c: Updated for version 0.10.2. development/d-tools: Updated for version 2.109.1 development/dmd: Updated for version 2.109.1 development/eclipse-cpp: Updated for version 4.32. development/eclipse-jee: Updated for version 4.32. development/eclipse-php: Updated for version 4.32. development/gnuradio: Updated for version 3.10.10.0, new maintainer. development/gr-osmosdr: Version 20240515_a6afeaa, new maintainer. development/jupyter-ipykernel: Update for 6.29.5 development/mongodb-compass: Updated for version 1.43.4. development/mysql-workbench: Updated for version 8.0.38. development/php82: Updated for version 8.2.21 development/protobuf3: Updated for version 27.2. development/sbcl: Updated for version 2.4.6. development/tea: updated for version 63.1.0 development/tiled: updated for version 1.11.0 development/uftrace: Updated for version 20240619_804ae6b development/zeal: Updated for version 0.7.1. games/ags: updated for version 3.6.1.25 games/ddnet: Updated for version 18.3.1 games/endless-sky: updated for version 0.10.8 games/principia: Updated for version 2024.06.28. games/tintin: Updated for version 2.02.41. games/vcmi: updated for version 1.5.3 games/warzone2100: updated for version 4.5.0 gis/cligj: Update for 0.7.2 (+new maintainer) graphics/tesseract: Updated for version 5.4.1. graphics/xmedcon: Updated for version 0.24.0. ham/gqrx-sdr: Updated for version 2.17, new maintainer. ham/rtl-sdr: Updated for version 20240423_619ac31, new maintainer. ham/sdrangel: Updated for version 7.21.4. libraries/libass: Note libunibreak as an optional dependency. libraries/librapidcheck: Fix build and information. libraries/qt-avif-image-plugin: Updated for version 0.8.3. libraries/rapidjson: Fix build on current. misc/KeePass: Updated for version 2.57. misc/bitwarden-desktop: updated for version 2024.6.4 multimedia/smplayer: Updated for version 24.5.0. multimedia/videomass: Updated for version 5.0.16. network/AdGuardHome: Updated for version 0.107.52. network/dillo: Updated for version 3.1.1. network/icyque: Removed (ICQ shutting down). network/nessus: Updated for version 10.7.4. network/telegram: Updated for version 5.2.0. network/telegram: Updated for version 5.2.2. network/vivaldi: Updated for version 6.8.3381.46. network/zoom-linux: Updated for version 6.1.1.443 office/grisbi: updated for version 3.0.4 perl/perl-Image-Info: Updated for version 1.44. perl/perl-Mail-DKIM: Updated for version 1.20240619. perl/perl-Mail-SPF: Updated for version 3.20240617. perl/perl-MailTools: Updated for version 2.21. perl/perl-http-message: Updated for version 6.46. perl/perl-net-dns: Updated for version 1.45. python/certbot-dns-cloudflare: Updated for version 2.11.0 python/munch: Update for 4.0.0 (+new maintainer) python/mypy: Updated for version 1.10.1. python/python3-alembic: updated for version 1.13.2 python/python3-authheaders: updated for version 0.16.3 python/python3-cairocffi: updated for version 1.7.1 python/python3-cloudflare: Updated for version 2.20.0 python/python3-debugpy: Update for 1.8.2 python/python3-dkimpy: updated for version 1.1.7 python/python3-enzyme: Version bump to 0.5.2 python/python3-gast: Version bump to 0.6.0 python/python3-pdm: Version bump to 2.16.1 python/python3-prompt_toolkit: updated for version 3.0.47 python/python3-pysubs2: Version bump to 1.7.2 python/python3-tenacity: Update for 8.4.2 python/python3-unearth: Version bump to 0.15.5 ruby/ruby-build: Updated for version 20240702. system/Iosevka-slab: Updated for version 30.3.0. system/Iosevka: Updated for version 30.3.0. system/OpenSnitch: Update for 1.6.6 system/adbfs-rootless: Added (Android Fuse FS). system/dosbox-x: updated for version 2024.07.01 system/dracut: updated to version 102 system/epson-inkjet-printer-escpr2: Updated for version 1.2.11. system/far2l: Updated for version 2.6.0. system/fastfetch: Updated for version 2.17.1. system/k3s: Updated to 1.30.2. system/kapacitor: Updated for version 1.7.5 system/mongodb: Use version that support OpenSSL 1.1. system/nix: Updated maintainer notice. system/nix: Updated to 2.13.6. system/pcp: Use a single build job on 32bit. system/pv: updated for version 1.8.10 system/redis-py: updated for version 5.0.7 system/restic: Updated for version 0.16.5 system/telegraf: Updated for version 1.31.0 system/terminator: Updated for version 2.1.4. system/unionfs-fuse: updated for version 3.5 +--------------------------+ -- Willy Sudiarto Raharjo -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From slack at giand.it Wed Jul 10 08:14:06 2024 From: slack at giand.it (=?UTF-8?Q?Giancarlo_Dess=C3=AC?=) Date: Wed, 10 Jul 2024 10:14:06 +0200 Subject: [Slackbuilds-users] bad permissions in /usr/share/mime Message-ID: <24c1e0b4-6df6-47c0-9dae-c04e97362d3c@giand.it> Hi, I'm updating the slackbuild for new version of QGIS (3.38.0). Usually this package is not affected by issues, but for this version this failure of sbopkglint occurred: ---usr/share/mime should not contain files with executable permission: -rwxr-xr-x 1 root root 373 lug 10 09:27 usr/share/mime/application/geopackage+sqlite3.xml -rwxr-xr-x 1 root root 383 lug 10 09:27 usr/share/mime/application/vnd.google-earth.kml+xml.xml -rwxr-xr-x 1 root root 386 lug 10 09:27 usr/share/mime/application/vnd.google-earth.kmz.xml -rwxr-xr-x 1 root root 347 lug 10 09:27 usr/share/mime/application/x-adobe-mif.xml -rwxr-xr-x 1 root root 398 lug 10 09:27 usr/share/mime/application/x-esri-crs.xml -rwxr-xr-x 1 root root 394 lug 10 09:27 usr/share/mime/application/x-esri-shape.xml -rwxr-xr-x 1 root root 376 lug 10 09:27 usr/share/mime/application/x-mapinfo-mif.xml -rwxr-xr-x 1 root root 446 lug 10 09:27 usr/share/mime/application/x-qgis-composer-template.xml -rwxr-xr-x 1 root root 430 lug 10 09:27 usr/share/mime/application/x-qgis-layer-definition.xml -rwxr-xr-x 1 root root 429 lug 10 09:27 usr/share/mime/application/x-qgis-layer-settings.xml -rwxr-xr-x 1 root root 451 lug 10 09:27 usr/share/mime/application/x-qgis-project-container.xml -rwxr-xr-x 1 root root 441 lug 10 09:27 usr/share/mime/application/x-qgis-project.xml -rwxr-xr-x 1 root root 368 lug 10 09:27 usr/share/mime/application/x-raster-aig.xml -rwxr-xr-x 1 root root 368 lug 10 09:27 usr/share/mime/application/x-raster-ecw.xml -rwxr-xr-x 1 root root 374 lug 10 09:27 usr/share/mime/application/x-raster-mrsid.xml -rwxr-xr-x 1 root root 389 lug 10 09:27 usr/share/mime/image/jp2.xml -rwxr-xr-x 1 root root 383 lug 10 09:27 usr/share/mime/image/jpeg.xml -rwxr-xr-x 1 root root 383 lug 10 09:27 usr/share/mime/image/tiff.xml FAILED These files don't appear in the package tree, so I think they are generated or modified during the installation by the following block of doinst.sh: if [ -x /usr/bin/update-mime-database ]; then ? /usr/bin/update-mime-database usr/share/mime >/dev/null 2>&1 fi Since doint.sh is the same of current and previous versions of the slackbuild, something should be wrong in some files of source, but I don't know where I have to check. Can someone help me? Thanks in advance -- ********************************************************* Giancarlo Dess? https://www.giand.it https://github.com/giandex Slackware Linux... because it works! ********************************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: From slack at giand.it Wed Jul 10 08:20:51 2024 From: slack at giand.it (=?UTF-8?Q?Giancarlo_Dess=C3=AC?=) Date: Wed, 10 Jul 2024 10:20:51 +0200 Subject: [Slackbuilds-users] bad permissions in /usr/share/mime In-Reply-To: <24c1e0b4-6df6-47c0-9dae-c04e97362d3c@giand.it> References: <24c1e0b4-6df6-47c0-9dae-c04e97362d3c@giand.it> Message-ID: Il 10/07/24 10:14, Giancarlo Dess? ha scritto: > > Hi, > > I'm updating the slackbuild for new version of QGIS (3.38.0). Usually > this package is not affected by issues, but for this version this > failure of sbopkglint occurred: > > ---usr/share/mime should not contain files with executable permission: > -rwxr-xr-x 1 root root 373 lug 10 09:27 > usr/share/mime/application/geopackage+sqlite3.xml > -rwxr-xr-x 1 root root 383 lug 10 09:27 > usr/share/mime/application/vnd.google-earth.kml+xml.xml > -rwxr-xr-x 1 root root 386 lug 10 09:27 > usr/share/mime/application/vnd.google-earth.kmz.xml > -rwxr-xr-x 1 root root 347 lug 10 09:27 > usr/share/mime/application/x-adobe-mif.xml > -rwxr-xr-x 1 root root 398 lug 10 09:27 > usr/share/mime/application/x-esri-crs.xml > -rwxr-xr-x 1 root root 394 lug 10 09:27 > usr/share/mime/application/x-esri-shape.xml > -rwxr-xr-x 1 root root 376 lug 10 09:27 > usr/share/mime/application/x-mapinfo-mif.xml > -rwxr-xr-x 1 root root 446 lug 10 09:27 > usr/share/mime/application/x-qgis-composer-template.xml > -rwxr-xr-x 1 root root 430 lug 10 09:27 > usr/share/mime/application/x-qgis-layer-definition.xml > -rwxr-xr-x 1 root root 429 lug 10 09:27 > usr/share/mime/application/x-qgis-layer-settings.xml > -rwxr-xr-x 1 root root 451 lug 10 09:27 > usr/share/mime/application/x-qgis-project-container.xml > -rwxr-xr-x 1 root root 441 lug 10 09:27 > usr/share/mime/application/x-qgis-project.xml > -rwxr-xr-x 1 root root 368 lug 10 09:27 > usr/share/mime/application/x-raster-aig.xml > -rwxr-xr-x 1 root root 368 lug 10 09:27 > usr/share/mime/application/x-raster-ecw.xml > -rwxr-xr-x 1 root root 374 lug 10 09:27 > usr/share/mime/application/x-raster-mrsid.xml > -rwxr-xr-x 1 root root 389 lug 10 09:27 usr/share/mime/image/jp2.xml > -rwxr-xr-x 1 root root 383 lug 10 09:27 usr/share/mime/image/jpeg.xml > -rwxr-xr-x 1 root root 383 lug 10 09:27 usr/share/mime/image/tiff.xml > FAILED > > These files don't appear in the package tree, so I think they are > generated or modified during the installation by the following block > of doinst.sh: > > if [ -x /usr/bin/update-mime-database ]; then > ? /usr/bin/update-mime-database usr/share/mime >/dev/null 2>&1 > fi > > Since doint.sh is the same of current and previous versions of the > slackbuild, something should be wrong in some files of source, but I > don't know where I have to check. > > Can someone help me? Thanks in advance > I verified just now that the issue occurs building the package in -current. In 15.0 stable sbopkglint doesn't report any error! :\ -- ********************************************************* Giancarlo Dess? https://www.giand.it https://github.com/giandex Slackware Linux... because it works! ********************************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: From matteo.bernardini at gmail.com Wed Jul 10 08:31:44 2024 From: matteo.bernardini at gmail.com (Matteo Bernardini) Date: Wed, 10 Jul 2024 10:31:44 +0200 Subject: [Slackbuilds-users] bad permissions in /usr/share/mime In-Reply-To: References: <24c1e0b4-6df6-47c0-9dae-c04e97362d3c@giand.it> Message-ID: Il giorno mer 10 lug 2024 alle ore 10:20 Giancarlo Dess? ha scritto: > Il 10/07/24 10:14, Giancarlo Dess? ha scritto: > > Hi, > > I'm updating the slackbuild for new version of QGIS (3.38.0). Usually this > package is not affected by issues, but for this version this failure of > sbopkglint occurred: > > --- usr/share/mime should not contain files with executable permission: > -rwxr-xr-x 1 root root 373 lug 10 09:27 > usr/share/mime/application/geopackage+sqlite3.xml > -rwxr-xr-x 1 root root 383 lug 10 09:27 > usr/share/mime/application/vnd.google-earth.kml+xml.xml > -rwxr-xr-x 1 root root 386 lug 10 09:27 > usr/share/mime/application/vnd.google-earth.kmz.xml > -rwxr-xr-x 1 root root 347 lug 10 09:27 > usr/share/mime/application/x-adobe-mif.xml > -rwxr-xr-x 1 root root 398 lug 10 09:27 > usr/share/mime/application/x-esri-crs.xml > -rwxr-xr-x 1 root root 394 lug 10 09:27 > usr/share/mime/application/x-esri-shape.xml > -rwxr-xr-x 1 root root 376 lug 10 09:27 > usr/share/mime/application/x-mapinfo-mif.xml > -rwxr-xr-x 1 root root 446 lug 10 09:27 > usr/share/mime/application/x-qgis-composer-template.xml > -rwxr-xr-x 1 root root 430 lug 10 09:27 > usr/share/mime/application/x-qgis-layer-definition.xml > -rwxr-xr-x 1 root root 429 lug 10 09:27 > usr/share/mime/application/x-qgis-layer-settings.xml > -rwxr-xr-x 1 root root 451 lug 10 09:27 > usr/share/mime/application/x-qgis-project-container.xml > -rwxr-xr-x 1 root root 441 lug 10 09:27 > usr/share/mime/application/x-qgis-project.xml > -rwxr-xr-x 1 root root 368 lug 10 09:27 > usr/share/mime/application/x-raster-aig.xml > -rwxr-xr-x 1 root root 368 lug 10 09:27 > usr/share/mime/application/x-raster-ecw.xml > -rwxr-xr-x 1 root root 374 lug 10 09:27 > usr/share/mime/application/x-raster-mrsid.xml > -rwxr-xr-x 1 root root 389 lug 10 09:27 usr/share/mime/image/jp2.xml > -rwxr-xr-x 1 root root 383 lug 10 09:27 usr/share/mime/image/jpeg.xml > -rwxr-xr-x 1 root root 383 lug 10 09:27 usr/share/mime/image/tiff.xml > FAILED > > These files don't appear in the package tree, so I think they are > generated or modified during the installation by the following block of > doinst.sh: > > if [ -x /usr/bin/update-mime-database ]; then > /usr/bin/update-mime-database usr/share/mime >/dev/null 2>&1 > fi > > Since doint.sh is the same of current and previous versions of the > slackbuild, something should be wrong in some files of source, but I don't > know where I have to check. > > Can someone help me? Thanks in advance > > > I verified just now that the issue occurs building the package in > -current. In 15.0 stable sbopkglint doesn't report any error! > > :\ > just add in the doinst.sh, after the block if [ -x /usr/bin/update-mime-database ]; then /usr/bin/update-mime-database usr/share/mime >/dev/null 2>&1 fi another line with chmod 0644 usr/share/mime/{application,image}/*.xml || true it should be harmless on 15.0... Matteo -------------- next part -------------- An HTML attachment was scrubbed... URL: From slack at giand.it Wed Jul 10 08:35:22 2024 From: slack at giand.it (=?UTF-8?Q?Giancarlo_Dess=C3=AC?=) Date: Wed, 10 Jul 2024 10:35:22 +0200 Subject: [Slackbuilds-users] bad permissions in /usr/share/mime In-Reply-To: References: <24c1e0b4-6df6-47c0-9dae-c04e97362d3c@giand.it> Message-ID: Il 10/07/24 10:31, Matteo Bernardini ha scritto: > chmod 0644 usr/share/mime/{application,image}/*.xml || true thanks Matteo, I'll try it. but I'm not sure if I have to add the line after or within the block. -- ********************************************************* Giancarlo Dess? https://www.giand.it https://github.com/giandex Slackware Linux... because it works! ********************************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: From matteo.bernardini at gmail.com Wed Jul 10 08:44:07 2024 From: matteo.bernardini at gmail.com (Matteo Bernardini) Date: Wed, 10 Jul 2024 10:44:07 +0200 Subject: [Slackbuilds-users] bad permissions in /usr/share/mime In-Reply-To: References: <24c1e0b4-6df6-47c0-9dae-c04e97362d3c@giand.it> Message-ID: Il giorno mer 10 lug 2024 alle ore 10:35 Giancarlo Dess? ha scritto: > Il 10/07/24 10:31, Matteo Bernardini ha scritto: > > chmod 0644 usr/share/mime/{application,image}/*.xml || true > > > thanks Matteo, I'll try it. > > but I'm not sure if I have to add the line after or within the block. > if you prefer you can modify the block like this if [ -x /usr/bin/update-mime-database ]; then /usr/bin/update-mime-database usr/share/mime >/dev/null 2>&1 /usr/bin/chmod 0644 usr/share/mime/{application,image}/*.xml >/dev/null 2>&1 || true fi Matteo -------------- next part -------------- An HTML attachment was scrubbed... URL: From slack at giand.it Wed Jul 10 08:48:30 2024 From: slack at giand.it (=?UTF-8?Q?Giancarlo_Dess=C3=AC?=) Date: Wed, 10 Jul 2024 10:48:30 +0200 Subject: [Slackbuilds-users] bad permissions in /usr/share/mime In-Reply-To: References: <24c1e0b4-6df6-47c0-9dae-c04e97362d3c@giand.it> Message-ID: <835ba94f-8992-4400-bc19-0cba4583835c@giand.it> Il 10/07/24 10:44, Matteo Bernardini ha scritto: > Il giorno mer 10 lug 2024 alle ore 10:35 Giancarlo Dess? > ha scritto: > > Il 10/07/24 10:31, Matteo Bernardini ha scritto: >> chmod 0644 usr/share/mime/{application,image}/*.xml || true > > > thanks Matteo, I'll try it. > > but I'm not sure if I have to add the line after or within the block. > > > if you prefer you can modify the block like this > > if [ -x /usr/bin/update-mime-database ]; then > ? /usr/bin/update-mime-database usr/share/mime >/dev/null 2>&1 > ? /usr/bin/chmod 0644 usr/share/mime/{application,image}/*.xml > >/dev/null 2>&1 || true > fi > > Matteo Thanks again :-) -- ********************************************************* Giancarlo Dess? https://www.giand.it https://github.com/giandex Slackware Linux... because it works! ********************************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: From slack at giand.it Wed Jul 10 09:01:57 2024 From: slack at giand.it (=?UTF-8?Q?Giancarlo_Dess=C3=AC?=) Date: Wed, 10 Jul 2024 11:01:57 +0200 Subject: [Slackbuilds-users] bad permissions in /usr/share/mime In-Reply-To: References: <24c1e0b4-6df6-47c0-9dae-c04e97362d3c@giand.it> Message-ID: <2d98ec01-cbf5-4a3b-b56a-b024ad11d20d@giand.it> Il 10/07/24 10:44, Matteo Bernardini ha scritto: > Il giorno mer 10 lug 2024 alle ore 10:35 Giancarlo Dess? > ha scritto: > > Il 10/07/24 10:31, Matteo Bernardini ha scritto: >> chmod 0644 usr/share/mime/{application,image}/*.xml || true > > > thanks Matteo, I'll try it. > > but I'm not sure if I have to add the line after or within the block. > > > if you prefer you can modify the block like this > > if [ -x /usr/bin/update-mime-database ]; then > ? /usr/bin/update-mime-database usr/share/mime >/dev/null 2>&1 > ? /usr/bin/chmod 0644 usr/share/mime/{application,image}/*.xml > >/dev/null 2>&1 || true > fi > > Matteo Solved, I tried with the line after the block, it works both in -current and stable -- ********************************************************* Giancarlo Dess? https://www.giand.it https://github.com/giandex Slackware Linux... because it works! ********************************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: From diniz.bortolotto at gmail.com Wed Jul 10 16:00:11 2024 From: diniz.bortolotto at gmail.com (Diniz Bortolotto) Date: Wed, 10 Jul 2024 13:00:11 -0300 Subject: [Slackbuilds-users] Taking over scrcpy SlackBuild In-Reply-To: References: Message-ID: Hi I didn't receive an answer to that email below until today. If you all agree I will take over this scrcpy package. BTW: maybe it could be useful to explain what is a "reasonable amount of time" in FAQ nr. 14. :-) Atenciosamente, Diniz Bortolotto ---------- Forwarded message --------- De: Diniz Bortolotto Date: qui., 27 de jun. de 2024 ?s 11:37 Subject: scrcpy SlackBuild To: Hi toolonely I've noticed that scrcpy is not updated since 2022. I'm writing to ask if you are able to keep taking care of this package or, if not, I could try takeover maintainership of this package. ;-) Atenciosamente, Diniz Bortolotto -------------- next part -------------- An HTML attachment was scrubbed... URL: From willysr at slackbuilds.org Thu Jul 11 02:08:32 2024 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Thu, 11 Jul 2024 09:08:32 +0700 Subject: [Slackbuilds-users] Taking over scrcpy SlackBuild In-Reply-To: References: Message-ID: <262f3eb8-a88c-4714-8771-bdc7020ffe1a@slackbuilds.org> > I didn't receive an answer to that email below until today. > If you all agree I will take over this scrcpy package. sure -- Willy Sudiarto Raharjo -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x3F617144D7238786.asc Type: application/pgp-keys Size: 8363 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From dev at iotib.net Thu Jul 11 19:02:54 2024 From: dev at iotib.net (Charadon) Date: Thu, 11 Jul 2024 15:02:54 -0400 Subject: [Slackbuilds-users] Questions with packaging a rust program. Message-ID: <8ed6251e-d288-4766-a6b1-fb58f8c9e31d@iotib.net> Hey all, I'm wanting to make a Slackbuild for BLAKE3. The issue is that it's made in rust. Now rust has a thing that makes it pretty easy to vendor (`cargo vendor`) the dependencies, the issue is that, unless upstream provides their own vendored tarball, you'll be making your own. So here are my questions: 1. Can I make a vendored tarball, upload it somewhere like archive.org and use that as a source? I know this is questionable security wise, but you should be able to replicate the archive using a `git clone` and `cargo vendor` 2. If not, can I include a script that downloads the source, runs cargo vendor, and makes a vendored tarball? 2. If not, how would you go about packaging a rust program? Is there any guide anywhere? From fourtysixandtwo at sliderr.net Thu Jul 11 19:42:20 2024 From: fourtysixandtwo at sliderr.net (fourtysixandtwo) Date: Thu, 11 Jul 2024 13:42:20 -0600 Subject: [Slackbuilds-users] Questions with packaging a rust program. In-Reply-To: <8ed6251e-d288-4766-a6b1-fb58f8c9e31d@iotib.net> References: <8ed6251e-d288-4766-a6b1-fb58f8c9e31d@iotib.net> Message-ID: Hi Charadon, I have been doing that for a little while now with some python/rust builds and filtering for a limited selection of linux rust targets to keep the size down. You'll want to install the "cargo-vendor-filterer" slackbuild first. Then have a look at my "python3-maturin" slackbuild. I include a stub "mkvendored.sh" script that calls another script I include with cargo-vendor-filterer "/usr/bin/cargo-mkvendored.sh". Let me know if you have any questions. Cheers On Thu, Jul 11, 2024 at 1:03?PM Charadon via SlackBuilds-users wrote: > > Hey all, > I'm wanting to make a Slackbuild for BLAKE3. The issue is that it's made > in rust. Now rust has a thing that makes it pretty easy to vendor > (`cargo vendor`) the dependencies, the issue is that, unless upstream > provides their own vendored tarball, you'll be making your own. > > So here are my questions: > > 1. Can I make a vendored tarball, upload it somewhere like archive.org > and use that as a source? I know this is questionable security wise, but > you should be able to replicate the archive using a `git clone` and > `cargo vendor` > 2. If not, can I include a script that downloads the source, runs cargo > vendor, and makes a vendored tarball? > 2. If not, how would you go about packaging a rust program? Is there any > guide anywhere? > _______________________________________________ > 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 dev at iotib.net Thu Jul 11 20:02:12 2024 From: dev at iotib.net (Charadon) Date: Thu, 11 Jul 2024 16:02:12 -0400 Subject: [Slackbuilds-users] Questions with packaging a rust program. In-Reply-To: References: <8ed6251e-d288-4766-a6b1-fb58f8c9e31d@iotib.net> Message-ID: <59f7f684-f140-48c0-8ad5-f69d125be3ee@iotib.net> Well i'm glad to know my idea for using a vendored tarball was already used in practice! Though, my vendor tarball won't have as prestigious of a mirror as slackware.uk, haha Guess I should ask Willy if archive.org or my own ftp site would be fine as a source, since it's all verified using md5 anyways. =P By the way, maybe you might want to make mkvendor.sh it's own package, as cargo-vendor-filterer is going to be included in the next version of Slackware. -----Original Message----- From: fourtysixandtwo [mailto:fourtysixandtwo at sliderr.net] Sent: Thursday, July 11, 2024 03:42 PM -04 To: "SlackBuilds.org Users List" Cc: Charadon Subject: [Slackbuilds-users] Questions with packaging a rust program. Importance: Low Hi Charadon, I have been doing that for a little while now with some python/rust builds and filtering for a limited selection of linux rust targets to keep the size down. You'll want to install the "cargo-vendor-filterer" slackbuild first. Then have a look at my "python3-maturin" slackbuild. I include a stub "mkvendored.sh" script that calls another script I include with cargo-vendor-filterer "/usr/bin/cargo-mkvendored.sh". Let me know if you have any questions. Cheers On Thu, Jul 11, 2024 at 1:03?PM Charadon via SlackBuilds-users wrote: Hey all, I'm wanting to make a Slackbuild for BLAKE3. The issue is that it's made in rust. Now rust has a thing that makes it pretty easy to vendor (`cargo vendor`) the dependencies, the issue is that, unless upstream provides their own vendored tarball, you'll be making your own. So here are my questions: 1. Can I make a vendored tarball, upload it somewhere like archive.org and use that as a source? I know this is questionable security wise, but you should be able to replicate the archive using a `git clone` and `cargo vendor` 2. If not, can I include a script that downloads the source, runs cargo vendor, and makes a vendored tarball? 2. If not, how would you go about packaging a rust program? Is there any guide anywhere? _______________________________________________ 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 Thu Jul 11 20:11:29 2024 From: urchlay at slackware.uk (B. Watson) Date: Thu, 11 Jul 2024 16:11:29 -0400 (EDT) Subject: [Slackbuilds-users] Questions with packaging a rust program. In-Reply-To: <59f7f684-f140-48c0-8ad5-f69d125be3ee@iotib.net> References: <8ed6251e-d288-4766-a6b1-fb58f8c9e31d@iotib.net> <59f7f684-f140-48c0-8ad5-f69d125be3ee@iotib.net> Message-ID: <83116154-1562-b128-c9d9-d739e2ae0a7@slackware.uk> On Thu, 11 Jul 2024, Charadon via SlackBuilds-users wrote: > Well i'm glad to know my idea for using a vendored tarball was already > used in practice! Though, my vendor tarball won't have as prestigious of > a mirror as slackware.uk, haha It can, if you ask nicely :) That said, it's better to use a host that you have direct access to, so you won't have to deal with me if you need to update the tarball. > Guess I should ask Willy if archive.org or my own ftp site would be fine > as a source, since it's all verified using md5 anyways. =P I'm not Willy, but I bet he says it's fine. My 2 cents: HTTP or HTTPS sources are preferred over FTP (more robust, less likely to get broken by misconfigured firewalls or clients), but we already have 60+ scripts[*] that use FTP for the download, so feel free to use it. [*] How I found that out (hopefully useful info): in a clone of the SBo repo, run: git grep -l 'ftp://' '*/*/*.info' | wc -l For a lot of questions, the answer is "well, we already have scripts that do that, so yes." From fourtysixandtwo at sliderr.net Thu Jul 11 20:50:07 2024 From: fourtysixandtwo at sliderr.net (fourtysixandtwo) Date: Thu, 11 Jul 2024 14:50:07 -0600 Subject: [Slackbuilds-users] Questions with packaging a rust program. In-Reply-To: <59f7f684-f140-48c0-8ad5-f69d125be3ee@iotib.net> References: <8ed6251e-d288-4766-a6b1-fb58f8c9e31d@iotib.net> <59f7f684-f140-48c0-8ad5-f69d125be3ee@iotib.net> Message-ID: On Thu, Jul 11, 2024 at 2:02?PM Charadon via SlackBuilds-users wrote: > > Well i'm glad to know my idea for using a vendored tarball was already > used in practice! Though, my vendor tarball won't have as prestigious of > a mirror as slackware.uk, haha I like that vendoring saves a lot of time when testing hundreds or thousands of builds. All the crates added to the .info file really slows down the works. > By the way, maybe you might want to make mkvendor.sh it's own package, > as cargo-vendor-filterer is going to be included in the next version of > Slackware. That is on my todo list, just being lazy about it. From dev at iotib.net Thu Jul 11 23:23:35 2024 From: dev at iotib.net (Charadon) Date: Thu, 11 Jul 2024 19:23:35 -0400 Subject: [Slackbuilds-users] Questions with packaging a rust program. In-Reply-To: <83116154-1562-b128-c9d9-d739e2ae0a7@slackware.uk> References: <8ed6251e-d288-4766-a6b1-fb58f8c9e31d@iotib.net> <59f7f684-f140-48c0-8ad5-f69d125be3ee@iotib.net> <83116154-1562-b128-c9d9-d739e2ae0a7@slackware.uk> Message-ID: <36a21ff4-d318-4026-9e10-cdc05768afbb@iotib.net> Well good news, my ftp server supports http, https, rsync, and ftp =P So we're good one that front lol -----Original Message----- From: B. Watson [mailto:urchlay at slackware.uk] Sent: Thursday, July 11, 2024 04:11 PM -04 To: Charadon via SlackBuilds-users Cc: Charadon Subject: [Slackbuilds-users] Questions with packaging a rust program. Importance: Low On Thu, 11 Jul 2024, Charadon via SlackBuilds-users wrote: Well i'm glad to know my idea for using a vendored tarball was already used in practice! Though, my vendor tarball won't have as prestigious of a mirror as slackware.uk, haha It can, if you ask nicely :) That said, it's better to use a host that you have direct access to, so you won't have to deal with me if you need to update the tarball. Guess I should ask Willy if archive.org or my own ftp site would be fine as a source, since it's all verified using md5 anyways. =P I'm not Willy, but I bet he says it's fine. My 2 cents: HTTP or HTTPS sources are preferred over FTP (more robust, less likely to get broken by misconfigured firewalls or clients), but we already have 60+ scripts[*] that use FTP for the download, so feel free to use it. [*] How I found that out (hopefully useful info): in a clone of the SBo repo, run: git grep -l 'ftp://' '*/*/*.info' | wc -l For a lot of questions, the answer is "well, we already have scripts that do that, so yes." From dev at iotib.net Thu Jul 11 23:29:27 2024 From: dev at iotib.net (Charadon) Date: Thu, 11 Jul 2024 19:29:27 -0400 Subject: [Slackbuilds-users] Questions with packaging a rust program. In-Reply-To: References: <8ed6251e-d288-4766-a6b1-fb58f8c9e31d@iotib.net> <59f7f684-f140-48c0-8ad5-f69d125be3ee@iotib.net> Message-ID: <27186def-88cc-471a-b7f4-3443569744ba@iotib.net> >I like that vendoring saves a lot of time when testing hundreds or thousands of builds. All the crates added to the .info file really slows down the works. Agreed! It's a shame that upstream developers very rarely supply vendored tarballs, even though it makes porting a lot easier and faster. -----Original Message----- From: fourtysixandtwo [mailto:fourtysixandtwo at sliderr.net] Sent: Thursday, July 11, 2024 04:50 PM -04 To: "SlackBuilds.org Users List" Subject: [Slackbuilds-users] Questions with packaging a rust program. Importance: Low I like that vendoring saves a lot of time when testing hundreds or thousands of builds. All the crates added to the .info file really slows down the works. From for_slackbuilds-users_mlist_2023-04-21 at lockywolf.net Fri Jul 12 03:18:25 2024 From: for_slackbuilds-users_mlist_2023-04-21 at lockywolf.net (Lockywolf) Date: Fri, 12 Jul 2024 11:18:25 +0800 Subject: [Slackbuilds-users] Questions with packaging a rust program. In-Reply-To: <8ed6251e-d288-4766-a6b1-fb58f8c9e31d@iotib.net> References: <8ed6251e-d288-4766-a6b1-fb58f8c9e31d@iotib.net> Message-ID: <87h6cvs3cz.fsf@laptop.lockywolf.net> I have a script for adding cargo links to the info-file: https://gitlab.com/Lockywolf/lwfslackbuilds/-/blob/master/02_lockywolf-sbo-scripts/lwf_make-cargolinks.bash?ref_type=heads Can't say it slows down things that much. Downloading is a bit slower, but overall it's okay. I would prefer not having custom-made tarballs hosted on private servers when possible. Charadon via SlackBuilds-users writes: > Hey all, > I'm wanting to make a Slackbuild for BLAKE3. The issue is that it's made in rust. > Now rust has a thing that makes it pretty easy to vendor (`cargo vendor`) the > dependencies, the issue is that, unless upstream provides their own vendored > tarball, you'll be making your own. > > So here are my questions: > > 1. Can I make a vendored tarball, upload it somewhere like archive.org and use that > as a source? I know this is questionable security wise, but you should be able to > replicate the archive using a `git clone` and `cargo vendor` > 2. If not, can I include a script that downloads the source, runs cargo vendor, and > makes a vendored tarball? > 2. If not, how would you go about packaging a rust program? Is there any guide > anywhere? > _______________________________________________ > 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/ -- Your sincerely, Vladimir Nikishkin (MiEr, lockywolf) (Laptop) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From dev at iotib.net Fri Jul 12 15:12:40 2024 From: dev at iotib.net (Charadon) Date: Fri, 12 Jul 2024 11:12:40 -0400 Subject: [Slackbuilds-users] Questions with packaging a rust program. In-Reply-To: <87h6cvs3cz.fsf@laptop.lockywolf.net> References: <8ed6251e-d288-4766-a6b1-fb58f8c9e31d@iotib.net> <87h6cvs3cz.fsf@laptop.lockywolf.net> Message-ID: <4fa301a5-b8e0-401f-987f-0244926bf3b2@iotib.net> Personally, I think I lean more towards fourtysix's method of packaging rust with the mkvendor.sh script. As long as the end result is reproducible and verified using a checksum, it's fine. That doesn't mean your method is invalid or awful though! I'm gonna experiment with both methods and see which one I like more in the end once I have hands on experience with it =) -----Original Message----- From: Lockywolf [mailto:for_slackbuilds-users_mlist_2023-04-21 at lockywolf.net] Sent: Thursday, July 11, 2024 11:18 PM -04 To: "SlackBuilds.org Users List" Cc: Charadon Subject: [Slackbuilds-users] Questions with packaging a rust program. Importance: Low I have a script for adding cargo links to the info-file: https://gitlab.com/Lockywolf/lwfslackbuilds/-/blob/master/02_lockywolf-sbo-scripts/lwf_make-cargolinks.bash?ref_type=heads Can't say it slows down things that much. Downloading is a bit slower, but overall it's okay. I would prefer not having custom-made tarballs hosted on private servers when possible. Charadon via SlackBuilds-users writes: Hey all, I'm wanting to make a Slackbuild for BLAKE3. The issue is that it's made in rust. Now rust has a thing that makes it pretty easy to vendor (`cargo vendor`) the dependencies, the issue is that, unless upstream provides their own vendored tarball, you'll be making your own. So here are my questions: 1. Can I make a vendored tarball, upload it somewhere like archive.org and use that as a source? I know this is questionable security wise, but you should be able to replicate the archive using a `git clone` and `cargo vendor` 2. If not, can I include a script that downloads the source, runs cargo vendor, and makes a vendored tarball? 2. If not, how would you go about packaging a rust program? Is there any guide anywhere? _______________________________________________ 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 willysr at slackbuilds.org Sat Jul 13 00:58:55 2024 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sat, 13 Jul 2024 07:58:55 +0700 Subject: [Slackbuilds-users] Updates - 20240713.1 Message-ID: <1bf7af67-5c6e-4ee8-a984-d2215cbb979e@slackbuilds.org> Sat Jul 13 00:50:17 UTC 2024 academic/copasi: Updated for version 4.44.295. academic/fet: Updated for version 6.22.1. academic/octave: Updated for version 9.2.0 academic/root: Updated for version 6.30/08, removed gsl_shared flag audio/puddletag: Version bump to 2.4.0 desktop/breath-gtk-theme: Removed (broken and outdated GTK theme) desktop/calcure: Updated for version 3.0.2 desktop/gfi: Updated for version 0.2.4. desktop/mousam: Orphan maintenance (and remove mousam) development/arduino-cli: Updated for version 1.0.2 development/aws-cdk: Updated for version 2.148.0. development/bbcsdl: Updated for version 1.40a. development/gambas3: Updated for version 3.19.3. development/gitlab-cli: Updated for version 1.43.0 development/hugo: updated for version 0.128.2 development/idea: Updated for version 2024.1.4. development/nodejs: Updated for version 20.15.1. development/postman: Updated for version 11.3.0 development/sbt: Updated for version 1.10.1 development/terraform: Updated for version 1.9.2 development/vscode-bin: Updated for version 1.91.0. games/RetroArch: Updated for version 1.19.1. games/ags: updated for version 3.6.1.26 games/atari_8bit_utils: Updated for version 20240721_e483db6. games/fbneo-libretro: Added (retro games). games/freeciv: updated for version 3.1.2 games/mgba: Updated for version 0.10.3 games/pioneer: Updated for version 20240710. games/ppsspp: Updated for version 1.17.1. games/warzone2100: updated for version 4.5.1 gis/Fiona: Update for 1.9.4.post1 (+new maintainer) gis/geographiclib-python: Update for 2.0 (+new maintainer) gis/geopy: Update for 2.4.1 (+new maintainer) gis/pdal: Updated for version 2.7.2. gis/qgis: Updated for version 3.38.0. gis/saga-gis: Updated for version 9.5.0. gis/survex: Updated for version 1.4.9. graphics/MaterialX: Updated for version 1.39.0. graphics/autotrace: Version bump to 3.31.10 + new maintainer ham/gridtracker: Updated for version 1.24.0707. ham/qlog: Updated for version 0.37.0. libraries/SimGear: Add patches for current. libraries/libfilezilla: Updated for version 0.48.1. libraries/libmirage: Update for 3.2.8 libraries/podofo: Update for 0.10.3 (+new maintainer) libraries/rest: Remove unneeded deps. misc/open-simh: Updated for version 20240703_e7b2431." multimedia/gpac: Version bump to 2.4.0 + new maintainer multimedia/k9copy-reloaded: Fix build. multimedia/lives: Fix build. multimedia/opera-ffmpeg-codecs: Updated for version 0.89.0. multimedia/plexmediaserver: Updated for version 1.40.4.8679_424562606. network/aerc: Added (terminal email client). network/brave-browser: Updated for version 1.67.123. network/discord: Version bump to 0.0.59 network/dnsproxy-bin: Updated for version 0.72.0. network/element-desktop: updated for version 1.11.70 network/exim: Updated for version 4.98. network/filezilla: Update script. network/filezilla: Updated for version 3.67.1. network/go-sendxmpp: Updated for version 0.11.1. network/haproxy: Updated for version 3.0.3. network/nextcloud-desktop: updated for version 3.13.1 network/opera: Updated for version 112.0.5197.24. network/scrcpy: Updated for version 2.5 network/tailscale: updated for version 1.68.2 network/telegram: Updated for version 5.2.3. network/tor-browser: Updated for version 13.5.1. network/webex: Updated for version 44.5.0.29672 network/whalebird: Updated for version 6.1.2. network/wireshark: Updated for version 4.2.6. network/yle-dl: Updated for version 20240706. network/yt-dlp: Updated for version 2024.07.09. network/zmap: Updated for version 4.2.0. office/calibre-bin: Updated for version 7.14.0. office/libreoffice-helppack: Updated for version 24.2.5. office/libreoffice-langpack: Updated for version 24.2.5. office/libreoffice: Updated for version 24.2.5. office/lyx: Updated for version 2.4.1. office/pandoc: updated for version 3.2.1 perl/perl-Convert-BinHex: Updated for version 1.125. perl/perl-Convert-UUlib: Updated for version 1.8. perl/perl-Email-Address-XS: Added (Parse and format RFC 5322). perl/perl-IO-Multiplex: Updated for version 1.16. perl/perl-IO-stringy: Updated for version 2.113. perl/perl-MIME-tools: Updated for version 5.515. python/python-importlib_metadata: Updated for version 8.0.0. python/python2-psutil: Updated for version 6.0.0. python/python3-dep-logic: Version bump to 0.4.1 python/python3-dkimpy: updated for version 1.1.8 python/python3-glances: Updated for version 4.1.2. python/python3-pdfminer.six: Updated for version 20240706. python/python3-pdm-backend: Version bump to 2.3.2 python/python3-plexapi: Updated to 4.15.15. python/python3-psutil: Updated for version 6.0.0. python/python3-pyogrio: Added (GeoPandas-oriented API). python/python3-rtree: Update for 1.3.0 python/python3-setuptools-opt: Updated for version 70.3.0. python/python3-tekore: Updated to 5.5.0. python/python3-tenacity: Update for 8.5.0 python/python3-tomlkit: Update for 0.13.0 python/python3-tox: Version bump to 4.16.0 python/python3-trove-classifiers: Updated for version 2024.7.2. python/python3-unearth: Version bump to 0.16.0 python/python3-validators: Version bump to 0.32.0 ruby/ruby-build: Updated for version 20240709.1. system/B-em: Updated for version 20240703_756742d. system/Iosevka-aile: Updated for version 30.3.2. system/Iosevka-etoile: Updated for version 30.3.2. system/cdemu-daemon: Update for 3.2.7 system/conky: Updated for version 1.21.4. system/epson-inkjet-printer-escpr2: Updated for version 1.2.12. system/fastfetch: Updated for version 2.17.2. system/inotify-info: Updated for version 0.0.3. system/jenkins: Updated for version 2.452.3. system/kvantum-qt5: Updated to 1.1.2. system/limine: Updated for version 7.10.0. system/mbuffer: Updated for version 20240707 system/netdata: Updated for version 1.46.2. system/nix: Some extra hardcoded assurance. system/nvidia-driver: Updated for version 555.58.02. system/nvidia-kernel: Updated for version 555.58.02. system/nvidia-legacy390-driver: Fix doinst.sh. system/nvidia-legacy470-driver: Fix doinst.sh. system/polychromatic: Updated for version 0.8.5. system/sarasa-gothic: Updated for version 1.0.15. system/st: Updated for version 0.9.2. system/ttf-charis-sil: Updated for version 6.200. system/ttf-doulos-sil: Updated for version 6.200. system/xfs_undelete: Added (XFS Recovery Program). +--------------------------+ -- Willy Sudiarto Raharjo -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From thedoogster at gmail.com Sat Jul 13 20:22:05 2024 From: thedoogster at gmail.com (Doogster) Date: Sat, 13 Jul 2024 13:22:05 -0700 Subject: [Slackbuilds-users] I am no longer maintaining ds4drv Message-ID: I'd intended to give up maintenance of my SlackBuilds ages ago, but it looks like we missed this one: https://slackbuilds.org/repository/15.0/system/ds4drv/ I am no longer maintaining this SlackBuild. From urchlay at slackware.uk Sat Jul 13 20:44:42 2024 From: urchlay at slackware.uk (B. Watson) Date: Sat, 13 Jul 2024 16:44:42 -0400 (EDT) Subject: [Slackbuilds-users] I am no longer maintaining ds4drv In-Reply-To: References: Message-ID: <8d594f37-4020-15dc-8412-9c26426e4528@slackware.uk> On Sat, 13 Jul 2024, Doogster wrote: > I'd intended to give up maintenance of my SlackBuilds ages ago, but it > looks like we missed this one: > > https://slackbuilds.org/repository/15.0/system/ds4drv/ > > I am no longer maintaining this SlackBuild. You're listed as maintainer for more than just that build, see: https://slackbuilds.org/advsearch.php?stype=maint&q=doogster To the list in general: anyone want to take these over? From didier at slint.fr Sat Jul 13 21:10:51 2024 From: didier at slint.fr (Didier Spaier) Date: Sat, 13 Jul 2024 23:10:51 +0200 Subject: [Slackbuilds-users] I am no longer maintaining these SlackBuilds In-Reply-To: References: Message-ID: <54dcbf96-ff5f-45a7-9730-213de857af37@slint.fr> https://slackbuilds.org/repository/15.0/accessibility/espeakup/ https://slackbuilds.org/repository/15.0/libraries/libgksu/ https://slackbuilds.org/repository/15.0/system/gksu/ https://slackbuilds.org/repository/15.0/system/qControlCenter/ Notes: 1. If someone wants to take over espeakup, see: https://slackware.uk/slint/x86_64/slint-15.0/source/espeakup/ I can help whoever wants it 2. I suggest to drop libgksu and gksu. A better replacement is gnsu, source: https://github.com/gapan/gnsu I prefer to grant permission to anyone knowing root's password than to members of the wheel group giving their, but that's just my way. Patch for this change: https://slackware.uk/slint/x86_64/slint-15.0/source/gnsu/ask_root_password.diff 3. I was the upstream maintainer of qCpontrolCenter, but it's now Dimitris Tzemos: https://github.com/djemos/qControlCenter Cheers, Didier From lenardrspencer at gmail.com Sat Jul 13 22:16:37 2024 From: lenardrspencer at gmail.com (Lenard Spencer) Date: Sat, 13 Jul 2024 18:16:37 -0400 Subject: [Slackbuilds-users] I am no longer maintaining these SlackBuilds In-Reply-To: <54dcbf96-ff5f-45a7-9730-213de857af37@slint.fr> References: <54dcbf96-ff5f-45a7-9730-213de857af37@slint.fr> Message-ID: I'll take espeakup. On Sat, Jul 13, 2024, 17:11 Didier Spaier wrote: > https://slackbuilds.org/repository/15.0/accessibility/espeakup/ > https://slackbuilds.org/repository/15.0/libraries/libgksu/ > https://slackbuilds.org/repository/15.0/system/gksu/ > https://slackbuilds.org/repository/15.0/system/qControlCenter/ > > Notes: > 1. If someone wants to take over espeakup, see: > https://slackware.uk/slint/x86_64/slint-15.0/source/espeakup/ > I can help whoever wants it > > 2. I suggest to drop libgksu and gksu. A better replacement is gnsu, > source: https://github.com/gapan/gnsu > I prefer to grant permission to anyone knowing root's password than to > members > of the wheel group giving their, but that's just my way. > Patch for this change: > > https://slackware.uk/slint/x86_64/slint-15.0/source/gnsu/ask_root_password.diff > > 3. I was the upstream maintainer of qCpontrolCenter, but it's now Dimitris > Tzemos: https://github.com/djemos/qControlCenter > > Cheers, > Didier > _______________________________________________ > 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 didier at slint.fr Sat Jul 13 22:31:15 2024 From: didier at slint.fr (Didier Spaier) Date: Sun, 14 Jul 2024 00:31:15 +0200 Subject: [Slackbuilds-users] I am no longer maintaining these SlackBuilds In-Reply-To: References: <54dcbf96-ff5f-45a7-9730-213de857af37@slint.fr> Message-ID: Le 7/14/24 ? 00:16, Lenard Spencer a ?crit?: > I'll take espeakup. Thanks :) From alisonken1 at juno.com Sat Jul 13 23:22:04 2024 From: alisonken1 at juno.com (Ken Roberts) Date: Sat, 13 Jul 2024 23:22:04 GMT Subject: [Slackbuilds-users] polib and relatorio up for grabs Message-ID: <20240713.162204.4231.0@webmail05.vgs.untd.com> The following slackbuilds are up for grabs: https://slackbuilds.org/repository/15.0/python/polib https://slackbuilds.org/repository/15.0/python/relatorio According to https://slackbuilds.org/advsearch.php?q=alisonken1&stype=maint I have 2 slackbuilds of which I was unaware that I was maintaining. I can remember maintaining a cpu-hack slackbuild for the [45]86 many moons ago. I do not remember asking for these 2. At any rate, I haven't been on slackware for a couple of years due to needing to keep work/hobby/home systems homogenized. - Ken Roberts Do you Slack? Slackware Linux since 1993 From kvngncrlsn at gmail.com Sun Jul 14 02:41:27 2024 From: kvngncrlsn at gmail.com (K. Eugene Carlson) Date: Sun, 14 Jul 2024 11:41:27 +0900 Subject: [Slackbuilds-users] I am no longer maintaining ds4drv In-Reply-To: <8d594f37-4020-15dc-8412-9c26426e4528@slackware.uk> References: <8d594f37-4020-15dc-8412-9c26426e4528@slackware.uk> Message-ID: I can take GentiumPlus. Best regards, Gene Carlson On Sun, Jul 14, 2024 at 5:44?AM B. Watson wrote: > > > On Sat, 13 Jul 2024, Doogster wrote: > > > I'd intended to give up maintenance of my SlackBuilds ages ago, but it > > looks like we missed this one: > > > > https://slackbuilds.org/repository/15.0/system/ds4drv/ > > > > I am no longer maintaining this SlackBuild. > > You're listed as maintainer for more than just that build, see: > > https://slackbuilds.org/advsearch.php?stype=maint&q=doogster > > To the list in general: anyone want to take these over? > _______________________________________________ > 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 Sun Jul 14 05:05:49 2024 From: urchlay at slackware.uk (B. Watson) Date: Sun, 14 Jul 2024 01:05:49 -0400 (EDT) Subject: [Slackbuilds-users] I am no longer maintaining ds4drv In-Reply-To: References: <8d594f37-4020-15dc-8412-9c26426e4528@slackware.uk> Message-ID: <809069c4-4a1-aed0-3a80-647962105292@slackware.uk> On Sun, 14 Jul 2024, K. Eugene Carlson wrote: > I can take GentiumPlus. Excellent. Go ahead and submit an update, with your name and email in the .info file, so this doesn't get forgotten about. From lenardrspencer at gmail.com Tue Jul 16 17:52:28 2024 From: lenardrspencer at gmail.com (Lenard Spencer) Date: Tue, 16 Jul 2024 13:52:28 -0400 Subject: [Slackbuilds-users] nvidia-open-kernel Message-ID: Willy, please remove system/nvidia-open-kernel. It is no longer needed as that functionality is now incorporated into nvidia-kernel by passing OPEN=yes to the script. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From willysr at slackbuilds.org Wed Jul 17 13:58:41 2024 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Wed, 17 Jul 2024 20:58:41 +0700 Subject: [Slackbuilds-users] nvidia-open-kernel In-Reply-To: References: Message-ID: <3fb156ec-c418-430a-81fc-90642af58f84@slackbuilds.org> > Willy, please remove system/nvidia-open-kernel. It is no longer needed as > that functionality is now incorporated into nvidia-kernel by passing > OPEN=yes to the script. Thanks. done -- Willy Sudiarto Raharjo -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From alessandro.baggi at gmail.com Thu Jul 18 09:28:38 2024 From: alessandro.baggi at gmail.com (Alessandro Baggi) Date: Thu, 18 Jul 2024 11:28:38 +0200 Subject: [Slackbuilds-users] mint-x-icons: source missing or bad versioning Message-ID: Hi, the source points to an invalid url. On http://packages.linuxmint.com/pool/main/m/mint-x-icons/ I can find: mint-x-icons_1.6.6.tar.xz mint-x-icons_1.7.1.tar.xz but not for the specified version (1.6.8). From alessandro.baggi at gmail.com Thu Jul 18 15:16:37 2024 From: alessandro.baggi at gmail.com (Alessandro Baggi) Date: Thu, 18 Jul 2024 17:16:37 +0200 Subject: [Slackbuilds-users] Slackbuilds: doinst.sh and douninst.sh Message-ID: <21cc316e-4fd9-4b3f-96bf-bdf33c1c69ce@gmail.com> Hi list, I noticed that sometime a slackbuild requires to create user and group. In my case, postgresql.SlackBuild requires user and group creation before builing the software. Why don't put the user creation inside doinst.sh? The user/group creation seems not needed for building purpose. I'm missing something? From man removepkg(8) I read this: "removepkg supports /bin/sh compatible uninstall scripts. If the package shipped with an uninstall script, it will be run after the package is removed. If present, the uninstall script resides in the /var/lib/pkgtools/douninst.sh/ directory and has the same full name as the package (without the extension). For example, a package named foo-1.0-noarch-1.txz might contain an uninstall script named: /var/lib/pkg?tools/douninst.sh/foo-1.0-noarch-1" This seems an interesting feature but I see it is not generally used or at least I have not found a package that provides douninst.sh. Why is it not used? For example, removing postgresql it could be useful to remove user/group for postgres or other files. Thank you in advance. Alessandro. From urchlay at slackware.uk Thu Jul 18 18:35:19 2024 From: urchlay at slackware.uk (B. Watson) Date: Thu, 18 Jul 2024 14:35:19 -0400 (EDT) Subject: [Slackbuilds-users] Slackbuilds: doinst.sh and douninst.sh In-Reply-To: <21cc316e-4fd9-4b3f-96bf-bdf33c1c69ce@gmail.com> References: <21cc316e-4fd9-4b3f-96bf-bdf33c1c69ce@gmail.com> Message-ID: On Thu, 18 Jul 2024, Alessandro Baggi wrote: > I noticed that sometime a slackbuild requires to create user and group. > In my case, postgresql.SlackBuild requires user and group creation > before builing the software. Why don't put the user creation inside > doinst.sh? The user/group creation seems not needed for building > purpose. I'm missing something? At least some of the time, the user & group are required at build time. Sometimes this could be avoided (e.g. SlackBuild does a "chown user:group", could be done in doinst.sh instead), other times it's because "make install" does the chown (or "install -o user -g group") and will fail if the user doesn't exist. Also, we consider user & group creation to be something that shouldn't be automated. > /var/lib/pkg?tools/douninst.sh/foo-1.0-noarch-1" > > This seems an interesting feature but I see it is not generally used or > at least I have not found a package that provides douninst.sh. > > Why is it not used? This feature didn't exist in Slackware stable until 15.0, so it's still relatively new. We have a lot of builds that would benefit from using it: *anything* that does "update-desktop-database" in the doinst.sh should do the same in douninst.sh. Also anything that installs info pages in /usr/info, or fonts in /usr/share/fonts. We have a few builds that do use it. Examples: take a look at audio/asap, audio/eawpats, system/vice, system/univga-font. If you've cloned the git tree, you can do something like: git ls-files '*/*/douninst.sh' Also, there are a few that install the doinst.sh as douininst.sh too (because the same actions need to be taken, e.g. rebuilding the font cache or /usr/info/dir). > For example, removing postgresql it could be useful to remove user/group > for postgres or other files. Remember that upgrading a package actually involves removing it. Whatever the douninst.sh script does, will happen not just for "removepkg blah" but also for reinstalls, including upgrades. And the douninst.sh script doesn't know which action (remove or reinstall) is calling it. postgresql's actual databases are owned by the postgresql user. What should happen to them, if the douninst.sh removed the user? If you delete them, you *royally* screw things up for anyone who's just trying to upgrade postgresql to the latest version. People *don't* expect that upgrading their database engine will wipe out all its data! If you don't delete them, you end up with files that belong to a nonexistent user, for people who really are removing postgresql and not upgrading it. This isn't really fatal, but it's what you might call "untidy". It would make more sense for postgresql's data files to still be listed as belonging to the postgresql user, which is what happens now. From jdashiel at panix.com Thu Jul 18 21:18:07 2024 From: jdashiel at panix.com (Jude DaShiell) Date: Thu, 18 Jul 2024 17:18:07 -0400 Subject: [Slackbuilds-users] Slackbuilds: doinst.sh and douninst.sh In-Reply-To: References: <21cc316e-4fd9-4b3f-96bf-bdf33c1c69ce@gmail.com> Message-ID: <7605ca10-091b-4d9a-bb99-c99305b30171@panix.com> I've had a question about slackware removal process ever since I first installed slackware so figure I best ask it here. Slackware removes each file one by one. It's possible with several package files in one directory so long as that's all in that directory to do something like rm -f target /* or rm -fr target if there are directories below target to remove directories and contents and that usually happens faster. Why wasn't this second approach taken with slackware? -- Jude "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." Ed Howdershelt 1940. On Thu, 18 Jul 2024, B. Watson wrote: > > > On Thu, 18 Jul 2024, Alessandro Baggi wrote: > > > I noticed that sometime a slackbuild requires to create user and group. In > > my case, postgresql.SlackBuild requires user and group creation before > > builing the software. Why don't put the user creation inside doinst.sh? The > > user/group creation seems not needed for building purpose. I'm missing > > something? > > At least some of the time, the user & group are required at build > time. Sometimes this could be avoided (e.g. SlackBuild does a "chown > user:group", could be done in doinst.sh instead), other times it's > because "make install" does the chown (or "install -o user -g group") > and will fail if the user doesn't exist. > > Also, we consider user & group creation to be something that shouldn't > be automated. > > > /var/lib/pkg?tools/douninst.sh/foo-1.0-noarch-1" > > > > This seems an interesting feature but I see it is not generally used or at > > least I have not found a package that provides douninst.sh. > > > > Why is it not used? > > This feature didn't exist in Slackware stable until 15.0, so it's > still relatively new. We have a lot of builds that would benefit > from using it: *anything* that does "update-desktop-database" in > the doinst.sh should do the same in douninst.sh. Also anything that > installs info pages in /usr/info, or fonts in /usr/share/fonts. > > We have a few builds that do use it. Examples: take a look at > audio/asap, audio/eawpats, system/vice, system/univga-font. > > If you've cloned the git tree, you can do something like: > > git ls-files '*/*/douninst.sh' > > Also, there are a few that install the doinst.sh as douininst.sh too > (because the same actions need to be taken, e.g. rebuilding the font > cache or /usr/info/dir). > > > For example, removing postgresql it could be useful to remove user/group for > > postgres or other files. > > Remember that upgrading a package actually involves removing > it. Whatever the douninst.sh script does, will happen not just for > "removepkg blah" but also for reinstalls, including upgrades. And the > douninst.sh script doesn't know which action (remove or reinstall) is > calling it. > > postgresql's actual databases are owned by the postgresql user. What > should happen to them, if the douninst.sh removed the user? > > If you delete them, you *royally* screw things up for anyone who's > just trying to upgrade postgresql to the latest version. People > *don't* expect that upgrading their database engine will wipe out all > its data! > > If you don't delete them, you end up with files that belong to a > nonexistent user, for people who really are removing postgresql and > not upgrading it. This isn't really fatal, but it's what you might > call "untidy". It would make more sense for postgresql's data files > to still be listed as belonging to the postgresql user, which is what > happens now. > From urchlay at slackware.uk Thu Jul 18 21:48:32 2024 From: urchlay at slackware.uk (B. Watson) Date: Thu, 18 Jul 2024 17:48:32 -0400 (EDT) Subject: [Slackbuilds-users] Slackbuilds: doinst.sh and douninst.sh In-Reply-To: <7605ca10-091b-4d9a-bb99-c99305b30171@panix.com> References: <21cc316e-4fd9-4b3f-96bf-bdf33c1c69ce@gmail.com> <7605ca10-091b-4d9a-bb99-c99305b30171@panix.com> Message-ID: <84ec6961-6eb-33fa-a7b0-6f891caf86e@slackware.uk> On Thu, 18 Jul 2024, Jude DaShiell wrote: > I've had a question about slackware removal process ever since I first > installed slackware so figure I best ask it here. > Slackware removes each file one by one. It's possible with several > package files in one directory so long as that's all in that directory to > do something like rm -f target /* or rm -fr target if there are > directories below target to remove directories and contents and that > usually happens faster. Why wasn't this second approach taken with > slackware? This got kinda long & involved, hopefully it's helpful. Multiple reasons. Keep in mind, "removal" doesn't just mean "removepkg foo", it also happens when you upgrade a package. "upgradepkg" is equivalent to removing the old package and installing the new (actually it's more complex: install new package, *then* remove the old, then reinstall the new). When you upgrade or remove a package, have you ever seen the " was found in another package. Skipping." message? That's essential, and requires checking each file before deleting it. If removepkg didn't do this check, you wouldn't be able to upgrade "core" libraries (the ones found in aaa_glibc-solibs and aaa_libraries) because deleting the old library would likely break all the shell commands that removepkg itself is using. Also, removing (including upgrading) a package should never delete any file except files that are part of the package. You wrote "so long as that's all in that directory", but how can removepkg know, up front, that someone hasn't created more files in that directory, ahead of time? It would have to check whether it's safe to use "rm -rf"... which would take away any speed advantage gained by using it, and if it determines it's not safe, it would have to revert to removing the files individually like it does now. Examples: 1. If a package installs /etc/appname/appname.conf (config file), and later we upgrade the package, "rm -rf /etc/appname" would remove the config. You want upgrades to leave config files in place (and that's why the doinst.sh template has the new_config() function). For that matter, I might have several old config files there, called things like /etc/appname/appname.conf.old or maybe separate *.conf.roaming and *.conf.home (to be copied over the main config, depending on my location)... those are *my* files, not part of any package, and removing a package should not delete them. 2. If a package called "appname" installs files in /usr/lib64/appname/plugins/, and another package called appname-extra-plugins installs more files in the same dir, you don't want "rm -rf /usr/lib64/appname/plugins/" to run when you upgrade the main appname package, because it'll blow away files that are in another package (appname-extra-plugins). It would be even worse if upgrading appname-extra-plugins ran the rm, because that would blow away the plugins that shipped with the main package. For what it's worth, other distro package formats work (broadly speaking) the same way: RPMs and debs don't use "rm -rf" either. From willysr at slackbuilds.org Fri Jul 19 00:38:17 2024 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Fri, 19 Jul 2024 07:38:17 +0700 Subject: [Slackbuilds-users] Slackbuilds: doinst.sh and douninst.sh In-Reply-To: <21cc316e-4fd9-4b3f-96bf-bdf33c1c69ce@gmail.com> References: <21cc316e-4fd9-4b3f-96bf-bdf33c1c69ce@gmail.com> Message-ID: <01b0f9c6-aacf-40b5-8ac6-8cd36d00d902@slackbuilds.org> > I noticed that sometime a slackbuild requires to create user and group. > In my case, postgresql.SlackBuild requires user and group creation > before builing the software. Why don't put the user creation inside > doinst.sh? The user/group creation seems not needed for building > purpose. I'm missing something? if you notice on postgresql.SlackBuild, we have this commands: mkdir -p $PKG/var/lib/pgsql/$PG_VERSION/data chown -R postgres:postgres $PKG/var/lib/pgsql without having postgres user and group, this would fail and the files/directories will not have correct permission for the application -- Willy Sudiarto Raharjo -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x3F617144D7238786.asc Type: application/pgp-keys Size: 8363 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From jdashiel at panix.com Fri Jul 19 00:57:02 2024 From: jdashiel at panix.com (Jude DaShiell) Date: Thu, 18 Jul 2024 20:57:02 -0400 Subject: [Slackbuilds-users] Slackbuilds: doinst.sh and douninst.sh In-Reply-To: <84ec6961-6eb-33fa-a7b0-6f891caf86e@slackware.uk> References: <21cc316e-4fd9-4b3f-96bf-bdf33c1c69ce@gmail.com> <7605ca10-091b-4d9a-bb99-c99305b30171@panix.com> <84ec6961-6eb-33fa-a7b0-6f891caf86e@slackware.uk> Message-ID: <025b156a-2a44-ba41-7d2e-e4947fd4bad3@panix.com> In this case shortcuts could result in system crash something systems with multiple users on them would not appreciate. Thanks for the explanation. -- Jude "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." Ed Howdershelt 1940. On Thu, 18 Jul 2024, B. Watson wrote: > > > On Thu, 18 Jul 2024, Jude DaShiell wrote: > > > I've had a question about slackware removal process ever since I first > > installed slackware so figure I best ask it here. > > Slackware removes each file one by one. It's possible with several > > package files in one directory so long as that's all in that directory to > > do something like rm -f target /* or rm -fr target if there are > > directories below target to remove directories and contents and that > > usually happens faster. Why wasn't this second approach taken with > > slackware? > > This got kinda long & involved, hopefully it's helpful. > > Multiple reasons. Keep in mind, "removal" doesn't just mean "removepkg > foo", it also happens when you upgrade a package. "upgradepkg" > is equivalent to removing the old package and installing the new > (actually it's more complex: install new package, *then* remove the > old, then reinstall the new). > > When you upgrade or remove a package, have you ever seen the " > was found in another package. Skipping." message? That's essential, > and requires checking each file before deleting it. If removepkg > didn't do this check, you wouldn't be able to upgrade "core" libraries > (the ones found in aaa_glibc-solibs and aaa_libraries) because > deleting the old library would likely break all the shell commands > that removepkg itself is using. > > Also, removing (including upgrading) a package should never delete > any file except files that are part of the package. You wrote "so > long as that's all in that directory", but how can removepkg know, > up front, that someone hasn't created more files in that directory, > ahead of time? It would have to check whether it's safe to use "rm > -rf"... which would take away any speed advantage gained by using > it, and if it determines it's not safe, it would have to revert to > removing the files individually like it does now. > > Examples: > > 1. If a package installs /etc/appname/appname.conf (config file), and > later we upgrade the package, "rm -rf /etc/appname" would remove the > config. You want upgrades to leave config files in place (and that's > why the doinst.sh template has the new_config() function). For that > matter, I might have several old config files there, called things > like /etc/appname/appname.conf.old or maybe separate *.conf.roaming > and *.conf.home (to be copied over the main config, depending on > my location)... those are *my* files, not part of any package, and > removing a package should not delete them. > > 2. If a package called "appname" installs files in > /usr/lib64/appname/plugins/, > and another package called appname-extra-plugins installs more files > in the same dir, you don't want "rm -rf /usr/lib64/appname/plugins/" > to run when you upgrade the main appname package, because it'll blow > away files that are in another package (appname-extra-plugins). It > would be even worse if upgrading appname-extra-plugins ran the rm, > because that would blow away the plugins that shipped with the main > package. > > For what it's worth, other distro package formats work (broadly > speaking) the same way: RPMs and debs don't use "rm -rf" either. > _______________________________________________ > 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 johannes at schoepfer.info Fri Jul 19 05:37:44 2024 From: johannes at schoepfer.info (=?ISO-8859-1?Q?Johannes_Sch=F6pfer?=) Date: Fri, 19 Jul 2024 07:37:44 +0200 Subject: [Slackbuilds-users] Slackbuilds: doinst.sh and douninst.sh In-Reply-To: <01b0f9c6-aacf-40b5-8ac6-8cd36d00d902@slackbuilds.org> References: <21cc316e-4fd9-4b3f-96bf-bdf33c1c69ce@gmail.com> <01b0f9c6-aacf-40b5-8ac6-8cd36d00d902@slackbuilds.org> Message-ID: <63964D1E-6467-4DAC-A27A-C09687A7987D@schoepfer.info> Am 19. Juli 2024 02:38:17 MESZ schrieb Willy Sudiarto Raharjo : >> I noticed that sometime a slackbuild requires to create user and group. In my case, postgresql.SlackBuild requires user and group creation before builing the software. Why don't put the user creation inside doinst.sh? The user/group creation seems not needed for building purpose. I'm missing something? > >if you notice on postgresql.SlackBuild, we have this commands: > >mkdir -p $PKG/var/lib/pgsql/$PG_VERSION/data >chown -R postgres:postgres $PKG/var/lib/pgsql > >without having postgres user and group, this would fail and the files/directories will not have correct permission for the application > > This could bei solved using uid/gid directly: chown -R 209:209 This would also work in doinst.sh If this package ist build once, and then is installed on various other boxes, it's the same outcome. manual user/group creation is then needed which is covered by the readme. It seems postgresql does not actually need a special user to be build. And if it would, the makefile could bei adjusted. Johannes From alessandro.baggi at gmail.com Fri Jul 19 07:03:08 2024 From: alessandro.baggi at gmail.com (Alessandro Baggi) Date: Fri, 19 Jul 2024 09:03:08 +0200 Subject: [Slackbuilds-users] doinst.sh and douninst.sh Message-ID: <97d6c0f4-d5f4-429c-a148-b5f61580be22@gmail.com> Hi list, I noticed that sometime a slackbuild requires to create user and group. In my case, postgresql.SlackBuild requires user and group creation before builing the software. Why don't put the user creation inside doinst.sh? The user/group creation seems not needed for building purpose. I'm missing something? From man removepkg(8) I read this: "removepkg supports /bin/sh compatible uninstall scripts. If the package shipped with an uninstall script, it will be run after the package is removed. If present, the uninstall script resides in the /var/lib/pkgtools/douninst.sh/ directory and has the same full name as the package (without the extension). For example, a package named foo-1.0-noarch-1.txz might contain an uninstall script named: /var/lib/pkg?tools/douninst.sh/foo-1.0-noarch-1" This seems an interesting feature but I see it is not generally used or at least I have not found a package that provides douninst.sh. Why is it not used? For example, removing postgresql it could be useful to remove user/group for postgres or other files. Thank you in advance. Alessandro. From alessandro.baggi at gmail.com Fri Jul 19 08:24:04 2024 From: alessandro.baggi at gmail.com (Alessandro Baggi) Date: Fri, 19 Jul 2024 10:24:04 +0200 Subject: [Slackbuilds-users] Slackbuilds: doinst.sh and douninst.sh In-Reply-To: <01b0f9c6-aacf-40b5-8ac6-8cd36d00d902@slackbuilds.org> References: <21cc316e-4fd9-4b3f-96bf-bdf33c1c69ce@gmail.com> <01b0f9c6-aacf-40b5-8ac6-8cd36d00d902@slackbuilds.org> Message-ID: <57c3c515-70f9-4b43-a57e-04812bb7fcf9@gmail.com> Il 19/07/24 02:38, Willy Sudiarto Raharjo ha scritto: > > if you notice on postgresql.SlackBuild, we have this commands: > > mkdir -p $PKG/var/lib/pgsql/$PG_VERSION/data > chown -R postgres:postgres $PKG/var/lib/pgsql > > without having postgres user and group, this would fail and the > files/directories will not have correct permission for the application Hi Willy, in this way, yes if user will not be created the chown command will fail, but at this point why not put the chown,user/group creation commands in doinst.sh and remove the statement that requires postgres user/group? I think it is more genuine. For example I build my packages inside a VM, then I install on my workstation. Here, on my workstation (and on other machines where I will install postgresql package) without the user/group creation postgresql "cannot be used" as configured so I'm forced to create them manually, plus configuring rc.local/rc.local_shutdown, while this should be done during package installation. For example, I have an automated build script to compile all needed slackbuilds. If I add a new package that requires a specific user/group definition the automated script will be stopped by that requirement but if provided inside doinst.sh the automation will work. From my point of view if an operation needs to be done many times, the right solution is automate it (this is one big advantages of IT). Another thing that could be inserted in the doinst.sh (for services that require to start on boot) is populating rc.local with the correct statement (if ..... /etc/rc.d/rc.service start...fi) with the caution to not rewrite the same "starts statements" if already defined (maybe used in upgrading the package) In the current state the package installation is not complete because it misses some points: 1. User/group privileges configuration that are required by the software to run (as shipped in the slackbuild) 2. Configuring and prepare the system to start/stop the service (if enabled) during boot/reboot/shutdown process 3. A clean process during package uninstall that clean created user/group, start/stop system configuration in rc.local/rc.local_shutdown My 2 cents, Alessandro. From dickson.tim at googlemail.com Fri Jul 19 10:58:33 2024 From: dickson.tim at googlemail.com (Tim Dickson) Date: Fri, 19 Jul 2024 11:58:33 +0100 Subject: [Slackbuilds-users] Slackbuilds: doinst.sh and douninst.sh In-Reply-To: <57c3c515-70f9-4b43-a57e-04812bb7fcf9@gmail.com> References: <21cc316e-4fd9-4b3f-96bf-bdf33c1c69ce@gmail.com> <01b0f9c6-aacf-40b5-8ac6-8cd36d00d902@slackbuilds.org> <57c3c515-70f9-4b43-a57e-04812bb7fcf9@gmail.com> Message-ID: On 19/07/2024 09:24, Alessandro Baggi wrote: > > > Il 19/07/24 02:38, Willy Sudiarto Raharjo ha scritto: >> >> if you notice on postgresql.SlackBuild, we have this commands: >> >> mkdir -p $PKG/var/lib/pgsql/$PG_VERSION/data >> chown -R postgres:postgres $PKG/var/lib/pgsql >> >> without having postgres user and group, this would fail and the >> files/directories will not have correct permission for the application > > Hi Willy, > > in this way, yes if user will not be created the chown command will > fail, but at this point why not put the chown,user/group creation > commands in doinst.sh and remove the statement that requires postgres > user/group? > > I think it is more genuine. For example I build my packages inside a > VM, then I install on my workstation. Here, on my workstation (and on > other machines where I will install postgresql package) without the > user/group creation postgresql "cannot be used" as configured so I'm > forced to create them manually, plus configuring > rc.local/rc.local_shutdown, while this should be done during package > installation. > > For example, I have an automated build script to compile all needed > slackbuilds. If I add a new package that requires a specific > user/group definition the automated script will be stopped by that > requirement but if provided inside doinst.sh the automation will work. > From my point of view if an operation needs to be done many times, the > right solution is automate it (this is one big advantages of IT). > > Another thing that could be inserted in the doinst.sh (for services > that require to start on boot) is populating rc.local with the correct > statement (if ..... /etc/rc.d/rc.service start...fi) with the caution > to not rewrite the same "starts statements" if already defined (maybe > used in upgrading the package) > > In the current state the package installation is not complete because > it misses some points: > > 1. User/group privileges configuration that are required by the > software to run (as shipped in the slackbuild) > 2. Configuring and prepare the system to start/stop the service (if > enabled) during boot/reboot/shutdown process > 3. A clean process during package uninstall that clean created > user/group, start/stop system configuration in rc.local/rc.local_shutdown > > My 2 cents, > > Alessandro. > > Although I agree it would be more convenient if users/groups and rc.local/rc.local_shutdown entries were done automatically (I have a printer driver which would benefit), these extra actions can be automated outside of the slackbuild script itself. You mentioned you have a build script. You can add the user/group creation in that. for example, in one of my scripts I have #lets create required avahi user and group if needed ? if [ `cat /etc/group|grep avahi|wc -l`x = "0x" ]; then ??? groupadd -g 214 avahi ? fi ? if [ `cat /etc/passwd|grep avahi|wc -l`x = "0x" ]; then ??? useradd -u 214 -g 214 -c "Avahi User" -d /dev/null -s /bin/false avahi ? fi You would also need an install script to do the same. (and the startup/shutdown stuff as well) I use such a script for the avahi and epson-inkjet-printer-escpr2 packages. one needs user and group, and they both need auto-startup/shutdown entries. denyhosts is another which should be started from rc.inet2 so it is running before sshd starts, but after the network is up. As there are so many "special case" packages, it is usually left for the admin to externally script their preferred handling, and keep the doinst scripts as minimal as possible. Unless there is consensus on a approach that is not invasive eg. is optional; such as a env variable which could be set if this stuff was wanted to be run on install, eg: SBOAUTOMATE=yes; export SBOAUTOMATE then in the doinst.sh if [ "x$SBOAUTOMATE" = "xyes" ]; then ?? #do extra setup tasks automatically ?? #.... fi it's not likely to get much traction. regards, Tim -- This email has been checked for viruses by AVG antivirus software. www.avg.com From willysr at slackbuilds.org Fri Jul 19 12:10:05 2024 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Fri, 19 Jul 2024 19:10:05 +0700 Subject: [Slackbuilds-users] Slackbuilds: doinst.sh and douninst.sh In-Reply-To: <57c3c515-70f9-4b43-a57e-04812bb7fcf9@gmail.com> References: <21cc316e-4fd9-4b3f-96bf-bdf33c1c69ce@gmail.com> <01b0f9c6-aacf-40b5-8ac6-8cd36d00d902@slackbuilds.org> <57c3c515-70f9-4b43-a57e-04812bb7fcf9@gmail.com> Message-ID: > in this way, yes if user will not be created the chown command will > fail, but at this point why not put the chown,user/group creation > commands in doinst.sh and remove the statement that requires postgres > user/group? > > I think it is more genuine. For example I build my packages inside a VM, > then I install on my workstation. Here, on my workstation (and on other > machines where I will install postgresql package) without the user/group > creation postgresql "cannot be used" as configured so I'm forced to > create them manually, plus configuring rc.local/rc.local_shutdown, while > this should be done during package installation. > > For example, I have an automated build script to compile all needed > slackbuilds. If I add a new package that requires a specific user/group > definition the automated script will be stopped by that requirement but > if provided inside doinst.sh the automation will work. From my point of > view if an operation needs to be done many times, the right solution is > automate it (this is one big advantages of IT). > > Another thing that could be inserted in the doinst.sh (for services that > require to start on boot) is populating rc.local with the correct > statement (if ..... /etc/rc.d/rc.service start...fi) with the caution to > not rewrite the same "starts statements" if already defined (maybe used > in upgrading the package) > > In the current state the package installation is not complete because it > misses some points: > > 1. User/group privileges configuration that are required by the software > to run (as shipped in the slackbuild) > 2. Configuring and prepare the system to start/stop the service (if > enabled) during boot/reboot/shutdown process > 3. A clean process during package uninstall that clean created user/ > group, start/stop system configuration in rc.local/rc.local_shutdown That's is up to users on how they want to set up their machine, just as how Slackware let users decide what to do with their machines we will follow how Slackware works in SBo so users should be responsible for their own setup, it should not be determined by the maintainer -- Willy Sudiarto Raharjo -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From urchlay at slackware.uk Fri Jul 19 19:46:01 2024 From: urchlay at slackware.uk (B. Watson) Date: Fri, 19 Jul 2024 15:46:01 -0400 (EDT) Subject: [Slackbuilds-users] Slackbuilds: doinst.sh and douninst.sh In-Reply-To: <57c3c515-70f9-4b43-a57e-04812bb7fcf9@gmail.com> References: <21cc316e-4fd9-4b3f-96bf-bdf33c1c69ce@gmail.com> <01b0f9c6-aacf-40b5-8ac6-8cd36d00d902@slackbuilds.org> <57c3c515-70f9-4b43-a57e-04812bb7fcf9@gmail.com> Message-ID: On Fri, 19 Jul 2024, Alessandro Baggi wrote: > 3. A clean process during package uninstall that clean created user/group, > start/stop system configuration in rc.local/rc.local_shutdown Again I will say it: Packages get *removed* when they get upgraded. Anything a douninst.sh script does, happens when the package gets upgraded. The douninst.sh script doesn't know know whether it's being run due to a permanent removal or due to an upgrade. Do you really want to delete the postgres user during the upgrade process? Normally when you delete a user, you delete the user's files, too (userdel -r). If you don't delete the files, upgrades are safe. But in that case, if someone really does permanently remove the postgresql package, it's not a clean removal: all the data that was in the databases is still on the filesystem, taking up space... and no longer owned by any user. From willysr at slackbuilds.org Sat Jul 20 01:22:09 2024 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sat, 20 Jul 2024 08:22:09 +0700 Subject: [Slackbuilds-users] Updates - 20240720.1 Message-ID: Sat Jul 20 01:10:07 UTC 2024 academic/ngspice: Updated for version 43. academic/openboard: Replaced backtick cmdsub. academic/sword-data-kjv: Replaced backtick cmdsub. audio/caps: Fixed chown syntax audio/gogglesmm: Fixed chown syntax audio/musikcube: Updated for version 3.0.4. audio/ncspot: Updated for version 1.1.2. audio/ogmtools: Fixed chown syntax audio/tauonmb: Update script. audio/tuner: Updated for version 1.5.2. audio/yabridge: Fix dbus problem desktop/crystalcursors: Fixed chown syntax desktop/fvwm95: Replaced backtick cmdsub. desktop/i3lock: Fixed chown syntax desktop/kfaenza-icon-theme: Fixed chown syntax desktop/mint-x-icons: Updated for version 1.7.1. desktop/mint-y-icons: Update for 1.7.7 desktop/nwg-panel: Updated for version 0.9.36. desktop/qtile: Update for 0.27.0 desktop/rofi-emoji: Updated for version 3.4.0. desktop/xmonad: Fixed chown syntax development/amazon-corretto: Fixed chown syntax development/amd-app-sdk: Replaced backtick cmdsub. development/aws-cdk: Updated for version 2.149.0. development/bacon: Replaced backtick cmdsub. development/bazel: Update for 5.4.1 development/cgit: Fixed chown syntax development/decklink-sdk: Replaced backtick cmdsub. development/gambas3: Replaced backtick cmdsub. development/ghidra: Updated for version 11.1.2 development/github-desktop: Updated for version 3.4.2. development/glm: Fixed chown syntax development/google-go-lang: Updated for version 1.22.5. development/inform: Fixed chown syntax development/jdk: Fixed chown syntax development/liberica-jdk-bin: Updated for version 21.0.4+9. development/openjdk7: Fixed chown syntax development/openjdk7: Replaced backtick cmdsub. development/openjdk8: Fixed chown syntax development/p4v: Replaced backtick cmdsub. development/postman: Updated for version 11.3.2 development/pulsar: Updated for version 1.119.0. development/rmac: Fixed chown syntax development/robomongo: Fixed chown syntax development/smartgit: Fixed chown syntax development/textadept: Replaced backtick cmdsub. development/tflint: Added (Pluggable Terraform Linter). games/atari_8bit_utils: Replaced backtick cmdsub. games/lbreakouthd: Updated for version 1.1.9. games/mgba: Fix build on current. games/mupen64plus: Updated for version 2.6.0. games/openttd: Updated for version 14.1 games/principia: Updated for version 2024.07.12. games/redeclipse: Replaced backtick cmdsub. games/rlvm: Fixed chown syntax games/rocksndiamonds: Fixed chown syntax games/scribble: Fixed chown syntax games/unnethack: Replaced backtick cmdsub. games/zsnes: Replaced backtick cmdsub. gis/geopandas: Update for 1.0.1 (+new maintainer) gis/grass: Replaced backtick cmdsub. gis/mapnik: Replaced backtick cmdsub. gis/postgis: Replaced backtick cmdsub. gis/whitebox-tools: Replaced backtick cmdsub. graphics/blender: Version bump to 4.2.0 graphics/gimagereader: Updated for version 3.4.2. graphics/graphviz: updated for version 12.0.0 graphics/jpeg2ps: Fixed chown syntax graphics/pencil2d: update deps. graphics/simple-scan: Fixed chown syntax graphics/tuxpaint-stamps: Updated for version 2024.07.17. graphics/tuxpaint: Updated for version 0.9.33. graphics/ufraw: Fixed chown syntax graphics/vips: Fixed chown syntax graphics/vuescan: Updated for version 9.8.35. ham/gridtracker: Updated for version 1.24.0715. ham/hamlib: Replaced backtick cmdsub. ham/qlog: Updated for version 0.37.1. libraries/OpenBLAS: Replaced backtick cmdsub. libraries/gsm: Replaced backtick cmdsub. libraries/libgit2-glib: Updated to 0.99.0.1 + new maintainer libraries/libgit2: Fix ssh option. libraries/libgit2: Updated to 1.8.1 + new maintainer libraries/libiptcdata: Fixed chown syntax libraries/libkate: Fixed chown syntax libraries/liblqr: Replaced backtick cmdsub. libraries/lua-zlib: Replaced backtick cmdsub. libraries/luaevent: Replaced backtick cmdsub. libraries/nacl: Replaced backtick cmdsub. libraries/p4api: Replaced backtick cmdsub. libraries/qt-avif-image-plugin: Updated for version 0.8.5. libraries/rabbitmq-c: Replaced backtick cmdsub. libraries/raylib: Replaced backtick cmdsub. libraries/webkit2gtk4.1: Replaced backtick cmdsub. libraries/wxGTK3: Replaced backtick cmdsub. libraries/wxPython3: Replaced backtick cmdsub. libraries/wxWidgets: Replaced backtick cmdsub. libraries/xmlsec: Updated for version 1.2.41. misc/bsdmainutils: Replaced backtick cmdsub. misc/fcitx-mozc: Replaced backtick cmdsub. misc/jmri: Updated for version 5.8 misc/kde_cdemu: Replaced backtick cmdsub. misc/yubioath-desktop: Replaced backtick cmdsub. multimedia/dirac: Fixed chown syntax multimedia/ffmpeg2theora: Fixed chown syntax multimedia/flowblade: Replaced backtick cmdsub. multimedia/k9copy-reloaded: Remove /usr/share/doc. multimedia/minidlna: Replaced backtick cmdsub multimedia/oggvideotools: Fixed chown syntax multimedia/qdvdauthor: Added (GUI frontend for dvdauthor). multimedia/schroedinger: Fixed chown syntax multimedia/videomass: Updated for version 5.0.18. multimedia/vobcopy: Fixed chown syntax network/amavisd-new: Fixed chown syntax network/beegfs: Replaced backtick cmdsub. network/cherokee: Replaced backtick cmdsub network/clive: Replaced backtick cmdsub. network/discord: Version bump to 0.0.60 network/dkimproxy: Replaced backtick cmdsub. network/dnsproxy-bin: Updated for version 0.72.1. network/dog: Replaced backtick cmdsub. network/dovecot-pigeonhole: Fixed chown syntax network/dropbox: Updated for version 203.4.4857. network/ejabberd-bin: Updated for version 24.07. network/ejabberd: Replaced backtick cmdsub. network/exim: Fixed chown syntax network/ganglia: Fixed chown syntax network/gtorrentviewer: Replaced backtick cmdsub. network/guacamole-client: Replaced backtick cmdsub. network/haproxy: Replaced backtick cmdsub network/havp: Replaced backtick cmdsub network/librewolf: Updated for version 127.0.2 network/luakit: Replaced backtick cmdsub. network/mstflint: Replaced backtick cmdsub. network/nrpe: Replaced backtick cmdsub network/nsca: Replaced backtick cmdsub network/offlineimap: Fixed chown syntax network/opensm: Replaced backtick cmdsub. network/pflogsumm: Fixed chown syntax network/policyd2: Fixed chown syntax network/policyd: Fixed chown syntax network/prosody: Replaced backtick cmdsub. network/quagga: Fixed chown syntax network/slack: Updated for version 4.39.90. network/tor: Fixed chown syntax network/ttdnsd: Replaced backtick cmdsub network/unbound: Replaced backtick cmdsub network/vivaldi: Updated for version 6.8.3381.48. network/xl2tpd: Replaced backtick cmdsub. office/LibreOffice: Updated for version 24.2.5.2 office/Ted: Replaced backtick cmdsub. office/calibre-bin: Updated for version 7.15.0. office/gnucash: Replaced backtick cmdsub. office/hebcal: Updated for version 5.8.6. office/keepnote: Fixed chown syntax office/onlyoffice-desktopeditors: Updated for version 8.1.1. office/pdfstudio: Replaced backtick cmdsub. office/pdfstudioviewer: Replaced backtick cmdsub. office/qtrans: Added (Offline dictionary). office/smoffice2016: Replaced backtick cmdsub. perl/perl-BerkeleyDB: Fixed chown syntax perl/perl-Cache-FastMmap: Fixed chown syntax perl/perl-Canary-Stability: Fixed chown syntax perl/perl-Config-IniFiles: Fixed chown syntax perl/perl-Config-Tiny: Added (read/write .ini style files). perl/perl-Convert-BinHex: Fixed chown syntax perl/perl-Convert-TNEF: Fixed chown syntax perl/perl-Convert-UUlib: Fixed chown syntax perl/perl-Crypt-OpenSSL-AES: Fixed chown syntax perl/perl-Crypt-OpenSSL-Bignum: Fixed chown syntax perl/perl-Crypt-OpenSSL-Guess: Fixed chown syntax perl/perl-Crypt-OpenSSL-RSA: Fixed chown syntax perl/perl-Crypt-OpenSSL-Random: Fixed chown syntax perl/perl-Date-Calc: Fixed chown syntax perl/perl-Encode-Detect: Fixed chown syntax perl/perl-File-Download: Added (Fetch large files from the web). perl/perl-Geography-Countries: Fixed chown syntax perl/perl-IO-Multiplex: Fixed chown syntax perl/perl-IO-stringy: Fixed chown syntax perl/perl-IP-Country: Fixed chown syntax perl/perl-IPC-Run: Fixed chown syntax perl/perl-Image-Info: Fixed chown syntax perl/perl-MIME-tools: Fixed chown syntax perl/perl-Mail-DKIM: Fixed chown syntax perl/perl-Mail-SPF: Fixed chown syntax perl/perl-MailTools: Fixed chown syntax perl/perl-Net-CIDR: Fixed chown syntax perl/perl-Net-DNS-Resolver-Programmable: Fixed chown syntax perl/perl-Net-Ident: Fixed chown syntax perl/perl-Net-Patricia: Fixed chown syntax perl/perl-Net-Server: Fixed chown syntax perl/perl-Net-UPnP: Fixed chown syntax perl/perl-NetAddr-IP: Fixed chown syntax perl/perl-String-ShellQuote: Fixed chown syntax perl/perl-Sub-Uplevel: Fixed chown syntax perl/perl-Test-Deep: Fixed chown syntax perl/perl-Test-Exception: Fixed chown syntax perl/perl-Test-Pod: Fixed chown syntax perl/perl-Test-SharedFork: Fixed chown syntax perl/perl-Test-TCP: Fixed chown syntax perl/perl-Time-Out: Fixed chown syntax perl/perl-TimeDate: Fixed chown syntax perl/perl-Unix-Syslog: Fixed chown syntax perl/perl-ZMQ-Constants: Fixed chown syntax python/jsonpointer: Update for 3.0.0 python/pycxx: Replaced backtick cmdsub. python/python2-magick: Replaced backtick cmdsub. python/python3-cachetools: Version bump to 5.4.0 python/python3-dep-logic: Version bump to 0.4.2 python/python3-hishel: Version bump to 0.0.30 python/python3-identify: Updated for version 2.6.0. python/python3-msal: Version bump to 1.30.0 python/python3-pdm-backend: Version bump to 2.3.3 python/python3-pdm-build-locked: Added (PDM plugin). python/python3-pdm: Version bump to 2.17.0 python/python3-pyudev: Added (Python3 of pyudev). python/python3-qbittorrent-api: Version bump to 2024.7.64. python/python3-textdistance: Update for 4.6.3 python/python3-unearth: Version bump to 0.16.1 python/python3-validators: Version bump to 0.33.0 python/python3-whatthepatch: Update for 1.0.6 python/thonny: Replaced backtick cmdsub. ruby/gem2tgz: Fixed chown syntax system/FontAwesome: Update for 6.6.0 system/GentiumPlus: Updated for version 6.200 and new maintainer. system/Solaar: Update deps. system/apache-activemq: Replaced backtick cmdsub. system/b2: Updated for version 20240710_232859_844adac. system/borgbackup/borgbackup: Update for version 1.2.8 system/borgmatic: Update for version 1.8.13 system/cabextract: Fixed chown syntax system/ccid: Fixed chown syntax system/ccrypt: Fixed chown syntax system/clamsmtp: Fixed chown syntax system/clamtk: Replaced backtick cmdsub. system/courier-prime: Replaced backtick cmdsub. system/dar: Fixed chown syntax system/docker-compose: Updated for version 2.29.0. system/dracut: Updated for version 103 system/ds4drv: Update deps. system/epson-inkjet-printer-escpr2: Updated for version 1.2.13. system/epson-printer-utility: Replaced backtick cmdsub system/fastfetch: Updated for version 2.18.1. system/fsarchiver: Fixed chown syntax system/heartbeat: Replaced backtick cmdsub. system/intel-microcode: Update for version 20240531 system/irqbalance: Fixed chown syntax system/jenkins: Fixed chown syntax system/jenkins: Replaced backtick cmdsub. system/lsb-release: Replaced backtick cmdsub. system/lxqt-powermanagement: Remove trailing spaces system/mcrypt: Fixed chown syntax system/motion: Replaced backtick cmdsub. system/nagios-plugins: Fixed chown syntax system/netdata: Replaced backtick cmdsub. system/nvidia-driver: Replaced backtick cmdsub. system/nvidia-fabricmanager: Replaced backtick cmdsub. system/nvidia-legacy390-driver: Replaced backtick cmdsub. system/nvidia-legacy470-driver: Replaced backtick cmdsub. system/nvidia-open-kernel: Removed (Included in nvidia-kernel). system/openrazer-daemon: Update deps. system/pcsc-perl: Fixed chown syntax system/pixma: Replaced backtick cmdsub. system/pmount: Fixed chown syntax system/prometheus: Updated to version 2.53.1 system/rasdaemon: Fixed chown syntax system/safecopy: Fixed chown syntax system/slack-timedate: Added (timedated1 interface). system/sleepd: Replaced backtick cmdsub system/targetcli-fb: Update deps. system/tomb: Updated for version 2.11. +--------------------------+ -- Willy Sudiarto Raharjo -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From alessandro.baggi at gmail.com Sat Jul 20 06:44:23 2024 From: alessandro.baggi at gmail.com (Alessandro Baggi) Date: Sat, 20 Jul 2024 08:44:23 +0200 Subject: [Slackbuilds-users] Slackbuilds: doinst.sh and douninst.sh In-Reply-To: References: <21cc316e-4fd9-4b3f-96bf-bdf33c1c69ce@gmail.com> <01b0f9c6-aacf-40b5-8ac6-8cd36d00d902@slackbuilds.org> <57c3c515-70f9-4b43-a57e-04812bb7fcf9@gmail.com> Message-ID: Hi Watson, Il 19/07/24 21:46, B. Watson ha scritto: > > > On Fri, 19 Jul 2024, Alessandro Baggi wrote: > >> 3. A clean process during package uninstall that clean created >> user/group, start/stop system configuration in rc.local/rc.local_shutdown > > Again I will say it: > > Packages get *removed* when they get upgraded. > > Anything a douninst.sh script does, happens when the package gets > upgraded. The douninst.sh script doesn't know know whether it's being > run due to a permanent removal or due to an upgrade. > > Do you really want to delete the postgres user during the upgrade process? > > Normally when you delete a user, you delete the user's files, too > (userdel -r). > > If you don't delete the files, upgrades are safe. this is a good point but it is not better to instruct slackpkg or upgradepkg or whatever to not run douninst.sh when upgrading packages? This seems a pkgtool feature lacks. But in that case, > if someone really does permanently remove the postgresql package, it's > not a clean removal: all the data that was in the databases is still > on the filesystem, taking up space... and no longer owned by any user. Generally, from my point of view, when a package is deleted the package manager should not delete application data and this is a common behaviour also in apt and dnf. There is a difference between system configuration (replicable), application files and real data (not replicable). A clean removal is meant by me like "the application is no more present on the system" and should not consider user data but only app configuration and binary/libs/etc of the specified application. Following your "clear all suggestion" and running an upgrade, being the package removed and reinstalled, all useful data (reproducible like configuration and not reproducile data like db records) will be deleted making the new installation broken because user loses all data, so is better to instruct pkgtool to assume the right behaviour when upgrading. Sometimes package manager should be updated with new feature or existent features enhancement. From tonus1 at free.fr Sat Jul 20 09:12:16 2024 From: tonus1 at free.fr (Tonus) Date: Sat, 20 Jul 2024 11:12:16 +0200 Subject: [Slackbuilds-users] Slackbuilds: doinst.sh and douninst.sh In-Reply-To: References: <21cc316e-4fd9-4b3f-96bf-bdf33c1c69ce@gmail.com> <01b0f9c6-aacf-40b5-8ac6-8cd36d00d902@slackbuilds.org> <57c3c515-70f9-4b43-a57e-04812bb7fcf9@gmail.com> Message-ID: <380D648D-1D5F-4122-9C27-0B1EC654403D@free.fr> Hi all I bet this is for the "request for current" thread on linuxquestions.org Regards Tonus (from phone, sorry for writing before quotes) Le 20 juillet 2024 08:44:23 GMT+02:00, Alessandro Baggi a ?crit?: > > >Hi Watson, > >Il 19/07/24 21:46, B. Watson ha scritto: >> >> >> On Fri, 19 Jul 2024, Alessandro Baggi wrote: >> >>> 3. A clean process during package uninstall that clean created user/group, start/stop system configuration in rc.local/rc.local_shutdown >> >> Again I will say it: >> >> Packages get *removed* when they get upgraded. >> >> Anything a douninst.sh script does, happens when the package gets >> upgraded. The douninst.sh script doesn't know know whether it's being >> run due to a permanent removal or due to an upgrade. >> >> Do you really want to delete the postgres user during the upgrade process? >> >> Normally when you delete a user, you delete the user's files, too (userdel -r). >> >> If you don't delete the files, upgrades are safe. > >this is a good point but it is not better to instruct slackpkg or upgradepkg or whatever to not run douninst.sh when upgrading packages? This seems a pkgtool feature lacks. > >But in that case, >> if someone really does permanently remove the postgresql package, it's >> not a clean removal: all the data that was in the databases is still >> on the filesystem, taking up space... and no longer owned by any user. > >Generally, from my point of view, when a package is deleted the package manager should not delete application data and this is a common behaviour also in apt and dnf. There is a difference between system configuration (replicable), application files and real data (not replicable). A clean removal is meant by me like "the application is no more present on the system" and should not consider user data but only app configuration and binary/libs/etc of the specified application. > >Following your "clear all suggestion" and running an upgrade, being the package removed and reinstalled, all useful data (reproducible like configuration and not reproducile data like db records) will be deleted making the new installation broken because user loses all data, so is better to instruct pkgtool to assume the right behaviour when upgrading. > >Sometimes package manager should be updated with new feature or existent features enhancement. > > > > > >_______________________________________________ >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 willysr at slackbuilds.org Sat Jul 20 10:51:14 2024 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sat, 20 Jul 2024 17:51:14 +0700 Subject: [Slackbuilds-users] Slackbuilds: doinst.sh and douninst.sh In-Reply-To: References: <21cc316e-4fd9-4b3f-96bf-bdf33c1c69ce@gmail.com> <01b0f9c6-aacf-40b5-8ac6-8cd36d00d902@slackbuilds.org> <57c3c515-70f9-4b43-a57e-04812bb7fcf9@gmail.com> Message-ID: <6ce6bbc7-0635-4e0a-b1c4-5d2a12797c29@slackbuilds.org> > this is a good point but it is not better to instruct slackpkg or > upgradepkg or whatever to not run douninst.sh when upgrading packages? > This seems a pkgtool feature lacks. > Generally, from my point of view, when a package is deleted the package > manager should not delete application data and this is a common > behaviour also in apt and dnf. There is a difference between system > configuration (replicable), application files and real data (not > replicable). A clean removal is meant by me like "the application is no > more present on the system" and should not consider user data but only > app configuration and binary/libs/etc of the specified application. > > Following your "clear all suggestion" and running an upgrade, being the > package removed and reinstalled, all useful data (reproducible like > configuration and not reproducile data like db records) will be deleted > making the new installation broken because user loses all data, so is > better to instruct pkgtool to assume the right behaviour when upgrading. > > Sometimes package manager should be updated with new feature or existent > features enhancement. I'm pretty sure such behaviour (not deleting application data) is already applied in slackpkg. It removes the binaries, documentations, manual pages, and other files/directories created during installation, but left out any other content created after the application is being used. If you have a suggestion for slackpkg, you can send PR into this repository: https://github.com/rworkman/slackpkg -- Willy Sudiarto Raharjo -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From dickson.tim at googlemail.com Sat Jul 20 11:36:29 2024 From: dickson.tim at googlemail.com (Tim Dickson) Date: Sat, 20 Jul 2024 12:36:29 +0100 Subject: [Slackbuilds-users] replacement of backtick in slackbuild scripts In-Reply-To: <6ce6bbc7-0635-4e0a-b1c4-5d2a12797c29@slackbuilds.org> References: <21cc316e-4fd9-4b3f-96bf-bdf33c1c69ce@gmail.com> <01b0f9c6-aacf-40b5-8ac6-8cd36d00d902@slackbuilds.org> <57c3c515-70f9-4b43-a57e-04812bb7fcf9@gmail.com> <6ce6bbc7-0635-4e0a-b1c4-5d2a12797c29@slackbuilds.org> Message-ID: <38d23101-f9f2-4b15-bc63-ce958f138cfd@googlemail.com> hi all, I noticed a bunch of scripts had backtick cmdsub changed. is there any technical reason?. both $(cmds) and `cmds` obviously work just interested, as i didn't notice any announcement about a preferred style (and I tend to use backtick method myself :-)??? ) regards, Tim -- This email has been checked for viruses by AVG antivirus software. www.avg.com From didier at slint.fr Sat Jul 20 11:51:55 2024 From: didier at slint.fr (Didier Spaier) Date: Sat, 20 Jul 2024 13:51:55 +0200 Subject: [Slackbuilds-users] replacement of backtick in slackbuild scripts In-Reply-To: <38d23101-f9f2-4b15-bc63-ce958f138cfd@googlemail.com> References: <21cc316e-4fd9-4b3f-96bf-bdf33c1c69ce@gmail.com> <01b0f9c6-aacf-40b5-8ac6-8cd36d00d902@slackbuilds.org> <57c3c515-70f9-4b43-a57e-04812bb7fcf9@gmail.com> <6ce6bbc7-0635-4e0a-b1c4-5d2a12797c29@slackbuilds.org> <38d23101-f9f2-4b15-bc63-ce958f138cfd@googlemail.com> Message-ID: <9ceb1a06-fce2-43b5-a820-76c3920ce980@slint.fr> Hi, I prefer and always use $(cmds) for reasons stated in https://www.shellcheck.net/wiki/SC2006 Cheers, Didier Le 7/20/24 ? 13:36, Tim Dickson via SlackBuilds-users a ?crit?: > hi all, I noticed a bunch of scripts had backtick cmdsub changed. > is there any technical reason?. > both $(cmds) and `cmds` obviously work > > just interested, as i didn't notice any announcement about a preferred style > (and I tend to use backtick method myself :-)??? ) > regards, Tim From jebrhansen+SBo at gmail.com Sat Jul 20 11:53:32 2024 From: jebrhansen+SBo at gmail.com (Jeremy Hansen) Date: Sat, 20 Jul 2024 04:53:32 -0700 Subject: [Slackbuilds-users] replacement of backtick in slackbuild scripts In-Reply-To: <38d23101-f9f2-4b15-bc63-ce958f138cfd@googlemail.com> References: <21cc316e-4fd9-4b3f-96bf-bdf33c1c69ce@gmail.com> <01b0f9c6-aacf-40b5-8ac6-8cd36d00d902@slackbuilds.org> <57c3c515-70f9-4b43-a57e-04812bb7fcf9@gmail.com> <6ce6bbc7-0635-4e0a-b1c4-5d2a12797c29@slackbuilds.org> <38d23101-f9f2-4b15-bc63-ce958f138cfd@googlemail.com> Message-ID: On Sat, Jul 20, 2024, 4:36?AM Tim Dickson via SlackBuilds-users < slackbuilds-users at slackbuilds.org> wrote: > hi all, I noticed a bunch of scripts had backtick cmdsub changed. > is there any technical reason?. > both $(cmds) and `cmds` obviously work > I'd imagine it has to do with backticks being legacy code and knowing they do not always provide expected results. If it weren't for the wide, wide use of them, they might've gotten formally deprecated with the intention to remove it from the code base. However, since they are so prevalent, they're likely here to stay, but it's still recommended to use $(cmd) unless you're using a ridiculously old shell prior to the POSIX era. You can read more about it at the following links: https://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xcu_chap02.html#tag_23_02_06_03 https://mywiki.wooledge.org/BashFAQ/082 https://www.redhat.com/sysadmin/backtick-operator-vs-parens https://www.putorius.net/command-substitution-bash.html Jeremy -------------- next part -------------- An HTML attachment was scrubbed... URL: From for_slackbuilds-users_mlist_2023-04-21 at lockywolf.net Sat Jul 20 11:45:24 2024 From: for_slackbuilds-users_mlist_2023-04-21 at lockywolf.net (Lockywolf) Date: Sat, 20 Jul 2024 19:45:24 +0800 Subject: [Slackbuilds-users] replacement of backtick in slackbuild scripts In-Reply-To: <38d23101-f9f2-4b15-bc63-ce958f138cfd@googlemail.com> References: <21cc316e-4fd9-4b3f-96bf-bdf33c1c69ce@gmail.com> <01b0f9c6-aacf-40b5-8ac6-8cd36d00d902@slackbuilds.org> <57c3c515-70f9-4b43-a57e-04812bb7fcf9@gmail.com> <6ce6bbc7-0635-4e0a-b1c4-5d2a12797c29@slackbuilds.org> <38d23101-f9f2-4b15-bc63-ce958f138cfd@googlemail.com> Message-ID: <878qxwp9jc.fsf@laptop.lockywolf.net> Backticks are a worse practice because parsing delimiters based on parity instead of them being different is needlessly hard. Just try adding unintended backticks or quotation marks in a file using a naive parser and observe syntax highlighting fly to the moon. Moreover, $() can be nested, while backticks cannot, that is proper syntax composes much better. I.e. echo $(ls $(echo ".")) The only reason of using backticks is really compatibility with obscure commercial UNIXes, but I doubt you'd like to compile SlackBuilds on those. Tim Dickson via SlackBuilds-users writes: > hi all, I noticed a bunch of scripts had backtick cmdsub changed. > is there any technical reason?. > both $(cmds) and `cmds` obviously work > > just interested, as i didn't notice any announcement about a preferred style > (and I tend to use backtick method myself :-)??? ) > regards, Tim -- Your sincerely, Vladimir Nikishkin (MiEr, lockywolf) (Laptop) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: From dickson.tim at googlemail.com Sat Jul 20 13:57:57 2024 From: dickson.tim at googlemail.com (Tim Dickson) Date: Sat, 20 Jul 2024 14:57:57 +0100 Subject: [Slackbuilds-users] replacement of backtick in slackbuild scripts In-Reply-To: <9ceb1a06-fce2-43b5-a820-76c3920ce980@slint.fr> References: <21cc316e-4fd9-4b3f-96bf-bdf33c1c69ce@gmail.com> <01b0f9c6-aacf-40b5-8ac6-8cd36d00d902@slackbuilds.org> <57c3c515-70f9-4b43-a57e-04812bb7fcf9@gmail.com> <6ce6bbc7-0635-4e0a-b1c4-5d2a12797c29@slackbuilds.org> <38d23101-f9f2-4b15-bc63-ce958f138cfd@googlemail.com> <9ceb1a06-fce2-43b5-a820-76c3920ce980@slint.fr> Message-ID: <1ef4410b-9ecb-42e4-af18-94e892904ab2@googlemail.com> thanks for the feedback. My first intro was to unix on ICL drs300 (386) and drs6000 running unix system V in 1992/3 so I probably sit in the "legacy" era before I was introduced to linux. (initially redhat in lat 90's, and slackware in around 2003) :-) regards, Tim -- This email has been checked for viruses by AVG antivirus software. www.avg.com From urchlay at slackware.uk Sat Jul 20 17:12:11 2024 From: urchlay at slackware.uk (B. Watson) Date: Sat, 20 Jul 2024 13:12:11 -0400 (EDT) Subject: [Slackbuilds-users] replacement of backtick in slackbuild scripts In-Reply-To: <38d23101-f9f2-4b15-bc63-ce958f138cfd@googlemail.com> References: <21cc316e-4fd9-4b3f-96bf-bdf33c1c69ce@gmail.com> <01b0f9c6-aacf-40b5-8ac6-8cd36d00d902@slackbuilds.org> <57c3c515-70f9-4b43-a57e-04812bb7fcf9@gmail.com> <6ce6bbc7-0635-4e0a-b1c4-5d2a12797c29@slackbuilds.org> <38d23101-f9f2-4b15-bc63-ce958f138cfd@googlemail.com> Message-ID: On Sat, 20 Jul 2024, Tim Dickson via SlackBuilds-users wrote: > hi all, I noticed a bunch of scripts had backtick cmdsub changed. > is there any technical reason?. Well, we already had a bunch of scripts that were still using "chown -R user.group" syntax, which (as of the latest coreutils update) causes a warning: chown: warning: '.' should be ':': ?urchlay.users? Personally, were I in Pat's shoes, I'd just patch coreutils to get rid of that warning. But then he's got a lot more important stuff to worry about... Near as I can tell, the problem with using a dot is that user and group names are allowed to include a dot, which would make it ambiguous. Not sure this is a real-world issue (does anyone ever create usernames with dots in them, for real?) So we decided to change those scripts to use the colon... and while we were at it, decided to "fix" the backticks too. Not that backticks are really "broken". I'm actually going to add a warning to sbolint about the chown-with-dot syntax. Not a fatal error, not yet... but it loox to me like the GNU folk really want the chown-with-dot syntax to go away someday. I won't be adding a backtick warning to sbolint, because it'd be hard to implement without false positives. Makefiles and upstream scripts use backticks too, and we have scripts that use sed commands with backticks inside the quoted sed argument... examples: system/makeself has this: sed -i -e "s,^HEADER\=\`dirname \"\$0\"\`,HEADER=/usr/share/$PRGNAM," makeself.sh The backticks there belong there (they match backticks inside the makeself.sh script). It'd be hard for sbolint to parse enough shell syntax to know that, though (essentially I'd be rewriting the shell in perl). From willysr at slackbuilds.org Sat Jul 20 18:27:45 2024 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sun, 21 Jul 2024 01:27:45 +0700 Subject: [Slackbuilds-users] missing sources Message-ID: <07603ffe-c0b5-486a-9b46-74142b6f6870@slackbuilds.org> Hi all during weekly rebuilt, we noticed some of our scripts are broken due to missing sources if you are the maintainer of those scripts, please make a PR or submit an update for those scripts. some maintainer may no longer be active, so it will probably be removed on next public update. you can see the list so far here: https://github.com/SlackBuildsOrg/slackbuilds/issues/7223 -- Willy Sudiarto Raharjo -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From dev at iotib.net Sat Jul 20 21:37:20 2024 From: dev at iotib.net (Charadon) Date: Sat, 20 Jul 2024 17:37:20 -0400 Subject: [Slackbuilds-users] missing sources In-Reply-To: <07603ffe-c0b5-486a-9b46-74142b6f6870@slackbuilds.org> References: <07603ffe-c0b5-486a-9b46-74142b6f6870@slackbuilds.org> Message-ID: <51906ea1-15ec-4920-904a-a7248e5fce8d@iotib.net> How about switching their sources to archive.org links? Like ffmpeg2theora's source can be changed to: https://web.archive.org/web/20161010020734/http://v2v.cc/~j/ffmpeg2theora/downloads/ffmpeg2theora-0.30.tar.bz2 -----Original Message----- From: Willy Sudiarto Raharjo [mailto:willysr at slackbuilds.org] Sent: Saturday, July 20, 2024 02:27 PM -04 To: SlackBuilds.org Users List Subject: [Slackbuilds-users] missing sources Hi all during weekly rebuilt, we noticed some of our scripts are broken due to missing sources if you are the maintainer of those scripts, please make a PR or submit an update for those scripts. some maintainer may no longer be active, so it will probably be removed on next public update. you can see the list so far here: https://github.com/SlackBuildsOrg/ slackbuilds/issues/7223 _______________________________________________ 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 Sat Jul 20 22:19:20 2024 From: urchlay at slackware.uk (B. Watson) Date: Sat, 20 Jul 2024 18:19:20 -0400 (EDT) Subject: [Slackbuilds-users] missing sources In-Reply-To: <51906ea1-15ec-4920-904a-a7248e5fce8d@iotib.net> References: <07603ffe-c0b5-486a-9b46-74142b6f6870@slackbuilds.org> <51906ea1-15ec-4920-904a-a7248e5fce8d@iotib.net> Message-ID: On Sat, 20 Jul 2024, Charadon via SlackBuilds-users wrote: > How about switching their sources to archive.org links? Like ffmpeg2theora's > source can be changed to: > > https://web.archive.org/web/20161010020734/http://v2v.cc/~j/ffmpeg2theora/downloads/ffmpeg2theora-0.30.tar.bz2 That works, and we've done that for a few builds before. I think Willy's issue isn't "the source is missing", it's "there is no active maintainer who should have *noticed* the source was missing *months ago* and already fixed it". Unmaintained scripts are OK, until they stop working. If nobody else wants to step up as maintainer, then what happens? Either one of us admins has to spend time fixing it, or we have to remove it because we don't want *broken* stuff in our repo. I lean more towards "spend some time fixing it", but my time is limited like everyone else's is. From dev at iotib.net Sat Jul 20 22:27:07 2024 From: dev at iotib.net (Charadon) Date: Sat, 20 Jul 2024 18:27:07 -0400 Subject: [Slackbuilds-users] missing sources In-Reply-To: References: <07603ffe-c0b5-486a-9b46-74142b6f6870@slackbuilds.org> <51906ea1-15ec-4920-904a-a7248e5fce8d@iotib.net> Message-ID: Yeah. Don't get wrong though, if the SlackBuild script itself is broken, i'd say get rid of it and don't waste any time on it. But if it's just the source link being broken (Good ol link rot), it's easy enough to switch it over to an archive.org link. As a sidenote/fun fact, linkrot is why NetBSD's pkgsrc has the `distfiles` directory. -----Original Message----- From: B. Watson [mailto:urchlay at slackware.uk] Sent: Saturday, July 20, 2024 06:19 PM -04 To: Charadon via SlackBuilds-users Cc: Charadon Subject: Re: [Slackbuilds-users] missing sources On Sat, 20 Jul 2024, Charadon via SlackBuilds-users wrote: How about switching their sources to archive.org links? Like ffmpeg2theora's source can be changed to: https://web.archive.org/web/20161010020734/http://v2v.cc/~j/ ffmpeg2theora/downloads/ffmpeg2theora-0.30.tar.bz2 That works, and we've done that for a few builds before. I think Willy's issue isn't "the source is missing", it's "there is no active maintainer who should have *noticed* the source was missing *months ago* and already fixed it". Unmaintained scripts are OK, until they stop working. If nobody else wants to step up as maintainer, then what happens? Either one of us admins has to spend time fixing it, or we have to remove it because we don't want *broken* stuff in our repo. I lean more towards "spend some time fixing it", but my time is limited like everyone else's is. From urchlay at slackware.uk Sat Jul 20 22:48:37 2024 From: urchlay at slackware.uk (B. Watson) Date: Sat, 20 Jul 2024 18:48:37 -0400 (EDT) Subject: [Slackbuilds-users] missing sources In-Reply-To: References: <07603ffe-c0b5-486a-9b46-74142b6f6870@slackbuilds.org> <51906ea1-15ec-4920-904a-a7248e5fce8d@iotib.net> Message-ID: <98eefc29-df8f-5595-e4f-c03b7211e269@slackware.uk> On Sat, 20 Jul 2024, Charadon via SlackBuilds-users wrote: > As a sidenote/fun fact, linkrot is why NetBSD's pkgsrc has the `distfiles` > directory. Yah, and it's why this exists: https://slackware.uk/sbosrcarch/ From dev at iotib.net Sun Jul 21 01:34:30 2024 From: dev at iotib.net (Charadon) Date: Sat, 20 Jul 2024 21:34:30 -0400 Subject: [Slackbuilds-users] missing sources In-Reply-To: <98eefc29-df8f-5595-e4f-c03b7211e269@slackware.uk> References: <07603ffe-c0b5-486a-9b46-74142b6f6870@slackbuilds.org> <51906ea1-15ec-4920-904a-a7248e5fce8d@iotib.net> <98eefc29-df8f-5595-e4f-c03b7211e269@slackware.uk> Message-ID: <065a74ab-8c6a-4fb4-88f6-d2c91adc88b4@iotib.net> Oh neat, didn't know that existed! That should probably go in the Slackbuilds FAQ -----Original Message----- From: B. Watson [mailto:urchlay at slackware.uk] Sent: Saturday, July 20, 2024 06:48 PM -04 To: Charadon via SlackBuilds-users Cc: Charadon Subject: Re: [Slackbuilds-users] missing sources On Sat, 20 Jul 2024, Charadon via SlackBuilds-users wrote: As a sidenote/fun fact, linkrot is why NetBSD's pkgsrc has the `distfiles` directory. Yah, and it's why this exists: https://slackware.uk/sbosrcarch/ From alessandro.baggi at gmail.com Sun Jul 21 10:01:32 2024 From: alessandro.baggi at gmail.com (Alessandro Baggi) Date: Sun, 21 Jul 2024 12:01:32 +0200 Subject: [Slackbuilds-users] Slackbuilds: doinst.sh and douninst.sh In-Reply-To: <380D648D-1D5F-4122-9C27-0B1EC654403D@free.fr> References: <21cc316e-4fd9-4b3f-96bf-bdf33c1c69ce@gmail.com> <01b0f9c6-aacf-40b5-8ac6-8cd36d00d902@slackbuilds.org> <57c3c515-70f9-4b43-a57e-04812bb7fcf9@gmail.com> <380D648D-1D5F-4122-9C27-0B1EC654403D@free.fr> Message-ID: Il 20/07/24 11:12, Tonus ha scritto: > Hi all > > I bet this is for the "request for current" thread on linuxquestions.org > > Regards > > Tonus (from phone, sorry for writing before quotes) Hi Tonus, can you share the link please? Thank you in advance From alessandro.baggi at gmail.com Sun Jul 21 10:02:17 2024 From: alessandro.baggi at gmail.com (Alessandro Baggi) Date: Sun, 21 Jul 2024 12:02:17 +0200 Subject: [Slackbuilds-users] Slackbuilds: doinst.sh and douninst.sh In-Reply-To: <6ce6bbc7-0635-4e0a-b1c4-5d2a12797c29@slackbuilds.org> References: <21cc316e-4fd9-4b3f-96bf-bdf33c1c69ce@gmail.com> <01b0f9c6-aacf-40b5-8ac6-8cd36d00d902@slackbuilds.org> <57c3c515-70f9-4b43-a57e-04812bb7fcf9@gmail.com> <6ce6bbc7-0635-4e0a-b1c4-5d2a12797c29@slackbuilds.org> Message-ID: <3df4485f-209e-4092-acb6-2d30b1debd79@gmail.com> Il 20/07/24 12:51, Willy Sudiarto Raharjo ha scritto: >> this is a good point but it is not better to instruct slackpkg or >> upgradepkg or whatever to not run douninst.sh when upgrading packages? >> This seems a pkgtool feature lacks. > >> Generally, from my point of view, when a package is deleted the >> package manager should not delete application data and this is a >> common behaviour also in apt and dnf. There is a difference between >> system configuration (replicable), application files and real data >> (not replicable). A clean removal is meant by me like "the application >> is no more present on the system" and should not consider user data >> but only app configuration and binary/libs/etc of the specified >> application. >> >> Following your "clear all suggestion" and running an upgrade, being >> the package removed and reinstalled, all useful data (reproducible >> like configuration and not reproducile data like db records) will be >> deleted making the new installation broken because user loses all >> data, so is better to instruct pkgtool to assume the right behaviour >> when upgrading. >> >> Sometimes package manager should be updated with new feature or >> existent features enhancement. > > I'm pretty sure such behaviour (not deleting application data) is > already applied in slackpkg. It removes the binaries, documentations, > manual pages, and other files/directories created during installation, > but left out any other content created after the application is being used. > > If you have a suggestion for slackpkg, you can send PR into this > repository: https://github.com/rworkman/slackpkg > > Hi Willy, thank you for the resource. From tonus1 at free.fr Sun Jul 21 11:35:51 2024 From: tonus1 at free.fr (Tonus) Date: Sun, 21 Jul 2024 13:35:51 +0200 Subject: [Slackbuilds-users] Slackbuilds: doinst.sh and douninst.sh In-Reply-To: References: <21cc316e-4fd9-4b3f-96bf-bdf33c1c69ce@gmail.com> <01b0f9c6-aacf-40b5-8ac6-8cd36d00d902@slackbuilds.org> <57c3c515-70f9-4b43-a57e-04812bb7fcf9@gmail.com> <380D648D-1D5F-4122-9C27-0B1EC654403D@free.fr> Message-ID: Here you are : Regards Tonus Le 21 juillet 2024 12:01:32 GMT+02:00, Alessandro Baggi a ?crit?: > > >Il 20/07/24 11:12, Tonus ha scritto: >> Hi all >> >> I bet this is for the "request for current" thread on linuxquestions.org >> >> Regards >> >> Tonus (from phone, sorry for writing before quotes) > >Hi Tonus, > >can you share the link please? > >Thank you in advance >_______________________________________________ >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 alessandro.baggi at gmail.com Mon Jul 22 10:55:43 2024 From: alessandro.baggi at gmail.com (Alessandro Baggi) Date: Mon, 22 Jul 2024 12:55:43 +0200 Subject: [Slackbuilds-users] openzfs warning during compilation Message-ID: <1758d154-62e9-4282-bb98-3daabeb5ad33@gmail.com> Hi all, I'm trying to compile openzfs using SBo. I got a long warning list while running the SB: libtool: warning: relinking 'libzfs_core.la' libtool: warning: 'libzfs.la' has not been installed in '/lib64' libtool: warning: 'libnvpair.la' has not been installed in '/lib64' libtool: warning: relinking 'contrib/pam_zfs_key/pam_zfs_key.la' libtool: warning: '/tmp/SBo/zfs-2.2.4/libzfs_core.la' has not been installed in '/lib64' libtool: warning: 'libzfs.la' has not been installed in '/lib64' libtool: warning: 'libzfs.la' has not been installed in '/lib64' libtool: warning: 'libzfs.la' has not been installed in '/lib64' libtool: warning: 'libzpool.la' has not been installed in '/lib64' libtool: warning: '/tmp/SBo/zfs-2.2.4/libnvpair.la' has not been installed in '/lib64' libtool: warning: '/tmp/SBo/zfs-2.2.4/libzfs_core.la' has not been installed in '/lib64' libtool: warning: '/tmp/SBo/zfs-2.2.4/libzfs_core.la' has not been installed in '/lib64' libtool: warning: '/tmp/SBo/zfs-2.2.4/libzfs_core.la' has not been installed in '/lib64' libtool: warning: '/tmp/SBo/zfs-2.2.4/libnvpair.la' has not been installed in '/lib64' libtool: warning: '/tmp/SBo/zfs-2.2.4/libuutil.la' has not been installed in '/lib64' libtool: warning: '/tmp/SBo/zfs-2.2.4/libnvpair.la' has not been installed in '/lib64' libtool: warning: '/tmp/SBo/zfs-2.2.4/libuutil.la' has not been installed in '/lib64' libtool: warning: '/tmp/SBo/zfs-2.2.4/libnvpair.la' has not been installed in '/lib64' libtool: warning: 'libzfs_core.la' has not been installed in '/lib64' libtool: warning: '/tmp/SBo/zfs-2.2.4/libuutil.la' has not been installed in '/lib64' libtool: warning: '/tmp/SBo/zfs-2.2.4/libuutil.la' has not been installed in '/lib64' libtool: warning: 'libzfs_core.la' has not been installed in '/lib64' libtool: warning: 'libzpool.la' has not been installed in '/lib64' libtool: warning: 'libzfs.la' has not been installed in '/lib64' libtool: warning: relinking 'libzfs.la' libtool: warning: '/tmp/SBo/zfs-2.2.4/libnvpair.la' has not been installed in '/lib64' libtool: warning: 'libzfs_core.la' has not been installed in '/lib64' libtool: warning: '/tmp/SBo/zfs-2.2.4/libzfs_core.la' has not been installed in '/lib64' libtool: warning: 'libnvpair.la' has not been installed in '/lib64' libtool: warning: '/tmp/SBo/zfs-2.2.4/libnvpair.la' has not been installed in '/lib64' libtool: warning: '/tmp/SBo/zfs-2.2.4/libnvpair.la' has not been installed in '/lib64' libtool: warning: 'libnvpair.la' has not been installed in '/lib64' libtool: warning: '/tmp/SBo/zfs-2.2.4/libuutil.la' has not been installed in '/lib64' libtool: warning: remember to run 'libtool --finish /lib64/security' libtool: warning: 'libzpool.la' has not been installed in '/lib64' libtool: warning: 'libnvpair.la' has not been installed in '/lib64' libtool: warning: 'libzfs_core.la' has not been installed in '/lib64' libtool: warning: 'libzpool.la' has not been installed in '/lib64' libtool: warning: '/tmp/SBo/zfs-2.2.4/libnvpair.la' has not been installed in '/lib64' libtool: warning: 'libzfs_core.la' has not been installed in '/lib64' libtool: warning: 'libnvpair.la' has not been installed in '/lib64' libtool: warning: '/tmp/SBo/zfs-2.2.4/libnvpair.la' has not been installed in '/lib64' libtool: warning: 'libzpool.la' has not been installed in '/lib64' libtool: warning: 'libzpool.la' has not been installed in '/lib64' libtool: warning: 'libzfs_core.la' has not been installed in '/lib64' libtool: warning: '/tmp/SBo/zfs-2.2.4/libnvpair.la' has not been installed in '/lib64' libtool: warning: '/tmp/SBo/zfs-2.2.4/libnvpair.la' has not been installed in '/lib64' libtool: warning: 'libnvpair.la' has not been installed in '/lib64' libtool: warning: 'libnvpair.la' has not been installed in '/lib64' libtool: warning: relinking 'libzfsbootenv.la' libtool: warning: 'libzfs.la' has not been installed in '/lib64' libtool: warning: 'libzfs_core.la' has not been installed in '/lib64' libtool: warning: '/tmp/SBo/zfs-2.2.4/libzfs_core.la' has not been installed in '/lib64' libtool: warning: '/tmp/SBo/zfs-2.2.4/libnvpair.la' has not been installed in '/lib64' libtool: warning: '/tmp/SBo/zfs-2.2.4/libuutil.la' has not been installed in '/lib64' libtool: warning: 'libnvpair.la' has not been installed in '/lib64' libtool: warning: 'libzfs_core.la' has not been installed in '/lib64' libtool: warning: '/tmp/SBo/zfs-2.2.4/libnvpair.la' has not been installed in '/lib64' libtool: warning: 'libzfs_core.la' has not been installed in '/lib64' libtool: warning: 'libnvpair.la' has not been installed in '/lib64' libtool: warning: '/tmp/SBo/zfs-2.2.4/libnvpair.la' has not been installed in '/lib64' libtool: warning: 'libuutil.la' has not been installed in '/lib64' libtool: warning: 'libnvpair.la' has not been installed in '/lib64' libtool: warning: relinking 'libzpool.la' libtool: warning: 'libzfs.la' has not been installed in '/lib64' libtool: warning: 'libzfs_core.la' has not been installed in '/lib64' libtool: warning: '/tmp/SBo/zfs-2.2.4/libzfs_core.la' has not been installed in '/lib64' libtool: warning: 'libzfs.la' has not been installed in '/lib64' libtool: warning: '/tmp/SBo/zfs-2.2.4/libuutil.la' has not been installed in '/lib64' libtool: warning: '/tmp/SBo/zfs-2.2.4/libzfs_core.la' has not been installed in '/lib64' libtool: warning: 'libzfs_core.la' has not been installed in '/lib64' libtool: warning: '/tmp/SBo/zfs-2.2.4/libnvpair.la' has not been installed in '/lib64' libtool: warning: '/tmp/SBo/zfs-2.2.4/libnvpair.la' has not been installed in '/lib64' libtool: warning: '/tmp/SBo/zfs-2.2.4/libuutil.la' has not been installed in '/lib64' libtool: warning: 'libnvpair.la' has not been installed in '/lib64' libtool: warning: 'libnvpair.la' has not been installed in '/lib64' libtool: warning: 'libzfs.la' has not been installed in '/lib64' libtool: warning: 'libnvpair.la' has not been installed in '/lib64' libtool: warning: '/tmp/SBo/zfs-2.2.4/libzfs_core.la' has not been installed in '/lib64' libtool: warning: 'libzfs.la' has not been installed in '/lib64' libtool: warning: '/tmp/SBo/zfs-2.2.4/libuutil.la' has not been installed in '/lib64' libtool: warning: '/tmp/SBo/zfs-2.2.4/libzfs_core.la' has not been installed in '/lib64' libtool: warning: 'libzfs_core.la' has not been installed in '/lib64' libtool: warning: 'libnvpair.la' has not been installed in '/lib64' libtool: warning: '/tmp/SBo/zfs-2.2.4/libnvpair.la' has not been installed in '/lib64' libtool: warning: '/tmp/SBo/zfs-2.2.4/libuutil.la' has not been installed in '/lib64' libtool: warning: 'libuutil.la' has not been installed in '/lib64' libtool: warning: '/tmp/SBo/zfs-2.2.4/libnvpair.la' has not been installed in '/lib64' libtool: warning: 'libzfs.la' has not been installed in '/lib64' libtool: warning: '/tmp/SBo/zfs-2.2.4/libzfs_core.la' has not been installed in '/lib64' libtool: warning: '/tmp/SBo/zfs-2.2.4/libuutil.la' has not been installed in '/lib64' libtool: warning: 'libzfs_core.la' has not been installed in '/lib64' libtool: warning: 'libzpool.la' has not been installed in '/lib64' libtool: warning: '/tmp/SBo/zfs-2.2.4/libnvpair.la' has not been installed in '/lib64' libtool: warning: remember to run 'libtool --finish /lib64' libtool: warning: 'libnvpair.la' has not been installed in '/lib64' libtool: warning: 'libzfs.la' has not been installed in '/lib64' libtool: warning: 'libzpool.la' has not been installed in '/lib64' libtool: warning: '/tmp/SBo/zfs-2.2.4/libzfs_core.la' has not been installed in '/lib64' libtool: warning: 'libzfs_core.la' has not been installed in '/lib64' libtool: warning: '/tmp/SBo/zfs-2.2.4/libuutil.la' has not been installed in '/lib64' libtool: warning: '/tmp/SBo/zfs-2.2.4/libnvpair.la' has not been installed in '/lib64' libtool: warning: 'libzfs_core.la' has not been installed in '/lib64' libtool: warning: '/tmp/SBo/zfs-2.2.4/libnvpair.la' has not been installed in '/lib64' libtool: warning: 'libnvpair.la' has not been installed in '/lib64' libtool: warning: 'libuutil.la' has not been installed in '/lib64' Those should be considered critical or this is something expected? Thank you in advance. Alessandro. From bru.barwal at sdf.org Mon Jul 22 15:05:19 2024 From: bru.barwal at sdf.org (bru.barwal at sdf.org) Date: Mon, 22 Jul 2024 15:05:19 -0000 Subject: [Slackbuilds-users] openzfs warning during compilation In-Reply-To: <1758d154-62e9-4282-bb98-3daabeb5ad33@gmail.com> References: <1758d154-62e9-4282-bb98-3daabeb5ad33@gmail.com> Message-ID: > Hi all, > I'm trying to compile openzfs using SBo. > > I got a long warning list while running the SB: > > libtool: warning: relinking 'libzfs_core.la' > libtool: warning: 'libzfs.la' has not been installed in '/lib64' > libtool: warning: 'libnvpair.la' has not been installed in '/lib64' > libtool: warning: relinking 'contrib/pam_zfs_key/pam_zfs_key.la' > libtool: warning: '/tmp/SBo/zfs-2.2.4/libzfs_core.la' has not been > installed in '/lib64' ... > installed in '/lib64' > libtool: warning: 'libzfs_core.la' has not been installed in '/lib64' > libtool: warning: '/tmp/SBo/zfs-2.2.4/libnvpair.la' has not been > installed in '/lib64' > libtool: warning: 'libnvpair.la' has not been installed in '/lib64' > libtool: warning: 'libuutil.la' has not been installed in '/lib64' > > > Those should be considered critical or this is something expected? Hi Alessandro, I ignore these warnings with no issues. If you look at line 118 of openzfs.SlackBulid, you can see that the .la files are intentionally removed. This is consistent with the SBo autotools template: https://slackbuilds.org/templates/autotools-template.SlackBuild As far as why SBo doesn't ship .la files, I do know. Can anyone share why? Thanks, Matt From alessandro.baggi at gmail.com Mon Jul 22 15:49:43 2024 From: alessandro.baggi at gmail.com (Alessandro Baggi) Date: Mon, 22 Jul 2024 17:49:43 +0200 Subject: [Slackbuilds-users] openzfs warning during compilation In-Reply-To: References: <1758d154-62e9-4282-bb98-3daabeb5ad33@gmail.com> Message-ID: <31c1f1a7-2329-4972-ab2d-b864d0292482@gmail.com> Il 22/07/24 17:05, Matt via SlackBuilds-users ha scritto: >> Hi all, >> I'm trying to compile openzfs using SBo. >> >> I got a long warning list while running the SB: >> >> libtool: warning: relinking 'libzfs_core.la' >> libtool: warning: 'libzfs.la' has not been installed in '/lib64' >> libtool: warning: 'libnvpair.la' has not been installed in '/lib64' >> libtool: warning: relinking 'contrib/pam_zfs_key/pam_zfs_key.la' >> libtool: warning: '/tmp/SBo/zfs-2.2.4/libzfs_core.la' has not been >> installed in '/lib64' > > ... > >> installed in '/lib64' >> libtool: warning: 'libzfs_core.la' has not been installed in '/lib64' >> libtool: warning: '/tmp/SBo/zfs-2.2.4/libnvpair.la' has not been >> installed in '/lib64' >> libtool: warning: 'libnvpair.la' has not been installed in '/lib64' >> libtool: warning: 'libuutil.la' has not been installed in '/lib64' >> >> >> Those should be considered critical or this is something expected? > > Hi Alessandro, > > I ignore these warnings with no issues. If you look at line 118 of > openzfs.SlackBulid, you can see that the .la files are intentionally > removed. This is consistent with the SBo autotools template: > https://slackbuilds.org/templates/autotools-template.SlackBuild > > As far as why SBo doesn't ship .la files, I do know. Can anyone share why? > > Thanks, > Matt > Hi Matt, thank you very much for your help. Appreciated. Best regards. Alessandro. From jebrhansen+SBo at gmail.com Mon Jul 22 15:57:34 2024 From: jebrhansen+SBo at gmail.com (Jeremy Hansen) Date: Mon, 22 Jul 2024 08:57:34 -0700 Subject: [Slackbuilds-users] openzfs warning during compilation In-Reply-To: References: <1758d154-62e9-4282-bb98-3daabeb5ad33@gmail.com> Message-ID: On Mon, Jul 22, 2024, 8:09?AM Matt via SlackBuilds-users < slackbuilds-users at slackbuilds.org> wrote: > > Hi all, > > I'm trying to compile openzfs using SBo. > > > > I got a long warning list while running the SB: > > > > libtool: warning: relinking 'libzfs_core.la' > > libtool: warning: 'libzfs.la' has not been installed in '/lib64' > > libtool: warning: 'libnvpair.la' has not been installed in '/lib64' > > libtool: warning: relinking 'contrib/pam_zfs_key/pam_zfs_key.la' > > libtool: warning: '/tmp/SBo/zfs-2.2.4/libzfs_core.la' has not been > > installed in '/lib64' > > ... > > > installed in '/lib64' > > libtool: warning: 'libzfs_core.la' has not been installed in '/lib64' > > libtool: warning: '/tmp/SBo/zfs-2.2.4/libnvpair.la' has not been > > installed in '/lib64' > > libtool: warning: 'libnvpair.la' has not been installed in '/lib64' > > libtool: warning: 'libuutil.la' has not been installed in '/lib64' > > > > > > Those should be considered critical or this is something expected? > > Hi Alessandro, > > I ignore these warnings with no issues. If you look at line 118 of > openzfs.SlackBulid, you can see that the .la files are intentionally > removed. This is consistent with the SBo autotools template: > https://slackbuilds.org/templates/autotools-template.SlackBuild > > As far as why SBo doesn't ship .la files, I do know. Can anyone share why? > This is to match what Slackware does (which historically SBo tries to do). Pat removed most .la files during the development of 15.0 and SBo rolled it out when they pushed their 15.0 repo and updated their templates. Here's the changelog entry from Pat: Thu Apr 19 01:04:06 UTC 2018 Hi folks, and welcome to the third ever Slackware Mass Rebuild (and the longest ChangeLog entry in project history). There were two primary motivations for rebuilding everything in the main tree. The first was to switch to the new C++ ABI. The second was to get rid of all the .la files in the LD_LIBRARY_PATH. Really, having .la files installed has been mostly obsolete since things began to use pkg-config instead, but it's not easy to get rid of them unless you do it all at once. If you just take them out of one package, any other packages containing .la files that refer to the removed ones will be broken. We've removed a few here and there before (and then handled any packages that had referred to them with a rebuild), but it was time to finally remove all the ones in /lib{,64} and /usr/lib{,64}. One of the reasons that this really needed to happen is that many projects are starting to migrate to build systems other than autotools, and those systems do not generate .la files. So if we didn't get rid of them now, we might end up in a situation later on where they are being removed by upstream and then we would have to chase down the dependency breakage and recompile (possibly many) other packages. The .la files that are outside of the LD_LIBRARY_PATH were not removed (and shouldn't be) - those ones are often used by the lt_dlopen() function to load plugins and removing those ones can break things. But those ones don't cause problems... they aren't likely to try to IMPORTANT NOTE: If you have any third party or other packages installed on your system that don't come with Slackware, and those packages have installed any .la files, it is very likely that they refer to some .la files which we have just removed, and that trying to compile against these packages will no longer work. Luckily, the solution is simple: remove them. This command will remove any stale .la files from the LD_LIBRARY_PATH: rm /{,usr/}lib{,64}/*.la Moving forward, nothing shipped in Slackware will contain any .la files in those directories, and any SlackBuilds intended to be used with Slackware 15.0 should contain this bit of script: # Don't ship .la files: rm -f $PKG/{,usr/}lib${LIBDIRSUFFIX}/*.la In addition to those goals, the opportunity was taken to clean up slack-desc files and make many trivial fixes to build scripts. We've also made it easy to recompile everything again should there be a good reason to do so. You'll also find various updates scattered throughout this long list. Enjoy, and sorry about the bandwidth. ;-) Jeremy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From urchlay at slackware.uk Mon Jul 22 19:25:50 2024 From: urchlay at slackware.uk (B. Watson) Date: Mon, 22 Jul 2024 15:25:50 -0400 (EDT) Subject: [Slackbuilds-users] openzfs warning during compilation In-Reply-To: <1758d154-62e9-4282-bb98-3daabeb5ad33@gmail.com> References: <1758d154-62e9-4282-bb98-3daabeb5ad33@gmail.com> Message-ID: <88527cc3-c48d-a52e-f160-d452e78812@slackware.uk> On Mon, 22 Jul 2024, Alessandro Baggi wrote: > libtool: warning: 'libnvpair.la' has not been installed in '/lib64' > libtool: warning: 'libuutil.la' has not been installed in '/lib64' > > > Those should be considered critical or this is something expected? Expected. And correct: the libraries haven't been installed in /usr/lib64 or /lib64... and won't be; they're going to get installed to $TMP/package-openzfs/{lib64,usr/lib64}. From dickson.tim at googlemail.com Thu Jul 25 15:00:44 2024 From: dickson.tim at googlemail.com (Tim Dickson) Date: Thu, 25 Jul 2024 16:00:44 +0100 Subject: [Slackbuilds-users] SBo-GitHub-Workflows.txt update suggestion Message-ID: hi all, regarding https://slackbuilds.org/SBo-Github-Workflows.txt A suggestion/request to help the git neophytes. it would be nice to add a point between 2 and 3 explaining how to create a certificate and upload it to you git account, otherwise point 3 onwards will fail. something like.... if you haven't created a key for secure access, run ssh-keygen -t ed25519 -C "your at email.address" then cat ~/.ssh/id_ed25519 copy the text of the catted file in web-browser on github, click your profile icon (top left), click settings, under access (on the left) click SSH and GPG keys click "New SSH key", add a title of your choice, and paste the copied key into the key text box, then click "Add SSH key" regards, Tim -- This email has been checked for viruses by AVG antivirus software. www.avg.com From duncan_roe at optusnet.com.au Fri Jul 26 01:34:35 2024 From: duncan_roe at optusnet.com.au (Duncan Roe) Date: Fri, 26 Jul 2024 11:34:35 +1000 Subject: [Slackbuilds-users] SBo-GitHub-Workflows.txt update suggestion In-Reply-To: References: Message-ID: Hi Tim, On Thu, Jul 25, 2024 at 04:00:44PM +0100, SlackBuilds wrote: > hi all, regarding https://slackbuilds.org/SBo-Github-Workflows.txt > A suggestion/request to help the git neophytes. > > it would be nice to add a point between 2 and 3 explaining how to create a > certificate and upload it to you git account, otherwise point 3 onwards will > fail. something like.... > > if you haven't created a key for secure access, run > ssh-keygen -t ed25519 -C "your at email.address" > then > cat ~/.ssh/id_ed25519 > copy the text of the catted file > in web-browser on github, click your profile icon (top left), click > settings, under access (on the left) click SSH and GPG keys > click "New SSH key", add a title of your choice, and paste the copied key > into the key text box, then click "Add SSH key" > > regards, Tim > ssh-keygen -t ed25519 -C "your at email.address" creates id_ed25519 and id_ed25519.pub in ~/.ssh I really think it is id_ed25519.pub that you want to share with others. Cheers ... Duncan. From willysr at slackbuilds.org Fri Jul 26 02:45:09 2024 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Fri, 26 Jul 2024 09:45:09 +0700 Subject: [Slackbuilds-users] SBo-GitHub-Workflows.txt update suggestion In-Reply-To: References: Message-ID: <03930ced-ab48-4112-bbe6-6779c7c3a249@slackbuilds.org> > hi all, regarding https://slackbuilds.org/SBo-Github-Workflows.txt > A suggestion/request to help the git neophytes. > > it would be nice to add a point between 2 and 3 explaining how to create > a certificate and upload it to you git account, otherwise point 3 > onwards will fail. something like.... > > if you haven't created a key for secure access, run > ssh-keygen -t ed25519 -C "your at email.address" > then > cat ~/.ssh/id_ed25519 > copy the text of the catted file > in web-browser on github, click your profile icon (top left), click > settings, under access (on the left) click SSH and GPG keys > click "New SSH key", add a title of your choice, and paste the copied > key into the key text box, then click "Add SSH key" This is more of personal options you can have, but AFAIK, it's not really necessary to do this in order to send PR to SBo -- Willy Sudiarto Raharjo -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0x3F617144D7238786.asc Type: application/pgp-keys Size: 8363 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From dickson.tim at googlemail.com Fri Jul 26 14:55:47 2024 From: dickson.tim at googlemail.com (Tim Dickson) Date: Fri, 26 Jul 2024 15:55:47 +0100 Subject: [Slackbuilds-users] SBo-GitHub-Workflows.txt update suggestion In-Reply-To: <03930ced-ab48-4112-bbe6-6779c7c3a249@slackbuilds.org> References: <03930ced-ab48-4112-bbe6-6779c7c3a249@slackbuilds.org> Message-ID: without setting up a key, the command gitclone git at github:/slackbuils.git fails with the error Cloning into 'slackbuilds'... git at github.com: Permission denied (publickey). fatal: Could not read from remote repository. (at least for me, YMMV) regards, Tim On 26/07/2024 03:45, Willy Sudiarto Raharjo wrote: >> hi all, regarding https://slackbuilds.org/SBo-Github-Workflows.txt >> A suggestion/request to help the git neophytes. >> >> it would be nice to add a point between 2 and 3 explaining how to >> create a certificate and upload it to you git account, otherwise >> point 3 onwards will fail. something like.... >> >> if you haven't created a key for secure access, run >> ssh-keygen -t ed25519 -C "your at email.address" >> then >> cat ~/.ssh/id_ed25519 >> copy the text of the catted file >> in web-browser on github, click your profile icon (top left), click >> settings, under access (on the left) click SSH and GPG keys >> click "New SSH key", add a title of your choice, and paste the copied >> key into the key text box, then click "Add SSH key" > > This is more of personal options you can have, but AFAIK, it's not > really necessary to do this in order to send PR to 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/ > -- This email has been checked for viruses by AVG antivirus software. www.avg.com From willysr at slackbuilds.org Sat Jul 27 01:24:41 2024 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sat, 27 Jul 2024 08:24:41 +0700 Subject: [Slackbuilds-users] Updates - 20240727.1 Message-ID: <263850c6-87a8-4cbf-adaf-75bd0e887d9b@slackbuilds.org> Sat Jul 27 01:17:53 UTC 2024 academic/cdo: Updated for version 2.4.2. academic/fet: Updated for version 6.22.2. academic/nco: Updated for version 5.2.7. academic/qucs-s: Updated for version 24.3.0. academic/xiphos: add webkit2gtk4.1 support audio/tauonmb: Maintainer's adjustment. desktop/kfaenza-icon-theme: Fix source. desktop/rss-guard: Updated for version 4.7.3. development/aspnetcore-runtime-7.0: Updated for version 7.0.20. development/aspnetcore-runtime-8.0: Updated for version 8.0.7. development/aws-cdk: Updated for version 2.150.0. development/chicken: Updated for version 5.4.0. development/dotnet-runtime-6.0: Updated for version 6.0.32. development/dotnet-runtime-7.0: Updated for version 7.0.20. development/dotnet-runtime-8.0: Updated for version 8.0.7. development/dotnet-sdk-6.0: Updated for version 6.0.424. development/dotnet-sdk-7.0: Updated for version 7.0.410. development/dotnet-sdk-8.0: Updated for version 8.0.303. development/github-cli: Updated for version 2.53.0 development/jdk: Updated for version 8u411. development/kicad: Updated for version 8.0.4. development/neovim: Updated for version 0.10.1. development/nodejs: Updated for version 20.16.0. development/openjdk7: fix build failure. development/postman: Updated for version 11.4.0 development/rider: Added (.NET IDE). development/uncrustify: Updated for version 0.79.0 games/ddnet: Updated for version 18.4 games/opensurge: Updated for version 0.6.1.1. games/scribble: Removed (upstream is gone). games/surgescript: Updated for version 0.6.0. games/vcmi: updated for version 1.5.5 games/vkQuake: Updated for version 1.31.0. gis/eccodes: Updated for version 2.36.0. graphics/flameshot: Updated for version 12.1.0. graphics/jpeg2ps: Fix download link. graphics/psftools: Updated for version 1.1.2. ham/qsstv: Fix broken link. libraries/allegro: updated REQUIRES libraries/aspnetcore-runtime-6.0: Updated for version 6.0.32. libraries/ayatana-ido: Updated for version 0.10.3. libraries/camlpdf: Updated for version 2.7.1. libraries/imlib2: Updated for version 1.12.3. libraries/libayatana-appindicator: Taking over maintainership. libraries/libayatana-indicator: Taking over maintainership. libraries/libcurl-gnutls: Updated for version 8.9.0. libraries/libgit2-glib: Updated for 1.0.0.1. libraries/libheif: Updated for version 1.18.1. libraries/libjodycode: Updated for version 3.1.1. libraries/libjwt: updated for version 1.17.2 libraries/liblastfm-qt5: Added (Qt C++ library for the Last.fm). libraries/mimalloc: Updated for version 2.1.7. libraries/protobuf-c: Remove faulty patch. libraries/rabbitmq-c: Fix script. misc/OSCAR: Updated for version 1.5.3 misc/bitwarden-desktop: Updated for version 2024.7.1. misc/yubioath-desktop: Do not write to $CWD. multimedia/ffmpeg2theora: Fix broken link. multimedia/qdvdauthor: Update script. multimedia/spotify: Fix permission. multimedia/spotify: Updated for version 1.2.42.290. network/anydesk: Updated for version 6.3.2. network/discord: Updated for version 0.0.61. network/netsurf: Updated for version 3.11. network/nordvpn: Updated for version 3.18.3. network/opera: Updated for version 112.0.5197.30. network/signal-desktop: Updated for version 7.17.0. network/teamviewer: Updated for version 15.55.3. network/windscribe: Updated for version 2.10.15. network/zoom-linux: Updated for version 6.1.5.871 office/apvlv: Update for 0.6.0 office/cpdf: Updated for version 2.7.1. office/focuswriter-qt6: updated for version 1.8.8 office/gnucash: add webkit2gtk4.1 support office/pdfstudio: Updated for version 2024.0.1. office/pdfstudioviewer: Updated for version 2024.0.1. office/qtrans: Fix script. python/instaloader: Added (Download content from Instagram). python/mypy: Updated for version 1.11.0. python/pyOpenSSL: Updated for version 24.2.1. python/python-krb5: Updated for version 0.6.0. python/python3-PyMuPDF: Updated for version 1.24.9. python/python3-atpublic: Updated for version 5.0. python/python3-dep-logic: Updated for version 0.4.4. python/python3-gast: Downgrade to 0.5.5 python/python3-incremental: Updated for version 24.7.0. python/python3-pdm-build-locked: Updated for version 0.3.2. python/python3-pdm: Updated for version 2.17.1. python/python3-plotly: Update for 5.23.0 python/python3-pure_eval: Updated for version 0.2.3. python/python3-pytest: Updated for version 8.3.1. python/python3-regex: Update for 2024.7.24 python/pyudev: Removed (rename to python3-pyudev) ruby/ruby-build: Updated for version 20240722. system/Iosevka-slab: Updated for version 30.3.3 system/Iosevka: Updated for version 30.3.3 system/android-udev-rules: Updated for version 2024.06.25. system/conky: Updated for version 1.21.5. system/containerd: Updated for version 1.7.20. system/docker-buildx: Updated for version 0.16.2. system/docker-cli: Updated for version 27.1.1. system/docker: Updated for version 27.1.1. system/fastfetch: Updated for version 2.19.1. system/k3s: Updated to 1.30.2.2. system/lxqt-admin: Added (LXQt system administration tool). system/mongo-tools: Updated for version 100.9.5. system/netdata: Updated for version 1.46.3. system/nix: Updated for version 2.17.2. system/powershell: Updated for version 7.4.4. system/pv: updated for version 1.8.12 system/runc: Updated for version 1.1.13. system/targetcli-fb: Added rc script. system/tomb: Fix repository changes. system/webmin: Updated for version 2.200. system/worker: Updated for version 5.1.0 system/yelp: add webkit2gtk4.1 support +--------------------------+ -- Willy Sudiarto Raharjo -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From willysr at slackbuilds.org Sat Jul 27 01:29:34 2024 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sat, 27 Jul 2024 08:29:34 +0700 Subject: [Slackbuilds-users] SBo-GitHub-Workflows.txt update suggestion In-Reply-To: References: <03930ced-ab48-4112-bbe6-6779c7c3a249@slackbuilds.org> Message-ID: > without setting up a key, the command > > gitclone git at github:/slackbuils.git > > fails with the error > > Cloning into 'slackbuilds'... > git at github.com: Permission denied (publickey). > fatal: Could not read from remote repository. I updated the initial steps to fork your local repo 3. Clone SBo GitHub repo from your repository to your local machine(s) git clone git at github.com:/slackbuilds.git (if you have setup SSH keys) git clone https://github.com//slackbuilds.git (if you don't setup SSH keys) -- Willy Sudiarto Raharjo -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From arkadiusz at drabczyk.org Sat Jul 27 17:55:42 2024 From: arkadiusz at drabczyk.org (Arkadiusz Drabczyk) Date: Sat, 27 Jul 2024 12:55:42 -0500 Subject: [Slackbuilds-users] system/virtualbox does not start Message-ID: <595b32ff1560f44f5acc3a9b10ec1ce5@drabczyk.org> Like that: $ sudo /etc/rc.d/rc.vboxdrv start vboxdrv.sh: Starting VirtualBox services. /etc/rc.d/rc.vboxdrv: line 162: kernel_requires_module_signature: command not found The fix is to remove commented lines: start() { begin_msg "Starting VirtualBox services" console if [ -d /proc/xen ]; then failure "Running VirtualBox in a Xen environment is not supported" fi # if test "$(kernel_requires_module_signature)" = "1" && test -z "$DEB_KEY_ENROLLED"; then # if test -n "$HAVE_DEB_KEY"; then # begin_msg "You must re-start your system to finish Debian secure boot set-up." console # else # begin_msg "You must sign these kernel modules before using VirtualBox: # $MODULE_LIST # See the documentation for your Linux distribution." console # fi # fi I'm building and running this on -current but the same problem should occur on stable but I cannot try it because I don't have stable installation at hand, I'm just trying to run it under VirtualBox so quite funny situation I'd say. -- Arkadiusz Drabczyk From arkadiusz at drabczyk.org Sun Jul 28 17:37:50 2024 From: arkadiusz at drabczyk.org (Arkadiusz Drabczyk) Date: Sun, 28 Jul 2024 12:37:50 -0500 Subject: [Slackbuilds-users] system/dstat slackbuild cannot extract tarball Message-ID: $ wget 'https://github.com/dstat-real/dstat/archive/refs/tags/v0.7.4.tar.gz' --2024-07-28 19:36:09-- https://github.com/dstat-real/dstat/archive/refs/tags/v0.7.4.tar.gz Resolving github.com (github.com)... 140.82.121.4 Connecting to github.com (github.com)|140.82.121.4|:443... connected. HTTP request sent, awaiting response... 302 Found Location: https://codeload.github.com/dstat-real/dstat/tar.gz/refs/tags/v0.7.4 [following] --2024-07-28 19:36:09-- https://codeload.github.com/dstat-real/dstat/tar.gz/refs/tags/v0.7.4 Resolving codeload.github.com (codeload.github.com)... 140.82.121.10 Connecting to codeload.github.com (codeload.github.com)|140.82.121.10|:443... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [application/x-gzip] Saving to: ?v0.7.4.tar.gz? v0.7.4.tar.gz [ <=> ] 136.71K --.-KB/s in 0.08s 2024-07-28 19:36:09 (1.72 MB/s) - ?v0.7.4.tar.gz? saved [139992] $ sudo bash dstat.SlackBuild tar: /home/ja/slackbuilds/system/dstat/dstat-0.7.4.tar.gz: Cannot open: No such file or directory tar: Error is not recoverable: exiting now tar: /home/ja/slackbuilds/system/dstat/0.7.4.tar.gz: Cannot open: No such file or directory tar: Error is not recoverable: exiting now -- Arkadiusz Drabczyk From arkadiusz at drabczyk.org Sun Jul 28 17:44:25 2024 From: arkadiusz at drabczyk.org (Arkadiusz Drabczyk) Date: Sun, 28 Jul 2024 12:44:25 -0500 Subject: [Slackbuilds-users] system/dstat slackbuild cannot extract tarball In-Reply-To: References: Message-ID: On 2024-07-28 12:37, Arkadiusz Drabczyk wrote: > $ wget > 'https://github.com/dstat-real/dstat/archive/refs/tags/v0.7.4.tar.gz' > --2024-07-28 19:36:09-- > https://github.com/dstat-real/dstat/archive/refs/tags/v0.7.4.tar.gz > Resolving github.com (github.com)... 140.82.121.4 > Connecting to github.com (github.com)|140.82.121.4|:443... connected. > HTTP request sent, awaiting response... 302 Found > Location: > https://codeload.github.com/dstat-real/dstat/tar.gz/refs/tags/v0.7.4 > [following] > --2024-07-28 19:36:09-- > https://codeload.github.com/dstat-real/dstat/tar.gz/refs/tags/v0.7.4 > Resolving codeload.github.com (codeload.github.com)... 140.82.121.10 > Connecting to codeload.github.com > (codeload.github.com)|140.82.121.10|:443... connected. > HTTP request sent, awaiting response... 200 OK > Length: unspecified [application/x-gzip] > Saving to: ?v0.7.4.tar.gz? > > v0.7.4.tar.gz [ <=> > > ] 136.71K --.-KB/s in 0.08s > > 2024-07-28 19:36:09 (1.72 MB/s) - ?v0.7.4.tar.gz? saved [139992] > > $ sudo bash dstat.SlackBuild > tar: /home/ja/slackbuilds/system/dstat/dstat-0.7.4.tar.gz: Cannot open: > No such file or directory > tar: Error is not recoverable: exiting now > tar: /home/ja/slackbuilds/system/dstat/0.7.4.tar.gz: Cannot open: No > such file or directory > tar: Error is not recoverable: exiting now OTOH this project is terminated so the package can be completely removed https://github.com/dstat-real/dstat/issues/170. -- Arkadiusz Drabczyk From arkadiusz at drabczyk.org Sun Jul 28 17:56:33 2024 From: arkadiusz at drabczyk.org (Arkadiusz Drabczyk) Date: Sun, 28 Jul 2024 12:56:33 -0500 Subject: [Slackbuilds-users] system/dstat slackbuild cannot extract tarball In-Reply-To: References: Message-ID: On 2024-07-28 12:44, Arkadiusz Drabczyk wrote: > On 2024-07-28 12:37, Arkadiusz Drabczyk wrote: >> $ wget >> 'https://github.com/dstat-real/dstat/archive/refs/tags/v0.7.4.tar.gz' >> --2024-07-28 19:36:09-- >> https://github.com/dstat-real/dstat/archive/refs/tags/v0.7.4.tar.gz >> Resolving github.com (github.com)... 140.82.121.4 >> Connecting to github.com (github.com)|140.82.121.4|:443... connected. >> HTTP request sent, awaiting response... 302 Found >> Location: >> https://codeload.github.com/dstat-real/dstat/tar.gz/refs/tags/v0.7.4 >> [following] >> --2024-07-28 19:36:09-- >> https://codeload.github.com/dstat-real/dstat/tar.gz/refs/tags/v0.7.4 >> Resolving codeload.github.com (codeload.github.com)... 140.82.121.10 >> Connecting to codeload.github.com >> (codeload.github.com)|140.82.121.10|:443... connected. >> HTTP request sent, awaiting response... 200 OK >> Length: unspecified [application/x-gzip] >> Saving to: ?v0.7.4.tar.gz? >> >> v0.7.4.tar.gz [ <=> >> >> ] 136.71K --.-KB/s in 0.08s >> >> 2024-07-28 19:36:09 (1.72 MB/s) - ?v0.7.4.tar.gz? saved [139992] >> >> $ sudo bash dstat.SlackBuild >> tar: /home/ja/slackbuilds/system/dstat/dstat-0.7.4.tar.gz: Cannot >> open: No such file or directory >> tar: Error is not recoverable: exiting now >> tar: /home/ja/slackbuilds/system/dstat/0.7.4.tar.gz: Cannot open: No >> such file or directory >> tar: Error is not recoverable: exiting now > > OTOH this project is terminated so the package can be completely > removed https://github.com/dstat-real/dstat/issues/170. I now found that tarballs have a different name when they are downloaded using Firefox but still the package can be removed. -- Arkadiusz Drabczyk From urchlay at slackware.uk Sun Jul 28 19:16:29 2024 From: urchlay at slackware.uk (B. Watson) Date: Sun, 28 Jul 2024 15:16:29 -0400 (EDT) Subject: [Slackbuilds-users] system/dstat slackbuild cannot extract tarball In-Reply-To: References: Message-ID: <8595261-e055-c83-bbb6-98106073e60@slackware.uk> On Sun, 28 Jul 2024, Arkadiusz Drabczyk wrote: >> OTOH this project is terminated so the package can be completely >> removed https://github.com/dstat-real/dstat/issues/170. > > I now found that tarballs have a different name when they are > downloaded using Firefox but still the package can be removed. Does it still work, and is it still useful? If so, it should stay. We don't have to immediately remove things from SBo just because they're no longer maintained upstream. Eventually, it might have to be removed because it stops working (e.g. due to kernel changes), or because it becomes too much of a burden to keep patching it for newer compilers/libraries/etc. The other reason to remove it from our repo would be because it's no longer maintained on SBo. But that's not the case here. What dstat needs, for now, is just a proper github download URL in the .info file. From arkadiusz at drabczyk.org Sun Jul 28 19:28:54 2024 From: arkadiusz at drabczyk.org (Arkadiusz Drabczyk) Date: Sun, 28 Jul 2024 14:28:54 -0500 Subject: [Slackbuilds-users] system/dstat slackbuild cannot extract tarball In-Reply-To: References: Message-ID: On 2024-07-28 12:56, Arkadiusz Drabczyk wrote: > On 2024-07-28 12:44, Arkadiusz Drabczyk wrote: >> On 2024-07-28 12:37, Arkadiusz Drabczyk wrote: >>> $ wget >>> 'https://github.com/dstat-real/dstat/archive/refs/tags/v0.7.4.tar.gz' >>> --2024-07-28 19:36:09-- >>> https://github.com/dstat-real/dstat/archive/refs/tags/v0.7.4.tar.gz >>> Resolving github.com (github.com)... 140.82.121.4 >>> Connecting to github.com (github.com)|140.82.121.4|:443... connected. >>> HTTP request sent, awaiting response... 302 Found >>> Location: >>> https://codeload.github.com/dstat-real/dstat/tar.gz/refs/tags/v0.7.4 >>> [following] >>> --2024-07-28 19:36:09-- >>> https://codeload.github.com/dstat-real/dstat/tar.gz/refs/tags/v0.7.4 >>> Resolving codeload.github.com (codeload.github.com)... 140.82.121.10 >>> Connecting to codeload.github.com >>> (codeload.github.com)|140.82.121.10|:443... connected. >>> HTTP request sent, awaiting response... 200 OK >>> Length: unspecified [application/x-gzip] >>> Saving to: ?v0.7.4.tar.gz? >>> >>> v0.7.4.tar.gz [ <=> >>> >>> ] 136.71K --.-KB/s in 0.08s >>> >>> 2024-07-28 19:36:09 (1.72 MB/s) - ?v0.7.4.tar.gz? saved [139992] >>> >>> $ sudo bash dstat.SlackBuild >>> tar: /home/ja/slackbuilds/system/dstat/dstat-0.7.4.tar.gz: Cannot >>> open: No such file or directory >>> tar: Error is not recoverable: exiting now >>> tar: /home/ja/slackbuilds/system/dstat/0.7.4.tar.gz: Cannot open: No >>> such file or directory >>> tar: Error is not recoverable: exiting now >> >> OTOH this project is terminated so the package can be completely >> removed https://github.com/dstat-real/dstat/issues/170. > > I now found that tarballs have a different name when they are > downloaded using Firefox but still the package can be removed. But actually no, wait, it will not work in sbopkg with the default settings: Processing dstat dstat: Found v0.7.4.tar.gz in /var/cache/sbopkg. Checking MD5SUM: MD5SUM check for v0.7.4.tar.gz ... OK Building package for dstat... tar: /var/lib/sbopkg/local/system/dstat/dstat-0.7.4.tar.gz: Cannot open: No such file or directory tar: Error is not recoverable: exiting now tar: /var/lib/sbopkg/local/system/dstat/0.7.4.tar.gz: Cannot open: No such file or directory tar: Error is not recoverable: exiting now dstat: Would you like to continue processing the rest of the queue or would you like to abort? If this failed package is a dependency of another package in the queue then it may not make sense to continue. (Y)es to continue, (N)o to abort, (R)etry the build?: Some slackbuilds try multiple tarball names and dstat does it too but it uses incorrect name, it should be: tar xvf $CWD/$PRGNAM-$VERSION.tar.gz || tar xvf $CWD/v$VERSION.tar.gz There is a similar problem in network/ngrep but this script is more optimistic and does not try different tarballs: tar xvf $CWD/$PRGNAM-$SOURCEVERSION.tar.gz It will not work with sbopkg neither. And there is network/radicale/radicale.SlackBuild which tries 3 different tarball names including the version with `v` at the beginning that dstat has missed but it isn't checked in $CWD: tar xvf $CWD/$PRGNAM-$VERSION.tar.gz || tar xvf $CWD/Radicale-$VERSION.tar.gz || tar xvf v$VERSION.tar.gz so that will not work neither. Interestingly in this case wget gets a correct filename even w/o using --content-disposition: $ wget https://github.com/Kozea/Radicale/archive/refs/tags/v3.1.8/radicale-3.1.8.tar.gz --2024-07-28 21:27:02-- https://github.com/Kozea/Radicale/archive/refs/tags/v3.1.8/radicale-3.1.8.tar.gz Resolving github.com (github.com)... 140.82.121.3 Connecting to github.com (github.com)|140.82.121.3|:443... connected. HTTP request sent, awaiting response... 302 Found Location: https://codeload.github.com/Kozea/Radicale/tar.gz/refs/tags/v3.1.8 [following] --2024-07-28 21:27:02-- https://codeload.github.com/Kozea/Radicale/tar.gz/refs/tags/v3.1.8 Resolving codeload.github.com (codeload.github.com)... 140.82.121.10 Connecting to codeload.github.com (codeload.github.com)|140.82.121.10|:443... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [application/x-gzip] Saving to: ?radicale-3.1.8.tar.gz? radicale-3.1.8.tar.gz [ <=> ] 133.91K --.-KB/s in 0.08s 2024-07-28 21:27:02 (1.69 MB/s) - ?radicale-3.1.8.tar.gz? saved [137123] -- Arkadiusz Drabczyk From urchlay at slackware.uk Sun Jul 28 19:50:24 2024 From: urchlay at slackware.uk (B. Watson) Date: Sun, 28 Jul 2024 15:50:24 -0400 (EDT) Subject: [Slackbuilds-users] system/dstat slackbuild cannot extract tarball In-Reply-To: References: Message-ID: On Sun, 28 Jul 2024, Arkadiusz Drabczyk wrote: > Some slackbuilds try multiple tarball names and dstat does it too but > it uses incorrect name, it should be: > > tar xvf $CWD/$PRGNAM-$VERSION.tar.gz || tar xvf > $CWD/v$VERSION.tar.gz > > There is a similar problem in network/ngrep but this script is more > optimistic and does not try different tarballs: > > tar xvf $CWD/$PRGNAM-$SOURCEVERSION.tar.gz > > It will not work with sbopkg neither. Right, but it's easily fixed. The maintainer should just follow this guide: https://slackbuilds.org/GITHUB_URLs.txt > And there is network/radicale/radicale.SlackBuild which tries 3 > different tarball names including the version with `v` at the > beginning that dstat has missed but it isn't checked in $CWD: > > tar xvf $CWD/$PRGNAM-$VERSION.tar.gz || tar xvf > $CWD/Radicale-$VERSION.tar.gz || tar xvf v$VERSION.tar.gz > > so that will not work neither. Interestingly in this case wget gets a > correct filename even w/o using --content-disposition: Right. Because radicale does use a "canonical" github download link. The extra code that checks for various other tarball filenames could be removed, since it's not needed. sbolint attempts to flag this issue, but might not be 100% reliable. From jebrhansen+SBo at gmail.com Sun Jul 28 23:58:07 2024 From: jebrhansen+SBo at gmail.com (Jeremy Hansen) Date: Sun, 28 Jul 2024 16:58:07 -0700 Subject: [Slackbuilds-users] GitHub (and PyPI) Download Helper Message-ID: I added some functionality to my slackbuild generator script last year to make sure source links to github always link to the proper location so it works with or without content disposition. I also added support for pythonhosted and pypi links to get the non-hashed download link so I can more easily use my version-bump script to update my packages (since the hash in the URL would change for every new version of that program). After thinking about doing this for some time and seeing a few recent emails about github download problems, I finally decided to excise it from my script and tweak it so it can be used standalone for people to check their github and python links. It's built as a function, so you can add it to your own script, add it to your environment, or just pass a URL to the script. Feel free to test it and let me know if you find any issues. I've been using it for well over a year and it seems to be working fine. I present, check-source-download.sh : $ check-source-download.sh https://github.com/nucleic/kiwi/releases/download/1.4.5/kiwisolver-1.4.5.tar.gz https://github.com/nucleic/kiwi/releases/download/1.4.5/kiwisolver-1.4.5.tar.gz $ check-source-download.sh https://github.com/nucleic/kiwi/archive/refs/tags/1.4.5.tar.gz https://github.com/nucleic/kiwi/archive/refs/tags/1.4.5/kiwi-1.4.5.tar.gz $ check-source-download.sh https://github.com/nucleic/kiwi/archive/03adafeb0f1188e34cde4c7ca8fe384912bd9e1b.zip https://github.com/nucleic/kiwi/archive/03adafe/kiwi-03adafeb0f1188e34cde4c7ca8fe384912bd9e1b.tar.gz $ check-source-download.sh https://github.com/nucleic/kiwi/archive/03adafeb0f1188e34cde4c7ca8fe384912bd9e1b.tar.gz https://github.com/nucleic/kiwi/archive/03adafe/kiwi-03adafeb0f1188e34cde4c7ca8fe384912bd9e1b.tar.gz $ check-source-download.sh https://files.pythonhosted.org/packages/0f/ed/a02b18943f9162644f90354fe6445410e942c857dd21ded758f630ba41c0/pymediainfo-6.1.0.tar.gz https://files.pythonhosted.org/packages/source/p/pymediainfo/pymediainfo-0.1.6.tar.gz Jeremy -------------- next part -------------- An HTML attachment was scrubbed... URL: From urchlay at slackware.uk Mon Jul 29 19:42:42 2024 From: urchlay at slackware.uk (B. Watson) Date: Mon, 29 Jul 2024 15:42:42 -0400 (EDT) Subject: [Slackbuilds-users] libhandy about to update to 1.8.3 Message-ID: <04d8c3-9f9a-581c-3e81-b91f6e1c1755@slackware.uk> Someone requested an update to libhandy, so I'm updating it to the latest stable, version 1.8.3. A lot of GNOME builds depend on libhandy. If your build appears on this list: https://slackbuilds.org/advsearch.php?stype=revdep&q=libhandy ...then you should test it with libhandy-1.8.3. To do this, download the source from https://download.gnome.org/sources/libhandy/1.8/libhandy-1.8.3.tar.xz, make sure gi-docgen is installed (it's a new dependency for libhandy), and run libhandy.SlackBuild with VERSION=1.8.3 set in the environment. Then install/upgrade the package you just built. I've test-built everything on the list except nwg-shell (because it has 106 dependencies) and epiphany (waiting for webkit2gtk-4.1 to finish building, as I write this). Everything builds fine with the new libhandy. I didn't run-test everything: I don't run Wayland so I didn't try to run SwayNotificationCenter or nwg-panel. Some of the GNOME components won't work outside of a GNOME session (the ones that will, seem to run correctly). Details here: https://slackware.uk/~urchlay/src/libhandy-testing.20240729.txt My run-testing isn't in-depth: I don't use any of these applications, so mostly I just made sure they'd start up, and do some simple things (e.g. view one image in gnome-photos, get one set of directions from gnome-maps). The maintainers of these builds should really do their own in-depth testing. If nobody reports any problems by Friday, the libhandy update will be merged in the next weekly update. From j at lngn.net Mon Jul 29 21:18:20 2024 From: j at lngn.net (Jay Lanagan) Date: Mon, 29 Jul 2024 17:18:20 -0400 Subject: [Slackbuilds-users] libhandy about to update to 1.8.3 In-Reply-To: <04d8c3-9f9a-581c-3e81-b91f6e1c1755@slackware.uk> References: <04d8c3-9f9a-581c-3e81-b91f6e1c1755@slackware.uk> Message-ID: <9DA002E5-256F-435E-ADEC-95825035F3F8@edison.tech> Nwg-shell works as intended with the latest libhandy as I actively maintain the environment on current, where it?s included within Slackware. Gnome should be fine as well, but I may be mis-remembering how 41/42 works, I?ll assume 0xBob will pipe in if there?s any pre-existing issues with it. ? Jay Lanagan > > On Jul 29, 2024 at 3:42 PM, wrote: > > > > Someone requested an update to libhandy, so I'm updating it to the latest stable, version 1.8.3. A lot of GNOME builds depend on libhandy. If your build appears on this list: https://slackbuilds.org/advsearch.php?stype=revdep&q=libhandy ...then you should test it with libhandy-1.8.3. To do this, download the source from https://download.gnome.org/sources/libhandy/1.8/libhandy-1.8.3.tar.xz, make sure gi-docgen is installed (it's a new dependency for libhandy), and run libhandy.SlackBuild with VERSION=1.8.3 set in the environment. Then install/upgrade the package you just built. I've test-built everything on the list except nwg-shell (because it has 106 dependencies) and epiphany (waiting for webkit2gtk-4.1 to finish building, as I write this). Everything builds fine with the new libhandy. I didn't run-test everything: I don't run Wayland so I didn't try to run SwayNotificationCenter or nwg-panel. Some of the GNOME components won't work outside of a GNOME session (the ones that will, seem to run correctly). Details here: https://slackware.uk/~urchlay/src/libhandy-testing.20240729.txt My run-testing isn't in-depth: I don't use any of these applications, so mostly I just made sure they'd start up, and do some simple things (e.g. view one image in gnome-photos, get one set of directions from gnome-maps). The maintainers of these builds should really do their own in-depth testing. If nobody reports any problems by Friday, the libhandy update will be merged in the next weekly update. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From urchlay at slackware.uk Mon Jul 29 21:42:36 2024 From: urchlay at slackware.uk (B. Watson) Date: Mon, 29 Jul 2024 17:42:36 -0400 (EDT) Subject: [Slackbuilds-users] libhandy about to update to 1.8.3 In-Reply-To: <04d8c3-9f9a-581c-3e81-b91f6e1c1755@slackware.uk> References: <04d8c3-9f9a-581c-3e81-b91f6e1c1755@slackware.uk> Message-ID: On Mon, 29 Jul 2024, B. Watson wrote: > I've test-built everything on the list except nwg-shell (because it > has 106 dependencies) and epiphany (waiting for webkit2gtk-4.1 to > finish building, as I write this). Update: epiphany builds and runs fine. From bobfunk11 at gmail.com Mon Jul 29 22:36:37 2024 From: bobfunk11 at gmail.com (Bob Funk) Date: Mon, 29 Jul 2024 17:36:37 -0500 Subject: [Slackbuilds-users] libhandy about to update to 1.8.3 In-Reply-To: References: <04d8c3-9f9a-581c-3e81-b91f6e1c1755@slackware.uk> Message-ID: If the gnome stack of software is building then it'll probably be fine at runtime too. I am traveling currently and won't be back home till next Sunday so I won't be able to do much until after then. I'll be happy to build and test it all when I get back. Cheers, Bob. On Mon, Jul 29, 2024, 15:42 B. Watson wrote: > > > On Mon, 29 Jul 2024, B. Watson wrote: > > > I've test-built everything on the list except nwg-shell (because it > > has 106 dependencies) and epiphany (waiting for webkit2gtk-4.1 to > > finish building, as I write this). > > Update: epiphany builds and runs fine. > _______________________________________________ > 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 Mon Jul 29 22:50:48 2024 From: urchlay at slackware.uk (B. Watson) Date: Mon, 29 Jul 2024 18:50:48 -0400 (EDT) Subject: [Slackbuilds-users] libhandy about to update to 1.8.3 In-Reply-To: References: <04d8c3-9f9a-581c-3e81-b91f6e1c1755@slackware.uk> Message-ID: On Mon, 29 Jul 2024, Bob Funk wrote: > > If the gnome stack of software is building then it'll probably be fine at runtime too. > > I am traveling currently and won't be back home till next Sunday so I won't be able to do much until after then. I'll be happy to build and test it all when I get back. Since you're the maintainer of most of the stack, I think I'll wait instead of pushing it in time for this week's update. I'd feel better about it, if it had your seal of approval. From j at lngn.net Mon Jul 29 22:54:14 2024 From: j at lngn.net (Jay Lanagan) Date: Mon, 29 Jul 2024 18:54:14 -0400 Subject: [Slackbuilds-users] libhandy about to update to 1.8.3 In-Reply-To: References: <04d8c3-9f9a-581c-3e81-b91f6e1c1755@slackware.uk> Message-ID: <105693CC-CC01-4231-8797-9CF86D7F8F16@edison.tech> @Bob Funk: I?ve just booted up the sbo gnome desktop and all is working well with updated libhandy over here. I don?t think the internal library has had a so version bump either so it?s expected that it should be compatible either way. Feels like a safe update to make from my point of view. All appears good. ? Jay Lanagan > > On Jul 29, 2024 at 6:36 PM, wrote: > > > > > If the gnome stack of software is building then it'll probably be fine at runtime too. > > > > I am traveling currently and won't be back home till next Sunday so I won't be able to do much until after then. I'll be happy to build and test it all when I get back. > > > > Cheers, > > > > Bob. > > > > > On Mon, Jul 29, 2024, 15:42 B. Watson wrote: > > > > > > > On Mon, 29 Jul 2024, B. Watson wrote: > > > > > I've test-built everything on the list except nwg-shell (because it > > > has 106 dependencies) and epiphany (waiting for webkit2gtk-4.1 to > > > finish building, as I write this). > > > > Update: epiphany builds and runs fine. > > _______________________________________________ > > SlackBuilds-users mailing list > > SlackBuilds-users at slackbuilds.org (mailto: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/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bobfunk11 at gmail.com Mon Jul 29 23:16:15 2024 From: bobfunk11 at gmail.com (Bob Funk) Date: Mon, 29 Jul 2024 17:16:15 -0600 Subject: [Slackbuilds-users] libhandy about to update to 1.8.3 In-Reply-To: <105693CC-CC01-4231-8797-9CF86D7F8F16@edison.tech> References: <04d8c3-9f9a-581c-3e81-b91f6e1c1755@slackware.uk> <105693CC-CC01-4231-8797-9CF86D7F8F16@edison.tech> Message-ID: I looked over the changes from libhandy 1.5.0 up to 1.8.0 and it's bug fixes, translation updates, and documentation switching to gi-docgen. Nothing major so no surprise if it works fine like Jay tested. Like I said, I'm not around my machines this week so if B Watson still wants to hold off till the following week's update that's fine by me too. Bob On Mon, Jul 29, 2024, 16:54 Jay Lanagan via SlackBuilds-users < slackbuilds-users at slackbuilds.org> wrote: > @Bob Funk: > > I?ve just booted up the sbo gnome desktop and all is working well with > updated libhandy over here. I don?t think the internal library has had a so > version bump either so it?s expected that it should be compatible either > way. > > Feels like a safe update to make from my point of view. All appears good. > > ? Jay Lanagan > > > On Jul 29, 2024 at 6:36 PM, > wrote: > > If the gnome stack of software is building then it'll probably be fine at > runtime too. > > I am traveling currently and won't be back home till next Sunday so I > won't be able to do much until after then. I'll be happy to build and test > it all when I get back. > > Cheers, > > Bob. > > On Mon, Jul 29, 2024, 15:42 B. Watson wrote: > >> >> >> On Mon, 29 Jul 2024, B. Watson wrote: >> >> > I've test-built everything on the list except nwg-shell (because it >> > has 106 dependencies) and epiphany (waiting for webkit2gtk-4.1 to >> > finish building, as I write this). >> >> Update: epiphany builds and runs fine. >> _______________________________________________ >> 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/ > > _______________________________________________ > 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 mm at dorfdsl.de Tue Jul 30 10:50:36 2024 From: mm at dorfdsl.de (Marco Moock) Date: Tue, 30 Jul 2024 12:50:36 +0200 Subject: [Slackbuilds-users] slackbuilds.org not accessible via IPv6 Message-ID: <1e2facf0-f161-c317-89e5-2decc10869eb@dorfdsl.de> Hello! I can't access SBo via IPv6, no answer, no ICMP. I assume it is an improperly configured firewall there. Can somebody of the admins please investigate? traceroute to slackbuilds.org (2604:5800:0:90::67), 30 hops max, 80 byte packets ?1? 2a01:170:118f:2::1 (2a01:170:118f:2::1)? 1.285 ms? 1.274 ms 1.425 ms ?2? 2a01:170:0:10::1 (2a01:170:0:10::1)? 9.169 ms? 9.184 ms? 9.127 ms ?3? dtag-fra.opencarrier.eu (2003:0:130e:9::1)? 9.165 ms? 9.253 ms * ?4? 2003:0:130e:20::2 (2003:0:130e:20::2)? 13.329 ms? 13.283 ms 13.225 ms ?5? ae12.cs1.fra6.de.eth.zayo.com (2001:438:ffff::407d:1aac) 125.623 ms? 125.525 ms? 125.582 ms ?6? * * * ?7? * * * ?8? * * * ?9? * * * 10? ae5.cs1.lhr11.uk.eth.zayo.com (2001:438:ffff::407d:1d7e) 124.810 ms *? 124.493 ms 11? * ae0.cs2.lga5.us.eth.zayo.com (2001:438:ffff::407d:1dbb) 127.478 ms * 12? * * * 13? ae21.mpr2.kcy4.us.zip.zayo.com (2001:438:ffff::407d:17df) 125.497 ms? 125.383 ms? 127.233 ms 14? ae3.mpr2.kcy1.us.zip.zayo.com (2001:438:ffff::407d:14b6) 128.279 ms? 126.953 ms? 128.066 ms 15? ae0.mpr1.kcy1.us.zip.zayo.com (2001:438:ffff::407d:1fbd) 128.029 ms? 136.566 ms? 136.430 ms 16? 2001:438:fffe::31ee (2001:438:fffe::31ee)? 136.657 ms? 136.550 ms? 137.449 ms 17? 2604:5800:1:c::2 (2604:5800:1:c::2)? 136.525 ms? 125.045 ms 123.741 ms 18? * * * No more reply here Same applies for ports 21 and 80. -- kind regards Marco From rworkman at slackbuilds.org Wed Jul 31 07:38:20 2024 From: rworkman at slackbuilds.org (Robby Workman) Date: Wed, 31 Jul 2024 02:38:20 -0500 Subject: [Slackbuilds-users] slackbuilds.org not accessible via IPv6 In-Reply-To: <1e2facf0-f161-c317-89e5-2decc10869eb@dorfdsl.de> References: <1e2facf0-f161-c317-89e5-2decc10869eb@dorfdsl.de> Message-ID: <20240731023820.4c65b001@home.rlworkman.net> On Tue, 30 Jul 2024 12:50:36 +0200 Marco Moock wrote: > Hello! > I can't access SBo via IPv6, no answer, no ICMP. I assume it is an > improperly configured firewall there. > > Can somebody of the admins please investigate? That is intentional. Unfortunately, we were hit by a large number of bots from various ipv6 addresses, each of which downloaded Slackware ISO images repeatedly, which caused us to go *way* over the transfer bandwidth allowed as part of our agreement with the colo host. We've got better things to do than play cat-and-mouse, especially when there's practically an infinite number of (cats|mice), and we certainly have better things on which we can spend the insane amounts of money that the game will cost us. -RW -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From mm at dorfdsl.de Wed Jul 31 07:53:54 2024 From: mm at dorfdsl.de (Marco Moock) Date: Wed, 31 Jul 2024 09:53:54 +0200 Subject: [Slackbuilds-users] slackbuilds.org not accessible via IPv6 In-Reply-To: <20240731023820.4c65b001@home.rlworkman.net> References: <1e2facf0-f161-c317-89e5-2decc10869eb@dorfdsl.de> <20240731023820.4c65b001@home.rlworkman.net> Message-ID: <20240731095354.7e4418f1@dorfdsl.de> Am Wed, 31 Jul 2024 02:38:20 -0500 schrieb Robby Workman : > That is intentional. So it is intentional to block all IPv6 traffic while still having the AAAA record, so users will try to connect to it and it should intentionally fail? Is that really the case? From rworkman at slackbuilds.org Wed Jul 31 08:07:49 2024 From: rworkman at slackbuilds.org (Robby Workman) Date: Wed, 31 Jul 2024 03:07:49 -0500 Subject: [Slackbuilds-users] slackbuilds.org not accessible via IPv6 In-Reply-To: <20240731095354.7e4418f1@dorfdsl.de> References: <1e2facf0-f161-c317-89e5-2decc10869eb@dorfdsl.de> <20240731023820.4c65b001@home.rlworkman.net> <20240731095354.7e4418f1@dorfdsl.de> Message-ID: <20240731030749.6348087b@home.rlworkman.net> On Wed, 31 Jul 2024 09:53:54 +0200 Marco Moock wrote: > Am Wed, 31 Jul 2024 02:38:20 -0500 > schrieb Robby Workman : > > > That is intentional. > > So it is intentional to block all IPv6 traffic while still having the > AAAA record, so users will try to connect to it and it should > intentionally fail? > > Is that really the case? What was intentional was to block the traffic. Please pardon the firehose blocking the street while we put out the fire. Sorry for the inconvenience it causes all of the vehicles. We'll either get the AAAA record removed or look into other solutions. -RW -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From mm at dorfdsl.de Wed Jul 31 08:25:14 2024 From: mm at dorfdsl.de (Marco Moock) Date: Wed, 31 Jul 2024 10:25:14 +0200 Subject: [Slackbuilds-users] slackbuilds.org not accessible via IPv6 In-Reply-To: <20240731030749.6348087b@home.rlworkman.net> References: <1e2facf0-f161-c317-89e5-2decc10869eb@dorfdsl.de> <20240731023820.4c65b001@home.rlworkman.net> <20240731095354.7e4418f1@dorfdsl.de> <20240731030749.6348087b@home.rlworkman.net> Message-ID: <20240731102514.0790dc9e@dorfdsl.de> Am Wed, 31 Jul 2024 03:07:49 -0500 schrieb Robby Workman : > We'll either get the AAAA record removed or look into other solutions. Thanks for the clarification. From rob0 at slackbuilds.org Wed Jul 31 19:02:00 2024 From: rob0 at slackbuilds.org (Rob McGee) Date: Wed, 31 Jul 2024 14:02:00 -0500 Subject: [Slackbuilds-users] slackbuilds.org not accessible via IPv6 In-Reply-To: <20240731102514.0790dc9e@dorfdsl.de> References: <1e2facf0-f161-c317-89e5-2decc10869eb@dorfdsl.de> <20240731023820.4c65b001@home.rlworkman.net> <20240731095354.7e4418f1@dorfdsl.de> <20240731030749.6348087b@home.rlworkman.net> <20240731102514.0790dc9e@dorfdsl.de> Message-ID: On 2024-07-31 03:25, Marco Moock wrote: > Am Wed, 31 Jul 2024 03:07:49 -0500 > schrieb Robby Workman : > >> We'll either get the AAAA record removed or look into other solutions. > > Thanks for the clarification. The AAAA records with the value of 2604:5800:0:90::67 have all been removed for the time being, while other remediations are under consideration. Cached records should all be gone by now (the two-hour TTL was expired a few minutes ago.) Removed: slackbuilds.org. 7200 IN AAAA 2604:5800:0:90::67 ftp.slackbuilds.org. 7200 IN AAAA 2604:5800:0:90::67 mirror.slackbuilds.org. 7200 IN AAAA 2604:5800:0:90::67 rsync.slackbuilds.org. 7200 IN AAAA 2604:5800:0:90::67 www.slackbuilds.org. 7200 IN AAAA 2604:5800:0:90::67