[Slackbuilds-users] Updates - 20240302.1
Sat Mar 2 02:20:27 UTC 2024 academic/cdo: Updated for version 2.4.0. academic/fet: Updated for version 6.18.0. audio/aeolus: Fix download, md5sum, icon, docs. audio/clxclient: update script. audio/spectmorph: New maintainer, PDF manual. audio/yoshimi: Updated for version 2.3.2. business/ledger: Updated for version 3.3.2. desktop/dunst: Updated for version 1.10.0 desktop/mate-terminal: Updated for version 1.28.1. desktop/menulibre: Updated for version 2.4.0. desktop/nwg-panel: Updated for version 0.9.25. desktop/nwg-readme-browser: Updated for version 0.1.5. desktop/nwg-shell-wallpapers: Updated for version 1.5. desktop/python3-autotiling: Updated for version 1.9.1. desktop/rofi-emoji: Updated for version 3.3.0. desktop/wofi-pass: Added (Wayland-native interface). desktop/wofi: Updated for version 1.4.1. desktop/wtype: Added (xdotool type for wayland). development/actionlint: Updated for version 1.6.27. development/geany-plugins: Updated for version 2.0. development/geany: Updated for version 2.0. development/hugo: update 0.123.3 development/jupyter-ipykernel: Update for 6.29.3 development/kicad: Updated for version 8.0. development/mold: Updated for version 2.4.1. development/neovim: update dep. development/obsidian: Updated for version 1.5.8. development/pahole: Updated for version 1.26. development/postman: Updated for version 10.23.5 development/pycharm: Updated for version 2023.3.4.233.14475.56. development/python3-spyder-kernels: Update for 2.5.1 development/rebar3: Added (erlang build tool). development/rizin: Updated for version 0.7.0 development/terraform: Updated for version 1.7.4 development/vile: update to 9.8z development/vscode-bin: Updated for version 1.87.0. development/wxFormBuilder: Update for version 4.1.0 development/xmake: Updated for version 2.8.7. development/xvile: update to 9.8z games/LucasChess: Fix download, doc perms, CWD write. games/dustrac: updated for version 2.1.1. New maintainer games/freeciv: updated for version 3.1.0 games/open-adventure: Upstream changed tarball; fix md5sum. games/stockfish: Updated for version 16.1. games/supertuxkart: Fix compiling with gcc13 games/wolfmame: Updated for version 0.263. gis/eccodes: Updated for version 2.34.1. gis/gpxsee: Updated for version 13.16. graphics/ueberzugpp: Updated for version 2.9.4. graphics/vuescan: Updated for version 9.8.28. libraries/canfigger: Update dependency. libraries/libkml: fixed outdated libkml build libraries/libstrophe: Updated for version 0.13.1. libraries/libtermkey: New maintainer. libraries/libvterm: Updated for version 0.3.3. libraries/lua-lpeg: Updated for version 1.1.0. libraries/python3-rpyc: Updated for version 6.0.0. libraries/unibilium: New maintainer. misc/open-simh: Fix permission. network/brave-browser: update 1.63.162 network/coturn: Update script. network/darkhttpd: updated for version 1.16 network/dnsproxy-bin: Updated for version 0.65.2. network/gallery-dl: Updated for version 1.26.8. network/haproxy: Updated for version 2.8.7. network/nextcloud-desktop: update 3.12.0 network/nicotine+: Updated for version 3.3.2. network/opera: Updated for version 107.0.5045.36. network/profanity: Updated for version 0.14.0. network/protonvpn-cli: Updated for version 2.2.12. network/qbittorrent: Updated for version 4.6.3. network/rclone: update 1.65.2 network/signal-desktop: Updated for version 7.0.0. network/tailscale: update 1.60.0 network/teamviewer: Updated for version 15.51.5. network/vivaldi: Updated for version 6.6.3271.45. network/whalebird: Updated for version 6.0.2. network/zoom-linux: Updated for version 5.17.10.3512 office/asymptote: Updated for version 2.87. office/calibre-bin: Updated for version 7.6.0. office/goldendict: Updated for version 1.5.0. office/grisbi: updated for version 3.1.0 office/onlyoffice-desktopeditors: Updated for version 8.0.1. office/pandoc-bin: update 3.1.12.1 perl/perl-Crypt-OpenSSL-Bignum: Adjust doc file permissions. perl/perl-Crypt-OpenSSL-Bignum: Updated for version 0.09. perl/perl-Crypt-OpenSSL-Guess: Updated for version 0.15. perl/perl-Crypt-OpenSSL-RSA: Updated for version 0.33. perl/perl-Expect: Updated for version 1.36. perl/perl-digest-hmac: Updated for version 1.04. python/argon2-cffi: Update for 23.1.0 python/certbot-dns-cloudflare: Updated for version 2.9.0 python/nest_asyncio: Update for 1.6.0 python/pipdeptree: Updated for version 2.15.1. python/pyinotify: New maintainer, remove Python 2 support python/python3-anyio: Remove python3-setuptools-scm-opt from DEPs python/python3-cachetools: Version bump to 5.3.3 python/python3-cloudflare: Updated for version 2.19.2 python/python3-compreffor: Updated for version 0.5.5. python/python3-dateutil: updated for version 2.9.0 python/python3-fontmake: Updated for version 3.8.1. python/python3-fonttools: Updated for version 4.49.0. python/python3-glyphslib: Updated for version 6.6.5. python/python3-identify: Updated for version 2.5.35. python/python3-json5: Add missing dep. python/python3-keyring: Update for 24.3.1
[Slackbuilds-users] WIP: protobuf3 25.3
Hi i have just started to work on protobuf3 updates, pushing 2y of works by upstream since last update. However, there are 26 other scripts which depends on protobuf3, listed here (https://slackbuilds.org/advsearch.php?q=protobuf3=revdep1) although we do have CI engine that could help us test whether the new update will break them or not, it won't help us testing the runtime issues. Therefore, i would like to ask for help by those who are using these 26 packages to see if by upgrading protobuf3 and rebuilding them will have any runtime issues or not. I will keep the protobuf3 updates for future public update (like 1-2 weeks delay) to give others more time to test. The protobuf3 update can be seen here https://git.slackbuilds.org/slackbuilds/log/?h=protobuf3-wip Big thanks in advance -- Willy Sudiarto Raharjo OpenPGP_signature.asc Description: OpenPGP digital signature ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - https://slackbuilds.org/faq/
Re: [Slackbuilds-users] tracking down SBo "dependencies"
> > However, tracking potential breakages could be done using hoorex. > > Not in this case... > > > # hoorex -i dav1d This'll list all installed packages requiring directly > > dav1d. > > And there's the problem... Neither vlc nor libheif (nor maybe others I > haven't found yet) *directly* require dav1d, so hoorex doesn't list them. So I've looked again, and sbbdep is quite useful. So my libheif is built with dav1d, but not my VLC. And then : $ hoorex -i dav1d dav1d libheif $ sbbdep --whoneeds /var/log/packages/dav1d-1.4.0-x86_64-1yth dav1d-1.4.0-x86_64-1yth libheif-1.17.6-x86_64-1yth Which returns what is relevant. Then I rebuilt VLC, which might probably have been built without dav1d. And then : $ sbbdep --whoneeds /var/log/packages/dav1d-1.4.0-x86_64-1yth dav1d-1.4.0-x86_64-1yth libheif-1.17.6-x86_64-1yth vlc-3.0.20-x86_64-1yth So it does work, for binary dependencies. I know that either libheif or vlc could require rebuilding after an update of dav1d. To be noted : I haven't tested building vlc with libdav1d.so.6, then updating dav1d to libdav1d.so.7, and asking sbbdep. It might fail, because the link is broken, vlc wouldn't show a link to dav1d since it doesn't link to libdav1d.so.7 But, you could update sbbdep database before an update, and ask without updating the sbbdep database. Let's say, it might not be perfect, and may require something on top of it, to detect, through comparison of dependencies before and after an update, what links may have been severed. As I said, I didn't test such a situation. For perl and python (and haskell, and... maybe other), it's less problematic, since most dependencies are SBo-related, hence we have a dependency tree available. That would be more True on stable 15.0 where python/perl and system modules aren't very updated, but could be pretty wrong on -current. - Yth. ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - https://slackbuilds.org/faq/
Re: [Slackbuilds-users] Some abandoned SlackBuilds
On Sat, Apr 22, 2023 at 09:33:58AM -0500, Konrad J Hambrick wrote: > On Sat, Apr 22, 2023 at 8:50 AM Alexander Verbovetsky > wrote: > > > On Sat, Apr 22, 2023 at 08:11:52AM -0500, Konrad J Hambrick wrote: > > > > However, rabbitmq-server-3.11.13 and rabbitmq-c-0.13.0 require > > > erlang-otp-25.3 and elixir-1.14.4 to build. > > > > And then ejabberd depends on erlang-otp which is maintained by > > > Alexander Verbovetsky ( also copied here ). > > > Are there any issues with the erlang-otp and elixr updates ? > > > Ejabberd will be happy with this update. > > Thanks Alexander. > I'll continue testing and let the list know when I have something :) Is there any news? In fact, without the update, Ejabber is a bit unhappy :-) rebar3 binaries included with ejabberd requires Erlang 24+ I plan to workaround this by providing a Slackbuild for rebar3, but even so, I think it would be a good idea to move to Erlang 25 or 26, unless there's a good reason to stay with Erlang 23. Also, Ejabberd can be used with Elixir, and in this case the documentation highly recommend to use Elixir 1.13.4 or higher. Best regards, Alexander ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - https://slackbuilds.org/faq/
Re: [Slackbuilds-users] tracking down SBo "dependencies"
On Friday, March 1st, 2024 at 4:16 AM, Tim Dickson via SlackBuilds-users wrote: > > > the problem is the optional dependencies. how does a tool know which > options you like. > Only when such a tool which has your preferred optional deps recorded > exists, can there > be a way to reverse dep without missing out bits. > regards, Tim > As already mentioned, slackrepo handles this. Optional deps are stored in hintfiles: $ cat /var/lib/slackrepo/etr/hintfiles/vlc.hint ADDREQUIRES="dav1d" You can even replace deps with other deps (e.g. use OpenBLAS instead of blas and lapack for octave): $ cat /var/lib/slackrepo/etr/hintfiles/blas.hint SKIP="Use OpenBLAS instead" $ cat /var/lib/slackrepo/etr/hintfiles/lapack.hint SKIP="Use OpenBLAS instead" $ cat /var/lib/slackrepo/etr/hintfiles/octave.hint DELREQUIRES="lapack" ADDREQUIRES="OpenBLAS suitesparse glpk arpack-ng qrupdate sundials qhull hdf5 fltk ftgl gl2ps GraphicsMagick portaudio rapidjson zulu-openjdk21" So when using slackrepo if blas has an update from SBo nothing will happen on my end (since nothing depends on blas). An upgrade of OpenBLAS will trigger octave to be rebuilt. Note: since required dependencies are not listed in hintfiles (they are already present in *.info), I also maintain a set of sbopkg queue files (which list both required and optional deps) so I can quickly grep for dependencies, though I rarely need to do so. Most often I use it when removing a package and then removing all of its deps that aren't used by other programs I have installed. After every public update I run (in a clean chroot); slackrepo update --preview to first review what will be rebuilt, taking note of any new optional deps I may want to add (rare). Then: slackrepo update This builds everything that needs an upgrade or rebuild. Erich ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - https://slackbuilds.org/faq/
Re: [Slackbuilds-users] tracking down SBo "dependencies"
yes, i am aware of that. the problem is that, unlike CRUX's revdep, this does not have a /etc/revdep.d where to store files indicating libraries in custom places, package wise. So, if I want to maintain a binary repackaging script, Emmets' revdep for Slackware will not report what such package is missing. anyway. That's beating a deadhorse as already wisely stated and i am fully aware nothing will change -p On Fri, 1 Mar 2024 at 12:45, Jay Lanagan via SlackBuilds-users wrote: > > This tool emmet1 made based on and acting like the CRUX tool of the same name > is still my favorite out of Didler’s, Pat’s and others I’ve used. It’s simple > and powerful and finds missing .so’s perfectly. > > https://gist.github.com/emmett1/eb71186ba5567be46ad34ae59ba1fa57 > > Of course things like Firefox/thunderbird will show up but they can be safely > ignored. Everything else will be shown correctly and for .so files, it’s > invaluable. > > — Jay Lanagan > > > On Mar 1, 2024 at 5:20 AM, wrote: > ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - https://slackbuilds.org/faq/
Re: [Slackbuilds-users] tracking down SBo "dependencies"
On 2/29/24 8:12 AM, Jim wrote: I recently upgraded the SBo dav1d, which upgraded the library from libdav1d.so.6 to libdav1d.so.7. Unfortunately, a couple of other SBo packages (libheif and vlc) had references to (specifically) libdav1d.so.6, which caused them to whine a bit. It was easy enough to recompile libheif and vlc after I found the problem, but this got me wondering... Does anyone have an easy way of tracking down this sort of "breakage" which might happen when upgrading an SBo package? [...] What about depfinder by Salix? ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - https://slackbuilds.org/faq/
Re: [Slackbuilds-users] tracking down SBo "dependencies"
Hi, Le 01/03/2024 à 11:32, Petar Petrov a écrit : > what about them? Of course it won't 'catch' these. Still, checking the > *.so libs is a great help. > > do you think that since it won't work for perl, python and ruby such > tool is unneeded? > > -p No, I don't. But.. Things would be so much simpler if Slackware packages' metadata included their dependencies, as other distributions do. Back to my rabbit hole. Didier > On Fri, 1 Mar 2024 at 12:28, Didier Spaier wrote: >> >> What about the non-binary deps (perl, python and ruby...)? >> >> Cheers, >> Didier >> >> Le 01/03/2024 à 11:19, Petar Petrov a écrit : >>> revdep checks for broken *.so, so it would not matter whether your >>> deps were optional or not. People running -current, who install stuff >>> from SBo, would greatly benefit from such a tool. >>> >>> regards, >>> >>> -p ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - https://slackbuilds.org/faq/
Re: [Slackbuilds-users] tracking down SBo "dependencies"
This tool emmet1 made based on and acting like the CRUX tool of the same name is still my favorite out of Didler’s, Pat’s and others I’ve used. It’s simple and powerful and finds missing .so’s perfectly. https://gist.github.com/emmett1/eb71186ba5567be46ad34ae59ba1fa57 Of course things like Firefox/thunderbird will show up but they can be safely ignored. Everything else will be shown correctly and for .so files, it’s invaluable. — Jay Lanagan > > On Mar 1, 2024 at 5:20 AM, mailto:slackal...@gmail.com)> > wrote: > > > > revdep checks for broken *.so, so it would not matter whether your deps were > optional or not. People running -current, who install stuff from SBo, would > greatly benefit from such a tool. regards, -p On Fri, 1 Mar 2024 at 12:16, > Tim Dickson via SlackBuilds-users > wrote: > > the problem is the optional dependencies. how does a tool know > which > options you like. > Only when such a tool which has your > preferred optional deps recorded > exists, can there > be a way to > reverse dep without missing out bits. > regards, Tim > > On 01/03/2024 > 09:38, Petar Petrov wrote: > > there were several discussions about > Slackware needing a tool such as > > revdep, to check for issues like > this. Search LQ, however, I did not > > find a good solution that just > works. I got advice to make my own > > tool, as well as, statements how > people use their own "home made" > > tools for this. > > > > -p > > > > > On Thu, 29 Feb 2024 at 18:12, Jim > wrote: > >> I recently upgraded the SBo dav1d, which upgraded the library > from > >> libdav1d.so.6 to libdav1d.so.7. > >> > >> > Unfortunately, a couple of other SBo packages (libheif and vlc) had > >> > references to (specifically) libdav1d.so.6, which caused them to whine a > > >> bit. > >> > >> It was easy enough to recompile libheif and vlc > after I found the problem, > >> but this got me wondering... > >> > > >> Does anyone have an easy way of tracking down this sort of "breakage" > which > >> might happen when upgrading an SBo package? > >> > >> > Thanks. > >> Jim > >> ___ > > >> SlackBuilds-users mailing list > >> > SlackBuilds-users@slackbuilds.org > >> > https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > >> > Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ > >> > FAQ - https://slackbuilds.org/faq/ > >> > > > ___ > > SlackBuilds-users > mailing list > > SlackBuilds-users@slackbuilds.org > > > https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > > > Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ > > > FAQ - https://slackbuilds.org/faq/ > > > > > ___ > SlackBuilds-users mailing > list > SlackBuilds-users@slackbuilds.org > > https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives > - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - > https://slackbuilds.org/faq/ > > ___ SlackBuilds-users mailing > list SlackBuilds-users@slackbuilds.org > https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - > https://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - > https://slackbuilds.org/faq/ > > ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - https://slackbuilds.org/faq/
Re: [Slackbuilds-users] tracking down SBo "dependencies"
what about them? Of course it won't 'catch' these. Still, checking the *.so libs is a great help. do you think that since it won't work for perl, python and ruby such tool is unneeded? -p On Fri, 1 Mar 2024 at 12:28, Didier Spaier wrote: > > What about the non-binary deps (perl, python and ruby...)? > > Cheers, > Didier > > Le 01/03/2024 à 11:19, Petar Petrov a écrit : > > revdep checks for broken *.so, so it would not matter whether your > > deps were optional or not. People running -current, who install stuff > > from SBo, would greatly benefit from such a tool. > > > > regards, > > > > -p > > > > > > On Fri, 1 Mar 2024 at 12:16, Tim Dickson via SlackBuilds-users > > wrote: > >> > >> the problem is the optional dependencies. how does a tool know which > >> options you like. > >> Only when such a tool which has your preferred optional deps recorded > >> exists, can there > >> be a way to reverse dep without missing out bits. > >> regards, Tim > >> > >> On 01/03/2024 09:38, Petar Petrov wrote: > >>> there were several discussions about Slackware needing a tool such as > >>> revdep, to check for issues like this. Search LQ, however, I did not > >>> find a good solution that just works. I got advice to make my own > >>> tool, as well as, statements how people use their own "home made" > >>> tools for this. > >>> > >>> -p > >>> > >>> On Thu, 29 Feb 2024 at 18:12, Jim wrote: > I recently upgraded the SBo dav1d, which upgraded the library from > libdav1d.so.6 to libdav1d.so.7. > > Unfortunately, a couple of other SBo packages (libheif and vlc) had > references to (specifically) libdav1d.so.6, which caused them to whine a > bit. > > It was easy enough to recompile libheif and vlc after I found the > problem, > but this got me wondering... > > Does anyone have an easy way of tracking down this sort of "breakage" > which > might happen when upgrading an SBo package? > > Thanks. > Jim > ___ > SlackBuilds-users mailing list > SlackBuilds-users@slackbuilds.org > https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - https://slackbuilds.org/faq/ > ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - https://slackbuilds.org/faq/
Re: [Slackbuilds-users] tracking down SBo "dependencies"
What about the non-binary deps (perl, python and ruby...)? Cheers, Didier Le 01/03/2024 à 11:19, Petar Petrov a écrit : > revdep checks for broken *.so, so it would not matter whether your > deps were optional or not. People running -current, who install stuff > from SBo, would greatly benefit from such a tool. > > regards, > > -p > > > On Fri, 1 Mar 2024 at 12:16, Tim Dickson via SlackBuilds-users > wrote: >> >> the problem is the optional dependencies. how does a tool know which >> options you like. >> Only when such a tool which has your preferred optional deps recorded >> exists, can there >> be a way to reverse dep without missing out bits. >> regards, Tim >> >> On 01/03/2024 09:38, Petar Petrov wrote: >>> there were several discussions about Slackware needing a tool such as >>> revdep, to check for issues like this. Search LQ, however, I did not >>> find a good solution that just works. I got advice to make my own >>> tool, as well as, statements how people use their own "home made" >>> tools for this. >>> >>> -p >>> >>> On Thu, 29 Feb 2024 at 18:12, Jim wrote: I recently upgraded the SBo dav1d, which upgraded the library from libdav1d.so.6 to libdav1d.so.7. Unfortunately, a couple of other SBo packages (libheif and vlc) had references to (specifically) libdav1d.so.6, which caused them to whine a bit. It was easy enough to recompile libheif and vlc after I found the problem, but this got me wondering... Does anyone have an easy way of tracking down this sort of "breakage" which might happen when upgrading an SBo package? Thanks. Jim ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - https://slackbuilds.org/faq/
Re: [Slackbuilds-users] tracking down SBo "dependencies"
revdep checks for broken *.so, so it would not matter whether your deps were optional or not. People running -current, who install stuff from SBo, would greatly benefit from such a tool. regards, -p On Fri, 1 Mar 2024 at 12:16, Tim Dickson via SlackBuilds-users wrote: > > the problem is the optional dependencies. how does a tool know which > options you like. > Only when such a tool which has your preferred optional deps recorded > exists, can there > be a way to reverse dep without missing out bits. > regards, Tim > > On 01/03/2024 09:38, Petar Petrov wrote: > > there were several discussions about Slackware needing a tool such as > > revdep, to check for issues like this. Search LQ, however, I did not > > find a good solution that just works. I got advice to make my own > > tool, as well as, statements how people use their own "home made" > > tools for this. > > > > -p > > > > On Thu, 29 Feb 2024 at 18:12, Jim wrote: > >> I recently upgraded the SBo dav1d, which upgraded the library from > >> libdav1d.so.6 to libdav1d.so.7. > >> > >> Unfortunately, a couple of other SBo packages (libheif and vlc) had > >> references to (specifically) libdav1d.so.6, which caused them to whine a > >> bit. > >> > >> It was easy enough to recompile libheif and vlc after I found the problem, > >> but this got me wondering... > >> > >> Does anyone have an easy way of tracking down this sort of "breakage" which > >> might happen when upgrading an SBo package? > >> > >> Thanks. > >> Jim > >> ___ > >> SlackBuilds-users mailing list > >> SlackBuilds-users@slackbuilds.org > >> https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > >> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ > >> FAQ - https://slackbuilds.org/faq/ > >> > > ___ > > SlackBuilds-users mailing list > > SlackBuilds-users@slackbuilds.org > > https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > > Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ > > FAQ - https://slackbuilds.org/faq/ > > > > ___ > SlackBuilds-users mailing list > SlackBuilds-users@slackbuilds.org > https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - https://slackbuilds.org/faq/ > ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - https://slackbuilds.org/faq/
Re: [Slackbuilds-users] tracking down SBo "dependencies"
the problem is the optional dependencies. how does a tool know which options you like. Only when such a tool which has your preferred optional deps recorded exists, can there be a way to reverse dep without missing out bits. regards, Tim On 01/03/2024 09:38, Petar Petrov wrote: there were several discussions about Slackware needing a tool such as revdep, to check for issues like this. Search LQ, however, I did not find a good solution that just works. I got advice to make my own tool, as well as, statements how people use their own "home made" tools for this. -p On Thu, 29 Feb 2024 at 18:12, Jim wrote: I recently upgraded the SBo dav1d, which upgraded the library from libdav1d.so.6 to libdav1d.so.7. Unfortunately, a couple of other SBo packages (libheif and vlc) had references to (specifically) libdav1d.so.6, which caused them to whine a bit. It was easy enough to recompile libheif and vlc after I found the problem, but this got me wondering... Does anyone have an easy way of tracking down this sort of "breakage" which might happen when upgrading an SBo package? Thanks. Jim ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - https://slackbuilds.org/faq/ ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - https://slackbuilds.org/faq/ ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - https://slackbuilds.org/faq/
Re: [Slackbuilds-users] tracking down SBo "dependencies"
there were several discussions about Slackware needing a tool such as revdep, to check for issues like this. Search LQ, however, I did not find a good solution that just works. I got advice to make my own tool, as well as, statements how people use their own "home made" tools for this. -p On Thu, 29 Feb 2024 at 18:12, Jim wrote: > > I recently upgraded the SBo dav1d, which upgraded the library from > libdav1d.so.6 to libdav1d.so.7. > > Unfortunately, a couple of other SBo packages (libheif and vlc) had > references to (specifically) libdav1d.so.6, which caused them to whine a > bit. > > It was easy enough to recompile libheif and vlc after I found the problem, > but this got me wondering... > > Does anyone have an easy way of tracking down this sort of "breakage" which > might happen when upgrading an SBo package? > > Thanks. > Jim > ___ > SlackBuilds-users mailing list > SlackBuilds-users@slackbuilds.org > https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - https://slackbuilds.org/faq/ > ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - https://slackbuilds.org/faq/
