From brandon.pribs11 at gmail.com Sun Sep 1 01:19:06 2024 From: brandon.pribs11 at gmail.com (Brandon Pribula) Date: Sat, 31 Aug 2024 18:19:06 -0700 Subject: [Slackbuilds-users] Orphaning my SlackBuilds In-Reply-To: <268ec249-cd11-c4e9-51c3-b578419baa8c@o2.pl> References: <268ec249-cd11-c4e9-51c3-b578419baa8c@o2.pl> Message-ID: On Sat, Aug 31, 2024 at 4:54?PM Dominik Drobek wrote: > Hi everyone, > > I'm moving away from Slackware, so please consider my SlackBuilds > orphaned. Feel free to change the license if you wish. > > > audio/MP3Diags: can be updated to a stable QT5-based version. > > desktop/xfce4-volumed-pulse: needs updating (it couldn't be updated in > 14.2). > > games/OpenXcom: no stable version since ages, just nightlies. > > graphics/gcolor2: obsolete, but I'm not aware of an equivalent GTK+3 > version. > > network/aircrack-ng: at latest version. > network/cowpatty: at latest version, doesn't look like it's developed > anymore. > network/macchanger: at latest version. Mature, hasn't been updated in > years. > network/pidgin-extprefs: at latest version, not sure if this package is > still useful. > network/skype4pidgin: at latest version, not sure if this package is > still useful. > network/SoulseekQt: Linux version hasn't been updated since 2018. Better > Linux clients are available. > > office/latexdiff: needs updating. > > perl/perl-Text-Iconv: at latest version. Mature, hasn't been updated in > years. > > python/GeoIP-Python: at latest version. Obsolete, but some software > still depends on it. > python/pyotp: actively developed, needs updating. > > system/hddtemp: no upstream development in years, but an active fork > with a newer version exists. > system/pigz: needs updating. > > > Best regards, > Dominik > _______________________________________________ > 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 can take over maintenance of system/pigz. -------------- next part -------------- An HTML attachment was scrubbed... URL: From diniz.bortolotto at gmail.com Sun Sep 1 04:45:01 2024 From: diniz.bortolotto at gmail.com (Diniz Bortolotto) Date: Sun, 1 Sep 2024 01:45:01 -0300 Subject: [Slackbuilds-users] Orphaning my SlackBuilds In-Reply-To: <268ec249-cd11-c4e9-51c3-b578419baa8c@o2.pl> References: <268ec249-cd11-c4e9-51c3-b578419baa8c@o2.pl> Message-ID: I like storage apps. :-) So I could take over the system/hddtemp SlackBuild. Atenciosamente, Diniz Bortolotto Em s?b., 31 de ago. de 2024 ?s 20:54, Dominik Drobek escreveu: > Hi everyone, > > I'm moving away from Slackware, so please consider my SlackBuilds > orphaned. Feel free to change the license if you wish. > > > audio/MP3Diags: can be updated to a stable QT5-based version. > > desktop/xfce4-volumed-pulse: needs updating (it couldn't be updated in > 14.2). > > games/OpenXcom: no stable version since ages, just nightlies. > > graphics/gcolor2: obsolete, but I'm not aware of an equivalent GTK+3 > version. > > network/aircrack-ng: at latest version. > network/cowpatty: at latest version, doesn't look like it's developed > anymore. > network/macchanger: at latest version. Mature, hasn't been updated in > years. > network/pidgin-extprefs: at latest version, not sure if this package is > still useful. > network/skype4pidgin: at latest version, not sure if this package is > still useful. > network/SoulseekQt: Linux version hasn't been updated since 2018. Better > Linux clients are available. > > office/latexdiff: needs updating. > > perl/perl-Text-Iconv: at latest version. Mature, hasn't been updated in > years. > > python/GeoIP-Python: at latest version. Obsolete, but some software > still depends on it. > python/pyotp: actively developed, needs updating. > > system/hddtemp: no upstream development in years, but an active fork > with a newer version exists. > system/pigz: needs updating. > > > Best regards, > Dominik > _______________________________________________ > 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 roberto.puzzanghera at sagredo.eu Sun Sep 1 07:25:04 2024 From: roberto.puzzanghera at sagredo.eu (Roberto Puzzanghera) Date: Sun, 01 Sep 2024 09:25:04 +0200 Subject: [Slackbuilds-users] nginx maintenance In-Reply-To: <3e6f56f2-1a4-1ac3-ad52-3c8ac72232d@slackware.uk> References: <3e6f56f2-1a4-1ac3-ad52-3c8ac72232d@slackware.uk> Message-ID: > I would estimate that about 25% of our repo is effectively > unmaintained. We really need folks to step up and take over anything > they need or are interested in. I would be happy to be a new entry. But something is not clear to me about the steps to follow when I would like to take over a certain package. Let's suppose that I contacted the maintainer and got no responce from her/him. How can I be officially declared the new maintainer of that package? Is it sufficient to give an advice on this list? regards Roberto From urchlay at slackware.uk Sun Sep 1 07:43:16 2024 From: urchlay at slackware.uk (B. Watson) Date: Sun, 1 Sep 2024 03:43:16 -0400 (EDT) Subject: [Slackbuilds-users] nginx maintenance In-Reply-To: References: <3e6f56f2-1a4-1ac3-ad52-3c8ac72232d@slackware.uk> Message-ID: <6e37d412-5198-bfa3-9b88-4feab7cf756@slackware.uk> On Sun, 1 Sep 2024, Roberto Puzzanghera via SlackBuilds-users wrote: >> I would estimate that about 25% of our repo is effectively >> unmaintained. We really need folks to step up and take over anything >> they need or are interested in. > > I would be happy to be a new entry. But something is not clear to me about > the steps to follow when I would like to take over a certain package. > Let's suppose that I contacted the maintainer and got no responce from > her/him. How can I be officially declared the new maintainer of that package? Announce it on the list, and give some details ("I tried to contact the maintainer and (the email bounceed | I got no response after N days | I was given permission to take over")... > Is it sufficient to give an advice on this list? Almost. The next step is to actually submit an update, even if all you change is MAINTAINER (your name) and EMAIL, in the .info file. Quite a few times over the years, someone has announced they were taking over a build, and then never got around to updating it with their information, and it just got forgotten about. Maybe I should write a new section for the FAQ. There doesn't seem to be anything there about taking over a build. From davidnchmelik at gmail.com Sun Sep 1 07:55:22 2024 From: davidnchmelik at gmail.com (David Chmelik) Date: Sun, 1 Sep 2024 00:55:22 -0700 Subject: [Slackbuilds-users] nginx maintenance In-Reply-To: <6e37d412-5198-bfa3-9b88-4feab7cf756@slackware.uk> References: <3e6f56f2-1a4-1ac3-ad52-3c8ac72232d@slackware.uk> <6e37d412-5198-bfa3-9b88-4feab7cf756@slackware.uk> Message-ID: <29402d21-b70c-c977-f3ca-8205a88f0862@gmail.com> On 9/1/24 12:43 AM, B. Watson wrote: > Almost. The next step is to actually submit an update, even if all you > change is MAINTAINER (your name) and EMAIL, in the .info file. > > Quite a few times over the years, someone has announced they were > taking over a build, and then never got around to updating it with > their information, and it just got forgotten about. > > Maybe I should write a new section for the FAQ. There doesn't seem to > be anything there about taking over a build. Please do so!? Once a friend took over one of my SlackBuilds but wanted to leave my name & information as the maintainer, and not add his, due to SlackBuilds being copyrighted, and did so for at least one update.? After I asked and the original creator finally agreed to switch to WTFPL my friend was finally willing to update to list his information.? Among FLOSS programmers, I doubt he's the only person that dislikes copyright, so we need to clarify if it's not allowed to leave the burden on the old maintainer as the official contact person and not have people even know you took it over. From urchlay at slackware.uk Sun Sep 1 09:35:47 2024 From: urchlay at slackware.uk (B. Watson) Date: Sun, 1 Sep 2024 05:35:47 -0400 (EDT) Subject: [Slackbuilds-users] nginx maintenance In-Reply-To: <29402d21-b70c-c977-f3ca-8205a88f0862@gmail.com> References: <3e6f56f2-1a4-1ac3-ad52-3c8ac72232d@slackware.uk> <6e37d412-5198-bfa3-9b88-4feab7cf756@slackware.uk> <29402d21-b70c-c977-f3ca-8205a88f0862@gmail.com> Message-ID: On Sun, 1 Sep 2024, David Chmelik wrote: > Please do so!? Once a friend took over one of my SlackBuilds but wanted > to leave my name & information as the maintainer, and not add his, due > to SlackBuilds being copyrighted, and did so for at least one update.? We'd rather people not do that. > After I asked and the original creator finally agreed to switch to WTFPL > my friend was finally willing to update to list his information.? Among > FLOSS programmers, I doubt he's the only person that dislikes copyright, I hate the need for it. But you were right to ask the original author, instead of just changing the license without permission. > so we need to clarify if it's not allowed to leave the burden on the old > maintainer as the official contact person and not have people even know > you took it over. If the old maintainer could "bear the burden" of being the contact person and maintaining the script, there wouldn't be any need for a new maintainer. When you take over a build, you leave the previous maintainer(s) names in the comments at the top of the script, to give them credit... but *you* are the contact person, if it's your script now. I tend to remove the old maintainer's email from the comment, to avoid him getting unwanted email. If someone *really* needs to contact the original author for some reason, there's always the git history. From slackbuilds at schoepfer.info Sun Sep 1 09:44:13 2024 From: slackbuilds at schoepfer.info (Franzen) Date: Sun, 01 Sep 2024 11:44:13 +0200 Subject: [Slackbuilds-users] nginx maintenance In-Reply-To: References: Message-ID: I'll take Opensonic then. Johannes Am 31. August 2024 19:58:12 MESZ schrieb Eugen Wissner : >Hello, > >I'm a bit concerned about nginx not being updated since 1.23.2, because >I use it in production and wouldn't like to get any security >problems because of it. And the last updates weren't done by the actual >maintainer. > >Larry Hajali (the maintainer) doesn't seem to be active anymore. I've >found a commit message from 2022 about his other script, >multimedia/kodi (commit bce52521d6): > >> Larry has not responded to several email messages and it seems no >> others have been able to reach him as well. > >So I suppose I can take over the maintainence of nginx? > >Probably his other scripts need care too. The list is pretty long. > >alienarena >apsw >assaultcube >audiopreview >bitstream >brainparty >cdk >chartgeany >chroma >chromium-bsu >css-parser >cssutils >cubosphere >cuneiform >cuyo >dcadec >dosemu >dukpy >dvblast >easystroke >enca >eyeD3 >filechunkio >flvstreamer >fpconst >gdata >glestae >gst0-python >gtkimageview >html5-parser >http-parser >irrlicht >jag >keychain >kradio >ldns >libaacs >libb64 >libbdplus >libcec >libdc1394 >libdivecomputer >libdvbcsa >libmodplug >libmusicbrainz3 >libnfs >libotf >libunique >lockdev >meandmyshadow >mechanize >megaglest >mini18n >notification-daemon >ois >opensonic >pasang-emas >peg-e >perl-Cstools >perl-IO-CaptureOutput >perl-Unicode-Map >perl-Unicode-Map8 >perl-trayicon >pidgin-toobars >platform >pydf >pymysql >pypoppler >python-distutils-extra >python-libnacl >python-musicbrainz2 >python-sh >python2-MarkupSafe >python2-dateutil >python2-keyczar >qalculate-gtk >qcad >rezerwar >rope >s3cmd >shotcut >sigil >simplejson >soil >speedcrunch >subsurface >sysdig >t4k_common >tinyxml >tinyxml2 >tuxmath >unrardll >wxMaxima >xmlcopyeditor >xvst >yabause >yagf >_______________________________________________ >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 dominik.drobek at o2.pl Sun Sep 1 23:04:15 2024 From: dominik.drobek at o2.pl (Dominik Drobek) Date: Mon, 2 Sep 2024 01:04:15 +0200 Subject: [Slackbuilds-users] Orphaning my SlackBuilds In-Reply-To: References: <268ec249-cd11-c4e9-51c3-b578419baa8c@o2.pl> Message-ID: Thank you Brandon and Diniz, I'm sure these SlackBuilds are in good hands now. :) As for the remaining ones - could we mark them as orphaned by changing their .info files? For example, Gentoo people use "maintainer-needed at gentoo.org" as email addresses for abandoned ebuilds. If this is acceptable, I could push a similar change for my remaining scripts, i.e.: -MAINTAINER="Dominik Drobek" -EMAIL="dominik.drobek (at) o2.pl" +MAINTAINER="maintainer-needed" +EMAIL="maintainer-needed at slackbuilds.org" Regards, Dominik From jebrhansen+SBo at gmail.com Sun Sep 1 23:56:33 2024 From: jebrhansen+SBo at gmail.com (Jeremy Hansen) Date: Sun, 1 Sep 2024 16:56:33 -0700 Subject: [Slackbuilds-users] Orphaning my SlackBuilds In-Reply-To: References: <268ec249-cd11-c4e9-51c3-b578419baa8c@o2.pl> Message-ID: On Sun, Sep 1, 2024, 4:04?PM Dominik Drobek wrote: > Thank you Brandon and Diniz, I'm sure these SlackBuilds are in good > hands now. :) > > As for the remaining ones - could we mark them as orphaned by changing > their .info files? For example, Gentoo people use > "maintainer-needed at gentoo.org" as email addresses for abandoned ebuilds. > If this is acceptable, I could push a similar change for my remaining > scripts, i.e.: > > -MAINTAINER="Dominik Drobek" > -EMAIL="dominik.drobek (at) o2.pl" > +MAINTAINER="maintainer-needed" > +EMAIL="maintainer-needed at slackbuilds.org" > > Regards, > Dominik > I would love to see a change like this on SBo for known unmaintained scripts. It would be immediately obvious what scripts are considered unmaintained. They can remain that way until they no longer build and are removed or they are taken over by someone else. Jeremy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From urchlay at slackware.uk Mon Sep 2 06:23:21 2024 From: urchlay at slackware.uk (B. Watson) Date: Mon, 2 Sep 2024 02:23:21 -0400 (EDT) Subject: [Slackbuilds-users] Orphaning my SlackBuilds In-Reply-To: References: <268ec249-cd11-c4e9-51c3-b578419baa8c@o2.pl> Message-ID: <2c50b074-88cf-cf11-86e9-3ed98bbb39d8@slackware.uk> On Mon, 2 Sep 2024, Dominik Drobek wrote: > Thank you Brandon and Diniz, I'm sure these SlackBuilds are in good hands > now. :) > > As for the remaining ones - could we mark them as orphaned by changing their > .info files? For example, Gentoo people use "maintainer-needed at gentoo.org" as > email addresses for abandoned ebuilds. If this is acceptable, I could push a > similar change for my remaining scripts, i.e.: > > -MAINTAINER="Dominik Drobek" > -EMAIL="dominik.drobek (at) o2.pl" > +MAINTAINER="maintainer-needed" > +EMAIL="maintainer-needed at slackbuilds.org" You can. If you do this, the standard is: MAINTAINER="orphaned - no maintainer" EMAIL="nobody at nowhere.com" (Yes, I know, the email address should be something undeliverable, I'm just repeating what's actually there) Before you do that though... We do updates weekly, late Friday night (or early Saturday morning), so maybe wait until after the weekly update and see if any of them have new maintainers. From urchlay at slackware.uk Mon Sep 2 06:32:35 2024 From: urchlay at slackware.uk (B. Watson) Date: Mon, 2 Sep 2024 02:32:35 -0400 (EDT) Subject: [Slackbuilds-users] Orphaning my SlackBuilds In-Reply-To: References: <268ec249-cd11-c4e9-51c3-b578419baa8c@o2.pl> Message-ID: <91387224-27c3-738d-efc3-3d644bd335d@slackware.uk> On Sun, 1 Sep 2024, Jeremy Hansen wrote: > I would love to see a change like this on SBo for known unmaintained > scripts. It would be immediately obvious what scripts are considered > unmaintained. They can remain that way until they no longer build > and are removed or they are taken over by someone else. We have this already. See: https://slackbuilds.org/advsearch.php?stype=maint&q=orphaned The trouble is, we don't have an automated process for marking scripts as unmaintained. Someone abandons their builds, we leave them as-is and let others take them over... and then years later, the ones that didn't get taken over, still have the old maintainer info on them. Having the old maintainer send one last update with MAINTAINER="orphaned" is nice, but in all our years of operation, no maintainer has ever done this when leaving (though it sounds like Dominik Drobek is going to; thanks, Dominik!). In theory, some SBo admin should mark them as orphaned... but as long as it depends on humans to remember to do it, it'll remain undone. I have no idea how to really automate it, though. We have builds that haven't been updated in years because they haven't needed updates: "mature" or abandoned upstream, but still useful, or still entertaining if it's a game... so we can't just say something simple like "any build that hasn't been touched in N years becomes orphaned". From urchlay at slackware.uk Mon Sep 2 09:18:49 2024 From: urchlay at slackware.uk (B. Watson) Date: Mon, 2 Sep 2024 05:18:49 -0400 (EDT) Subject: [Slackbuilds-users] Orphaning my SlackBuilds In-Reply-To: <268ec249-cd11-c4e9-51c3-b578419baa8c@o2.pl> References: <268ec249-cd11-c4e9-51c3-b578419baa8c@o2.pl> Message-ID: On Sun, 1 Sep 2024, Dominik Drobek wrote: > graphics/gcolor2: obsolete, but I'm not aware of an equivalent GTK+3 version. > network/macchanger: at latest version. Mature, hasn't been updated in years. I'll take these two. There actually is a gcolor3: https://github.com/Hjdskes/gcolor3 ...but I don't see a reason to get rid of gcolor2, since it works and is useful. Someone else can submit a new build for gcolor3, if they want. From arabusov at gmail.com Mon Sep 2 09:47:29 2024 From: arabusov at gmail.com (=?UTF-8?B?0JDQvdC00YDQtdC5INCg0LDQsdGD0YHQvtCy?=) Date: Mon, 2 Sep 2024 10:47:29 +0100 Subject: [Slackbuilds-users] Orphaning my SlackBuilds In-Reply-To: <268ec249-cd11-c4e9-51c3-b578419baa8c@o2.pl> References: <268ec249-cd11-c4e9-51c3-b578419baa8c@o2.pl> Message-ID: Hi Dominik, If not already taken, I'll grab latexdiff Cheers Andrei On Sun, Sep 1, 2024, 00:54 Dominik Drobek wrote: > Hi everyone, > > I'm moving away from Slackware, so please consider my SlackBuilds > orphaned. Feel free to change the license if you wish. > > > audio/MP3Diags: can be updated to a stable QT5-based version. > > desktop/xfce4-volumed-pulse: needs updating (it couldn't be updated in > 14.2). > > games/OpenXcom: no stable version since ages, just nightlies. > > graphics/gcolor2: obsolete, but I'm not aware of an equivalent GTK+3 > version. > > network/aircrack-ng: at latest version. > network/cowpatty: at latest version, doesn't look like it's developed > anymore. > network/macchanger: at latest version. Mature, hasn't been updated in > years. > network/pidgin-extprefs: at latest version, not sure if this package is > still useful. > network/skype4pidgin: at latest version, not sure if this package is > still useful. > network/SoulseekQt: Linux version hasn't been updated since 2018. Better > Linux clients are available. > > office/latexdiff: needs updating. > > perl/perl-Text-Iconv: at latest version. Mature, hasn't been updated in > years. > > python/GeoIP-Python: at latest version. Obsolete, but some software > still depends on it. > python/pyotp: actively developed, needs updating. > > system/hddtemp: no upstream development in years, but an active fork > with a newer version exists. > system/pigz: needs updating. > > > Best regards, > Dominik > _______________________________________________ > 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 dominik.drobek at o2.pl Mon Sep 2 11:29:09 2024 From: dominik.drobek at o2.pl (Dominik Drobek) Date: Mon, 2 Sep 2024 13:29:09 +0200 Subject: [Slackbuilds-users] Orphaning my SlackBuilds In-Reply-To: <2c50b074-88cf-cf11-86e9-3ed98bbb39d8@slackware.uk> References: <268ec249-cd11-c4e9-51c3-b578419baa8c@o2.pl> <2c50b074-88cf-cf11-86e9-3ed98bbb39d8@slackware.uk> Message-ID: <9a9bc805-3447-4c4f-b982-dee09a9bde66@o2.pl> W dniu 02.09.2024 o?08:23, B. Watson pisze: > If you do this, the standard is: > > MAINTAINER="orphaned - no maintainer" > EMAIL="nobody at nowhere.com" Huh. Believe it or not, I was looking for an existing "maintainer needed" pattern in the .info files, but somehow I missed it. > Before you do that though... We do updates weekly, late Friday night > (or early Saturday morning), so maybe wait until after the weekly > update and see if any of them have new maintainers. Good point. I'll see which scripts are still not taken after the weekly update, and I'll mark them as orphaned then. Regards, Dominik From nick at smallbone.se Mon Sep 2 12:35:53 2024 From: nick at smallbone.se (Nick Smallbone) Date: Mon, 02 Sep 2024 14:35:53 +0200 Subject: [Slackbuilds-users] Orphaning my SlackBuilds In-Reply-To: <268ec249-cd11-c4e9-51c3-b578419baa8c@o2.pl> References: <268ec249-cd11-c4e9-51c3-b578419baa8c@o2.pl> Message-ID: <4b2e708d-d36d-4985-b005-d40631791129@app.fastmail.com> I can take desktop/xfce4-volumed-pulse. Nick On Sun, 1 Sep 2024, at 1:47 AM, Dominik Drobek wrote: > Hi everyone, > > I'm moving away from Slackware, so please consider my SlackBuilds > orphaned. Feel free to change the license if you wish. > > > audio/MP3Diags: can be updated to a stable QT5-based version. > > desktop/xfce4-volumed-pulse: needs updating (it couldn't be updated in > 14.2). > > games/OpenXcom: no stable version since ages, just nightlies. > > graphics/gcolor2: obsolete, but I'm not aware of an equivalent GTK+3 > version. > > network/aircrack-ng: at latest version. > network/cowpatty: at latest version, doesn't look like it's developed > anymore. > network/macchanger: at latest version. Mature, hasn't been updated in years. > network/pidgin-extprefs: at latest version, not sure if this package is > still useful. > network/skype4pidgin: at latest version, not sure if this package is > still useful. > network/SoulseekQt: Linux version hasn't been updated since 2018. Better > Linux clients are available. > > office/latexdiff: needs updating. > > perl/perl-Text-Iconv: at latest version. Mature, hasn't been updated in > years. > > python/GeoIP-Python: at latest version. Obsolete, but some software > still depends on it. > python/pyotp: actively developed, needs updating. > > system/hddtemp: no upstream development in years, but an active fork > with a newer version exists. > system/pigz: needs updating. > > > Best regards, > Dominik > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - https://slackbuilds.org/faq/ From pyllyukko at maimed.org Mon Sep 2 19:47:34 2024 From: pyllyukko at maimed.org (pyllyukko) Date: Mon, 2 Sep 2024 22:47:34 +0300 Subject: [Slackbuilds-users] Orphaning my SlackBuilds In-Reply-To: <268ec249-cd11-c4e9-51c3-b578419baa8c@o2.pl> References: <268ec249-cd11-c4e9-51c3-b578419baa8c@o2.pl> Message-ID: Ehlo. On Sun, Sep 01, 2024 at 01:47:47AM +0200, Dominik Drobek wrote: > network/aircrack-ng: at latest version. I can take Aircrack-ng. -- pyllyukko email: PGP: https://keybase.io/pyllyukko twitter: https://twitter.com/pyllyukko -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From matt.egger at gmail.com Tue Sep 3 15:57:15 2024 From: matt.egger at gmail.com (Matt Egger) Date: Tue, 3 Sep 2024 11:57:15 -0400 Subject: [Slackbuilds-users] nginx maintenance In-Reply-To: References: Message-ID: On Sat, Aug 31, 2024 at 1:58?PM Eugen Wissner wrote: > > Larry Hajali (the maintainer) doesn't seem to be active anymore. I've > found a commit message from 2022 about his other script, > multimedia/kodi (commit bce52521d6): > > > Larry has not responded to several email messages and it seems no > > others have been able to reach him as well. > > So I suppose I can take over the maintainence of nginx? > > Probably his other scripts need care too. The list is pretty long. > > keychain > > I can take keychain, but I might not get around to it until next week. -Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From kvngncrlsn at gmail.com Tue Sep 3 22:20:58 2024 From: kvngncrlsn at gmail.com (K. Eugene Carlson) Date: Wed, 4 Sep 2024 07:20:58 +0900 Subject: [Slackbuilds-users] nginx maintenance In-Reply-To: References: Message-ID: I'll take qalculate-gtk and bump the version to match libqalculate. Gene Carlson On Sun, Sep 1, 2024 at 2:58?AM Eugen Wissner wrote: > Hello, > > I'm a bit concerned about nginx not being updated since 1.23.2, because > I use it in production and wouldn't like to get any security > problems because of it. And the last updates weren't done by the actual > maintainer. > > Larry Hajali (the maintainer) doesn't seem to be active anymore. I've > found a commit message from 2022 about his other script, > multimedia/kodi (commit bce52521d6): > > > Larry has not responded to several email messages and it seems no > > others have been able to reach him as well. > > So I suppose I can take over the maintainence of nginx? > > Probably his other scripts need care too. The list is pretty long. > > alienarena > apsw > assaultcube > audiopreview > bitstream > brainparty > cdk > chartgeany > chroma > chromium-bsu > css-parser > cssutils > cubosphere > cuneiform > cuyo > dcadec > dosemu > dukpy > dvblast > easystroke > enca > eyeD3 > filechunkio > flvstreamer > fpconst > gdata > glestae > gst0-python > gtkimageview > html5-parser > http-parser > irrlicht > jag > keychain > kradio > ldns > libaacs > libb64 > libbdplus > libcec > libdc1394 > libdivecomputer > libdvbcsa > libmodplug > libmusicbrainz3 > libnfs > libotf > libunique > lockdev > meandmyshadow > mechanize > megaglest > mini18n > notification-daemon > ois > opensonic > pasang-emas > peg-e > perl-Cstools > perl-IO-CaptureOutput > perl-Unicode-Map > perl-Unicode-Map8 > perl-trayicon > pidgin-toobars > platform > pydf > pymysql > pypoppler > python-distutils-extra > python-libnacl > python-musicbrainz2 > python-sh > python2-MarkupSafe > python2-dateutil > python2-keyczar > qalculate-gtk > qcad > rezerwar > rope > s3cmd > shotcut > sigil > simplejson > soil > speedcrunch > subsurface > sysdig > t4k_common > tinyxml > tinyxml2 > tuxmath > unrardll > wxMaxima > xmlcopyeditor > xvst > yabause > yagf > _______________________________________________ > 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 sbo at linuxgalaxy.org Wed Sep 4 02:52:13 2024 From: sbo at linuxgalaxy.org (KB_SBo) Date: Wed, 04 Sep 2024 02:52:13 +0000 Subject: [Slackbuilds-users] nginx maintenance In-Reply-To: References: Message-ID: On 8/31/24 10:58, Eugen Wissner wrote: > Probably his other scripts need care too. The list is pretty long. > Huh, I wonder what happened to ol' Larry. I'll take a few, related to stuff I already maintain and/or use: assaultcube libaacs libbdplus libdc1394 -kb From rozenglass at protonmail.com Mon Sep 2 10:21:03 2024 From: rozenglass at protonmail.com (Red Rozenglass) Date: Mon, 02 Sep 2024 10:21:03 +0000 Subject: [Slackbuilds-users] Upgrade Request for graphics/optipng, Maintainer Email Bounce Message-ID: Hello fellow builders, I was checking SlackBuilds I use for ones that haven't been updated for a while, having newer versions, and sent Emails to the maintainers of half a dozen of them requesting updates. I sent such an Email today to the maintainer of graphics/optipng, but the Email bounced undeliverable. Perhaps they are subscribed to the list here with a new address. So, here's the request again: > Hello Oleg, > > A more recent version of optipng is available from upstream. > It contains a security fix for a buffer overflow vulnerability. > Would you kindly upgrade the version available on slackbuilds.org > > Current Version: "0.7.7" > Newer Version: "0.7.8" I wish you all a good day, and thank you for your work, Red Rozenglass From willysr at slackbuilds.org Wed Sep 4 13:25:43 2024 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Wed, 4 Sep 2024 20:25:43 +0700 Subject: [Slackbuilds-users] Upgrade Request for graphics/optipng, Maintainer Email Bounce In-Reply-To: References: Message-ID: <341a2e1a-b68a-42ca-a378-8fe3cdaf5c56@slackbuilds.org> > Hello fellow builders, > > I was checking SlackBuilds I use for ones that haven't been > updated for a while, having newer versions, and sent Emails to the > maintainers of half a dozen of them requesting updates. > > I sent such an Email today to the maintainer of graphics/optipng, > but the Email bounced undeliverable. Perhaps they are subscribed to > the list here with a new address. So, here's the request again: > > > Hello Oleg, > > > > A more recent version of optipng is available from upstream. > > It contains a security fix for a buffer overflow vulnerability. > > Would you kindly upgrade the version available on slackbuilds.org > > > > Current Version: "0.7.7" > > Newer Version: "0.7.8" His last commit was 5y ago so i assume he is no longer active if you are using the software, please feel free to take over maintenance -- 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 Wed Sep 4 16:41:24 2024 From: urchlay at slackware.uk (B. Watson) Date: Wed, 4 Sep 2024 12:41:24 -0400 (EDT) Subject: [Slackbuilds-users] Upgrade Request for graphics/optipng, Maintainer Email Bounce In-Reply-To: References: Message-ID: <7f7b8aee-9399-e63a-40cc-d1ebddb20c6@slackware.uk> On Mon, 2 Sep 2024, Red Rozenglass via SlackBuilds-users wrote: > I sent such an Email today to the maintainer of graphics/optipng, > but the Email bounced undeliverable. Perhaps they are subscribed to > the list here with a new address. So, here's the request again: Looking at the git log, Oleg O. Chukaev hasn't updated anything in 5 years. Last activity was: commit 56890e5f36358f6e6c70f553d96e75d4f21cd948 Author: Oleg O. Chukaev Date: Thu Jul 25 02:09:08 2019 -0500 graphics/optipng: Updated for version 0.7.7. So I'd say optipng is up for grabs. If you (Red Rozenglass) want to take it over, you're welcome to. If not, it's open for whoever wants it. Full list of Oleg's builds: biew convmv dbview optipng ssdeep uni2ascii Any takers? From j+sbo-users at maschinengott.de Wed Sep 4 19:22:42 2024 From: j+sbo-users at maschinengott.de (j+sbo-users at maschinengott.de) Date: Wed, 4 Sep 2024 21:22:42 +0200 Subject: [Slackbuilds-users] Upgrade Request for graphics/optipng, Maintainer Email Bounce In-Reply-To: <7f7b8aee-9399-e63a-40cc-d1ebddb20c6@slackware.uk> References: <7f7b8aee-9399-e63a-40cc-d1ebddb20c6@slackware.uk> Message-ID: Hi, for convmv a simple VERSION bump seems to suffice, even though the major version increased. Though I don't have a usecase right now to test it with. (I thought I had.) Cheers, Jay On 04.09.24 18:41, B. Watson wrote: > > > On Mon, 2 Sep 2024, Red Rozenglass via SlackBuilds-users wrote: > >> ?????? I sent such an Email today to the maintainer of graphics/optipng, >> ?but the Email bounced undeliverable.? Perhaps they are subscribed to >> ?the list here with a new address.? So, here's the request again: > > Looking at the git log, Oleg O. Chukaev hasn't updated anything in 5 > years. Last activity was: > > commit 56890e5f36358f6e6c70f553d96e75d4f21cd948 > Author: Oleg O. Chukaev > Date:?? Thu Jul 25 02:09:08 2019 -0500 > > ??? graphics/optipng: Updated for version 0.7.7. > > So I'd say optipng is up for grabs. If you (Red Rozenglass) want to > take it over, you're welcome to. If not, it's open for whoever wants > it. > > Full list of Oleg's builds: > > biew > convmv > dbview > optipng > ssdeep > uni2ascii > > Any takers? > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - https://slackbuilds.org/faq/ > From poprocks at gmail.com Wed Sep 4 21:50:08 2024 From: poprocks at gmail.com (Logan Rathbone) Date: Wed, 4 Sep 2024 17:50:08 -0400 Subject: [Slackbuilds-users] sysprof (was: Re: Had to move off Slackware, so consider all my slackbuilds unmaintained.) In-Reply-To: References: <335ed343-4bb0-479d-bd25-7025b852021a@iotib.net> Message-ID: On Fri, Sep 01, 2023 at 12:41:56PM EDT, Charadon via SlackBuilds-users wrote: > On 8/27/23 20:26, Willy Sudiarto Raharjo wrote: > > > Recently I got an Intel Arc GPU, and unfortunately it didn't work at > > > all on Slackware, even with -current. Therefore I had to distro hop > > > to Void Linux. Because of this, it's probably safe to assume that > > > all my packages are unmaintained as I have no time to update/test > > > them if my main workstation is no longer running Slackware. > > > > > > Hopefully, one day I can return to Slackware when Intel Arc support > > > reaches it. (I think it's just some build options not turned on in > > > Mesa and the Kernel, but I don't want to keep recompiling those.) > > > > Here are his scripts [snip] > > sysprof I'll take sysprof - I couldn't get it to build on 15.0 without a couple of modifications. I see Charadon posted around this time last year, but has posted since, so I thought I'd run it by the list. From dev at iotib.net Wed Sep 4 22:49:54 2024 From: dev at iotib.net (Charadon) Date: Wed, 4 Sep 2024 18:49:54 -0400 Subject: [Slackbuilds-users] sysprof In-Reply-To: References: <335ed343-4bb0-479d-bd25-7025b852021a@iotib.net> Message-ID: I thought Bob Funk took maintainership of it? -----Original Message----- From: Logan Rathbone [mailto:poprocks at gmail.com] Sent: Wednesday, September 04, 2024 05:50 PM -04 To: SlackBuilds.org Users List Cc: Charadon Subject: sysprof (was: Re: Had to move off Slackware, so consider all my slackbuilds unmaintained.) On Fri, Sep 01, 2023 at 12:41:56PM EDT, Charadon via SlackBuilds-users wrote: On 8/27/23 20:26, Willy Sudiarto Raharjo wrote: Recently I got an Intel Arc GPU, and unfortunately it didn't work at all on Slackware, even with -current. Therefore I had to distro hop to Void Linux. Because of this, it's probably safe to assume that all my packages are unmaintained as I have no time to update/test them if my main workstation is no longer running Slackware. >> Hopefully, one day I can return to Slackware when Intel Arc support reaches it. (I think it's just some build options not turned on in Mesa and the Kernel, but I don't want to keep recompiling those.) > Here are his scripts [snip] sysprof I'll take sysprof - I couldn't get it to build on 15.0 without a couple of modifications. I see Charadon posted around this time last year, but has posted since, so I thought I'd run it by the list. From bobfunk11 at gmail.com Thu Sep 5 00:01:04 2024 From: bobfunk11 at gmail.com (Bob Funk) Date: Wed, 4 Sep 2024 19:01:04 -0500 Subject: [Slackbuilds-users] sysprof In-Reply-To: References: <335ed343-4bb0-479d-bd25-7025b852021a@iotib.net> Message-ID: Yes I took over sysprof last year when Charadon sent out that email (Sept 1, 2023). I wasn't planning on doing much with it, along with the rest of the gnome slackbuilds, until Slackware moves on to 15.1 and I can push a lot of builds forward with updates. Is there a problem with the build now? Last I checked it was building fine. Regards, Bob On Wed, Sep 4, 2024, 17:49 Charadon via SlackBuilds-users < slackbuilds-users at slackbuilds.org> wrote: > I thought Bob Funk took maintainership of it? > > > -----Original Message----- > From: Logan Rathbone [mailto:poprocks at gmail.com] > Sent: Wednesday, September 04, 2024 05:50 PM -04 > To: SlackBuilds.org Users List > Cc: Charadon > Subject: sysprof (was: Re: Had to move off Slackware, so consider all my > slackbuilds unmaintained.) > > On Fri, Sep 01, 2023 at 12:41:56PM EDT, Charadon via SlackBuilds-users > wrote: > On 8/27/23 20:26, Willy Sudiarto Raharjo wrote: > Recently I got an Intel Arc GPU, and unfortunately it didn't work at > all on Slackware, even with -current. Therefore I had to distro hop > to Void Linux. Because of this, it's probably safe to assume that > all my packages are unmaintained as I have no time to update/test > them if my main workstation is no longer running Slackware. > >> > Hopefully, one day I can return to Slackware when Intel Arc support > reaches it. (I think it's just some build options not turned on in > Mesa and the Kernel, but I don't want to keep recompiling those.) > > > Here are his scripts > [snip] > sysprof > > I'll take sysprof - I couldn't get it to build on 15.0 without a couple > of modifications. I see Charadon posted around this time last year, but > has posted since, so I thought I'd run it by the list. > _______________________________________________ > 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 poprocks at gmail.com Thu Sep 5 01:29:56 2024 From: poprocks at gmail.com (Logan Rathbone) Date: Wed, 4 Sep 2024 21:29:56 -0400 Subject: [Slackbuilds-users] sysprof In-Reply-To: References: <335ed343-4bb0-479d-bd25-7025b852021a@iotib.net> Message-ID: Ah sorry for the confusion. I figured out why it would build on 15.0 but not on my system without a change to the Slackbuild. I forgot that I updated meson to 1.0 on my local system. There are some stale options in the SB - ../meson.build:1:0: ERROR: Unknown options: "agent, examples, gtk, install-static, tools" --> some of these have been deleted, others have been changed to 'enable_X'. I'm guessing this would just produce a warning on meson 0.59 and produces a fatal error on later versions. So likely false alarm on the build not working on 15.0. It wouldn't hurt to update the Sb to remove the staie options though. Cheers, Logan On Wed, Sep 4, 2024 at 8:01?PM Bob Funk wrote: > Yes I took over sysprof last year when Charadon sent out that email (Sept > 1, 2023). > > I wasn't planning on doing much with it, along with the rest of the gnome > slackbuilds, until Slackware moves on to 15.1 and I can push a lot of > builds forward with updates. > > Is there a problem with the build now? Last I checked it was building fine. > > > Regards, > > Bob > > On Wed, Sep 4, 2024, 17:49 Charadon via SlackBuilds-users < > slackbuilds-users at slackbuilds.org> wrote: > >> I thought Bob Funk took maintainership of it? >> >> >> -----Original Message----- >> From: Logan Rathbone [mailto:poprocks at gmail.com] >> Sent: Wednesday, September 04, 2024 05:50 PM -04 >> To: SlackBuilds.org Users List >> Cc: Charadon >> Subject: sysprof (was: Re: Had to move off Slackware, so consider all my >> slackbuilds unmaintained.) >> >> On Fri, Sep 01, 2023 at 12:41:56PM EDT, Charadon via SlackBuilds-users >> wrote: >> On 8/27/23 20:26, Willy Sudiarto Raharjo wrote: >> Recently I got an Intel Arc GPU, and unfortunately it didn't work at >> all on Slackware, even with -current. Therefore I had to distro hop >> to Void Linux. Because of this, it's probably safe to assume that >> all my packages are unmaintained as I have no time to update/test >> them if my main workstation is no longer running Slackware. >> >> >> Hopefully, one day I can return to Slackware when Intel Arc support >> reaches it. (I think it's just some build options not turned on in >> Mesa and the Kernel, but I don't want to keep recompiling those.) >> > >> Here are his scripts >> [snip] >> sysprof >> >> I'll take sysprof - I couldn't get it to build on 15.0 without a couple >> of modifications. I see Charadon posted around this time last year, but >> has posted since, so I thought I'd run it by the list. >> _______________________________________________ >> SlackBuilds-users mailing list >> SlackBuilds-users at slackbuilds.org >> https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users >> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ >> FAQ - https://slackbuilds.org/faq/ >> >> _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - https://slackbuilds.org/faq/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brandon.pribs11 at gmail.com Thu Sep 5 19:54:56 2024 From: brandon.pribs11 at gmail.com (Brandon Pribula) Date: Thu, 5 Sep 2024 12:54:56 -0700 Subject: [Slackbuilds-users] Please Remove pigz.tar.gz from Pending Message-ID: Hello, I recently took over maintenance of pigz and submitted a new package with updated maintainer info earlier this week. I was able to do a version bump to 2.8 today. I was wondering if I could have pigz removed from pending so I can submit the new one? Brandon -------------- next part -------------- An HTML attachment was scrubbed... URL: From brandon.pribs11 at gmail.com Thu Sep 5 19:55:10 2024 From: brandon.pribs11 at gmail.com (Brandon Pribula) Date: Thu, 5 Sep 2024 12:55:10 -0700 Subject: [Slackbuilds-users] pigz New Download Source Message-ID: Hello, I changed the download source for pigz to github so you can remove it from https://slackware.uk/~urchlay/src/ if you like. Brandon -------------- next part -------------- An HTML attachment was scrubbed... URL: From urchlay at slackware.uk Thu Sep 5 20:03:12 2024 From: urchlay at slackware.uk (B. Watson) Date: Thu, 5 Sep 2024 16:03:12 -0400 (EDT) Subject: [Slackbuilds-users] Please Remove pigz.tar.gz from Pending In-Reply-To: References: Message-ID: <14381e4-c3c9-e2b4-d1f3-12d9e5adee73@slackware.uk> On Thu, 5 Sep 2024, Brandon Pribula wrote: > I recently took over maintenance of pigz and submitted a new package with updated maintainer info earlier this week. I was able to do a version bump to 2.8 today. I was wondering if > I could have pigz removed from pending so I can submit the new one? Done. From brandon.pribs11 at gmail.com Thu Sep 5 20:04:01 2024 From: brandon.pribs11 at gmail.com (Brandon Pribula) Date: Thu, 5 Sep 2024 13:04:01 -0700 Subject: [Slackbuilds-users] Please Remove pigz.tar.gz from Pending In-Reply-To: <14381e4-c3c9-e2b4-d1f3-12d9e5adee73@slackware.uk> References: <14381e4-c3c9-e2b4-d1f3-12d9e5adee73@slackware.uk> Message-ID: On Thu, Sep 5, 2024 at 1:03?PM B. Watson wrote: > > > On Thu, 5 Sep 2024, Brandon Pribula wrote: > > > I recently took over maintenance of pigz and submitted a new package > with updated maintainer info earlier this week. I was able to do a version > bump to 2.8 today. I was wondering if > > I could have pigz removed from pending so I can submit the new one? > > Done. > Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dev at iotib.net Fri Sep 6 17:51:35 2024 From: dev at iotib.net (Charadon) Date: Fri, 6 Sep 2024 13:51:35 -0400 Subject: [Slackbuilds-users] Can I take over maintainership of perl-local-lib? Message-ID: I haven't been able to get in contact with the maintainer, and it looks like he hasn't contributed since 2017. Right now it's extremely out of date, fails to build on -current, and is considered x86_64 even though it should be noarch. I have confirmed the latest version of perl-local-lib *does* build on 15.0 From urchlay at slackware.uk Fri Sep 6 18:57:28 2024 From: urchlay at slackware.uk (B. Watson) Date: Fri, 6 Sep 2024 14:57:28 -0400 (EDT) Subject: [Slackbuilds-users] Can I take over maintainership of perl-local-lib? In-Reply-To: References: Message-ID: <6e3d35c1-2f97-9f77-b41a-b277e7c4bb8a@slackware.uk> On Fri, 6 Sep 2024, Charadon via SlackBuilds-users wrote: > I haven't been able to get in contact with the maintainer, and it looks like > he hasn't contributed since 2017. Right now it's extremely out of date, fails > to build on -current, and is considered x86_64 even though it should be > noarch. I have confirmed the latest version of perl-local-lib *does* build on > 15.0 Go for it. Send an update when you're ready. From dev at iotib.net Fri Sep 6 19:36:15 2024 From: dev at iotib.net (Charadon) Date: Fri, 6 Sep 2024 15:36:15 -0400 Subject: [Slackbuilds-users] Can I take over maintainership of perl-local-lib? In-Reply-To: <6e3d35c1-2f97-9f77-b41a-b277e7c4bb8a@slackware.uk> References: <6e3d35c1-2f97-9f77-b41a-b277e7c4bb8a@slackware.uk> Message-ID: <8b434cef-9df5-41db-8976-526e48a203b3@iotib.net> Sounds good, i'll probably get it updated sometime next week =) -----Original Message----- From: B. Watson [mailto:urchlay at slackware.uk] Sent: Friday, September 06, 2024 02:57 PM -04 To: Charadon via SlackBuilds-users Cc: Charadon Subject: Re: [Slackbuilds-users] Can I take over maintainership of perl-local-lib? On Fri, 6 Sep 2024, Charadon via SlackBuilds-users wrote: I haven't been able to get in contact with the maintainer, and it looks like he hasn't contributed since 2017. Right now it's extremely out of date, fails to build on -current, and is considered x86_64 even though it should be noarch. I have confirmed the latest version of perl-local-lib *does* build on 15.0 Go for it. Send an update when you're ready. From urchlay at slackware.uk Fri Sep 6 20:03:53 2024 From: urchlay at slackware.uk (B. Watson) Date: Fri, 6 Sep 2024 16:03:53 -0400 (EDT) Subject: [Slackbuilds-users] Can I take over maintainership of perl-local-lib? In-Reply-To: <8b434cef-9df5-41db-8976-526e48a203b3@iotib.net> References: <6e3d35c1-2f97-9f77-b41a-b277e7c4bb8a@slackware.uk> <8b434cef-9df5-41db-8976-526e48a203b3@iotib.net> Message-ID: <7d50b32c-cd2e-653b-6b9a-fd9a319c11e5@slackware.uk> On Fri, 6 Sep 2024, Charadon via SlackBuilds-users wrote: > Sounds good, i'll probably get it updated sometime next week =) Since we have a weekly update tonight, I'm going to go ahead and change the .info file for perl-local-lib, put your name and email there. After that, you can take as much time as needed to send your update. From willysr at slackbuilds.org Sat Sep 7 02:24:37 2024 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sat, 7 Sep 2024 09:24:37 +0700 Subject: [Slackbuilds-users] Updates - 20240907.1 Message-ID: <5a7e38a8-ed7e-4a62-83fb-cd4e65acb211@slackbuilds.org> Sat Sep 7 02:10:43 UTC 2024 academic/WordNet: New maintainer, fixes. academic/fet: Updated for version 6.24.1. academic/nco: Updated for version 5.2.8. academic/qalculate-gtk: Updated for version 3.22.0; new maintainer. academic/reduce-algebra: Orphaned. academic/zotero: Updated for version 7.0.3. audio/butt: Updated for version 0.1.39. audio/qmmp-plugin-pack-qt5: Updated for version 1.6.2. audio/qmmp-qt5: Updated for version 1.6.9. desktop/hyfetch: Rename typing-extensions dep desktop/kanshi: Added (Dynamic display configuration). desktop/myGtkMenu: Updated for version 1.4, new maintainer. desktop/nwg-panel: Updated for version 0.9.38. desktop/nwg-shell-config: Updated for version 0.5.46. development/SQLAlchemy: Rename typing-extensions dep development/aws-cdk: Updated for version 2.156.0. development/azuredatastudio: Updated for version 1.49.1. development/cargo-c: Updated for version 0.10.4. development/composer: Updated for version 2.7.9 development/cunit: New maintainer and patches. development/dpkg: Updated for version 1.22.11. development/hopper: Removed. development/hugo: Updated for version 0.134.1. development/jupyter-nbconvert: Update dependency. development/jupyter_server_terminals: Update dependency. development/mongodb-compass: Updated for version 1.44.0. development/poedit: Updated for version 3.5. development/postman: Updated for version 11.10.0 development/protobuf3: Updated for version 28.0. development/pulsar: Updated for version 1.120.0. development/rider: Updated for version 2024.2.3. development/sbcl: Updated for version 2.4.8. development/spyder: Add further commenting development/ucpp: New maintainer. development/vscode-bin: Updated for version 1.93.0. development/zulu-openjdk11: Updated for version 11.0.24. development/zulu-openjdk17: Updated for version 17.0.12. development/zulu-openjdk21: Updated for version 21.0.4. development/zulu-openjdk6: Allow profile script to override jdk. development/zulu-openjdk7: Allow profile script to override jdk. development/zulu-openjdk8: Updated for version 8.0.422. games/OpenXcom: New maintainer. games/Tempus-Irae: New maintainer. games/assaultcube: New maintainer games/ddnet: Updated for version 18.5 games/ecwolf: Updated for version 1.4.1, new maintainer. games/marathon-eternal-data: Updated for version 1.2.1, new maint. games/marathon-evil-data: New maintainer. games/marathon-phoenix-data: Updated for version 1.4.2, new maint. games/marathon-red-data: New maintainer. games/marathon-rubicon-data: Updated for v20240421, new maint. games/opensonic: New maintainer. games/pinball: New maintainer. games/wolfmame: Updated for version 0.269. gis/python3-shapely: Updated for version 2.0.6. graphics/feh: Updated for version 3.10.3, new maintainer. graphics/gcolor2: New maintainer. graphics/optipng: Updated for version 0.7.8, new maintainer. graphics/synfig: Updated for version 1.5.3 graphics/synfigstudio: Updated for version 1.5.3 graphics/vuescan: Updated MD5SUMs. graphics/vuescan: Updated MD5SUMs. ham/CubicSDR: Update dependency. ham/fldigi: Updated for version 4.2.05. libraries/ETL: Updated for version 1.5.3. libraries/gumbo-parser: New maintainer. libraries/libaacs: New maintainer libraries/libbdplus: New maintainer libraries/libcec: New maintainer libraries/libcpuid: Updated for version 0.7.0. libraries/libdc1394: New maintainer libraries/liblqr: Fix build. libraries/liblqr: Reverted for version 0.4.2. libraries/libnfs: Version bump to 5.0.2 + New maintainer libraries/libscfg: Added (C library for a simple configuration file format). libraries/libsoup3: Updated for version 3.6.0. libraries/libspiro: Updated for version 20240903. libraries/libxnvctrl: Updated for version 560.35.03. libraries/platform: New maintainer libraries/pytorch: Rename typing-extensions dep libraries/srt: Updated for version 1.5.3 libraries/tinyxml2: New maintainer libraries/tinyxml: New maintainer libraries/wxWidgets: Add webkit2gtk as mandatory dep. misc/bitwarden-desktop: updated for version 2024.8.2 misc/dbview: New maintainer. misc/lppf: New maintainer. misc/uni2ascii: Updated for version 4.20, new maintainer. multimedia/opera-ffmpeg-codecs: Updated for version 0.91.0. multimedia/picard: Version bump to 2.12.3 multimedia/plasmatube: Removed (Request by maintainer). multimedia/plexmediaserver: Updated for version 1.40.5.8921_836b34c27. multimedia/svt-av1: Updated for version 2.2.1. multimedia/vapoursynth: Add missing file. network/UDR: Orphaned. network/aircrack-ng: New maintainer. network/ani-cli: Updated for version 4.9. network/brave-browser: Updated for version 1.69.162. network/connman: Updated for version 1.43. network/discord: Version bump to 0.0.67 network/dnscrypt-proxy: Update Quad9 Signing key. network/goimapnotify: Updated for version 2.3.16. network/macchanger: New maintainer. network/microsoft-edge: Updated for version 128.0.2739.67. network/mullvadvpn-app: Updated for version 2024.5. network/nextcloud-desktop: Updated for version 3.13.3. network/nginx: Updated for version 1.26.2. New maintainer network/nordvpn: Updated for version 3.18.5. network/opera: Updated for version 113.0.5230.55. network/signal-desktop: Updated for version 7.23.0. network/tailscale: Updated for version 1.72.1. network/teamviewer: Updated for version 15.57.3. network/telegram: Updated for version 5.5.0. network/teleport-connect: Updated for version 16.2.0. network/tor-browser: Updated for version 13.5.3. network/vivaldi: Updated for version 6.9.3447.37. office/glow: Updated for version 2.0.0. perl/perl-B-Keywords: Added (Reserved barewords and symbol names). perl/perl-B-Lint: Added (Perl lint). perl/perl-ExtUtils-Helpers: Updated for version 0.028. perl/perl-Lingua-EN-Inflect: Added (Convert singular to plural). perl/perl-Module-Build-Tiny: Updated for version 0.050. perl/perl-PAR-Dist: Updated for version 0.53. perl/perl-PPIx-QuoteLike: Added (Parse Perl string literals). perl/perl-PPIx-Regexp: Added (Parse regular expressions). perl/perl-PPIx-Utils: Added (Utility functions for PPI). perl/perl-Perl-Critic: Added (static analyzer for Perl). perl/perl-Perl-Tidy: Added (a source code formatter for Perl). perl/perl-Pod-Spell: Added (Pod::Spell perl module). perl/perl-String-Format: Added (sprintf-like string formatting). perl/perl-file-mimeinfo: Updated for version 0.35. perl/perl-local-lib: New maintainer. python/asgiref: Rename typing-extensions dep python/cryptography: Updated for version 43.0.1. python/ipython: Rename typing-extensions dep python/mypy: Rename typing-extensions dep python/python2-pytz: Added (Python2 version of pytz). python/python3-PyMuPDF: Updated for version 1.24.10. python/python3-PyPDF2: Rename typing-extensions dep python/python3-annotated-types: Rename typing-extensions dep python/python3-astroid: Rename typing-extensions dep python/python3-async-timeout: Rename typing-extensions dep python/python3-black: Rename typing-extensions dep python/python3-cattrs: Rename typing-extensions dep python/python3-celery: Rename typing-extensions dep python/python3-dep-logic: Version bump to 0.4.5 python/python3-dogpile.cache: Rename typing-extensions dep python/python3-executing: Version bump to 2.1.0 python/python3-jaraco.functools: Rename typing-extensions dep python/python3-kiwisolver: Version bump to 1.4.7 python/python3-mailman: Rename typing-extensions dep python/python3-pandocfilters: Added (Python3 of pandocfilters). python/python3-pipx: Updated for version 1.7.1. python/python3-psycopg3: Rename typing-extensions dep python/python3-pytz: Added (Python3 version of pytz). python/python3-setuptools-rust-opt: Rename typing-extensions dep python/python3-setuptools-scm-opt: Rename typing-extensions dep python/python3-terminado: Added (Python3 version of terminado). python/python3-testpath: Added (Python3 version of testpath). python/python3-types-python-dateutil: Update for 2.9.0.20240906 python/python3-typing-extensions: Added (Python3 version of typing-extensions). python/python3-unearth: Version bump to 0.17.2 python/python3-validators: Version bump to 0.34.0 python/python3-watchdog: Update for 5.0.1 python/python3-websockets: Updated for version 13.0.1. python/python3-yarl: Rename typing-extensions dep python/python3-yarl: Updated for version 1.9.8 python/tinycss2: Update for 1.3.0 (+new maintainer) python/typing-extensions: Removed (renamed to python3-typing-extensions) ruby/ruby-build: Updated for version 20240903. system/Iosevka-aile: Updated for version 31.5.0. system/Iosevka-etoile: Updated for version 31.5.0. system/Iosevka-slab: Updated for version 31.5.0. system/Iosevka: Updated for version 31.5.0. system/android-udev-rules: Updated for version 2024.08.29. system/biew: New maintainer. system/bleachbit: Updated for version 4.6.1. system/borgmatic: Update for version 1.8.14 system/clamav: Updated for version 1.4.1. system/conky: Updated for version 1.21.7. system/convmv: Updated for version 2.05, new maintainer. system/ecm-tools: New maintainer. system/edk2-ovmf: Updated for version 202408. system/fakeroot: Update for version 1.36 system/game-devices-udev: Added (udev rules for game-devices). system/gpart: Fix maintainer/email in .info file. system/hivex: Updated for version 1.3.24. system/intelmas: Orphaned. system/jenkins: Updated for version 2.462.2. system/kitty: Updated for version 0.36.2 system/linkchecker: Updated for version 10.4.0. system/locust: Rename typing-extensions dep system/locust: Updated for version 2.31.5. system/lolcat: Updated for version 1.5. system/maxcso: Updated for version 1.13.0, new maintainer. system/nvidia-legacy470-driver: Fix build. system/pigz: New maintainer. system/pigz: Updated for version 2.8. system/rsyslog: Updated for version 8.2408.0. system/sakura: Updated for version 3.8.8. system/ssdeep: Updated for version 2.14.1, new maintainer. system/sst: Updated for version 1.15. system/tpm: New maintainer. system/wiimms-iso-tools: Updated for version 3.05a, new maintainer. +--------------------------+ -- Willy Sudiarto Raharjo -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From dchmelik at gmail.com Sat Sep 7 04:51:14 2024 From: dchmelik at gmail.com (dchmelik at gmail.com) Date: Fri, 6 Sep 2024 21:51:14 -0700 Subject: [Slackbuilds-users] game-devices-udev (Re: Updates - 20240907.1) In-Reply-To: <5a7e38a8-ed7e-4a62-83fb-cd4e65acb211@slackbuilds.org> References: <5a7e38a8-ed7e-4a62-83fb-cd4e65acb211@slackbuilds.org> Message-ID: <9aaf6b7e-8ab0-58e4-b6dd-6d1baecdc4aa@gmail.com> On 9/6/24 7:24 PM, Willy Sudiarto Raharjo wrote: > Sat Sep? 7 02:10:43 UTC 2024 > [...] system/game-devices-udev: Added (udev rules for game-devices) [...] Would it be possible to use Elecom or Tomee USB controllers if it'd improve them?? I think one works as-is, but the other brand has about two extra buttons.? They're like Super Nintendo Entertainment System (SNES) controllers with the one with extra buttons supposedly being able to do things like let you program to repeatedly 'press' a button faster than human.? Maybe it'd work on Apple or Windows but I never got that to work on GNU/Linux... don't know that udev is what it needs, or just drivers?? I also have some old gameport (alternatively MIDI port) controllers and could still hook up a port in a slot... From jebrhansen+SBo at gmail.com Sat Sep 7 04:56:28 2024 From: jebrhansen+SBo at gmail.com (Jeremy Hansen) Date: Fri, 6 Sep 2024 21:56:28 -0700 Subject: [Slackbuilds-users] game-devices-udev (Re: Updates - 20240907.1) In-Reply-To: <9aaf6b7e-8ab0-58e4-b6dd-6d1baecdc4aa@gmail.com> References: <5a7e38a8-ed7e-4a62-83fb-cd4e65acb211@slackbuilds.org> <9aaf6b7e-8ab0-58e4-b6dd-6d1baecdc4aa@gmail.com> Message-ID: On Fri, Sep 6, 2024, 9:51?PM wrote: > On 9/6/24 7:24 PM, Willy Sudiarto Raharjo wrote: > > Sat Sep 7 02:10:43 UTC 2024 > > [...] system/game-devices-udev: Added (udev rules for game-devices) [...] > Would it be possible to use Elecom or Tomee USB controllers if it'd > improve them? I think one works as-is, but the other brand has about > two extra buttons. They're like Super Nintendo Entertainment System > (SNES) controllers with the one with extra buttons supposedly being able > to do things like let you program to repeatedly 'press' a button faster > than human. Maybe it'd work on Apple or Windows but I never got that to > work on GNU/Linux... don't know that udev is what it needs, or just > drivers? I also have some old gameport (alternatively MIDI port) > controllers and could still hook up a port in a slot... > This was all based on the work from https://codeberg.org/fabiscafe/game-devices-udev with udev rules created or submitted to them. If there are suggestions or updates for udev rules, they should go to them, which can then be updated in future revisions. If one of these rules conflict with devices already on your system, your can disable that brand's rule by following the steps in the README (or replace it with a same-named rule in /etc/udev/rules.d/ that I forgot to mention in the README). Jeremy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dchmelik at gmail.com Sat Sep 7 08:23:26 2024 From: dchmelik at gmail.com (dchmelik at gmail.com) Date: Sat, 7 Sep 2024 01:23:26 -0700 Subject: [Slackbuilds-users] oidentd Message-ID: <3e2eff12-b47e-4b55-151d-3519c3400aa0@gmail.com> With oidentd apparently not being maintained, it was suggested I take it due to formerly maintaining (discontinued) iseeque (ICQ). The thing is, ICQ is simple--just needing interface settings, at least? username, password--not requiring knowing networking, needed in testing oidentd (every time I have to ask their IRC channel some hours/days/weeks).? ICQ was simple to use; oidentd is complicated to use (maybe unless you were using Internet before the world wide web (WWW)) so I won't takeover oidentd, nor plan to add new network-related software.? If I do, they'd only be a game and/or easy plugins to libpurple (BitlBee, Pidgin) that similarly require little/no networking knowledge (mostly interface aspects/improvements, but I don't consider myself a GUI expert either, despite it's a little easier). ??? If anyone uses oidentd on servers, please consider taking it over.? Right now, users can just increment the version number to use oidentd.SlackBuild with several new (minor and major 3.1.0) versions of the source code.? There was some configuration change but I guess you can process that with slackpkg new-config. From urchlay at slackware.uk Sat Sep 7 08:37:38 2024 From: urchlay at slackware.uk (B. Watson) Date: Sat, 7 Sep 2024 04:37:38 -0400 (EDT) Subject: [Slackbuilds-users] oidentd In-Reply-To: <3e2eff12-b47e-4b55-151d-3519c3400aa0@gmail.com> References: <3e2eff12-b47e-4b55-151d-3519c3400aa0@gmail.com> Message-ID: <596142be-9cad-5899-4789-35596eec1ccb@slackware.uk> On Sat, 7 Sep 2024, dchmelik at gmail.com wrote: > ??? If anyone uses oidentd on servers, please consider taking it over.? oidentd is maintained by Mario Preksavec... who appears to be an active maintainer (last activity was July 2, 2024, taking over as maintainer of rtl-sdr). Have you contacted him? From dchmelik at gmail.com Sat Sep 7 09:01:46 2024 From: dchmelik at gmail.com (dchmelik at gmail.com) Date: Sat, 7 Sep 2024 02:01:46 -0700 Subject: [Slackbuilds-users] oidentd In-Reply-To: <596142be-9cad-5899-4789-35596eec1ccb@slackware.uk> References: <3e2eff12-b47e-4b55-151d-3519c3400aa0@gmail.com> <596142be-9cad-5899-4789-35596eec1ccb@slackware.uk> Message-ID: <04019ef7-5ade-444d-e2e5-fdb841e31086@gmail.com> On 9/7/24 1:37 AM, B. Watson wrote: > On Sat, 7 Sep 2024, dchmelik at gmail.com wrote: >> ??? If anyone uses oidentd on servers, please consider taking it over. > > oidentd is maintained by Mario Preksavec... who appears to be an > active maintainer (last activity was July 2, 2024, taking over as > maintainer of rtl-sdr). Have you contacted him? I mentioned doing so, on this mailing list, some months/years ago, saying he is thinking of no longer maintaining it, and it's some versions behind.? I think you're the person who replied to that and suggested I take it over (I'm not going to). From urchlay at slackware.uk Sat Sep 7 09:32:32 2024 From: urchlay at slackware.uk (B. Watson) Date: Sat, 7 Sep 2024 05:32:32 -0400 (EDT) Subject: [Slackbuilds-users] oidentd In-Reply-To: <04019ef7-5ade-444d-e2e5-fdb841e31086@gmail.com> References: <3e2eff12-b47e-4b55-151d-3519c3400aa0@gmail.com> <596142be-9cad-5899-4789-35596eec1ccb@slackware.uk> <04019ef7-5ade-444d-e2e5-fdb841e31086@gmail.com> Message-ID: <1b4a8a59-9d62-2126-9357-9ae15899d23b@slackware.uk> On Sat, 7 Sep 2024, dchmelik at gmail.com wrote: > On 9/7/24 1:37 AM, B. Watson wrote: >> On Sat, 7 Sep 2024, dchmelik at gmail.com wrote: >>> ??? If anyone uses oidentd on servers, please consider taking it over. >> >> oidentd is maintained by Mario Preksavec... who appears to be an >> active maintainer (last activity was July 2, 2024, taking over as >> maintainer of rtl-sdr). Have you contacted him? > > I mentioned doing so, on this mailing list, some months/years ago, saying he > is thinking of no longer maintaining it, and it's some versions behind.? I > think you're the person who replied to that and suggested I take it over (I'm > not going to). OK, yes, I do remember suggesting that. I said it because apparently you are the only person in the SlackBuilds universe who cares about oidentd (its own maintainer doesn't, apparently). Also in your previous email, you stated that oident.SlackBuild can build the newer versions of oidentd just by updating VERSION. So, it would make sense for you to take over the script, update VERSION, make sure the new version actually runs, and call it a day. What do you think a maintainer *does*, exactly? Another thought: I have no idea what you're using oidentd for. The usual use is for IRC, but don't think modern IRC networks actually require it. At least libera doesn't, I know for a fact. Slackware already ships two identd's: the regular /usr/sbin/in.identd, and a "fakeidentd" inside the /usr/share/mkinitrd/initrd-tree.tar.gz tarball (which is just a symlink to a busybox binary, also found in that tarball). Maybe one of these would serve your needs? From dominik.drobek at o2.pl Sat Sep 7 13:57:28 2024 From: dominik.drobek at o2.pl (Dominik Drobek) Date: Sat, 7 Sep 2024 15:57:28 +0200 Subject: [Slackbuilds-users] Orphaning my SlackBuilds In-Reply-To: <9a9bc805-3447-4c4f-b982-dee09a9bde66@o2.pl> References: <268ec249-cd11-c4e9-51c3-b578419baa8c@o2.pl> <2c50b074-88cf-cf11-86e9-3ed98bbb39d8@slackware.uk> <9a9bc805-3447-4c4f-b982-dee09a9bde66@o2.pl> Message-ID: Status after last update: Scripts with new maintainers: games/OpenXcom -> B. Watson graphics/gcolor2 -> B. Watson network/aircrack-ng -> pyllyukko network/macchanger -> B. Watson system/pigz -> Brandon Pribula Handed over, but .info files not updated yet: desktop/xfce4-volumed-pulse -> Nick Smallbone office/latexdiff -> Andrei Rabusov system/hddtemp -> Diniz Bortolotto Orphaned: audio/MP3Diags network/cowpatty network/pidgin-extprefs network/skype4pidgin network/SoulseekQt perl/perl-Text-Iconv python/GeoIP-Python python/pyotp So I'll go ahead and make a GitHub PR to mark the orphaned scripts as such. Regards, Dominik From arkadiusz at drabczyk.org Sat Sep 7 17:27:34 2024 From: arkadiusz at drabczyk.org (Arkadiusz Drabczyk) Date: Sat, 7 Sep 2024 19:27:34 +0200 Subject: [Slackbuilds-users] RFC: Proposed mandb additions to doinst/douninst template In-Reply-To: References: Message-ID: On Sun, Aug 25, 2024 at 01:42:11PM -0400, B. Watson wrote: > > > On Sun, 25 Aug 2024, Arkadiusz Drabczyk wrote: > > > > ### in doinst.sh: > > > # DESCRIPTION: Updates the man database (for "man -k"). > > > # Use one "man -f" command for each man page in the package. > > > if [ -x usr/bin/mandb ]; then > > > usr/bin/mandb -f usr/man/man1/program.1.gz > > > fi > > > > so there is no easier way than to run mandb for each manpage > > separately? > > No easier way that I've found yet. > > Well, "mandb -c" in doinst.sh would be easier, but it takes too long > to run on Slackware 15.0. Out of curiosity I checked how Debian is managing manpages because I remember "Processing triggers for man-db" being printed every time a package is installed and I verified that man -k works immediately after the package is installed: ja at debian:~$ man -k offlineimap offlineimap: nothing appropriate. ja at debian:~$ sudo apt-get -y install offlineimap3 Reading package lists... Done Building dependency tree... Done Reading state information... Done Suggested packages: python3-gssapi The following NEW packages will be installed: offlineimap3 0 upgraded, 1 newly installed, 0 to remove and 64 not upgraded. Need to get 0 B/155 kB of archives. After this operation, 636 kB of additional disk space will be used. Selecting previously unselected package offlineimap3. (Reading database ... 158999 files and directories currently installed.) Preparing to unpack .../offlineimap3_0.0~git20211018.e64c254+dfsg-2_all.deb ... Unpacking offlineimap3 (0.0~git20211018.e64c254+dfsg-2) ... Setting up offlineimap3 (0.0~git20211018.e64c254+dfsg-2) ... Processing triggers for man-db (2.11.2-2) ... ja at debian:~$ man -k offlineimap offlineimap (1) - Synchronize mailboxes and Maildirs both ways or one either way. offlineimapui (7) - The User Interfaces To my surprise mandb is run only with -pq parameters in /var/lib/dpkg/info/man-db.postinst. Refreshing man database can work like that only because dpkg does not change the mtime of existing directories by not extracting directories that already exist on the filesystem https://salsa.debian.org/dpkg-team/dpkg/-/blob/main/src/main/archives.c?ref_type=heads#L954. If that check didn't exist mtime of /usr/share/man/man1 would change to time saved in the tarball inside .deb as it happens on Slackware, for example 2023-01-10: ja at debian:~$ apt-get -y download offlineimap3 Get:1 http://deb.debian.org/debian bookworm/main amd64 offlineimap3 all 0.0~git20211018.e64c254+dfsg-2 [155 kB] Fetched 155 kB in 0s (980 kB/s) ja at debian:~$ ar x offlineimap3_0.0~git20211018.e64c254+dfsg-2_all.deb ja at debian:~$ tar tvf data.tar.xz | grep usr/share/man/man1/$ drwxr-xr-x root/root 0 2023-01-10 16:44 ./usr/share/man/man1/ But with the check in place it doesn't - to make sure that tests make sense remove /var/lib/man-db/auto-update to prevent /var/lib/dpkg/info/man-db.postinst from running: ja at debian:~$ sudo rm /var/lib/man-db/auto-update ja at debian:~$ ls --full-time -hld /usr/share/man/man1 drwxr-xr-x 2 root root 68K 2024-09-07 12:38:34.370247176 -0400 /usr/share/man/man1 ja at debian:~$ sudo apt-get -y install offlineimap3 Reading package lists... Done Building dependency tree... Done Reading state information... Done Suggested packages: python3-gssapi The following NEW packages will be installed: offlineimap3 0 upgraded, 1 newly installed, 0 to remove and 64 not upgraded. Need to get 0 B/155 kB of archives. After this operation, 636 kB of additional disk space will be used. Selecting previously unselected package offlineimap3. (Reading database ... 158999 files and directories currently installed.) Preparing to unpack .../offlineimap3_0.0~git20211018.e64c254+dfsg-2_all.deb ... Unpacking offlineimap3 (0.0~git20211018.e64c254+dfsg-2) ... Setting up offlineimap3 (0.0~git20211018.e64c254+dfsg-2) ... Processing triggers for man-db (2.11.2-2) ... Not building database; man-db/auto-update is not 'true'. ja at debian:~$ ls --full-time -hld /usr/share/man/man1 drwxr-xr-x 2 root root 68K 2024-09-07 12:38:42.478004504 -0400 /usr/share/man/man1 As we see mtime of /usr/share/man/man1 didn't go back to 2023-01-10. But there is still an issue here as man -k lists manpages even after package has been removed due to -p option used with mandb: ja at debian:~$ sudo touch /var/lib/man-db/auto-update ja at debian:~$ sudo apt-get -y remove offlineimap3 Reading package lists... Done Building dependency tree... Done Reading state information... Done The following package was automatically installed and is no longer required: python3-imaplib2 Use 'sudo apt autoremove' to remove it. The following packages will be REMOVED: offlineimap3 0 upgraded, 0 newly installed, 1 to remove and 64 not upgraded. After this operation, 636 kB disk space will be freed. (Reading database ... 159069 files and directories currently installed.) Removing offlineimap3 (0.0~git20211018.e64c254+dfsg-2) ... Processing triggers for man-db (2.11.2-2) ... ja at debian:~$ man -k offlineimap offlineimap (1) - Synchronize mailboxes and Maildirs both ways or one either way. offlineimapui (7) - The User Interfaces Apparently it's a known issue https://bugs-devel.debian.org/cgi-bin/bugreport.cgi?bug=539221#10. So if man database was refreshed on package removal Slackware would be better than Debian :D. Coming back to the proposal, since running mandb with each manpage is the only viable option to achieve the goal on Slackware (apart from rolling our custom tar extractor as Debian developers did) could we have something that could automate creating the doinst.sh? For example, sbopkglint could try finding all manpages in the package and suggest a bunch of lines that could be pasted verbatim into doinst.sh. I find the current method very daunting as I said in my previous e-mail. We could use system/openGLRefToMan to test the new approach as its install script already calls mandb -c and installs a lot of manpages. -- Arkadiusz Drabczyk From urchlay at slackware.uk Sat Sep 7 21:40:19 2024 From: urchlay at slackware.uk (B. Watson) Date: Sat, 7 Sep 2024 17:40:19 -0400 (EDT) Subject: [Slackbuilds-users] RFC: Proposed mandb additions to doinst/douninst template In-Reply-To: References: Message-ID: <507d9e4-5e73-c5b6-c97-f15615e84023@slackware.uk> On Sat, 7 Sep 2024, Arkadiusz Drabczyk wrote: > Out of curiosity I checked how Debian is managing manpages because I > remember "Processing triggers for man-db" being printed every time a > package is installed and I verified that man -k works immediately > after the package is installed: This is good research. > But there is still an issue here as man -k lists manpages even after > package has been removed due to -p option used with mandb: > > ja at debian:~$ sudo apt-get -y remove offlineimap3 ... > ja at debian:~$ man -k offlineimap > offlineimap (1) - Synchronize mailboxes and Maildirs both ways or one either way. > offlineimapui (7) - The User Interfaces > > Apparently it's a known issue > https://bugs-devel.debian.org/cgi-bin/bugreport.cgi?bug=539221#10. So > if man database was refreshed on package removal Slackware would be > better than Debian :D. I'm assuming that Debian's got a daily cron job like Slackware does, that will remove the removed man pages from the database, eventually... > Coming back to the proposal, since running mandb with each manpage is > the only viable option to achieve the goal on Slackware (apart from > rolling our custom tar extractor as Debian developers did) could we > have something that could automate creating the doinst.sh? For > example, sbopkglint could try finding all manpages in the package and > suggest a bunch of lines that could be pasted verbatim into > doinst.sh. I find the current method very daunting as I said in my > previous e-mail. We could use system/openGLRefToMan to test the new > approach as its install script already calls mandb -c and installs a > lot of manpages. I could make sbopkglint do that. Sample output might look like: ___note: package's man pages not added to man database. suggest adding this code to your doinst.sh: if [ -x usr/bin/mandb ]; then chroot . /usr/bin/mandb -f /usr/man/man1/blah.1.gz &> /dev/null fi ...with one mandb -f command per man page in the package. Not sure if this should include symlinks (does it even matter?). I wish the chroot weren't necessary, but mandb -f won't work if I give it a relative path, and it's incorrect to give an absolute path without chroot, because the package might not be getting installed to the real root... I'm not so sure that rebuilding the man database in the douninst.sh script is worth the overhead it creates. It's just wasted time, if you're upgrading a package and the new version has the same man pages as the previous version... and in any case, the daily cronjob will remove them from the db. Of course, not everyone leaves their machines running overnight (laptops for instance). But we have anacron in the repo, for just that sort of situation. From radinc at mail.ru Sat Sep 7 13:22:45 2024 From: radinc at mail.ru (Roman Dyaba) Date: Sat, 7 Sep 2024 23:22:45 +1000 Subject: [Slackbuilds-users] Link to get TeamViewer Message-ID: <99b5975a-94e9-4354-ab91-cd942e3de959@mail.ru> Hi ! TeamViewer link may be forbidden in some country, must be show Alternative ( i just find from GOOGLE ) : https://chuangtzu.ftp.acc.umu.se/mirror/ufficiozero.org/uzl-deb/urbino64/pool/main/t/teamviewer/teamviewer_15.57.3_amd64.deb Best works for you ! -- Roman Dyaba mail-to: radinc at mail.ru mob: +7 924 735 000 7 From arabusov at gmail.com Sun Sep 8 12:02:57 2024 From: arabusov at gmail.com (=?UTF-8?B?0JDQvdC00YDQtdC5INCg0LDQsdGD0YHQvtCy?=) Date: Sun, 8 Sep 2024 13:02:57 +0100 Subject: [Slackbuilds-users] Orphaning my SlackBuilds In-Reply-To: References: <268ec249-cd11-c4e9-51c3-b578419baa8c@o2.pl> <2c50b074-88cf-cf11-86e9-3ed98bbb39d8@slackware.uk> <9a9bc805-3447-4c4f-b982-dee09a9bde66@o2.pl> Message-ID: On Sat, Sep 7, 2024, 14:57 Dominik Drobek wrote: > Status after last update: > > Scripts with new maintainers: > games/OpenXcom -> B. Watson > graphics/gcolor2 -> B. Watson > network/aircrack-ng -> pyllyukko > network/macchanger -> B. Watson > system/pigz -> Brandon Pribula > > Handed over, but .info files not updated yet: > desktop/xfce4-volumed-pulse -> Nick Smallbone > office/latexdiff -> Andrei Rabusov > Updated now. Was a bit confused with the GH cli, so two attempts for the PR were needed) system/hddtemp -> Diniz Bortolotto > > Orphaned: > audio/MP3Diags > network/cowpatty > network/pidgin-extprefs > network/skype4pidgin > network/SoulseekQt > perl/perl-Text-Iconv > python/GeoIP-Python > python/pyotp > > So I'll go ahead and make a GitHub PR to mark the orphaned scripts as such. > > Regards, > Dominik > _______________________________________________ > 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 arkadiusz at drabczyk.org Sun Sep 8 17:27:40 2024 From: arkadiusz at drabczyk.org (Arkadiusz Drabczyk) Date: Sun, 8 Sep 2024 19:27:40 +0200 Subject: [Slackbuilds-users] RFC: Proposed mandb additions to doinst/douninst template In-Reply-To: <507d9e4-5e73-c5b6-c97-f15615e84023@slackware.uk> References: <507d9e4-5e73-c5b6-c97-f15615e84023@slackware.uk> Message-ID: On Sat, Sep 07, 2024 at 05:40:19PM -0400, B. Watson wrote: > > > On Sat, 7 Sep 2024, Arkadiusz Drabczyk wrote: > > > Out of curiosity I checked how Debian is managing manpages because I > > remember "Processing triggers for man-db" being printed every time a > > package is installed and I verified that man -k works immediately > > after the package is installed: > > This is good research. > > > But there is still an issue here as man -k lists manpages even after > > package has been removed due to -p option used with mandb: > > > > ja at debian:~$ sudo apt-get -y remove offlineimap3 > ... > > ja at debian:~$ man -k offlineimap > > offlineimap (1) - Synchronize mailboxes and Maildirs both ways or one either way. > > offlineimapui (7) - The User Interfaces > > > > Apparently it's a known issue > > https://bugs-devel.debian.org/cgi-bin/bugreport.cgi?bug=539221#10. So > > if man database was refreshed on package removal Slackware would be > > better than Debian :D. > > I'm assuming that Debian's got a daily cron job like Slackware > does, that will remove the removed man pages from the database, > eventually... Yes, there is /etc/cron.weekly/man-db which does that. > > Coming back to the proposal, since running mandb with each manpage is > > the only viable option to achieve the goal on Slackware (apart from > > rolling our custom tar extractor as Debian developers did) could we > > have something that could automate creating the doinst.sh? For > > example, sbopkglint could try finding all manpages in the package and > > suggest a bunch of lines that could be pasted verbatim into > > doinst.sh. I find the current method very daunting as I said in my > > previous e-mail. We could use system/openGLRefToMan to test the new > > approach as its install script already calls mandb -c and installs a > > lot of manpages. > > I could make sbopkglint do that. > > Sample output might look like: > > ___note: package's man pages not added to man database. suggest adding > this code to your doinst.sh: > > if [ -x usr/bin/mandb ]; then > chroot . /usr/bin/mandb -f /usr/man/man1/blah.1.gz &> /dev/null > fi > > ...with one mandb -f command per man page in the package. Not sure if > this should include symlinks (does it even matter?). > > I wish the chroot weren't necessary, but mandb -f won't work if I > give it a relative path, and it's incorrect to give an absolute path > without chroot, because the package might not be getting installed to > the real root... Yeah I get the same behavior on -current and on Debian, this must be the intended behavior of mandb. Anyway, sounds good but why should we hide errors from the user? And it's a bit worrying that mandb manpage says that -f 'is not for general use', I hope they'll not remove it someday. > I'm not so sure that rebuilding the man database in the douninst.sh > script is worth the overhead it creates. It's just wasted time, if > you're upgrading a package and the new version has the same man pages > as the previous version... and in any case, the daily cronjob will > remove them from the db. > > Of course, not everyone leaves their machines running overnight > (laptops for instance). But we have anacron in the repo, for just that > sort of situation. ok, so we can behave like Debian and run mandb only in doinst.sh. Another interesting thing is that mandb manpage says that the database cache should be in /var/cache/man/index.(bt|db|dir|pag) - and indeed /var/cache/man/index.db exists on Debian but on Slackware /etc/man_db.conf has been modified in https://git.slackware.nl/current/commit/?id=646a5c1cbfd95873950a87b5f75d52073a967023 and the database is in /var/cache/man/usr-man/index.db - does anybody why it was changed? -- Arkadiusz Drabczyk From urchlay at slackware.uk Tue Sep 10 02:34:39 2024 From: urchlay at slackware.uk (B. Watson) Date: Mon, 9 Sep 2024 22:34:39 -0400 (EDT) Subject: [Slackbuilds-users] RFC: Proposed mandb additions to doinst/douninst template In-Reply-To: References: <507d9e4-5e73-c5b6-c97-f15615e84023@slackware.uk> Message-ID: On Sun, 8 Sep 2024, Arkadiusz Drabczyk wrote: > Yeah I get the same behavior on -current and on Debian, this must be > the intended behavior of mandb. Anyway, sounds good but why should we > hide errors from the user? And it's a bit worrying that mandb manpage > says that -f 'is not for general use', I hope they'll not remove it > someday. I think Debian's man page postinstall trigger stuff uses -f, so I doubt it'll go away (or if it's going to, there will be plenty of advance notice). I had a thought. Instead of including a doinst.sh with all the man pages listed in it, how about having the SlackBuild generate one? Change the last 2 lines of a script, insert doinst-generation code between the 'cd $PKG' and the makepkg command... something like this: cd $PKG find usr/man -type f -a -name '*.gz' | \ sed -e 's,^,chroot . /usr/bin/mandb -f "/,' \ -e 's,$," \&>/dev/null,' \ >> install/doinst.sh /sbin/makepkg -l y -c n $OUTPUT/$PRGNAM-$VERSION-$ARCH-$BUILD$TAG.$PKGTYPE ...it uses >> so if there's already a doinst.sh, it'll append to it. The resulting doinst.sh will look something like: chroot . /usr/bin/mandb -f "/usr/man/man1/foo.1.gz" &>/dev/null chroot . /usr/bin/mandb -f "/usr/man/man1/bar.1.gz" &>/dev/null chroot . /usr/bin/mandb -f "/usr/man/man1/baz.1.gz" &>/dev/null It doesn't have the "if [ -x usr/man/mandb ]" check, but it doesn't really need it: the commands always run, but will silenty (and quickly) fail, if there's no mandb command to run. So, no need to manually maintain a doinst.sh script with all the man pages listed in it. This should Just Work, everyone please try it on some of your own builds and let me know if you have problems. From fourtysixandtwo at sliderr.net Tue Sep 10 12:57:00 2024 From: fourtysixandtwo at sliderr.net (fourtysixandtwo) Date: Tue, 10 Sep 2024 06:57:00 -0600 Subject: [Slackbuilds-users] important info regarding python3-hatchling update Message-ID: Hi all, I've added another -opt slackbuild (python3-packaging-opt) to facilitate upgrading python3-setuptools-opt and python3-hatchling. These updates mostly concern the latter and anyone with manual build queues. Any python build requiring python3-hatchling now requires the same changes that the other slackbuilds using any of the python3-*-opt builds. This has been added to the README. PYVER=$(python3 -c 'import sys; print("%d.%d" % sys.version_info[:2])') export PYTHONPATH=/opt/python$PYVER/site-packages The following slackbuilds have been fixed, tested and are sitting in my queue. desktop/py3status development/jupyter-ipykernel development/jupyter-nbclient development/jupyter-nbconvert development/jupyter-nbformat development/jupyter-notebook_shim development/jupyter_client development/jupyter_console development/jupyter_core development/jupyter_events development/jupyter_packaging development/jupyter_server development/jupyter_server_terminals development/jupyterlab_server libraries/PrettyTable libraries/pylast libraries/python3-plumbum libraries/python3-rpyc multimedia/videomass network/yt-dlp python/BeautifulSoup4 python/colorama python/django-debug-toolbar python/humanize python/python3-Flask-WTF python/python3-WTForms python/python3-aiofiles python/python3-argon2-cffi python/python3-atpublic python/python3-attrs python/python3-black python/python3-comm python/python3-dnspython python/python3-docker python/python3-filelock python/python3-flufl.i18n python/python3-flufl.lock python/python3-hatch-nodejs-version python/python3-hatch_fancy_pypi_readme python/python3-hatch_jupyter_builder python/python3-hatch_vcs python/python3-hishel python/python3-httpcore python/python3-httpx python/python3-iniconfig python/python3-jsonschema python/python3-pipx python/python3-pydantic python/python3-pyproject-api python/python3-service-identity python/python3-soupsieve python/python3-terminado python/python3-tox python/python3-twisted python/python3-userpath python/termcolor python/traitlets #python/terminado -is being removed so it is excluded If you'd like to test these yourself, it would be best to apply all the updates in my queue and install the new python3-packaging-opt (still in the submission queue) first. https://slackware.uk/~fourtysixandtwo/src/python3-packaging-opt.tar.xz https://git.slackbuilds.org/slackbuilds/log/?h=user/46and2/updates Cheers From dickson.tim at googlemail.com Tue Sep 10 14:13:32 2024 From: dickson.tim at googlemail.com (Tim Dickson) Date: Tue, 10 Sep 2024 15:13:32 +0100 Subject: [Slackbuilds-users] important info regarding python3-hatchling update In-Reply-To: References: Message-ID: So are you saying wait till all the other build updates are pushed on the weekend, then install python3-packaging-opt,and update python3-setuptools-opt and python3-hatchling, and then all the packages that depend on them?. thanks for the heads up on the extra dep. how many levels up should they be rebuilt? for example; pytrainer requires python3-matplotlib which requires python3-fonttols which requires python3-lz4 which requires python3-tox which requires colerama which requires python3-hatchling you have the last 3 in your list, but will the others need rebuilding as well, eg python3-lz4?? ? Regards, Tim On 10/09/2024 13:57, fourtysixandtwo wrote: > Hi all, > > I've added another -opt slackbuild (python3-packaging-opt) to > facilitate upgrading python3-setuptools-opt and python3-hatchling. > These updates mostly concern the latter and anyone with manual build > queues. > > Any python build requiring python3-hatchling now requires the same > changes that the other slackbuilds using any of the python3-*-opt > builds. This has been added to the README. > > PYVER=$(python3 -c 'import sys; print("%d.%d" % sys.version_info[:2])') > export PYTHONPATH=/opt/python$PYVER/site-packages > > The following slackbuilds have been fixed, tested and are sitting in my queue. > > desktop/py3status > development/jupyter-ipykernel > development/jupyter-nbclient > development/jupyter-nbconvert > development/jupyter-nbformat > development/jupyter-notebook_shim > development/jupyter_client > development/jupyter_console > development/jupyter_core > development/jupyter_events > development/jupyter_packaging > development/jupyter_server > development/jupyter_server_terminals > development/jupyterlab_server > libraries/PrettyTable > libraries/pylast > libraries/python3-plumbum > libraries/python3-rpyc > multimedia/videomass > network/yt-dlp > python/BeautifulSoup4 > python/colorama > python/django-debug-toolbar > python/humanize > python/python3-Flask-WTF > python/python3-WTForms > python/python3-aiofiles > python/python3-argon2-cffi > python/python3-atpublic > python/python3-attrs > python/python3-black > python/python3-comm > python/python3-dnspython > python/python3-docker > python/python3-filelock > python/python3-flufl.i18n > python/python3-flufl.lock > python/python3-hatch-nodejs-version > python/python3-hatch_fancy_pypi_readme > python/python3-hatch_jupyter_builder > python/python3-hatch_vcs > python/python3-hishel > python/python3-httpcore > python/python3-httpx > python/python3-iniconfig > python/python3-jsonschema > python/python3-pipx > python/python3-pydantic > python/python3-pyproject-api > python/python3-service-identity > python/python3-soupsieve > python/python3-terminado > python/python3-tox > python/python3-twisted > python/python3-userpath > python/termcolor > python/traitlets > #python/terminado -is being removed so it is excluded > > If you'd like to test these yourself, it would be best to apply all > the updates in my queue and install the new python3-packaging-opt > (still in the submission queue) first. > > https://slackware.uk/~fourtysixandtwo/src/python3-packaging-opt.tar.xz > https://git.slackbuilds.org/slackbuilds/log/?h=user/46and2/updates > > Cheers > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - https://slackbuilds.org/faq/ > -- This email has been checked for viruses by AVG antivirus software. www.avg.com From willysr at slackbuilds.org Tue Sep 10 14:53:59 2024 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Tue, 10 Sep 2024 21:53:59 +0700 Subject: [Slackbuilds-users] important info regarding python3-hatchling update In-Reply-To: References: Message-ID: <518b9993-60fb-4174-8910-698bd9a8457d@slackbuilds.org> > If you'd like to test these yourself, it would be best to apply all > the updates in my queue and install the new python3-packaging-opt > (still in the submission queue) first. It has been merged into my branch https://git.slackbuilds.org/slackbuilds/commit/?id=5d331b8a1 -- 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 fourtysixandtwo at sliderr.net Tue Sep 10 15:03:34 2024 From: fourtysixandtwo at sliderr.net (fourtysixandtwo) Date: Tue, 10 Sep 2024 09:03:34 -0600 Subject: [Slackbuilds-users] important info regarding python3-hatchling update In-Reply-To: References: Message-ID: On Tue, Sep 10, 2024 at 8:13?AM Tim Dickson via SlackBuilds-users wrote: > > So are you saying wait till all the other build updates are pushed on > the weekend, then install python3-packaging-opt,and update > python3-setuptools-opt and python3-hatchling, and then all the packages > that depend on them?. Yes, my note about testing was more for the maintainers of those slackbuilds. Normal update process applies. Those are only build time deps so unless you are installing a new build or updating something further up the chain that depends on them there's no need to rebuild everything. Testing is another story... > thanks for the heads up on the extra dep. how many levels up should they > be rebuilt? > for example; > pytrainer requires python3-matplotlib which requires python3-fonttols > which requires python3-lz4 which requires python3-tox which requires > colerama which requires python3-hatchling Any build queue with python3-hatchling in it will look very close to this snippet from the diff in my pytrainer.sqf file. diff --git a/pytrainer.sqf b/pytrainer.sqf index 3774971..2157e58 100644 --- a/pytrainer.sqf +++ b/pytrainer.sqf @@ -11,6 +11,7 @@ python3-installer python3-wheel python3-pyproject-hooks python3-build +python3-packaging-opt python3-setuptools-opt python-zipp python-importlib_metadata In others, python3-setuptools-opt will be added or moved further up like in this example: diff --git a/jupyter_server.sqf b/jupyter_server.sqf index 353873b..52054e9 100644 --- a/jupyter_server.sqf +++ b/jupyter_server.sqf @@ -7,6 +7,8 @@ python3-pyproject-hooks python3-build send2trash python3-prometheus_client +python3-packaging-opt +python3-setuptools-opt python3-calver python3-trove-classifiers python3-pluggy @@ -14,7 +16,6 @@ python3-pathspec python3-editables python3-hatchling python3-hatch_jupyter_builder -python3-setuptools-opt python-zipp python-importlib_metadata python3-mdurl > you have the last 3 in your list, but will the others need rebuilding as > well, eg python3-lz4 ? Only new or version updated slackbuilds will need rebuilding. Hope that answers your questions From dickson.tim at googlemail.com Tue Sep 10 15:40:04 2024 From: dickson.tim at googlemail.com (Tim Dickson) Date: Tue, 10 Sep 2024 16:40:04 +0100 Subject: [Slackbuilds-users] important info regarding python3-hatchling update In-Reply-To: References: Message-ID: <4cbc41c6-db78-4de3-a558-fa904fcb30e2@googlemail.com> On 10/09/2024 16:03, fourtysixandtwo wrote: > On Tue, Sep 10, 2024 at 8:13?AM Tim Dickson via SlackBuilds-users > wrote: >> So are you saying wait till all the other build updates are pushed on >> the weekend, then install python3-packaging-opt,and update >> python3-setuptools-opt and python3-hatchling, and then all the packages >> that depend on them?. > Yes, my note about testing was more for the maintainers of those > slackbuilds. Normal update process applies. Those are only build > time deps so unless you are installing a new build or updating > something further up the chain that depends on them there's no need to > rebuild everything. Testing is another story... > >> thanks for the heads up on the extra dep. how many levels up should they >> be rebuilt? >> for example; >> pytrainer requires python3-matplotlib which requires python3-fonttols >> which requires python3-lz4 which requires python3-tox which requires >> colerama which requires python3-hatchling > Any build queue with python3-hatchling in it will look very close to > this snippet from the diff in my pytrainer.sqf file. > > diff --git a/pytrainer.sqf b/pytrainer.sqf > index 3774971..2157e58 100644 > --- a/pytrainer.sqf > +++ b/pytrainer.sqf > @@ -11,6 +11,7 @@ python3-installer > python3-wheel > python3-pyproject-hooks > python3-build > +python3-packaging-opt > python3-setuptools-opt > python-zipp > python-importlib_metadata > > In others, python3-setuptools-opt will be added or moved further up > like in this example: > > diff --git a/jupyter_server.sqf b/jupyter_server.sqf > index 353873b..52054e9 100644 > --- a/jupyter_server.sqf > +++ b/jupyter_server.sqf > @@ -7,6 +7,8 @@ python3-pyproject-hooks > python3-build > send2trash > python3-prometheus_client > +python3-packaging-opt > +python3-setuptools-opt > python3-calver > python3-trove-classifiers > python3-pluggy > @@ -14,7 +16,6 @@ python3-pathspec > python3-editables > python3-hatchling > python3-hatch_jupyter_builder > -python3-setuptools-opt > python-zipp > python-importlib_metadata > python3-mdurl > >> you have the last 3 in your list, but will the others need rebuilding as >> well, eg python3-lz4 ? > Only new or version updated slackbuilds will need rebuilding. > > Hope that answers your questions thanks. just wanted to make sure before I started rebuilding lots of stuff :-) -- This email has been checked for viruses by AVG antivirus software. www.avg.com From jebrhansen+SBo at gmail.com Tue Sep 10 16:06:24 2024 From: jebrhansen+SBo at gmail.com (Jeremy Hansen) Date: Tue, 10 Sep 2024 09:06:24 -0700 Subject: [Slackbuilds-users] important info regarding python3-hatchling update In-Reply-To: References: Message-ID: On Tue, Sep 10, 2024, 5:57?AM fourtysixandtwo wrote: > Hi all, > > I've added another -opt slackbuild (python3-packaging-opt) to > facilitate upgrading python3-setuptools-opt and python3-hatchling. > Do you know what issue/error this is addressing when building (if any)? Over the last year or so, I've needed to add tweaks/hacks to some of my SlackBuilds to deal with issues arising from older versions of software in 15.0 and/or on SBo. Some of those fixes became obsolete when you added other packages like python3-setuptools-scm-opt. If that's possibly the case here, I'd like to go through and remove any unneeded hacks like I did with the following PR after using your aforementioned package. https://github.com/SlackBuildsOrg/slackbuilds/pull/5782/files Thanks for all your work! Jeremy -------------- next part -------------- An HTML attachment was scrubbed... URL: From fourtysixandtwo at sliderr.net Tue Sep 10 17:39:20 2024 From: fourtysixandtwo at sliderr.net (fourtysixandtwo) Date: Tue, 10 Sep 2024 11:39:20 -0600 Subject: [Slackbuilds-users] important info regarding python3-hatchling update In-Reply-To: References: Message-ID: On Tue, Sep 10, 2024 at 10:06?AM Jeremy Hansen wrote: > Do you know what issue/error this is addressing when building (if any)? None that I'm aware of other than the hard version requirement for setuptools and hatchling. You made me curious and I have found the following. I can remove these in my branch if you'd like?: ./python/python3-tox/python3-tox.SlackBuild:sed -i 's|=1\.25|=1\.22|' pyproject.toml # hatchling ./python/python3-tox/python3-tox.SlackBuild:sed -i 's|=24\.1|=21\.3|' pyproject.toml # packaging ./python/python3-pyproject-api/python3-pyproject-api.SlackBuild:sed -i 's|1\.24\.2|1\.18|' pyproject.toml # hatchling ./python/python3-pyproject-api/python3-pyproject-api.SlackBuild:sed -i 's|24\.1|21\.0|' pyproject.toml # packaging Cheers! From jebrhansen+SBo at gmail.com Tue Sep 10 18:55:00 2024 From: jebrhansen+SBo at gmail.com (Jeremy Hansen) Date: Tue, 10 Sep 2024 11:55:00 -0700 Subject: [Slackbuilds-users] important info regarding python3-hatchling update In-Reply-To: References: Message-ID: On Tue, Sep 10, 2024, 10:39?AM fourtysixandtwo wrote: > On Tue, Sep 10, 2024 at 10:06?AM Jeremy Hansen > wrote: > > Do you know what issue/error this is addressing when building (if any)? > > None that I'm aware of other than the hard version requirement for > setuptools and hatchling. Cool, because I have a bunch of export SETUPTOOLS_SCM_PRETEND_VERSION=$VERSION and a few export PDM_BUILD_SCM_VERSION=$VERSION to fix some issue with versions not being detected properly during build time (although, I believe several are due to me choosing GitHub tarballs instead of PyPi, which are packaged differently). If those hacks were to be fixed by these updates, I'd remove them. You made me curious and I have found the > following. I can remove these in my branch if you'd like?: > > ./python/python3-tox/python3-tox.SlackBuild:sed -i 's|=1\.25|=1\.22|' > pyproject.toml # hatchling > ./python/python3-tox/python3-tox.SlackBuild:sed -i 's|=24\.1|=21\.3|' > pyproject.toml # packaging > ./python/python3-pyproject-api/python3-pyproject-api.SlackBuild:sed -i > 's|1\.24\.2|1\.18|' pyproject.toml # hatchling > ./python/python3-pyproject-api/python3-pyproject-api.SlackBuild:sed -i > 's|24\.1|21\.0|' pyproject.toml # packaging > > Cheers! > Go for it! It's easier than me trying to merge your changes and submit a PR this week. Thanks! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbo at linuxgalaxy.org Wed Sep 11 02:15:28 2024 From: sbo at linuxgalaxy.org (KB_SBo) Date: Wed, 11 Sep 2024 02:15:28 +0000 Subject: [Slackbuilds-users] RFC: Proposed mandb additions to doinst/douninst template In-Reply-To: References: Message-ID: On 8/23/24 23:32, B. Watson wrote: > Thinking of adding this to the doinst template: > > ### in doinst.sh: > # DESCRIPTION: Updates the man database (for "man -k"). > # Use one "man -f" command for each man page in the package. > if [ -x usr/bin/mandb ]; then > usr/bin/mandb -f usr/man/man1/program.1.gz > fi After lurking around this idea a bit, I'm still having trouble understanding why this is needed. Speed? Convenience? Purity of Spirit? Adding mandb to doinst seems to add extra complexity without any significant gain. After all, we don't run # updatedb on package installation since updates eventually occur in a system cron. Also, I've never experienced any issues accessing a manpage immediately after package installation, i.e., no updates to mandb. (Or maybe after given up on 32-bit and 20th century hardware I don't notice any "lag".) -Ed From urchlay at slackware.uk Wed Sep 11 04:42:58 2024 From: urchlay at slackware.uk (B. Watson) Date: Wed, 11 Sep 2024 00:42:58 -0400 (EDT) Subject: [Slackbuilds-users] RFC: Proposed mandb additions to doinst/douninst template In-Reply-To: References: Message-ID: On Wed, 11 Sep 2024, KB_SBo wrote: > After lurking around this idea a bit, I'm still having trouble > understanding why this is needed. Speed? Convenience? Purity of Spirit? To Fix That Which Is Broken. For "man -k", "whatis", "apropos" commands to work. Not just "right after package install", for them to work *reliably* at all. > Adding mandb to doinst seems to add extra complexity without any > significant gain. If you're not in the habit of using "man -k", "apropos", or "whatis", then for you there isn't any gain at all. But other people have different usage patterns. Our packages should be general-purpose, not just "works for me". If you want to, I guess you could label that as "Purity of Spirit". > After all, we don't run > > # updatedb > > on package installation since updates eventually occur in a system cron. Right. But the daily updatedb cron job reliably finds all files that have been added since last time it ran. The daily man-db cron job *doesn't* always pick up the new man pages. It's not reliable. Specifically, it won't pick them up if you install a package that was created before the last time the cron job ran. Reason being, the timestamps on the /usr/man/man* directories get reset to the timestamps from the package tarball. Then when the cron job runs, it sees that the timestamps are older than the timestamps of the databases, so it assumes it doesn't need to do anything. Other Linux distrubutions have the same problem. Debian deals with it by having the package installer (dpkg) automatically update the man database. We don't get to change Slackware's installpkg, so the same solution can't be used there. So, doing it in doinst.sh is the best I could come up with. > Also, I've never experienced any issues accessing a manpage immediately > after package installation, i.e., no updates to mandb. Accessing the man page ("man whatever") doesn't use the database. It's -k option (or apropos, or whatis) that uses the database. In other words, the database is used for searches. If it was just a matter of "you have to wait until the daily cronjob picks them up", I would never have suggested making any changes. Note that I'm not trying to force anyone to change their existing builds. I want to add this to the template (for new builds) and as a "note" (suggestion) in sbolint. It won't be a warning or an error. From kvngncrlsn at gmail.com Wed Sep 11 05:52:17 2024 From: kvngncrlsn at gmail.com (K. Eugene Carlson) Date: Wed, 11 Sep 2024 14:52:17 +0900 Subject: [Slackbuilds-users] RFC: Proposed mandb additions to doinst/douninst template In-Reply-To: References: Message-ID: > find usr/man -type f -a -name '*.gz' | \ > sed -e 's,^,chroot . /usr/bin/mandb -f "/,' \ > -e 's,$," \&>/dev/null,' \ > >> install/doinst.sh My only suggestion would be to use "-type f,l". Almost 20% of all man pages are symlinks on a clean Slackware installation. Anyway, I've started trying this out on my own builds (albeit with awk instead of sed; just personal preference), and it appears to work. Best regards, Gene Carlson -------------- next part -------------- An HTML attachment was scrubbed... URL: From urchlay at slackware.uk Wed Sep 11 06:15:44 2024 From: urchlay at slackware.uk (B. Watson) Date: Wed, 11 Sep 2024 02:15:44 -0400 (EDT) Subject: [Slackbuilds-users] RFC: Proposed mandb additions to doinst/douninst template In-Reply-To: References: Message-ID: <219c2ae-f997-80e3-4cae-3aa9b84fb9@slackware.uk> On Wed, 11 Sep 2024, K. Eugene Carlson wrote: > >? ?find usr/man -type f -a -name '*.gz' | \ > >? ? ?sed -e 's,^,chroot . /usr/bin/mandb -f "/,' \ > >? ? ? ? ?-e 's,$," \&>/dev/null,' \ > >? ? ?>> install/doinst.sh > > My only suggestion would be to use "-type f,l". Almost 20% of all man pages are symlinks on a clean Slackware installation. I was thinking adding symlinks to the database wouldn't be helpful. For man -k or apropos (which search the descriptions and return the pages), it wouldn't be. For whatis I suppose it would be (takes a page name, which might be a symlink, and gives you the description). > Anyway, I've started trying this out on my own builds (albeit with awk instead of sed; just personal preference), and it appears to work. Someone on IRC pointed out that rewriting it to use awk would be less ugly. I tend to reach for sed first due to familiarity, but I think in this case you and him are right. Something like this, maybe? find usr/man -type f -a -name '*.gz' | \ awk '{ print "chroot . /usr/bin/mandb -f \"/"$1"\" &>/dev/null" }' \ >> install/doinst.sh It would be less ugly if we could assume man pages never have spaces or shell metacharacters in them... I don't think the man command can handle spaces in the man page filenames, and it would be bizarre to have $ or * or such in the filename... But better to leave the quotes there I suppose. From nick at smallbone.se Wed Sep 11 06:31:55 2024 From: nick at smallbone.se (Nick Smallbone) Date: Wed, 11 Sep 2024 08:31:55 +0200 Subject: [Slackbuilds-users] RFC: Proposed mandb additions to doinst/douninst template In-Reply-To: <219c2ae-f997-80e3-4cae-3aa9b84fb9@slackware.uk> References: <219c2ae-f997-80e3-4cae-3aa9b84fb9@slackware.uk> Message-ID: On Wed, 11 Sep 2024, at 8:15 AM, B. Watson wrote: > Someone on IRC pointed out that rewriting it to use awk would be less > ugly. I tend to reach for sed first due to familiarity, but I think in > this case you and him are right. > > Something like this, maybe? > > find usr/man -type f -a -name '*.gz' | \ > awk '{ print "chroot . /usr/bin/mandb -f \"/"$1"\" &>/dev/null" }' \ > >> install/doinst.sh > > It would be less ugly if we could assume man pages never have spaces > or shell metacharacters in them... I don't think the man command can > handle spaces in the man page filenames, and it would be bizarre to > have $ or * or such in the filename... But better to leave the quotes > there I suppose. I just learned that find has a -printf flag which can be used to format the output, avoiding the need for sed/awk altogether: find usr/man -type f -a -name '*.gz' \ -printf "chroot . /usr/bin/mandb -f '/%p' &> /dev/null\n" \ >> install/doinst.sh There's also a %P format specifier which prints the filename relative to the search root (e.g. man1/whatever.1.gz), hence the following variant which even works if run before the 'cd $PKG' command (but it still needs to come after 'mkdir $PKG/install' so perhaps not a useful improvement): find $PKG/usr/man -type f -a -name '*.gz' \ -printf "chroot . /usr/bin/mandb -f /usr/man/%P &> /dev/null\n" \ >> $PKG/install/doinst.sh Nick From urchlay at slackware.uk Wed Sep 11 07:45:09 2024 From: urchlay at slackware.uk (B. Watson) Date: Wed, 11 Sep 2024 03:45:09 -0400 (EDT) Subject: [Slackbuilds-users] RFC: Proposed mandb additions to doinst/douninst template In-Reply-To: References: <219c2ae-f997-80e3-4cae-3aa9b84fb9@slackware.uk> Message-ID: <4bcb3d25-649c-460-9ef5-fa3575dd8223@slackware.uk> On Wed, 11 Sep 2024, Nick Smallbone wrote: > > I just learned that find has a -printf flag which can be used to format the output, avoiding the need for sed/awk altogether: > > find usr/man -type f -a -name '*.gz' \ > -printf "chroot . /usr/bin/mandb -f '/%p' &> /dev/null\n" \ > >> install/doinst.sh Ooh, I like this! From fourtysixandtwo at sliderr.net Wed Sep 11 11:23:11 2024 From: fourtysixandtwo at sliderr.net (fourtysixandtwo) Date: Wed, 11 Sep 2024 05:23:11 -0600 Subject: [Slackbuilds-users] important info regarding python3-hatchling update In-Reply-To: References: Message-ID: On Tue, Sep 10, 2024 at 12:55?PM Jeremy Hansen wrote: > export SETUPTOOLS_SCM_PRETEND_VERSION=$VERSION > > and a few > > export PDM_BUILD_SCM_VERSION=$VERSION > > to fix some issue with versions not being detected properly during build time (although, I believe several are due to me choosing GitHub tarballs instead of PyPi, which are packaged differently). If those hacks were to be fixed by these updates, I'd remove them. I use the pypi tarballs solely because I can also grab the MD5SUM they provide with my update script. It is a bonus that I haven't had to use those methods above with any builds I maintain. I just checked with python3-tox and python3-pyproject-api tarballs from pypi and they both include a "src/*/*version.py". One does have to watch for the change in source from say pyproject-api to pyproject_api in both download and SRCNAM though. Have you come across this for troubleshooting? export SETUPTOOLS_SCM_DEBUG=true While we are on the topic of setuptools_scm, I have a method using venv to upgrade it to 8.1.0, but unfortunately the newer versions do not honour PYTHONPATH precedence and import the older slackware 15.0 version. One would have to remove the older system package or use the venv hack on every slackbuild that requires the newer setuptools_scm in /opt. Upstream is aware of this issue but don't have any interest in fixing it currently. Hopefully the python3-setuptools-scm-opt-8.0.2 version continues to work in the meantime. > Go for it! It's easier than me trying to merge your changes and submit a PR this week. Done! From jebrhansen+SBo at gmail.com Thu Sep 12 05:29:50 2024 From: jebrhansen+SBo at gmail.com (Jeremy Hansen) Date: Wed, 11 Sep 2024 22:29:50 -0700 Subject: [Slackbuilds-users] important info regarding python3-hatchling update In-Reply-To: References: Message-ID: On Wed, Sep 11, 2024 at 4:23?AM fourtysixandtwo wrote: > On Tue, Sep 10, 2024 at 12:55?PM Jeremy Hansen > wrote: > > export SETUPTOOLS_SCM_PRETEND_VERSION=$VERSION > > > > and a few > > > > export PDM_BUILD_SCM_VERSION=$VERSION > > > > to fix some issue with versions not being detected properly during build > time (although, I believe several are due to me choosing GitHub tarballs > instead of PyPi, which are packaged differently). If those hacks were to be > fixed by these updates, I'd remove them. > > I use the pypi tarballs solely because I can also grab the MD5SUM they > provide with my update script. This isn't an issue for me as my update script will generate MD5SUM automatically no matter how many source files there are. It will just download everything in the DOWNLOAD or DOWNLOAD_X86_64 variables in the .info (if they don't already exist) and then generate MD5s for all of them and update the .info file. > It is a bonus that I haven't had to use those methods above with any > builds I maintain. This is a minor inconvenience for a handful of packages that prefer downloads from PyPi or a git clone (rather than an archive download from a tag/release). Luckily, out of the 150+ packages I maintain, there's probably less than a dozen that I had to add this tweak/hack. I think my preference to GitHub was many python packages I took over that used PyPi as their source location used hashed download links, which prevented my update script from using the right download link (although, I suppose I could add the functionality to switch to links that simply require updating the version -- future me will worry about that :D). This led me to prefer GitHub links and then outta sheer stubbornness, when problems arose from it, I found hacks to continue using GitHub over PyPi. > I just checked with python3-tox and python3-pyproject-api tarballs from > pypi and they both include a "src/*/*version.py". One does have to watch > for the change in source from say pyproject-api to pyproject_api in both > download and SRCNAM though. > > Have you come across this for troubleshooting? > export SETUPTOOLS_SCM_DEBUG=true > I was not aware of that flag, however, it led to either a similar or the same issue (too lazy to investigate further right now). "mAke sURe yoU're EitHer bUildINg frOM A FulLy iNTAcT git RepOsiToRY oR PyPi taRbaLLs." Error, meet stubbornness (my hack) :D > While we are on the topic of setuptools_scm, I have a method using > venv to upgrade it to 8.1.0, but unfortunately the newer versions do > not honour PYTHONPATH precedence and import the older slackware 15.0 > version. One would have to remove the older system package or use the > venv hack on every slackbuild that requires the newer setuptools_scm > in /opt. I mean, we currently have to add hacks in SlackBuilds to use newer python packages residing in /opt/ (which are mostly, if not entirely, packages you maintain). This has opened up the ability to upgrade a lot of python packages further than would be allowed if we solely used the packages from 15.0. They've been very helpful in allowing upgrades without additional hacks. If the newer version offers something severely lacking on Slackware or SBo today, I (and I can only speak for myself), have no issues adding a line or few to my SlackBuilds that require that newer version. > Upstream is aware of this issue but don't have any interest in fixing it > currently. That sucks. > > Go for it! It's easier than me trying to merge your changes and submit a > PR this week. > > Done! > Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From dickson.tim at googlemail.com Thu Sep 12 07:57:03 2024 From: dickson.tim at googlemail.com (Tim Dickson) Date: Thu, 12 Sep 2024 08:57:03 +0100 Subject: [Slackbuilds-users] important info regarding python3-hatchling update In-Reply-To: References: Message-ID: <6e9cbbfd-eaf2-4ce1-b011-920b85b96426@googlemail.com> On 12/09/2024 06:29, Jeremy Hansen wrote: > > > On Wed, Sep 11, 2024 at 4:23?AM fourtysixandtwo > wrote: > > On Tue, Sep 10, 2024 at 12:55?PM Jeremy Hansen > > wrote: > > export SETUPTOOLS_SCM_PRETEND_VERSION=$VERSION > > > > and a few > > > > export PDM_BUILD_SCM_VERSION=$VERSION > > > > to fix some issue with versions not being detected properly > during build time (although, I believe several are due to me > choosing GitHub tarballs instead of PyPi, which are packaged > differently). If those hacks were to be fixed by these updates, > I'd remove them. > > I use the pypi tarballs solely because I can also grab the MD5SUM > they provide with my update script. > > > This isn't an issue for me as my update script will generate MD5SUM > automatically no matter how many source files there are. It will just > download everything in the DOWNLOAD or DOWNLOAD_X86_64 variables in > the .info (if they don't already exist) and then generate MD5s for all > of them and update the .info file. > > It is a bonus that I haven't had to use those methods above with > any builds I maintain. > > > This is a minor inconvenience for a handful of packages that prefer > downloads from PyPi or a git clone (rather than an archive download > from a tag/release). Luckily, out of the 150+ packages I maintain, > there's probably less than a dozen that I had to add this tweak/hack. > I think my preference to GitHub was many python packages I took over > that used PyPi as their source location used hashed download links, > which prevented my update script from using the right download link > (although, I suppose I could add the functionality to switch to links > that simply require updating the version -- future me will worry about > that :D). This led me to prefer GitHub links and then outta sheer > stubbornness, when problems arose from it, I found hacks to continue > using GitHub over PyPi. > > I just checked with python3-tox and python3-pyproject-api tarballs > from pypi and they both include a "src/*/*version.py".? One does > have to watch for the change in source from say pyproject-api to > pyproject_api in both download and SRCNAM though. > > Have you come across this for troubleshooting? > export SETUPTOOLS_SCM_DEBUG=true > > > I was not aware of that flag, however, it led to either a similar or > the same issue (too lazy to investigate further right now). > > "mAke sURe yoU're EitHer bUildINg frOM A FulLy iNTAcT git RepOsiToRY > oR PyPi taRbaLLs." > > Error, meet stubbornness (my hack) :D > > While we are on the topic of setuptools_scm, I have a method using > venv to upgrade it to 8.1.0, but unfortunately the newer versions do > not honour PYTHONPATH precedence and import the older slackware 15.0 > version.? One would have to remove the older system package or use the > venv hack on every slackbuild that requires the newer setuptools_scm > in /opt. > > > I mean, we currently have to add hacks in SlackBuilds to use newer > python packages residing in /opt/ (which are mostly, if not entirely, > packages you maintain). This has opened up the ability to upgrade a > lot of python packages further than would be allowed if we solely used > the packages from 15.0. They've been very helpful in allowing upgrades > without additional hacks. > > If the newer version offers something severely lacking on Slackware or > SBo today, I (and I can only speak for myself), have no issues adding > a line or few to my SlackBuilds that require that newer version. > > Upstream is aware of this issue but don't have any interest in > fixing it currently. > > > That sucks. > > > Go for it! It's easier than me trying to merge your changes and > submit a PR this week. > > Done! > > > Thanks! > > _______________________________________________ > 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 found that for some python builds github archives/tags were missing some of the source, which was included in pypi source download, so have to use pypi for those. it's a bit more inconvenient, as the url's have the hashes as you mentioned, but it's not too awkward. regards, Tim -- This email has been checked for viruses by AVG antivirus software. www.avg.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From jebrhansen+SBo at gmail.com Thu Sep 12 08:14:02 2024 From: jebrhansen+SBo at gmail.com (Jeremy Hansen) Date: Thu, 12 Sep 2024 01:14:02 -0700 Subject: [Slackbuilds-users] important info regarding python3-hatchling update In-Reply-To: <6e9cbbfd-eaf2-4ce1-b011-920b85b96426@googlemail.com> References: <6e9cbbfd-eaf2-4ce1-b011-920b85b96426@googlemail.com> Message-ID: On Thu, Sep 12, 2024, 12:57?AM Tim Dickson via SlackBuilds-users < slackbuilds-users at slackbuilds.org> wrote: > On 12/09/2024 06:29, Jeremy Hansen wrote: > > > > On Wed, Sep 11, 2024 at 4:23?AM fourtysixandtwo < > fourtysixandtwo at sliderr.net> wrote: > >> On Tue, Sep 10, 2024 at 12:55?PM Jeremy Hansen >> wrote: >> > export SETUPTOOLS_SCM_PRETEND_VERSION=$VERSION >> > >> > and a few >> > >> > export PDM_BUILD_SCM_VERSION=$VERSION >> > >> > to fix some issue with versions not being detected properly during >> build time (although, I believe several are due to me choosing GitHub >> tarballs instead of PyPi, which are packaged differently). If those hacks >> were to be fixed by these updates, I'd remove them. >> >> I use the pypi tarballs solely because I can also grab the MD5SUM they >> provide with my update script. > > > This isn't an issue for me as my update script will generate MD5SUM > automatically no matter how many source files there are. It will just > download everything in the DOWNLOAD or DOWNLOAD_X86_64 variables in the > .info (if they don't already exist) and then generate MD5s for all of them > and update the .info file. > > >> It is a bonus that I haven't had to use those methods above with any >> builds I maintain. > > > This is a minor inconvenience for a handful of packages that prefer > downloads from PyPi or a git clone (rather than an archive download from a > tag/release). Luckily, out of the 150+ packages I maintain, there's > probably less than a dozen that I had to add this tweak/hack. I think my > preference to GitHub was many python packages I took over that used PyPi as > their source location used hashed download links, which prevented my update > script from using the right download link (although, I suppose I could add > the functionality to switch to links that simply require updating the > version -- future me will worry about that :D). This led me to prefer > GitHub links and then outta sheer stubbornness, when problems arose from > it, I found hacks to continue using GitHub over PyPi. > > >> I just checked with python3-tox and python3-pyproject-api tarballs from >> pypi and they both include a "src/*/*version.py". One does have to watch >> for the change in source from say pyproject-api to pyproject_api in both >> download and SRCNAM though. >> >> Have you come across this for troubleshooting? >> export SETUPTOOLS_SCM_DEBUG=true >> > > I was not aware of that flag, however, it led to either a similar or the > same issue (too lazy to investigate further right now). > > "mAke sURe yoU're EitHer bUildINg frOM A FulLy iNTAcT git RepOsiToRY oR > PyPi taRbaLLs." > > Error, meet stubbornness (my hack) :D > > >> While we are on the topic of setuptools_scm, I have a method using >> venv to upgrade it to 8.1.0, but unfortunately the newer versions do >> not honour PYTHONPATH precedence and import the older slackware 15.0 >> version. One would have to remove the older system package or use the >> venv hack on every slackbuild that requires the newer setuptools_scm >> in /opt. > > > I mean, we currently have to add hacks in SlackBuilds to use newer python > packages residing in /opt/ (which are mostly, if not entirely, packages you > maintain). This has opened up the ability to upgrade a lot of python > packages further than would be allowed if we solely used the packages from > 15.0. They've been very helpful in allowing upgrades without additional > hacks. > > If the newer version offers something severely lacking on Slackware or SBo > today, I (and I can only speak for myself), have no issues adding a line or > few to my SlackBuilds that require that newer version. > > >> Upstream is aware of this issue but don't have any interest in fixing it >> currently. > > > That sucks. > > >> > Go for it! It's easier than me trying to merge your changes and submit >> a PR this week. >> >> Done! >> > > Thanks! > > _______________________________________________ > SlackBuilds-users mailing listSlackBuilds-users at slackbuilds.orghttps://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - https://slackbuilds.org/faq/ > > i found that for some python builds github archives/tags were missing some > of the source, which was included in pypi source download, so have to use > pypi for those. it's a bit more inconvenient, as the url's have the hashes > as you mentioned, but it's not too awkward. > regards, Tim > You can change the PyPi URLs to not have hashes, but you can also usually bypass the missing source files when getting it from GitHub with variables passed during the build process. I usually choose the latter out of spite for PyPi not defaulting to non-hashed source links. However, if you're interested in bypassing the hash-based sources with PyPi, it is based on the following URL layout: https://files.pythonhosted.org/packages/source/${PROJECT::1}/${PROJECT}/${PROJECT}-${VERSION}.tar.gz The ${PROJECT::1} being the first letter of the project/package name. So if it was tox (which is python3-tox on SBo) the url would be (replacing ${VERSION} with the actual version): https://files.pythonhosted.org/packages/source/t/tox/tox-${VERSION}.tar.gz I have a bash function that can find the non-hashed URL for PyPi sources and will correct any download links for GitHub (since they do funky stuff with content disposition). You can work it into a script, add it to your shell using a bashrc or similar, or make it its own script. https://github.com/bassmadrigal/scripts/blob/master/check-source-download.sh Jeremy (I don't know what the crap is going on with the below section of quoted email. I couldn't delete it using Gmail's android app. It really frustrated me, but not enough to go to my computer and see if I can fix it there.) > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dickson.tim at googlemail.com Thu Sep 12 08:35:12 2024 From: dickson.tim at googlemail.com (Tim Dickson) Date: Thu, 12 Sep 2024 09:35:12 +0100 Subject: [Slackbuilds-users] important info regarding python3-hatchling update In-Reply-To: References: <6e9cbbfd-eaf2-4ce1-b011-920b85b96426@googlemail.com> Message-ID: <6b369bb5-9f5f-4cfd-b3ff-0b94f5e1cbd1@googlemail.com> On 12/09/2024 09:14, Jeremy Hansen wrote: > > > On Thu, Sep 12, 2024, 12:57?AM Tim Dickson via SlackBuilds-users > wrote: > > On 12/09/2024 06:29, Jeremy Hansen wrote: >> >> >> On Wed, Sep 11, 2024 at 4:23?AM fourtysixandtwo >> wrote: >> >> On Tue, Sep 10, 2024 at 12:55?PM Jeremy Hansen >> > > wrote: >> > export SETUPTOOLS_SCM_PRETEND_VERSION=$VERSION >> > >> > and a few >> > >> > export PDM_BUILD_SCM_VERSION=$VERSION >> > >> > to fix some issue with versions not being detected properly >> during build time (although, I believe several are due to me >> choosing GitHub tarballs instead of PyPi, which are packaged >> differently). If those hacks were to be fixed by these >> updates, I'd remove them. >> >> I use the pypi tarballs solely because I can also grab the >> MD5SUM they provide with my update script. >> >> >> This isn't an issue for me as my update script will generate >> MD5SUM automatically no matter how many source files there are. >> It will just download everything in the DOWNLOAD or >> DOWNLOAD_X86_64 variables in the .info (if they don't already >> exist) and then generate MD5s for all of them and update the >> .info file. >> >> It is a bonus that I haven't had to use those methods above >> with any builds I maintain. >> >> >> This is a minor inconvenience for a handful of packages that >> prefer downloads from PyPi or a git clone (rather than an archive >> download from a tag/release). Luckily, out of the 150+ packages I >> maintain, there's probably less than a dozen that I had to add >> this tweak/hack. I think my preference to GitHub was many python >> packages I took over that used PyPi as their source location used >> hashed download links, which prevented my update script from >> using the right download link (although, I suppose I could add >> the functionality to switch to links that simply require updating >> the version -- future me will worry about that :D). This led me >> to prefer GitHub links and then outta sheer stubbornness, when >> problems arose from it, I found hacks to continue using GitHub >> over PyPi. >> >> I just checked with python3-tox and python3-pyproject-api >> tarballs from pypi and they both include a >> "src/*/*version.py".? One does have to watch for the change >> in source from say pyproject-api to pyproject_api in both >> download and SRCNAM though. >> >> Have you come across this for troubleshooting? >> export SETUPTOOLS_SCM_DEBUG=true >> >> >> I was not aware of that flag, however, it led to either a similar >> or the same issue (too lazy to investigate further right now). >> >> "mAke sURe yoU're EitHer bUildINg frOM A FulLy iNTAcT git >> RepOsiToRY oR PyPi taRbaLLs." >> >> Error, meet stubbornness (my hack) :D >> >> While we are on the topic of setuptools_scm, I have a method >> using >> venv to upgrade it to 8.1.0, but unfortunately the newer >> versions do >> not honour PYTHONPATH precedence and import the older >> slackware 15.0 >> version.? One would have to remove the older system package >> or use the >> venv hack on every slackbuild that requires the newer >> setuptools_scm >> in /opt. >> >> >> I mean, we currently have to add hacks in SlackBuilds to use >> newer python packages residing in /opt/ (which are mostly, if not >> entirely, packages you maintain). This has opened up the ability >> to upgrade a lot of python packages further than would be allowed >> if we solely used the packages from 15.0. They've been very >> helpful in allowing upgrades without additional hacks. >> >> If the newer version offers something severely lacking on >> Slackware or SBo today, I (and I can only speak for myself), have >> no issues adding a line or few to my SlackBuilds that require >> that newer version. >> >> Upstream is aware of this issue but don't have any interest >> in fixing it currently. >> >> >> That sucks. >> >> > Go for it! It's easier than me trying to merge your changes >> and submit a PR this week. >> >> Done! >> >> >> Thanks! >> >> _______________________________________________ >> 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 found that for some python builds github archives/tags were > missing some of the source, which was included in pypi source > download, so have to use pypi for those. it's a bit more > inconvenient, as the url's have the hashes as you mentioned, but > it's not too awkward. > regards, Tim > > > You can change the PyPi URLs to not have hashes, but you can also > usually bypass the missing source files when getting it from GitHub > with variables passed during the build process. > > I usually choose the latter out of spite for PyPi not defaulting to > non-hashed source links. > > However, if you're interested in bypassing the hash-based sources with > PyPi, it is based on the following URL layout: > > https://files.pythonhosted.org/packages/source/${PROJECT::1}/${PROJECT}/${PROJECT}-${VERSION}.tar.gz > > > The?${PROJECT::1} being the first letter of the project/package name. > > So if it was tox (which is python3-tox on SBo) the url would be > (replacing ${VERSION} with the actual version): > > https://files.pythonhosted.org/packages/source/t/tox/tox-${VERSION}.tar.gz > > > I have a bash function that can find the non-hashed URL for PyPi > sources and will correct any download links for GitHub (since they do > funky stuff with content disposition). You can work it into a script, > add it to your shell using a bashrc or similar, or make it its own > script. > > https://github.com/bassmadrigal/scripts/blob/master/check-source-download.sh > > Jeremy > > (I don't know what the crap is going on with the below section of > quoted email. I couldn't delete it using Gmail's android app. It > really frustrated me, but not enough to go to my computer and see if I > can fix it there.) > thanks, that's really useful info. It looks similar to sourceforge upload urls in that respect. It would be useful to have all these sort of tips for slackbuild maintainers in a central place. maybe https://www.slackwiki.com/Writing_A_SlackBuild_Script? ,or is there a better place? regards, Tim -- This email has been checked for viruses by AVG antivirus software. www.avg.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From fellype at gmail.com Thu Sep 12 13:38:04 2024 From: fellype at gmail.com (Fellype) Date: Thu, 12 Sep 2024 10:38:04 -0300 Subject: [Slackbuilds-users] Windows 32/64 apps without multilib In-Reply-To: <26zu41.siq9w0.0-qmf@orgizm.net> References: <5a9f4916-caaf-459e-9e5c-fbcf300e06aa.ref@yahoo.com> <5a9f4916-caaf-459e-9e5c-fbcf300e06aa@yahoo.com> <26zu41.siq9w0.0-qmf@orgizm.net> Message-ID: Hello! Em qua., 4 de set. de 2024 ?s 10:23, Ruben Schuller escreveu: > Hi! > > The wine found on SBo now can run win32 applications on slackware64 > without multilib! Wouldn't have known but someone recently told me as well > :) > Yes. Most win32 softwares just run fine on Slackware 64-bit when using wine 9.0 from SBo. > > Notepad++ editor: > > > https://github.com/antonioleal/myslackbuilds/tree/main/development/notepad%2B%2B > > > Notepad++ is a good example of a win32 software running without problems with wine 9 on Slackware 64 Regards, Fellype -------------- next part -------------- An HTML attachment was scrubbed... URL: From roberto.puzzanghera at sagredo.eu Thu Sep 12 14:18:40 2024 From: roberto.puzzanghera at sagredo.eu (Roberto Puzzanghera) Date: Thu, 12 Sep 2024 16:18:40 +0200 Subject: [Slackbuilds-users] Taking over viking and gpsd pkgs Message-ID: <41ce216e-8d30-4eb7-bc35-bf37d07e80f5@sagredo.eu> I contacted the maintainer of viking and gpsd (viking's dep) on September 1, using two different email addresses, also I tried to contact him last year, but I've never got any responce. So, if any of you don't have direct contact with David Spencer I would take over these two packages. Roberto From urchlay at slackware.uk Thu Sep 12 18:07:09 2024 From: urchlay at slackware.uk (B. Watson) Date: Thu, 12 Sep 2024 14:07:09 -0400 (EDT) Subject: [Slackbuilds-users] Taking over viking and gpsd pkgs In-Reply-To: <41ce216e-8d30-4eb7-bc35-bf37d07e80f5@sagredo.eu> References: <41ce216e-8d30-4eb7-bc35-bf37d07e80f5@sagredo.eu> Message-ID: <9f4dd1d8-e5cf-369d-3df4-d2f6c7821dfc@slackware.uk> On Thu, 12 Sep 2024, Roberto Puzzanghera via SlackBuilds-users wrote: > I contacted the maintainer of viking and gpsd (viking's dep) on September 1, > using two different email addresses, also I tried to contact him last year, > but I've never got any responce. Did you already try to contact him via this mailing list? If not, wait a few days, see if he responds here. > So, if any of you don't have direct contact with David Spencer I would take > over these two packages. David Spencer's last activity in the git log was over a year ago. He has 327 builds... I hope he hasn't disappeared. David, if you're reading this, please let us know whether you're still maintaining your builds. From roberto.puzzanghera at sagredo.eu Thu Sep 12 18:42:35 2024 From: roberto.puzzanghera at sagredo.eu (Roberto Puzzanghera) Date: Thu, 12 Sep 2024 20:42:35 +0200 Subject: [Slackbuilds-users] Taking over viking and gpsd pkgs In-Reply-To: <9f4dd1d8-e5cf-369d-3df4-d2f6c7821dfc@slackware.uk> References: <41ce216e-8d30-4eb7-bc35-bf37d07e80f5@sagredo.eu> <9f4dd1d8-e5cf-369d-3df4-d2f6c7821dfc@slackware.uk> Message-ID: Il 12/09/24 20:07, B. Watson ha scritto: > > > On Thu, 12 Sep 2024, Roberto Puzzanghera via SlackBuilds-users wrote: > >> I contacted the maintainer of viking and gpsd (viking's dep) on >> September 1, using two different email addresses, also I tried to >> contact him last year, but I've never got any responce. > > Did you already try to contact him via this mailing list? If not, wait > a few days, see if he responds here. last year I posted here the question if I could take over viking, but I got no response. Let's wait a few days. From pyllyukko at maimed.org Sat Sep 14 07:44:51 2024 From: pyllyukko at maimed.org (pyllyukko) Date: Sat, 14 Sep 2024 10:44:51 +0300 Subject: [Slackbuilds-users] oidentd In-Reply-To: <1b4a8a59-9d62-2126-9357-9ae15899d23b@slackware.uk> References: <3e2eff12-b47e-4b55-151d-3519c3400aa0@gmail.com> <596142be-9cad-5899-4789-35596eec1ccb@slackware.uk> <04019ef7-5ade-444d-e2e5-fdb841e31086@gmail.com> <1b4a8a59-9d62-2126-9357-9ae15899d23b@slackware.uk> Message-ID: Ehlo. On Sat, Sep 07, 2024 at 05:32:32AM -0400, B. Watson wrote: > I have no idea what you're using oidentd for. The usual use is for > IRC, but don't think modern IRC networks actually require it. At least > libera doesn't, I know for a fact. I use it for IRC even though it is not required. I can take over the maintainership if it's cool with Mario. -- 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 willysr at slackbuilds.org Sat Sep 14 16:47:49 2024 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sat, 14 Sep 2024 23:47:49 +0700 Subject: [Slackbuilds-users] Updates - 20240914.1 Message-ID: <0c883eb6-0a8b-4ffb-ad6b-440dc4f1f5a9@slackbuilds.org> Sat Sep 14 16:37:48 UTC 2024 academic/R: Updated for version 4.4.1. academic/edsim51di: Updated for version 2.1.36. academic/fet: Updated for version 6.25.0. academic/zotero: updated for version 7.0.5 audio/MP3Diags: Mark as orphaned audio/icecast: update contact email audio/japa: Updated for version 0.9.4. audio/jkmeter: Updated for version 0.9.0. audio/klick: Updated for version 0.14.2. audio/volctl: update contact email audio/wavbreaker: new maintainer desktop/calcure: Rename pytz dependency desktop/gtk-xfce-engine: New maintainer. desktop/murrine-themes: New maintainer. desktop/nwg-displays: Updated for version 0.3.21. desktop/nwg-shell: Updated for version 0.5.38. desktop/py3status: Fix for new hatchling. desktop/wl-mirror: Added (simple Wayland output mirror client). desktop/xfce4-cpufreq-plugin: New maintainer. desktop/xfce4-volumed-pulse: Updated for version 0.2.4, new maintainer. desktop/xfwm4-themes: New maintainer. development/android-tools: Updated for version 35.0.2 development/astyle: Updated for version 3.6.1. development/avrdude: Updated for version 8.0. development/aws-cdk: Updated for version 2.158.0. development/cosmocc: Updated for version 3.8.0. development/github-cli: Updated for version 2.56.0 development/gitlab-cli: Updated for version 1.46.0 development/heroku-cli: Updated for version 9.2.1 development/hugo: Updated for version 0.134.2. development/ieee-pilot: Added (CAI language Pilot impl). development/jupyter-ipykernel: Fix for new hatchling. development/jupyter-nbclient: Fix for new hatchling. development/jupyter-nbconvert: Fix for new hatchling. development/jupyter-nbformat: Fix for new hatchling. development/jupyter-notebook_shim: Fix for new hatchling. development/jupyter_client: Fix for new hatchling. development/jupyter_console: Fix for new hatchling. development/jupyter_core: Fix for new hatchling. development/jupyter_events: Fix for new hatchling. development/jupyter_packaging: Fix for new hatchling. development/jupyter_server: Fix for new hatchling. development/jupyter_server_terminals: Fix for new hatchling. development/jupyterlab_server: Fix for new hatchling. development/lua-language-server: Updated for version 3.10.6. development/luajit: Fix Download URL. development/mawk: Updated for version 1.3.4_20240905. development/mongodb-compass: Updated for version 1.44.3. development/pandas: Rename pytz dependency (+convert python to python2) development/pgmodeler: Updated for version 1.1.4. development/python3-matplotlib: Edit mention of pytz self-test dependency in README development/rider: Updated for version 2024.2.4. development/vscode-bin: Updated for version 1.93.1. development/xmake: Updated for version 2.9.5. games/alienarena: New maintainer games/brainparty: New maintainer games/chroma: New maintainer games/chromium-bsu: New maintainer games/commandergenius: Updated for version 3.5.1. games/cubosphere: New maintainer games/cuyo: New maintainer games/domination: Updated for version 1.3.1. games/glestae: New maintainer games/jag: New maintainer games/mame: Updated for version 0.269. games/meandmyshadow: New maintainer games/megaglest: New maintainer games/minetest: Updated for version 5.9.0. games/pasang-emas: New maintainer games/peg-e: New maintainer games/rezerwar: New maintainer games/srb2: Updated for version 2.2.13. games/xonotic: update contact email games/yabause: New maintainer gis/OWSLib: Rename pytz dependency gis/geos: Updated for version 3.13.0. graphics/GraphicsMagick: Updated for version 1.3.45. graphics/OpenCASCADE: Fix cmake config. Check ffmpeg version graphics/chafa: Updated for version 1.14.4. graphics/gimp-plugin-export-layers: new maintainer graphics/kuickshow: Updated for version 20240604_3712aa0. graphics/qimgv: update contact email graphics/vuescan: Updated MD5SUMs. ham/flmsg: Updated for version 4.0.23. ham/gridtracker: Updated for version 1.24.0908. libraries/PrettyTable: Fix for new hatchling. libraries/antlr4: Updated for version 4.13.2. libraries/curlpp: Added (C++ wrapper for libcURL). libraries/libcoap: Updated for version 4.3.5. libraries/libcurl-gnutls: Updated for version 8.10.0. libraries/libdca: New maintainer. libraries/liblqr: Updated for version 0.4.3. libraries/liboauth: update contact email libraries/libshout: New maintainer. libraries/live555: New maintainer. libraries/pylast: Fix for new hatchling. libraries/python2-matplotlib: Rename pytz dependency libraries/python3-plumbum: Fix for new hatchling. libraries/python3-rpyc: Fix for new hatchling. libraries/qt-installer-script: Added (Qt Installer). libraries/webkit2gtk4.1: Updated for version 2.44.4. libraries/webkit2gtk: Updated for version 2.44.4. libraries/wxWidgets: Updated for version 3.2.6. libraries/zziplib: Generate doinst.sh for mandb. misc/keychain: new maintainer misc/lppf: Add missing patches. multimedia/MediathekView: Updated for version 14.1.0. multimedia/pipe-viewer: Updated for version 0.5.3. multimedia/plexmediaserver: Updated for version 1.41.0.8992_8463ad060. multimedia/videomass: Fix for new hatchling. multimedia/youtube-music: Updated for version 3.5.2. multimedia/zvbi: New maintainer. network/SoulseekQt: Mark as orphaned network/brave-browser: Updated for version 1.69.168. network/courier-unicode: new maintainer network/cowpatty: Mark as orphaned network/discord: Updated for version 0.0.68. network/dnscrypt-proxy: Replaced init, minor tweaks. network/dropbox: Updated for version 207.4.5821. network/electrs: Rewrote init and fixed some mistakes in the build script. network/grafana: Added (monitoring tool). network/haproxy: Updated for version 3.0.4. network/librewolf: Updated for version 130.0 network/maildrop: new maintainer network/microsoft-edge: Updated for version 128.0.2739.79. network/mpop: Updated for version 1.4.20. network/nextcloud-desktop: Updated for version 3.13.4. network/nullidentd: Added (small, fast identd daemon). network/oidentd: Updated for version 3.1.0, new maintainer. network/opera: Updated for version 113.0.5230.86. network/pidgin-extprefs: Mark as orphaned network/radicale: Fix permission. network/radicale: Rename pytz dependency network/rclone: Updated for version 1.68.0. network/signal-desktop: Updated for version 7.24.1. network/skype4pidgin: Mark as orphaned network/tailscale: updated for version 1.74.0 network/telegram: Updated for version 5.5.1. network/telegram: Updated for version 5.5.3. network/telegram: Updated for version 5.5.5. network/vivaldi: Updated for version 6.9.3447.44. network/whalebird: Updated for version 6.1.4. network/whatsie: Updated for version 4.15.5. network/yt-dlp: Fix for new hatchling. network/zeek: Updated for version 6.0.6. office/LibreOffice: Updated for version 24.8.1.2 office/homebank: Updated for version 5.8.2. office/latexdiff: New maintainer office/latexdiff: Update for version 1.3.4. office/libreoffice-helppack: Updated for version 24.8.1. office/libreoffice-langpack: Updated for version 24.8.1. office/libreoffice: Updated for version 24.8.1. office/pandoc: Updated for version 3.4. office/sioyek: Added (pdf viewer). perl/perl-CryptX: Updated for version 0.081. perl/perl-ExtUtils-InstallPaths: Updated for version 0.014. perl/perl-HTML-Template: New maintainer. perl/perl-Module-Build-Tiny: Updated for version 0.051. perl/perl-Text-Iconv: Mark as orphaned perl/perl-Text-Soundex: New maintainer. perl/perl-local-lib: Updated for version 2.000029. python/BeautifulSoup4: Fix for new hatchling. python/GeoIP-Python: Mark as orphaned python/babel: Rename pytz dependency python/colorama: Fix for new hatchling. python/django-debug-toolbar: Fix for new hatchling. python/freetype-py: Updated for version 2.5.1. python/humanize: Fix for new hatchling. python/pandocfilters: Removed (renamed to python3-pandocfilters) python/pelican: Rename pytz dependency python/plaso: Rename pytz dependency python/pyotp: Mark as orphaned python/python-importlib_metadata: Updated for version 8.5.0. python/python-zipp: Updated for version 3.20.1. python/python3-Flask-RESTX: Rename pytz dependency python/python3-Flask-RESTful: Rename pytz dependency python/python3-Flask-WTF: Fix for new hatchling. python/python3-WTForms: Fix for new hatchling. python/python3-aiofiles: Fix for new hatchling. python/python3-annotated-types: Updated for version 0.7.0. python/python3-argon2-cffi: Fix for new hatchling. python/python3-atpublic: Fix for new hatchling. python/python3-attrs: Fix for new hatchling. python/python3-babel: Rename pytz dependency python/python3-black: Fix for new hatchling. python/python3-build: Updated for version 1.2.2. python/python3-cattrs: Updated for version 24.1.1. python/python3-comm: Fix for new hatchling. python/python3-daemon: Temp workaround for new setuptools. python/python3-dep-logic: Updated for version 0.4.6. python/python3-dnspython: Fix for new hatchling. python/python3-docker: Fix for new hatchling. python/python3-exceptiongroup: Updated for version 1.2.2. python/python3-filelock: Fix for new hatchling. python/python3-flufl.i18n: Fix for new hatchling. python/python3-flufl.lock: Fix for new hatchling. python/python3-glyphslib: Updated for version 6.8.2. python/python3-hatch-nodejs-version: Fix for new hatchling. python/python3-hatch_fancy_pypi_readme: Fix for new hatchling. python/python3-hatch_jupyter_builder: Fix for new hatchling. python/python3-hatch_vcs: Fix for new hatchling. python/python3-hatchling: Updated for version 1.25.0. python/python3-hishel: Fix for new hatchling. python/python3-httpcore: Fix for new hatchling. python/python3-httpx: Fix for new hatchling. python/python3-icalendar: Rename pytz dependency python/python3-iniconfig: Fix for new hatchling. python/python3-jsonlines: update contact email python/python3-jsonschema: Fix for new hatchling. python/python3-maturin: Updated for version 1.7.1. python/python3-meson-opt: Updated for version 1.5.1. python/python3-more-itertools: Updated for version 10.5.0. python/python3-msal: Updated for version 1.31.0. python/python3-multidict: Updated for version 6.1.0. python/python3-orjson: Updated for version 3.10.7. python/python3-packaging-opt: Added (Core utilities for Python packages). python/python3-pandas: Rename pytz dependency python/python3-pdm: Updated for version 2.18.2. python/python3-pipx: Fix for new hatchling. python/python3-plotly: Updated for version 5.24.1. python/python3-poetry-dynamic-versioning: Updated for version 1.4.1. python/python3-pydantic-core: Updated for version 2.23.3. python/python3-pydantic: Updated for version 2.9.1. python/python3-pyproject-api: Fix for new hatchling. python/python3-pytest: Updated for version 8.3.3. python/python3-pytz: Update for 2024.2 python/python3-regex: Update for 2024.9.11 python/python3-service-identity: Fix for new hatchling. python/python3-setuptools-opt: Updated for version 74.1.2. python/python3-setuptools-rust-opt: Updated for version 1.10.1. python/python3-soupsieve: Fix for new hatchling. python/python3-tempora: Rename pytz dependency python/python3-terminado: Fix for new hatchling. python/python3-tox: Fix for new hatchling. python/python3-twisted: Fix for new hatchling. python/python3-ufo2ft: Updated for version 3.2.8. python/python3-uharfbuzz: Updated for version 0.39.5. python/python3-userpath: Fix for new hatchling. python/python3-virtualenv: Updated for version 20.26.4. python/python3-watchdog: Update for 5.0.2 python/python3-wheel: Updated for version 0.44.0. python/python3-yarl: Updated for version 1.11.1. python/taskw: Rename pytz dependency python/termcolor: Fix for new hatchling. python/terminado: Removed (renamed to python3-terminado) python/testpath: Removed (renamed to python3-testpath) python/traitlets: Fix for new hatchling. python/tzlocal: Rename pytz dependency system/B-em: Update for version 20240820_5ce9c1b. system/Iosevka-aile: Updated for version 31.6.1. system/Iosevka-etoile: Updated for version 31.6.1. system/Solaar: Updated for version 1.1.13. system/ansifilter: Updated for version 2.21. system/apache-cassandra: Updated for version 4.1.6. system/apg: Updated for version 2.3.0b+20240821_dcddc65. system/cowsql: Added (SQL engine). system/dget: Updated source. system/docker-buildx: Updated for version 0.17.1. system/dust: Updated for version 1.1.1. system/incus: Added (system container). system/letsencrypt: Rename pytz dependency system/limine: Updated for version 8.0.11 system/linkchecker: Updated for version 10.5.0. system/locust: Updated deps. system/netdata: Updated for version 1.47.1. system/openzfs: updated for version 2.2.6 system/osquery-bin: Updated for version 5.13.1. system/prometheus: Updated to version 2.54.1 system/raft: Added (Raft consensus protocol). system/rhash: update contact email system/sdl2trs: Updated for version 1.2.30+20240818_fe765966. system/sdltrs: Updated for version 1.2.30. system/telegraf: Updated for version 1.32.0 system/usbguard: Updated for version 1.1.3. system/wine-staging: Updated for version 9.17. system/yubico-piv-tool: Updated for version 2.6.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 lumin at etherlight.link Sat Sep 14 19:44:53 2024 From: lumin at etherlight.link (lumin at etherlight.link) Date: Sat, 14 Sep 2024 19:44:53 +0000 Subject: [Slackbuilds-users] Maybe Taking Over Some Packages Message-ID: <20240914194453.96D15220485@wave.etherlight.link> Hello friends, I'm interested in taking over the following packages: system/busybox Maintainer mail server timing out, package behind many versions. graphics/feh Maintainer was contacted, they said they haven't been active on SBo for a while, and that someone should take feh over. graphics/optipng There was discussion about it being vulnerable and unmaintained, seems urchlay updated it, but I can help with this one if he wants. A few questions on the responsibility of a maintainer: 1. Is there any comprehensive guide on that? A link to said guide would be appreciated. 2. What platforms should I test for? Is a clean chroot or VM of x64 stable enough for now? or should I test on x86, arm, -current combinations? Personally I currently only use stable x64 15.0. 3. feh and optipng are relatively simple to test, and I use them frequently, but with busybox there is a huge number of things to test; personally I only use a subset in some scripts. Any solutions for this problem? (e.g. a way for multiple test users to try it out before publishing it to SBo proper). 4. If my request to take over the packages is granted, do I wait until next upstream update? Or do I push an update to change the maintainer immediately? 5. If I don't want to use GitHub or GitLab, what other options do I have? Can I send git patch emails somewhere? Or is the web submission form the only alternative? Thank you all for your work on SlackBuilds. Best Regards Lumin Etherlight From 1.41421 at gmail.com Sun Sep 15 14:22:43 2024 From: 1.41421 at gmail.com (Luveh Keraph) Date: Sun, 15 Sep 2024 08:22:43 -0600 Subject: [Slackbuilds-users] sbotools not working any more, or is it just me? Message-ID: After the most recent slackbuilds update sbotools has stopped working for me. I used to be able to invoke sboupgrade --all and I would be prompted to apply upgrades on packages that I have built from Slackbuilds, and for which an upgrade is found to exist. That is not working any more: no upgrades are detected by this tool now. And when I upgrade a package by hand, using sbopkg -i, on running sbocheck I am informed that my version is more recent than that in the Slackbuilds tree, and that I must upgrade - which, in this case, would be a downgrade. I haven't touched anything to do with sbotools recently. Might anybody in this forum know what could possibly be going on, and how to fix it? -------------- next part -------------- An HTML attachment was scrubbed... URL: From j+sbo-users at maschinengott.de Sun Sep 15 15:10:43 2024 From: j+sbo-users at maschinengott.de (J) Date: Sun, 15 Sep 2024 17:10:43 +0200 Subject: [Slackbuilds-users] KiCAD and webkit2gtk Message-ID: <2aca923e-78c9-4f8a-acf5-a0eac1cc3d5c@maschinengott.de> Hi. I was just going through SBo packages that needed upgrading (I don't keep on top of it regularly) with `sbopkg -c` and generated a queue for kicad. This queue contains webkit2gtk4.1 (as a dependency of wxPython4) and webkit2gtk (as a dependency of wxWidgets). These two have notes that they can't be installed at the same time: > This package builds the 4.0 WebKit API. If you need 4.1 WebKit API, use webkit2gtk4.1. Don't install both at the same time!! Aside from the ridiculousness of having to do the same several hour build twice for the same software? What's going on there? Ciao, Jay From bgrundy at linuxleo.com Sun Sep 15 16:14:48 2024 From: bgrundy at linuxleo.com (Barry J. Grundy) Date: Sun, 15 Sep 2024 12:14:48 -0400 Subject: [Slackbuilds-users] sbotools not working any more, or is it just me? In-Reply-To: References: Message-ID: On 24/09/15 08:22AM, Luveh Keraph wrote: > After the most recent slackbuilds update sbotools has stopped working for > me. I used to be able to invoke sboupgrade --all and I would be prompted to > apply upgrades on packages that I have built from Slackbuilds, and for > which an upgrade is found to exist. > > That is not working any more: no upgrades are detected by this tool now. > And when I upgrade a package by hand, using sbopkg -i, on running > sbocheck I am informed that my version is more recent than that in the > Slackbuilds tree, and that I must upgrade - which, in this case, would be a > downgrade. > > I haven't touched anything to do with sbotools recently. Might anybody in > this forum know what could possibly be going on, and how to fix it? FWIW, sbotools is behaving the same way it always has for me. No issues after the last update. Have you looked at /etc/sbotools/sbotools.conf? Is the proper repo still set? Maybe your conf got clobbered somehow. Barry From 1.41421 at gmail.com Sun Sep 15 16:28:41 2024 From: 1.41421 at gmail.com (Luveh Keraph) Date: Sun, 15 Sep 2024 10:28:41 -0600 Subject: [Slackbuilds-users] sbotools not working any more, or is it just me? In-Reply-To: References: Message-ID: Thanks. The contents of my /etc/sbotools/sbotools.conf are the following: SLACKWARE_VERSION=15.0 REPO=https://gitlab.com/SlackBuilds.org/slackbuilds.git They have not changed for almost two years. What is intriguing here is that the problems that I am reporting have appeared simultaneously in six different systems. Let me show you the output from sbocheck in one of them: HEAD is now at 35ff2388af Public www update: Sat Sep 7 02:10:43 UTC 2024. Checking for updated SlackBuilds... brave-browser 1.69.168 < needs updating (1.69.162 from SBo) libreoffice 24.8.1 < needs updating (24.8.0 from SBo) netdata 1.47.1 < needs updating (1.47.0 from SBo) opera 113.0.5230.86 < needs updating (113.0.5230.55 from SBo) My sbotools environment does not know about the Slackbuilds upgrades that were made publicly available two days ago. I have repeatedly synced sbopkg, to no avail. On Sun, Sep 15, 2024 at 10:14?AM Barry J. Grundy wrote: > > On 24/09/15 08:22AM, Luveh Keraph wrote: > > After the most recent slackbuilds update sbotools has stopped working for > > me. I used to be able to invoke sboupgrade --all and I would be prompted > to > > apply upgrades on packages that I have built from Slackbuilds, and for > > which an upgrade is found to exist. > > > > That is not working any more: no upgrades are detected by this tool now. > > And when I upgrade a package by hand, using sbopkg -i, on running > > sbocheck I am informed that my version is more recent than that in the > > Slackbuilds tree, and that I must upgrade - which, in this case, would > be a > > downgrade. > > > > I haven't touched anything to do with sbotools recently. Might anybody in > > this forum know what could possibly be going on, and how to fix it? > > FWIW, sbotools is behaving the same way it always has for me. No issues > after the last update. Have you looked at /etc/sbotools/sbotools.conf? > Is the proper repo still set? Maybe your conf got clobbered somehow. > > Barry > _______________________________________________ > 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 jebrhansen+SBo at gmail.com Sun Sep 15 18:19:44 2024 From: jebrhansen+SBo at gmail.com (Jeremy Hansen) Date: Sun, 15 Sep 2024 11:19:44 -0700 Subject: [Slackbuilds-users] sbotools not working any more, or is it just me? In-Reply-To: References: Message-ID: It looks like GitLab was not updated with this last public update. It's showing the latest update is on the 7th rather than the 14th. You could try switching your repo to GitHub's mirror: https://github.com/SlackBuildsOrg/slackbuilds.git You could also try using SBo's official repo, but I'm not positive this is the right address: https://git.slackbuilds.org/slackbuilds.git Then just try a sync and see if it finds the 14 September public update. Jeremy On Sun, Sep 15, 2024, 9:28?AM Luveh Keraph <1.41421 at gmail.com> wrote: > Thanks. The contents of my /etc/sbotools/sbotools.conf are the following: > > SLACKWARE_VERSION=15.0 > REPO=https://gitlab.com/SlackBuilds.org/slackbuilds.git > > They have not changed for almost two years. > > What is intriguing here is that the problems that I am reporting have > appeared simultaneously in six different systems. Let me show you the > output from sbocheck in one of them: > > HEAD is now at 35ff2388af Public www update: Sat Sep 7 02:10:43 UTC 2024. > Checking for updated SlackBuilds... > > brave-browser 1.69.168 < needs updating (1.69.162 from SBo) > libreoffice 24.8.1 < needs updating (24.8.0 from > SBo) > netdata 1.47.1 < needs updating (1.47.0 from > SBo) > opera 113.0.5230.86 < needs updating (113.0.5230.55 from > SBo) > > My sbotools environment does not know about the Slackbuilds upgrades that > were made publicly available two days ago. I have repeatedly synced sbopkg, > to no avail. > > > > > On Sun, Sep 15, 2024 at 10:14?AM Barry J. Grundy > wrote: > >> >> On 24/09/15 08:22AM, Luveh Keraph wrote: >> > After the most recent slackbuilds update sbotools has stopped working >> for >> > me. I used to be able to invoke sboupgrade --all and I would be >> prompted to >> > apply upgrades on packages that I have built from Slackbuilds, and for >> > which an upgrade is found to exist. >> > >> > That is not working any more: no upgrades are detected by this tool now. >> > And when I upgrade a package by hand, using sbopkg -i, on running >> > sbocheck I am informed that my version is more recent than that in the >> > Slackbuilds tree, and that I must upgrade - which, in this case, would >> be a >> > downgrade. >> > >> > I haven't touched anything to do with sbotools recently. Might anybody >> in >> > this forum know what could possibly be going on, and how to fix it? >> >> FWIW, sbotools is behaving the same way it always has for me. No issues >> after the last update. Have you looked at /etc/sbotools/sbotools.conf? >> Is the proper repo still set? Maybe your conf got clobbered somehow. >> >> Barry >> _______________________________________________ >> SlackBuilds-users mailing list >> SlackBuilds-users at slackbuilds.org >> https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users >> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ >> FAQ - https://slackbuilds.org/faq/ >> >> _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - https://slackbuilds.org/faq/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From 1.41421 at gmail.com Sun Sep 15 18:27:41 2024 From: 1.41421 at gmail.com (Luveh Keraph) Date: Sun, 15 Sep 2024 12:27:41 -0600 Subject: [Slackbuilds-users] sbotools not working any more, or is it just me? In-Reply-To: References: Message-ID: Thanks. Changing to the GitHub mirror does indeed fix the sbocheck issue that I reported. On Sun, Sep 15, 2024 at 12:19?PM Jeremy Hansen wrote: > It looks like GitLab was not updated with this last public update. It's > showing the latest update is on the 7th rather than the 14th. > > You could try switching your repo to GitHub's mirror: > > https://github.com/SlackBuildsOrg/slackbuilds.git > > You could also try using SBo's official repo, but I'm not positive this is > the right address: > > https://git.slackbuilds.org/slackbuilds.git > > Then just try a sync and see if it finds the 14 September public update. > > Jeremy > > On Sun, Sep 15, 2024, 9:28?AM Luveh Keraph <1.41421 at gmail.com> wrote: > >> Thanks. The contents of my /etc/sbotools/sbotools.conf are the following: >> >> SLACKWARE_VERSION=15.0 >> REPO=https://gitlab.com/SlackBuilds.org/slackbuilds.git >> >> They have not changed for almost two years. >> >> What is intriguing here is that the problems that I am reporting have >> appeared simultaneously in six different systems. Let me show you the >> output from sbocheck in one of them: >> >> HEAD is now at 35ff2388af Public www update: Sat Sep 7 02:10:43 UTC 2024. >> Checking for updated SlackBuilds... >> >> brave-browser 1.69.168 < needs updating (1.69.162 from SBo) >> libreoffice 24.8.1 < needs updating (24.8.0 >> from SBo) >> netdata 1.47.1 < needs updating (1.47.0 >> from SBo) >> opera 113.0.5230.86 < needs updating (113.0.5230.55 >> from SBo) >> >> My sbotools environment does not know about the Slackbuilds upgrades that >> were made publicly available two days ago. I have repeatedly synced sbopkg, >> to no avail. >> >> >> >> >> On Sun, Sep 15, 2024 at 10:14?AM Barry J. Grundy >> wrote: >> >>> >>> On 24/09/15 08:22AM, Luveh Keraph wrote: >>> > After the most recent slackbuilds update sbotools has stopped working >>> for >>> > me. I used to be able to invoke sboupgrade --all and I would be >>> prompted to >>> > apply upgrades on packages that I have built from Slackbuilds, and for >>> > which an upgrade is found to exist. >>> > >>> > That is not working any more: no upgrades are detected by this tool >>> now. >>> > And when I upgrade a package by hand, using sbopkg -i, on running >>> > sbocheck I am informed that my version is more recent than that in the >>> > Slackbuilds tree, and that I must upgrade - which, in this case, would >>> be a >>> > downgrade. >>> > >>> > I haven't touched anything to do with sbotools recently. Might anybody >>> in >>> > this forum know what could possibly be going on, and how to fix it? >>> >>> FWIW, sbotools is behaving the same way it always has for me. No issues >>> after the last update. Have you looked at /etc/sbotools/sbotools.conf? >>> Is the proper repo still set? Maybe your conf got clobbered somehow. >>> >>> Barry >>> _______________________________________________ >>> SlackBuilds-users mailing list >>> SlackBuilds-users at slackbuilds.org >>> https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users >>> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ >>> FAQ - https://slackbuilds.org/faq/ >>> >>> _______________________________________________ >> SlackBuilds-users mailing list >> SlackBuilds-users at slackbuilds.org >> https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users >> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ >> FAQ - https://slackbuilds.org/faq/ >> >> _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - https://slackbuilds.org/faq/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From urchlay at slackware.uk Sun Sep 15 19:55:41 2024 From: urchlay at slackware.uk (B. Watson) Date: Sun, 15 Sep 2024 15:55:41 -0400 (EDT) Subject: [Slackbuilds-users] Maybe Taking Over Some Packages In-Reply-To: <20240914194453.96D15220485@wave.etherlight.link> References: <20240914194453.96D15220485@wave.etherlight.link> Message-ID: <4e1a8b8a-1661-52be-ff9b-e87968ab5dde@slackware.uk> On Sat, 14 Sep 2024, lumin--- via SlackBuilds-users wrote: > system/busybox > Maintainer mail server timing out, > package behind many versions. Jan F. Chadima hasn't been active since 2020. Go ahead and take this one over. Looks like Chadima has a lot more builds that need maintainers. Anyone reading this is welcome to grab them. List here: https://slackbuilds.org/advsearch.php?stype=maint&q=jfch%40jagda.eu > graphics/feh > Maintainer was contacted, they said they > haven't been active on SBo for a while, > and that someone should take feh over. > > graphics/optipng > There was discussion about it being > vulnerable and unmaintained, seems > urchlay updated it, but I can help > with this one if he wants. I took both of these, rather than see them go unmaintained. But, if you're interested, you're welcome to them. I have 900 builds already, I won't miss these :) One request: please base your versions on my updated versions. > A few questions on the responsibility > of a maintainer: > > 1. Is there any comprehensive guide on that? > A link to said guide would be appreciated. I'm working on writing such a guide, but it's not finished yet. The short version: when you maintain a script, you're responsible for responding to emails from users, helping them with any problems they may have. You're also responsible for keeping the script updated, when the software updates... though you don't have to "knee-jerk" upgrade as soon as a new release comes out. You want to do some actual testing, make sure the upgrade doesn't break anything. *Especially*, you have to make sure your upgrade doesn't break any other builds that depend on yours! Use the "advanced search" on the site to do a Dependee search, to find out what depends on your build. There are tools to help you keep your builds clean. Use sbolint and sbopkglint from sbo-maintainer-tools to check them. > 2. What platforms should I test for? Is a > clean chroot or VM of x64 stable enough > for now? or should I test on x86, arm, > -current combinations? Personally I > currently only use stable x64 15.0. Please test on 15.0, on both x86 and x86_64, clean environment (chroot or VM). I recommend testing on both a clean environment *and* a "dirty" environment with lots of other SBo packages installed (to catch conflicts with other builds), but not everyone agrees with me that the dirty testing is worth the effort. We don't support -current, so don't worry about testing there unless you really really want to. There's an unofficial fork of the SBo repo, run by Matteo Bernardini aka ponce, where fixes for -current are gathered. We don't support 32-bit arm, and never will AFAIK. We have plans to support 64-bit arm (aarch64) sometime after Slackware 15.1 is released, but even then, maintainers won't really be expected to test everything on it. Not everyone owns the hardware, and emulation is painfully slow. All that'll be required is, if an aarch64 user sends you a patch to fix the build on aarch64, you'll apply the patch (unless it's broken of course). > 3. feh and optipng are relatively simple to > test, and I use them frequently, but with > busybox there is a huge number of things > to test; personally I only use a subset > in some scripts. Any solutions for this > problem? (e.g. a way for multiple test > users to try it out before publishing it > to SBo proper). You can put your modified script somewhere public and post on the mailing list about it, ask for people to help you test it. > 4. If my request to take over the packages is > granted, do I wait until next upstream > update? Or do I push an update to change > the maintainer immediately? Go ahead and send an update to change the maintainer info immediately. You could also make other changes at the same time (version update, or fix a bug). > 5. If I don't want to use GitHub or GitLab, > what other options do I have? Can I send > git patch emails somewhere? Or is the web > submission form the only alternative? I'm not in charge of the github/gitlab stuff (I don't even have accounts on either service), but so far as I know, the choices are github, gitlab, or the web submission form. I don't think we ever pull from any other git repos. If I'm wrong, someone (Willy) will probably correct me. There are a couple of tools that automate the process of using the web submission form, which would be better than doing it manuall with a browser. One is called "sbosubmit". > Thank you all for your work on SlackBuilds. Thank you for your interest. Hope this answers some of your questions in a useful way. The Maintainer FAQ is still a work in progress, and your email has motivated me to start working on it again. From lumin+slackbuilds at etherlight.link Mon Sep 16 01:16:43 2024 From: lumin+slackbuilds at etherlight.link (Lumin Etherlight) Date: Mon, 16 Sep 2024 01:16:43 +0000 Subject: [Slackbuilds-users] Reverting system/busybox to Default Build Configurations Message-ID: <20240916011643.cD7ib%lumin+slackbuilds@etherlight.link> Hello, fellow slackbuilders, I'm working on an update for busybox; hasn't been updated for a while, and is behind many versions. Working on it, I found that the previous maintainer apparently included a custom build config with some substantial modifications. I'm planning on reverting the configs to be as close as possible to the default shipped by busybox, with few minor modifications, like buildings statically, and without symlinks that replace normal path utilities. I may later include an option to build dynamically, or a mechanism to load a custom .config file before building, but I'm afraid it would result in a huge number of edge cases during the installation process. Any thoughts on the following points: 1. Is reverting to the default configs dangerous? It may break people's workflows, but the busybox package update already includes a large number of upstream changes anyway. 2. Is building statically by default and providing an option to build dynamically a reasonable approach? The default builds dynamically, but current SlackBuild builds statically. 3. Should the SlackBuild allow loading custom build configs? Or should we assume that if a user wants to build their own custom version they will know what to do? Currently we ship a build config file, and even if we want to stay closer to default we most likely will still need to ship the build config file, as generating it from upstream package is an interactive menu process. ...would be appreciated :) Thank you all, I wish you a great day, Lumin Etherlight From duncan_roe at optusnet.com.au Mon Sep 16 02:42:36 2024 From: duncan_roe at optusnet.com.au (Duncan Roe) Date: Mon, 16 Sep 2024 12:42:36 +1000 Subject: [Slackbuilds-users] RFC: Proposed mandb additions to doinst/douninst template In-Reply-To: References: <219c2ae-f997-80e3-4cae-3aa9b84fb9@slackware.uk> Message-ID: On Wed, Sep 11, 2024 at 08:31:55AM +0200, Nick Smallbone wrote: > On Wed, 11 Sep 2024, at 8:15 AM, B. Watson wrote: > > Someone on IRC pointed out that rewriting it to use awk would be less > > ugly. I tend to reach for sed first due to familiarity, but I think in > > this case you and him are right. > > > > Something like this, maybe? > > > > find usr/man -type f -a -name '*.gz' | \ > > awk '{ print "chroot . /usr/bin/mandb -f \"/"$1"\" &>/dev/null" }' \ > > >> install/doinst.sh > > > > It would be less ugly if we could assume man pages never have spaces > > or shell metacharacters in them... I don't think the man command can > > handle spaces in the man page filenames, and it would be bizarre to > > have $ or * or such in the filename... But better to leave the quotes > > there I suppose. > > I just learned that find has a -printf flag which can be used to format the output, avoiding the need for sed/awk altogether: > > find usr/man -type f -a -name '*.gz' \ > -printf "chroot . /usr/bin/mandb -f '/%p' &> /dev/null\n" \ > >> install/doinst.sh > > There's also a %P format specifier which prints the filename relative to the search root (e.g. man1/whatever.1.gz), hence the following variant which even works if run before the 'cd $PKG' command (but it still needs to come after 'mkdir $PKG/install' so perhaps not a useful improvement): > > find $PKG/usr/man -type f -a -name '*.gz' \ > -printf "chroot . /usr/bin/mandb -f /usr/man/%P &> /dev/null\n" \ > >> $PKG/install/doinst.sh > > Nick I just thought of a simpler way. Append [ ! -d usr/man ] || find usr/man -type f -a -name '*.gz' | xargs -r touch to install/doinst.sh. The man pages are now modified at install time so the daily mandb will process them. Or am I missing something? Cheers ... Duncan. From jebrhansen+SBo at gmail.com Mon Sep 16 05:15:01 2024 From: jebrhansen+SBo at gmail.com (Jeremy Hansen) Date: Sun, 15 Sep 2024 22:15:01 -0700 Subject: [Slackbuilds-users] Reverting system/busybox to Default Build Configurations In-Reply-To: <20240916011643.cD7ib%lumin+slackbuilds@etherlight.link> References: <20240916011643.cD7ib%lumin+slackbuilds@etherlight.link> Message-ID: On Sun, Sep 15, 2024, 6:16?PM Lumin Etherlight via SlackBuilds-users < slackbuilds-users at slackbuilds.org> wrote: > > Hello, fellow slackbuilders, > > I'm working on an update for busybox; hasn't been updated for > a while, and is behind many versions. Working on it, I found that > the previous maintainer apparently included a custom build config > with some substantial modifications. I'm planning on reverting the > configs to be as close as possible to the default shipped by busybox, > with few minor modifications, like buildings statically, and without > symlinks that replace normal path utilities. I may later include an > option to build dynamically, or a mechanism to load a custom .config > file before building, but I'm afraid it would result in a huge number > of edge cases during the installation process. > > Any thoughts on the following points: > > 1. Is reverting to the default configs dangerous? It may break > people's workflows, but the busybox package update already > includes a large number of upstream changes anyway. > There's always a chance a change or updated version will break somebody's workflow (https://xkcd.com/1172/). This is the reason Pat rarely upgrades packages on a stable release if there isn't a vulnerability or serious bug that needs to be addressed However, SBo, as a whole, is not under that restraint. As the package maintainer, you're free to update as little or frequently as you like. I generally try to keep my packages up-to-date, but others choose to update only when problems are found. Both are correct options. 2. Is building statically by default and providing an option to > build dynamically a reasonable approach? The default builds > dynamically, but current SlackBuild builds statically. Based on SBo's templates, they prefer building packages with shared (dynamic) libraries. However, those templates are templates, so maintainers are free to use our disregard them. That being said, unless you have a good reason to disregard the templates, it's generally best practice to use them (which would mean shared by default). Personally, unless you know why the previous maintainer chose static, if might be worth making the default shared, and, if you desire (since you're the maintainer), you can make an option to make a static version. 3. Should the SlackBuild allow loading custom build configs? > Or should we assume that if a user wants to build their own > custom version they will know what to do? Currently we ship a > build config file, and even if we want to stay closer to default > we most likely will still need to ship the build config file, > as generating it from upstream package is an interactive menu > process. Like my previous responses alluded to, you're the maintainer and as the maintainer, you get to make these decisions. It's generally a good idea to plan for the masses and possibly make exceptions for the few. Personally, I like making my SlackBuilds configurable, so I will add autodetect for optional dependencies and offer flags/variables users can pass to change the defaults. But that does add extra complexity that I'm willing to deal with, and this is with the very real possibility that users may not even choose to use my various options I've added. Ultimately, you're now the maintainer, which means you make the decisions that everyone else on SBo would need to deal with when using your script. Sometimes it's better to decide for the user (maybe a program has an optional dependency, but most users would expect the functionality that dependency offers, so maybe it's best to include it on the REQUIRES line in the .info) and sometimes it's good to give them a choice. I feel like my Kodi SlackBuild does a decent job of flags, autodetect, expected defaults. Just don't forget to document optional things in the README. Jeremy -------------- next part -------------- An HTML attachment was scrubbed... URL: From urchlay at slackware.uk Mon Sep 16 08:00:26 2024 From: urchlay at slackware.uk (B. Watson) Date: Mon, 16 Sep 2024 04:00:26 -0400 (EDT) Subject: [Slackbuilds-users] RFC: Proposed mandb additions to doinst/douninst template In-Reply-To: References: <219c2ae-f997-80e3-4cae-3aa9b84fb9@slackware.uk> Message-ID: On Mon, 16 Sep 2024, Duncan Roe wrote: > I just thought of a simpler way. Append > > [ ! -d usr/man ] || find usr/man -type f -a -name '*.gz' | xargs -r touch > > to install/doinst.sh. The man pages are now modified at install time so the > daily mandb will process them. It's the timestamps of the man directories that mandb checks. But yes, this could work. I'd invert the tests (I read your code as a double negative), avoid xargs, and write something like: [ -d usr/man ] && find usr/man -type d -exec touch {} + The + will make it execute touch once, with all the filenames as arguments. Since it doesn't use the shell, no escaping has to be done... find's -exec correctly handles filenames with spaces or even embedded newlines (just checked that part). Yes, I like this a lot better than my original idea. Simpler and faster. Provided it works (and I don't see why it wouldn't; I just haven't tested it in actual doinst.sh yet). The disadvantage is that the man pages don't get added to the db until the nightly cronjob runs, but that's totally fine (as long as they *eventually* get added, I don't insist it has to be right away). > Or am I missing something? I don't think so. My hat's off to you (or, would be, were I wearing one). I'll do some real-world testing now, get back to you tomorrow probably. From urchlay at slackware.uk Mon Sep 16 08:13:33 2024 From: urchlay at slackware.uk (B. Watson) Date: Mon, 16 Sep 2024 04:13:33 -0400 (EDT) Subject: [Slackbuilds-users] Reverting system/busybox to Default Build Configurations In-Reply-To: References: <20240916011643.cD7ib%lumin+slackbuilds@etherlight.link> Message-ID: On Sun, 15 Sep 2024, Jeremy Hansen wrote: > Personally, unless you know why the previous maintainer chose static, if might be worth making the default shared, and, if you desire (since you're the maintainer), you can make an > option to make a static version. I'm not the previous maintainer but I'm pretty familiar with busybox... Most likely the use-case for static linking is, you can use your statically-linked busybox tools to fix broken dynamic linking (failed upgrade of glibc-solibs, or an accidental "rm -f" of a core shared library). If someone already has busybox installed, statically linked, and it gets upgraded to a dynamically linked busybox... and then later on needs it to fix .so breakage... that user will think "oh, good thing I have a static busybox to fix this with", and then will be surprised and mightily irritated that busybox is suddenly broken, too. My vote would be, leave it static, and maybe add an option to make it dynamic. Templates aren't there to be blindly adhered to 100% of the time, they exist to give you a starting point. From urchlay at slackware.uk Mon Sep 16 08:23:59 2024 From: urchlay at slackware.uk (B. Watson) Date: Mon, 16 Sep 2024 04:23:59 -0400 (EDT) Subject: [Slackbuilds-users] RFC: Proposed mandb additions to doinst/douninst template In-Reply-To: References: <219c2ae-f997-80e3-4cae-3aa9b84fb9@slackware.uk> Message-ID: <9bd5a822-7269-d79c-a2d5-359babab839d@slackware.uk> On Mon, 16 Sep 2024, Duncan Roe wrote: > [ ! -d usr/man ] || find usr/man -type f -a -name '*.gz' | xargs -r touch > > to install/doinst.sh. The man pages are now modified at install time so the > daily mandb will process them. > > Or am I missing something? I meant to mention in the previous message... Touching every *.gz file under /usr/man would be a bad idea, because there's over 10,000 of them on a full Slackware install. Might take a while to run, if nothing else. But, not needed. Touching just the directories will be quick and is actually what's required. From duncan_roe at optusnet.com.au Mon Sep 16 10:21:25 2024 From: duncan_roe at optusnet.com.au (Duncan Roe) Date: Mon, 16 Sep 2024 20:21:25 +1000 Subject: [Slackbuilds-users] RFC: Proposed mandb additions to doinst/douninst template In-Reply-To: <9bd5a822-7269-d79c-a2d5-359babab839d@slackware.uk> References: <219c2ae-f997-80e3-4cae-3aa9b84fb9@slackware.uk> <9bd5a822-7269-d79c-a2d5-359babab839d@slackware.uk> Message-ID: On Mon, Sep 16, 2024 at 04:23:59AM -0400, B. Watson wrote: > > > On Mon, 16 Sep 2024, Duncan Roe wrote: > > > [ ! -d usr/man ] || find usr/man -type f -a -name '*.gz' | xargs -r touch > > > > to install/doinst.sh. The man pages are now modified at install time so the > > daily mandb will process them. > > > > Or am I missing something? > > I meant to mention in the previous message... > > Touching every *.gz file under /usr/man would be a bad idea, because there's > over 10,000 of them on a full Slackware install. Might take a while to run, > if nothing else. > > But, not needed. Touching just the directories will be quick and is > actually what's required. D'oh! I only meant to touch *newly installed* files. Would need to run find at build time and append touch commands to doinst.sh. >From strace of mandb I can see it is reading directory entries. Are you sure it isn't checking file modification times? I would have thought it had to. Cheers ... Duncan. From urchlay at slackware.uk Mon Sep 16 10:56:07 2024 From: urchlay at slackware.uk (B. Watson) Date: Mon, 16 Sep 2024 06:56:07 -0400 (EDT) Subject: [Slackbuilds-users] RFC: Proposed mandb additions to doinst/douninst template In-Reply-To: References: <219c2ae-f997-80e3-4cae-3aa9b84fb9@slackware.uk> <9bd5a822-7269-d79c-a2d5-359babab839d@slackware.uk> Message-ID: On Mon, 16 Sep 2024, Duncan Roe wrote: > D'oh! I only meant to touch *newly installed* files. Would need to run find at > build time and append touch commands to doinst.sh. Yeah. That wouldn't really be any simpler or better than the previous idea (generated doinst.sh with 1 "mandb -f" command per man page). > From strace of mandb I can see it is reading directory entries. Are you sure it > isn't checking file modification times? I would have thought it had to. The trouble is... it skips the entire directory if the timestamp on the dir is older than the database for that dir. Touching just the directories forces it to at least look in all the dirs. If it finds a man page that's not indexed, it'll add it (regardless of timestamp on the man page, it looks like). I guess you still might run into a situation where you had a package installed, upgraded it, and it has the same man page files, but the files have different descriptions in the new version. I think in that case, "mandb -k" would still show the old version's description. This, I think we can live with for now. It looks like when Slackware 15.1 comes, its new man-db version is going to generate the databases much faster (a while back, someone reported "mandb -c" only taking 10 seconds, where it took 10 minutes on my 15.0 box). So maybe we should be trying to talk PV into changing /etc/cron.daily/man-db, add a "-c" to the mandb command it runs. That'd make mandb rebuild the whole cache from scratch, and we wouldn't have to worry about doinst.sh at all. Pat doesn't seem to answer emails any more (or anyway, not the last few I sent him), maybe someone who uses LQ could try to contact him there? (I don't use it, not a big fan of web forums) From willysr at slackbuilds.org Mon Sep 16 13:08:17 2024 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Mon, 16 Sep 2024 20:08:17 +0700 Subject: [Slackbuilds-users] KiCAD and webkit2gtk In-Reply-To: <2aca923e-78c9-4f8a-acf5-a0eac1cc3d5c@maschinengott.de> References: <2aca923e-78c9-4f8a-acf5-a0eac1cc3d5c@maschinengott.de> Message-ID: > I was just going through SBo packages that needed upgrading (I don't > keep on top of it regularly) with `sbopkg -c` and generated a queue for > kicad. This queue contains webkit2gtk4.1 (as a dependency of wxPython4) > and webkit2gtk (as a dependency of wxWidgets). These two have notes that > they can't be installed at the same time: > > > This package builds the 4.0 WebKit API. If you need 4.1 WebKit API, > use webkit2gtk4.1. Don't install both at the same time!! > > Aside from the ridiculousness of having to do the same several hour > build twice for the same software? > > What's going on there I added webkit2gtk as hard dependency of wxWidget since i need it to build poedit. You can skip installing webkit2gtk and change DwxUSE_WEBVIEW_WEBKIT=ON into DwxUSE_WEBVIEW_WEBKIT=OFF and that should work, but you won't get webkit engine in wxWidgets I don't know if this will impact kicad or not, but my guess is that kicad will build just fine without this feature. -- 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 alisonken1 at juno.com Mon Sep 16 13:58:05 2024 From: alisonken1 at juno.com (Ken Roberts) Date: Mon, 16 Sep 2024 06:58:05 -0700 Subject: [Slackbuilds-users] Reverting system/busybox to Default Build Configurations In-Reply-To: References: <20240916011643.cD7ib%lumin+slackbuilds@etherlight.link> Message-ID: Isn't busybox used in the initrd? If it is, then it would need to be static anyway since .so files are not added to the initrd. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lumin at etherlight.link Mon Sep 16 14:13:06 2024 From: lumin at etherlight.link (lumin at etherlight.link) Date: Mon, 16 Sep 2024 14:13:06 +0000 Subject: [Slackbuilds-users] Reverting system/busybox to Default Build Configurations In-Reply-To: References: <20240916011643.cD7ib%lumin+slackbuilds@etherlight.link> Message-ID: <20240916141306.ABDFB220495@wave.etherlight.link> Ken Roberts wrote: > Isn't busybox used in the initrd? > If it is, then it would need to be static anyway > since .so files are not added to the initrd. The Slackware initrd uses its own build of busybox bundled within the mkinitrd package, in /usr/share/mkinitrd/initrd-tree.tar.gz. What we are discussing here is the SlackBuild offering, which is unrelated. So far, most use-cases for busybox on a complete OS like Slackware seem to benefit from static linking more than dynamic; recovery, custom from-scratch initrd bundles, minimalist chroots. I will keep static linking for now, seems the more useful option. Best regards, Lumin Etherlight From zhu.qunying at gmail.com Mon Sep 16 17:40:22 2024 From: zhu.qunying at gmail.com (Qun-Ying) Date: Mon, 16 Sep 2024 10:40:22 -0700 Subject: [Slackbuilds-users] KiCAD and webkit2gtk In-Reply-To: <2aca923e-78c9-4f8a-acf5-a0eac1cc3d5c@maschinengott.de> References: <2aca923e-78c9-4f8a-acf5-a0eac1cc3d5c@maschinengott.de> Message-ID: Actually, I built wxWidgets with webkit2gtk4.1 API without problem. For a few of the programs I compiled that use wxWidgets/webkit2gtk, it seems all working fine. (Yelp, poedit, gnucash (I updated to 5.6, did not really test the version in SBo), kicad) On Sun, Sep 15, 2024 at 8:10?AM J wrote: > Hi. > I was just going through SBo packages that needed upgrading (I don't > keep on top of it regularly) with `sbopkg -c` and generated a queue for > kicad. This queue contains webkit2gtk4.1 (as a dependency of wxPython4) > and webkit2gtk (as a dependency of wxWidgets). These two have notes that > they can't be installed at the same time: > > > This package builds the 4.0 WebKit API. If you need 4.1 WebKit API, > use webkit2gtk4.1. Don't install both at the same time!! > > Aside from the ridiculousness of having to do the same several hour > build twice for the same software? > > What's going on there? > > Ciao, Jay > _______________________________________________ > 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/ > > -- Qun-Ying -------------- next part -------------- An HTML attachment was scrubbed... URL: From dev at iotib.net Mon Sep 16 20:57:27 2024 From: dev at iotib.net (Charadon) Date: Mon, 16 Sep 2024 16:57:27 -0400 Subject: [Slackbuilds-users] Taking over maintainership of perl-Variable-Magic Message-ID: I attempted to contact jfch at jagda.eu to update it, but the e-mail bounced, so it's safe to say all his packages are orphaned. My reasoning for wanting it updated is because perl-Variable-Magic fails to build on -current, and I need it to build perl-Moose. While i'm at it, may as well take the whole dependency chain, so if it's acceptable I can take: perl-Test-CleanNamespaces perl-namespace-clean perl-B-Hooks-EndOfScope perl-Moose From urchlay at slackware.uk Mon Sep 16 22:36:15 2024 From: urchlay at slackware.uk (B. Watson) Date: Mon, 16 Sep 2024 18:36:15 -0400 (EDT) Subject: [Slackbuilds-users] Taking over maintainership of perl-Variable-Magic In-Reply-To: References: Message-ID: <79f448ba-425a-9882-535-28b468cf87@slackware.uk> On Mon, 16 Sep 2024, Charadon via SlackBuilds-users wrote: > I attempted to contact jfch at jagda.eu to update it, but the e-mail bounced, so > it's safe to say all his packages are orphaned. > > My reasoning for wanting it updated is because perl-Variable-Magic fails to > build on -current, and I need it to build perl-Moose. > > While i'm at it, may as well take the whole dependency chain, so if it's > acceptable I can take: > > perl-Test-CleanNamespaces > perl-namespace-clean > perl-B-Hooks-EndOfScope > perl-Moose Sounds good to me. Go ahead and send updates, preferably before Friday. Thanks! From urchlay at slackware.uk Mon Sep 16 22:53:08 2024 From: urchlay at slackware.uk (B. Watson) Date: Mon, 16 Sep 2024 18:53:08 -0400 (EDT) Subject: [Slackbuilds-users] Taking over maintainership of perl-Variable-Magic In-Reply-To: References: Message-ID: On Mon, 16 Sep 2024, Charadon via SlackBuilds-users wrote: > I attempted to contact jfch at jagda.eu to update it, but the e-mail bounced, so > it's safe to say all his packages are orphaned. Jan F. Chadima's last activity on SBo was October 2020, so yes, I'd say the builds are orphaned. I'd suggest Mario Preksavec or Michael Edie take over libqb, since they both have builds that depend on it. The perl modules should also be taken over by maintainers who have builds that depend on them (though I haven't gone through the list to see who). Here's the full list, for whoever's interested: libraries/libqb misc/tidyp network/squirrelmail perl/perl-B-COW perl/perl-B-Hooks-EndOfScope perl/perl-B-Hooks-OP-Check perl/perl-B-Hooks-OP-PPAddr perl/perl-Class-Load-XS perl/perl-Clone-PP perl/perl-Clone perl/perl-Data-Dumper-Concise perl/perl-Data-IEEE754 perl/perl-Data-Printer perl/perl-Data-Validate-IP perl/perl-Devel-Declare perl/perl-Devel-OverloadInfo perl/perl-Devel-PartialDump perl/perl-File-Grep perl/perl-File-Type perl/perl-HTML-HTMLDoc perl/perl-HTML-Tidy perl/perl-Hook-LexWrap perl/perl-List-AllUtils perl/perl-List-SomeUtils perl/perl-List-UtilsBy perl/perl-MRO-Compat perl/perl-Math-GSL-Linalg-SVD perl/perl-Math-Int128 perl/perl-Math-Int64 perl/perl-MaxMind-DB-Common perl/perl-MaxMind-DB-Reader-XS perl/perl-MaxMind-DB-Reader perl/perl-Module-Runtime-Conflicts perl/perl-MooX-StrictConstructor perl/perl-Moose perl/perl-MooseX-Traits perl/perl-MooseX-Types-Structured perl/perl-MooseX-Types perl/perl-Mutex perl/perl-Net-Works perl/perl-Number-Convert-Roman perl/perl-PPI perl/perl-Parse-Method-Signatures perl/perl-Scalar-List-Utils perl/perl-Scope-Upper perl/perl-String-Random perl/perl-String-Scanf perl/perl-Sub-Exporter-ForMethods perl/perl-Sub-Identify perl/perl-Test-Bits perl/perl-Test-Class perl/perl-Test-CleanNamespaces perl/perl-Test-HexDifferences perl/perl-Test-Object perl/perl-Test-SubCalls perl/perl-TryCatch perl/perl-Variable-Magic perl/perl-aliased perl/perl-namespace-autoclean perl/perl-namespace-clean system/busybox system/grub_legacy system/klish system/newLd system/vmfs-tools system/xldconfig From willysr at slackbuilds.org Mon Sep 16 23:27:21 2024 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Tue, 17 Sep 2024 06:27:21 +0700 Subject: [Slackbuilds-users] Taking over maintainership of perl-Variable-Magic In-Reply-To: References: Message-ID: > I attempted to contact jfch at jagda.eu to update it, but the e-mail > bounced, so it's safe to say all his packages are orphaned. > > My reasoning for wanting it updated is because perl-Variable-Magic fails > to build on -current, and I need it to build perl-Moose. > > While i'm at it, may as well take the whole dependency chain, so if it's > acceptable I can take: > > perl-Test-CleanNamespaces > perl-namespace-clean > perl-B-Hooks-EndOfScope > perl-Moose go for 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 dev at iotib.net Mon Sep 16 23:45:53 2024 From: dev at iotib.net (Charadon) Date: Mon, 16 Sep 2024 19:45:53 -0400 Subject: [Slackbuilds-users] Maybe Taking Over Some Packages In-Reply-To: <4e1a8b8a-1661-52be-ff9b-e87968ab5dde@slackware.uk> References: <20240914194453.96D15220485@wave.etherlight.link> <4e1a8b8a-1661-52be-ff9b-e87968ab5dde@slackware.uk> Message-ID: Do you have a link to that sbosubmit tool? That sounds very handy! -----Original Message----- From: B. Watson [mailto:urchlay at slackware.uk] Sent: Sunday, September 15, 2024 03:55 PM -04 To: lumin--- via SlackBuilds-users Cc: lumin at etherlight.link Subject: Re: [Slackbuilds-users] Maybe Taking Over Some Packages On Sat, 14 Sep 2024, lumin--- via SlackBuilds-users wrote: system/busybox Maintainer mail server timing out, package behind many versions. Jan F. Chadima hasn't been active since 2020. Go ahead and take this one over. Looks like Chadima has a lot more builds that need maintainers. Anyone reading this is welcome to grab them. List here: https://slackbuilds.org/advsearch.php?stype=maint&q=jfch%40jagda.eu graphics/feh Maintainer was contacted, they said they haven't been active on SBo for a while, and that someone should take feh over. graphics/optipng There was discussion about it being vulnerable and unmaintained, seems urchlay updated it, but I can help with this one if he wants. I took both of these, rather than see them go unmaintained. But, if you're interested, you're welcome to them. I have 900 builds already, I won't miss these :) One request: please base your versions on my updated versions. A few questions on the responsibility of a maintainer: 1. Is there any comprehensive guide on that? A link to said guide would be appreciated. I'm working on writing such a guide, but it's not finished yet. The short version: when you maintain a script, you're responsible for responding to emails from users, helping them with any problems they may have. You're also responsible for keeping the script updated, when the software updates... though you don't have to "knee-jerk" upgrade as soon as a new release comes out. You want to do some actual testing, make sure the upgrade doesn't break anything. *Especially*, you have to make sure your upgrade doesn't break any other builds that depend on yours! Use the "advanced search" on the site to do a Dependee search, to find out what depends on your build. There are tools to help you keep your builds clean. Use sbolint and sbopkglint from sbo-maintainer-tools to check them. 2. What platforms should I test for? Is a clean chroot or VM of x64 stable enough for now? or should I test on x86, arm, -current combinations? Personally I currently only use stable x64 15.0. Please test on 15.0, on both x86 and x86_64, clean environment (chroot or VM). I recommend testing on both a clean environment *and* a "dirty" environment with lots of other SBo packages installed (to catch conflicts with other builds), but not everyone agrees with me that the dirty testing is worth the effort. We don't support -current, so don't worry about testing there unless you really really want to. There's an unofficial fork of the SBo repo, run by Matteo Bernardini aka ponce, where fixes for -current are gathered. We don't support 32-bit arm, and never will AFAIK. We have plans to support 64-bit arm (aarch64) sometime after Slackware 15.1 is released, but even then, maintainers won't really be expected to test everything on it. Not everyone owns the hardware, and emulation is painfully slow. All that'll be required is, if an aarch64 user sends you a patch to fix the build on aarch64, you'll apply the patch (unless it's broken of course). 3. feh and optipng are relatively simple to test, and I use them frequently, but with busybox there is a huge number of things to test; personally I only use a subset in some scripts. Any solutions for this problem? (e.g. a way for multiple test users to try it out before publishing it to SBo proper). You can put your modified script somewhere public and post on the mailing list about it, ask for people to help you test it. 4. If my request to take over the packages is granted, do I wait until next upstream update? Or do I push an update to change the maintainer immediately? Go ahead and send an update to change the maintainer info immediately. You could also make other changes at the same time (version update, or fix a bug). 5. If I don't want to use GitHub or GitLab, what other options do I have? Can I send git patch emails somewhere? Or is the web submission form the only alternative? I'm not in charge of the github/gitlab stuff (I don't even have accounts on either service), but so far as I know, the choices are github, gitlab, or the web submission form. I don't think we ever pull from any other git repos. If I'm wrong, someone (Willy) will probably correct me. There are a couple of tools that automate the process of using the web submission form, which would be better than doing it manuall with a browser. One is called "sbosubmit". Thank you all for your work on SlackBuilds. Thank you for your interest. Hope this answers some of your questions in a useful way. The Maintainer FAQ is still a work in progress, and your email has motivated me to start working on it again. _______________________________________________ SlackBuilds-users mailing list SlackBuilds-users at slackbuilds.org https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - https://slackbuilds.org/faq/ From urchlay at slackware.uk Tue Sep 17 02:06:13 2024 From: urchlay at slackware.uk (B. Watson) Date: Mon, 16 Sep 2024 22:06:13 -0400 (EDT) Subject: [Slackbuilds-users] Maybe Taking Over Some Packages In-Reply-To: References: <20240914194453.96D15220485@wave.etherlight.link> <4e1a8b8a-1661-52be-ff9b-e87968ab5dde@slackware.uk> Message-ID: <113f2e1c-15e0-169-cdd5-2534888a557e@slackware.uk> On Mon, 16 Sep 2024, Charadon via SlackBuilds-users wrote: > Do you have a link to that sbosubmit tool? That sounds very handy! This looks like it: https://github.com/atelszewski/sbosubmit I've never actually *used* sbosubmit, I only know about this because I had written my own sbosubmit tool (never published or packaged though) and had to rename mine when this one was released. From andrzej at telszewski.com Tue Sep 17 07:17:30 2024 From: andrzej at telszewski.com (Andrzej Telszewski) Date: Tue, 17 Sep 2024 09:17:30 +0200 Subject: [Slackbuilds-users] Maybe Taking Over Some Packages In-Reply-To: <113f2e1c-15e0-169-cdd5-2534888a557e@slackware.uk> References: <20240914194453.96D15220485@wave.etherlight.link> <4e1a8b8a-1661-52be-ff9b-e87968ab5dde@slackware.uk> <113f2e1c-15e0-169-cdd5-2534888a557e@slackware.uk> Message-ID: On 17/09/2024 04:06, B. Watson wrote: > > > On Mon, 16 Sep 2024, Charadon via SlackBuilds-users wrote: > >> Do you have a link to that sbosubmit tool? That sounds very handy! > > This looks like it: > > https://github.com/atelszewski/sbosubmit > > I've never actually *used* sbosubmit, I only know about this because I > had written my own sbosubmit tool (never published or packaged though) > and had to rename mine when this one was released. Maybe it's time for me to make it available on SBo. ;-) ("Me" is the author of the tool. ;-)) From slack at giand.it Tue Sep 17 15:38:50 2024 From: slack at giand.it (=?UTF-8?Q?Giancarlo_Dess=C3=AC?=) Date: Tue, 17 Sep 2024 17:38:50 +0200 Subject: [Slackbuilds-users] Sbopkglint failure due wrong permission of a file installed by update-mime-database Message-ID: <0c4606e6-4103-49c8-b265-37d8bcda11e2@giand.it> Hi trying to solve an issue reported by Willy for birdfont package, sbopkglint returns this message: Running test: 05-basic-sanity... ---usr/share/mime should not contain files with executable permission: -rwxr-xr-x 1 root root 362 set 17 17:02 usr/share/mime/application/birdfont.xml FAILED I wasn't able to solve this: this file is not included in the package, but it is generated by update-mime-database in doint.sh It is possible to remove the executable permission with chmod 644 in doinst.sh but the failure report in sbopkglint remains. I see also that all xml files installed in /usr/share/mime/application have executable permissions. Why sbopkglint returns this as error!? -- ********************************************************* Giancarlo Dess? https://www.giand.it https://github.com/giandex Slackware Linux... because it works! ********************************************************* -------------- next part -------------- An HTML attachment was scrubbed... URL: From urchlay at slackware.uk Tue Sep 17 16:15:12 2024 From: urchlay at slackware.uk (B. Watson) Date: Tue, 17 Sep 2024 12:15:12 -0400 (EDT) Subject: [Slackbuilds-users] Sbopkglint failure due wrong permission of a file installed by update-mime-database In-Reply-To: <0c4606e6-4103-49c8-b265-37d8bcda11e2@giand.it> References: <0c4606e6-4103-49c8-b265-37d8bcda11e2@giand.it> Message-ID: <672b833c-51b7-c5db-c43-251b393318cf@slackware.uk> On Tue, 17 Sep 2024, Giancarlo Dess? wrote: > > Hi > > trying to solve an issue reported by Willy for birdfont package, sbopkglint returns this message: > > Running test: 05-basic-sanity... > --- usr/share/mime should not contain files with executable permission: > -rwxr-xr-x 1 root root 362 set 17 17:02 usr/share/mime/application/birdfont.xml > FAILED > > I wasn't able to solve this: this file is not included in the package, but it is generated by update-mime-database in doint.sh It is possible to remove the executable permission > with chmod 644 in doinst.sh but the failure report in sbopkglint remains. > > I see also that all xml files installed in /usr/share/mime/application have executable permissions. Why sbopkglint returns this as error!? Something wrong with your system. Somehow update-mime-database is generating the file with +x permission. If *all* of them are +x, that includes the ones from core Slackware (not SBo). /usr/share/mime/application contains 2664 .xml files on my test system (hundreds of SBo packages installed), and none of them are executable. sbopkglint reports it as an error because it *is* an error... not sure why your update-mime-database is creating +x files, but it shouldn't be. From slack at giand.it Tue Sep 17 16:27:55 2024 From: slack at giand.it (=?UTF-8?Q?Giancarlo_Dess=C3=AC?=) Date: Tue, 17 Sep 2024 18:27:55 +0200 Subject: [Slackbuilds-users] Sbopkglint failure due wrong permission of a file installed by update-mime-database In-Reply-To: <672b833c-51b7-c5db-c43-251b393318cf@slackware.uk> References: <0c4606e6-4103-49c8-b265-37d8bcda11e2@giand.it> <672b833c-51b7-c5db-c43-251b393318cf@slackware.uk> Message-ID: <77301e92-b650-45c3-a9fd-642771ba1a21@giand.it> Il 17/09/24 18:15, B. Watson ha scritto: > > > On Tue, 17 Sep 2024, Giancarlo Dess? wrote: > >> >> Hi >> >> trying to solve an issue reported by Willy for birdfont package, >> sbopkglint returns this message: >> >> Running test: 05-basic-sanity... >> --- usr/share/mime should not contain files with executable permission: >> -rwxr-xr-x 1 root root 362 set 17 17:02 >> usr/share/mime/application/birdfont.xml >> FAILED >> >> I wasn't able to solve this: this file is not included in the >> package, but it is generated by update-mime-database in doint.sh It >> is possible to remove the executable permission >> with chmod 644 in doinst.sh but the failure report in sbopkglint >> remains. >> >> I see also that all xml files installed in >> /usr/share/mime/application have executable permissions. Why >> sbopkglint returns this as error!? > > Something wrong with your system. Somehow update-mime-database is > generating the file with +x permission. If *all* of them are +x, that > includes the ones from core Slackware (not SBo). > > /usr/share/mime/application contains 2664 .xml files on my test system > (hundreds of SBo packages installed), and none of them are executable. > > sbopkglint reports it as an error because it *is* an error... not sure > why your update-mime-database is creating +x files, but it shouldn't > be. Thanks Bob, so it is an issue in my system! It's curious: this happens in a Slackware -current. An installation of Slackware 15 stable in another machine does not present this problem: all xml files in /usr/share/mime/application have 644 permission. Since I never modified configuration about update-mime-database I think that this could depend on Slackware -current -- ********************************************************* Giancarlo Dess? https://www.giand.it https://github.com/giandex Slackware Linux... because it works! ********************************************************* From artourter at gmail.com Tue Sep 17 18:04:12 2024 From: artourter at gmail.com (Greg Tourte) Date: Tue, 17 Sep 2024 19:04:12 +0100 Subject: [Slackbuilds-users] Sbopkglint failure due wrong permission of a file installed by update-mime-database In-Reply-To: <77301e92-b650-45c3-a9fd-642771ba1a21@giand.it> References: <0c4606e6-4103-49c8-b265-37d8bcda11e2@giand.it> <672b833c-51b7-c5db-c43-251b393318cf@slackware.uk> <77301e92-b650-45c3-a9fd-642771ba1a21@giand.it> Message-ID: indeed it looks like on current, all files in /usr/share/mime/application are 755. The version of update-mime-database on -current is 2.4 as opposed to 2.1 on -stable, but I could not find any configuration files for it (I don't think there is any). It is definitely a change in behaviour in the program, but whether it is on purpose or not I don't know. I could not find any mention of it in the changelog upstream On Tue, 17 Sept 2024 at 17:28, Giancarlo Dess? wrote: > Il 17/09/24 18:15, B. Watson ha scritto: > > > > > > On Tue, 17 Sep 2024, Giancarlo Dess? wrote: > > > >> > >> Hi > >> > >> trying to solve an issue reported by Willy for birdfont package, > >> sbopkglint returns this message: > >> > >> Running test: 05-basic-sanity... > >> --- usr/share/mime should not contain files with executable permission: > >> -rwxr-xr-x 1 root root 362 set 17 17:02 > >> usr/share/mime/application/birdfont.xml > >> FAILED > >> > >> I wasn't able to solve this: this file is not included in the > >> package, but it is generated by update-mime-database in doint.sh It > >> is possible to remove the executable permission > >> with chmod 644 in doinst.sh but the failure report in sbopkglint > >> remains. > >> > >> I see also that all xml files installed in > >> /usr/share/mime/application have executable permissions. Why > >> sbopkglint returns this as error!? > > > > Something wrong with your system. Somehow update-mime-database is > > generating the file with +x permission. If *all* of them are +x, that > > includes the ones from core Slackware (not SBo). > > > > /usr/share/mime/application contains 2664 .xml files on my test system > > (hundreds of SBo packages installed), and none of them are executable. > > > > sbopkglint reports it as an error because it *is* an error... not sure > > why your update-mime-database is creating +x files, but it shouldn't > > be. > > Thanks Bob, so it is an issue in my system! > > It's curious: this happens in a Slackware -current. An installation of > Slackware 15 stable in another machine does not present this problem: > all xml files in /usr/share/mime/application have 644 permission. Since > I never modified configuration about update-mime-database I think that > this could depend on Slackware -current > > -- > ********************************************************* > Giancarlo Dess? > https://www.giand.it > https://github.com/giandex > > Slackware Linux... because it works! > ********************************************************* > > _______________________________________________ > 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 Sep 17 18:51:03 2024 From: urchlay at slackware.uk (B. Watson) Date: Tue, 17 Sep 2024 14:51:03 -0400 (EDT) Subject: [Slackbuilds-users] Sbopkglint failure due wrong permission of a file installed by update-mime-database In-Reply-To: References: <0c4606e6-4103-49c8-b265-37d8bcda11e2@giand.it> <672b833c-51b7-c5db-c43-251b393318cf@slackware.uk> <77301e92-b650-45c3-a9fd-642771ba1a21@giand.it> Message-ID: On Tue, 17 Sep 2024, Greg Tourte wrote: > indeed it looks like on current, all files in /usr/share/mime/application are 755. The version of update-mime-database on -current is 2.4 as opposed to 2.1 on -stable, but I could > not find any configuration files for it (I don't think there is any). It is definitely a change in behaviour in the program, but whether it is on purpose or not I don't know. I > could not find any mention of it in the changelog upstream Yeah, also confirmed with an IRC user running -current. sbopklint (and SBo, in general) was never intended for -current, we only support the latest stable. Someone should let PV know about this, maybe he will patch shared-mime-info to fix the permissions of the files it creates. From mario at slackware.hr Tue Sep 17 20:21:00 2024 From: mario at slackware.hr (Mario) Date: Tue, 17 Sep 2024 22:21:00 +0200 Subject: [Slackbuilds-users] oidentd In-Reply-To: References: <3e2eff12-b47e-4b55-151d-3519c3400aa0@gmail.com> <596142be-9cad-5899-4789-35596eec1ccb@slackware.uk> <04019ef7-5ade-444d-e2e5-fdb841e31086@gmail.com> <1b4a8a59-9d62-2126-9357-9ae15899d23b@slackware.uk> Message-ID: <75847682-0b58-408d-bd8c-fcf31e89c3bd@slackware.hr> On 9/14/24 9:44 AM, pyllyukko wrote: > Ehlo. > > I use it for IRC even though it is not required. I can take over the > maintainership if it's cool with Mario. > :-) -- Mario From didier at slint.fr Wed Sep 18 17:21:44 2024 From: didier at slint.fr (Didier Spaier) Date: Wed, 18 Sep 2024 19:21:44 +0200 Subject: [Slackbuilds-users] Follow-up of https://app.matera.eu/messages?topic_id=396674 Message-ID: <81c3d882-4f46-4ab7-99c7-7d3691d93f84@slint.fr> Hi, B. Watson wrote: > So maybe we should be trying to talk PV into changing > /etc/cron.daily/man-db, add a "-c" to the mandb command it > runs. That'd make mandb rebuild the whole cache from scratch, and we > wouldn't have to worry about doinst.sh at all. > Pat doesn't seem to answer emails any more (or anyway, not the last > few I sent him), maybe someone who uses LQ could try to contact him > there? (I don't use it, not a big fan of web forums) I could be this someone, however I do not see a mandb command in /etc/cron.daily/man-db and am not acquainted with man-db What changes should I request in this file (attached)? Cheers, Didier -------------- next part -------------- #!/bin/sh # man-db daily cronjob, part of the man-db package. # Unset $MANPATH so that mandb will get it from man_db.conf rather than # the environment: unset MANPATH # Make sure the man-db cache directory exists: mkdir -p /var/cache/man # Regenerate the index databases caches used by man-db. # These increase perfomance and provide features such as whatis and apropos. ionice -c3 nice -n 19 /usr/bin/mandb --quiet From urchlay at slackware.uk Wed Sep 18 20:49:25 2024 From: urchlay at slackware.uk (B. Watson) Date: Wed, 18 Sep 2024 16:49:25 -0400 (EDT) Subject: [Slackbuilds-users] Follow-up of https://app.matera.eu/messages?topic_id=396674 In-Reply-To: <81c3d882-4f46-4ab7-99c7-7d3691d93f84@slint.fr> References: <81c3d882-4f46-4ab7-99c7-7d3691d93f84@slint.fr> Message-ID: <7bb7effc-e912-cde9-d8be-71aea341b56f@slackware.uk> On Wed, 18 Sep 2024, Didier Spaier wrote: > I could be this someone, however I do not see a mandb command in > /etc/cron.daily/man-db and am not acquainted with man-db This is the mandb command: ionice -c3 nice -n 19 /usr/bin/mandb --quiet > What changes should I request in this file (attached)? ionice -c3 nice -n 19 /usr/bin/mandb -c --quiet In other words, add the -c to the command just before the --quiet. From urchlay at slackware.uk Wed Sep 18 20:56:22 2024 From: urchlay at slackware.uk (B. Watson) Date: Wed, 18 Sep 2024 16:56:22 -0400 (EDT) Subject: [Slackbuilds-users] Follow-up of https://app.matera.eu/messages?topic_id=396674 In-Reply-To: <81c3d882-4f46-4ab7-99c7-7d3691d93f84@slint.fr> References: <81c3d882-4f46-4ab7-99c7-7d3691d93f84@slint.fr> Message-ID: <69f79f94-8c0-e983-78d8-7f61eb4d4ac3@slackware.uk> On Wed, 18 Sep 2024, Didier Spaier wrote: > I could be this someone, however I do not see a mandb command in > /etc/cron.daily/man-db and am not acquainted with man-db > > What changes should I request in this file (attached)? Before you actually ask PV for that, someone's gotta verify that the "man pages never get indexed" issue even exists on -current. Possibly the new man-db in -current might not have the problem that the one in 15.0 has. From didier at slint.fr Wed Sep 18 21:28:20 2024 From: didier at slint.fr (Didier Spaier) Date: Wed, 18 Sep 2024 23:28:20 +0200 Subject: [Slackbuilds-users] Follow-up of https://app.matera.eu/messages?topic_id=396674 In-Reply-To: <69f79f94-8c0-e983-78d8-7f61eb4d4ac3@slackware.uk> References: <81c3d882-4f46-4ab7-99c7-7d3691d93f84@slint.fr> <69f79f94-8c0-e983-78d8-7f61eb4d4ac3@slackware.uk> Message-ID: <0a50ce8e-517c-4cc3-ae4b-a3c31422e114@slint.fr> Le 18/09/2024 ? 22:56, B. Watson a ?crit?: > > > On Wed, 18 Sep 2024, Didier Spaier wrote: > >> I could be this someone, however I do not see a mandb command in >> /etc/cron.daily/man-db and am not acquainted with man-db >> >> What changes should I request in this file (attached)? > > Before you actually ask PV for that, someone's gotta verify that the > "man pages never get indexed" issue even exists on -current. Possibly > the new man-db in -current might not have the problem that the one in > 15.0 has. Sorry, too late ;) https://www.linuxquestions.org/questions/slackware-14/please-add-the-option-c-to-the-mandb-command-in-man-db-cron-4175741783/ And sorry for the wrong link in the subject line. Fortunately, as we say here "le lecteur a r?tabli de lui-m?me". From didier at slint.fr Thu Sep 19 20:53:58 2024 From: didier at slint.fr (Didier Spaier) Date: Thu, 19 Sep 2024 22:53:58 +0200 Subject: [Slackbuilds-users] add the option -c to the mandb command in man-db.cron (follow-up) Message-ID: <4933c596-0c44-4839-abab-e40d08f0cf7c@slint.fr> Patrick Volkerding has done it for Slackware-current as shown on top of http://www.slackware.com/changelog/current.php?cpu=x86_64 but not for slackware 15.0 as requested :( Cheers, Didier From urchlay at slackware.uk Thu Sep 19 21:46:06 2024 From: urchlay at slackware.uk (B. Watson) Date: Thu, 19 Sep 2024 17:46:06 -0400 (EDT) Subject: [Slackbuilds-users] add the option -c to the mandb command in man-db.cron (follow-up) In-Reply-To: <4933c596-0c44-4839-abab-e40d08f0cf7c@slint.fr> References: <4933c596-0c44-4839-abab-e40d08f0cf7c@slint.fr> Message-ID: On Thu, 19 Sep 2024, Didier Spaier wrote: > Patrick Volkerding has done it for Slackware-current as shown on top of > http://www.slackware.com/changelog/current.php?cpu=x86_64 Nice! > but not for slackware 15.0 as requested :( Ugh, miscommunication. I didn't actually want 15.0 to get that change. The mandb -c command in 15.0 takes way too long to run (10 mins on my test box), whereas on -current it takes around 10 seconds. So it's actually good that he didn't change it in 15.0. Since the change is in -current now, mission accomplished. Many thanks! From willysr at slackbuilds.org Sat Sep 21 00:43:04 2024 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sat, 21 Sep 2024 07:43:04 +0700 Subject: [Slackbuilds-users] Updates - 20240921.1 Message-ID: <0e792bc6-0a4b-474c-aa89-6ee9670a58ba@slackbuilds.org> Sat Sep 21 00:34:21 UTC 2024 academic/cistrome-mdseqpos: Fix source URL. academic/gcompris-qt: Updated for version 4.2. academic/openboard: Switch to cmake academic/qucs-s: Updated for version 24.3.1. audio/ices-cc: Removed (Upstream removed source and no maintainer). audio/jamulus: Updated for version 3.10.0. desktop/SiriKali: Added (GUI front end). desktop/Tela-icon-theme: Updated for version 2024_09_04. desktop/mint-themes: Revert download source to Linux Mint's repository desktop/mint-y-icons: Revert download source to Linux Mint's repository, remove extraneous folder desktop/murrine-themes: Fix source. development/astyle: Updated for version 3.6.2. development/aws-cdk: Updated for version 2.159.0. development/github-cli: Updated for version 2.57.0 development/google-go-lang: Updated for version 1.22.7. development/mongodb-compass: Updated for version 1.44.4. development/poedit: Updated for version 3.5.1. development/protobuf3: Updated for version 28.1. development/protobuf3: Updated for version 28.2. development/robotframework: Updated for version 7.1. development/sbt: Updated for version 1.10.2 development/wxHexEditor: Update script. games/alienarena: Version bump to 7.71.6. games/chroma: Version bump to 1.20 games/ddnet: Updated for version 18.5.1 games/doomretro: Updated for version 5.5.1. games/jag: Version bump to 0.3.8 gis/eccodes: Updated for version 2.37.0. gis/proj-data: Updated for version 1.19. gis/proj: Updated for version 9.5.0. graphics/birdfont: Fix install location. graphics/feh: New maintainer. graphics/gpick: Added (color picker). graphics/optipng: New maintainer. libraries/libjxl: Updated for version 0.11.0. libraries/libmirage: Update for 3.2.9 libraries/libmodsecurity: Added (Mod Security). libraries/libtorrent: Updated for version 0.13.8, new maintainer. libraries/libuninameslist: Updated for version 20240910. libraries/webkit2gtk4.1: Patch for gobject-introspection >= 1.82.x libraries/webkit2gtk4.1: Updated for version 2.46.0. libraries/webkit2gtk: Patch for gobject-introspection >= 1.82.x. libraries/webkit2gtk: Remove unneeded patch. libraries/webkit2gtk: Updated for version 2.46.0. libraries/wxPython4: Updated for version 4.2.2. libraries/zziplib: Simplify doinst.sh for mandb. misc/open-simh: Updated for version 20240905_2437b13. misc/tarotplane: Added (Curses flashcard program). multimedia/x265: Updated for version 4.0. multimedia/youtube-music: Updated for version 3.5.3. network/kdrive: Updated for version 3.6.4.20240814. network/lagrange: Updated for version 1.17.6. network/liferea: Update script. network/modsecurity-apache: Updated for version 2.9.8 and CRS 4.6.0. network/rtorrent: Updated for version 0.9.8, new maintainer. network/signal-desktop: Updated for version 7.25.0. network/syncthingtray-bin: Added (Plasma integration for Syncthing). network/tor-browser: Updated for version 13.5.4. network/vimb: Removed (broken with webkit2gtk4.1 and no maintainer) network/vivaldi: Updated for version 6.9.3447.46. network/zoom-linux: Updated for version 6.2.0.1855 office/Logseq: Updated for version 0.10.9. office/gospel-pdf-viewer: Added (pdf viewer). office/gospel-pdf-viewer: remove double .info. office/smoffice2024: Updated for version 2024_1218. perl/perl-Mojolicious: Updated for version 9.38. perl/perl-Variable-Magic: Updated for version 0.64. python/python3-anyio: Update for 4.5.0 python/python3-filelock: Version bump to 3.16.1 python/python3-keyring: Update for 25.4.0 python/python3-keyring: Update for 25.4.1 python/python3-platformdirs: Version bump to 4.3.6 python/python3-prometheus_client: Update for 0.21.0 python/python3-pyproject-api: Version bump to 1.8.0 python/python3-qbittorrent-api: Version bump to 2024.9.66 python/python3-tox: Version bump to 4.20.0 python/python3-virtualenv: Version bump to 20.26.5 python/pytz: Removed (has split into python2-pytz and python3-pytz) ruby/rbenv: Updated for version 1.3.0. system/Iosevka-slab: Updated for version 31.6.1. system/Iosevka: Updated for version 31.6.1. system/bitrot: Update maintainer info. system/busybox: Updated for version 1.36.1. system/chipsec: Updated for version 1.13.1. system/epson-inkjet-printer-escpr2: Updated for version 1.2.18. system/fastfetch: Updated for version 2.25.0. system/fnt: Updated for version 1.7. system/hddtemp: New maintainer. system/incus: Fix permission. system/incus: Generate man pages system/locust: Updated for version 2.31.6. system/onefetch: Updated for version 2.22.0. system/raft: Remove empty directory system/restic: Updated for version 0.17.1 system/ripgrep: Updated for version 14.1.1. system/sdltrs: Fix README (SDL-1.2 doesn't support Wayland). system/signify: Updated for version 32. system/slpkg: Updated for version 5.1.2. system/tqemu: Added (QEMU frontend). system/vhba-module: Update for 20240917 +--------------------------+ -- 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 Sep 22 09:33:56 2024 From: kvngncrlsn at gmail.com (K. Eugene Carlson) Date: Sun, 22 Sep 2024 18:33:56 +0900 Subject: [Slackbuilds-users] rust16 status update Message-ID: Hello, all, rust16 has been stuck a couple of major versions behind -current for some time now due to reverse dependency FTBFS. To ensure that version updates for rust stuff can continue smoothly, a new script called rust-opt will be available at the next public update, which will install rust-1.81.0 to /opt/rust. rust16 will be removed when the remaining scripts requiring version 1.79.0 have had new upstream versions. I'm currently testing a PR that would move all compatible scripts to rust-opt (probably everything except for lean-elan and wezterm). The commits can be found at https://github.com/pghvlaans/slackbuilds/tree/rust-opt. If you would prefer to retain rust16 as a dependency for your script for the time being, please let me know within the next few days. Best regards, Gene Carlson kvngncrlsn at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From didier at slint.fr Sun Sep 22 12:06:47 2024 From: didier at slint.fr (Didier Spaier) Date: Sun, 22 Sep 2024 14:06:47 +0200 Subject: [Slackbuilds-users] Sbopkglint failure due wrong permission of a file installed by update-mime-database In-Reply-To: References: <0c4606e6-4103-49c8-b265-37d8bcda11e2@giand.it> <672b833c-51b7-c5db-c43-251b393318cf@slackware.uk> <77301e92-b650-45c3-a9fd-642771ba1a21@giand.it> Message-ID: Hi, Le 9/17/24 ? 20:51, B. Watson a ?crit?: > > On Tue, 17 Sep 2024, Greg Tourte wrote: > >> indeed it looks like on current, all files in /usr/share/mime/application are >> 755. The version of update-mime-database on -current is 2.4 as opposed to 2.1 >> on -stable, but I could >> not find any configuration files for it (I don't think there is any). It is >> definitely a change in behaviour in the program, but whether it is on purpose >> or not I don't know. I >> could not find any mention of it in the changelog upstream > > Yeah, also confirmed with an IRC user running -current. > > sbopklint (and SBo, in general) was never intended for -current, we > only support the latest stable. > > Someone should let PV know about this, maybe he will patch > shared-mime-info to fix the permissions of the files it creates. Before I convey the message on LQ I just checked in an up to date Slackware64-current, including the package shared-mime-info-2.4-x86_64-1 typing as root: /usr/bin/update-mime-database /usr/share/mime and after that found all files in /usr/share/mime/application being 0644. Am I the only one, or did I misunderstand something again? Cheers, Didier From urchlay at slackware.uk Mon Sep 23 06:17:58 2024 From: urchlay at slackware.uk (B. Watson) Date: Mon, 23 Sep 2024 02:17:58 -0400 (EDT) Subject: [Slackbuilds-users] Sbopkglint failure due wrong permission of a file installed by update-mime-database In-Reply-To: References: <0c4606e6-4103-49c8-b265-37d8bcda11e2@giand.it> <672b833c-51b7-c5db-c43-251b393318cf@slackware.uk> <77301e92-b650-45c3-a9fd-642771ba1a21@giand.it> Message-ID: On Sun, 22 Sep 2024, Didier Spaier wrote: > Before I convey the message on LQ I just checked in an up to date > Slackware64-current, including the package > shared-mime-info-2.4-x86_64-1 > typing as root: > /usr/bin/update-mime-database /usr/share/mime > and after that found all files in /usr/share/mime/application > being 0644. > > Am I the only one, or did I misunderstand something again? Interesting. The folks on IRC who end up with +x files in /usr/share/mime are also running shared-mime-info-2.4. Wonder why it's happening to them & not to you. From artourter at gmail.com Mon Sep 23 08:24:44 2024 From: artourter at gmail.com (Greg Tourte) Date: Mon, 23 Sep 2024 10:24:44 +0200 Subject: [Slackbuilds-users] Sbopkglint failure due wrong permission of a file installed by update-mime-database In-Reply-To: References: <0c4606e6-4103-49c8-b265-37d8bcda11e2@giand.it> <672b833c-51b7-c5db-c43-251b393318cf@slackware.uk> <77301e92-b650-45c3-a9fd-642771ba1a21@giand.it> Message-ID: Yeah this is weird. When i tested it, i even removed the x permission before running the command and it came back. I am travelling rn but i'll investigate further later. Cheers Greg On Mon, 23 Sept 2024, 08:18 B. Watson, wrote: > > > On Sun, 22 Sep 2024, Didier Spaier wrote: > > > Before I convey the message on LQ I just checked in an up to date > > Slackware64-current, including the package > > shared-mime-info-2.4-x86_64-1 > > typing as root: > > /usr/bin/update-mime-database /usr/share/mime > > and after that found all files in /usr/share/mime/application > > being 0644. > > > > Am I the only one, or did I misunderstand something again? > > Interesting. The folks on IRC who end up with +x files in > /usr/share/mime are also running shared-mime-info-2.4. Wonder why it's > happening to them & not to you. > _______________________________________________ > 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 roberto.puzzanghera at sagredo.eu Mon Sep 23 16:30:09 2024 From: roberto.puzzanghera at sagredo.eu (Roberto Puzzanghera) Date: Mon, 23 Sep 2024 18:30:09 +0200 Subject: [Slackbuilds-users] Taking over viking and gpsd pkgs In-Reply-To: <9f4dd1d8-e5cf-369d-3df4-d2f6c7821dfc@slackware.uk> References: <41ce216e-8d30-4eb7-bc35-bf37d07e80f5@sagredo.eu> <9f4dd1d8-e5cf-369d-3df4-d2f6c7821dfc@slackware.uk> Message-ID: Il 12/09/24 20:07, B. Watson ha scritto: > > > On Thu, 12 Sep 2024, Roberto Puzzanghera via SlackBuilds-users wrote: > >> I contacted the maintainer of viking and gpsd (viking's dep) on >> September 1, using two different email addresses, also I tried to >> contact him last year, but I've never got any responce. > > Did you already try to contact him via this mailing list? If not, wait > a few days, see if he responds here. > >> So, if any of you don't have direct contact with David Spencer I would >> take over these two packages. Is it safe at this point to consider those packages abandoned? Roberto From urchlay at slackware.uk Mon Sep 23 18:43:50 2024 From: urchlay at slackware.uk (B. Watson) Date: Mon, 23 Sep 2024 14:43:50 -0400 (EDT) Subject: [Slackbuilds-users] Taking over viking and gpsd pkgs In-Reply-To: References: <41ce216e-8d30-4eb7-bc35-bf37d07e80f5@sagredo.eu> <9f4dd1d8-e5cf-369d-3df4-d2f6c7821dfc@slackware.uk> Message-ID: On Mon, 23 Sep 2024, Roberto Puzzanghera via SlackBuilds-users wrote: > Is it safe at this point to consider those packages abandoned? Yes, you've been very patient. Go ahead and take over viking and gpsd as soon as you're ready. This means that all of David Spencer's builds are up for grabs. The list is here: https://slackbuilds.org/advsearch.php?stype=maint&q=baildon.research If anyone wants to take any of these over, go ahead and do so. I suppose I can take system/slim myself, since I actually use it on one box here. Unless someone else wants it? It hasn't been updated upstream in 11 years, so maintaining it shouldn't take up much time. From roberto.puzzanghera at sagredo.eu Mon Sep 23 19:50:41 2024 From: roberto.puzzanghera at sagredo.eu (Roberto Puzzanghera) Date: Mon, 23 Sep 2024 21:50:41 +0200 Subject: [Slackbuilds-users] Taking over viking and gpsd pkgs In-Reply-To: References: <41ce216e-8d30-4eb7-bc35-bf37d07e80f5@sagredo.eu> <9f4dd1d8-e5cf-369d-3df4-d2f6c7821dfc@slackware.uk> Message-ID: <53e6ff92-7485-44c8-8a32-1049e2bc6e7b@sagredo.eu> Il 23/09/24 20:43, B. Watson ha scritto: > This means that all of David Spencer's builds are up for grabs. The > list is here: > > https://slackbuilds.org/advsearch.php?stype=maint&q=baildon.research > > If anyone wants to take any of these over, go ahead and do so. I can take nextcloud-server as well Roberto From kvngncrlsn at gmail.com Mon Sep 23 22:18:42 2024 From: kvngncrlsn at gmail.com (K. Eugene Carlson) Date: Tue, 24 Sep 2024 07:18:42 +0900 Subject: [Slackbuilds-users] Taking over viking and gpsd pkgs In-Reply-To: <53e6ff92-7485-44c8-8a32-1049e2bc6e7b@sagredo.eu> References: <41ce216e-8d30-4eb7-bc35-bf37d07e80f5@sagredo.eu> <9f4dd1d8-e5cf-369d-3df4-d2f6c7821dfc@slackware.uk> <53e6ff92-7485-44c8-8a32-1049e2bc6e7b@sagredo.eu> Message-ID: I'll take darktable, flickurl and osm-gps-map. Gene -------------- next part -------------- An HTML attachment was scrubbed... URL: From didier at slint.fr Tue Sep 24 10:23:54 2024 From: didier at slint.fr (Didier Spaier) Date: Tue, 24 Sep 2024 12:23:54 +0200 Subject: [Slackbuilds-users] hardinfo2 Message-ID: Hello, most distributions are now shipping hardinfo2, that supersedes hardinfo. I suggest that someone (David, who maintains hardinfo?) provide a SlackBuild for it. I have written a SLKBUILD for it https://slackware.uk/slint/x86_64/slint-15.0/source/hardinfo2/SLKBUILD adapted from the PKGBUILD from Arch. The binary is /usr/bin/hardinfo2 so it does not really conflict with hardinfo, although it clearly supersedes it. sysbench is a highly recommended dependency, preferably at version 1.0.20 so a version bump from 1.0.19 wold be welcome. I address this email to Sergio too. This suggestion triggered by this post @ LQ: https://www.linuxquestions.org/questions/slackware-14/hardinfo2-available-to-slackware-4175741947/#post6528524 Cheers, Didier From urchlay at slackware.uk Tue Sep 24 18:45:50 2024 From: urchlay at slackware.uk (B. Watson) Date: Tue, 24 Sep 2024 14:45:50 -0400 (EDT) Subject: [Slackbuilds-users] Taking over viking and gpsd pkgs In-Reply-To: References: <41ce216e-8d30-4eb7-bc35-bf37d07e80f5@sagredo.eu> <9f4dd1d8-e5cf-369d-3df4-d2f6c7821dfc@slackware.uk> <53e6ff92-7485-44c8-8a32-1049e2bc6e7b@sagredo.eu> Message-ID: On Tue, 24 Sep 2024, K. Eugene Carlson wrote: > I'll take darktable, flickurl and osm-gps-map. Excellent. Go ahead & send updates with your name/email in the .info file, even if no other changes are needed. From urchlay at slackware.uk Wed Sep 25 00:45:25 2024 From: urchlay at slackware.uk (B. Watson) Date: Tue, 24 Sep 2024 20:45:25 -0400 (EDT) Subject: [Slackbuilds-users] hardinfo2 In-Reply-To: References: Message-ID: On Tue, 24 Sep 2024, Didier Spaier wrote: > most distributions are now shipping hardinfo2, that supersedes hardinfo. > > I suggest that someone (David, who maintains hardinfo?) provide a SlackBuild for > it. I went ahead and wrote/submitted a SlackBuild for hardinfo2. David Golus hasn't been active in 2+ years, no idea if he's still planning to maintain anything. From urchlay at slackware.uk Wed Sep 25 06:50:17 2024 From: urchlay at slackware.uk (B. Watson) Date: Wed, 25 Sep 2024 02:50:17 -0400 (EDT) Subject: [Slackbuilds-users] kitty-bin removal Message-ID: <99b53b94-14c-c2ae-712-56dede938e8@slackware.uk> Will anyone miss kitty-bin if it goes away? I'm removing it because it's a binary repack, and it requires newer libraries than Slackware 15.0 has (though it does ship with its own set of precompiled libs, if I wanted to deal with the resulting mess). Also because the regular kitty build is a much better choice, for someone who wants to run kitty. Eugen Wissner is doing a fine job of keeping it up to date. Plus, after having tried it, I've decided I really don't like kitty as much as good old urxvt. From matt.egger at gmail.com Wed Sep 25 20:36:14 2024 From: matt.egger at gmail.com (Matt Egger) Date: Wed, 25 Sep 2024 16:36:14 -0400 Subject: [Slackbuilds-users] Taking over viking and gpsd pkgs In-Reply-To: References: <41ce216e-8d30-4eb7-bc35-bf37d07e80f5@sagredo.eu> <9f4dd1d8-e5cf-369d-3df4-d2f6c7821dfc@slackware.uk> Message-ID: I'll take diffoscope, tlsh and python-libarchive-c. I'll send updates tomorrow. -Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidnchmelik at gmail.com Fri Sep 27 07:00:44 2024 From: davidnchmelik at gmail.com (David Chmelik) Date: Fri, 27 Sep 2024 00:00:44 -0700 Subject: [Slackbuilds-users] haskell dependencies Message-ID: <0aa8721e-1afd-ac01-e755-49d9d413c5e8@gmail.com> When I tried to install pandoc (with dependency haskell-scientific) it said 'Setup: Encountered missing or private dependencies: th-abstraction >=0.2.3 && <0.5', and then it could't find the source code for th-lift (which I installed) and then not for control/concurrent/async either (installing async didn't help). From matteo.bernardini at gmail.com Fri Sep 27 13:29:00 2024 From: matteo.bernardini at gmail.com (Matteo Bernardini) Date: Fri, 27 Sep 2024 15:29:00 +0200 Subject: [Slackbuilds-users] haskell dependencies In-Reply-To: <0aa8721e-1afd-ac01-e755-49d9d413c5e8@gmail.com> References: <0aa8721e-1afd-ac01-e755-49d9d413c5e8@gmail.com> Message-ID: Hi David, I'm not able to reproduce your problem. I tried installing pandoc with all of its dependencies here, in this order ghc haskell-deepseq-generics haskell-transformers-compat haskell-base-orphans haskell-hashable haskell-data-fix haskell-base-compat haskell-OneTuple haskell-th-abstraction haskell-generic-deriving haskell-unordered-containers haskell-tagged haskell-semigroups haskell-void haskell-indexed-traversable haskell-distributive haskell-StateVar haskell-contravariant haskell-comonad haskell-bifunctors haskell-base-compat-batteries haskell-time-compat haskell-text-short haskell-semigroupoids haskell-primitive haskell-vector haskell-indexed-traversable-instances haskell-assoc haskell-these haskell-semialign haskell-witherable haskell-strict haskell-random haskell-uuid-types haskell-old-locale haskell-time-locale-compat haskell-syb haskell-blaze-builder haskell-integer-logarithms haskell-scientific haskell-attoparsec haskell-dlist haskell-aeson haskell-splitmix haskell-tf-random haskell-extensible-exceptions haskell-erf haskell-QuickCheck haskell-pandoc-types haskell-network-uri haskell-emojis haskell-bitarray haskell-unicode-transforms haskell-commonmark haskell-commonmark-extensions haskell-commonmark-pandoc haskell-lua haskell-lpeg haskell-hslua-core haskell-hslua-marshalling haskell-hslua-objectorientation haskell-hslua-packaging haskell-hslua-classes haskell-fail haskell-hslua haskell-safe haskell-pandoc-lua-marshal haskell-hslua-aeson haskell-temporary haskell-hslua-module-system haskell-hslua-module-path haskell-hslua-module-version haskell-base64-bytestring haskell-ipynb haskell-jira-wiki-markup haskell-uniplate haskell-th-lift haskell-th-lift-instances haskell-unicode-collation haskell-file-embed haskell-xml-types haskell-data-default-class haskell-blaze-markup haskell-blaze-html haskell-cabal-doctest haskell-unliftio-core haskell-async haskell-typed-process haskell-zlib haskell-network haskell-streaming-commons haskell-mmorph haskell-transformers-base haskell-monad-control haskell-lifted-base haskell-resourcet haskell-vector-algorithms haskell-split haskell-mono-traversable haskell-conduit haskell-conduit-extra haskell-xml-conduit haskell-data-default-instances-old-locale haskell-data-default-instances-dlist haskell-data-default-instances-containers haskell-data-default-instances-base haskell-data-default haskell-case-insensitive haskell-citeproc haskell-utf8-string haskell-digest haskell-zip-archive haskell-libyaml haskell-enclosed-exceptions haskell-yaml haskell-xml haskell-texmath haskell-tagsoup haskell-SHA haskell-mmap haskell-JuicyPixels haskell-appar haskell-byteorder haskell-iproute haskell-text-icu haskell-stringprep haskell-cereal haskell-punycode haskell-idna haskell-publicsuffixlist haskell-mime-types haskell-basement haskell-foundation haskell-memory haskell-http-types haskell-cookie haskell-http-client haskell-pem haskell-cryptonite haskell-byteable haskell-cryptohash haskell-hourglass haskell-asn1-types haskell-asn1-encoding haskell-crypto-pubkey-types haskell-asn1-parse haskell-x509 haskell-x509-store haskell-x509-system haskell-x509-validation haskell-securemem haskell-crypto-random haskell-crypto-numbers haskell-crypto-pubkey haskell-crypto-cipher-types haskell-cipher-rc4 haskell-cipher-des haskell-cipher-aes haskell-tls haskell-socks haskell-connection haskell-http-client-tls haskell-HTTP haskell-regex-base haskell-regex-pcre-builtin haskell-highlighting-kate haskell-unix-compat haskell-filemanip haskell-cmark haskell-regex-pcre haskell-hxt-charproperties haskell-hxt-regex-xmlschema haskell-hxt-unicode haskell-call-stack haskell-HUnit haskell-hxt haskell-colour haskell-ansi-terminal haskell-skylighting-core haskell-lexer happy haskell-pretty-show haskell-skylighting haskell-hslua-module-text haskell-haddock-library haskell-errors haskell-base16-bytestring haskell-text-conversions haskell-doclayout haskell-nats haskell-HsYAML haskell-doctemplates haskell-cmark-gfm haskell-cmdargs haskell-aeson-pretty haskell-Glob pandoc and everything went perfectly fine, besides it taking half a day: if you wish to speed up things you can also install, as an alternative, pandoc-bin, a repackaging of the official binary on github. Matteo Il giorno ven 27 set 2024 alle ore 09:01 David Chmelik < davidnchmelik at gmail.com> ha scritto: > When I tried to install pandoc (with dependency haskell-scientific) it > said 'Setup: Encountered missing or private dependencies: th-abstraction > >=0.2.3 && <0.5', and then it could't find the source code for th-lift > (which I installed) and then not for control/concurrent/async either > (installing async didn't help). > > _______________________________________________ > 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 Sep 28 00:31:44 2024 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sat, 28 Sep 2024 07:31:44 +0700 Subject: [Slackbuilds-users] Updates - 20240928.1 Message-ID: Sat Sep 28 00:04:12 UTC 2024 academic/fet: Updated for version 6.25.1. academic/qucs-s: Updated for version 24.3.2. audio/alsamodularsynth: Updated for version 2.2.1. audio/drumkv1: Updated for version 1.1.1. audio/ncspot: Dependency changed to rust-opt. audio/padthv1: Updated for version 1.1.1. audio/qjackctl: Updated for version 1.0.2. audio/samplv1: Updated for version 1.1.1. audio/synthv1: Updated for version 1.1.1. audio/yabridge: Dependency changed to rust-opt. desktop/9menu: Updated for version 1.11. desktop/leftwm: Dependency changed to rust-opt. desktop/nwg-drawer: Updated for version 0.5.0. desktop/nwg-hello: Updated for version 0.2.4. desktop/nwg-menu: Updated for version 0.1.6. desktop/nwg-panel: Updated for version 0.9.39. desktop/sun: Updated for version 1.6.3. desktop/wallpaper: Orphaned. development/UASM: Added (MASM-compatible assembler). development/actionlint: Updated for version 1.7.2. development/bcpp: Updated for version 20240917. development/cargo-c: Dependency changed to rust-opt. development/cargo-vendor-filterer: Dependency changed to rust-opt. development/cudatoolkit_12.6: Added (GPU-accelerated libraries). development/diffoscope: new maintainer, updated for version 277 development/gitlab-cli: Updated for version 1.46.1 development/haxe-bin: Updated for version 4.3.6. development/hugo: Updated for version 0.135.0. development/mdbook: Dependency changed to rust-opt. development/mold: Updated for version 2.34.0. development/php82: Updated for version 8.2.24 development/postman: Updated for version 11.13.0 development/pycharm: Updated for version 2024.2.2.242.22855.92. development/reflex: Updated for version 2.5.4.20240906. development/rstudio-desktop: Update for 2024.09.0+375 development/rust-opt: Added (Newer version of RUST). development/rustup: Dependency changed to rust-opt. development/uftrace: Updated for version 20240909_f3b92bb development/unicorn: Updated for version 2.1.0. development/wxHexEditor: Updated for version 20231108_f439d8f. games/crawl: Updated for version 0.32.1. games/jzintv: Updated for version 20200712, add 4-tris ROM. games/ltris: Updated for version 2.0.1. games/open-adventure: Updated for version 1.20. games/pasang-emas: Version bump to 6.3.0 games/peg-e: Version bump to 1.3.0 games/tome-ah: Updated for version 20240912_203c8c1. games/vbam: Updated for version 2.1.11. games/xroar: Updated for version 1.6.5. gis/gpsd: Updated for version 3.25. gis/osm-gps-map: Updated for version 1.2.0; new maintainer. gis/viking: Updated for version 1.10. graphics/blender: Switch source to (hopefully) more stable mirror graphics/blender: Version bump to 4.2.2 graphics/darktable: New maintainer. graphics/kuickshow: Updated for version 20240925_9fc56a8. graphics/veles: Dependency changed to rust-opt. graphics/vuescan: Updated MD5SUMs. ham/gridtracker: Updated for version 1.24.0922. libraries/botocore: Updated for version 1.35.28. libraries/flickcurl: New maintainer. libraries/ftgl: Fix -current build. libraries/gtkglext: Fix HOMEPAGE. libraries/p8-platform: Added (Platform support library). libraries/pytorch: Updated for version 2.4.1. libraries/qt6gtk2: Updated for version 0.3. libraries/tlsh: new maintainer misc/cheat: Remove hard-coded GOROOT path. multimedia/iptvnator: Updated for version 0.16.0. multimedia/minidlna: Updated for version 1.3.3. multimedia/opera-ffmpeg-codecs: Updated for version 0.92.0. multimedia/plexmediaserver: Updated for version 1.41.0.8994_f2c27da23. multimedia/rav1e: cargo-c dependency changed to rust-opt. multimedia/vapoursynth: Updated for version R70. multimedia/x265: Updated for version 3.6. network/NetworkManager-sstp: Added (Secure Socket Tunneling Protocol). network/awscli: Updated for version 1.34.28. network/brave-browser: Updated for version 1.70.119. network/cinny-desktop: Updated for version 4.2.1. network/discord: Version bump to 0.0.69 network/dropbox: Updated for version 208.4.5824. network/electrs: Dependency changed to rust-opt. network/newsboat: Dependency changed to rust-opt. network/noip-duc: Dependency changed to rust-opt. network/opera: Updated for version 114.0.5282.21. network/qbittorrent: Updated for version 4.6.7. network/rclone: Updated for version 1.68.1. network/scrcpy: Updated for version 2.7 network/sslscan: Updated for version 2.1.5. network/tailscale: Updated for version 1.74.1. network/tor-browser: Updated for version 13.5.5. network/vivaldi: Updated for version 6.9.3447.48. network/weechat: Updated for version 4.4.2. network/whalebird: Updated for version 6.1.6 network/youtube-dl: Updated for version 2024.07.11-nightly+20240806_c5098961b. network/znc: Updated for version 1.9.1. network/zoom-linux: Updated for version 6.2.2.2028 office/luametatex: Added (Continuation of luatex). office/luametatex: Fix permission. office/mupdf: Updated for version 1.24.9. office/navi: Dependency changed to rust-opt. office/zathura-cb: Updated for version 0.1.11. office/zathura-djvu: Updated for version 0.2.10. office/zathura-ps: Updated for version 0.2.8. python/cryptography: python3-maturin dependency changed to rust-opt. python/esptool: Updated for version 4.8.1. python/jellyfish: python3-maturin dependency changed to rust-opt. python/python-libarchive-c: new maintainer python/python-libarchive-c: updated for version 5.1 python/python3-aiohappyeyeballs: Updated for version 2.4.2. python/python3-aiohttp: Updated for version 3.10.6. python/python3-anyio: Update for 4.6.0 python/python3-bcrypt: Dependency changed to rust-opt. python/python3-debugpy: Update for 1.8.6 python/python3-dep-logic: Version bump to 0.4.9 python/python3-hishel: Version bump to 0.0.31 python/python3-maturin: Dependency changed to rust-opt. python/python3-orjson: python3-maturin dependency changed to rust-opt. python/python3-pdm-backend: Version bump to 2.4.1 python/python3-pdm: Version bump to 2.19.1 python/python3-pydantic-core: python3-maturin dependency changed to rust-opt. python/python3-watchdog: Updated for version 5.0.3. python/python3-yarl: Updated for version 1.12.1. python/python3-yarl: Updated for version 1.13.0. python/python3-yarl: Updated for version 1.13.1. python/s3transfer: Updated for version 0.10.2. ruby/ruby-build: Updated for version 20240917. system/7zip: Added (7Zip Archiver). system/86box: Updated for version 4.2.1. system/Iosevka-aile: Updated for version 31.7.1. system/Iosevka-etoile: Updated for version 31.7.1. system/alacritty: Dependency changed to rust-opt. system/bat: Dependency changed to rust-opt. system/bottom: Dependency changed to rust-opt. system/clamav: Dependency changed to rust-opt. system/doublecmd-qt5: Updated for version 1.1.18 system/dust: Dependency changed to rust-opt. system/fd: Dependency changed to rust-opt. system/greetd: Dependency changed to rust-opt. system/hardinfo2: Added (System Information and Benchmark). system/helvum: Dependency changed to rust-opt. system/hyperfine: Dependency changed to rust-opt. system/kitty-bin: Removed (use kitty instead). system/kitty: Updated for version 0.36.4 system/libratbag: Update for 0.18 system/locust: Updated for version 2.31.7. system/lynis: Updated for version 3.1.2. system/nerdctl: Added (Docker-compatible CLI for containerd). system/netdata: Updated for version 1.47.2. system/onefetch: Dependency changed to rust-opt. system/pax-utils: Updated for version 1.3.8. system/peazip: Added (file archiver utility). system/pigz: Orphaned. system/piper: Update for 0.8 system/ripgrep: Dependency changed to rust-opt. system/runc: Updated for version 1.1.14. system/sarasa-gothic: Updated for version 1.0.21. system/skim: Dependency changed to rust-opt. system/slackrepo-hints: Updated for version 20240927. system/slackrepo: Updated for version 20240921. system/slim: New maintainer, fix slimlock.conf. system/slpkg: Updated for version 5.1.3. system/tzupdate: Dependency changed to rust-opt. +--------------------------+ -- 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 lumin+slackbuilds at etherlight.link Sat Sep 28 01:28:33 2024 From: lumin+slackbuilds at etherlight.link (Lumin Etherlight) Date: Sat, 28 Sep 2024 04:28:33 +0300 Subject: [Slackbuilds-users] Upstream LTS Releases & Possibility of New Node.js 18.x SlackBuild Message-ID: <3d43c1ab-c794-4baf-a666-7d407e99ea06@etherlight.link> Hello Fellow Slackers, What is the SlackBuild typical practice regarding packages that have multiple concurrently supported upstream releases? The Node.js project, for example, maintains a current version, and multiple LTS versions. SlackBuilds currently packages only the latest LTS version of Node.js. I find myself deploying previous LTS for some production projects (previous LTS is still maintained upstream), or using newer non-LTS versions for development of new projects. I'm interested in maintaining a SlackBuild of the Node.js previous LTS (the 18.x.x series), which is still supported upstream, and is used in some projects I'm responsible for. Inspired by the likes of zulu-openjdk21, and zulu-openjdk17, etc. maybe a nodejs18 package would be acceptable? With wishes of a good day, to all of you, Lumin Etherlight From willysr at slackbuilds.org Sat Sep 28 02:05:03 2024 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sat, 28 Sep 2024 09:05:03 +0700 Subject: [Slackbuilds-users] Upstream LTS Releases & Possibility of New Node.js 18.x SlackBuild In-Reply-To: <3d43c1ab-c794-4baf-a666-7d407e99ea06@etherlight.link> References: <3d43c1ab-c794-4baf-a666-7d407e99ea06@etherlight.link> Message-ID: > Hello Fellow Slackers, > > ??????? What is the SlackBuild typical practice > ? regarding packages that have multiple concurrently > ? supported upstream releases?? The Node.js project, > ? for example, maintains a current version, and > ? multiple LTS versions. > > ??????? SlackBuilds currently packages only the > ? latest LTS version of Node.js.? I find myself > ? deploying previous LTS for some production > ? projects (previous LTS is still maintained > ? upstream), or using newer non-LTS versions for > ? development of new projects. > > ??????? I'm interested in maintaining a SlackBuild > ? of the Node.js previous LTS (the 18.x.x series), > ? which is still supported upstream, and is used in > ? some projects I'm responsible for. > > ??????? Inspired by the likes of zulu-openjdk21, and > ? zulu-openjdk17, etc. maybe a nodejs18 package > ? would be acceptable? yes, it's possible to do that i was also planning to do the same with postgresql since they have annual release cycle -- 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 dchmelik at gmail.com Sat Sep 28 02:43:02 2024 From: dchmelik at gmail.com (dchmelik at gmail.com) Date: Fri, 27 Sep 2024 19:43:02 -0700 Subject: [Slackbuilds-users] my updates (crawl, kuickshow, moria, tome-ah) Message-ID: Recently I uploaded updates to Dungeon Crawl Stone Soup (crawl), Kuickshow, Moria, AnonymousHero's ToME2 (tome-ah) and had been thinking about updating my maintainer name to my historical last name (Chmelik) rather than abridged/legal (Melik) but then decided not to it if it'll split my maintainer history on git.slackbuilds.org.? I see three (other than Moria which I had wrong md5sum) were added to the queue I guess for next week (because I can no longer delete/fix) with my last name being different in .info & .SlackBuild.? Can any SlackBuilds.org team members advise or correct me on this?? I'm not 100% sure it'll split my history on git (which I'd now rather avoid) but should at least have same last name in both files, so you can fix this or I can re-upload (then re-upload moria.tar.xz). From urchlay at slackware.uk Sat Sep 28 04:10:13 2024 From: urchlay at slackware.uk (B. Watson) Date: Sat, 28 Sep 2024 00:10:13 -0400 (EDT) Subject: [Slackbuilds-users] tre update to 0.9.0 Message-ID: I'm about to update libraries/tre to version 0.9.0. scalpel (Klaatu) and vis (Ruben Schuller) depend on tre. I've checked that these both build with the new tre, but I didn't do much runtime testing (vis at least starts up and regex searches work, no idea how to use scalpel). If you want to test with the new tre before next week's update, you can find it in my git branch, or grab a copy here: https://slackware.uk/~urchlay/src/tre.tar.gz I don't think you're going to find any problems, but it's worth a look. The other thing on SBo that uses tre (as an optional dep) is elinks, maintained by Dave Woodfall. Unfortunately he's not available for comment... but I did test elinks with the new tre, it builds and runs, and its regex searches work. From didier at slint.fr Sat Sep 28 07:48:39 2024 From: didier at slint.fr (Didier Spaier) Date: Sat, 28 Sep 2024 09:48:39 +0200 Subject: [Slackbuilds-users] hardinfo2 In-Reply-To: References: Message-ID: On 9/25/24 02:45, B. Watson wrote: > On Tue, 24 Sep 2024, Didier Spaier wrote: > >> most distributions are now shipping hardinfo2, that supersedes hardinfo. >> >> I suggest that someone (David, who maintains hardinfo?) provide a SlackBuild for >> it. > > I went ahead and wrote/submitted a SlackBuild for hardinfo2. David > Golus hasn't been active in 2+ years, no idea if he's still planning > to maintain anything. Available now and carefully crafted a usual, many thanks! Didier From j+sbo-users at maschinengott.de Sat Sep 28 08:27:09 2024 From: j+sbo-users at maschinengott.de (j+sbo-users at maschinengott.de) Date: Sat, 28 Sep 2024 10:27:09 +0200 Subject: [Slackbuilds-users] my updates (crawl, kuickshow, moria, tome-ah) In-Reply-To: References: Message-ID: https://ntietz.com/blog/git-mailmap-for-name-changes/ On 28.09.24 04:43, dchmelik at gmail.com wrote: > Recently I uploaded updates to Dungeon Crawl Stone Soup (crawl), > Kuickshow, Moria, AnonymousHero's ToME2 (tome-ah) and had been thinking > about updating my maintainer name to my historical last name (Chmelik) > rather than abridged/legal (Melik) but then decided not to it if it'll > split my maintainer history on git.slackbuilds.org. From urchlay at slackware.uk Sat Sep 28 10:23:32 2024 From: urchlay at slackware.uk (B. Watson) Date: Sat, 28 Sep 2024 06:23:32 -0400 (EDT) Subject: [Slackbuilds-users] my updates (crawl, kuickshow, moria, tome-ah) In-Reply-To: References: Message-ID: <4c8afc9-365e-be3b-ec8e-987d78a86a8@slackware.uk> On Sat, 28 Sep 2024, j+sbo-users at maschinengott.de wrote: > https://ntietz.com/blog/git-mailmap-for-name-changes/ That would made his commit log appear to have to new name for all his commits, on *his* computer(s)... but it would only work for everyone else if we all installed his .mailmap file (or, put it in SBo's master repo). Actually that might not be a bad idea, have a .mailmap in the repo that can be used by any maintainer, whenever his name needs to change. Though, I can see reasons not to do this (more work for us admins, and it would seem to *encourage* people to change their maintainer-names at will). Also, the database backend that drives the website doesn't support .mailmap, so we could end up with inconsistency between the site and the git history. Another alternative would be to rewrite the git history to update the name (and email, if that changes) on all commits. But that would break all remote repos/forks, and everyone would be forced to rm -rf and re-clone, every time this happened. Too much overhead and headache (can I make up a new word here? Overheadache). We had to deal with this exactly once in the history of SBo (a file had to be removed from the repo completely, due to DMCA blather [*]) and it resulted in mass confusion. [*] In the interest of full disclosure... it was my fault :( From klaatu at mixedsignals.ml Sat Sep 28 10:43:55 2024 From: klaatu at mixedsignals.ml (Klaatu) Date: Sat, 28 Sep 2024 22:43:55 +1200 Subject: [Slackbuilds-users] tre update to 0.9.0 In-Reply-To: References: Message-ID: <4911738.OV4Wx5bFTl@beast.slackermedia.local> Just tried scalpel with 0.9.0 tre and it works as expected. Thanks for the heads up. -klaatu On Saturday, September 28, 2024 4:10:13 PM NZST B. Watson wrote: > I'm about to update libraries/tre to version 0.9.0. > > scalpel (Klaatu) and vis (Ruben Schuller) depend on tre. I've checked > that these both build with the new tre, but I didn't do much runtime > testing (vis at least starts up and regex searches work, no idea how > to use scalpel). > > If you want to test with the new tre before next week's update, you > can find it in my git branch, or grab a copy here: > > https://slackware.uk/~urchlay/src/tre.tar.gz > > I don't think you're going to find any problems, but it's worth a look. > > The other thing on SBo that uses tre (as an optional dep) is elinks, > maintained by Dave Woodfall. Unfortunately he's not available for > comment... but I did test elinks with the new tre, it builds and runs, > and its regex searches work. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: From 1.41421 at gmail.com Sat Sep 28 17:00:46 2024 From: 1.41421 at gmail.com (Luveh Keraph) Date: Sat, 28 Sep 2024 11:00:46 -0600 Subject: [Slackbuilds-users] Updates - 20240928.1 In-Reply-To: References: Message-ID: A number of updates (cryptography, hyperfine, python3-maturin, maybe others) require more recent versions of Rust than the latest official one (1.60) in Slackware 15.0. There are newer versions of Rust under testing though. On Fri, Sep 27, 2024 at 6:31?PM Willy Sudiarto Raharjo < willysr at slackbuilds.org> wrote: > Sat Sep 28 00:04:12 UTC 2024 > academic/fet: Updated for version 6.25.1. > academic/qucs-s: Updated for version 24.3.2. > audio/alsamodularsynth: Updated for version 2.2.1. > audio/drumkv1: Updated for version 1.1.1. > audio/ncspot: Dependency changed to rust-opt. > audio/padthv1: Updated for version 1.1.1. > audio/qjackctl: Updated for version 1.0.2. > audio/samplv1: Updated for version 1.1.1. > audio/synthv1: Updated for version 1.1.1. > audio/yabridge: Dependency changed to rust-opt. > desktop/9menu: Updated for version 1.11. > desktop/leftwm: Dependency changed to rust-opt. > desktop/nwg-drawer: Updated for version 0.5.0. > desktop/nwg-hello: Updated for version 0.2.4. > desktop/nwg-menu: Updated for version 0.1.6. > desktop/nwg-panel: Updated for version 0.9.39. > desktop/sun: Updated for version 1.6.3. > desktop/wallpaper: Orphaned. > development/UASM: Added (MASM-compatible assembler). > development/actionlint: Updated for version 1.7.2. > development/bcpp: Updated for version 20240917. > development/cargo-c: Dependency changed to rust-opt. > development/cargo-vendor-filterer: Dependency changed to rust-opt. > development/cudatoolkit_12.6: Added (GPU-accelerated libraries). > development/diffoscope: new maintainer, updated for version 277 > development/gitlab-cli: Updated for version 1.46.1 > development/haxe-bin: Updated for version 4.3.6. > development/hugo: Updated for version 0.135.0. > development/mdbook: Dependency changed to rust-opt. > development/mold: Updated for version 2.34.0. > development/php82: Updated for version 8.2.24 > development/postman: Updated for version 11.13.0 > development/pycharm: Updated for version 2024.2.2.242.22855.92. > development/reflex: Updated for version 2.5.4.20240906. > development/rstudio-desktop: Update for 2024.09.0+375 > development/rust-opt: Added (Newer version of RUST). > development/rustup: Dependency changed to rust-opt. > development/uftrace: Updated for version 20240909_f3b92bb > development/unicorn: Updated for version 2.1.0. > development/wxHexEditor: Updated for version 20231108_f439d8f. > games/crawl: Updated for version 0.32.1. > games/jzintv: Updated for version 20200712, add 4-tris ROM. > games/ltris: Updated for version 2.0.1. > games/open-adventure: Updated for version 1.20. > games/pasang-emas: Version bump to 6.3.0 > games/peg-e: Version bump to 1.3.0 > games/tome-ah: Updated for version 20240912_203c8c1. > games/vbam: Updated for version 2.1.11. > games/xroar: Updated for version 1.6.5. > gis/gpsd: Updated for version 3.25. > gis/osm-gps-map: Updated for version 1.2.0; new maintainer. > gis/viking: Updated for version 1.10. > graphics/blender: Switch source to (hopefully) more stable mirror > graphics/blender: Version bump to 4.2.2 > graphics/darktable: New maintainer. > graphics/kuickshow: Updated for version 20240925_9fc56a8. > graphics/veles: Dependency changed to rust-opt. > graphics/vuescan: Updated MD5SUMs. > ham/gridtracker: Updated for version 1.24.0922. > libraries/botocore: Updated for version 1.35.28. > libraries/flickcurl: New maintainer. > libraries/ftgl: Fix -current build. > libraries/gtkglext: Fix HOMEPAGE. > libraries/p8-platform: Added (Platform support library). > libraries/pytorch: Updated for version 2.4.1. > libraries/qt6gtk2: Updated for version 0.3. > libraries/tlsh: new maintainer > misc/cheat: Remove hard-coded GOROOT path. > multimedia/iptvnator: Updated for version 0.16.0. > multimedia/minidlna: Updated for version 1.3.3. > multimedia/opera-ffmpeg-codecs: Updated for version 0.92.0. > multimedia/plexmediaserver: Updated for version 1.41.0.8994_f2c27da23. > multimedia/rav1e: cargo-c dependency changed to rust-opt. > multimedia/vapoursynth: Updated for version R70. > multimedia/x265: Updated for version 3.6. > network/NetworkManager-sstp: Added (Secure Socket Tunneling Protocol). > network/awscli: Updated for version 1.34.28. > network/brave-browser: Updated for version 1.70.119. > network/cinny-desktop: Updated for version 4.2.1. > network/discord: Version bump to 0.0.69 > network/dropbox: Updated for version 208.4.5824. > network/electrs: Dependency changed to rust-opt. > network/newsboat: Dependency changed to rust-opt. > network/noip-duc: Dependency changed to rust-opt. > network/opera: Updated for version 114.0.5282.21. > network/qbittorrent: Updated for version 4.6.7. > network/rclone: Updated for version 1.68.1. > network/scrcpy: Updated for version 2.7 > network/sslscan: Updated for version 2.1.5. > network/tailscale: Updated for version 1.74.1. > network/tor-browser: Updated for version 13.5.5. > network/vivaldi: Updated for version 6.9.3447.48. > network/weechat: Updated for version 4.4.2. > network/whalebird: Updated for version 6.1.6 > network/youtube-dl: Updated for version > 2024.07.11-nightly+20240806_c5098961b. > network/znc: Updated for version 1.9.1. > network/zoom-linux: Updated for version 6.2.2.2028 > office/luametatex: Added (Continuation of luatex). > office/luametatex: Fix permission. > office/mupdf: Updated for version 1.24.9. > office/navi: Dependency changed to rust-opt. > office/zathura-cb: Updated for version 0.1.11. > office/zathura-djvu: Updated for version 0.2.10. > office/zathura-ps: Updated for version 0.2.8. > python/cryptography: python3-maturin dependency changed to rust-opt. > python/esptool: Updated for version 4.8.1. > python/jellyfish: python3-maturin dependency changed to rust-opt. > python/python-libarchive-c: new maintainer > python/python-libarchive-c: updated for version 5.1 > python/python3-aiohappyeyeballs: Updated for version 2.4.2. > python/python3-aiohttp: Updated for version 3.10.6. > python/python3-anyio: Update for 4.6.0 > python/python3-bcrypt: Dependency changed to rust-opt. > python/python3-debugpy: Update for 1.8.6 > python/python3-dep-logic: Version bump to 0.4.9 > python/python3-hishel: Version bump to 0.0.31 > python/python3-maturin: Dependency changed to rust-opt. > python/python3-orjson: python3-maturin dependency changed to rust-opt. > python/python3-pdm-backend: Version bump to 2.4.1 > python/python3-pdm: Version bump to 2.19.1 > python/python3-pydantic-core: python3-maturin dependency changed to > rust-opt. > python/python3-watchdog: Updated for version 5.0.3. > python/python3-yarl: Updated for version 1.12.1. > python/python3-yarl: Updated for version 1.13.0. > python/python3-yarl: Updated for version 1.13.1. > python/s3transfer: Updated for version 0.10.2. > ruby/ruby-build: Updated for version 20240917. > system/7zip: Added (7Zip Archiver). > system/86box: Updated for version 4.2.1. > system/Iosevka-aile: Updated for version 31.7.1. > system/Iosevka-etoile: Updated for version 31.7.1. > system/alacritty: Dependency changed to rust-opt. > system/bat: Dependency changed to rust-opt. > system/bottom: Dependency changed to rust-opt. > system/clamav: Dependency changed to rust-opt. > system/doublecmd-qt5: Updated for version 1.1.18 > system/dust: Dependency changed to rust-opt. > system/fd: Dependency changed to rust-opt. > system/greetd: Dependency changed to rust-opt. > system/hardinfo2: Added (System Information and Benchmark). > system/helvum: Dependency changed to rust-opt. > system/hyperfine: Dependency changed to rust-opt. > system/kitty-bin: Removed (use kitty instead). > system/kitty: Updated for version 0.36.4 > system/libratbag: Update for 0.18 > system/locust: Updated for version 2.31.7. > system/lynis: Updated for version 3.1.2. > system/nerdctl: Added (Docker-compatible CLI for containerd). > system/netdata: Updated for version 1.47.2. > system/onefetch: Dependency changed to rust-opt. > system/pax-utils: Updated for version 1.3.8. > system/peazip: Added (file archiver utility). > system/pigz: Orphaned. > system/piper: Update for 0.8 > system/ripgrep: Dependency changed to rust-opt. > system/runc: Updated for version 1.1.14. > system/sarasa-gothic: Updated for version 1.0.21. > system/skim: Dependency changed to rust-opt. > system/slackrepo-hints: Updated for version 20240927. > system/slackrepo: Updated for version 20240921. > system/slim: New maintainer, fix slimlock.conf. > system/slpkg: Updated for version 5.1.3. > system/tzupdate: Dependency changed to rust-opt. > +--------------------------+ > > > -- > 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 matteo.bernardini at gmail.com Sat Sep 28 17:25:22 2024 From: matteo.bernardini at gmail.com (Matteo Bernardini) Date: Sat, 28 Sep 2024 19:25:22 +0200 Subject: [Slackbuilds-users] Updates - 20240928.1 In-Reply-To: References: Message-ID: Il giorno sab 28 set 2024 alle ore 19:01 Luveh Keraph <1.41421 at gmail.com> ha scritto: > A number of updates (cryptography, hyperfine, python3-maturin, maybe > others) require more recent versions of Rust than the latest official one > (1.60) in Slackware 15.0. There are newer versions of Rust under testing > though. > yes, and that's why they depend on rust-opt (still available on SBo), a newer rust installed in /opt, and they have this bit in the SlackBuild that let them use it export PATH="/opt/rust/bin:$PATH" if [ -z "$LD_LIBRARY_PATH" ]; then export LD_LIBRARY_PATH="/opt/rust/lib$LIBDIRSUFFIX" else export LD_LIBRARY_PATH="/opt/rust/lib$LIBDIRSUFFIX:$LD_LIBRARY_PATH" fi Matteo -------------- next part -------------- An HTML attachment was scrubbed... URL: From 1.41421 at gmail.com Sat Sep 28 18:06:41 2024 From: 1.41421 at gmail.com (Luveh Keraph) Date: Sat, 28 Sep 2024 12:06:41 -0600 Subject: [Slackbuilds-users] Updates - 20240928.1 In-Reply-To: References: Message-ID: Thanks, that fixed the build problems. I did not even have to touch PATH nor LD_LIBRARY_PATH. On Sat, Sep 28, 2024 at 11:25?AM Matteo Bernardini < matteo.bernardini at gmail.com> wrote: > Il giorno sab 28 set 2024 alle ore 19:01 Luveh Keraph <1.41421 at gmail.com> > ha scritto: > >> A number of updates (cryptography, hyperfine, python3-maturin, maybe >> others) require more recent versions of Rust than the latest official one >> (1.60) in Slackware 15.0. There are newer versions of Rust under testing >> though. >> > > yes, and that's why they depend on rust-opt (still available on SBo), a > newer rust installed in /opt, and they have this bit in the SlackBuild that > let them use it > > export PATH="/opt/rust/bin:$PATH" > if [ -z "$LD_LIBRARY_PATH" ]; then > export LD_LIBRARY_PATH="/opt/rust/lib$LIBDIRSUFFIX" > else > export LD_LIBRARY_PATH="/opt/rust/lib$LIBDIRSUFFIX:$LD_LIBRARY_PATH" > fi > > Matteo > _______________________________________________ > 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 jebrhansen+SBo at gmail.com Sat Sep 28 18:55:26 2024 From: jebrhansen+SBo at gmail.com (Jeremy Hansen) Date: Sat, 28 Sep 2024 11:55:26 -0700 Subject: [Slackbuilds-users] Updates - 20240928.1 In-Reply-To: References: Message-ID: That bit is added into the SlackBuild when needed. Users shouldn't ever need to adjust those to build software on SBo (unless they're trying to do something funky). Jeremy On Sat, Sep 28, 2024, 11:07?AM Luveh Keraph <1.41421 at gmail.com> wrote: > Thanks, that fixed the build problems. I did not even have to touch PATH > nor LD_LIBRARY_PATH. > > On Sat, Sep 28, 2024 at 11:25?AM Matteo Bernardini < > matteo.bernardini at gmail.com> wrote: > >> Il giorno sab 28 set 2024 alle ore 19:01 Luveh Keraph <1.41421 at gmail.com> >> ha scritto: >> >>> A number of updates (cryptography, hyperfine, python3-maturin, maybe >>> others) require more recent versions of Rust than the latest official one >>> (1.60) in Slackware 15.0. There are newer versions of Rust under testing >>> though. >>> >> >> yes, and that's why they depend on rust-opt (still available on SBo), a >> newer rust installed in /opt, and they have this bit in the SlackBuild that >> let them use it >> >> export PATH="/opt/rust/bin:$PATH" >> if [ -z "$LD_LIBRARY_PATH" ]; then >> export LD_LIBRARY_PATH="/opt/rust/lib$LIBDIRSUFFIX" >> else >> export LD_LIBRARY_PATH="/opt/rust/lib$LIBDIRSUFFIX:$LD_LIBRARY_PATH" >> fi >> >> Matteo >> _______________________________________________ >> SlackBuilds-users mailing list >> SlackBuilds-users at slackbuilds.org >> https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users >> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ >> FAQ - https://slackbuilds.org/faq/ >> >> _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - https://slackbuilds.org/faq/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From 1.41421 at gmail.com Sat Sep 28 22:49:38 2024 From: 1.41421 at gmail.com (Luveh Keraph) Date: Sat, 28 Sep 2024 16:49:38 -0600 Subject: [Slackbuilds-users] What's with x265? Message-ID: In the 21st September update x265 was upgraded to version 4.0. In the 28th September update it has been downgraded to version 3.6. Is there a problem with x265 version 4.0? -------------- next part -------------- An HTML attachment was scrubbed... URL: From urchlay at slackware.uk Sat Sep 28 23:10:51 2024 From: urchlay at slackware.uk (B. Watson) Date: Sat, 28 Sep 2024 19:10:51 -0400 (EDT) Subject: [Slackbuilds-users] What's with x265? In-Reply-To: References: Message-ID: <546696b2-24d1-9fb2-6a1c-baf4a262e72@slackware.uk> On Sat, 28 Sep 2024, Luveh Keraph wrote: > In the 21st September update x265 was upgraded to version 4.0. In the 28th September update it has been downgraded to version 3.6. > Is there a problem with x265 version 4.0? Was that you asking on IRC? If not... apparently mpv has problems with x265 4.0. But, don't know the details. It'd be nice if there was a comment in the script explaining *why* it was downgraded. All we've got is the git log: commit 4de0d333affc2d42e50f40a4d0a1cda5db92b63c Author: Willy Sudiarto Raharjo Date: Mon Sep 23 07:41:00 2024 +0700 multimedia/x265: Updated for version 3.6. This reverts commit 585c6dda5e541c359e4cc8e689b910d348295c4e. Signed-off-by: Willy Sudiarto Raharjo commit 585c6dda5e541c359e4cc8e689b910d348295c4e Author: Willy Sudiarto Raharjo Date: Sun Sep 15 15:52:45 2024 +0700 multimedia/x265: Updated for version 4.0. Signed-off-by: Willy Sudiarto Raharjo Your mission, should you choose to accept it, is to clone the repo, do a 'git checkout 585c6dda' (to get the x265 4.0 build). Build x265, install it, then build/install mpv's deps, then mpv itself. If it fails to compile, post the build log here. If it does compile, try using mpv to play a file encoded with the H.265 HEVC codec, and see if it plays correctly. Alternatively, if you can't/won't do the work, you could ask Chris Willing, maintainer of mpv, to take a look at it. Or you could wait 3 or 4 days, and I'll have time to mess with it myself. Probably. If I remember to. mpv and x265 aren't my builds, I'm just the 'repo fixer-upper' whenever I can be. From 1.41421 at gmail.com Sun Sep 29 00:23:45 2024 From: 1.41421 at gmail.com (Luveh Keraph) Date: Sat, 28 Sep 2024 18:23:45 -0600 Subject: [Slackbuilds-users] What's with x265? In-Reply-To: <546696b2-24d1-9fb2-6a1c-baf4a262e72@slackware.uk> References: <546696b2-24d1-9fb2-6a1c-baf4a262e72@slackware.uk> Message-ID: It wasn't me on IRC, but obviously somebody else has noticed. What bugs me is that every time that x265 is upgraded a number of other tools (at least ffmpeg, mplayer, mkvtoolnix) must be rebuilt. Well, at least I have to do so: otherwise, they can't find the target x265 library. Interestingly, mpv does not have to be rebuilt - and it still seems to work fine for me, in that it is able to play everything I throw at it, including material that uses the H.265 HEVC codec. On Sat, Sep 28, 2024 at 5:11?PM B. Watson wrote: > > > On Sat, 28 Sep 2024, Luveh Keraph wrote: > > > In the 21st September update x265 was upgraded to version 4.0. In the > 28th September update it has been downgraded to version 3.6. > > Is there a problem with x265 version 4.0? > > Was that you asking on IRC? > > If not... apparently mpv has problems with x265 4.0. But, don't know > the details. > > It'd be nice if there was a comment in the script explaining *why* it > was downgraded. All we've got is the git log: > > commit 4de0d333affc2d42e50f40a4d0a1cda5db92b63c > Author: Willy Sudiarto Raharjo > Date: Mon Sep 23 07:41:00 2024 +0700 > > multimedia/x265: Updated for version 3.6. > > This reverts commit 585c6dda5e541c359e4cc8e689b910d348295c4e. > > Signed-off-by: Willy Sudiarto Raharjo > > commit 585c6dda5e541c359e4cc8e689b910d348295c4e > Author: Willy Sudiarto Raharjo > Date: Sun Sep 15 15:52:45 2024 +0700 > > multimedia/x265: Updated for version 4.0. > > Signed-off-by: Willy Sudiarto Raharjo > > Your mission, should you choose to accept it, is to clone the repo, > do a 'git checkout 585c6dda' (to get the x265 4.0 build). Build > x265, install it, then build/install mpv's deps, then mpv itself. > > If it fails to compile, post the build log here. > > If it does compile, try using mpv to play a file encoded with the > H.265 HEVC codec, and see if it plays correctly. > > Alternatively, if you can't/won't do the work, you could ask Chris > Willing, maintainer of mpv, to take a look at it. > > Or you could wait 3 or 4 days, and I'll have time to mess with it > myself. Probably. If I remember to. mpv and x265 aren't my builds, I'm > just the 'repo fixer-upper' whenever I can be. > _______________________________________________ > 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 Sep 29 02:43:35 2024 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sun, 29 Sep 2024 09:43:35 +0700 Subject: [Slackbuilds-users] What's with x265? In-Reply-To: References: <546696b2-24d1-9fb2-6a1c-baf4a262e72@slackware.uk> Message-ID: <8ee20d0b-ac70-4952-bee3-2d17b81f987a@slackbuilds.org> > It wasn't me on IRC, but obviously somebody else has noticed. What bugs me > is that every time that x265 is upgraded a number of other tools (at least > ffmpeg, mplayer, mkvtoolnix) must be rebuilt. Well, at least I have to do > so: otherwise, they can't find the target x265 library. Interestingly, mpv > does not have to be rebuilt - and it still seems to work fine for me, in > that it is able to play everything I throw at it, including material that > uses the H.265 HEVC codec. There are some reports that it breaks some other scripts during runtime (not build time since i tested with all scripts that directly depends on it before i merge the update in master) see this posts: https://www.linuxquestions.org/questions/slackware-14/sbo-scripts-not-building-on-current-read-1st-post-pls-4175561999/page417.html https://www.linuxquestions.org/questions/slackware-14/sbo-scripts-not-building-on-current-read-1st-post-pls-4175561999/page418.html -- 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 Sun Sep 29 03:27:25 2024 From: 1.41421 at gmail.com (Luveh Keraph) Date: Sat, 28 Sep 2024 21:27:25 -0600 Subject: [Slackbuilds-users] What's with x265? In-Reply-To: <8ee20d0b-ac70-4952-bee3-2d17b81f987a@slackbuilds.org> References: <546696b2-24d1-9fb2-6a1c-baf4a262e72@slackware.uk> <8ee20d0b-ac70-4952-bee3-2d17b81f987a@slackbuilds.org> Message-ID: The only thing that I can say is that I built it last on 15th June, and that it seems to work with x265 4.0. On Sat, Sep 28, 2024 at 8:43?PM Willy Sudiarto Raharjo < willysr at slackbuilds.org> wrote: > > It wasn't me on IRC, but obviously somebody else has noticed. What bugs > me > > is that every time that x265 is upgraded a number of other tools (at > least > > ffmpeg, mplayer, mkvtoolnix) must be rebuilt. Well, at least I have to do > > so: otherwise, they can't find the target x265 library. Interestingly, > mpv > > does not have to be rebuilt - and it still seems to work fine for me, in > > that it is able to play everything I throw at it, including material that > > uses the H.265 HEVC codec. > > There are some reports that it breaks some other scripts during runtime > (not build time since i tested with all scripts that directly depends on > it before i merge the update in master) > > see this posts: > > https://www.linuxquestions.org/questions/slackware-14/sbo-scripts-not-building-on-current-read-1st-post-pls-4175561999/page417.html > > > https://www.linuxquestions.org/questions/slackware-14/sbo-scripts-not-building-on-current-read-1st-post-pls-4175561999/page418.html > > > > -- > 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 Sep 29 03:28:29 2024 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sun, 29 Sep 2024 10:28:29 +0700 Subject: [Slackbuilds-users] What's with x265? In-Reply-To: References: <546696b2-24d1-9fb2-6a1c-baf4a262e72@slackware.uk> <8ee20d0b-ac70-4952-bee3-2d17b81f987a@slackbuilds.org> Message-ID: > The only thing that I can say is that I built it last on 15th June, and > that it seems to work with x265 4.0. what did you built on 15th June? -- 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 Sun Sep 29 10:41:16 2024 From: antonioleal at yahoo.com (Antonio Leal) Date: Sun, 29 Sep 2024 11:41:16 +0100 Subject: [Slackbuilds-users] clamav rebuild fail References: <9b0f29ad-358d-4746-b785-9f80548330f3.ref@yahoo.com> Message-ID: <9b0f29ad-358d-4746-b785-9f80548330f3@yahoo.com> Maybe also related to the rust changes, clamav 1.4.1 updated script generates: [ 16%] Building CXX object libclamunrar/CMakeFiles/clamunrar.dir/volume.cpp.o [ 17%] Linking CXX shared library libclamunrar.so [ 17%] Built target clamunrar [ 17%] Building CXX object libclamunrar_iface/CMakeFiles/clamunrar_iface.dir/unrar_iface.cpp.o [ 18%] Linking CXX shared library libclamunrar_iface.so [ 18%] Built target clamunrar_iface [ 19%] Building clamav_rust in /tmp/SBo/clamav-1.4.1/build with: ?/usr/bin/cargo build --offline --target x86_64-unknown-linux-gnu --release --target-dir /tmp/SBo/clamav-1.4.1/build error: failed to get `base64` as a dependency of package `clamav_rust v0.0.1 (/tmp/SBo/clamav-1.4.1/libclamav_rust)` Caused by: ?failed to load source for dependency `base64` Caused by: ?Unable to update registry `crates-io` Caused by: ?failed to update replaced source registry `crates-io` Caused by: ?failed to parse manifest at `/tmp/SBo/clamav-1.4.1/.cargo/vendor/gif/Cargo.toml` Caused by: ?namespaced features with the `dep:` prefix are only allowed on the nightly channel and requires the `-Z namespaced-features` flag on the command-line make[2]: *** [libclamav_rust/CMakeFiles/clamav_rust_target.dir/build.make:87: x86_64-unknown-linux-gnu/release/libclamav_rust.a] Error 101 make[1]: *** [CMakeFiles/Makefile2:643: libclamav_rust/CMakeFiles/clamav_rust_target.dir/all] Error 2 make: *** [Makefile:156: all] Error 2 clamav: Would you like to continue processing the rest of the queue or would you like to abort? ?If this failed package is a dependency of another package in the queue then it may not make sense to continue. (Y)es to continue, (N)o to abort, (R)etry the build?: -------------- next part -------------- An HTML attachment was scrubbed... URL: From antonioleal at yahoo.com Sun Sep 29 10:53:12 2024 From: antonioleal at yahoo.com (Antonio Leal) Date: Sun, 29 Sep 2024 11:53:12 +0100 Subject: [Slackbuilds-users] clamav rebuild fail In-Reply-To: <9b0f29ad-358d-4746-b785-9f80548330f3@yahoo.com> References: <9b0f29ad-358d-4746-b785-9f80548330f3.ref@yahoo.com> <9b0f29ad-358d-4746-b785-9f80548330f3@yahoo.com> Message-ID: please ignore this post. somehow the rust-opt dependency was skipped... strange... On 29/09/24 11:41, Antonio Leal via SlackBuilds-users wrote: > > Maybe also related to the rust changes, clamav 1.4.1 updated script > generates: > > [ 16%] Building CXX object > libclamunrar/CMakeFiles/clamunrar.dir/volume.cpp.o > [ 17%] Linking CXX shared library libclamunrar.so > [ 17%] Built target clamunrar > [ 17%] Building CXX object > libclamunrar_iface/CMakeFiles/clamunrar_iface.dir/unrar_iface.cpp.o > [ 18%] Linking CXX shared library libclamunrar_iface.so > [ 18%] Built target clamunrar_iface > [ 19%] Building clamav_rust in /tmp/SBo/clamav-1.4.1/build with: > ?/usr/bin/cargo build --offline --target x86_64-unknown-linux-gnu > --release --target-dir /tmp/SBo/clamav-1.4.1/build > error: failed to get `base64` as a dependency of package `clamav_rust > v0.0.1 (/tmp/SBo/clamav-1.4.1/libclamav_rust)` > > Caused by: > ?failed to load source for dependency `base64` > > Caused by: > ?Unable to update registry `crates-io` > > Caused by: > ?failed to update replaced source registry `crates-io` > > Caused by: > ?failed to parse manifest at > `/tmp/SBo/clamav-1.4.1/.cargo/vendor/gif/Cargo.toml` > > Caused by: > ?namespaced features with the `dep:` prefix are only allowed on the > nightly channel and requires the `-Z namespaced-features` flag on the > command-line > make[2]: *** > [libclamav_rust/CMakeFiles/clamav_rust_target.dir/build.make:87: > x86_64-unknown-linux-gnu/release/libclamav_rust.a] Error 101 > make[1]: *** [CMakeFiles/Makefile2:643: > libclamav_rust/CMakeFiles/clamav_rust_target.dir/all] Error 2 > make: *** [Makefile:156: all] Error 2 > > clamav: > Would you like to continue processing the rest of the > queue or would you like to abort? ?If this failed > package is a dependency of another package in the queue > then it may not make sense to continue. > > (Y)es to continue, (N)o to abort, (R)etry the build?: > > > > _______________________________________________ > 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 Sep 29 12:51:53 2024 From: 1.41421 at gmail.com (Luveh Keraph) Date: Sun, 29 Sep 2024 06:51:53 -0600 Subject: [Slackbuilds-users] What's with x265? In-Reply-To: References: <546696b2-24d1-9fb2-6a1c-baf4a262e72@slackware.uk> <8ee20d0b-ac70-4952-bee3-2d17b81f987a@slackbuilds.org> Message-ID: I did either sbopkg -i mpv, or else sbopkg -ki mpv.sqf - I can't quite recall whether I already had it in place or whether it was the first time I was building it in this system: -rw-r--r-- 1 root root 2856 Jun 15 12:09 /var/log/packages/mpv-0.38.0-x86_64-1_SBo I have not used it much since though - it was only yesterday the first time in many weeks that I tried it. On Sat, Sep 28, 2024 at 9:28?PM Willy Sudiarto Raharjo < willysr at slackbuilds.org> wrote: > > The only thing that I can say is that I built it last on 15th June, and > > that it seems to work with x265 4.0. > > what did you built on 15th June? > > > -- > 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 erich.public at protonmail.com Mon Sep 30 14:46:47 2024 From: erich.public at protonmail.com (Erich Ritz) Date: Mon, 30 Sep 2024 14:46:47 +0000 Subject: [Slackbuilds-users] Please remove network/protonvpn-cli Message-ID: <1_9DKMSWlbTx5jlCjLWT0p67JJLIJSp9clh7JqsrSuI1ebZYUH8KhF4iou-23pjsDu8Wfp8vaYhbCuFaHtQTbMOfwsB-DFmmUU6fZ4qfa-E=@protonmail.com> The legacy protonvpn-cli has finally stopped working all together.? It's time to say goodbye. Please note it is still possible to use the ProtonVPN service by using the OpenVPN or WireGuard configuration files (I use the WireGuard configuration files with my router). Here is the output when trying to connect to the VPN using protonvpn-cli: # protonvpn -c Traceback (most recent call last): File "/usr/bin/protonvpn", line 33, in sys.exit(load_entry_point('protonvpn-cli==2.2.12', 'console_scripts', 'protonvpn')()) File "/usr/lib64/python3.9/site-packages/protonvpn_cli/cli.py", line 72, in main cli() File "/usr/lib64/python3.9/site-packages/protonvpn_cli/cli.py", line 134, in cli connection.dialog() File "/usr/lib64/python3.9/site-packages/protonvpn_cli/connection.py", line 94, in dialog country = show_dialog("Choose a country:", choices) File "/usr/lib64/python3.9/site-packages/protonvpn_cli/connection.py", line 38, in show_dialog code, tag = d.menu(headline, title="ProtonVPN-CLI", choices=choices) File "/usr/lib64/python3.9/site-packages/dialog.py", line 2935, in menu return self._widget_with_string_output( File "/usr/lib64/python3.9/site-packages/dialog.py", line 1728, in _widget_with_string_output code, output = self._perform(args, **kwargs) File "/usr/lib64/python3.9/site-packages/dialog.py", line 1523, in _perform exit_code, output = self._handle_program_exit(child_pid, File "/usr/lib64/python3.9/site-packages/dialog.py", line 1489, in _handle_program_exit self._wait_for_program_termination(child_pid, File "/usr/lib64/python3.9/site-packages/dialog.py", line 1435, in _wait_for_program_termination raise DialogError( dialog.DialogError: dialog-like terminated due to an error: the dialog-like program exited with status 3 (which was passed to it as the DIALOG_ERROR environment variable). Sometimes, the reason is simply that dialog was given a height or width parameter that is too big for the terminal in use. Its output, with leading and trailing whitespace stripped, was: Expected at least 20 tokens for --men, have 4. Use --help to list options. Erich