From willysr at slackbuilds.org Sat Mar 1 01:45:27 2025 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sat, 1 Mar 2025 08:45:27 +0700 Subject: [Slackbuilds-users] Updates - 20250301.1 Message-ID: <9061b30c-c5d6-4965-a3db-3760c98ec616@slackbuilds.org> Sat Mar 1 01:38:18 UTC 2025 academic/pari-elldata: Added (Pari/GP). academic/pari-galdata: Added (Pari Packages). academic/pari-galpol: Added (PARI packages). academic/pari-nflistdata: Added (Pari packages). academic/pari-seadata: Added (Pari Packages). academic/xsimd: Version bump to 13.2.0 academic/zotero: updated for version 7.0.13 audio/deadbeef: Updated for version 1.9.6 desktop/byzanz: Added (Simple Recording Tool). desktop/icewm: Updated for version 3.7.1. desktop/nwg-displays: Updated for version 0.3.23. desktop/nwg-shell: Updated for version 0.5.46. desktop/sun: Updated for version 2.0.0. development/STM32CubeIDE: Removed (use stm32cubeide). development/aws-cdk: Updated for version 2.1000.3. development/composer: Updated for version 2.8.6 development/diffoscope: updated for version 289 development/gerbil: Added (Gerbil Scheme). development/gnu-apl: Added (APL interpreter). development/golangci-lint: Updated for version 1.64.5. development/gopls: Updated for version 0.18.0. development/idea: Updated for version 2024.3.3. development/mongodb-shell: Updated for version 2.4.0. development/msbasic2ascii: Updated for version 0.2+20250222_db15677. development/pnpm: Updated for version 10.4.1. development/postman: Updated for version 11.33.4 development/qb64pe: Updated for version 4.1.0 development/rust-opt: Updated for version 1.85.0. development/stm32cubeide: Remove leftover from local build testing development/stm32cubeprog: Remove leftover from local build testing development/unicorn: Updated for version 2.1.2. games/ddnet: Updated for version 19.0 games/frotz: Fix build w/o modplug, fix xfrotz. games/nestopia: Updated for version 1.53.0 games/yamagi-quake2: Updated for version 8.41 graphics/embree: Updated for version 4.3.3. ham/qlog: Updated for version 0.42.1. ham/rtl_433: Updated for version 25.02. libraries/CLI11: Updated for version 2.5.0. libraries/docopt.cpp: Added (C++11 Parser). libraries/duktape: Added (portable ECMAScript). libraries/libzim: Added (reference implementation for ZIM). libraries/protobuf-c: Force rebuild. libraries/vmaf: Update script. misc/smu: Added (Markup Language). multimedia/HandBrake: Version bump to 1.9.2 network/AdGuardHome: Updated for version 0.107.57. network/asterisk: Updated for version 22.2.0. network/cinny-desktop: Updated for version 4.4.0. network/discord: Version bump to 0.0.87 network/dnsproxy-bin: Updated for version 0.75.0. network/exim: Updated for version 4.98.1. network/rclone: updated for version 1.69.1 network/signal-desktop:Update for version 7.44.0. network/vivaldi: Updated for version 7.1.3570.58. network/wireshark: Updated for version 4.4.5. network/yt-dlp-bin: Updated for version 2025.02.19. office/LibreOffice: Updated for version 25.2.1.2 office/MasterPDFEditor: Updated for version 5.9.87. office/ishmael: Updated for version 0.06. office/libreoffice-helppack: Updated for version 25.2.1. office/libreoffice-langpack: Updated for version 25.2.1. office/libreoffice: Updated for version 25.2.1. office/onlyoffice-desktopeditors: Updated for version 8.3.1 office/pandoc: updated for version 3.6.3 office/typobuster: Updated for version 0.1.5. perl/perl-Error: Updated for version 0.17030. python/python2-psutil: Update README. python/python3-aiohttp: Updated for version 3.11.13. python/python3-dep-logic: Version bump to 0.4.11 python/python3-evdev: Version bump to 1.9.1 python/python3-flit: Updated for version 3.11.0. python/python3-flit_core: Updated for version 3.11.0. python/python3-meson-opt: Updated for version 1.7.0. python/python3-mir_eval: Version bump to 0.8.2 python/python3-pdm-build-locked: Version bump to 0.3.5 python/python3-poetry-core: Updated for version 2.1.1. python/python3-psutil: Updated for version 7.0.0. python/python3-putio.py: Version bump to 8.8.0 python/python3-stevedore: Version bump to 5.4.1 python/python3-yarl: Updated for version 1.18.3. python/python3-zxcvbn: Updated for version 4.5.0. ruby/ruby-build: Updated for version 20250215. system/docker-buildx: Updated for versino 0.21.1. system/docker-compose: Updated for version 2.33.1 system/dracut: changed config file to support 32 bit Slackware system/dust: Updated for version 1.1.2. system/fastfetch: Updated for version 2.37.0. system/fio: Updated for version 3.39. system/fonts-gurmukhi-nonlibre: Added (Gurmukhi fonts). system/fonts-indic-nonlibre: Added (Indian fonts). system/fonts-tamil-nonlibre: Added (Tamil Fonts). system/fzf: Updated for version 0.60.2. system/mongodb: Updated for version 8.0.5. system/nvidia-driver: Updated for version 570.124.04. system/nvidia-kernel: Updated for version 570.124.04. system/openzfs: modified config args to support -current system/sbokeeper: Updated for version 2.05. system/slpkg: Updated for version 5.2.1. system/usermin: Fix build. system/xen: Updated for version 4.19.1. +--------------------------+ -- 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 fsleg at t-rg.ws Sun Mar 2 22:19:51 2025 From: fsleg at t-rg.ws (fsLeg) Date: Mon, 03 Mar 2025 01:19:51 +0300 Subject: [Slackbuilds-users] Request to take over popcorntime Message-ID: <32D87343-0467-426E-BF28-ED1882110021@t-rg.ws> Sometime mid-January I remembered that Popcorn-Time used to exist. Curious, I checked SBo, and apparently there was a script for it. Unfortunately, due to the nature of the program, the upstream has been long dead and the program no longer works. As I was composing an email to propose the script's removal, my wording prompted me to see if any forks were still alive. And I found one. So instead of a removal request I instead wrote to the SlackBuild's maintainer asking to update his script to use a working fork. That was back on January 18 and I never got a reply. I checked the maintainer's activity, and he only made two contributions: one in 2015 to add the SlackBuild and another one in 2017 to update its version. Today I spent the day writing a SlackBuild to replace the existing one. Popcorn-Time is a Node.js program, but instead of repackaging a pre-built binary or relying on internet connection I managed to build it from source completely offline by providing a tarball with vendored sources (similar to Rust scripts). It was a fun experience, and next weekend I plan to tweak the SlackBuild a bit more (I think it's possible to make it work on 32 bit systems). What I currently have is located on my github: Meanwhile, I'm requesting to take over multimedia/popcorntime. From urchlay at slackware.uk Mon Mar 3 09:35:04 2025 From: urchlay at slackware.uk (B. Watson) Date: Mon, 3 Mar 2025 04:35:04 -0500 (EST) Subject: [Slackbuilds-users] Request to take over popcorntime In-Reply-To: <32D87343-0467-426E-BF28-ED1882110021@t-rg.ws> References: <32D87343-0467-426E-BF28-ED1882110021@t-rg.ws> Message-ID: <2f82fd5-4a27-a995-5820-ecc4d01fbb87@slackware.uk> On Mon, 3 Mar 2025, fsLeg wrote: > As I was composing an email to propose the script's removal, my > wording prompted me to see if any forks were still alive. And I > found one. So instead of a removal request I instead wrote to the > SlackBuild's maintainer asking to update his script to use a working > fork. That was back on January 18 and I never got a reply. I checked > the maintainer's activity, and he only made two contributions: one > in 2015 to add the SlackBuild and another one in 2017 to update its > version. Take popcorntime, it's yours. From antonioleal at yahoo.com Mon Mar 3 11:04:38 2025 From: antonioleal at yahoo.com (Antonio Leal) Date: Mon, 3 Mar 2025 11:04:38 +0000 Subject: [Slackbuilds-users] missing return email from SlackBuilds.org submission References: <80b40ae4-1b70-4b58-adda-7f9d73a3a044.ref@yahoo.com> Message-ID: <80b40ae4-1b70-4b58-adda-7f9d73a3a044@yahoo.com> Hi Probably this has been questioned already, but are the feedback emails working? I didn't got a reply mail after submitting. /Thank you, your SlackBuild archive was successfully uploaded and is pending approval. *An email has been sent to antonioleal at yahoo.com* Please check your spam folder and/or whitelist noreply at slackbuilds.org if necessary. You will be contacted by an admin if there is a problem approving your submission./ -------------- next part -------------- An HTML attachment was scrubbed... URL: From fsleg at t-rg.ws Mon Mar 3 11:27:32 2025 From: fsleg at t-rg.ws (fsLeg) Date: Mon, 03 Mar 2025 14:27:32 +0300 Subject: [Slackbuilds-users] missing return email from SlackBuilds.org submission In-Reply-To: <80b40ae4-1b70-4b58-adda-7f9d73a3a044@yahoo.com> References: <80b40ae4-1b70-4b58-adda-7f9d73a3a044.ref@yahoo.com> <80b40ae4-1b70-4b58-adda-7f9d73a3a044@yahoo.com> Message-ID: I was told you are only sent an email if something is wrong with your submission. In my experience if nothing is wrong then nothing is emailed. I am yet to receive a single email, although I haven't been a maintainer for long. You can track your submission: 1) first, in pending queue: 2) when the time comes (usually within one or two days) it moves to the CI pipeline: 3) if nothing is wrong, it ends up in the ready queue: Submissions in that queue are pushed to the site somewhere between Friday evening and Saturday morning, depending on where you are. On March 3, 2025 14:04:38 GMT+03:00, Antonio Leal via SlackBuilds-users wrote: >Hi > >Probably this has been questioned already, but are the feedback emails working? I didn't got a reply mail after submitting. > > >/Thank you, your SlackBuild archive was successfully uploaded and is pending approval. > >*An email has been sent to antonioleal at yahoo.com* > >Please check your spam folder and/or whitelist noreply at slackbuilds.org if necessary. >You will be contacted by an admin if there is a problem approving your submission./ From slackcoder at server.ky Mon Mar 3 14:30:09 2025 From: slackcoder at server.ky (Slack Coder) Date: Mon, 3 Mar 2025 09:30:09 -0500 Subject: [Slackbuilds-users] Checksum failing for missing packages In-Reply-To: <040f7e57-3cf5-4689-b221-9dc579aa2c0a@slackbuilds.org> References: <79dc87d2-6dfd-423c-bc1c-a79b24dfc25d@server.ky> <9459e199-7548-4d37-817f-a3169c5b1d5d@slackbuilds.org> <6b64c8c9-a0fb-45ee-91ae-ac6cf8f63989@slackbuilds.org> <8f209489-6177-4832-ab02-e578aa225cde@server.ky> <040f7e57-3cf5-4689-b221-9dc579aa2c0a@slackbuilds.org> Message-ID: > Yes, it should be consistent, but sometimes i deleted the script in > the database and filesystem before the public update with the > assumption that nobody checks CHECKSUMS.md5 everyday :) Hmm, this might be a chicken and egg problem.? I have forked sbotools version 2 for maintenance with the exception of adding GPG + (rsync) MD5 verification. From willysr at slackbuilds.org Mon Mar 3 14:55:57 2025 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Mon, 3 Mar 2025 21:55:57 +0700 Subject: [Slackbuilds-users] missing return email from SlackBuilds.org submission In-Reply-To: References: <80b40ae4-1b70-4b58-adda-7f9d73a3a044.ref@yahoo.com> <80b40ae4-1b70-4b58-adda-7f9d73a3a044@yahoo.com> Message-ID: > I was told you are only sent an email if something is wrong with your submission. In my experience if nothing is wrong then nothing is emailed. I am yet to receive a single email, although I haven't been a maintainer for long. > > You can track your submission: > 1) first, in pending queue: > 2) when the time comes (usually within one or two days) it moves to the CI pipeline: > 3) if nothing is wrong, it ends up in the ready queue: Submissions in that queue are pushed to the site somewhere between Friday evening and Saturday morning, depending on where you are. We are still having issue (no one to fix) with the email cert. So please use the above procedure for now -- 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 for_slackbuilds-users_mlist_2023-04-21 at lockywolf.net Tue Mar 4 06:29:30 2025 From: for_slackbuilds-users_mlist_2023-04-21 at lockywolf.net (Lockywolf) Date: Tue, 04 Mar 2025 14:29:30 +0800 Subject: [Slackbuilds-users] [RFC] a binary repack SlackBuild template. Message-ID: <87o6yhxq21.fsf@laptop.lockywolf.net> Dear SlackBuilds community, Increasingly, we have to write more and more binary repacks, as software is becoming harder and harder to build on the premises. While this is an unfortunate development, and the community members are encouraged to build software from the original sources to ensure transparency and flexibility, sometimes building a package as a repack is an unnecessary evil. This message has (attached) a proposed binary-repacking SlackBuild, which I would like to propose for an inclusion into the templates repository. Please comment and suggest how this template can be improved. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: -------------- next part -------------- #!/bin/bash # Please, name your build script ending with -bin. # Slackware build script for -bin # Copyright # All rights reserved. # # Redistribution and use of this script, with or without modification, is # permitted provided that the following conditions are met: # # 1. Redistributions of this script must retain the above copyright # notice, this list of conditions and the following disclaimer. # # THIS SOFTWARE IS PROVIDED BY THE AUTHOR "AS IS" AND ANY EXPRESS OR IMPLIED # WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF # MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO # EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, # SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, # PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; # OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, # WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR # OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF # ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. # |-----------------------------------------------------------------| # # REMOVE THIS ENTIRE BLOCK OF TEXT # # # Please, name your build script ending with -bin, even if your # hypothetical software ends with -bin by itself. So, a piece of # software originally called frobnicate-bin would have a script name # frobnicate-bin-bin. # # A license is required, and we strongly suggest you use the above # BSD/MIT style license. We DO NOT accept "Public Domain" scripts. # Public domain is not valid in some countries, and no license is # worse than a "bad" license in those countries. # # This template is not meant to be a 'cut and paste' script to # enable any random user to make a working package. While # we're certainly not discouraging use of this template, if # you haven't manually gone through each step of the process # without the build script (typically as a normal user, as this # will reveal problems that you won't see as root), then there's # a good chance that something important is missing from your # submission. # When using this template script, please remove as many of # these unnecessary comments as possible. Commented code is # a good thing, but if it's obvious, there's no need to comment it. # # AGAIN, REMOVE THE COMMENTS IF THEY ARE NOT NEEDED - DON'T JUST # DELETE THIS BLOCK OF TEXT WITHOUT BOTHERING TO READ WHAT'S IN IT. # # |-----------------------------------------------------------------| # cd $(dirname $0) ; CWD=$(pwd) PRGNAM=appname-bin # replace with name of program VERSION=${VERSION:-1.4.1} # replace with version of program BUILD=${BUILD:-1} TAG=${TAG:-_SBo} # the "_SBo" is required PKGTYPE=${PKGTYPE:-tgz} TARNAM=appname # Automatically determine the architecture we're building on: if [ -z "$ARCH" ]; then case "$( uname -m )" in i?86) ARCH=i586 ;; arm*) ARCH=arm ;; # Unless $ARCH is already set, use uname -m for all other archs: *) ARCH=$( uname -m ) ;; esac fi # If the variable PRINT_PACKAGE_NAME is set, then this script will report what # the name of the created package would be, and then exit. This information # could be useful to other scripts. if [ ! -z "${PRINT_PACKAGE_NAME}" ]; then echo "$PRGNAM-$VERSION-$ARCH-$BUILD$TAG.$PKGTYPE" exit 0 fi TMP=${TMP:-/tmp/SBo} # For consistency's sake, use this PKG=$TMP/package-$PRGNAM OUTPUT=${OUTPUT:-/tmp} # Drop the package in /tmp if [ "$ARCH" = "i586" ]; then LIBDIRSUFFIX="" UNSUP=1 elif [ "$ARCH" = "i686" ]; then LIBDIRSUFFIX="" UNSUP=1 elif [ "$ARCH" = "x86_64" ]; then LIBDIRSUFFIX="64" elif [ "$ARCH" = "aarch64" ]; then LIBDIRSUFFIX="64" UNSUP=1 else LIBDIRSUFFIX="" UNSUP=1 fi if [[ "$UNSUP" == 1 ]] ; then printf "Unsupported architecture: unknown.\n" 1>&2 fi # If your package is actually "noarch", uncomment the following line. #ARCH=noarch set -e # Exit on most errors # If you prefer to do selective error checking with # command || exit 1 # then that's also acceptable. rm -rf $PKG mkdir -p $TMP $PKG $OUTPUT cd $TMP rm -rf $TARNAM-$VERSION tar xvf $CWD/$TARNAM-$VERSION-$ARCH.tar.gz cd $TARNAM-$VERSION chown -R root:root . find -L . \ \( -perm 777 -o -perm 775 -o -perm 750 -o -perm 711 -o -perm 555 \ -o -perm 511 \) -exec chmod 755 {} + -o \ \( -perm 666 -o -perm 664 -o -perm 640 -o -perm 600 -o -perm 444 \ -o -perm 440 -o -perm 400 \) -exec chmod 644 {} + # Unpack the archive to /opt/ install -d -m755 $PKG/opt mv ${TARNAM}-${VERSION}-${ARCH} $PKG/opt # Make a binary softlink. You might want to make a shell script instead, # see your own particular use-case. # You especially might want to do it if you need to UNSET some environment # variable. Java is particularly prone to this, many binary repacks # have to unset _JAVA_OPTIONS mkdir -p "$PKG"/usr/bin ( cd $PKG/usr/bin ln -sr ../../opt/${TARNAM}-${VERSION}-${ARCH}/${PRGNAM} ./ ) PKGOPT=$PKG/opt/${TARNAM}-${VERSION}-${ARCH} # You may have to install something into /usr/lib$LIBDIRSUFFIX , it is hard to # guess. See for yourself. Browser plugins, cmake or pkg-config scripts. # install -Dm644 $PKGOPT/plugins/ $PKG/usr/lib$LIBDIRSUFFIX/mozilla/plugins # Install desktop file install -Dm644 $PKGOPT/$TARNAM.desktop \ $PKG/usr/share/applications/$TARNAM.desktop # Install icons install -Dm644 $PKGOPT/images/$TARNAM.svg \ $PKG/usr/share/icons/hicolor/scalable/$TARNAM.svg install -Dm644 $PKGOPT/images/$TARNAM.svg \ $PKG/usr/share/pixmaps/$TARNAM.svg # Copy program documentation into the package # The included documentation varies from one application to another, so be sure # to adjust your script as needed # Also, include the SlackBuild script in the documentation directory mkdir -p $PKG/usr/doc/$PRGNAM-$VERSION cp -a \ \ $PKG/usr/doc/$PRGNAM-$VERSION cat $CWD/$PRGNAM.SlackBuild > $PKG/usr/doc/$PRGNAM-$VERSION/$PRGNAM.SlackBuild # Copy the slack-desc (and a custom doinst.sh if necessary) into ./install mkdir -p $PKG/install cat $CWD/slack-desc > $PKG/install/slack-desc cat $CWD/doinst.sh > $PKG/install/doinst.sh # Final sanity check. if [[ "${PRGNAM: -4}" != "-bin" ]] ; then printf "Fatal Error: PRGNAM must end in '-bin', but now ends with %s\n" \ "${PRGNAM: -4}" exit 2 fi # Make the package; be sure to leave it in $OUTPUT # If package symlinks need to be created during install *before* # your custom contents of doinst.sh runs, then add the -p switch to # the makepkg command below -- see makepkg(8) for details cd $PKG /sbin/makepkg -l y -c n $OUTPUT/$PRGNAM-$VERSION-$ARCH-$BUILD$TAG.$PKGTYPE -------------- next part -------------- -- Your sincerely, Vladimir Nikishkin (MiEr, lockywolf) (Laptop) From fsleg at t-rg.ws Tue Mar 4 07:42:11 2025 From: fsleg at t-rg.ws (fsLeg) Date: Tue, 04 Mar 2025 10:42:11 +0300 Subject: [Slackbuilds-users] [RFC] a binary repack SlackBuild template. In-Reply-To: <87o6yhxq21.fsf@laptop.lockywolf.net> References: <87o6yhxq21.fsf@laptop.lockywolf.net> Message-ID: <1E7E6624-91AF-4529-870C-D5CF6650F552@t-rg.ws> Interesting proposition. It definitely raises a few questions. First, what about repackaging software from Debian-like packages? That's done a lot, and details vary from your SlackBuild, like, binaries usually go to /usr instead of /opt. Second, speaking of /opt. I put pre-built things in /usr if it's the upstream practice, which it usually is. However, in my recently adopted popcorntime SlackBuild the upstream practice is to put the binaries in /opt, even if built manually or packaged, although I've seen someone on AUR putting those binaries into /usr/share instead. Should we follow the upstream? Should we formulate our own best practices? Basically, where do we put binaries and when? Third, does a repackaged package actually need to be named *-bin? Even if the only available SlackBuild only repackages the pre-built binaries. If so, then I might need to rename a script or two. Fourth, steps for repackaging pre-built binaries don't vary much from building from source, minus the building part. With some toolchains you have to move things around manually anyway, so it's not so much about a template as guidelines where to put things. What I think is needed is not just a template but a sort of an accompanying README about how to build packages that use different toolchains. Or just thoroughly document each step inside a SlackBuild, explaining why something is done a certain way, what to do and what to keep in mind if something doesn't apply to a particular piece of software. On March 4, 2025 09:29:30 GMT+03:00, Lockywolf wrote: >Dear SlackBuilds community, > >Increasingly, we have to write more and more binary repacks, >as software is becoming harder and harder to build on the premises. > >While this is an unfortunate development, and the community members >are encouraged to build software from the original sources to ensure >transparency and flexibility, sometimes building a package as a >repack is an unnecessary evil. > >This message has (attached) a proposed binary-repacking SlackBuild, >which I would like to propose for an inclusion into the templates >repository. > >Please comment and suggest how this template can be improved. > From rizitis at gmail.com Tue Mar 4 08:12:10 2025 From: rizitis at gmail.com (=?UTF-8?B?zpnPic6szr3Ovc63z4I=?=) Date: Tue, 4 Mar 2025 10:12:10 +0200 Subject: [Slackbuilds-users] [RFC] a binary repack SlackBuild template. In-Reply-To: <1E7E6624-91AF-4529-870C-D5CF6650F552@t-rg.ws> References: <87o6yhxq21.fsf@laptop.lockywolf.net> <1E7E6624-91AF-4529-870C-D5CF6650F552@t-rg.ws> Message-ID: Personally I use some scripts for local builds that support various compress types. I tried edit repack-template.SlackBuild to add some options maybe you find something useful for the final repack-template.SlackBuild. thanks ???? ??? 4 ??? 2025 ???? 9:42??.?., ?/? fsLeg ??????: > Interesting proposition. It definitely raises a few questions. > > First, what about repackaging software from Debian-like packages? That's > done a lot, and details vary from your SlackBuild, like, binaries usually > go to /usr instead of /opt. > > Second, speaking of /opt. I put pre-built things in /usr if it's the > upstream practice, which it usually is. However, in my recently adopted > popcorntime SlackBuild the upstream practice is to put the binaries in > /opt, even if built manually or packaged, although I've seen someone on AUR > putting those binaries into /usr/share instead. Should we follow the > upstream? Should we formulate our own best practices? Basically, where do > we put binaries and when? > > Third, does a repackaged package actually need to be named *-bin? Even if > the only available SlackBuild only repackages the pre-built binaries. If > so, then I might need to rename a script or two. > > Fourth, steps for repackaging pre-built binaries don't vary much from > building from source, minus the building part. With some toolchains you > have to move things around manually anyway, so it's not so much about a > template as guidelines where to put things. > > What I think is needed is not just a template but a sort of an > accompanying README about how to build packages that use different > toolchains. Or just thoroughly document each step inside a SlackBuild, > explaining why something is done a certain way, what to do and what to keep > in mind if something doesn't apply to a particular piece of software. > > On March 4, 2025 09:29:30 GMT+03:00, Lockywolf < > for_slackbuilds-users_mlist_2023-04-21 at lockywolf.net> wrote: > >Dear SlackBuilds community, > > > >Increasingly, we have to write more and more binary repacks, > >as software is becoming harder and harder to build on the premises. > > > >While this is an unfortunate development, and the community members > >are encouraged to build software from the original sources to ensure > >transparency and flexibility, sometimes building a package as a > >repack is an unnecessary evil. > > > >This message has (attached) a proposed binary-repacking SlackBuild, > >which I would like to propose for an inclusion into the templates > >repository. > > > >Please comment and suggest how this template can be improved. > > > _______________________________________________ > 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: repack-template.SlackBuild Type: application/octet-stream Size: 9831 bytes Desc: not available URL: From jebrhansen+SBo at gmail.com Tue Mar 4 08:15:53 2025 From: jebrhansen+SBo at gmail.com (Jeremy Hansen) Date: Tue, 4 Mar 2025 00:15:53 -0800 Subject: [Slackbuilds-users] [RFC] a binary repack SlackBuild template. In-Reply-To: <87o6yhxq21.fsf@laptop.lockywolf.net> References: <87o6yhxq21.fsf@laptop.lockywolf.net> Message-ID: On Mon, Mar 3, 2025, 10:34?PM Lockywolf < for_slackbuilds-users_mlist_2023-04-21 at lockywolf.net> wrote: > Dear SlackBuilds community, > > Increasingly, we have to write more and more binary repacks, > as software is becoming harder and harder to build on the premises. > > While this is an unfortunate development, and the community members > are encouraged to build software from the original sources to ensure > transparency and flexibility, sometimes building a package as a > repack is an unnecessary evil. > > This message has (attached) a proposed binary-repacking SlackBuild, > which I would like to propose for an inclusion into the templates > repository. > > Please comment and suggest how this template can be improved. > Looking over my SlackBuilds that package repackd binaries, I feel a template is unlikely you capture the many nuances required in a repack. Some are able to reside in /usr/ (discord), while others are better contained in /opt/ (SweetHome3D, blender). Some may include .desktop files while others will require creating and/or modifying them. Basically, looking at your existing template, there is very little that would work on the repacks I package. On my sbgen.sh script?, I just simply have an essentially "do you own thing" template for situations like repacks where existing templates don't work. It simply doesn't contain a compilation section and provides a comment for maintainers to add their own commands. These scripts seem to require a lot of manual really that is likely hard to capture on a single template. But maybe I just don't repackage enough software to realize there is a solid template that applies to most rather than many requiring their own unique commands... Jeremy ?https://github.com/bassmadrigal/scripts/blob/master/sbgen.sh > -------------- next part -------------- An HTML attachment was scrubbed... URL: From urchlay at slackware.uk Tue Mar 4 08:19:11 2025 From: urchlay at slackware.uk (B. Watson) Date: Tue, 4 Mar 2025 03:19:11 -0500 (EST) Subject: [Slackbuilds-users] [RFC] a binary repack SlackBuild template. In-Reply-To: <1E7E6624-91AF-4529-870C-D5CF6650F552@t-rg.ws> References: <87o6yhxq21.fsf@laptop.lockywolf.net> <1E7E6624-91AF-4529-870C-D5CF6650F552@t-rg.ws> Message-ID: <61f8481-fc48-511b-4d9-68fbcb4c7c81@slackware.uk> On Tue, 4 Mar 2025, fsLeg wrote: > Third, does a repackaged package actually need to be named *-bin? Even if the only available SlackBuild only repackages the pre-built binaries. If so, then I might need to rename a script or two. Yes. Two reasons for this: 1. We don't want another mess like "libreoffice" and "LibreOffice". Can you remember which is the binary repack, without looking it up? 2. Naming it "whatever-bin" leaves the name "whatever" free for someone else to create a "whatever" script that builds from source. You don't have to rename your existing scripts. I hope you do, but nobody's going to try to make you do it. From fsleg at t-rg.ws Tue Mar 4 08:33:14 2025 From: fsleg at t-rg.ws (fsLeg) Date: Tue, 04 Mar 2025 11:33:14 +0300 Subject: [Slackbuilds-users] [RFC] a binary repack SlackBuild template. In-Reply-To: <61f8481-fc48-511b-4d9-68fbcb4c7c81@slackware.uk> References: <87o6yhxq21.fsf@laptop.lockywolf.net> <1E7E6624-91AF-4529-870C-D5CF6650F552@t-rg.ws> <61f8481-fc48-511b-4d9-68fbcb4c7c81@slackware.uk> Message-ID: <3EB3331C-B0C2-45C0-A040-A2C820B623A5@t-rg.ws> I don't mind renaming my scripts. One almost definitely needs renaming, a couple more are in the air because of the following. What about proprietary software? It's only distributed as pre-built binaries (like mentioned discord, also saflashplayer). Do such packages need to be named *-bin? What about software that is impossible to build in SBo-compatible way? Like, flutter (or maybe entire dart, I don't remember anymore) just plain refuses to run as root, so flutter-based programs (yubioath-desktop) have to be repackaged from binaries. Do such packages need to be named *-bin? On March 4, 2025 11:19:11 GMT+03:00, "B. Watson" wrote: > >You don't have to rename your existing scripts. I hope you do, but >nobody's going to try to make you do it. From urchlay at slackware.uk Tue Mar 4 08:54:50 2025 From: urchlay at slackware.uk (B. Watson) Date: Tue, 4 Mar 2025 03:54:50 -0500 (EST) Subject: [Slackbuilds-users] [RFC] a binary repack SlackBuild template. In-Reply-To: <3EB3331C-B0C2-45C0-A040-A2C820B623A5@t-rg.ws> References: <87o6yhxq21.fsf@laptop.lockywolf.net> <1E7E6624-91AF-4529-870C-D5CF6650F552@t-rg.ws> <61f8481-fc48-511b-4d9-68fbcb4c7c81@slackware.uk> <3EB3331C-B0C2-45C0-A040-A2C820B623A5@t-rg.ws> Message-ID: <93eda2f4-fd27-75f9-6fc7-1473a07c6e6b@slackware.uk> On Tue, 4 Mar 2025, fsLeg wrote: > I don't mind renaming my scripts. One almost definitely needs renaming, a couple more are in the air because of the following. > > What about proprietary software? It's only distributed as pre-built binaries (like mentioned discord, also saflashplayer). Do such packages need to be named *-bin? Good question. I might not bother with the -bin in that case. > What about software that is impossible to build in SBo-compatible way? Like, flutter (or maybe entire dart, I don't remember anymore) just plain refuses to run as root, so flutter-based programs (yubioath-desktop) have to be repackaged from binaries. Do such packages need to be named *-bin? Not familiar with flutter. However... if it really refuses to run as root, the SlackBuild could do something like: su - nobody -s /bin/sh -c flutter This would run flutter as the nobody used. You'd have to chown the sources to nobody first, and chown the binaries afterward, or install with "install -oroot -groot ..." That, or whoever packages flutter could patch out the code that detects when it's run by root. YMMV on whether that's a good idea, I literally never heard of flutter until just now. If any of the above actually works, then there could be a yubioath-desktop that builds from source, and the existing one could be renamed to yubioath-desktop-bin (or removed, if it's no longer needed). From list+sbo at vahedi.org Tue Mar 4 13:32:42 2025 From: list+sbo at vahedi.org (Shahab Vahedi) Date: Tue, 04 Mar 2025 13:32:42 +0000 Subject: [Slackbuilds-users] fzf 0.6.20 build fails on Slackware64-15.0 Message-ID: <1353b1bce6e1791c40c0b40c39372d0b67319f1e@vahedi.org> # sbopkg -Ri fzf ... Processing fzf fzf: Found fzf-0.60.2.tar.gz in /var/cache/sbopkg. Checking MD5SUM: MD5SUM check for fzf-0.60.2.tar.gz ... OK ... Building package for fzf... fzf-0.60.2/ ... fzf-0.60.2/uninstall fatal: not a git repository (or any parent up to mount point /) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). GOARCH=amd64 go build -a -ldflags "-s -w -X main.version=0.60.2 -X main.revision=Slackware" -tags "" -trimpath -mod=vendor -o target/fzf-linux_amd64 src/reader.go:15:2: //go:build comment without // +build comment main.go:10:2: //go:build comment without // +build comment main.go:11:2: //go:build comment without // +build comment src/ansi.go:9:2: //go:build comment without // +build comment src/algo/algo.go:88:2: //go:build comment without // +build comment src/util/util.go:11:2: //go:build comment without // +build comment vendor/github.com/mattn/go-isatty/isatty_tcgets.go:8:8: //go:build comment without // +build comment src/tui/light.go:17:2: //go:build comment without // +build comment make: *** [Makefile:150: target/fzf-linux_amd64] Error 1 From matteo.bernardini at gmail.com Tue Mar 4 15:18:18 2025 From: matteo.bernardini at gmail.com (Matteo Bernardini) Date: Tue, 4 Mar 2025 16:18:18 +0100 Subject: [Slackbuilds-users] fzf 0.6.20 build fails on Slackware64-15.0 In-Reply-To: <1353b1bce6e1791c40c0b40c39372d0b67319f1e@vahedi.org> References: <1353b1bce6e1791c40c0b40c39372d0b67319f1e@vahedi.org> Message-ID: hi Shahab, that happens because the build system is using gcc's go, not the go compiler from google-go-lang. this could happen usually in a couple of cases: - you haven't installed the fzf build dependency google-go-lang; - after installing google-go-lang you haven't logout and logged in again into your root session or switched again to root with "su -" (note the trailing dash) so that the /etc/profile.d/go.sh script is sourced in your environment: it's explained in google-go-lang's README on SBo. Matteo Il giorno mar 4 mar 2025 alle ore 14:32 Shahab Vahedi via SlackBuilds-users ha scritto: > # sbopkg -Ri fzf > > ... > Processing fzf > > fzf: > Found fzf-0.60.2.tar.gz in /var/cache/sbopkg. > Checking MD5SUM: > MD5SUM check for fzf-0.60.2.tar.gz ... OK > ... > Building package for fzf... > fzf-0.60.2/ > ... > fzf-0.60.2/uninstall > fatal: not a git repository (or any parent up to mount point /) > Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). > GOARCH=amd64 go build -a -ldflags "-s -w -X main.version=0.60.2 -X > main.revision=Slackware" -tags "" -trimpath -mod=vendor -o > target/fzf-linux_amd64 > src/reader.go:15:2: //go:build comment without // +build comment > main.go:10:2: //go:build comment without // +build comment > main.go:11:2: //go:build comment without // +build comment > src/ansi.go:9:2: //go:build comment without // +build comment > src/algo/algo.go:88:2: //go:build comment without // +build comment > src/util/util.go:11:2: //go:build comment without // +build comment > vendor/github.com/mattn/go-isatty/isatty_tcgets.go:8:8: //go:build > comment without // +build comment > src/tui/light.go:17:2: //go:build comment without // +build comment > make: *** [Makefile:150: target/fzf-linux_amd64] Error 1 > _______________________________________________ > 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 list+sbo at vahedi.org Tue Mar 4 17:32:23 2025 From: list+sbo at vahedi.org (Shahab Vahedi) Date: Tue, 04 Mar 2025 17:32:23 +0000 Subject: [Slackbuilds-users] fzf 0.6.20 build fails on Slackware64-15.0 In-Reply-To: References: <1353b1bce6e1791c40c0b40c39372d0b67319f1e@vahedi.org> Message-ID: <620f12d11747a504350f88e6b902929d74118e38@vahedi.org> Hi Matteo, On March 4, 2025, "Matteo Bernardini" wrote: > that happens because the build system is using gcc's go, not the go > compiler from google-go-lang. > ... > > into your root session or switched again to root with "su -" (note the > trailing dash) so that the /etc/profile.d/go.sh script is sourced in your > environment: it's explained in google-go-lang's README on SBo. You are absolutely right, I needed the "su -" part after just freshly installing "google-go-lang". I thought I covered it when I did ". /etc/profile.d/go.sh" followed by a "doas sh fzf.SlackBuild". Apparently, that was useless. Cheers, Shahab From phalange at komputermatrix.com Wed Mar 5 15:13:02 2025 From: phalange at komputermatrix.com (phalange at komputermatrix.com) Date: Wed, 05 Mar 2025 10:13:02 -0500 Subject: [Slackbuilds-users] [RFC] a binary repack SlackBuild template. In-Reply-To: <87o6yhxq21.fsf@laptop.lockywolf.net> References: <87o6yhxq21.fsf@laptop.lockywolf.net> Message-ID: <25abff16444c7dde864be8fb14d37a12@komputermatrix.com> On 2025-03-04 01:29, Lockywolf wrote: > Dear SlackBuilds community, > > Increasingly, we have to write more and more binary repacks, > as software is becoming harder and harder to build on the premises. > > While this is an unfortunate development, and the community members > are encouraged to build software from the original sources to ensure > transparency and flexibility, sometimes building a package as a > repack is an unnecessary evil. > > This message has (attached) a proposed binary-repacking SlackBuild, > which I would like to propose for an inclusion into the templates > repository. > > Please comment and suggest how this template can be improved. > > > > > _______________________________________________ > 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/ I'll pass on the template. Also binaries have important use cases. For example I package pandoc-bin because I (and probably many others) can't be bothered to build all 10 million Haskell dependencies for one app. I'm open to *-bin on binaries, but for the few users who care enough to fuss over the difference, I bet they're building their own. FreeBSD does ports and pkgs. That's another solution but a lot of overhead. From urchlay at slackware.uk Wed Mar 5 20:30:34 2025 From: urchlay at slackware.uk (B. Watson) Date: Wed, 5 Mar 2025 15:30:34 -0500 (EST) Subject: [Slackbuilds-users] [RFC] a binary repack SlackBuild template. In-Reply-To: <25abff16444c7dde864be8fb14d37a12@komputermatrix.com> References: <87o6yhxq21.fsf@laptop.lockywolf.net> <25abff16444c7dde864be8fb14d37a12@komputermatrix.com> Message-ID: <5ca6b87c-a78-1e5d-811b-f68b6034728@slackware.uk> On Wed, 5 Mar 2025, phalange at komputermatrix.com wrote: > Also binaries have important use cases. For example I package pandoc-bin > because I (and probably many others) can't be bothered to build all 10 > million Haskell dependencies for one app. Yes, and *thank you* for pandoc-bin. I have several builds that use pandoc to generate a man page... the man page might be 1 or 2 KB, and it seems ludicrous to have pandoc as a dependency. It actually has 196 dependencies, which might as well be 10 million. Most of the time, what I do is install pandoc-bin on my dev box, generate the man page, then include the man page in the SlackBuild so there's no dependency even on pandoc-bin. > FreeBSD does ports and pkgs. That's another solution but a lot of overhead. IIRC, a FreeBSD port is a build from source, and a pkg as a prebuilt port? SBo has never provided prebuilt packages, and that's unlikely to ever change. From willysr at slackbuilds.org Sat Mar 8 00:39:15 2025 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sat, 8 Mar 2025 07:39:15 +0700 Subject: [Slackbuilds-users] protobuf3: 30.0 Message-ID: <98f2ec70-fc08-432c-ab3b-2221f16a2174@slackbuilds.org> Hi, protobuf3: 30.0 introduced incompatible changes and it breaks some scripts. I have a PR here https://github.com/SlackBuildsOrg/slackbuilds/pull/10020 and as you can see, it shows scripts that didn't build properly with new protobuf3. I will track them on separate issue: https://github.com/SlackBuildsOrg/slackbuilds/issues/10021 If you are a maintainer of those affected scripts, you can help by testing with new protobuf3 and send PR to fix this thank you -- 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 Sat Mar 8 00:54:13 2025 From: urchlay at slackware.uk (B. Watson) Date: Fri, 7 Mar 2025 19:54:13 -0500 (EST) Subject: [Slackbuilds-users] [Slackbuilds-devel] TLP package (fwd) Message-ID: Aaditya, this is for you: ---------- Forwarded message ---------- Date: Fri, 07 Mar 2025 14:45:28 -0300 From: kind.note8582 at fastmail.com Reply-To: SBo Admin List To: SBo Admin List Subject: [Slackbuilds-devel] TLP package Hi, ? I tried to contact the maintainer about the TLP new version, the last Feb.14, no reply... ? Can I grab this package? I already have TLP version 1.8.0 running. Cheers, Ricardson -------------- next part -------------- _______________________________________________ Slackbuilds-devel mailing list Slackbuilds-devel at slackbuilds.org https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-devel From willysr at slackbuilds.org Sat Mar 8 04:32:38 2025 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sat, 8 Mar 2025 11:32:38 +0700 Subject: [Slackbuilds-users] Updates - 20250308.1 Message-ID: <8e8bdd65-658b-4c0e-92ae-f6d8463db9bc@slackbuilds.org> Sat Mar 8 04:26:49 UTC 2025 academic/R: updated for version 4.4.3 academic/pari-elldata: Update script. academic/pari-galdata: Update script. academic/pari-galpol: Update script. academic/pari-nflistdata: Update script. academic/pari-seadata: Update script. desktop/ClamAV-GUI: Updated for version 1.0.8 desktop/sun: Updated for version 2.0.1. development/Archi: Updated for version 5.5.0. development/a68g: Added (Algol 68 interpreter). development/android-studio: Updated for version 2024.2.2.15. development/aws-cdk: Updated for version 2.1001.0. development/aws-cdk: Updated for version 2.1003.0. development/cargo-vendor-filterer: Fix included script. development/config-file-validator: Added (Syntax Validation). development/dart-sass: Updated for version 1.85.1. development/github-cli: Updated for version 2.68.1. development/hugo: updated for version 0.145.0 development/mold: Updated for version 2.37.0. development/obsidian: updated for version 1.8.9 development/postman: Updated for version 11.35.0 development/radare2: Updated for version 5.9.8. development/sbcl: Updated for version 2.5.2. development/sbt: Updated for version 1.10.10 development/sourcegit: Added (GUI Client for GIT). development/terraform: Updated for version 1.11.0 development/vscode-bin: Updated for version 1.98.0. development/vstudio: Updated for version 15.1. games/lincity-ng: Updated for version 2.13.1. games/mame: Updated for version 0.275. gis/gpxsee: Updated for version 13.36. gis/proj-data: Updated for version 1.20. gis/proj: Updated for version 9.5.1. gis/python3-pyproj: Updated for version 3.7.1. gis/python3-shapely: Updated for version 2.0.7. gis/python3-xarray: Updated for version 2025.01.2, graphics/kgeotag: Added (standalone geotagging program). graphics/vuescan: Updated for version 9.8.45. ham/qlog: Updated for version 0.42.2. ham/redsea: Updated for version 1.1.1. ham/soapy-remote: Added (Remote Control for Soapy SDR). ham/soapy-sdr: Added (Soapy SDR). libraries/FreeImage: Fix building on current. libraries/Mustache: Added (Mustache templates for C++). libraries/goffice: Updated for version 0.10.59. libraries/gtk-fortran: Added (Bindings for Fortran). libraries/libkiwix: Added (Library to manipulate ZIM format). libraries/libxml++5: Added (C++ API). libraries/sfml: Added (Multimedia Library). libraries/tree-sitter: Updated for version 0.25.3 libraries/vst3sdk: Updated for version 3.7.13 misc/bitwarden-desktop: updated for version 2025.2.1 multimedia/filebot: Version bump to 5.1.7 multimedia/w_scan_cpp: Updated vdr source. multimedia/youtube-music: Updated for version 3.7.5. network/brave-browser: updated for version 1.76.73 network/cinny-desktop: Updated for version 4.5.1. network/dropbox: Updated for version 219.4.4463. network/dstp: Added (Network Tools). network/floorp-bin: Updated for version 11.24.0, new maintainer. network/gallery-dl: Updated for version 1.29.0. network/kubectl: Updated for version 1.32.2. network/s: Added (Web Search from Terminal). network/signal-desktop: Update for version 7.45.1. network/tailscale: updated for version 1.80.3 network/tor-browser: Updated for version 14.0.7. network/waterfox: Added (Web Browser). network/whalebird: Updated for version 6.2.1 network/yle-dl: Updated for version 20250227. network/yt-dlp: Updated for version 2025.02.19. network/zoom-linux: Updated for 6.3.11.7212 office/epub2txt2: Added (Extract from EPUB). office/glow: Updated for version 2.1.0. office/gnumeric: Updated for version 1.12.59. office/ishmael: Updated for version 1.00. office/keepassxc: Updated for version 2.7.10. office/kiwix-desktop: Added (Kiwix Desktop Application). office/wps-office-dicts: Updated for version 25.2.1.2 perl/perl-Date-Manip: Updated for version 6.97. python/cryptography: Updated for version 44.0.2. python/python3-aiohappyeyeballs: Updated for version 2.5.0. python/python3-ffmpeg: Added (FFmpeg wrapper for Python). python/python3-pytest: Version bump to 8.3.5 python/python3-virtualenv: Version bump to 20.29.3 system/B-em: Updated for version 20250303_920605b. system/CNS11643-kai-font: Updated for version 20250113. system/CNS11643-sung-font: Updated for version 20250113. system/Iosevka-aile: Updated for version 33.0.1. system/Iosevka-etoile: Updated for version 33.0.1. system/Iosevka-slab: Updated for version 33.0.1 system/Iosevka: Updated for version 33.0.1 system/Microsoft-Fonts: Added (Microsoft Fonts). system/acpi: Updated for version 1.8. system/borgmatic: Updated for version 1.9.13 system/brave-browser-the-latest: Added (Brave Browser). system/c-lcrypt: Added (LCrypt on C++). system/docker-buildx: Updated for version 0.21.2. system/duperemove: Updated for version 0.15.1. system/fnt: Updated for version 1.9. system/incus: Updated for version 6.10.1 system/jenkins: Updated for version 2.492.2. system/kiwix-tools: Added (Command Line Kiwix Tools). system/logwatch: Updated for version 7.12. system/mongodb: Fix swapped MD5SUM. system/prometheus: Updated for version 3.2.1 system/sarasa-gothic: Updated for version 1.0.29. system/sbctl: Added (Secure Boot Manager). system/sbokeeper: Updated for version 2.06. system/slackrepo-hints: Updated for version 20250308. system/slackrepo: Updated for version 20250308. system/squashfuse: Updated for version 0.6.0. system/telegraf: Updated for version 1.33.3 system/usermin: Updated for version 2.202. system/vifm: Updated for version 0.14. system/webmin: Updated for version 2.302. system/xosview: Added (System Monitor). system/zim-tools: Added (Command Line Tools for ZIM files). +--------------------------+ -- 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 aaditya_gnulinux at zoho.com Sat Mar 8 16:43:15 2025 From: aaditya_gnulinux at zoho.com (Aditya) Date: Sat, 8 Mar 2025 22:13:15 +0530 Subject: [Slackbuilds-users] [Slackbuilds-devel] TLP package (fwd) In-Reply-To: References: Message-ID: <4e33c40a-fce4-43d0-8f46-9f2609dcda3b@zoho.com> Thanks, I missed this. Ricardson, feel free to take over maintenance for TLP. -- Kind Regards, Aditya On 08-03-2025 06:24, B. Watson wrote: > > Aaditya, this is for you: > > ---------- Forwarded message ---------- > Date: Fri, 07 Mar 2025 14:45:28 -0300 > From: kind.note8582 at fastmail.com > Reply-To: SBo Admin List > To: SBo Admin List > Subject: [Slackbuilds-devel] TLP package > > Hi, > > ? I tried to contact the maintainer about the TLP new version, the > last Feb.14, no reply... > ? Can I grab this package? I already have TLP version 1.8.0 running. > > > Cheers, > Ricardson > > _______________________________________________ > Slackbuilds-devel mailing list > Slackbuilds-devel at slackbuilds.org > https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-devel From kind.note8582 at fastmail.com Sat Mar 8 16:45:52 2025 From: kind.note8582 at fastmail.com (kind.note8582 at fastmail.com) Date: Sat, 08 Mar 2025 13:45:52 -0300 Subject: [Slackbuilds-users] [Slackbuilds-devel] TLP package (fwd) In-Reply-To: <4e33c40a-fce4-43d0-8f46-9f2609dcda3b@zoho.com> References: <4e33c40a-fce4-43d0-8f46-9f2609dcda3b@zoho.com> Message-ID: <5f3b843a-c2f3-4304-b93f-b9f79a705726@app.fastmail.com> Thank you Aditya. On Sat, Mar 8, 2025, at 1:43 PM, Aditya via SlackBuilds-users wrote: > Thanks, I missed this. > > Ricardson, feel free to take over maintenance for TLP. > > -- > Kind Regards, > Aditya > > On 08-03-2025 06:24, B. Watson wrote: > > > > Aaditya, this is for you: > > > > ---------- Forwarded message ---------- > > Date: Fri, 07 Mar 2025 14:45:28 -0300 > > From: kind.note8582 at fastmail.com > > Reply-To: SBo Admin List > > To: SBo Admin List > > Subject: [Slackbuilds-devel] TLP package > > > > Hi, > > > > I tried to contact the maintainer about the TLP new version, the > > last Feb.14, no reply... > > Can I grab this package? I already have TLP version 1.8.0 running. > > > > > > Cheers, > > Ricardson > > > > _______________________________________________ > > Slackbuilds-devel mailing list > > Slackbuilds-devel at slackbuilds.org > > https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-devel > _______________________________________________ > 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 kind.note8582 at fastmail.com Sat Mar 8 17:31:32 2025 From: kind.note8582 at fastmail.com (kind.note8582 at fastmail.com) Date: Sat, 08 Mar 2025 14:31:32 -0300 Subject: [Slackbuilds-users] naming conventions Message-ID: I?d like to discuss package naming conventions, using kubectl as an example. The current package uses a precompiled version of kubectl. I?ve created a new SlackBuild that compiles it from source, resulting in a much smaller binary. This got me thinking..... why don?t we adopt a consistent naming approach like this: - kubectl.SlackBuild (compiles from source) - kubectl-bin.SlackBuild (repacks prebuilt binaries) What do you think? -- BR, r1w1s1 From fsleg at t-rg.ws Sat Mar 8 19:31:52 2025 From: fsleg at t-rg.ws (fsLeg) Date: Sat, 8 Mar 2025 22:31:52 +0300 Subject: [Slackbuilds-users] naming conventions In-Reply-To: References: Message-ID: On 08.03.2025 20:31, kind.note8582 at fastmail.com wrote: >why don?t we adopt a consistent naming approach like this: > > - kubectl.SlackBuild (compiles from source) > - kubectl-bin.SlackBuild (repacks prebuilt binaries) This question was actually raised a few days ago in a thread about a proposed SlackBuild template for packaging pre-built binaries. It also proposed to name scripts for repackaging software as *-bin, and in the following discussion I felt that the consensus was to use exactly that naming scheme for SlackBuilds, except for cases when repackaging a binary is the only SBo-compatible way (like proprietary software). So you should ask the current maintainer of kubectl to rename the SlackBuild to kubectl-bin or even remove it altogether if building from source doesn't require many dependencies and not resource-intensive. From andrzej at telszewski.com Sat Mar 8 21:33:16 2025 From: andrzej at telszewski.com (Andrzej Telszewski) Date: Sat, 8 Mar 2025 22:33:16 +0100 Subject: [Slackbuilds-users] naming conventions In-Reply-To: References: Message-ID: <01022d5d-0c59-41f5-9ba8-71b6ef87b05b@telszewski.com> On 08/03/2025 20:31, fsLeg wrote: > This question was actually raised a few days ago in a thread about a > proposed SlackBuild template for packaging pre-built binaries. It also > proposed to name scripts for repackaging software as *-bin, and in the > following discussion I felt that the consensus was to use exactly that > naming scheme for SlackBuilds, except for cases when repackaging a > binary is the only SBo-compatible way (like proprietary software). I love this idea! > > So you should ask the current maintainer of kubectl to rename the > SlackBuild to kubectl-bin or even remove it altogether if building > from source doesn't require many dependencies and not resource-intensive. Exactly. :-) From rizitis at gmail.com Sat Mar 8 21:47:58 2025 From: rizitis at gmail.com (=?UTF-8?B?zpnPic6szr3Ovc63z4I=?=) Date: Sat, 8 Mar 2025 23:47:58 +0200 Subject: [Slackbuilds-users] sfml and SFML Message-ID: Latest SBo updates include an ADD: sfml.SlackBuild by me. I just realized that my friend Dimitris Zlatanidis already has a SFML.SlackBuild also... I guess my SlackBuild must be removed... or rename it to sfml-static.SlackBuild (?) since I'm building static libs also! I don't know exactly what must be done, I'm sorry for what happened. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurt.maxwell.weber at gmail.com Sun Mar 9 02:12:29 2025 From: kurt.maxwell.weber at gmail.com (Kurt M. Weber) Date: Sat, 8 Mar 2025 20:12:29 -0600 Subject: [Slackbuilds-users] Two Soapy-SDR packages? Message-ID: <27b6edee-bdb1-418f-9e2e-6f5de783438f@gmail.com> What is the difference between the SoapySDR slackbuild maintained by Alan Aversa that's been in the repo for ages, and the soapy-sdr from Ioannis Anagnostakis that was just added in the most recent update? --Kurt From willysr at slackbuilds.org Sun Mar 9 03:33:26 2025 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sun, 9 Mar 2025 10:33:26 +0700 Subject: [Slackbuilds-users] naming conventions In-Reply-To: References: Message-ID: > >why don?t we adopt a consistent naming approach like this: > > > >?????? - kubectl.SlackBuild (compiles from source) > >?????? - kubectl-bin.SlackBuild (repacks prebuilt binaries) > > This question was actually raised a few days ago in a thread about a > proposed SlackBuild template for packaging pre-built binaries. It also > proposed to name scripts for repackaging software as *-bin, and in the > following discussion I felt that the consensus was to use exactly that > naming scheme for SlackBuilds, except for cases when repackaging a > binary is the only SBo-compatible way (like proprietary software). > > So you should ask the current maintainer of kubectl to rename the > SlackBuild to kubectl-bin or even remove it altogether if building from > source doesn't require many dependencies and not resource-intensive. IMHO, we don't really need a spesific template for pre-built binaries, since it's just a matter of packaging. We can just use the existing templates and adjust it with the project we are trying to package. Template is useful when there's a spesific ways of packaging projects using different build tools, like rust, go, python, perl, etc. I agree with *-bin naming thing. It's consistent with what we have currently in our repo. as for kubectl, i didn't know the situation when i took over kubectl from Dimitris and pushed the public update. I saw he was trying to remove it, so i took over because i used it. If r1w1s1 wants to provide a script for building it from source, feel free to send PR. I will submit a new script kubectl-bin for this purpose. During normal cycle like nowadays, renaming is two-way process: Add new script and remove old one. It has to be done manually since it need to be populated in the database. For mass renames, i would suggest to do it during development for new SBo repo for next Slackware release. Since everything is not yet populated in the database, we can do "wild" things in the repo: adding new scripts, renames, delete broken scripts, etc. -- 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 wrodrigues201 at gmail.com Sun Mar 9 04:58:48 2025 From: wrodrigues201 at gmail.com (wilson rodrigues) Date: Sun, 9 Mar 2025 10:28:48 +0530 Subject: [Slackbuilds-users] letsencrypt not working. Message-ID: Hello, When using certbot to create ssl certificates, an error is thrown "AttributeError: module 'josepy' has no attribute 'ComparableX509'" josepy changelog on github shows 2.0.0 Breaking Change: PyOpenSSL has been fully removed. - Dropped objects: - josepy.util.ComparableX509 Version: letsencrypt 3.20 josepy 2.0.0 Slackware 15.0 Regards. WR -------------- next part -------------- An HTML attachment was scrubbed... URL: From willysr at slackbuilds.org Sun Mar 9 05:02:54 2025 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sun, 9 Mar 2025 12:02:54 +0700 Subject: [Slackbuilds-users] letsencrypt not working. In-Reply-To: References: Message-ID: <9c106a47-b797-42b9-9e6d-b8d61d86a2c0@slackbuilds.org> > Hello, > When using certbot to create ssl certificates, an error is thrown > "AttributeError: module 'josepy' has no attribute 'ComparableX509'" > > josepy changelog on github shows > > 2.0.0 > Breaking Change: PyOpenSSL has been fully removed. - Dropped objects: > - josepy.util.ComparableX509 > > Version: > letsencrypt 3.20 > josepy 2.0.0 > Slackware 15.0 Thanks for the report i revert the commit back to 1.5.0 i missed the changelog this time :( -- 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 kind.note8582 at fastmail.com Sun Mar 9 16:48:30 2025 From: kind.note8582 at fastmail.com (kind.note8582 at fastmail.com) Date: Sun, 09 Mar 2025 13:48:30 -0300 Subject: [Slackbuilds-users] naming conventions In-Reply-To: References: Message-ID: Nice! thank you all for the feedback, I will create PR today. --- BR r1w1s1(Ricardson) On Sun, Mar 9, 2025, at 12:33 AM, Willy Sudiarto Raharjo wrote: >> >why don?t we adopt a consistent naming approach like this: >> > >> >?????? - kubectl.SlackBuild (compiles from source) >> >?????? - kubectl-bin.SlackBuild (repacks prebuilt binaries) >> >> This question was actually raised a few days ago in a thread about a >> proposed SlackBuild template for packaging pre-built binaries. It also >> proposed to name scripts for repackaging software as *-bin, and in the >> following discussion I felt that the consensus was to use exactly that >> naming scheme for SlackBuilds, except for cases when repackaging a >> binary is the only SBo-compatible way (like proprietary software). >> >> So you should ask the current maintainer of kubectl to rename the >> SlackBuild to kubectl-bin or even remove it altogether if building from >> source doesn't require many dependencies and not resource-intensive. > > IMHO, we don't really need a spesific template for pre-built binaries, > since it's just a matter of packaging. We can just use the existing > templates and adjust it with the project we are trying to package. > Template is useful when there's a spesific ways of packaging projects > using different build tools, like rust, go, python, perl, etc. > I agree with *-bin naming thing. It's consistent with what we have > currently in our repo. > > as for kubectl, i didn't know the situation when i took over kubectl > from Dimitris and pushed the public update. I saw he was trying to > remove it, so i took over because i used it. If r1w1s1 wants to provide > a script for building it from source, feel free to send PR. > > I will submit a new script kubectl-bin for this purpose. > > During normal cycle like nowadays, renaming is two-way process: Add new > script and remove old one. It has to be done manually since it need to > be populated in the database. > > For mass renames, i would suggest to do it during development for new > SBo repo for next Slackware release. Since everything is not yet > populated in the database, we can do "wild" things in the repo: adding > new scripts, renames, delete broken scripts, etc. > > > -- > Willy Sudiarto Raharjo > > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - https://slackbuilds.org/faq/ > > > Attachments: > * OpenPGP_signature.asc From thinkunix at zoho.com Mon Mar 10 08:11:33 2025 From: thinkunix at zoho.com (thinkunix) Date: Mon, 10 Mar 2025 04:11:33 -0400 Subject: [Slackbuilds-users] [RFC] a binary repack SlackBuild template. In-Reply-To: <93eda2f4-fd27-75f9-6fc7-1473a07c6e6b@slackware.uk> References: <87o6yhxq21.fsf@laptop.lockywolf.net> <1E7E6624-91AF-4529-870C-D5CF6650F552@t-rg.ws> <61f8481-fc48-511b-4d9-68fbcb4c7c81@slackware.uk> <3EB3331C-B0C2-45C0-A040-A2C820B623A5@t-rg.ws> <93eda2f4-fd27-75f9-6fc7-1473a07c6e6b@slackware.uk> Message-ID: <831e8b70-ae1b-292b-4c48-9b992084d14b@zoho.com> B. Watson wrote: > > > On Tue, 4 Mar 2025, fsLeg wrote: >> >> What about proprietary software? It's only distributed as pre-built >> binaries (like mentioned discord, also saflashplayer). Do such >> packages need to be named *-bin? > > Good question. I might not bother with the -bin in that case. Wouldn't it be better to always use the "-bin" for binary repacks? Then if the source is eventually released, you won't have naming issues. The non"-bin" version is built from source; the "-bin" is a binary repack. From phalange at komputermatrix.com Mon Mar 10 13:21:43 2025 From: phalange at komputermatrix.com (phalange at komputermatrix.com) Date: Mon, 10 Mar 2025 09:21:43 -0400 Subject: [Slackbuilds-users] [RFC] a binary repack SlackBuild template. In-Reply-To: <831e8b70-ae1b-292b-4c48-9b992084d14b@zoho.com> References: <87o6yhxq21.fsf@laptop.lockywolf.net> <1E7E6624-91AF-4529-870C-D5CF6650F552@t-rg.ws> <61f8481-fc48-511b-4d9-68fbcb4c7c81@slackware.uk> <3EB3331C-B0C2-45C0-A040-A2C820B623A5@t-rg.ws> <93eda2f4-fd27-75f9-6fc7-1473a07c6e6b@slackware.uk> <831e8b70-ae1b-292b-4c48-9b992084d14b@zoho.com> Message-ID: On 2025-03-10 04:11, thinkunix via SlackBuilds-users wrote: > B. Watson wrote: >> >> >> On Tue, 4 Mar 2025, fsLeg wrote: >>> >>> What about proprietary software? It's only distributed as pre-built >>> binaries (like mentioned discord, also saflashplayer). Do such >>> packages need to be named *-bin? >> >> Good question. I might not bother with the -bin in that case. > > Wouldn't it be better to always use the "-bin" for binary repacks? > Then if the source is eventually released, you won't have naming > issues. The non"-bin" version is built from source; the "-bin" is > a binary repack. > _______________________________________________ > 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/ I share this view; I maintain a couple binaries and I'd be happy to rename them *-bin. IMHO it's easier to have a rule than a case-by-case evaluation (i.e., checking is there, could there be a source code build). From 1.41421 at gmail.com Mon Mar 10 19:18:24 2025 From: 1.41421 at gmail.com (Luveh Keraph) Date: Mon, 10 Mar 2025 13:18:24 -0600 Subject: [Slackbuilds-users] Source code missing for some Slackbuilds scripts Message-ID: Yesterday I was building a bunch of packages in a system to match what I have in a separate system. As it happens, a substantial number of them - like e.g. calc, makemkv, monitorix, transcode, pari) could not be built simply because the source code to be used is not available in the target location any more. For the most part it is not a big deal, for the new sources can usually be found without a problem (things for transcode were a bit more tricky) and a simple modification to the corresponding Slackbuilds script gets things built properly. I was wondering, however, whether it would be a good idea to add small script to the Slackbuilds repository whereby the script attempts to download the source code for each item in Slackbuilds once a day every day, and sends a warning email to the maintainer of each package. This does not guarantee anything, as some maintainers simply stop checking their emails, or even delete their email address, but I wonder whether it would help those who still do maintenance chores, especially when they are responsible for more than just a couple of items. -------------- next part -------------- An HTML attachment was scrubbed... URL: From urchlay at slackware.uk Mon Mar 10 20:42:51 2025 From: urchlay at slackware.uk (B. Watson) Date: Mon, 10 Mar 2025 16:42:51 -0400 (EDT) Subject: [Slackbuilds-users] Source code missing for some Slackbuilds scripts In-Reply-To: References: Message-ID: On Mon, 10 Mar 2025, Luveh Keraph wrote: > Yesterday I was building a bunch of packages in a system to match what I have in a separate system. As it happens, a substantial number of them - like e.g. calc, makemkv, monitorix, > transcode, pari) could not be built simply because the source code to be used is not available in the target location any more.? There's a solution for this: the SBo source archive. https://slackware.uk/sbosrcarch/ slackbuilds.org itself doesn't host sources, so the archive is hosted elsewhere. Every time there's an update to the SBo master git branch, the new DOWNLOAD and DOWNLOAD_x86_64 files are downloaded and filed in the archive trees (by-name and by-md5). If you use sbopkg, it will automatically use the archive if the original URL doesn't work. Also, if you use sbo-maintainer-tools, it has a sbodl command that can download sources from the archive (the -a option). > For the most part it is not a big deal, for the new sources can usually be found without a problem?(things for transcode were a bit more tricky) and a simple modification?to the > corresponding Slackbuilds script gets things built properly. I was wondering, however, whether it would be a good idea to add small script to the Slackbuilds repository whereby the > script attempts to download the source code for each item in Slackbuilds once a day every day, and sends a warning email to the maintainer of each package. If someone implements this, I beg of you, keep track of previous emails and don't send the maintainer the same email twice. Also, daily is a bad idea. Weekly would be better. This is because the repo only updates weekly, on Friday nights. So if a source disappears on Saturday and I get an email about it, I fix the build and submit the update... but it won't get merged to the master branch until the next Friday. I do *not* want to receive 5 more emails that week telling me to update my build, since I already did. If your system did that, then I probably would block the emails or file them as spam, for my own sanity. Another issue with your idea... some of the sources are rather large. Constantly re-downloading them every day (or even every week) might cost us money. Hard numbers: The sbosrcarch by-name and by-md5 directories are each 190GB. Files are hardlinked between the two trees, and outdated files are removed from the archive weekly, so this gives a pretty good idea of how much source your email script would have to download per run. 190GB a day would be 5.7 terabytes a month... Of course your script could just do an HTTP HEAD instead of a download. But there are web servers out there that refuse to respond to a HEAD request. Plus, it doesn't let the script detect when the md5sum is wrong (meaning, the file changed on the server). From 1.41421 at gmail.com Mon Mar 10 21:15:17 2025 From: 1.41421 at gmail.com (Luveh Keraph) Date: Mon, 10 Mar 2025 15:15:17 -0600 Subject: [Slackbuilds-users] Source code missing for some Slackbuilds scripts In-Reply-To: References: Message-ID: Thanks. I was certainly not suggesting to download the sources every time, but merely to verify that they are available where they are supposed to be in each case, triggering the email communication only when they are not. While I acknowledge that doing so every day would be overkill, all the more so bearing in mind the details that you described about the weekly updates; doing it once a week would make more sense. I still think that an email ought to be sent every week for each affected item for as long as the relevant maintainer won't sort things out for that item. Another issue is that some Slackbuilds items are multiple versions behind the current official upstream one, and while there often is a stability rationale for this it is not uncommon for such a thing to happen because the maintainers have simply ditched their maintenance responsibilities, as evidenced by the fact that they don't acknowledge repeated emails on the issue. What I am proposing would obviously make no difference in such cases, but it might when the reason why the item is not being properly upgraded is because the relevant maintainer simply forgot about it - which, based on some threads in this list, does not seem to be an entirely unusual occurrence. On Mon, Mar 10, 2025 at 2:43?PM B. Watson wrote: > > > On Mon, 10 Mar 2025, Luveh Keraph wrote: > > > Yesterday I was building a bunch of packages in a system to match what I > have in a separate system. As it happens, a substantial number of them - > like e.g. calc, makemkv, monitorix, > > transcode, pari) could not be built simply because the source code to be > used is not available in the target location any more. > > There's a solution for this: the SBo source archive. > > https://slackware.uk/sbosrcarch/ > > slackbuilds.org itself doesn't host sources, so the archive is hosted > elsewhere. Every time there's an update to the SBo master git branch, > the new DOWNLOAD and DOWNLOAD_x86_64 files are downloaded and filed in > the archive trees (by-name and by-md5). > > If you use sbopkg, it will automatically use the archive if the > original URL doesn't work. Also, if you use sbo-maintainer-tools, it > has a sbodl command that can download sources from the archive (the > -a option). > > > For the most part it is not a big deal, for the new sources can usually > be found without a problem (things for transcode were a bit more tricky) > and a simple modification to the > > corresponding Slackbuilds script gets things built properly. I was > wondering, however, whether it would be a good idea to add small script to > the Slackbuilds repository whereby the > > script attempts to download the source code for each item in Slackbuilds > once a day every day, and sends a warning email to the maintainer of each > package. > > If someone implements this, I beg of you, keep track of previous > emails and don't send the maintainer the same email twice. Also, daily > is a bad idea. Weekly would be better. > > This is because the repo only updates weekly, on Friday nights. So if > a source disappears on Saturday and I get an email about it, I fix the > build and submit the update... but it won't get merged to the master > branch until the next Friday. I do *not* want to receive 5 more emails > that week telling me to update my build, since I already did. If your > system did that, then I probably would block the emails or file them > as spam, for my own sanity. > > Another issue with your idea... some of the sources are rather > large. Constantly re-downloading them every day (or even every week) > might cost us money. > > Hard numbers: The sbosrcarch by-name and by-md5 directories are each > 190GB. Files are hardlinked between the two trees, and outdated files > are removed from the archive weekly, so this gives a pretty good idea > of how much source your email script would have to download per run. > > 190GB a day would be 5.7 terabytes a month... > > Of course your script could just do an HTTP HEAD instead of a > download. But there are web servers out there that refuse to respond > to a HEAD request. Plus, it doesn't let the script detect when the > md5sum is wrong (meaning, the file changed on the server). > _______________________________________________ > 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 Tue Mar 11 03:45:44 2025 From: urchlay at slackware.uk (B. Watson) Date: Mon, 10 Mar 2025 23:45:44 -0400 (EDT) Subject: [Slackbuilds-users] Source code missing for some Slackbuilds scripts In-Reply-To: References: Message-ID: On Mon, 10 Mar 2025, Luveh Keraph wrote: > Thanks. I was certainly not suggesting to download the sources every > time, but merely to verify that they are available where they are > supposed to be in each case, triggering the email communication only > when they are not. While I acknowledge that doing so every day would > be overkill, all the more so bearing in mind the details that you > described about the weekly updates; doing it once a week would make > more sense. I still think that an email ought to be sent every week > for each affected item for as long as the relevant maintainer won't > sort things out for that item. "Verify that they are available" could be done with HTTP HEAD. And sbolint (from sbo-maintainer-tools) already can check the whole repo for broken download links using HEAD. At the top level of the tree, you'd run "sbolint -au". It doesn't send emails, though. But some other script could parse the results and send out emails... if we really want to do that. > Another issue is that some Slackbuilds items are multiple versions > behind the current official upstream one, and while there often > is a stability rationale for this it is not uncommon for such a > thing to happen because the maintainers have simply ditched their > maintenance responsibilities, as evidenced by the fact that they > don't acknowledge repeated emails on the issue. What I am proposing > would obviously make no difference in such cases, but it might when > the reason why the item is not being properly upgraded is because > the relevant maintainer simply forgot about it - which, based on > some threads in this list, does?not seem to be an entirely unusual > occurrence.? I'm not sure this is such a good idea. Some of us don't like being nagged. It would have to be opt-in... and the maintainers who would opt in are likely the ones who already do a decent job of keeping their builds updated. The ones who don't update their builds probably would ignore nag emails, too. Just from a technical perspective, it would be fairly complex to do it right. We would need (a) a way to check a package for new versions, and (b) a way for maintainers to tell the system "this package can't/won't be upgraded because $REASON". (a) could somewhat be done via repology.org. A lot of maintainers already use it to track when their stuff needs updates. However, that has issues... If none of the other repos monitored by replogy have the same package, there's nothing to compare to. And if one of the repos updates to some bleeding-edge git version, your build gets flagged as outdated even if it's the last release. (b) would need some way to be automated. Nobody wants to manually maintain a list (text file or whatever on the server) of exceptions to the version update emails. Also... the way things work now makes some sense. If a build isn't being updated, it's up to the build's users to ask the maintainer for an update. If none of the users care enough to send the maintainer an email, then the users are happy with the version they have, and there's no need to update it *just* to be updating. If there's a new update and neither the users nor the maintainer even notice that it's there, that's equivalent to "if a tree falls in the forest and nobody's there to hear it, does it make a sound?" IMO. If users do care enough to send a mail, that accomplishes the same purpose as your automated mail scheme: let the maintainer know that there's a new version. The maintainer might have a good reason for not updating (which he explains in the reply to the mail), or he might just not have noticed the new version is out (so he tells the user "thanks" and updates the build). If the mails get ignored by the maintainer, eventually some user will step up and take over the build, and become the new maintainer. If nobody does, that likely means nobody cares all that much about the build, and it can get removed (eventually, after some amount of time listed as "orphaned"). Automating the "this project has a new version" emails might not really accomplish all that much actual change, is what I'm trying to say. Inattentive maintainers will continue to be inattentive, and ones that pay attention don't *need* to be prodded. From fourtysixandtwo at sliderr.net Tue Mar 11 04:31:16 2025 From: fourtysixandtwo at sliderr.net (fourtysixandtwo) Date: Mon, 10 Mar 2025 22:31:16 -0600 Subject: [Slackbuilds-users] Source code missing for some Slackbuilds scripts In-Reply-To: References: Message-ID: I'm with Mr. Watson on this. This needs the human touch which also adds a certain urgency to it that an automated system won't. Cheers. From slack at giand.it Tue Mar 11 05:44:13 2025 From: slack at giand.it (=?UTF-8?Q?Giancarlo_Dess=C3=AC?=) Date: Tue, 11 Mar 2025 06:44:13 +0100 Subject: [Slackbuilds-users] Please remove BeautifulSoup4 Message-ID: <7331a88f-6423-4d17-87cf-6f2ba98b304d@giand.it> Hi, yesterday I submitted the update of BeautifulSoup4. At the moment it doesn't appear in pending queue and I didn't received any report, so I think it should included in approval at soon. Please remove my submit in any case: I checked just now via pip that a new dependency is required, so the info file must be fixed. Thanks gian -- ********************************************************* Giancarlo Dess? https://www.giand.it https://github.com/giandex Slackware Linux... because it works! ********************************************************* From urchlay at slackware.uk Tue Mar 11 05:49:34 2025 From: urchlay at slackware.uk (B. Watson) Date: Tue, 11 Mar 2025 01:49:34 -0400 (EDT) Subject: [Slackbuilds-users] Please remove BeautifulSoup4 In-Reply-To: <7331a88f-6423-4d17-87cf-6f2ba98b304d@giand.it> References: <7331a88f-6423-4d17-87cf-6f2ba98b304d@giand.it> Message-ID: <7b27b1a-2c39-5660-8f2c-334e6fbdda36@slackware.uk> On Tue, 11 Mar 2025, Giancarlo Dess? wrote: > Please remove my submit in any case: I checked just now via pip that a > new dependency is required, so the info file must be fixed. Removed. From urchlay at slackware.uk Tue Mar 11 06:46:23 2025 From: urchlay at slackware.uk (B. Watson) Date: Tue, 11 Mar 2025 02:46:23 -0400 (EDT) Subject: [Slackbuilds-users] Source code missing for some Slackbuilds scripts In-Reply-To: References: Message-ID: Something I forgot to mention in my previous email... The reason I'm going into such detail about this is that I'm almost certainly the one who would have to do the work, if there's going to be a system that notifies maintainers about broken source URLs and outdated versions. I'm not the only one who could possibly do it, but AFAIK I'm the only SBo admin who currently has the free time to possibly work on it. I don't want you to think "This guy doesn't want to do the work because he's lazy" or "because he's opposed to change". I just don't see it as being worth the time and effort. I don't think it would actually do much to prevent lazy maintainers from being lazy, and it would be marginally useful for active maintainers... but also annoying. If a human says "Hey, can you update to version ?", I can respond with one of these: - "Version is a development version, I prefer to stick with the stable version" - "I will, when I have time to work on it, please be patient" - "I tried to update it, but it needs a newer version of than Slackware 15.0 has" - "I tested the newer version, and it has bugs that make it useless" - " is a dependee for , which requires the older version" - "I have stopped using , would you like to take over maintenance?" If an automated email bot sends me such a message, I can't explain anything to it. From dickson.tim at googlemail.com Tue Mar 11 11:30:31 2025 From: dickson.tim at googlemail.com (Tim Dickson) Date: Tue, 11 Mar 2025 11:30:31 +0000 Subject: [Slackbuilds-users] Source code missing for some Slackbuilds scripts In-Reply-To: References: Message-ID: agreed. I have my own script that checks the packages I maintain for updates, (and also some other ones I keep a repo of) That highlights when there is an update, or a change in the website broke my scraping script. We also have https://sourceforge.net/projects/slackbuildsdirectlinks/ which we can use for those projects which keep changing, or? removing source code/links so you don't loose access to source for existing scripts where projects don't keep older versions. It would be more useful to have a location containing a list of the latest packages which can be checked programmatically by those who want to automate their own checking. To a certain extent repology.org can do this, but the problems of distro's rolling git pushes as releases makes it less useful for projects that actually have proper release versions, or at least tag versions. Then if the maintainer wants an easy version check they can grep the list for their packages, and if not, they can continue doing things they way they always have done. regards, Tim On 11/03/2025 06:46, B. Watson wrote: > > Something I forgot to mention in my previous email... > > The reason I'm going into such detail about this is that I'm almost > certainly the one who would have to do the work, if there's going to > be a system that notifies maintainers about broken source URLs and > outdated versions. > > I'm not the only one who could possibly do it, but AFAIK I'm the only > SBo admin who currently has the free time to possibly work on it. I > don't want you to think "This guy doesn't want to do the work because > he's lazy" or "because he's opposed to change". > > I just don't see it as being worth the time and effort. I don't think > it would actually do much to prevent lazy maintainers from being lazy, > and it would be marginally useful for active maintainers... but also > annoying. > > If a human says "Hey, can you update to version ?", I > can respond with one of these: > > - "Version is a development version, I prefer to stick with the > ? stable version" > > - "I will, when I have time to work on it, please be patient" > > - "I tried to update it, but it needs a newer version of than > ? Slackware 15.0 has" > > - "I tested the newer version, and it has bugs that make it useless" > > - " is a dependee for , which requires the > older version" > > - "I have stopped using , would you like to take over > maintenance?" > > If an automated email bot sends me such a message, I can't explain > anything to it. > _______________________________________________ > 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 duncan_roe at optusnet.com.au Wed Mar 12 07:18:59 2025 From: duncan_roe at optusnet.com.au (Duncan Roe) Date: Wed, 12 Mar 2025 18:18:59 +1100 Subject: [Slackbuilds-users] Source code missing for some Slackbuilds scripts In-Reply-To: References: Message-ID: On Tue, Mar 11, 2025 at 02:46:23AM -0400, B. Watson wrote: > > Something I forgot to mention in my previous email... > > The reason I'm going into such detail about this is that I'm almost > certainly the one who would have to do the work, if there's going to > be a system that notifies maintainers about broken source URLs and > outdated versions. > I agree it would be poor use of your time. Anyone who cares can browse https://repology.org/repository/slackbuilds/problems for their email. That's what I do. Cheers ... Duncan. From urchlay at slackware.uk Wed Mar 12 07:31:03 2025 From: urchlay at slackware.uk (B. Watson) Date: Wed, 12 Mar 2025 03:31:03 -0400 (EDT) Subject: [Slackbuilds-users] Source code missing for some Slackbuilds scripts In-Reply-To: References: Message-ID: On Wed, 12 Mar 2025, Duncan Roe wrote: > I agree it would be poor use of your time. Anyone who cares can browse > https://repology.org/repository/slackbuilds/problems for their email. That's > what I do. Yah, repology.org is very useful. I highly recommend it for any SlackBuild maintainer. That said... some of the stuff I package, doesn't exist in any other distro. In that case, repology can't help: it doesn't actually track the upstream project, only distro repos. If none of those repos have my package, there's nothing for it to compare to. Example: https://repology.org//projects/?search=hatari-tos-roms ...that one's not a great example: it's a repackaging of ROM images from the 1980s. It'll never need a version update (though it might need the homepage and download URLs updated some day). Better example: https://repology.org//projects/?search=cicb The other subtle thing about using repology to track updates... you're always a bit behind. repology won't notice that project XYZwhatever has updated, it'll only notice when some distro repo has updated their build/package of it. From spycrowsoft at gmail.com Wed Mar 12 09:58:17 2025 From: spycrowsoft at gmail.com (Spycrowsoft) Date: Wed, 12 Mar 2025 10:58:17 +0100 Subject: [Slackbuilds-users] [RFC] a binary repack SlackBuild template. In-Reply-To: References: <87o6yhxq21.fsf@laptop.lockywolf.net> <1E7E6624-91AF-4529-870C-D5CF6650F552@t-rg.ws> <61f8481-fc48-511b-4d9-68fbcb4c7c81@slackware.uk> <3EB3331C-B0C2-45C0-A040-A2C820B623A5@t-rg.ws> <93eda2f4-fd27-75f9-6fc7-1473a07c6e6b@slackware.uk> <831e8b70-ae1b-292b-4c48-9b992084d14b@zoho.com> Message-ID: <26332d9c-3d48-409e-a457-4940e51dda05@gmail.com> Should programs which are only available in binary form also be named *-bin? Some examples: resilio-sync, stm32cubeide, stm32cubeprog, teams and others. Op 10-03-2025 om 14:21 schreef phalange at komputermatrix.com: > On 2025-03-10 04:11, thinkunix via SlackBuilds-users wrote: >> B. Watson wrote: >>> >>> >>> On Tue, 4 Mar 2025, fsLeg wrote: >>>> >>>> What about proprietary software? It's only distributed as pre-built >>>> binaries (like mentioned discord, also saflashplayer). Do such >>>> packages need to be named *-bin? >>> >>> Good question. I might not bother with the -bin in that case. >> >> Wouldn't it be better to always use the "-bin" for binary repacks? >> Then if the source is eventually released, you won't have naming >> issues.? The non"-bin" version is built from source; the "-bin" is >> a binary repack. >> _______________________________________________ >> 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/ > > I share this view; I maintain a couple binaries and I'd be happy to > rename them *-bin. > > IMHO it's easier to have a rule than a case-by-case evaluation (i.e., > checking is there, could there be a source code build). > _______________________________________________ > 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 andrzej at telszewski.com Wed Mar 12 10:02:43 2025 From: andrzej at telszewski.com (Andrzej Telszewski) Date: Wed, 12 Mar 2025 11:02:43 +0100 Subject: [Slackbuilds-users] Source code missing for some Slackbuilds scripts In-Reply-To: References: Message-ID: <5df351b8-86b3-4c73-83b1-1956584db662@telszewski.com> Hi, just a 3 cents on how I watch for updates for software hosted on GitHub. I'm subscribed to the release RSS feeds for the ones I'm interested in. -- Best regards, Andrzej Telszewski From mab974 at misouk.com Wed Mar 12 11:44:32 2025 From: mab974 at misouk.com (Mab974) Date: Wed, 12 Mar 2025 11:44:32 +0000 Subject: [Slackbuilds-users] Source code missing for some Slackbuilds scripts In-Reply-To: <5df351b8-86b3-4c73-83b1-1956584db662@telszewski.com> References: <5df351b8-86b3-4c73-83b1-1956584db662@telszewski.com> Message-ID: Idem for Perl cpan.. Le 12 mars 2025 10:02:43 UTC, Andrzej Telszewski a ?crit?: >Hi, > >just a 3 cents on how I watch for updates for software hosted on GitHub. > >I'm subscribed to the release RSS feeds for the ones I'm interested in. > >-- >Best regards, >Andrzej Telszewski > >_______________________________________________ >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/ > Mab974 From smartphone. -------------- next part -------------- An HTML attachment was scrubbed... URL: From 1.41421 at gmail.com Wed Mar 12 12:59:12 2025 From: 1.41421 at gmail.com (Luveh Keraph) Date: Wed, 12 Mar 2025 06:59:12 -0600 Subject: [Slackbuilds-users] Source code missing for some Slackbuilds scripts In-Reply-To: References: <5df351b8-86b3-4c73-83b1-1956584db662@telszewski.com> Message-ID: What I was proposing is much simpler than what has been discussed in this thread: 1. For item abc the Slackbuilds page says that one must download abc-2.3.77.tar..gz from location L. 2. Once a week the script would check out for the presence of abc-2.3.77.tar.gz in L. 3. If that tarball is missing the script would email the maintainer something like "abc-2.3.77.tar.gz not found in L". 4. The maintainer would look into it, and would have the capability of disabling further emails for abc if she/she thinks that would be appropriate. This would do nothing for maintainers that are keeping track of things diligently already, and could therefore opt out. It might be useful for new maintainers, or for forgetful ones. Step 4 would never be taken by some maintainers anyway, but chances are nothing would work in those cases. On Wed, Mar 12, 2025 at 5:44?AM Mab974 wrote: > Idem for Perl cpan.. > > Le 12 mars 2025 10:02:43 UTC, Andrzej Telszewski > a ?crit : >> >> Hi, >> >> just a 3 cents on how I watch for updates for software hosted on GitHub. >> >> I'm subscribed to the release RSS feeds for the ones I'm interested in. >> >> -- >> Best regards, >> Andrzej Telszewski >> ------------------------------ >> 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/ >> >> Mab974 > From smartphone. > _______________________________________________ > 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 zsd+slackbuilds at jdvb.ca Wed Mar 12 13:23:53 2025 From: zsd+slackbuilds at jdvb.ca (Jim) Date: Wed, 12 Mar 2025 10:23:53 -0300 Subject: [Slackbuilds-users] Source code missing for some Slackbuilds scripts In-Reply-To: References: Message-ID: On Wed, Mar 12, 2025 at 18:18 (+1100), Duncan Roe wrote: > On Tue, Mar 11, 2025 at 02:46:23AM -0400, B. Watson wrote: >> Something I forgot to mention in my previous email... >> The reason I'm going into such detail about this is that I'm almost >> certainly the one who would have to do the work, if there's going to >> be a system that notifies maintainers about broken source URLs and >> outdated versions. > I agree it would be poor use of your time. Anyone who cares can browse > https://repology.org/repository/slackbuilds/problems for their email. That's > what I do. I think you missed or forgot about the discussion of "interrupts vs. polling" in your computer architecture and/or OS classes. :-) I would much rather get interrupted by an email telling me I should/could update a package than spend my time polling one or more web sites to see if there is some issue. YMMV. Jim From arnaud.garcia-fernandez at laposte.net Wed Mar 12 13:31:22 2025 From: arnaud.garcia-fernandez at laposte.net (Arnaud) Date: Wed, 12 Mar 2025 13:31:22 +0000 Subject: [Slackbuilds-users] Source code missing for some Slackbuilds scripts In-Reply-To: References: Message-ID: <76E886A1-E1D5-4E43-BB3F-95CFF08FF63D@laposte.net> Le 12 mars 2025 13:23:53 UTC, Jim a ?crit?: >On Wed, Mar 12, 2025 at 18:18 (+1100), Duncan Roe wrote: > >> On Tue, Mar 11, 2025 at 02:46:23AM -0400, B. Watson wrote: > >>> Something I forgot to mention in my previous email... > >>> The reason I'm going into such detail about this is that I'm almost >>> certainly the one who would have to do the work, if there's going to >>> be a system that notifies maintainers about broken source URLs and >>> outdated versions. > >> I agree it would be poor use of your time. Anyone who cares can browse >> https://repology.org/repository/slackbuilds/problems for their email. That's >> what I do. > >I think you missed or forgot about the discussion of "interrupts >vs. polling" in your computer architecture and/or OS classes. :-) > >I would much rather get interrupted by an email telling me I should/could >update a package than spend my time polling one or more web sites to see if >there is some issue. > >YMMV. > > Jim >_______________________________________________ >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/ > You can subscribe to your own maintainer RSS feed on repology, getting RSS notifications when one of your script is out-of-date, or becomes up-to-date after an SBo release. This is quite efficient. I use that and the RSS feeds from github or Pypi, for almost all my SlackBuilds. But that's only because I've done this for a long time, it'd take too much efforts to do it from scratch now. - Yth. -------------- next part -------------- An HTML attachment was scrubbed... URL: From urchlay at slackware.uk Wed Mar 12 19:22:44 2025 From: urchlay at slackware.uk (B. Watson) Date: Wed, 12 Mar 2025 15:22:44 -0400 (EDT) Subject: [Slackbuilds-users] Source code missing for some Slackbuilds scripts In-Reply-To: References: Message-ID: <1bec283-7a8c-6948-6a7-8668b1b97964@slackware.uk> On Wed, 12 Mar 2025, Jim wrote: > I think you missed or forgot about the discussion of "interrupts > vs. polling" in your computer architecture and/or OS classes. :-) People aren't computers though... > I would much rather get interrupted by an email telling me I should/could > update a package than spend my time polling one or more web sites to see if > there is some issue. > > YMMV. My mileage does vary... I don't want to be interrupted when doing something else. I'll poll for updates when I decide it's time to work on SBo stuff. When I'm busy doing something else, there's no need to know that a build needs updating (I'm not gonna work on it because I'm already busy). Anyway, any polling process can be turned into an interrupt one by running it periodically and emailing the result to your address. We got this handy cron daemon in Slackware... From noel.butler at ausics.net Thu Mar 13 11:33:33 2025 From: noel.butler at ausics.net (Noel Butler) Date: Thu, 13 Mar 2025 21:33:33 +1000 Subject: [Slackbuilds-users] [RFC] a binary repack SlackBuild template. In-Reply-To: <26332d9c-3d48-409e-a457-4940e51dda05@gmail.com> References: <87o6yhxq21.fsf@laptop.lockywolf.net> <1E7E6624-91AF-4529-870C-D5CF6650F552@t-rg.ws> <61f8481-fc48-511b-4d9-68fbcb4c7c81@slackware.uk> <3EB3331C-B0C2-45C0-A040-A2C820B623A5@t-rg.ws> <93eda2f4-fd27-75f9-6fc7-1473a07c6e6b@slackware.uk> <831e8b70-ae1b-292b-4c48-9b992084d14b@zoho.com> <26332d9c-3d48-409e-a457-4940e51dda05@gmail.com> Message-ID: <6e4cbea7194972c895173bdae0295645@ausics.net> On 12/03/2025 19:58, Spycrowsoft wrote: > Should programs which are only available in binary form also be named > *-bin? These should follow what's generally excepted for decades and be named by their architecture like redhat and debian have always done, what Pat does, in fact, what winweenies also get bind-9.16.25-x86_64-1.txz google-earth-pro-stable_current_amd64.deb google-earth-stable_current_i386.deb master-pdf-editor-3.2.81_i386.tar.gz master-pdf-editor-3.7.10_amd64.tar.gz TeamViewer_Setup_x64.exe ... and so on... -- Regards, Noel Butler -------------- next part -------------- An HTML attachment was scrubbed... URL: From fsleg at t-rg.ws Thu Mar 13 11:43:29 2025 From: fsleg at t-rg.ws (fsLeg) Date: Thu, 13 Mar 2025 14:43:29 +0300 Subject: [Slackbuilds-users] [RFC] a binary repack SlackBuild template. In-Reply-To: <6e4cbea7194972c895173bdae0295645@ausics.net> References: <87o6yhxq21.fsf@laptop.lockywolf.net> <1E7E6624-91AF-4529-870C-D5CF6650F552@t-rg.ws> <61f8481-fc48-511b-4d9-68fbcb4c7c81@slackware.uk> <3EB3331C-B0C2-45C0-A040-A2C820B623A5@t-rg.ws> <93eda2f4-fd27-75f9-6fc7-1473a07c6e6b@slackware.uk> <831e8b70-ae1b-292b-4c48-9b992084d14b@zoho.com> <26332d9c-3d48-409e-a457-4940e51dda05@gmail.com> <6e4cbea7194972c895173bdae0295645@ausics.net> Message-ID: What you're talking about is $PRGNAM-$VERSION-$ARCH-$BUILD$TAG.$PKGTYPE format in its entirety. The topic, however, is whether $PGRNAM should be prgnam or prgnam-bin for scripts that just repackage pre-built binaries. On March 13, 2025 14:33:33 GMT+03:00, Noel Butler via SlackBuilds-users wrote: >bind-9.16.25-x86_64-1.txz >google-earth-pro-stable_current_amd64.deb >google-earth-stable_current_i386.deb >master-pdf-editor-3.2.81_i386.tar.gz >master-pdf-editor-3.7.10_amd64.tar.gz >TeamViewer_Setup_x64.exe > >... and so on... > From for_slackbuilds-users_mlist_2023-04-21 at lockywolf.net Thu Mar 13 15:02:26 2025 From: for_slackbuilds-users_mlist_2023-04-21 at lockywolf.net (Lockywolf) Date: Thu, 13 Mar 2025 23:02:26 +0800 Subject: [Slackbuilds-users] [RFC] a binary repack SlackBuild template. In-Reply-To: References: <87o6yhxq21.fsf@laptop.lockywolf.net> Message-ID: <87o6y5nefy.fsf@laptop.lockywolf.net> Jeremy Hansen writes: > Looking over my SlackBuilds that package repackd binaries, I feel a template is unlikely you capture the many > nuances required in a repack. Well, yes, but the same is true for too many source-based builds. A template is just a set of guidelines, and on Slackware we often ignore them. But it is still better to have them. > Some are able to reside in /usr/ (discord), while others are better contained in > /opt/ (SweetHome3D, blender). Personally I would prefer to have as much binary software in /opt/ as possible. There might be cases when this is hard to attain, as with browser-plugins, which just insist on residing in /usr/, but even in those cases it is often enough to add enough symlinks. I am usually trying to imagine /usr/ being a thing under my control, and /opt being out of it. > These scripts seem to require a lot of manual really that > is likely hard to capture on a single template. Well, initially I wanted to write a "HOWTO", or a plain-text guideline file, but then I thought that a script is in no way worse than a plain text file. Spycrowsoft writes: > Should programs which are only available in binary form also be named *-bin? I personally think so, yes. After all, sometimes software is opened. >It actually has 196 dependencies, which might as well be 10 million. Apologies for being a bit rude, but SBo's Haskell approach makes little sense. Most (if not all) Haskell packages are providing _static_ libraries, and there is no sense installing them systemwide, it only confuses the build system. I actually tried to write a link generator script for Haskell just like Rust/Go, https://gitlab.com/Lockywolf/lwfslackbuilds/-/blob/master/02_lockywolf-sbo-scripts/lwf_make-cargolinks.bash?ref_type=heads I tried to raise the issue on Hackage, but perhaps didn't succeed: https://github.com/haskell/hackage-server/issues/1261 -- 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 urchlay at slackware.uk Thu Mar 13 15:48:27 2025 From: urchlay at slackware.uk (B. Watson) Date: Thu, 13 Mar 2025 11:48:27 -0400 (EDT) Subject: [Slackbuilds-users] [RFC] a binary repack SlackBuild template. In-Reply-To: <87o6y5nefy.fsf@laptop.lockywolf.net> References: <87o6yhxq21.fsf@laptop.lockywolf.net> <87o6y5nefy.fsf@laptop.lockywolf.net> Message-ID: <9e5129ba-5feb-3dd9-77a6-227d4da8e5fe@slackware.uk> On Thu, 13 Mar 2025, Lockywolf wrote: >> It actually has 196 dependencies, which might as well be 10 million. > > Apologies for being a bit rude, but SBo's Haskell approach makes little > sense. Most (if not all) Haskell packages are providing _static_ > libraries, and there is no sense installing them systemwide, it only > confuses the build system. You're not being rude, you're expressing an opinion. I don't know enough about Haskell to agree or disagree with you, but hopefully it causes further discussion among those who do know. So if we stopped having systemwide libraries for haskell, pandoc would have 197 source file downloads (the way a go or rust build does) instead of 196 package dependencies? That's a little better, but not much better. I'd still prefer pandoc-bin. From zsd+slackbuilds at jdvb.ca Thu Mar 13 23:33:44 2025 From: zsd+slackbuilds at jdvb.ca (Jim) Date: Thu, 13 Mar 2025 20:33:44 -0300 Subject: [Slackbuilds-users] Source code missing for some Slackbuilds scripts In-Reply-To: <1bec283-7a8c-6948-6a7-8668b1b97964@slackware.uk> References: <1bec283-7a8c-6948-6a7-8668b1b97964@slackware.uk> Message-ID: On Wed, Mar 12, 2025 at 15:22 (-0400), B. Watson wrote: > On Wed, 12 Mar 2025, Jim wrote: >> I think you missed or forgot about the discussion of "interrupts >> vs. polling" in your computer architecture and/or OS classes. :-) > People aren't computers though... Are you sure? Maybe we're all just part of some big simulation. :-) >> I would much rather get interrupted by an email telling me I should/could >> update a package than spend my time polling one or more web sites to see if >> there is some issue. >> YMMV. > My mileage does vary... I don't want to be interrupted when doing > something else. I could argue that you just don't need to read your email when you are busy. (But if these emails come frequently, I agree with your point. At least to a point.) > I'll poll for updates when I decide it's time to work on SBo stuff. When > I'm busy doing something else, there's no need to know that a build needs > updating (I'm not gonna work on it because I'm already busy). > Anyway, any polling process can be turned into an interrupt one by > running it periodically and emailing the result to your address. We > got this handy cron daemon in Slackware... Sure, if you have an way to automatically check each of your Slackbuilds for updates. I know you have a lot, and for you that makes sense. But for people who have a small number (back to the varying mileage), setting that up may not make sense, depending on whether or not the source repository makes automatically checking for updates easy. Jim From willysr at slackbuilds.org Sat Mar 15 02:29:39 2025 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sat, 15 Mar 2025 09:29:39 +0700 Subject: [Slackbuilds-users] Updates - 20250315.1 Message-ID: Hi all with this public update, we have completed the merge with protobuf 30.0. Let's hope we didn't miss anything next in queue is the update of webkit2gtk Sat Mar 15 02:21:33 UTC 2025 academic/kissat: Updated for version 4.0.2. academic/zotero: updated for version 7.0.14 desktop/icewm: Updated for version 3.7.2. desktop/kanshi: Updated for version 20250224_00a653a desktop/nwg-displays: Updated for version 0.3.24. desktop/nwg-look: Updated for version 1.0.3. desktop/sun: Updated for version 2.0.2. desktop/sun: Updated for version 2.0.3. development/android-tools: Fix build with new profobuf3 development/aws-cdk: Updated for version 2.1004.0. development/bw-atari8-tools: Added (Atari 8-bit related utilities). development/git-tools: Added (git-related tools). development/gitify-bin: Added (Github Notification). development/golangci-lint: Updated for version 1.64.6. development/golangci-lint: Updated for version 1.64.7. development/google-go-lang: Updated for version 1.23.7. development/gopls: Updated for version 0.18.1. development/lua-language-server: Updated for version 3.13.9. development/mold: Updated for version 2.37.1. development/mongodb-compass: Updated for version 1.45.4. development/pnpm: Updated for version 10.6.2. development/pnpm: Updated for version 10.6.3. development/postman: Updated for version 11.35.4 development/protobuf3: Re-enable private headers. development/protobuf3: Updated for version 30.0. development/qbs: Updated for version 2.6.0 development/redo: Remove empty man directory. development/rustup: Updated for version 1.28.1. development/sourcegit: Fix permission. development/sourcegit: Updated for version 2025.08 development/terraform: Updated for version 1.11.1 development/tkman: Added (Texinfo Browser). development/vscode-bin: Updated for version 1.98.1. development/vstudio: Updated for version 15.1.1 development/witsy: Added (Gen AI Desktop Application). development/zulu-openjdk11: Updated for version 11.0.26. development/zulu-openjdk17: Updated for version 17.0.14. development/zulu-openjdk21: Updated for version 21.0.6. development/zulu-openjdk8: Updated for version 8.0.442. games/frotz: Fix parallel build heisenbug. games/mgba: Updated for version 0.10.5 games/protontricks: Version bump to 1.12.1 gis/OWSLib: Updated for version 0.32.0. gis/eccodes: Updated for version 2.40.0. gis/geos: Updated for version 3.13.1. gis/libgeotiff: Updated for version 1.7.4. gis/pdal: Updated for version 2.8.4. gis/postgis: Updated for version 3.5.2. graphics/FotoKilof: Update README. graphics/kgeotag: Updated for version 1.8.0 ham/soapy-remote: Removed (Duplicate of SoapyRemote). ham/soapy-sdr: Removed (duplicate of SoapySDR). libraries/FreeImage: Fix line endings of the patches. libraries/grpc: Updated for version 1.71.0. libraries/libxmlb: Updated for version 0.3.22. libraries/netcdf: Updated for version 4.9.3. libraries/protobuf-c: Fix build with new protobuf3. libraries/qwt: Disable Playground & Tests components by default libraries/sfml: Removed (duplicate of SFML). libraries/spglib: Updated for version 2.6.0. libraries/tinygltf: Updated for version 2.9.5. libraries/tinyxml2: Version bump to 10.1.0 misc/KeePass: Updated for version 2.58. misc/countryfetch: Added (Fetch Country Information). multimedia/plexmediaserver: Updated for version 1.41.5.9522_a96edc606. multimedia/popcorntime: Updated for version 0.5.1 network/brave-browser: updated for version 1.76.74 network/discord: Version bump to 0.0.88 network/dokuwiki: Updated for version 20240206b. network/dropbear: Updated for version 2025.87. network/kubectl-bin: Added (CLI for kubernetes Cluster). network/kubectl-bin: Updated for version 1.32.3. network/kubectl: Updated for version 1.32.3. network/librewolf: Updated for version 136.0 network/nextcloud-server: Update script. network/rustdesk-opt: Updated for version 1.3.8. network/session: Updated for version 1.14.5. network/sfeed: Updated for version 2.2 network/snac2: Updated for version 2.73. network/syncthingtray-bin: Updated for version 1.7.3. network/telegram: Updated for version 5.12.3. network/vivaldi: Updated for version 7.1.3570.60. network/vnstat: Update README. network/waterfox: Updated for version 6.5.5 office/csbooks-bin: Added (Smart Book Manager). office/hunspell-ancient-greek: Added (Ancient Greek Dictionary). office/ishmael: Updated for version 1.01. office/pandoc-bin: Fix script for CI. office/typobuster: Updated for version 0.1.7. python/BeautifulSoup4: Updated for version 4.13.3. python/git-fame: Updated for version 2.1.0. python/josepy: Updated for version 1.5.0 python/pyotherside: Updated for version 1.6.2. python/python-jeepney: Updated for version 0.9.0. python/python-libarchive-c: Updated for version 5.2. python/python3-aiohappyeyeballs: Updated for version 2.6.1. python/python3-cssselect: Version bump to 1.3.0 python/python3-findpython: Version bump to 0.6.3 python/python3-grpcio: Updated for version 1.71.0. python/python3-identify: Updated for version 2.6.9. python/python3-librosa: Version bump to 0.11.0 python/python3-msal: Version bump to 1.32.0 python/python3-pdm: Version bump to 2.22.4 python/python3-threadpoolctl: Version bump to 3.6.0 python/python3-tox: Version bump to 4.24.2 system/OpenSnitch: Update for 1.6.8 system/TLP: Updated for version 1.8.0. system/alacritty: Updated for version 0.15.1. system/borgmatic: Updated for version 1.9.14 system/brave-browser-the-latest: Updated for version 1.1 system/cpmtools: Add --with-diskdefs to configure. system/fonts-khmer-extra: Added (Khmer Fonts). system/fonts-lao-extra: Added (Lao Fonts). system/fonts-myanmar-extra: Added (Burmese Fonts). system/fzf: Updated for version 0.60.3. system/letsencrypt: Updated for version 3.3.0. system/openzfs: updated for version 2.3.1 system/osquery-bin: Updated for version 5.16.0. system/rasdaemon: Updated for version 0.8.3 system/sbpkg: Updated for version 1.1.3. system/skim: Updated for version 0.16.1. system/usbguard: Fix build with protobuf 30.0. +--------------------------+ -- 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 antonioleal at yahoo.com Sat Mar 15 13:00:48 2025 From: antonioleal at yahoo.com (Antonio Leal) Date: Sat, 15 Mar 2025 13:00:48 +0000 Subject: [Slackbuilds-users] Failing PRs on github? References: <65531675-e8d6-4e12-9f3e-f8fd7b081948.ref@yahoo.com> Message-ID: <65531675-e8d6-4e12-9f3e-f8fd7b081948@yahoo.com> Github PRs are failing. Got this message. Any of you have the same problem? Current runner version: '2.322.0' 2 Operating System 6 Runner Image 11 Runner Image Provisioner 13 GITHUB_TOKEN Permissions 16 Secret source: Actions 17 Prepare workflow directory 18 Prepare all required actions 19 Getting action download info 20 Download action repository 'actions/checkout at 11bd71901bbe5b1630ceea73d27597364c9af683' (SHA:11bd71901bbe5b1630ceea73d27597364c9af683) 21 Download action repository 'tj-actions/changed-files at dcc7a0cba800f454d79fff4b993e8c3555bcc0a8' (SHA:dcc7a0cba800f454d79fff4b993e8c3555bcc0a8) 22 Error: An action could not be found at the URI 'https://api.github.com/repos/tj-actions/changed-files/tarball/dcc7a0cba800f454d79fff4b993e8c3555bcc0a8' (AC40:17C00E:E00842:1C75775:67D5792D) -------------- next part -------------- An HTML attachment was scrubbed... URL: From willysr at slackbuilds.org Sat Mar 15 14:54:03 2025 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sat, 15 Mar 2025 21:54:03 +0700 Subject: [Slackbuilds-users] Failing PRs on github? In-Reply-To: <65531675-e8d6-4e12-9f3e-f8fd7b081948@yahoo.com> References: <65531675-e8d6-4e12-9f3e-f8fd7b081948.ref@yahoo.com> <65531675-e8d6-4e12-9f3e-f8fd7b081948@yahoo.com> Message-ID: <9be8aaf3-960a-4e6f-acb9-c400dd6c1336@slackbuilds.org> > Github PRs are failing. Got this message. > > Any of you have the same problem? > > Current runner version: '2.322.0' > 2 runs/13873064351/job/38822031316?pr=10114#step:1:2>Operating System > 6 runs/13873064351/job/38822031316?pr=10114#step:1:7>Runner Image > 11 runs/13873064351/job/38822031316?pr=10114#step:1:13>Runner Image > Provisioner > 13 runs/13873064351/job/38822031316?pr=10114#step:1:16>GITHUB_TOKEN > Permissions > 16 runs/13873064351/job/38822031316?pr=10114#step:1:20>Secret source: Actions > 17 runs/13873064351/job/38822031316?pr=10114#step:1:21>Prepare workflow > directory > 18 runs/13873064351/job/38822031316?pr=10114#step:1:22>Prepare all required > actions > 19 runs/13873064351/job/38822031316?pr=10114#step:1:23>Getting action > download info > 20 runs/13873064351/job/38822031316?pr=10114#step:1:24>Download action > repository 'actions/ > checkout at 11bd71901bbe5b1630ceea73d27597364c9af683' (SHA:11bd71901bbe5b1630ceea73d27597364c9af683) > 21 runs/13873064351/job/38822031316?pr=10114#step:1:25>Download action > repository 'tj-actions/changed- > files at dcc7a0cba800f454d79fff4b993e8c3555bcc0a8' (SHA:dcc7a0cba800f454d79fff4b993e8c3555bcc0a8) > 22 runs/13873064351/job/38822031316?pr=10114#step:1:26>Error: An action > could not be found at the URI 'https://api.github.com/repos/tj-actions/ > changed-files/tarball/ > dcc7a0cba800f454d79fff4b993e8c3555bcc0a8' (AC40:17C00E:E00842:1C75775:67D5792D) See this PR https://github.com/SlackBuildsOrg/slackbuilds/pull/10115 I will push an unscheduled public update once the build check is complete and see if we can fix some issues found during our weekly check it should be a minor update since not many scripts submitted between today's public update and tomorrow -- 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 pyllyukko at maimed.org Sun Mar 16 06:48:54 2025 From: pyllyukko at maimed.org (pyllyukko) Date: Sun, 16 Mar 2025 08:48:54 +0200 Subject: [Slackbuilds-users] letsencrypt not working. In-Reply-To: References: Message-ID: Hello. On Sun, Mar 09, 2025 at 10:28:48AM +0530, wilson rodrigues wrote: > 2.0.0 > Breaking Change: PyOpenSSL has been fully removed. - Dropped objects: > - josepy.util.ComparableX509 > > Version: > letsencrypt 3.20 > josepy 2.0.0 > Slackware 15.0 There's also an open issue about this in certbot's repo: https://github.com/certbot/certbot/issues/10185 -- pyllyukko email: PGP: https://keybase.io/pyllyukko -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From slack at giand.it Tue Mar 18 18:32:50 2025 From: slack at giand.it (=?UTF-8?Q?Giancarlo_Dess=C3=AC?=) Date: Tue, 18 Mar 2025 19:32:50 +0100 Subject: [Slackbuilds-users] Please remove qgis from CI_queue Message-ID: Maybe I solved the issue, if you remove from pending I'll send another submit Thanks -- ********************************************************* Giancarlo Dess? https://www.giand.it https://github.com/giandex Slackware Linux... because it works! ********************************************************* From urchlay at slackware.uk Tue Mar 18 19:24:52 2025 From: urchlay at slackware.uk (B. Watson) Date: Tue, 18 Mar 2025 15:24:52 -0400 (EDT) Subject: [Slackbuilds-users] Please remove qgis from CI_queue In-Reply-To: References: Message-ID: <8359b59d-f7fa-393a-d320-1dfec6c08d26@slackware.uk> On Tue, 18 Mar 2025, Giancarlo Dess? wrote: > Maybe I solved the issue, if you remove from pending I'll send another > submit Removed. From fourtysixandtwo at sliderr.net Wed Mar 19 17:16:27 2025 From: fourtysixandtwo at sliderr.net (fourtysixandtwo) Date: Wed, 19 Mar 2025 11:16:27 -0600 Subject: [Slackbuilds-users] Remove network/flexget Message-ID: It's been broken for a while now and is too much of a moving target to support. If someone else would like to take it over, be my guest. Thanks! From wrodrigues201 at gmail.com Thu Mar 20 03:19:14 2025 From: wrodrigues201 at gmail.com (wilson rodrigues) Date: Thu, 20 Mar 2025 08:49:14 +0530 Subject: [Slackbuilds-users] tinyxml2 upgrade breaks encfs Message-ID: Hello, After upgrading tinyxml2 to version tinyxml2-11.0.0 the encfs utility is unable to mount the encrypted directory. Error: "Bus error" After downgrading to tinyxml2-10.0.0 there is no error message. Thanks WR -------------- next part -------------- An HTML attachment was scrubbed... URL: From urchlay at slackware.uk Thu Mar 20 05:44:40 2025 From: urchlay at slackware.uk (B. Watson) Date: Thu, 20 Mar 2025 01:44:40 -0400 (EDT) Subject: [Slackbuilds-users] tinyxml2 upgrade breaks encfs In-Reply-To: References: Message-ID: <340fffd-793a-d199-57cf-60185c86b168@slackware.uk> On Thu, 20 Mar 2025, wilson rodrigues wrote: > Hello, > After upgrading tinyxml2 to version tinyxml2-11.0.0 Do you mean 10.1.0? That's the version that's in the SBo repo as of last week's update. > the encfs utility is unable to mount the encrypted directory. Error: "Bus error" Can't duplicate here. encfs seems to be working fine with tinyxml2-10.1.0. > After downgrading to tinyxml2-10.0.0 there is no error message. Did you upgrade tinyxml2 without rebuilding encfs? Usually a bus error means ABI incompatibility. Try rebuilding encfs against the new tinyxml2 version. From jebrhansen+SBo at gmail.com Thu Mar 20 06:27:23 2025 From: jebrhansen+SBo at gmail.com (Jeremy Hansen) Date: Wed, 19 Mar 2025 23:27:23 -0700 Subject: [Slackbuilds-users] tinyxml2 upgrade breaks encfs In-Reply-To: References: Message-ID: On Wed, Mar 19, 2025, 8:19?PM wilson rodrigues wrote: > Hello, > After upgrading tinyxml2 to version tinyxml2-11.0.0 the encfs utility is > unable to mount the encrypted directory. Error: "Bus error" > > After downgrading to tinyxml2-10.0.0 there is no error message. > I'm the maintainer for tinyxml2 and upgraded it to 10.1.0 recently. That version bump upgraded the .so library which requires rebuilding packages that rely on it. Try rebuilding encfs after updating tinyxml2 and report any issues with it. Jeremy Jeremy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wrodrigues201 at gmail.com Thu Mar 20 12:02:53 2025 From: wrodrigues201 at gmail.com (wilson rodrigues) Date: Thu, 20 Mar 2025 17:32:53 +0530 Subject: [Slackbuilds-users] tinyxml2 upgrade breaks encfs In-Reply-To: <340fffd-793a-d199-57cf-60185c86b168@slackware.uk> References: <340fffd-793a-d199-57cf-60185c86b168@slackware.uk> Message-ID: Hello, Sorry, the version installed was tinyxml2-10.1.0 which caused the encfs utility to fail. After reinstalling tinyxml2-10.1.0 and encfs-1.9.5, the issue got resolved. Thanks. WR On Thu, 20 Mar 2025 at 11:15, B. Watson wrote: > > > On Thu, 20 Mar 2025, wilson rodrigues wrote: > > > Hello, > > After upgrading tinyxml2 to version tinyxml2-11.0.0 > > Do you mean 10.1.0? That's the version that's in the SBo repo as of > last week's update. > > > the encfs utility is unable to mount the encrypted directory. Error: > "Bus error" > > Can't duplicate here. encfs seems to be working fine with > tinyxml2-10.1.0. > > > After downgrading to tinyxml2-10.0.0 there is no error message. > > Did you upgrade tinyxml2 without rebuilding encfs? Usually a bus > error means ABI incompatibility. Try rebuilding encfs against the new > tinyxml2 version. > _______________________________________________ > 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 wrodrigues201 at gmail.com Thu Mar 20 12:03:40 2025 From: wrodrigues201 at gmail.com (wilson rodrigues) Date: Thu, 20 Mar 2025 17:33:40 +0530 Subject: [Slackbuilds-users] tinyxml2 upgrade breaks encfs In-Reply-To: References: Message-ID: Thanks. Issue is resolved. On Thu, 20 Mar 2025 at 11:57, Jeremy Hansen wrote: > On Wed, Mar 19, 2025, 8:19?PM wilson rodrigues > wrote: > >> Hello, >> After upgrading tinyxml2 to version tinyxml2-11.0.0 the encfs utility is >> unable to mount the encrypted directory. Error: "Bus error" >> >> After downgrading to tinyxml2-10.0.0 there is no error message. >> > > I'm the maintainer for tinyxml2 and upgraded it to 10.1.0 recently. > > That version bump upgraded the .so library which requires rebuilding > packages that rely on it. > > Try rebuilding encfs after updating tinyxml2 and report any issues with it. > > Jeremy > > Jeremy > >> _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - https://slackbuilds.org/faq/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From willysr at slackbuilds.org Sat Mar 22 02:07:09 2025 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sat, 22 Mar 2025 09:07:09 +0700 Subject: [Slackbuilds-users] Updates - 20250322.1 Message-ID: <3023e47d-e670-42c7-9354-4710dc075ae9@slackbuilds.org> Sat Mar 22 01:47:33 UTC 2025 academic/archaeopteryx: Removed (upstream gone). academic/avogadroapp: Updated for version 1.100.0. academic/avogadrolibs: Updated for version 1.100.0. academic/gaiasky: Updated for version 3.6.7. academic/gplates: Updated for version 2.5. academic/grb: Update script. academic/kjv: Update script. academic/pari: Updated for version 2.17.2. academic/vul: Update script. academic/zotero: updated for version 7.0.15 audio/noisetorch-bin: Added (Noise Supression). desktop/ClamAV-GUI: Updated for version 1.0.9 desktop/awf: Updated for version 2.8.1. desktop/gammastep: Updated for version 2.0.10. desktop/gromit-mpx: Updated for version 1.7.0. desktop/nwg-look: Updated for version 1.0.4. desktop/nwg-readme-browser: Updated for version 0.1.7. desktop/screenfetch: Updated for version 3.9.9. desktop/xmouseless: Update script. desktop/xwallpaper: Update script. develop/golangci-lint: Updated for version 1.64.8. develop/pre-commit: Updated for version 4.2.0. development/aws-cdk: Updated for version 2.1005.0. development/bbcsdl: Updated for version 1.41a development/dart-sass: Updated for version 1.86.0. development/fortitude-bin: Added (Fortran linter). development/golang-googlecode-gonet: Update source URL. development/kotlin: Updated for version 2.1.20. development/php82: Updated for version 8.2.28 development/php84: Updated for version 8.4.5 development/postman: Updated for version 11.36.6 development/processing: Fix DOWNLOAD URL. development/protobuf3: Updated for version 30.1. development/sourcegit: Updated for version 2025.09 development/unicorn: Updated for version 2.1.3. development/vscode-bin: Updated for version 1.98.2. development/witsy: Updated for version 2.1.6 development/zulu-openjdk11: Updated MD5SUMs. games/FlightGear: Updated for version 2024.1.1. games/pioneer: Applied upstream commits. gis/librttopo: Update MD5SUM. gis/osm2pgsql: Updated for version 2.0.1. gis/qgis: Updated for version 3.42.0. git/ci: Replace tj-actions/changed-files. graphics/alembic-framework: Updated for version 1.8.8. graphics/converseen: Updated for version 0.13.0.0. graphics/img2pdf: Updated for version 0.6.0. graphics/xmedcon: Updated for version 0.25.1. ham/gridtracker2: Added (Amateur Radio Companion). ham/sdrpp: Updated for version 20250325.aa2b4b1c. libraries/SimGear: Updated for version 2024.1.1. libraries/VTK: Enable choice between Qt5 and Qt6 libraries/liblogging: Updated for version 1.0.7. libraries/libsoup3: Updated for version 3.6.5. libraries/msgpack-c-cpp: Updated for version 7.0.0. libraries/openvkl: Update README. misc/ghostpcl: Updated for version 10.05.0. misc/nordpass: Updated for version 5.29.7. misc/yubikey-manager: Updated for version 5.6.1. network/brave-browser: updated for version 1.76.80 network/deltachat-desktop: Added (Chat App). network/dropbox: Updated for version 220.4.4126. network/flexget: Removed (maintainer request). network/gem: Update script. network/gemget: Update script. network/gmi100: Update script. network/grpcurl: Fix permission. network/grpcurl: Updated for version 1.9.3 network/gutenberg: Added (Fetch ebooks). network/kubectl: Update from source. network/newsraft: Updated for version 0.29. network/nextcloud-server: Updated for version 29.0.13. network/rspamd: Updated for version 3.11.1 network/session: Updated for version 1.15.0. network/shadowsocks-rust: Updated for version 1.23.0. network/translate-shell: Update script. network/turbo-attack: Added (Turbo Traffic Generator). network/turbo-scanner: Added (Test Network). network/vivaldi: Updated for version 7.2.3621.67. network/yadifa: Updated for version 3.0.2 network/yle-dl: Updated for version 20250316. network/yt-dlp-bin: Update script. network/zabbix_agent2: Update source URL. network/zabbix_agentd: Update source URL. network/zabbix_frontend: Update source URL. network/zabbix_java_gateway: Update source URL. network/zabbix_proxy: Update source URL. network/zabbix_server: Update source URL. network/zoom-linux: Updated for 6.4.0.471 office/ishmael: Updated for version 1.02. office/miktex: Added (TeX/LaTeX implementation). office/mu: Updated for 1.12.9 office/onlyoffice-desktopeditors: Updated for version 8.3.2 office/pandoc-bin: Updated for version 3.6.4 office/sent: Update script. office/typobuster: Updated for version 0.2.0. python/cloudpickle: Updated for version 3.1.1. python/findsystemfontsfilename: Updated for version 0.3.2. python/instaloader: Update script. python/python2-pycryptodomex: Updated for version 3.22.0. python/python3-aiohttp: Updated for version 3.11.14. python/python3-boto3: Update for 1.36.24 python/python3-dunamai: Updated for version 1.23.1. python/python3-grpcio: Re-enable python3-grpcio-tools module python/python3-multidict: Updated for version 6.2.0. python/python3-poetry-dynamic-versioning: Updated for version 1.8.0. python/python3-pycryptodomex: Updated for version 3.22.0. python/python3-pydub: Added (Manipulate audio). python/python3-webrtcvad: Added (Python interface to the WebRTC). system/Iosevka-aile: Updated for version 33.1.0. system/Iosevka-etoile: Updated for version 33.1.0. system/apache-cassandra: Updated for version 4.1.8. system/brave-browser-the-latest: Updated for version 1.2 system/c-lcrypt: Updated for version 3.0.0. system/conky: Updated for version 1.22.1. system/debootstrap: Updated for version 1.0.140. system/fonts-armenian-extra: Added (Armenian Fonts). system/fonts-devanagari-extra: Update README system/fonts-georgian-extra: Added (Georgian Fonts). system/fonts-indic-ne: Update README system/fonts-indic-other: Update README system/fonts-thai-extra: Added (Thai Fonts). system/fzy: Update script. system/google-chrome-the-latest: Updated for version 4.0 system/incus: Fix VERSION system/kiwix-tools-bin: Update script. system/mongodb: Updated for version 8.0.6. system/netdata: Updated for version 2.3.0. system/openrazer-daemon: Updated for version 3.10.1. system/openrazer-kernel: Updated for version 3.10.1. system/pkg: Updated for version 0.5.0. system/rsyslog: Updated for version 8.2502.0. system/secure-delete: Update script. system/slackbootstrap: Added (Slackware Chroot Jail). system/usermin: Updated for version 2.203. system/webmin: Updated for version 2.303. +--------------------------+ -- 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 noel.butler at ausics.net Sat Mar 22 12:19:01 2025 From: noel.butler at ausics.net (Noel Butler) Date: Sat, 22 Mar 2025 22:19:01 +1000 Subject: [Slackbuilds-users] [RFC] a binary repack SlackBuild template. In-Reply-To: References: <87o6yhxq21.fsf@laptop.lockywolf.net> <1E7E6624-91AF-4529-870C-D5CF6650F552@t-rg.ws> <61f8481-fc48-511b-4d9-68fbcb4c7c81@slackware.uk> <3EB3331C-B0C2-45C0-A040-A2C820B623A5@t-rg.ws> <93eda2f4-fd27-75f9-6fc7-1473a07c6e6b@slackware.uk> <831e8b70-ae1b-292b-4c48-9b992084d14b@zoho.com> <26332d9c-3d48-409e-a457-4940e51dda05@gmail.com> <6e4cbea7194972c895173bdae0295645@ausics.net> Message-ID: <6e373ab2ba86d213ebbb8b0eec66645b@ausics.net> On 13/03/2025 21:43, fsLeg wrote: > What you're talking about is $PRGNAM-$VERSION-$ARCH-$BUILD$TAG.$PKGTYPE > format in its entirety. The topic, however, is whether $PGRNAM should > be prgnam or prgnam-bin for scripts that just repackage pre-built > binaries. My bad, I guess I didn't read the entire thread, (I use by-date and not threads in my mail and most list groups are auto marked as read by sieve - yes, my choice), however, my opinion is same. We didnt call postfix postfix-bin and so on, built or pre built, who cares, so no, just use the standard naming convention for the binary, ie: postfix, or yourbinary... I use binary packs from proprietary companies for billing system, 4G5G service management, and so on, they dont call their binaries foo-bin or foo.bin even, they use the standard naming convention, ie "foo". I dont see any problem that needs solving here. -- Regards, Noel Butler -------------- next part -------------- An HTML attachment was scrubbed... URL: From urchlay at slackware.uk Sat Mar 22 23:53:05 2025 From: urchlay at slackware.uk (B. Watson) Date: Sat, 22 Mar 2025 19:53:05 -0400 (EDT) Subject: [Slackbuilds-users] [RFC] a binary repack SlackBuild template. In-Reply-To: <6e373ab2ba86d213ebbb8b0eec66645b@ausics.net> References: <87o6yhxq21.fsf@laptop.lockywolf.net> <1E7E6624-91AF-4529-870C-D5CF6650F552@t-rg.ws> <61f8481-fc48-511b-4d9-68fbcb4c7c81@slackware.uk> <3EB3331C-B0C2-45C0-A040-A2C820B623A5@t-rg.ws> <93eda2f4-fd27-75f9-6fc7-1473a07c6e6b@slackware.uk> <831e8b70-ae1b-292b-4c48-9b992084d14b@zoho.com> <26332d9c-3d48-409e-a457-4940e51dda05@gmail.com> <6e4cbea7194972c895173bdae0295645@ausics.net> <6e373ab2ba86d213ebbb8b0eec66645b@ausics.net> Message-ID: <24e0c3aa-922b-c636-d274-2cc48cda445@slackware.uk> On Sat, 22 Mar 2025, Noel Butler via SlackBuilds-users wrote: > We didnt call postfix postfix-bin and so on, built or pre built, who cares, so no, just use the standard naming convention for the binary, ie: postfix, or ?yourbinary... Since you didn't read the whole thread, here's a synopsis. The -bin suffix is proposed because of things like "libreoffice" and "LibreOffice", which both exist in our repo. One is a build from source, the other is a repackaged binary. Calling them "libreoffice" and "libreoffice-bin" would make a *lot* more sense. Why do both exist? Because it literally takes all day to compile libreoffice on some systems. Someone thought it would be a good idea to offer users the choice to use the repackaged binary, so they could just get on with using libreoffice when needed instead of waiting all day. For software that's *only* distributed as binaries, my opinion is that the -bin isn't needed... though others prefer the idea that "binary repacks should always have -bin in the name" for consistency. That's what was being discussed. As far as your "who cares" comment goes... read the whole thread. Some people obviously do care. From davidnchmelik at gmail.com Sun Mar 23 04:26:14 2025 From: davidnchmelik at gmail.com (David Chmelik) Date: Sat, 22 Mar 2025 21:26:14 -0700 Subject: [Slackbuilds-users] new maintainers omitting READMEs Message-ID: <30287fc0-7c1e-a052-3ad3-c487dffaec71@gmail.com> Recently I saw several new SlackBuilds that omit most official README.* information from README rather than having mostly brief/non-descriptive one-liners.? I looked at some the source code which all has long README.* but for some reason all that was omitted.? When there's only brief/non-descriptive one-liners I don't know what any that software does, so had to look at source code.? If I was a SlackBuilds team member I'd reject all those and say put as much of the README.* as possible. From chris.willing at linux.com Sun Mar 23 04:59:02 2025 From: chris.willing at linux.com (Christoph Willing) Date: Sun, 23 Mar 2025 15:59:02 +1100 Subject: [Slackbuilds-users] [RFC] a binary repack SlackBuild template. In-Reply-To: <24e0c3aa-922b-c636-d274-2cc48cda445@slackware.uk> References: <87o6yhxq21.fsf@laptop.lockywolf.net> <1E7E6624-91AF-4529-870C-D5CF6650F552@t-rg.ws> <61f8481-fc48-511b-4d9-68fbcb4c7c81@slackware.uk> <3EB3331C-B0C2-45C0-A040-A2C820B623A5@t-rg.ws> <93eda2f4-fd27-75f9-6fc7-1473a07c6e6b@slackware.uk> <831e8b70-ae1b-292b-4c48-9b992084d14b@zoho.com> <26332d9c-3d48-409e-a457-4940e51dda05@gmail.com> <6e4cbea7194972c895173bdae0295645@ausics.net> <6e373ab2ba86d213ebbb8b0eec66645b@ausics.net> <24e0c3aa-922b-c636-d274-2cc48cda445@slackware.uk> Message-ID: On 23/3/25 10:53, B. Watson wrote: > > > On Sat, 22 Mar 2025, Noel Butler via SlackBuilds-users wrote: > >> We didnt call postfix postfix-bin and so on, built or pre built, who >> cares, so no, just use the standard naming convention for the binary, >> ie: postfix, or ?yourbinary... > > Since you didn't read the whole thread, here's a synopsis. > > The -bin suffix is proposed because of things like "libreoffice" > and "LibreOffice", which both exist in our repo. One is a build from > source, the other is a repackaged binary. Calling them "libreoffice" > and "libreoffice-bin" would make a *lot* more sense. > > Why do both exist? Because it literally takes all day to compile > libreoffice on some systems. Someone thought it would be a good idea > to offer users the choice to use the repackaged binary, so they could > just get on with using libreoffice when needed instead of waiting > all day. Some historical context from the SBo git log: - the binary package of libreoffice was added in 2010 i.e. "libreoffice" existed before "LibreOffice" - the "build from source" version LibreOffice was added only in 2016 - the first "-bin" package I can find was palemoon-bin which was renamed from plain palemoon in 2018 So, with hindsight, it may have been better in 2016 to rename libreoffice as libreoffice-bin before adding the new build from source version as libreoffice. However that seems to have been the first instance of the existence of both types of package in the repo i.e. there was no precedent to model on. In fact I still remember when first submitting LibreOffice that I was quite concerned whether two versions of the same software would even be allowed. Anyway, there's nothing to prevent renaming now that -bin packages are such a thing. chris > > For software that's *only* distributed as binaries, my opinion is > that the -bin isn't needed... though others prefer the idea that > "binary repacks should always have -bin in the name" for consistency. > That's what was being discussed. > > As far as your "who cares" comment goes... read the whole thread. Some > people obviously do care. > > _______________________________________________ > 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 noel.butler at ausics.net Sun Mar 23 09:47:24 2025 From: noel.butler at ausics.net (Noel Butler) Date: Sun, 23 Mar 2025 19:47:24 +1000 Subject: [Slackbuilds-users] [RFC] a binary repack SlackBuild template. In-Reply-To: <24e0c3aa-922b-c636-d274-2cc48cda445@slackware.uk> References: <87o6yhxq21.fsf@laptop.lockywolf.net> <1E7E6624-91AF-4529-870C-D5CF6650F552@t-rg.ws> <61f8481-fc48-511b-4d9-68fbcb4c7c81@slackware.uk> <3EB3331C-B0C2-45C0-A040-A2C820B623A5@t-rg.ws> <93eda2f4-fd27-75f9-6fc7-1473a07c6e6b@slackware.uk> <831e8b70-ae1b-292b-4c48-9b992084d14b@zoho.com> <26332d9c-3d48-409e-a457-4940e51dda05@gmail.com> <6e4cbea7194972c895173bdae0295645@ausics.net> <6e373ab2ba86d213ebbb8b0eec66645b@ausics.net> <24e0c3aa-922b-c636-d274-2cc48cda445@slackware.uk> Message-ID: <2623ac4a0d46d6ebef8b51fa147e535f@ausics.net> On 23/03/2025 09:53, B. Watson wrote: > On Sat, 22 Mar 2025, Noel Butler via SlackBuilds-users wrote: > >> We didnt call postfix postfix-bin and so on, built or pre built, who >> cares, so no, just use the standard naming convention for the binary, >> ie: postfix, or yourbinary... > > Since you didn't read the whole thread, here's a synopsis. > > The -bin suffix is proposed because of things like "libreoffice" > and "LibreOffice", which both exist in our repo. One is a build from > source, the other is a repackaged binary. Calling them "libreoffice" > and "libreoffice-bin" would make a *lot* more sense. rubbish, you'll do little more than create confusion - I've seen it before. > Why do both exist? Because it literally takes all day to compile > libreoffice on some systems. Someone thought it would be a good idea > to offer users the choice to use the repackaged binary, so they could > just get on with using libreoffice when needed instead of waiting > all day. So? installing 2 versions of anything is fraught with risks and incredibly rare. Compiling by source knowing you want to also install a packaged version is pretty common in past 30 years to install the source version into /opt -------------- next part -------------- An HTML attachment was scrubbed... URL: From urchlay at slackware.uk Sun Mar 23 09:58:07 2025 From: urchlay at slackware.uk (B. Watson) Date: Sun, 23 Mar 2025 05:58:07 -0400 (EDT) Subject: [Slackbuilds-users] [RFC] a binary repack SlackBuild template. In-Reply-To: <2623ac4a0d46d6ebef8b51fa147e535f@ausics.net> References: <87o6yhxq21.fsf@laptop.lockywolf.net> <1E7E6624-91AF-4529-870C-D5CF6650F552@t-rg.ws> <61f8481-fc48-511b-4d9-68fbcb4c7c81@slackware.uk> <3EB3331C-B0C2-45C0-A040-A2C820B623A5@t-rg.ws> <93eda2f4-fd27-75f9-6fc7-1473a07c6e6b@slackware.uk> <831e8b70-ae1b-292b-4c48-9b992084d14b@zoho.com> <26332d9c-3d48-409e-a457-4940e51dda05@gmail.com> <6e4cbea7194972c895173bdae0295645@ausics.net> <6e373ab2ba86d213ebbb8b0eec66645b@ausics.net> <24e0c3aa-922b-c636-d274-2cc48cda445@slackware.uk> <2623ac4a0d46d6ebef8b51fa147e535f@ausics.net> Message-ID: On Sun, 23 Mar 2025, Noel Butler wrote: > The?-bin?suffix?is?proposed?because?of?things?like?"libreoffice" > and?"LibreOffice",?which?both?exist?in?our?repo.?One?is?a?build?from > source,?the?other?is?a?repackaged?binary.?Calling?them?"libreoffice" > and?"libreoffice-bin"?would?make?a?*lot*?more?sense. > > ? > rubbish, you'll do little more than create confusion - I've seen it before. You're saying that naming the packages "libreoffice" and "libreoffice-bin" will be *more* confusing than naming them "libreoffice" and "LibreOffice"? I can't see how that would be the case. Think it through. > Why?do?both?exist??Because?it?literally?takes?all?day?to?compile > libreoffice?on?some?systems.?Someone?thought?it?would?be?a?good?idea > to?offer?users?the?choice?to?use?the?repackaged?binary,?so?they?could > just?get?on?with?using?libreoffice?when?needed?instead?of?waiting > all?day. > > ? > So? installing 2 versions of anything is fraught with risks and incredibly rare. Compiling by source knowing you want to also install a packaged version is pretty common in past 30 > years to install the source version into ?/opt Red herring. Nobody's talking about actually installing libreoffice and libreoffice-bin (or any whatever and whatever-bin) at the same time. Also, it's normally the other way around on SBo: the built from source version goes in /usr and the prepackaged binary often (not always) goes in /opt. From noel.butler at ausics.net Sun Mar 23 10:28:56 2025 From: noel.butler at ausics.net (Noel Butler) Date: Sun, 23 Mar 2025 20:28:56 +1000 Subject: [Slackbuilds-users] [RFC] a binary repack SlackBuild template. In-Reply-To: References: <87o6yhxq21.fsf@laptop.lockywolf.net> <1E7E6624-91AF-4529-870C-D5CF6650F552@t-rg.ws> <61f8481-fc48-511b-4d9-68fbcb4c7c81@slackware.uk> <3EB3331C-B0C2-45C0-A040-A2C820B623A5@t-rg.ws> <93eda2f4-fd27-75f9-6fc7-1473a07c6e6b@slackware.uk> <831e8b70-ae1b-292b-4c48-9b992084d14b@zoho.com> <26332d9c-3d48-409e-a457-4940e51dda05@gmail.com> <6e4cbea7194972c895173bdae0295645@ausics.net> <6e373ab2ba86d213ebbb8b0eec66645b@ausics.net> <24e0c3aa-922b-c636-d274-2cc48cda445@slackware.uk> <2623ac4a0d46d6ebef8b51fa147e535f@ausics.net> Message-ID: On 23/03/2025 19:58, B. Watson wrote: > You're saying that naming the packages "libreoffice" and > "libreoffice-bin" will be *more* confusing than naming them > "libreoffice" and "LibreOffice"? I can't see how that would be the > case. Think it through. yep, I've dealt with it with office staff in the past using, unsurprisingly openoffice > Red herring. Nobody's talking about actually installing libreoffice > and libreoffice-bin (or any whatever and whatever-bin) at the same > time. So, you're not doing it at same time? then WTF are we even having this discussion, no need to rename anything if its the only version on the system. -- Regards, Noel Butler -------------- next part -------------- An HTML attachment was scrubbed... URL: From erich.public at protonmail.com Sun Mar 23 12:49:04 2025 From: erich.public at protonmail.com (Erich Ritz) Date: Sun, 23 Mar 2025 12:49:04 +0000 Subject: [Slackbuilds-users] [RFC] a binary repack SlackBuild template. In-Reply-To: References: <87o6yhxq21.fsf@laptop.lockywolf.net> <831e8b70-ae1b-292b-4c48-9b992084d14b@zoho.com> <26332d9c-3d48-409e-a457-4940e51dda05@gmail.com> <6e4cbea7194972c895173bdae0295645@ausics.net> <6e373ab2ba86d213ebbb8b0eec66645b@ausics.net> <24e0c3aa-922b-c636-d274-2cc48cda445@slackware.uk> Message-ID: On Saturday, March 22nd, 2025 at 11:59 PM, Christoph Willing wrote: > On 23/3/25 10:53, B. Watson wrote: > >> On Sat, 22 Mar 2025, Noel Butler via SlackBuilds-users wrote: >> >>> We didnt call postfix postfix-bin and so on, built or pre built, who cares, so no, just use the standard naming convention for the binary, ie: postfix, or yourbinary... >> >> Since you didn't read the whole thread, here's a synopsis. >> >> The -bin suffix is proposed because of things like "libreoffice" >> and "LibreOffice", which both exist in our repo. One is a build from >> source, the other is a repackaged binary. Calling them "libreoffice" >> and "libreoffice-bin" would make a *lot* more sense. >> >> Why do both exist? Because it literally takes all day to compile >> libreoffice on some systems. Someone thought it would be a good idea >> to offer users the choice to use the repackaged binary, so they could >> just get on with using libreoffice when needed instead of waiting >> all day. > > Some historical context from the SBo git log: > >> - the binary package of libreoffice was added in 2010 i.e. "libreoffice" existed before "LibreOffice" >> - the "build from source" version LibreOffice was added only in 2016 >> - the first "-bin" package I can find was palemoon-bin which was renamed from plain palemoon in 2018 > > So, with hindsight, it may have been better in 2016 to rename libreoffice as libreoffice-bin before adding the new build from source version as libreoffice. However that seems to have been the first instance of the existence of both types of package in the repo i.e. there was no precedent to model on. In fact I still remember when first submitting LibreOffice that I was quite concerned whether two versions of the same software would even be allowed. Anyway, there's nothing to prevent renaming now that -bin packages are such a thing I think the most important thing is to explicitly state in the README if it is a binary repack. In the case of LibreOffice/libreoffice they both state whether they are built from source or are a binary repack. I do this with my builds as well (e.g. protonmail-bridge: "This script repackages the Debian binary provided by Proton AG."). ... because users are reading the README. ... oh wait... Erich > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lumin+slackbuilds at etherlight.link Sun Mar 23 14:49:52 2025 From: lumin+slackbuilds at etherlight.link (lumin+slackbuilds at etherlight.link) Date: Sun, 23 Mar 2025 17:49:52 +0300 Subject: [Slackbuilds-users] [RFC] a binary repack SlackBuild template. In-Reply-To: References: <87o6yhxq21.fsf@laptop.lockywolf.net> <1E7E6624-91AF-4529-870C-D5CF6650F552@t-rg.ws> <61f8481-fc48-511b-4d9-68fbcb4c7c81@slackware.uk> <3EB3331C-B0C2-45C0-A040-A2C820B623A5@t-rg.ws> <93eda2f4-fd27-75f9-6fc7-1473a07c6e6b@slackware.uk> <831e8b70-ae1b-292b-4c48-9b992084d14b@zoho.com> <26332d9c-3d48-409e-a457-4940e51dda05@gmail.com> <6e4cbea7194972c895173bdae0295645@ausics.net> <6e373ab2ba86d213ebbb8b0eec66645b@ausics.net> <24e0c3aa-922b-c636-d274-2cc48cda445@slackware.uk> <2623ac4a0d46d6ebef8b51fa147e535f@ausics.net> Message-ID: <64bcd135-af41-4047-aa95-28bde1d341bb@etherlight.link> > So, you're not doing it at same time? then WTF are > we even having this discussion, no need to rename > anything if its the only version on the system. This bikeshed- um, uh... discussion, thread, is about naming package scripts in the database of SlackBuilds.org, and not the names of the binaries themselves; it has nothing to do with installing multiple versions at the same time. It's more about discoverability of packages on SBo. * * * I have a slight preference to binary scripts ending with -bin, including ones without source available, but I don't really care that much, as long as it is stated in the package description, or at least, in the README (Yes, some of us do read those). Of course, I don't think any of this is worth doing mass-renaming or enforcing policy, especially not in the middle of a release cycle. Any changes and renames can be done at the next Slackware release freeze. But I say just leave all of this as a recommendation, and keep the agency with the individual maintainers. * * * Back to the original topic of the thread's OP; whether we should have a SlackBuild template for binary repacks. I vote no. For two reasons: First, what repacks? A repack from .deb? from .rpm? from some .tar.gz built for Ubuntu? Some statically linked loose Golang binaries? There's no end to what a binary repack means. Contrast that to a cmake or autotools source program, in which it is obvious what steps need to be taken, generally, to build it. For cmake and autotools, we do provide templates. Second, I don't think we should encourage binary repacks. They should be, in my opinion, a last-resort, when the software is very resource intensive to build, or only exists in binary form. I already see too many packages existing as binary repacks only, too often just because it is easier than building them from source. I don't think I like that, I view it as a degradation of SBo's packaging quality. I still appreciate all of y'all's work, thank you. Best regards :) Lumin Etherlight From antonioleal at yahoo.com Sun Mar 23 17:02:08 2025 From: antonioleal at yahoo.com (Antonio Leal) Date: Sun, 23 Mar 2025 17:02:08 +0000 Subject: [Slackbuilds-users] [RFC] a binary repack SlackBuild template. In-Reply-To: <87o6yhxq21.fsf@laptop.lockywolf.net> References: <87o6yhxq21.fsf@laptop.lockywolf.net> Message-ID: <642a2b87-2699-4d0d-bbf9-b765ced13d83@yahoo.com> I think its a valid proposal. The end-user will know immediately he is going to get something not build from source. A template could be a good idea, but I wouldn't enforce its application too strongly, maybe present it as a suggestion? If adopting this, *when* would it be done? Isn't there a risk that unaware users stay with old packages, without any update?? So if changing, I would say it better do it when -current is released and all scripts are revisited. ? If we're going the Aur way why not "-git" too? On 3/4/25 6:29 AM, Lockywolf wrote: > Dear SlackBuilds community, > > Increasingly, we have to write more and more binary repacks, > as software is becoming harder and harder to build on the premises. > > While this is an unfortunate development, and the community members > are encouraged to build software from the original sources to ensure > transparency and flexibility, sometimes building a package as a > repack is an unnecessary evil. > > This message has (attached) a proposed binary-repacking SlackBuild, > which I would like to propose for an inclusion into the templates > repository. > > Please comment and suggest how this template can be improved. > > > > > _______________________________________________ > 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 lenardrspencer at gmail.com Sun Mar 23 20:11:56 2025 From: lenardrspencer at gmail.com (Lenard Spencer) Date: Sun, 23 Mar 2025 16:11:56 -0400 Subject: [Slackbuilds-users] FlightGear-data Message-ID: If you would, please remove FlightGear-data since I have now integrated the data file into the FlightGear SlackBuild script. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From urchlay at slackware.uk Sun Mar 23 20:46:30 2025 From: urchlay at slackware.uk (B. Watson) Date: Sun, 23 Mar 2025 16:46:30 -0400 (EDT) Subject: [Slackbuilds-users] [RFC] a binary repack SlackBuild template. In-Reply-To: <64bcd135-af41-4047-aa95-28bde1d341bb@etherlight.link> References: <87o6yhxq21.fsf@laptop.lockywolf.net> <1E7E6624-91AF-4529-870C-D5CF6650F552@t-rg.ws> <61f8481-fc48-511b-4d9-68fbcb4c7c81@slackware.uk> <3EB3331C-B0C2-45C0-A040-A2C820B623A5@t-rg.ws> <93eda2f4-fd27-75f9-6fc7-1473a07c6e6b@slackware.uk> <831e8b70-ae1b-292b-4c48-9b992084d14b@zoho.com> <26332d9c-3d48-409e-a457-4940e51dda05@gmail.com> <6e4cbea7194972c895173bdae0295645@ausics.net> <6e373ab2ba86d213ebbb8b0eec66645b@ausics.net> <24e0c3aa-922b-c636-d274-2cc48cda445@slackware.uk> <2623ac4a0d46d6ebef8b51fa147e535f@ausics.net> <64bcd135-af41-4047-aa95-28bde1d341bb@etherlight.link> Message-ID: <7c5f1ac6-acde-e26d-cec2-ba99e7cb7e@slackware.uk> On Sun, 23 Mar 2025, Lumin Etherlight via SlackBuilds-users wrote: > Back to the original topic of the thread's > OP; whether we should have a SlackBuild template > for binary repacks. I vote no. For two reasons: > > First, what repacks? A repack from .deb? > from .rpm? from some .tar.gz built for Ubuntu? > Some statically linked loose Golang binaries? > There's no end to what a binary repack means. Ideally, a template for binary repacks would have commented-out example code for all of the above. > Second, I don't think we should encourage > binary repacks. They should be, in my opinion, a > last-resort, when the software is very resource > intensive to build, or only exists in binary form. That, I can agree with. > I already see too many packages existing as binary > repacks only, too often just because it is easier > than building them from source. I don't think I > like that, I view it as a degradation of SBo's > packaging quality. I've been guilty of "easier than building from source" at least once: I submitted a kitty-bin, before anyone had done a kitty from-source build. I mostly did this for myself, because I wanted to try out kitty, and submitted it to SBo in case someone else might find a use for it. It's gone now. Partly because there's no need for it, since there's a proper from-source build, and partly because upstream's binaries need newer libs (including glibc) than Slackware 15.0 has. Well, that, and I really didn't like kitty once I'd tried it (I'll stick with rxvt-unicode, thanks). I guess the point of telling you that is, I named the build with -bin specifically so someone else could use the proper name without -bin. To me, that seems like a good idea, for stuff that can be built from source but also provides binaries. From dchmelik at gmail.com Mon Mar 24 06:10:23 2025 From: dchmelik at gmail.com (David Chmelik) Date: Sun, 23 Mar 2025 23:10:23 -0700 Subject: [Slackbuilds-users] new maintainers omitting READMEs In-Reply-To: <948530ae-0a9d-4463-8d65-612775728395@slackbuilds.org> References: <30287fc0-7c1e-a052-3ad3-c487dffaec71@gmail.com> <948530ae-0a9d-4463-8d65-612775728395@slackbuilds.org> Message-ID: On 3/23/25 7:37 PM, Willy Sudiarto Raharjo wrote: >> Recently I saw several new SlackBuilds that omit most official >> README.* information from README rather than having mostly >> brief/non-descriptive one-liners.? I looked at some the source code >> which all has long README.* but for some reason all that was >> omitted.? When there's only brief/non-descriptive one-liners I don't >> know what any that software does, so had to look at source code.? If >> I was a SlackBuilds team member I'd reject all those and say put as >> much of the README.* as possible. > > README is just a brief description about the project being showed in > the SBo website, nothing more. That's what its first line is. > Upstream website is the official documentation, so no need to list all > features about the project in the README. When people need to find out > about what is this project all about in detail, they should go to > upstream rather than looking from simple README. I doubt it; no one wants to 'go upstream' for thousands packages: just have sufficient READMEs, which historically normally had everything except Internet site. From dchmelik at gmail.com Tue Mar 25 14:33:02 2025 From: dchmelik at gmail.com (David Chmelik) Date: Tue, 25 Mar 2025 07:33:02 -0700 Subject: [Slackbuilds-users] new maintainers omitting READMEs In-Reply-To: <65d68735-a045-4515-b79b-6e5de8d7287a@slackbuilds.org> References: <30287fc0-7c1e-a052-3ad3-c487dffaec71@gmail.com> <948530ae-0a9d-4463-8d65-612775728395@slackbuilds.org> <65d68735-a045-4515-b79b-6e5de8d7287a@slackbuilds.org> Message-ID: On 3/24/25 1:22 AM, Willy Sudiarto Raharjo wrote: >> I doubt it; no one wants to 'go upstream' for thousands packages: >> just have sufficient READMEs, which historically normally had >> everything except Internet site. > > I doubt people would read EVERY README for thousand packages > they just need to see some packages they need and README is just enough Speak for yourself: I built 1,500+ SBo packages, and a few other people use almost as many or maybe more.? README is enough when it's more than terse one-liner--following template--historically using entirety of upstream README.* except URL.? One-liner is for sbopkg menu, not substituting for README, which is just sloppy/lazy/unprofessional, including some use jargon so one must hunt down README to find out what the software even is (let alone if one wants/needs it)... maintainers could take a minute or two to copy that in instead of wasting minutes of thousands people forever (often finding the software isn't something they want/need). > at least they know what this script is all about Not at all; not descriptive enough, including some use jargon. > if they need more information on how to use, they should follow > upstream documentation for more detailed information Upstream README.* should be README, because it's more information on what a piece of software even is. From fsleg at t-rg.ws Tue Mar 25 14:59:02 2025 From: fsleg at t-rg.ws (fsLeg) Date: Tue, 25 Mar 2025 17:59:02 +0300 Subject: [Slackbuilds-users] new maintainers omitting READMEs In-Reply-To: References: <30287fc0-7c1e-a052-3ad3-c487dffaec71@gmail.com> <948530ae-0a9d-4463-8d65-612775728395@slackbuilds.org> <65d68735-a045-4515-b79b-6e5de8d7287a@slackbuilds.org> Message-ID: <7F3B6473-346C-4CF8-8F07-37CFBA69D99B@t-rg.ws> Here are some READMEs for the programs SlackBuilds for which I maintain: - popcorntime: - dart-sass: - shadowsocks-rust: So I'm supposed to include these walls of text with ungodly amount of irrelevant information as the script's README? I'd rather copy some relevant short excerpt that describes the piece of software in question and be done with that. If anyone really wants the entire README, it's copied to /usr/doc by the SlackBuild anyway. SBo is a repository of build scripts, not programs themselves. You don't see walls of text in, say, Debian's package descriptions. Those are of varying lengths, but never too long. Should READMEs on SBo be more descriptive? Probably. But some developers don't provide a concise description of their programs, or it's way too concise, so the only way of having a more descriptive README would be to write it yourself, and how many maintainers would be willing to do that? It's like writing documentation, almost nobody likes to do that. I think the idea is that a user would already know what program they need, README would be just to confirm it's the right one. How many people just browse a repo looking for programs to try instead of just googling/knowing something they need and then looking if it's there? Especially a third-party unofficial repo. Also, a lot of packages are just dependencies, not many people care what they do by themselves. Do those need descriptive READMEs? On March 25, 2025 17:33:02 GMT+03:00, David Chmelik wrote: >Upstream README.* should be README, because it's more information on what a piece of software even is. From matt.egger at gmail.com Tue Mar 25 15:10:57 2025 From: matt.egger at gmail.com (Matt Egger) Date: Tue, 25 Mar 2025 11:10:57 -0400 Subject: [Slackbuilds-users] new maintainers omitting READMEs In-Reply-To: References: <30287fc0-7c1e-a052-3ad3-c487dffaec71@gmail.com> <948530ae-0a9d-4463-8d65-612775728395@slackbuilds.org> <65d68735-a045-4515-b79b-6e5de8d7287a@slackbuilds.org> Message-ID: On Tue, Mar 25, 2025 at 10:33?AM David Chmelik wrote: > > > if they need more information on how to use, they should follow > > upstream documentation for more detailed information > Upstream README.* should be README, because it's more information on > what a piece of software even is. I don' fully understand the change you're asking for. Do you have an example? Perhaps one of the slackbuilds you maintain contrasted with one that you think needs more detail in the README? -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidnchmelik at gmail.com Tue Mar 25 15:15:24 2025 From: davidnchmelik at gmail.com (David Chmelik) Date: Tue, 25 Mar 2025 08:15:24 -0700 Subject: [Slackbuilds-users] new maintainers omitting READMEs In-Reply-To: <7F3B6473-346C-4CF8-8F07-37CFBA69D99B@t-rg.ws> References: <30287fc0-7c1e-a052-3ad3-c487dffaec71@gmail.com> <948530ae-0a9d-4463-8d65-612775728395@slackbuilds.org> <65d68735-a045-4515-b79b-6e5de8d7287a@slackbuilds.org> <7F3B6473-346C-4CF8-8F07-37CFBA69D99B@t-rg.ws> Message-ID: On 3/25/25 7:59 AM, fsLeg wrote: > Here are some READMEs for the programs SlackBuilds for which I maintain: > > - popcorntime: > - dart-sass: > - shadowsocks-rust: > > So I'm supposed to include these walls of text with ungodly amount of irrelevant information as the script's README? I'd rather copy some relevant short excerpt that describes the piece of software in question and be done with that. If anyone really wants the entire README, it's copied to /usr/doc by the SlackBuild anyway. 'Wall of text' is a false propaganda concept popularized by anti-intellectuals of The Illiterati.? SlackBuilds.org templates have a length, so yes, can be 'relevant length' even if a few upstream READMEs (probably not most... becoming more common to by short or nonexistent) are longer than the template. > SBo is a repository of build scripts, not programs themselves. You don't see walls of text in, say, Debian's package descriptions. Those are of varying lengths, but never too long. > > Should READMEs on SBo be more descriptive? Probably. But some developers don't provide a concise description of their programs [...] They all do for first line in sbopkg menu. > or it's way too concise, so the only way of having a more descriptive README would be to write it yourself, and how many maintainers would be willing to do that? It's like writing documentation, almost nobody likes to do that. It's not like writing documentation: look how much larger an average software manual (printed) or even manpage is. > I think the idea is that a user would already know what program they need, README would be just to confirm it's the right one. How many people just browse a repo looking for programs to try instead of just googling/knowing something they need and then looking if it's there? Especially a third-party unofficial repo. Also, a lot of packages are just dependencies, not many people care what they do by themselves. Do those need descriptive READMEs? I'd guess that's mostly nonsense; many people find most their programs in software managers including programs to run build scripts, such as sbopkg: I do this weekly.? Most what I installed I found in sbopkg, not by finding a webpage for software I don't even know exists, which only happened in rare cases.? For third-party repositories (such as slackers.it and quasi-official alienBOB & RLWorkman's ones (them being Slackware team members)) it's even more the case that I look in repositories to find/know what I want to try.? Dependencies need READMEs just as much as what they depend on, because people may read all lines in sbopkg (I did originally and maybe once/year, and all updates, or at least searching through for 'added') and it's common to add software depending on those, or even just write a program depending on them; a large number of dependencies have software using them by multiple maintainers, and I occasionally install libraries/APIs I want to try, and made a SlackBuild of a library (though it has test software). From willysr at slackbuilds.org Tue Mar 25 16:16:38 2025 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Tue, 25 Mar 2025 23:16:38 +0700 Subject: [Slackbuilds-users] new maintainers omitting READMEs In-Reply-To: References: <30287fc0-7c1e-a052-3ad3-c487dffaec71@gmail.com> <948530ae-0a9d-4463-8d65-612775728395@slackbuilds.org> <65d68735-a045-4515-b79b-6e5de8d7287a@slackbuilds.org> Message-ID: > Speak for yourself: I built 1,500+ SBo packages, and a few other people > use almost as many or maybe more.? README is enough when it's more than > terse one-liner--following template--historically using entirety of > upstream README.* except URL.? One-liner is for sbopkg menu, not > substituting for README, which is just sloppy/lazy/unprofessional, > including some use jargon so one must hunt down README to find out what > the software even is (let alone if one wants/needs it)... maintainers > could take a minute or two to copy that in instead of wasting minutes of > thousands people forever (often finding the software isn't something > they want/need). Did ALL those 1500+ packages landed on SBo? I'm sure it should be less than that. If you want to keep your README long and include all the details, be my guess, but keep it in your repository. Don't force your way of preferences into others where most people are happy with the current README works now. We are talking about SBo in context right? Why does this include sbopkg which is NOT part of SBo project at all It's just a third party tool that helps people to build script taken from SBo to native Slackware packages. >> at least they know what this script is all about > Not at all; not descriptive enough, including some use jargon. > >> if they need more information on how to use, they should follow >> upstream documentation for more detailed information > Upstream README.* should be README, because it's more information on > what a piece of software even is. Well, that's true, but you don't have to include the WHOLE README right? At least you know what this script is and besides, you can see the homepage URL in each of the script page. That gives you idea about where to find more information about the script is all about. -- 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 Tue Mar 25 16:23:37 2025 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Tue, 25 Mar 2025 23:23:37 +0700 Subject: [Slackbuilds-users] new maintainers omitting READMEs In-Reply-To: References: <30287fc0-7c1e-a052-3ad3-c487dffaec71@gmail.com> <948530ae-0a9d-4463-8d65-612775728395@slackbuilds.org> <65d68735-a045-4515-b79b-6e5de8d7287a@slackbuilds.org> <7F3B6473-346C-4CF8-8F07-37CFBA69D99B@t-rg.ws> Message-ID: <63f57b44-f3a2-46d1-913f-6614c2422ac1@slackbuilds.org> >> Should READMEs on SBo be more descriptive? Probably. But some >> developers don't provide a concise description of their programs [...] > They all do for first line in sbopkg menu. sbopkg is designed to help you build the source into native Slackware packages, not to help you READ the DETAIL of the script. > I'd guess that's mostly nonsense; many people find most their programs > in software managers including programs to run build scripts, such as > sbopkg: I do this weekly.? Most what I installed I found in sbopkg, not > by finding a webpage for software I don't even know exists, which only > happened in rare cases.? For third-party repositories (such as > slackers.it and quasi-official alienBOB & RLWorkman's ones (them being > Slackware team members)) it's even more the case that I look in > repositories to find/know what I want to try.? Dependencies need READMEs > just as much as what they depend on, because people may read all lines > in sbopkg (I did originally and maybe once/year, and all updates, or at > least searching through for 'added') and it's common to add software > depending on those, or even just write a program depending on them; a > large number of dependencies have software using them by multiple > maintainers, and I occasionally install libraries/APIs I want to try, > and made a SlackBuild of a library (though it has test software). Again, we are talking about 2 different things SBo is the repository that contains all the READMEs, while sbopkg is just a third party tool outside of SBo. Just browse the SBo website for information and use sbopkg (or any other third party tool) to build it. That should solve your problem. -- 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 Tue Mar 25 22:48:49 2025 From: urchlay at slackware.uk (B. Watson) Date: Tue, 25 Mar 2025 18:48:49 -0400 (EDT) Subject: [Slackbuilds-users] new maintainers omitting READMEs In-Reply-To: <63f57b44-f3a2-46d1-913f-6614c2422ac1@slackbuilds.org> References: <30287fc0-7c1e-a052-3ad3-c487dffaec71@gmail.com> <948530ae-0a9d-4463-8d65-612775728395@slackbuilds.org> <65d68735-a045-4515-b79b-6e5de8d7287a@slackbuilds.org> <7F3B6473-346C-4CF8-8F07-37CFBA69D99B@t-rg.ws> <63f57b44-f3a2-46d1-913f-6614c2422ac1@slackbuilds.org> Message-ID: <3e3138d7-1844-e296-6e77-574a5f3b348d@slackware.uk> On Tue, 25 Mar 2025, Willy Sudiarto Raharjo wrote: >>> Should READMEs on SBo be more descriptive? Probably. But some developers >>> don't provide a concise description of their programs [...] >> They all do for first line in sbopkg menu. > > sbopkg is designed to help you build the source into native Slackware > packages, not to help you READ the DETAIL of the script. Huh? It does both. When you select a package in sbopkg, the first menu item is "README", "View the README file". Also the next 3 options are "View the .info file", "View the SlackBuild file", and "Choose any file to display". > Just browse the SBo website for information and use sbopkg (or any other > third party tool) to build it. That should solve your problem. The same information is available in sbopkg, I think people can be excused for viewing it in sbopkg instead of using a separate app like a browser. The OP's complaint isn't really about sbopkg, it's about READMEs in the SBo repo that are short on detail. He's used to looking at the READMEs in sbopkg, so that's how he phrased it... but the same would apply to looking at the READMEs on the web site or in a git clone of the repo. I agree, READMEs should explain what the software is/does. They don't have to go into great detail, but they should usually be longer than one line. And yes, if upstream doesn't provide any documentation, that means the SBo maintainer should write a useful README. It's not hard to do: presumably if you're packaging the software, you *know* what it is and what it's for. Just a few of lines of text is all you need. As a first approximation, cd into the local git/rsync copy of the repo and run: find . -name README -a -size -80c However, not all of these READMEs need to be expanded. An example: $ cat ./audio/xmms-pulse/README xmms-pulse is an XMMS output plugin for the PulseAudio sound server. That's pretty short, but it does say exactly what the software is. I might have added a line or two about how to enable it in the XMMS GUI, but that's not really required for a SBo README. Presumably the package's /usr/doc documentation will explain this. Also, presumably, it would be obvious how to enable it, once you're looking at the XMMS GUI (ease-of-use is supposed to be the whole point of a GUI). From erich.public at protonmail.com Wed Mar 26 17:31:34 2025 From: erich.public at protonmail.com (Erich Ritz) Date: Wed, 26 Mar 2025 17:31:34 +0000 Subject: [Slackbuilds-users] office/pandoc-bin update changed webkit2gtk4.1 SlackBuild Message-ID: Hello Andrew and Willy, Commit e89ec01 "office/pandoc-bin: Updated for version 3.6.4" modified libraries/webkit2gtk4.1/webkit2gtk4.1.SlackBuild - see: https://git.slackbuilds.org/slackbuilds/commit/?id=e89ec01d22bded8cb443dc11a24cfdd2a6d7a445 Was this intentional? Erich From willysr at slackbuilds.org Thu Mar 27 00:56:27 2025 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Thu, 27 Mar 2025 07:56:27 +0700 Subject: [Slackbuilds-users] office/pandoc-bin update changed webkit2gtk4.1 SlackBuild In-Reply-To: References: Message-ID: <95c45d86-4c61-4975-8d60-73fcdadc3116@slackbuilds.org> > Hello Andrew and Willy, > > Commit e89ec01 "office/pandoc-bin: Updated for version 3.6.4" modified libraries/webkit2gtk4.1/webkit2gtk4.1.SlackBuild - see: > > https://git.slackbuilds.org/slackbuilds/commit/?id=e89ec01d22bded8cb443dc11a24cfdd2a6d7a445 > > Was this intentional? No, it was a mistake on my part i will fix it soon thanks for spotting it -- 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 Mar 29 01:46:48 2025 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sat, 29 Mar 2025 08:46:48 +0700 Subject: [Slackbuilds-users] Updates - 20250329.1 Message-ID: <68ad9cc3-2190-480f-bc54-8bd032bffdc0@slackbuilds.org> Sat Mar 29 01:40:26 UTC 2025 academic/TreeGraph: Removed (upstream source is gone). academic/qtdmm: Added (Simple DMM). audio/deadbeef: Updated for version 1.10.0 desktop/ClamAV-GUI: Updated for version 1.1.1 desktop/human-gtk-theme: Added (GTK Theme). desktop/nwg-clipman: Updated for version 0.2.5. desktop/nwg-displays: Updated for version 0.3.25. desktop/nwg-hello: Updated for version 0.3.1. desktop/nwg-shell: Updated for version 0.5.47. development/abseil-cpp: Version bump to 20250127.1 development/apache-ant: Updated for version 1.10.15. development/apache-ivy: Updated for version 2.5.3. development/apache-jmeter: Updated for version 5.6.3. development/aws-cdk: Updated for version 2.1006.0. development/diffoscope: updated for version 291 development/github-cli: Updated for version 2.69.0 development/google-go-lang: Updated for version 1.24.1. development/ispc: Patch to build with llvm 20.x. development/ispc: Update README to note new llvm in extra. development/mawk: Updated for version 1.3.4_20250131. development/pnpm: Updated for version 10.6.5. development/postman: Updated for version 11.37.5 development/rarian: Updated for version 0.8.6. development/sourcegit: Updated for version 2025.10. development/spyder: Clarify commenting on python3-spyder-kernels version restriction development/terraform: Updated for version 1.11.3. development/tkman: allow tkman to accept cli parameters development/vstudio: Updated for version 15.1.2 development/witsy: Updated for version 2.4.1 development/xnedit: Updated for version 1.6.3 development/yabasic: Updated for version 2.91.2 games/FlightGear-data: Removed (included in FlightGear). games/fgrun: Removed (FTBFS and upstream inactive). games/nestopia: Updated for version 1.53.1 gis/Fiona: Update for 1.10.1 graphics/blender: Version bump to 4.4.0 graphics/converseen: Updated for version 0.13.0.1. graphics/gifsicle: Updated for version 1.96. graphics/img2pdf: Revert to 0.5.1 (for fixing runtime error) graphics/qiv: Updated for version 2.3.4. ham/xdx: Updated for version 2.91. libraries/imlib2: Updated for version 1.12.4. libraries/libmediainfo: Version bump to 25.03 libraries/libtpms: Updated for version 0.10.0. libraries/ospray: Update README to note new llvm in extra. libraries/qt-avif-image-plugin: Updated for version 0.9.2. libraries/qt-installer-script: Updated for version 4.9.0 libraries/robin-map: Updated for version 1.3.0 libraries/tinyxml2: Version bump to 11.0.0 libraries/webkit2gtk4.1: Revert changes for next webkit2gtk4.1. misc/ibus-rime: Added (Rime Input Method Engine). misc/yubioath-desktop: Updated for version 7.2.0. multimedia/MediathekView: Updated for version 14.2.0. multimedia/mediainfo: Version bump to 25.03 multimedia/muse-sounds-manager: Updated for version 2.0.3.659 multimedia/pipe-viewer: Patch to fix "Bad request". multimedia/youtube-music: Updated for version 3.8.0. network/anydesk: Updated for version 6.4.2. network/brave-browser: updated for version 1.76.82 network/broadcom-wl: Added patch to support kernel 6.14. network/discord: Version bump to 0.0.89 network/grafana: Updated for version 11.6.0. network/holehe: Added (Email Audit). network/landrun: Added (Secure Sandbox). network/lighttpd: Updated for version 1.4.78. network/luakit: Updated for version 2.4.0. network/mod_bw: Update homepage and source URL. network/mullvadvpn-app: Updated for version 2025.5. network/nextcloud-server: Updated for version 29.0.14. network/resilio-sync: Fix conflict with CI. network/resilio-sync: Updated for version 3.0.3.1065. network/rustdesk: Updated for version 1.3.8. network/signal-desktop: Updated for version 7.48.0. network/tailscale: updated for version 1.82.0 network/telegram: Updated for version 5.13.0. network/telegram: Updated for version 5.13.1. network/vivaldi: Updated for version 7.3.3635.2. network/waterfox: Updated for version 6.5.6 network/yt-dlp-bin: Updated for version 2025.03.27. network/yt-dlp: Updated for version 2025.03.27. network/zoom-linux: Updated for 6.4.1.587 office/LibreOffice: Updated for version 25.2.2.1 office/ishmael: Updated for version 1.03. office/libreoffice-helppack: Updated for version 25.2.2. office/libreoffice-langpack: Updated for version 25.2.2. office/libreoffice: Updated for version 25.2.2. office/miktex: Updated for version 25.3 office/smoffice2024: Updated for version 2024_1224 office/typobuster: Updated for version 1.0.0. office/xournalpp: Updated for version 1.2.6. python/python3-anyio: Version bump to 4.9.0 python/python3-auditok: Added (Audio activity detection tool). python/python3-expandvars: Updated for version 1.0.0. python/python3-ffsubsync: Added (Language-agnostic automatic synchronization). python/python3-ffsubsync: Fix MD5SUM. python/python3-filelock: Version bump to 3.18.0 python/python3-iniconfig: Version bump to 2.1.0 python/python3-platformdirs: Version bump to 4.3.7 python/python3-poetry-dynamic-versioning: Updated for version 1.8.2. python/python3-statsmodels: Edit README (+update homepage) python/python3-unearth: Version bump to 0.17.3 ruby/ruby-build: Update for version 20250326. system/FreeFileSync: Updated for version 14.3 system/TLP: Update script. system/android-udev-rules: Updated for version 2025.03.14. system/apache-tomcat: Updated for version 10.1.39. system/brave-browser-the-latest: Updated for version 1.3 system/c-lcrypt: Updated for version 4.0.0. system/convmv: Updated for version 2.06. system/doublecmd-qt5: Updated for version 1.1.23 system/firejail: Updated for version 0.9.74. system/fonts-bengali-extra: Update README system/fonts-ethiopic-extra: Added (Ethiopic fonts). system/fonts-famil-tva: Update README system/fonts-indic-archaic: Update README system/fonts-kannada-extra: Update README system/fonts-malayalam-extra: Update README system/fonts-oriya-extra: Update README system/fonts-tamil-bharathi: Update README system/fonts-tamil-libre: Update README system/fonts-telugu-extra: Update README system/google-chrome-the-latest: Updated for version 4.1 system/incus: Updated for version 6.11 system/mount-zip: Updated for version 1.8. system/netdata: Updated for version 2.3.1. system/nvidia-legacy470-kernel: Update script. system/p7zip: Updated for version 17.05. system/sbotools: Updated for version 3.5. system/scrypt: Updated for version 1.3.3. system/swtpm: Updated for version 0.10.0. system/telegraf: Updated for version 1.34.1 +--------------------------+ -- 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 1.41421 at gmail.com Sat Mar 29 16:37:27 2025 From: 1.41421 at gmail.com (Luveh Keraph) Date: Sat, 29 Mar 2025 10:37:27 -0600 Subject: [Slackbuilds-users] Updates - 20250329.1 In-Reply-To: <68ad9cc3-2190-480f-bc54-8bd032bffdc0@slackbuilds.org> References: <68ad9cc3-2190-480f-bc54-8bd032bffdc0@slackbuilds.org> Message-ID: These updates have broken two items for me: * xpdf: It displays diagrams and pictures in PDF files, but not the text. Okular still does the right thing. * Signal: When invoked from the command line it returns the following diagnostic: A JavaScript error occurred in the main process Uncaught Exception: Error: Cannot find module 'fs-extra' Require stack: - /opt/Signal/resources/app.asar/app/main.js - at Module._resolveFilename (node:internal/modules/cjs/loader:1232:15) at s._resolveFilename (node:electron/js2c/browser_init:2:129170) at Module._load (node:internal/modules/cjs/loader:1062:27) at c._load (node:electron/js2c/node_init:2:18008) at TracingChannel.traceSync (node:diagnostics_channel:322:14) at wrapModuleLoad (node:internal/modules/cjs/loader:227:24) at Module.require (node:internal/modules/cjs/loader:1318:12) at require (node:internal/modules/helpers:136:16) at Object. (/opt/Signal/resources/app.asar/app/main.js:38:23) at Module._compile (node:internal/modules/cjs/loader:1569:14) And then it just hangs there indefinitely. On Fri, Mar 28, 2025 at 7:46?PM Willy Sudiarto Raharjo < willysr at slackbuilds.org> wrote: > Sat Mar 29 01:40:26 UTC 2025 > academic/TreeGraph: Removed (upstream source is gone). > academic/qtdmm: Added (Simple DMM). > audio/deadbeef: Updated for version 1.10.0 > desktop/ClamAV-GUI: Updated for version 1.1.1 > desktop/human-gtk-theme: Added (GTK Theme). > desktop/nwg-clipman: Updated for version 0.2.5. > desktop/nwg-displays: Updated for version 0.3.25. > desktop/nwg-hello: Updated for version 0.3.1. > desktop/nwg-shell: Updated for version 0.5.47. > development/abseil-cpp: Version bump to 20250127.1 > development/apache-ant: Updated for version 1.10.15. > development/apache-ivy: Updated for version 2.5.3. > development/apache-jmeter: Updated for version 5.6.3. > development/aws-cdk: Updated for version 2.1006.0. > development/diffoscope: updated for version 291 > development/github-cli: Updated for version 2.69.0 > development/google-go-lang: Updated for version 1.24.1. > development/ispc: Patch to build with llvm 20.x. > development/ispc: Update README to note new llvm in extra. > development/mawk: Updated for version 1.3.4_20250131. > development/pnpm: Updated for version 10.6.5. > development/postman: Updated for version 11.37.5 > development/rarian: Updated for version 0.8.6. > development/sourcegit: Updated for version 2025.10. > development/spyder: Clarify commenting on python3-spyder-kernels version > restriction > development/terraform: Updated for version 1.11.3. > development/tkman: allow tkman to accept cli parameters > development/vstudio: Updated for version 15.1.2 > development/witsy: Updated for version 2.4.1 > development/xnedit: Updated for version 1.6.3 > development/yabasic: Updated for version 2.91.2 > games/FlightGear-data: Removed (included in FlightGear). > games/fgrun: Removed (FTBFS and upstream inactive). > games/nestopia: Updated for version 1.53.1 > gis/Fiona: Update for 1.10.1 > graphics/blender: Version bump to 4.4.0 > graphics/converseen: Updated for version 0.13.0.1. > graphics/gifsicle: Updated for version 1.96. > graphics/img2pdf: Revert to 0.5.1 (for fixing runtime error) > graphics/qiv: Updated for version 2.3.4. > ham/xdx: Updated for version 2.91. > libraries/imlib2: Updated for version 1.12.4. > libraries/libmediainfo: Version bump to 25.03 > libraries/libtpms: Updated for version 0.10.0. > libraries/ospray: Update README to note new llvm in extra. > libraries/qt-avif-image-plugin: Updated for version 0.9.2. > libraries/qt-installer-script: Updated for version 4.9.0 > libraries/robin-map: Updated for version 1.3.0 > libraries/tinyxml2: Version bump to 11.0.0 > libraries/webkit2gtk4.1: Revert changes for next webkit2gtk4.1. > misc/ibus-rime: Added (Rime Input Method Engine). > misc/yubioath-desktop: Updated for version 7.2.0. > multimedia/MediathekView: Updated for version 14.2.0. > multimedia/mediainfo: Version bump to 25.03 > multimedia/muse-sounds-manager: Updated for version 2.0.3.659 > multimedia/pipe-viewer: Patch to fix "Bad request". > multimedia/youtube-music: Updated for version 3.8.0. > network/anydesk: Updated for version 6.4.2. > network/brave-browser: updated for version 1.76.82 > network/broadcom-wl: Added patch to support kernel 6.14. > network/discord: Version bump to 0.0.89 > network/grafana: Updated for version 11.6.0. > network/holehe: Added (Email Audit). > network/landrun: Added (Secure Sandbox). > network/lighttpd: Updated for version 1.4.78. > network/luakit: Updated for version 2.4.0. > network/mod_bw: Update homepage and source URL. > network/mullvadvpn-app: Updated for version 2025.5. > network/nextcloud-server: Updated for version 29.0.14. > network/resilio-sync: Fix conflict with CI. > network/resilio-sync: Updated for version 3.0.3.1065. > network/rustdesk: Updated for version 1.3.8. > network/signal-desktop: Updated for version 7.48.0. > network/tailscale: updated for version 1.82.0 > network/telegram: Updated for version 5.13.0. > network/telegram: Updated for version 5.13.1. > network/vivaldi: Updated for version 7.3.3635.2. > network/waterfox: Updated for version 6.5.6 > network/yt-dlp-bin: Updated for version 2025.03.27. > network/yt-dlp: Updated for version 2025.03.27. > network/zoom-linux: Updated for 6.4.1.587 > office/LibreOffice: Updated for version 25.2.2.1 > office/ishmael: Updated for version 1.03. > office/libreoffice-helppack: Updated for version 25.2.2. > office/libreoffice-langpack: Updated for version 25.2.2. > office/libreoffice: Updated for version 25.2.2. > office/miktex: Updated for version 25.3 > office/smoffice2024: Updated for version 2024_1224 > office/typobuster: Updated for version 1.0.0. > office/xournalpp: Updated for version 1.2.6. > python/python3-anyio: Version bump to 4.9.0 > python/python3-auditok: Added (Audio activity detection tool). > python/python3-expandvars: Updated for version 1.0.0. > python/python3-ffsubsync: Added (Language-agnostic automatic > synchronization). > python/python3-ffsubsync: Fix MD5SUM. > python/python3-filelock: Version bump to 3.18.0 > python/python3-iniconfig: Version bump to 2.1.0 > python/python3-platformdirs: Version bump to 4.3.7 > python/python3-poetry-dynamic-versioning: Updated for version 1.8.2. > python/python3-statsmodels: Edit README (+update homepage) > python/python3-unearth: Version bump to 0.17.3 > ruby/ruby-build: Update for version 20250326. > system/FreeFileSync: Updated for version 14.3 > system/TLP: Update script. > system/android-udev-rules: Updated for version 2025.03.14. > system/apache-tomcat: Updated for version 10.1.39. > system/brave-browser-the-latest: Updated for version 1.3 > system/c-lcrypt: Updated for version 4.0.0. > system/convmv: Updated for version 2.06. > system/doublecmd-qt5: Updated for version 1.1.23 > system/firejail: Updated for version 0.9.74. > system/fonts-bengali-extra: Update README > system/fonts-ethiopic-extra: Added (Ethiopic fonts). > system/fonts-famil-tva: Update README > system/fonts-indic-archaic: Update README > system/fonts-kannada-extra: Update README > system/fonts-malayalam-extra: Update README > system/fonts-oriya-extra: Update README > system/fonts-tamil-bharathi: Update README > system/fonts-tamil-libre: Update README > system/fonts-telugu-extra: Update README > system/google-chrome-the-latest: Updated for version 4.1 > system/incus: Updated for version 6.11 > system/mount-zip: Updated for version 1.8. > system/netdata: Updated for version 2.3.1. > system/nvidia-legacy470-kernel: Update script. > system/p7zip: Updated for version 17.05. > system/sbotools: Updated for version 3.5. > system/scrypt: Updated for version 1.3.3. > system/swtpm: Updated for version 0.10.0. > system/telegraf: Updated for version 1.34.1 > +--------------------------+ > > > -- > Willy Sudiarto Raharjo > > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - https://slackbuilds.org/faq/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From 1.41421 at gmail.com Sat Mar 29 16:47:33 2025 From: 1.41421 at gmail.com (Luveh Keraph) Date: Sat, 29 Mar 2025 10:47:33 -0600 Subject: [Slackbuilds-users] Updates - 20250329.1 In-Reply-To: References: <68ad9cc3-2190-480f-bc54-8bd032bffdc0@slackbuilds.org> Message-ID: These are the packages that I updated - before I updated them both xpdf and Signal were working fine: expat-2.7.1-x86_64-1_slack15.0 abseil-cpp-20250127.1-x86_64-1_SBo anydesk-6.4.2-x86_64-1_SBo brave-browser-1.76.82-x86_64-1_SBo gifsicle-1.96-x86_64-1_SBo google-go-lang-1.24.1-x86_64-1_SBo imlib2-1.12.4-x86_64-1_SBo libmediainfo-25.03-x86_64-1_SBo libreoffice-25.2.2-x86_64-1_SBo libtpms-0.10.0-x86_64-1_SBo mediainfo-25.03-x86_64-1_SBo netdata-2.3.1-x86_64-1_SBo nextcloud-server-29.0.14-noarch-1_SBo p7zip-17.05-x86_64-1_SBo sbotools-3.5-noarch-1_SBo signal-desktop-7.48.0-x86_64-1_SBo tinyxml2-11.0.0-x86_64-1_SBo vivaldi-7.3.3635.2-x86_64-1_SBo yt-dlp-2025.03.27-x86_64-1_SBo zoom-linux-6.4.1.587-x86_64-1_SBo On Sat, Mar 29, 2025 at 10:37?AM Luveh Keraph <1.41421 at gmail.com> wrote: > These updates have broken two items for me: > > * xpdf: It displays diagrams and pictures in PDF files, but not the > text. Okular still does the right thing. > * Signal: When invoked from the command line it returns the following > diagnostic: > > A JavaScript error occurred in the main process > Uncaught Exception: > Error: Cannot find module 'fs-extra' > Require stack: > - /opt/Signal/resources/app.asar/app/main.js > - > at Module._resolveFilename (node:internal/modules/cjs/loader:1232:15) > at s._resolveFilename (node:electron/js2c/browser_init:2:129170) > at Module._load (node:internal/modules/cjs/loader:1062:27) > at c._load (node:electron/js2c/node_init:2:18008) > at TracingChannel.traceSync (node:diagnostics_channel:322:14) > at wrapModuleLoad (node:internal/modules/cjs/loader:227:24) > at Module.require (node:internal/modules/cjs/loader:1318:12) > at require (node:internal/modules/helpers:136:16) > at Object. > (/opt/Signal/resources/app.asar/app/main.js:38:23) > at Module._compile (node:internal/modules/cjs/loader:1569:14) > > And then it just hangs there indefinitely. > > > On Fri, Mar 28, 2025 at 7:46?PM Willy Sudiarto Raharjo < > willysr at slackbuilds.org> wrote: > >> Sat Mar 29 01:40:26 UTC 2025 >> academic/TreeGraph: Removed (upstream source is gone). >> academic/qtdmm: Added (Simple DMM). >> audio/deadbeef: Updated for version 1.10.0 >> desktop/ClamAV-GUI: Updated for version 1.1.1 >> desktop/human-gtk-theme: Added (GTK Theme). >> desktop/nwg-clipman: Updated for version 0.2.5. >> desktop/nwg-displays: Updated for version 0.3.25. >> desktop/nwg-hello: Updated for version 0.3.1. >> desktop/nwg-shell: Updated for version 0.5.47. >> development/abseil-cpp: Version bump to 20250127.1 >> development/apache-ant: Updated for version 1.10.15. >> development/apache-ivy: Updated for version 2.5.3. >> development/apache-jmeter: Updated for version 5.6.3. >> development/aws-cdk: Updated for version 2.1006.0. >> development/diffoscope: updated for version 291 >> development/github-cli: Updated for version 2.69.0 >> development/google-go-lang: Updated for version 1.24.1. >> development/ispc: Patch to build with llvm 20.x. >> development/ispc: Update README to note new llvm in extra. >> development/mawk: Updated for version 1.3.4_20250131. >> development/pnpm: Updated for version 10.6.5. >> development/postman: Updated for version 11.37.5 >> development/rarian: Updated for version 0.8.6. >> development/sourcegit: Updated for version 2025.10. >> development/spyder: Clarify commenting on python3-spyder-kernels version >> restriction >> development/terraform: Updated for version 1.11.3. >> development/tkman: allow tkman to accept cli parameters >> development/vstudio: Updated for version 15.1.2 >> development/witsy: Updated for version 2.4.1 >> development/xnedit: Updated for version 1.6.3 >> development/yabasic: Updated for version 2.91.2 >> games/FlightGear-data: Removed (included in FlightGear). >> games/fgrun: Removed (FTBFS and upstream inactive). >> games/nestopia: Updated for version 1.53.1 >> gis/Fiona: Update for 1.10.1 >> graphics/blender: Version bump to 4.4.0 >> graphics/converseen: Updated for version 0.13.0.1. >> graphics/gifsicle: Updated for version 1.96. >> graphics/img2pdf: Revert to 0.5.1 (for fixing runtime error) >> graphics/qiv: Updated for version 2.3.4. >> ham/xdx: Updated for version 2.91. >> libraries/imlib2: Updated for version 1.12.4. >> libraries/libmediainfo: Version bump to 25.03 >> libraries/libtpms: Updated for version 0.10.0. >> libraries/ospray: Update README to note new llvm in extra. >> libraries/qt-avif-image-plugin: Updated for version 0.9.2. >> libraries/qt-installer-script: Updated for version 4.9.0 >> libraries/robin-map: Updated for version 1.3.0 >> libraries/tinyxml2: Version bump to 11.0.0 >> libraries/webkit2gtk4.1: Revert changes for next webkit2gtk4.1. >> misc/ibus-rime: Added (Rime Input Method Engine). >> misc/yubioath-desktop: Updated for version 7.2.0. >> multimedia/MediathekView: Updated for version 14.2.0. >> multimedia/mediainfo: Version bump to 25.03 >> multimedia/muse-sounds-manager: Updated for version 2.0.3.659 >> multimedia/pipe-viewer: Patch to fix "Bad request". >> multimedia/youtube-music: Updated for version 3.8.0. >> network/anydesk: Updated for version 6.4.2. >> network/brave-browser: updated for version 1.76.82 >> network/broadcom-wl: Added patch to support kernel 6.14. >> network/discord: Version bump to 0.0.89 >> network/grafana: Updated for version 11.6.0. >> network/holehe: Added (Email Audit). >> network/landrun: Added (Secure Sandbox). >> network/lighttpd: Updated for version 1.4.78. >> network/luakit: Updated for version 2.4.0. >> network/mod_bw: Update homepage and source URL. >> network/mullvadvpn-app: Updated for version 2025.5. >> network/nextcloud-server: Updated for version 29.0.14. >> network/resilio-sync: Fix conflict with CI. >> network/resilio-sync: Updated for version 3.0.3.1065. >> network/rustdesk: Updated for version 1.3.8. >> network/signal-desktop: Updated for version 7.48.0. >> network/tailscale: updated for version 1.82.0 >> network/telegram: Updated for version 5.13.0. >> network/telegram: Updated for version 5.13.1. >> network/vivaldi: Updated for version 7.3.3635.2. >> network/waterfox: Updated for version 6.5.6 >> network/yt-dlp-bin: Updated for version 2025.03.27. >> network/yt-dlp: Updated for version 2025.03.27. >> network/zoom-linux: Updated for 6.4.1.587 >> office/LibreOffice: Updated for version 25.2.2.1 >> office/ishmael: Updated for version 1.03. >> office/libreoffice-helppack: Updated for version 25.2.2. >> office/libreoffice-langpack: Updated for version 25.2.2. >> office/libreoffice: Updated for version 25.2.2. >> office/miktex: Updated for version 25.3 >> office/smoffice2024: Updated for version 2024_1224 >> office/typobuster: Updated for version 1.0.0. >> office/xournalpp: Updated for version 1.2.6. >> python/python3-anyio: Version bump to 4.9.0 >> python/python3-auditok: Added (Audio activity detection tool). >> python/python3-expandvars: Updated for version 1.0.0. >> python/python3-ffsubsync: Added (Language-agnostic automatic >> synchronization). >> python/python3-ffsubsync: Fix MD5SUM. >> python/python3-filelock: Version bump to 3.18.0 >> python/python3-iniconfig: Version bump to 2.1.0 >> python/python3-platformdirs: Version bump to 4.3.7 >> python/python3-poetry-dynamic-versioning: Updated for version 1.8.2. >> python/python3-statsmodels: Edit README (+update homepage) >> python/python3-unearth: Version bump to 0.17.3 >> ruby/ruby-build: Update for version 20250326. >> system/FreeFileSync: Updated for version 14.3 >> system/TLP: Update script. >> system/android-udev-rules: Updated for version 2025.03.14. >> system/apache-tomcat: Updated for version 10.1.39. >> system/brave-browser-the-latest: Updated for version 1.3 >> system/c-lcrypt: Updated for version 4.0.0. >> system/convmv: Updated for version 2.06. >> system/doublecmd-qt5: Updated for version 1.1.23 >> system/firejail: Updated for version 0.9.74. >> system/fonts-bengali-extra: Update README >> system/fonts-ethiopic-extra: Added (Ethiopic fonts). >> system/fonts-famil-tva: Update README >> system/fonts-indic-archaic: Update README >> system/fonts-kannada-extra: Update README >> system/fonts-malayalam-extra: Update README >> system/fonts-oriya-extra: Update README >> system/fonts-tamil-bharathi: Update README >> system/fonts-tamil-libre: Update README >> system/fonts-telugu-extra: Update README >> system/google-chrome-the-latest: Updated for version 4.1 >> system/incus: Updated for version 6.11 >> system/mount-zip: Updated for version 1.8. >> system/netdata: Updated for version 2.3.1. >> system/nvidia-legacy470-kernel: Update script. >> system/p7zip: Updated for version 17.05. >> system/sbotools: Updated for version 3.5. >> system/scrypt: Updated for version 1.3.3. >> system/swtpm: Updated for version 0.10.0. >> system/telegraf: Updated for version 1.34.1 >> +--------------------------+ >> >> >> -- >> Willy Sudiarto Raharjo >> >> _______________________________________________ >> SlackBuilds-users mailing list >> SlackBuilds-users at slackbuilds.org >> https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users >> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ >> FAQ - https://slackbuilds.org/faq/ >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From 414N at slacky.it Sat Mar 29 17:32:19 2025 From: 414N at slacky.it (414N) Date: Sat, 29 Mar 2025 18:32:19 +0100 Subject: [Slackbuilds-users] postman glibc issue In-Reply-To: References: Message-ID: Greetings, recent postman package upgrades are not compatible with Slackware 15.0, as they require a newer glibc (2.34). The last working version that I tested was 11.27.3. Does anyone have the same issue? I tried contacting the package maintainer for this issue (see the following) but I got no response back. -- Alan Alberghini -------- Messaggio Inoltrato -------- Oggetto: postman glibc issue Data: Mon, 24 Feb 2025 10:41:40 +0100 Mittente: 414N <414N at slacky.it> A: slackbuilds at dscp.org Greetings, I stumbled upon a glibc incompatibility issue with the latest postman package updates, as the later precompiled builds seem to require glibc-2.34, while Slackware 15.0 sports version 2.33: $ postman postman: /lib64/libc.so.6: version `GLIBC_2.34' not found (required by postman) The latest version of the package that I found working is version 11.27.3. Maybe a downgrade is needed? Kindest regards -- Alan Alberghini SBo clone: https://github.com/414n/slackbuilds.org From 1.41421 at gmail.com Sat Mar 29 18:25:08 2025 From: 1.41421 at gmail.com (Luveh Keraph) Date: Sat, 29 Mar 2025 12:25:08 -0600 Subject: [Slackbuilds-users] Updates - 20250329.1 In-Reply-To: References: <68ad9cc3-2190-480f-bc54-8bd032bffdc0@slackbuilds.org> Message-ID: Another thing I have just noticed: after successfully upgrading the packages listed above by means of sboupgrade --all the permissions of my /tmp directory changed from drwxrwxrwt to drwxr-xr-x. This happened in several Slackware 15.0 systems where the upgrades (not all the same as listed above though) were made. I don't know whether this is sboupgrade's fault or else the doing of some particular package build script. On Sat, Mar 29, 2025 at 10:47?AM Luveh Keraph <1.41421 at gmail.com> wrote: > These are the packages that I updated - before I updated them both xpdf > and Signal were working fine: > > expat-2.7.1-x86_64-1_slack15.0 > abseil-cpp-20250127.1-x86_64-1_SBo > anydesk-6.4.2-x86_64-1_SBo > brave-browser-1.76.82-x86_64-1_SBo > gifsicle-1.96-x86_64-1_SBo > google-go-lang-1.24.1-x86_64-1_SBo > imlib2-1.12.4-x86_64-1_SBo > libmediainfo-25.03-x86_64-1_SBo > libreoffice-25.2.2-x86_64-1_SBo > libtpms-0.10.0-x86_64-1_SBo > mediainfo-25.03-x86_64-1_SBo > netdata-2.3.1-x86_64-1_SBo > nextcloud-server-29.0.14-noarch-1_SBo > p7zip-17.05-x86_64-1_SBo > sbotools-3.5-noarch-1_SBo > signal-desktop-7.48.0-x86_64-1_SBo > tinyxml2-11.0.0-x86_64-1_SBo > vivaldi-7.3.3635.2-x86_64-1_SBo > yt-dlp-2025.03.27-x86_64-1_SBo > zoom-linux-6.4.1.587-x86_64-1_SBo > > On Sat, Mar 29, 2025 at 10:37?AM Luveh Keraph <1.41421 at gmail.com> wrote: > >> These updates have broken two items for me: >> >> * xpdf: It displays diagrams and pictures in PDF files, but not the >> text. Okular still does the right thing. >> * Signal: When invoked from the command line it returns the following >> diagnostic: >> >> A JavaScript error occurred in the main process >> Uncaught Exception: >> Error: Cannot find module 'fs-extra' >> Require stack: >> - /opt/Signal/resources/app.asar/app/main.js >> - >> at Module._resolveFilename (node:internal/modules/cjs/loader:1232:15) >> at s._resolveFilename (node:electron/js2c/browser_init:2:129170) >> at Module._load (node:internal/modules/cjs/loader:1062:27) >> at c._load (node:electron/js2c/node_init:2:18008) >> at TracingChannel.traceSync (node:diagnostics_channel:322:14) >> at wrapModuleLoad (node:internal/modules/cjs/loader:227:24) >> at Module.require (node:internal/modules/cjs/loader:1318:12) >> at require (node:internal/modules/helpers:136:16) >> at Object. >> (/opt/Signal/resources/app.asar/app/main.js:38:23) >> at Module._compile (node:internal/modules/cjs/loader:1569:14) >> >> And then it just hangs there indefinitely. >> >> >> On Fri, Mar 28, 2025 at 7:46?PM Willy Sudiarto Raharjo < >> willysr at slackbuilds.org> wrote: >> >>> Sat Mar 29 01:40:26 UTC 2025 >>> academic/TreeGraph: Removed (upstream source is gone). >>> academic/qtdmm: Added (Simple DMM). >>> audio/deadbeef: Updated for version 1.10.0 >>> desktop/ClamAV-GUI: Updated for version 1.1.1 >>> desktop/human-gtk-theme: Added (GTK Theme). >>> desktop/nwg-clipman: Updated for version 0.2.5. >>> desktop/nwg-displays: Updated for version 0.3.25. >>> desktop/nwg-hello: Updated for version 0.3.1. >>> desktop/nwg-shell: Updated for version 0.5.47. >>> development/abseil-cpp: Version bump to 20250127.1 >>> development/apache-ant: Updated for version 1.10.15. >>> development/apache-ivy: Updated for version 2.5.3. >>> development/apache-jmeter: Updated for version 5.6.3. >>> development/aws-cdk: Updated for version 2.1006.0. >>> development/diffoscope: updated for version 291 >>> development/github-cli: Updated for version 2.69.0 >>> development/google-go-lang: Updated for version 1.24.1. >>> development/ispc: Patch to build with llvm 20.x. >>> development/ispc: Update README to note new llvm in extra. >>> development/mawk: Updated for version 1.3.4_20250131. >>> development/pnpm: Updated for version 10.6.5. >>> development/postman: Updated for version 11.37.5 >>> development/rarian: Updated for version 0.8.6. >>> development/sourcegit: Updated for version 2025.10. >>> development/spyder: Clarify commenting on python3-spyder-kernels version >>> restriction >>> development/terraform: Updated for version 1.11.3. >>> development/tkman: allow tkman to accept cli parameters >>> development/vstudio: Updated for version 15.1.2 >>> development/witsy: Updated for version 2.4.1 >>> development/xnedit: Updated for version 1.6.3 >>> development/yabasic: Updated for version 2.91.2 >>> games/FlightGear-data: Removed (included in FlightGear). >>> games/fgrun: Removed (FTBFS and upstream inactive). >>> games/nestopia: Updated for version 1.53.1 >>> gis/Fiona: Update for 1.10.1 >>> graphics/blender: Version bump to 4.4.0 >>> graphics/converseen: Updated for version 0.13.0.1. >>> graphics/gifsicle: Updated for version 1.96. >>> graphics/img2pdf: Revert to 0.5.1 (for fixing runtime error) >>> graphics/qiv: Updated for version 2.3.4. >>> ham/xdx: Updated for version 2.91. >>> libraries/imlib2: Updated for version 1.12.4. >>> libraries/libmediainfo: Version bump to 25.03 >>> libraries/libtpms: Updated for version 0.10.0. >>> libraries/ospray: Update README to note new llvm in extra. >>> libraries/qt-avif-image-plugin: Updated for version 0.9.2. >>> libraries/qt-installer-script: Updated for version 4.9.0 >>> libraries/robin-map: Updated for version 1.3.0 >>> libraries/tinyxml2: Version bump to 11.0.0 >>> libraries/webkit2gtk4.1: Revert changes for next webkit2gtk4.1. >>> misc/ibus-rime: Added (Rime Input Method Engine). >>> misc/yubioath-desktop: Updated for version 7.2.0. >>> multimedia/MediathekView: Updated for version 14.2.0. >>> multimedia/mediainfo: Version bump to 25.03 >>> multimedia/muse-sounds-manager: Updated for version 2.0.3.659 >>> multimedia/pipe-viewer: Patch to fix "Bad request". >>> multimedia/youtube-music: Updated for version 3.8.0. >>> network/anydesk: Updated for version 6.4.2. >>> network/brave-browser: updated for version 1.76.82 >>> network/broadcom-wl: Added patch to support kernel 6.14. >>> network/discord: Version bump to 0.0.89 >>> network/grafana: Updated for version 11.6.0. >>> network/holehe: Added (Email Audit). >>> network/landrun: Added (Secure Sandbox). >>> network/lighttpd: Updated for version 1.4.78. >>> network/luakit: Updated for version 2.4.0. >>> network/mod_bw: Update homepage and source URL. >>> network/mullvadvpn-app: Updated for version 2025.5. >>> network/nextcloud-server: Updated for version 29.0.14. >>> network/resilio-sync: Fix conflict with CI. >>> network/resilio-sync: Updated for version 3.0.3.1065. >>> network/rustdesk: Updated for version 1.3.8. >>> network/signal-desktop: Updated for version 7.48.0. >>> network/tailscale: updated for version 1.82.0 >>> network/telegram: Updated for version 5.13.0. >>> network/telegram: Updated for version 5.13.1. >>> network/vivaldi: Updated for version 7.3.3635.2. >>> network/waterfox: Updated for version 6.5.6 >>> network/yt-dlp-bin: Updated for version 2025.03.27. >>> network/yt-dlp: Updated for version 2025.03.27. >>> network/zoom-linux: Updated for 6.4.1.587 >>> office/LibreOffice: Updated for version 25.2.2.1 >>> office/ishmael: Updated for version 1.03. >>> office/libreoffice-helppack: Updated for version 25.2.2. >>> office/libreoffice-langpack: Updated for version 25.2.2. >>> office/libreoffice: Updated for version 25.2.2. >>> office/miktex: Updated for version 25.3 >>> office/smoffice2024: Updated for version 2024_1224 >>> office/typobuster: Updated for version 1.0.0. >>> office/xournalpp: Updated for version 1.2.6. >>> python/python3-anyio: Version bump to 4.9.0 >>> python/python3-auditok: Added (Audio activity detection tool). >>> python/python3-expandvars: Updated for version 1.0.0. >>> python/python3-ffsubsync: Added (Language-agnostic automatic >>> synchronization). >>> python/python3-ffsubsync: Fix MD5SUM. >>> python/python3-filelock: Version bump to 3.18.0 >>> python/python3-iniconfig: Version bump to 2.1.0 >>> python/python3-platformdirs: Version bump to 4.3.7 >>> python/python3-poetry-dynamic-versioning: Updated for version 1.8.2. >>> python/python3-statsmodels: Edit README (+update homepage) >>> python/python3-unearth: Version bump to 0.17.3 >>> ruby/ruby-build: Update for version 20250326. >>> system/FreeFileSync: Updated for version 14.3 >>> system/TLP: Update script. >>> system/android-udev-rules: Updated for version 2025.03.14. >>> system/apache-tomcat: Updated for version 10.1.39. >>> system/brave-browser-the-latest: Updated for version 1.3 >>> system/c-lcrypt: Updated for version 4.0.0. >>> system/convmv: Updated for version 2.06. >>> system/doublecmd-qt5: Updated for version 1.1.23 >>> system/firejail: Updated for version 0.9.74. >>> system/fonts-bengali-extra: Update README >>> system/fonts-ethiopic-extra: Added (Ethiopic fonts). >>> system/fonts-famil-tva: Update README >>> system/fonts-indic-archaic: Update README >>> system/fonts-kannada-extra: Update README >>> system/fonts-malayalam-extra: Update README >>> system/fonts-oriya-extra: Update README >>> system/fonts-tamil-bharathi: Update README >>> system/fonts-tamil-libre: Update README >>> system/fonts-telugu-extra: Update README >>> system/google-chrome-the-latest: Updated for version 4.1 >>> system/incus: Updated for version 6.11 >>> system/mount-zip: Updated for version 1.8. >>> system/netdata: Updated for version 2.3.1. >>> system/nvidia-legacy470-kernel: Update script. >>> system/p7zip: Updated for version 17.05. >>> system/sbotools: Updated for version 3.5. >>> system/scrypt: Updated for version 1.3.3. >>> system/swtpm: Updated for version 0.10.0. >>> system/telegraf: Updated for version 1.34.1 >>> +--------------------------+ >>> >>> >>> -- >>> Willy Sudiarto Raharjo >>> >>> _______________________________________________ >>> SlackBuilds-users mailing list >>> SlackBuilds-users at slackbuilds.org >>> https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users >>> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ >>> FAQ - https://slackbuilds.org/faq/ >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From urchlay at slackware.uk Sat Mar 29 19:59:00 2025 From: urchlay at slackware.uk (B. Watson) Date: Sat, 29 Mar 2025 15:59:00 -0400 (EDT) Subject: [Slackbuilds-users] Updates - 20250329.1 In-Reply-To: References: <68ad9cc3-2190-480f-bc54-8bd032bffdc0@slackbuilds.org> Message-ID: <1f533440-db4-accd-abdf-f2349e292dcb@slackware.uk> On Sat, 29 Mar 2025, Luveh Keraph wrote: > Another thing I have just noticed: after successfully upgrading the packages listed above by means of sboupgrade?--all the permissions of my /tmp directory changed from?drwxrwxrwt > to?drwxr-xr-x. This happened in several Slackware 15.0 systems where the upgrades (not all the same as listed above though) were made. I don't know whether this is sboupgrade's > fault or else the doing of some particular package build script. Try: grep ^tmp/ /var/log/packages/* On 15.0, the only result from the command should be: /var/adm/packages/aaa_base-15.0-x86_64-4_slack15.0:tmp/ ...but there might be some broken package that installed files in /tmp, like maybe /tmp/SBo/package-whatever/usr/bin/whatever. I've seen this happen when I'm writing a new SlackBuild script and I make a mistake. From willysr at slackbuilds.org Sun Mar 30 00:45:31 2025 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sun, 30 Mar 2025 07:45:31 +0700 Subject: [Slackbuilds-users] postman glibc issue In-Reply-To: References: Message-ID: <05b19157-a2d8-4173-8a32-62bbc2278c2a@slackbuilds.org> > recent postman package upgrades are not compatible with Slackware 15.0, > as they require a newer glibc (2.34). > > The last working version that I tested was 11.27.3. > > Does anyone have the same issue? > > I tried contacting the package maintainer for this issue (see the > following) but I got no response back. The maintainer is actively sending PR on github, but didn't respond to any of my query as well If he doesn't respond before end of this week, i will revert it back to 11.27.3 can you test other newer version before the latest one? I saw that several PR has been pushed https://github.com/SlackBuildsOrg/slackbuilds/pulls?q=is%3Apr+is%3Aclosed+postman -- 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 Sun Mar 30 00:48:30 2025 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sun, 30 Mar 2025 07:48:30 +0700 Subject: [Slackbuilds-users] Updates - 20250329.1 In-Reply-To: References: <68ad9cc3-2190-480f-bc54-8bd032bffdc0@slackbuilds.org> Message-ID: <550781a0-9d26-41a3-a635-fb24bb0449af@slackbuilds.org> > These updates have broken two items for me: > > * xpdf: It displays diagrams and pictures in PDF files, but not the text. > Okular still does the right thing. xpdf is part of Slackware's core packages, not part of SBo -- 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 kvngncrlsn at gmail.com Sun Mar 30 04:01:23 2025 From: kvngncrlsn at gmail.com (K. Eugene Carlson) Date: Sun, 30 Mar 2025 13:01:23 +0900 Subject: [Slackbuilds-users] Updates - 20250329.1 In-Reply-To: <1f533440-db4-accd-abdf-f2349e292dcb@slackware.uk> References: <68ad9cc3-2190-480f-bc54-8bd032bffdc0@slackbuilds.org> <1f533440-db4-accd-abdf-f2349e292dcb@slackware.uk> Message-ID: On Sun, Mar 30, 2025 at 4:59?AM B. Watson wrote: > ...but there might be some broken package that installed files in > /tmp, like maybe /tmp/SBo/package-whatever/usr/bin/whatever. > Yep, it's netdata, whether built manually or with sboupgrade. Gene -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgrundy at linuxleo.com Sun Mar 30 12:24:08 2025 From: bgrundy at linuxleo.com (Barry J. Grundy) Date: Sun, 30 Mar 2025 08:24:08 -0400 Subject: [Slackbuilds-users] remove yara-python Message-ID: In the process of updating my builds, I noticed that yara-python was split into both python 2 and 3 versions. I believe yara-python can be removed. I can't see anything that depends on it, and I likely just forgot to have it removed when I split the python versions. SBo: python3-yara 4.5.0 Path: /usr/sbo/repo/python/python3-yara SBo: yara-python 4.1.2 Path: /usr/sbo/repo/python/yara-python SBo: python2-yara 4.5.0 Path: /usr/sbo/repo/python/python2-yara Thanks, Barry From 1.41421 at gmail.com Sun Mar 30 14:24:31 2025 From: 1.41421 at gmail.com (Luveh Keraph) Date: Sun, 30 Mar 2025 08:24:31 -0600 Subject: [Slackbuilds-users] Updates - 20250329.1 In-Reply-To: <550781a0-9d26-41a3-a635-fb24bb0449af@slackbuilds.org> References: <68ad9cc3-2190-480f-bc54-8bd032bffdc0@slackbuilds.org> <550781a0-9d26-41a3-a635-fb24bb0449af@slackbuilds.org> Message-ID: I know. And, in fact, it seems to be working now. From what I can see it may have been a glitch in my Xfce desktop, for I noticed that some icons were missing yesterday. I am at a loss as to what happened, but things seem to be fine now as far as xpdf and those icons are concerned. On Sat, Mar 29, 2025 at 6:48?PM Willy Sudiarto Raharjo < willysr at slackbuilds.org> wrote: > > These updates have broken two items for me: > > > > * xpdf: It displays diagrams and pictures in PDF files, but not the > text. > > Okular still does the right thing. > > xpdf is part of Slackware's core packages, not part of SBo > > -- > Willy Sudiarto Raharjo > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - https://slackbuilds.org/faq/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From 1.41421 at gmail.com Sun Mar 30 14:33:26 2025 From: 1.41421 at gmail.com (Luveh Keraph) Date: Sun, 30 Mar 2025 08:33:26 -0600 Subject: [Slackbuilds-users] Updates - 20250329.1 In-Reply-To: References: <68ad9cc3-2190-480f-bc54-8bd032bffdc0@slackbuilds.org> <550781a0-9d26-41a3-a635-fb24bb0449af@slackbuilds.org> Message-ID: And Signal works too! I am mystified as to what happened with my Xfce desktop; I have not changed anything recently that I am aware of. Things started misbehaving mysteriously, and, just as mysteriously, they seem to be back to normal. Which makes me uneasy - but, at least, they work . My apologies for having brought this up. On Sun, Mar 30, 2025 at 8:24?AM Luveh Keraph <1.41421 at gmail.com> wrote: > I know. And, in fact, it seems to be working now. From what I can see it > may have been a glitch in my Xfce desktop, for I noticed that some icons > were missing yesterday. I am at a loss as to what happened, but things seem > to be fine now as far as xpdf and those icons are concerned. > > On Sat, Mar 29, 2025 at 6:48?PM Willy Sudiarto Raharjo < > willysr at slackbuilds.org> wrote: > >> > These updates have broken two items for me: >> > >> > * xpdf: It displays diagrams and pictures in PDF files, but not the >> text. >> > Okular still does the right thing. >> >> xpdf is part of Slackware's core packages, not part of SBo >> >> -- >> Willy Sudiarto Raharjo >> _______________________________________________ >> SlackBuilds-users mailing list >> SlackBuilds-users at slackbuilds.org >> https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users >> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ >> FAQ - https://slackbuilds.org/faq/ >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From willysr at slackbuilds.org Sun Mar 30 15:32:24 2025 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sun, 30 Mar 2025 22:32:24 +0700 Subject: [Slackbuilds-users] remove yara-python In-Reply-To: References: Message-ID: > In the process of updating my builds, I noticed that yara-python was > split into both python 2 and 3 versions. I believe yara-python can be > removed. I can't see anything that depends on it, and I likely just > forgot to have it removed when I split the python versions. Done on my branch -- 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 Sun Mar 30 15:33:53 2025 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sun, 30 Mar 2025 22:33:53 +0700 Subject: [Slackbuilds-users] Updates - 20250329.1 In-Reply-To: References: <68ad9cc3-2190-480f-bc54-8bd032bffdc0@slackbuilds.org> <1f533440-db4-accd-abdf-f2349e292dcb@slackware.uk> Message-ID: <757503a3-b247-46f5-b2ee-313ed726cc69@slackbuilds.org> >> ...but there might be some broken package that installed files in >> /tmp, like maybe /tmp/SBo/package-whatever/usr/bin/whatever. >> > > Yep, it's netdata, whether built manually or with sboupgrade. I fixed it on my branch (https://git.slackbuilds.org/slackbuilds/commit/?id=23bd42c28) sorry that i skipped that part, but it was new issue as i never saw that in previous version -- 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 414N at slacky.it Sun Mar 30 16:50:46 2025 From: 414N at slacky.it (414N) Date: Sun, 30 Mar 2025 18:50:46 +0200 Subject: [Slackbuilds-users] postman glibc issue In-Reply-To: <05b19157-a2d8-4173-8a32-62bbc2278c2a@slackbuilds.org> References: <05b19157-a2d8-4173-8a32-62bbc2278c2a@slackbuilds.org> Message-ID: Il 30/03/25 01:45, Willy Sudiarto Raharjo ha scritto: > can you test other newer version before the latest one? > I saw that several PR has been pushed > https://github.com/SlackBuildsOrg/slackbuilds/pulls? > q=is%3Apr+is%3Aclosed+postman I just found that version 11.28.4 is the last working one from the submitted PRs. Version 11.29.5 is the first that breaks due to glibc incompatibility. -- Alan Alberghini SBo clone: https://github.com/414n/slackbuilds.org From urchlay at slackware.uk Sun Mar 30 19:12:12 2025 From: urchlay at slackware.uk (B. Watson) Date: Sun, 30 Mar 2025 15:12:12 -0400 (EDT) Subject: [Slackbuilds-users] Updates - 20250329.1 In-Reply-To: References: <68ad9cc3-2190-480f-bc54-8bd032bffdc0@slackbuilds.org> <550781a0-9d26-41a3-a635-fb24bb0449af@slackbuilds.org> Message-ID: On Sun, 30 Mar 2025, Luveh Keraph wrote: > I know. And, in fact, it seems to be working now. From what I can see it may have been a glitch in my Xfce desktop, for I noticed that some icons were missing yesterday. I am at a > loss as to what happened, but things seem to be fine now as far as xpdf and those icons are concerned. It may actually have been caused by /tmp having wrong permissions, and it's fine now that you fixed the perms.