From chytraeu at sdf.org Tue Mar 2 02:40:15 2021 From: chytraeu at sdf.org (Donald Cooley) Date: Mon, 1 Mar 2021 20:40:15 -0600 Subject: [Slackbuilds-users] please remove qbittorrent and dissenter browser and waterfox browser Message-ID: <1c1b4e7c-47d2-b9c7-722d-c2e02acf352b@sdf.org> As the maintainer of both qbittorrent and dissenter browser, please remove these outdated packages. qbittorrent is old and cannot easily be updated; people really should move to the qbittorent-qt5 build. What I am proposing to happen is for one of the admins to remove the present qbittorrent build and rename qbittorent-qt5 to qbittorrent. i.e., mv qbittorrent-qt5 qbittorrent dissenter-browser for Linux is old and has not been updated upstream for sometime. So please just remove it. I will probably resubmit a build if it is updated again in the future. waterfox binaries do not any longer run on slackware 64 14.2. please remove waterfox also. -- regards, Donald Cooley From chytraeu at sdf.org Wed Mar 3 12:38:09 2021 From: chytraeu at sdf.org (Donald Cooley) Date: Wed, 03 Mar 2021 06:38:09 -0600 Subject: [Slackbuilds-users] please remove qbittorrent and dissenter browser and waterfox browser In-Reply-To: <1c1b4e7c-47d2-b9c7-722d-c2e02acf352b@sdf.org> References: <1c1b4e7c-47d2-b9c7-722d-c2e02acf352b@sdf.org> Message-ID: On March 1, 2021 8:40:15 PM CST, Donald Cooley via SlackBuilds-users wrote: >As the maintainer of both qbittorrent and dissenter browser, please >remove these outdated packages. > >qbittorrent is old and cannot easily be updated; people really should >move to the qbittorent-qt5 build. What I am proposing to happen is for >one of the admins to remove the present qbittorrent build and rename >qbittorent-qt5 to qbittorrent. > >i.e., >mv qbittorrent-qt5 qbittorrent > > >dissenter-browser for Linux is old and has not been updated upstream for >sometime. So please just remove it. I will probably resubmit a build if >it is updated again in the future. > >waterfox binaries do not any longer run on slackware 64 14.2. please >remove waterfox also. > Anyone? From matteo.bernardini at gmail.com Wed Mar 3 13:11:14 2021 From: matteo.bernardini at gmail.com (Matteo Bernardini) Date: Wed, 3 Mar 2021 14:11:14 +0100 Subject: [Slackbuilds-users] please remove qbittorrent and dissenter browser and waterfox browser In-Reply-To: References: <1c1b4e7c-47d2-b9c7-722d-c2e02acf352b@sdf.org> Message-ID: Hi Donald, please have a look at my branch, I hope the modifications pushed as are you intended https://git.slackbuilds.org/slackbuilds/log/?h=user/ponce/updates Matteo Il giorno mer 3 mar 2021 alle ore 13:38 Donald Cooley via SlackBuilds-users ha scritto: > > On March 1, 2021 8:40:15 PM CST, Donald Cooley via SlackBuilds-users wrote: > >As the maintainer of both qbittorrent and dissenter browser, please > >remove these outdated packages. > > > >qbittorrent is old and cannot easily be updated; people really should > >move to the qbittorent-qt5 build. What I am proposing to happen is for > >one of the admins to remove the present qbittorrent build and rename > >qbittorent-qt5 to qbittorrent. > > > >i.e., > >mv qbittorrent-qt5 qbittorrent > > > > > >dissenter-browser for Linux is old and has not been updated upstream for > >sometime. So please just remove it. I will probably resubmit a build if > >it is updated again in the future. > > > >waterfox binaries do not any longer run on slackware 64 14.2. please > >remove waterfox also. > > > > Anyone? > _______________________________________________ > 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 chytraeu at sdf.org Wed Mar 3 13:18:16 2021 From: chytraeu at sdf.org (Donald Cooley) Date: Wed, 3 Mar 2021 07:18:16 -0600 Subject: [Slackbuilds-users] please remove qbittorrent and dissenter browser and waterfox browser In-Reply-To: References: <1c1b4e7c-47d2-b9c7-722d-c2e02acf352b@sdf.org> Message-ID: <6a6e5be6-9da9-7303-79f4-7d7d7adbbaca@sdf.org> Hi Matteo, Looks great. Thank you. regards, Donald Cooley On 3/3/21 7:11 AM, Matteo Bernardini wrote: > Hi Donald, > > please have a look at my branch, I hope the modifications pushed as > are you intended > > https://git.slackbuilds.org/slackbuilds/log/?h=user/ponce/updates > > Matteo > > Il giorno mer 3 mar 2021 alle ore 13:38 Donald Cooley via > SlackBuilds-users ha scritto: >> >> On March 1, 2021 8:40:15 PM CST, Donald Cooley via SlackBuilds-users wrote: >>> As the maintainer of both qbittorrent and dissenter browser, please >>> remove these outdated packages. >>> >>> qbittorrent is old and cannot easily be updated; people really should >>> move to the qbittorent-qt5 build. What I am proposing to happen is for >>> one of the admins to remove the present qbittorrent build and rename >>> qbittorent-qt5 to qbittorrent. >>> >>> i.e., >>> mv qbittorrent-qt5 qbittorrent >>> >>> >>> dissenter-browser for Linux is old and has not been updated upstream for >>> sometime. So please just remove it. I will probably resubmit a build if >>> it is updated again in the future. >>> >>> waterfox binaries do not any longer run on slackware 64 14.2. please >>> remove waterfox also. >>> >> >> Anyone? >> _______________________________________________ >> SlackBuilds-users mailing list >> SlackBuilds-users at slackbuilds.org >> https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users >> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ >> FAQ - https://slackbuilds.org/faq/ >> > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - https://slackbuilds.org/faq/ > From upnort at tushmail.com Fri Mar 5 20:11:19 2021 From: upnort at tushmail.com (UpNort) Date: Fri, 5 Mar 2021 14:11:19 -0600 Subject: [Slackbuilds-users] Proposal for build scripts Message-ID: Hi All, Proposal: SBo build scripts check locally for the downloaded sources and validate the md5sum. I always hen-pecked my way through SBo to build the packages I want. Doable on a single package basis. Now that I am trying to help test Current with at least the packages I use, I notice some inefficiency at my end. The Current git clone (fork) does not contain the sources. That's ok and I don't expect that, even with the parent SBo site. Yet when I copy a specific SBo package directory to a build environment, the sources still do not exist locally. While the parent SBo site has links to the sources, with the git clone I have to open the info file to find the upstream location and manually download. Perhaps all SBo scripts could automate this. Before executing the tar command verify the sources exist in $CWD. Use the info file to download as necessary. Then validate the sources with md5sum from the info file. I realize third party packages automate this, but for people manually installing SBo packages the modifications would save time and offer nominal security. Just a thought. Thanks. P.S. I am not a member of the list. From erich.public at protonmail.com Sat Mar 6 04:33:56 2021 From: erich.public at protonmail.com (Erich Ritz) Date: Sat, 06 Mar 2021 04:33:56 +0000 Subject: [Slackbuilds-users] Proposal for build scripts In-Reply-To: References: Message-ID: Hi UpNort, ??????? Original Message ??????? On Friday, March 5, 2021 1:11 PM, UpNort wrote: > Hi All, > > Proposal: SBo build scripts check locally for the downloaded sources and > validate the md5sum. I disagree: a SlackBuild is for building a package - no more, no less. > > I always hen-pecked my way through SBo to build the packages I want. > Doable on a single package basis. Now that I am trying to help test > Current with at least the packages I use, I notice some inefficiency at > my end. > > The Current git clone (fork) does not contain the sources. That's ok and > I don't expect that, even with the parent SBo site. > > Yet when I copy a specific SBo package directory to a build environment, > the sources still do not exist locally. While the parent SBo site has > links to the sources, with the git clone I have to open the info file to > find the upstream location and manually download. Yes, this is what the .info file is for. > > Perhaps all SBo scripts could automate this. Before executing the tar > command verify the sources exist in $CWD. Use the info file to download > as necessary. Then validate the sources with md5sum from the info file. > > I realize third party packages automate this, but for people manually > installing SBo packages the modifications would save time and offer > nominal security. If you want it to be automated, please use one of the tools that already do all this for you. The SlackBuilds.org philosophy is to provide the information needed for you to use any tools you would like. Each component does one thing and does it well. I have used both sbopkg and slackrepo - they are both excellent. Shoehorning this functionality into each and every SlackBuild actually decreases "security" as it just increases code copying and the chances for mistakes. I would be against adding such code to the SlackBuilds I maintain, at least. Originally, like you I preferred to use the SlackBuilds manually. After managing more than several SBo packages I realized this was just a waste of time and looked into how to automate the process. This led me to realize other people had already written automation tools. So I used them. I suggest you find the tool(s) you like best and use them. > > Just a thought. > > Thanks. > > P.S. I am not a member of 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/ From willysr at slackbuilds.org Sat Mar 6 05:06:05 2021 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sat, 6 Mar 2021 12:06:05 +0700 Subject: [Slackbuilds-users] Updates - 20210306.1 Message-ID: Sat Mar 6 04:13:01 UTC 2021 academic/Gridcoin-Research: Updated for version 5.2.0.0 academic/STAR: Updated for version 2.7.8a. academic/fet: Updated for version 5.49.0. audio/apulse: Updated for version 0.1.13, new maintainer. audio/drumstick: Added (C++ MIDI libraries using Qt5 objects) audio/vmpk: Updated for version 0.7.1. desktop/hushboard: Fix version in .info. development/f2c: Updated for version 2020916. development/gedit-plugins: Changed DOWNLOAD URL. development/gedit: Changed DOWNLOAD URL. development/git-crypt: Added (transparent file encryption in git) development/github-cli: Updated for version 1.7.0 development/kotlin: Updated for version 1.4.31. development/radare2: Updated for version 5.1.1. development/vscode-bin: Updated for version 1.54.1. development/xnedit: Updated for version 1.2.2. games/Genesis-Plus-GX: Updated for version 2020.01.05_74ad967. games/ags: Updated for version 3.5.0.30. games/beetle-psx-libretro: Updated for version 2020.02.03_e5e83cd. games/empire: Updated for version 4.4.1. games/uqm: Updated for version 0.8.0. games/uqm_3domusic: Updated for version 0.8.0. games/uqm_remixes: Updated for version 0.8.0. graphics/gscan2pdf: Updated for version 2.11.0 graphics/vuescan: Updated MD5SUMs. libraries/dumb: Added (Dynamic Universal Music Bibliotheque) libraries/libxkbcommon: Updated for version 1.1.0. libraries/xforms: Patch for newer gcc misc/jmri: Updated for version 4.22. multimedia/LBRY: Updated for version 0.49.5. network/acme.sh: Updated for version 2.8.8. network/brave-browser: Updated for version 1.21.73. network/dissenter-browser: Removed (unmaintained upstream). network/neomutt: Updated for version 20210205. network/qbittorrent-qt5: Removed (renamed as qbittorent). network/qbittorrent: Updated for version 4.3.0.1 (switch to qt5). network/scapy: Updated for version 2.4.4. network/tor-browser: Updated for version 10.0.13. network/waterfox: Removed (doesn't run on 14.2 anymore). network/youtube-dl: Updated for version 2021.02.22. network/zoom-linux: Updated for version 5.5.7938.0228 office/hebcal: Updated for version 4.24. office/todo.txt-cli: Added (CLI frontend for todo.txt) perl/perl-Date-Manip: Updated for version 6.85. perl/perl-IO-Socket-SSL: Updated for version 2.070. perl/perl-Image-Sane: Updated for version 5 python/defusedxml: Updated for version 0.7.0. python/python-socks: Added (SOCKS proxy connector for aiohttp) python/python3-aiohttp-socks: Updated for version 0.6.0. python/python3-aiohttp: Updated for version 3.7.4. python/python3-lazy-object-proxy: Updated for version 1.5.2. python/python3-pylint: Updated for version 2.7.1. python/websocket-client: Updated for version 0.58.0. system/compsize: Updated for version 1.5. system/dosbox-dev: updated for version 0.75_pre4441 system/f2fs_tools: Updated for version 1.14.0. system/intelmas: Updated for version 1.6. system/kegs: Updated for version 1.05. system/lddsafe: Added (safe replacement for ldd) system/letsencrypt: Updated for version 1.13.0. system/netdata: Updated for version 1.29.3. system/passwordsafe: Updated for version 1.13.0. system/rmw: Updated for version 0.7.06. system/s3fs-fuse: Updated for version 1.89. +--------------------------+ -- Willy Sudiarto Raharjo -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From lists at osh.id.au Sat Mar 6 07:38:30 2021 From: lists at osh.id.au (David O'Shaughnessy) Date: Sat, 06 Mar 2021 15:38:30 +0800 Subject: [Slackbuilds-users] Proposal for build scripts In-Reply-To: References: Message-ID: <23513747-df6d-4f6f-955b-4590e0da4cca@www.fastmail.com> On Sat, 6 Mar 2021, at 4:11 AM, UpNort wrote: > Hi All, > > Proposal: SBo build scripts check locally for the downloaded sources and > validate the md5sum. I have to agree with Erich on this one, I think that work should be left for the 3rd party SBo maintenance tools. If you want something simple that will grab sources and compare md5s for manual SlackBuild work, you might find sbuild useful: https://gitlab.com/oshd/sbuild/ -- Dave From spycrowsoft at gmail.com Sun Mar 7 15:32:50 2021 From: spycrowsoft at gmail.com (Spycrowsoft) Date: Sun, 7 Mar 2021 16:32:50 +0100 Subject: [Slackbuilds-users] Proposal for build scripts In-Reply-To: <23513747-df6d-4f6f-955b-4590e0da4cca@www.fastmail.com> References: <23513747-df6d-4f6f-955b-4590e0da4cca@www.fastmail.com> Message-ID: <3c16365f-5029-52eb-fb7c-6af69ad64b94@gmail.com> Hi all, I agree with this as well as I tend to use the slackbuild scripts from time to time to build a different version of a package than the one that is currenly on SBo. Being able to run a slackbuild like "VERSION=some.other.number ./package.Slackbuild" is a great boon, but this functionality would be ruined if the slackbuilds themselves start validating the tarballs. Kind regards, Spycrowsoft Op 06-03-2021 om 08:38 schreef David O'Shaughnessy: > On Sat, 6 Mar 2021, at 4:11 AM, UpNort wrote: >> Hi All, >> >> Proposal: SBo build scripts check locally for the downloaded sources and >> validate the md5sum. > I have to agree with Erich on this one, I think that work should be left for the 3rd party SBo maintenance tools. > > If you want something simple that will grab sources and compare md5s for manual SlackBuild work, you might find sbuild useful: > > https://gitlab.com/oshd/sbuild/ > > -- > Dave > _______________________________________________ > 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 luc.vanrompaey at gmail.com Sun Mar 7 15:52:32 2021 From: luc.vanrompaey at gmail.com (Luc Van Rompaey) Date: Sun, 7 Mar 2021 16:52:32 +0100 Subject: [Slackbuilds-users] Proposal for build scripts In-Reply-To: <3c16365f-5029-52eb-fb7c-6af69ad64b94@gmail.com> References: <23513747-df6d-4f6f-955b-4590e0da4cca@www.fastmail.com> <3c16365f-5029-52eb-fb7c-6af69ad64b94@gmail.com> Message-ID: I use my own little script to do the download for me. Thus, I can still choose to do the download manually (or modify my script accordingly) if I want to download a different source version from what the slackbuild specifies. Op zo 7 mrt. 2021 16:32 schreef Spycrowsoft : > Hi all, > > I agree with this as well as I tend to use the slackbuild scripts from > time to time to build a different version of a package than the one that > is currenly on SBo. > > Being able to run a slackbuild like "VERSION=some.other.number > ./package.Slackbuild" is a great boon, but this functionality would be > ruined if the slackbuilds themselves start validating the tarballs. > > Kind regards, > > Spycrowsoft > > Op 06-03-2021 om 08:38 schreef David O'Shaughnessy: > > On Sat, 6 Mar 2021, at 4:11 AM, UpNort wrote: > >> Hi All, > >> > >> Proposal: SBo build scripts check locally for the downloaded sources and > >> validate the md5sum. > > I have to agree with Erich on this one, I think that work should be left > for the 3rd party SBo maintenance tools. > > > > If you want something simple that will grab sources and compare md5s for > manual SlackBuild work, you might find sbuild useful: > > > > https://gitlab.com/oshd/sbuild/ > > > > -- > > Dave > > _______________________________________________ > > 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 davidnchmelik at gmail.com Mon Mar 8 06:55:22 2021 From: davidnchmelik at gmail.com (David Chmelik) Date: Sun, 7 Mar 2021 22:55:22 -0800 Subject: [Slackbuilds-users] Angband Message-ID: After many years, I'm thinking of giving up the Angband SlackBuild in the case someone else wants it.? Since they removed charisma from the game (so you don't do as well in shops or perhaps with neutral monsters) they made many more changes away from classic style, which I don't really like (like to magic/spells, so it no longer feels like playing Moria.)? I'd want to make a new 'retro' Angband SlackBuild, the last Angband that had charisma... would that be an acceptable one to submit? Sincerely, David From dave at slackbuilds.org Mon Mar 8 07:01:29 2021 From: dave at slackbuilds.org (Dave Woodfall) Date: Mon, 8 Mar 2021 07:01:29 +0000 Subject: [Slackbuilds-users] Angband In-Reply-To: References: Message-ID: <20210308070129.GD15582@localhost> On 07/03/21 22:55, David Chmelik put forth the proposition: > After many years, I'm thinking of giving up the Angband SlackBuild in the > case someone else wants it.? Since they removed charisma from the game (so > you don't do as well in shops or perhaps with neutral monsters) they made > many more changes away from classic style, which I don't really like (like > to magic/spells, so it no longer feels like playing Moria.)? I'd want to > make a new 'retro' Angband SlackBuild, the last Angband that had charisma... > would that be an acceptable one to submit? > Sincerely, > David I can't see it as problem personally. -- Dave From porting at use.startmail.com Mon Mar 8 12:55:19 2021 From: porting at use.startmail.com (=?ISO-8859-1?Q?Rub=E9n?= Llorente) Date: Mon, 8 Mar 2021 12:55:19 -0000 (UTC) Subject: [Slackbuilds-users] Angband References: Message-ID: David Chmelik wrote: > After many years, I'm thinking of giving up the Angband SlackBuild in > the case someone else wants it.? Since they removed charisma from the > game (so you don't do as well in shops or perhaps with neutral monsters) > they made many more changes away from classic style, which I don't > really like (like to magic/spells, so it no longer feels like playing > Moria.)? I'd want to make a new 'retro' Angband SlackBuild, the last > Angband that had charisma... would that be an acceptable one to submit? > > Sincerely, > David Roguelike fan here. I think the sensible policy here is to stick to the last software version that works. If the newer versions of the software don't work for you there is no reason to upgrade unless there is a lot of demand from users. Seriously, they have a Dungeon Crawl version from before Dungeon Crawl Stone Soup and a _MORIA_ version in the OpenBSD port tree precisely because of this reason. I would argue that when the changes between versions are that big, it makes sense to have two versions of the same package in a software repository as long as there is interest on both. By the way, I am also a bit pissed off by the fact many classig roguelikes are getting upgraded and changed beyond recognition... -- OpenPGP Key Fingerprint: BB5A C2A2 2CAD ACB7 D50D C081 1DB9 6FC4 5AB7 92FA From rshepard at appl-ecosys.com Mon Mar 8 15:23:43 2021 From: rshepard at appl-ecosys.com (Rich Shepard) Date: Mon, 8 Mar 2021 07:23:43 -0800 (PST) Subject: [Slackbuilds-users] Pitivi: now crashes loading file Message-ID: I had pitivi-0.95-x86_64-3_SBo running last Friday with two files loaded. It constantly had ~50% CPU usage even sitting there and would take minutes to react to a mouse click or keyboard entry. This morning I started it and tried loading a .mp4 file. Each time the application crashed. I'm not sure where to find a file with information about crashing. There's no maillist or web forum for pitivi, but there is an IRC channel for it. Would that be the appropriate place to seek help in resolving both today's crashes and Friday's high CPU usage (on an 8-core Ryzen7) and long delays responding to actions? TIA, Rich From rshepard at appl-ecosys.com Mon Mar 8 16:21:12 2021 From: rshepard at appl-ecosys.com (Rich Shepard) Date: Mon, 8 Mar 2021 08:21:12 -0800 (PST) Subject: [Slackbuilds-users] Pitivi: now crashes loading file [RESOLVED] In-Reply-To: References: Message-ID: On Mon, 8 Mar 2021, Rich Shepard wrote: > This morning I started it and tried loading a .mp4 file. Each time the > application crashed. I'm not sure where to find a file with information > about crashing. This issue's been resolved. I restored the .mkv clips and loaded them. It must be that pitivi doesn't like working with .mp4 clips. That'll work for me. And so far the CPU usage is near zero because I'm writing this message and not working with pitivi. Rich From didier at slint.fr Mon Mar 8 16:21:45 2021 From: didier at slint.fr (Didier Spaier) Date: Mon, 8 Mar 2021 17:21:45 +0100 Subject: [Slackbuilds-users] Pitivi: now crashes loading file In-Reply-To: References: Message-ID: Le 08/03/2021 ? 16:23, Rich Shepard a ?crit?: > There's no maillist or web forum for pitivi, but there is an IRC channel > for > it. Would that be the appropriate place to seek help in resolving both > today's crashes and Friday's high CPU usage (on an 8-core Ryzen7) and long > delays responding to actions? Yes. From rshepard at appl-ecosys.com Mon Mar 8 16:44:16 2021 From: rshepard at appl-ecosys.com (Rich Shepard) Date: Mon, 8 Mar 2021 08:44:16 -0800 (PST) Subject: [Slackbuilds-users] Pitivi: now crashes loading file In-Reply-To: References: Message-ID: On Mon, 8 Mar 2021, Didier Spaier wrote: > Yes. Thought so, Didier. Thanks for confirming, Rich From davidnchmelik at gmail.com Tue Mar 9 05:50:56 2021 From: davidnchmelik at gmail.com (David Chmelik) Date: Mon, 8 Mar 2021 21:50:56 -0800 Subject: [Slackbuilds-users] offering giving up two roguelike game SlackBuilds Message-ID: I'm leaning heavily towards giving up my Angband (angband) and Dungeon Crawl Stone Soup (DCSS, stone_soup) SlackBuilds.? In recent months/years the games changed too much for my taste, much different than what they were under the original maintainers (and at least Linley's Dungeon Crawl.)? It's on condition I could make an 'angband-retro' SlackBuild (before giving up angband or if I could be guaranteed to be able to do this one.)? I doubt I'd bother to do the same with DCSS nor make a Linley's one if it can even compile on n86_64, but if it can, that'd be an interesting one to have (or maybe older DCSS before they started removing character types and did tons of bizarre changes.) From yalhcru at gmail.com Tue Mar 9 09:18:01 2021 From: yalhcru at gmail.com (B Watson) Date: Tue, 9 Mar 2021 04:18:01 -0500 Subject: [Slackbuilds-users] Angband In-Reply-To: References: Message-ID: On 3/8/21, Rub?n Llorente via SlackBuilds-users wrote: > > I would argue that when the changes between versions are that big, it makes > sense to have two versions of the same package in a software repository as > long as there is interest on both. I've got gzdoom and gzdoom-legacy... in that case it's because the older version still works fine on low-spec systems (don't need OpenGL 3.0 or proprietary drivers, etc). Also love (the game engine) and 2 older versions (love-legacy072 and love-legacy080), because incompatible changes were made, games developed with the older versions won't run with the new. Sorta like python 2 vs. python 3. From phalange at komputermatrix.com Tue Mar 9 17:55:13 2021 From: phalange at komputermatrix.com (Andrew Payne) Date: Tue, 9 Mar 2021 12:55:13 -0500 (EST) Subject: [Slackbuilds-users] Proposal for build scripts In-Reply-To: References: Message-ID: I have a script here to do this. Like you, I don't use the automated tools, I just wanted to automate the download and checksum process, especially with sprawling dependency lists. https://github.com/afhpayne/slackutils On Fri, 5 Mar 2021, UpNort wrote: > Hi All, > > Proposal: SBo build scripts check locally for the downloaded sources and > validate the md5sum. > > I always hen-pecked my way through SBo to build the packages I want. Doable > on a single package basis. Now that I am trying to help test Current with at > least the packages I use, I notice some inefficiency at my end. > > The Current git clone (fork) does not contain the sources. That's ok and I > don't expect that, even with the parent SBo site. > > Yet when I copy a specific SBo package directory to a build environment, the > sources still do not exist locally. While the parent SBo site has links to > the sources, with the git clone I have to open the info file to find the > upstream location and manually download. > > Perhaps all SBo scripts could automate this. Before executing the tar command > verify the sources exist in $CWD. Use the info file to download as necessary. > Then validate the sources with md5sum from the info file. > > I realize third party packages automate this, but for people manually > installing SBo packages the modifications would save time and offer nominal > security. > > Just a thought. > > Thanks. > > P.S. I am not a member of 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/ > > From porting at use.startmail.com Wed Mar 10 12:50:02 2021 From: porting at use.startmail.com (=?ISO-8859-1?Q?Rub=E9n?= Llorente) Date: Wed, 10 Mar 2021 12:50:02 -0000 (UTC) Subject: [Slackbuilds-users] offering giving up two roguelike game SlackBuilds References: Message-ID: David Chmelik wrote: > I'm leaning heavily towards giving up my Angband (angband) and Dungeon > Crawl Stone Soup (DCSS, stone_soup) SlackBuilds.? In recent months/years > the games changed too much for my taste, much different than what they > were under the original maintainers (and at least Linley's Dungeon > Crawl.)? It's on condition I could make an 'angband-retro' SlackBuild > (before giving up angband or if I could be guaranteed to be able to do > this one.)? I doubt I'd bother to do the same with DCSS nor make a > Linley's one if it can even compile on n86_64, but if it can, that'd be > an interesting one to have (or maybe older DCSS before they started > removing character types and did tons of bizarre changes.) > > _______________________________________________ > 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/ > > Last stable Linley's Dungeon Crawl compiles on OpenBSD. It needs a lot of patches, though. If you are curious, check the OpenBSD port collection for how they do it. Such a pity with DCSS. I am not very interested in the really new stone_soup myself (you know, the one in which they have the Zot clock instead of food. And they removed the centaur. The freaking centaur is gone). If you were to freeze for a stone_soup version, which version would you settle for? I don't think an angband-legacy build is needed unless somebody has the intention of maintaining a build for newer angband versions. If there is interest and somebody willing to maintain a build for a new angband version, I say let him do it, and rename the current one to angband-legacy or angband-$version. Else just leave the current one where it is and just don't upgrade it - just keep ensuring it compiles fine and patch security issues if necessary. -- OpenPGP Key Fingerprint: BB5A C2A2 2CAD ACB7 D50D C081 1DB9 6FC4 5AB7 92FA From duncan_roe at optusnet.com.au Fri Mar 12 01:04:25 2021 From: duncan_roe at optusnet.com.au (Duncan Roe) Date: Fri, 12 Mar 2021 12:04:25 +1100 Subject: [Slackbuilds-users] QT5 documentation not building Message-ID: <20210312010425.GA26200@dimstar.local.net> Hi, I built and installed qt5-5.12.8 with examples. Later I tried to build with examples and documentation. This build failed at `make docs` with error > /tmp/SBo/qt-everywhere-src-5.12.8/qtbase/src/corelib/qdoc_wrapper.sh: line 12: /usr/lib64/qt5/bin/qdoc: No such file or directory If I had done this when qt5-5.9.8 was still installed then I wouldn't have noticed a problem because that rev did build qdoc. So it looks like a config problem in the SB for qt5-5.12.8. Cheers ... Duncan. From lenardrspencer at gmail.com Fri Mar 12 02:18:41 2021 From: lenardrspencer at gmail.com (Lenard Spencer) Date: Thu, 11 Mar 2021 21:18:41 -0500 Subject: [Slackbuilds-users] QT5 documentation not building In-Reply-To: <20210312010425.GA26200@dimstar.local.net> References: <20210312010425.GA26200@dimstar.local.net> Message-ID: You need the newer llvm package in /extra to build the docs. On Thu, Mar 11, 2021, 20:04 Duncan Roe wrote: > Hi, > > I built and installed qt5-5.12.8 with examples. > > Later I tried to build with examples and documentation. This build failed > at > `make docs` with error > > /tmp/SBo/qt-everywhere-src-5.12.8/qtbase/src/corelib/qdoc_wrapper.sh: > line 12: /usr/lib64/qt5/bin/qdoc: No such file or directory > > If I had done this when qt5-5.9.8 was still installed then I wouldn't have > noticed a problem because that rev did build qdoc. > > So it looks like a config problem in the SB for qt5-5.12.8. > > Cheers ... Duncan. > _______________________________________________ > 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 duncan_roe at optusnet.com.au Fri Mar 12 23:36:23 2021 From: duncan_roe at optusnet.com.au (Duncan Roe) Date: Sat, 13 Mar 2021 10:36:23 +1100 Subject: [Slackbuilds-users] QT5 documentation not building In-Reply-To: References: <20210312010425.GA26200@dimstar.local.net> Message-ID: <20210312233623.GC26200@dimstar.local.net> That was it. I had an old llvm. Thanks ... Duncan. On Thu, Mar 11, 2021 at 09:18:41PM -0500, Lenard Spencer wrote: > You need the newer llvm package in /extra to build the docs. > > > On Thu, Mar 11, 2021, 20:04 Duncan Roe wrote: > > > Hi, > > > > I built and installed qt5-5.12.8 with examples. > > > > Later I tried to build with examples and documentation. This build failed > > at > > `make docs` with error > > > /tmp/SBo/qt-everywhere-src-5.12.8/qtbase/src/corelib/qdoc_wrapper.sh: > > line 12: /usr/lib64/qt5/bin/qdoc: No such file or directory > > > > If I had done this when qt5-5.9.8 was still installed then I wouldn't have > > noticed a problem because that rev did build qdoc. > > > > So it looks like a config problem in the SB for qt5-5.12.8. > > > > Cheers ... Duncan. > > _______________________________________________ > > SlackBuilds-users mailing list > > SlackBuilds-users at slackbuilds.org > > https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > > Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ > > FAQ - https://slackbuilds.org/faq/ > > > > > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - https://slackbuilds.org/faq/ > From willysr at slackbuilds.org Sat Mar 13 02:26:31 2021 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sat, 13 Mar 2021 09:26:31 +0700 Subject: [Slackbuilds-users] Updates - 20210313.1 Message-ID: <14e4acb0-233c-c432-25ff-fc26025045ad@slackbuilds.org> Sat Mar 13 02:08:06 UTC 2021 academic/ngspice: KiCAD build fixes. development/ShellCheck-bin: Simplify ARCH kicker. development/dbeaver-ce: Updated for version 21.0.0. development/f2c: Fix VERSION. development/mongodb-compass: Updated for version 1.26.0. development/postman: Updated for version 8.0.7 development/robotframework: Updated for version 4.0. development/sbcl: Updated for version 2.1.2. development/tig: Updated for version 2.5.3. development/vscode-bin: Updated for version 1.54.2. games/endless-sky: allows for building on both -current and -14.2 graphics/gscan2pdf: Fix DEP. graphics/vuescan: Updated for version 9.7.50. libraries/dumb: build both static and shared libraries libraries/ntl: Updated for version 11.4.4. libraries/skalibs: Updated for version 2.10.0.2. multimedia/plexmediaserver: Updated for 1.22.0.4163_d8c4875dd. network/AdGuardHome: Updated for version 0.105.2. network/qutebrowser-tox: Updated for version 2.1.0. network/qutebrowser: Updated for version 2.1.0. network/wireshark: Updated for version 3.4.4. office/calibre-bin: Updated for version 5.13.0. python/defusedxml: Updated for version 0.7.1. python/python-mysql-replication: Updated for version 0.23. python/python-precis-i18n: Updated for version 1.0.3. python/python3-astroid: Updated for version 2.5.1. python/python3-pylint: Updated for version 2.7.2. ruby/ruby-build: Updated for version 20210309. system/Iosevka-slab: Updated for version 5.0.5. system/Iosevka: Updated for version 5.0.5. system/execline: Updated for version 2.8.0.0. system/jenkins: Updated for version 2.277.1. system/opendoas: Added (port of doas from OpenBSD) system/rEFInd: Updated for version 0.13.1 system/refind: Updated for version 0.13.1 system/s6-linux-init: Updated for version 1.0.6.1. system/s6: Updated for version 2.10.0.2. +--------------------------+ -- Willy Sudiarto Raharjo -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From brent at exitstatusone.com Tue Mar 16 14:35:08 2021 From: brent at exitstatusone.com (Brent Earl) Date: Tue, 16 Mar 2021 08:35:08 -0600 Subject: [Slackbuilds-users] Cannot build lua, many other scripts on arm and arm64 Message-ID: I noticed an issue with the lua SlackBuild that is actually wide spread on SBo. As an example, lua will not build without adding to the script. Build failure: gcc -DLUA_USE_LINUX -c -o ldblib.o ldblib.c gcc -DLUA_USE_LINUX -c -o liolib.o liolib.c In file included from /usr/include/bits/errno.h:26, from /usr/include/errno.h:28, from lauxlib.c:9: /usr/include/linux/errno.h:1:10: fatal error: asm/errno.h: No such file or directory 1 | #include | ^~~~~~~~~~~~~ compilation terminated. make[2]: *** [: lauxlib.o] Error 1 make[2]: *** Waiting for unfinished jobs.... In file included from /usr/include/bits/errno.h:26, from /usr/include/errno.h:28, from liolib.c:8: /usr/include/linux/errno.h:1:10: fatal error: asm/errno.h: No such file or directory 1 | #include | ^~~~~~~~~~~~~ compilation terminated. make[2]: *** [: liolib.o] Error 1 make[2]: Leaving directory '/tmp/SBo/lua-5.1.5/src' make[1]: *** [Makefile:99: linux] Error 2 make[1]: Leaving directory '/tmp/SBo/lua-5.1.5/src' make: *** [Makefile:56: linux] Error 2 Changing the following in the SlackBuild fixes it for ARM and ARM64: --- lua.SlackBuild.orig 2021-03-15 22:24:45.560902023 -0600 +++ lua.SlackBuild 2021-03-16 08:20:55.529113247 -0600 @@ -38,6 +38,15 @@ elif [ "$ARCH" = "x86_64" ]; then SLKCFLAGS="-O2 -fPIC" LIBDIRSUFFIX="64" +elif [ "$ARCH" = "armv7hl" ]; then + SLKCFLAGS="-O2 -march=armv7-a -mfpu=vfpv3-d16" + LIBDIRSUFFIX="" +elif [ "$ARCH" = "aarch64" ]; then + SLKCFLAGS="-O2 -fPIC" + LIBDIRSUFFIX="64" +else + SLKCFLAGS="-O2" + LIBDIRSUFFIX="" fi set -e This brought on a larger concern I have about SBo as a whole. Will ARM and soon ARM64 continue to be unsupported by SBo? Both are official ports of Slackware and should have at least some basic support. More and more systems will use these architectures due to the increased hardware performance. ARM is not an isolated issue anymore and it stunts the ports if SBo is too difficult to use on the platforms. Best Regards, Brent -------------- next part -------------- An HTML attachment was scrubbed... URL: From yalhcru at gmail.com Tue Mar 16 19:02:38 2021 From: yalhcru at gmail.com (B Watson) Date: Tue, 16 Mar 2021 15:02:38 -0400 Subject: [Slackbuilds-users] Cannot build lua, many other scripts on arm and arm64 In-Reply-To: References: Message-ID: This email got longer than expected. Please bear with me... On 3/16/21, Brent Earl wrote: > gcc -DLUA_USE_LINUX -c -o liolib.o liolib.c > In file included from /usr/include/bits/errno.h:26, > from /usr/include/errno.h:28, > from lauxlib.c:9: > /usr/include/linux/errno.h:1:10: fatal error: asm/errno.h: No such file or > directory > 1 | #include > | ^~~~~~~~~~~~~ Generally that error is caused by a missing symlink. /usr/include/asm is supposed to be a symlink to asm-, e.g. asm-x86. The symlink is part of the kernel-headers package, as is the asm- dir. > +elif [ "$ARCH" = "armv7hl" ]; then > + SLKCFLAGS="-O2 -march=armv7-a -mfpu=vfpv3-d16" > + LIBDIRSUFFIX="" > +elif [ "$ARCH" = "aarch64" ]; then > + SLKCFLAGS="-O2 -fPIC" > + LIBDIRSUFFIX="64" I know what these CFLAGS do, and I agree they're useful (and LIBDIRSUFFIX=64 is necessary) for arm/arm64... but I don't see how they fix the error you were having above (missing asm/errno.h would still be missing). There's more to this story. > This brought on a larger concern I have about SBo as a whole. Will ARM and > soon ARM64 continue to be unsupported by SBo? Both are official ports of > Slackware and should have at least some basic support. More and more > systems will use these architectures due to the increased hardware > performance. ARM is not an isolated issue anymore and it stunts the ports > if SBo is too difficult to use on the platforms. The main reason SBo builds aren't tested on arm/arm64 is that most of us apparently don't own or use arm hardware. At least, I don't, and I very rarely see discussion of arm stuff on the mailing list or IRC channel. Secondary reason is the extra work and time involved: a maintainer is already expected to test everything on two platforms (x86 and x86_64). Adding 2 more platforms doubles the test-build time (or worse than doubles, because most of us would be using qemu or some other ARM emulator). The SBo admins and maintainers are unpaid volunteers, and you may have noticed that we don't have a long list of policies and rules... I'd accept patches for my builds that fix ARM-specific problems, but I'm never going to buy a fast ARM box just to do test compiles on. The traditional way to work around that would be to use a fast x86_64 box and cross-compile the ARM stuff... but SlackBuilds aren't generally set up for cross compiles (try it sometime). I know raspberry pi machines are cheap... but looking at their specs, they're also pretty underpowered as far as compiling lots of software goes. All the above looks very negative... so here are some positive suggestions: We can and should add your SLKCFLAGS stuff to the template. When 15.0 gets released, we'll be doing a lot of 'housekeeping' stuff to the SBo repo to get it ready for 15. One of those things might be adding your SLKCFLAGS to all existing SlackBuilds (at least the ones that ain't "noarch"). Someone, or a team of someones, could volunteer to be the "ARM maintainer(s)". This would involve testing stuff, actively looking for problems, and sending patches to fix them. Whoever does this would ideally follow the weekly update emails and test-build everything that got upgraded. There's a way to set up distccd to work with a cross-compiler. This would let people run builds on a little raspberry pi and offload the actual compilation to one or more bigger/faster machines. Unlike regular cross compiles, this is 'transparent'. I've done this, ages ago (though not for ARM). I could write a HOWTO specifically for SBo and ARM, so people could set up "compile servers" to speed things up. From brent at exitstatusone.com Tue Mar 16 20:03:59 2021 From: brent at exitstatusone.com (Brent Earl) Date: Tue, 16 Mar 2021 14:03:59 -0600 Subject: [Slackbuilds-users] Cannot build lua, many other scripts on arm and arm64 In-Reply-To: References: Message-ID: Hello, I appreciate your reply and the time you took to write it. :) The build completes when LIBDIRSUFFIX is set to "64". I should have clarified about that, apologies. The patch is meant more as a way to sort of fix builds for aarch64 in SBo in general. Arm32 works with most SlackBuilds, sometimes with other modifications. But aarch64 will not work if the _else_ portion of the _if_ statement is missing at the end. In the case of lua, the SlackBuild didn't check for the aarch64 architecture. It skips it because it doesn't know about it. The script continues, assumes $( uname -m ) and doesn't set any SLCKFLAGS for aarch64. The kernel headers are installed on the system and are not the problem. The problem is that the script assumes "libaarch64" instead of "lib64." I hadn't planned on setting up a build infrastructure to test build all of SBo for Slackware ARM. I wasn't looking to start the huge project of porting all of SBo to arm or aarch64. Anyway, there is already documentation on cross compiling with distcc on docs.slackware.com for ARM. All that would be required is integrating a tool (sbopkg as an example) into a cross compiler for SBo. Maybe, modify Stuart Winter's "x-toolchain" from the "slackwarearm-devtools" directory to do so. To clarify further, an expensive ARM build server is not necessary. Off-load to other devices on the network with distcc. Anyone with a large SBo build for x86/x64 (Qt, I am looking at you) should already be doing this anyway. Best regards, Brent On Tue, Mar 16, 2021 at 1:02 PM B Watson wrote: > This email got longer than expected. Please bear with me... > > On 3/16/21, Brent Earl wrote: > > gcc -DLUA_USE_LINUX -c -o liolib.o liolib.c > > In file included from /usr/include/bits/errno.h:26, > > from /usr/include/errno.h:28, > > from lauxlib.c:9: > > /usr/include/linux/errno.h:1:10: fatal error: asm/errno.h: No such file > or > > directory > > 1 | #include > > | ^~~~~~~~~~~~~ > > Generally that error is caused by a missing symlink. /usr/include/asm > is supposed to be a symlink to asm-, e.g. asm-x86. The symlink > is part of the kernel-headers package, as is the asm- dir. > > > +elif [ "$ARCH" = "armv7hl" ]; then > > + SLKCFLAGS="-O2 -march=armv7-a -mfpu=vfpv3-d16" > > + LIBDIRSUFFIX="" > > +elif [ "$ARCH" = "aarch64" ]; then > > + SLKCFLAGS="-O2 -fPIC" > > + LIBDIRSUFFIX="64" > > I know what these CFLAGS do, and I agree they're useful (and > LIBDIRSUFFIX=64 is necessary) for arm/arm64... but I don't see how > they fix the error you were having above (missing asm/errno.h would > still be missing). There's more to this story. > > > This brought on a larger concern I have about SBo as a whole. Will ARM > and > > soon ARM64 continue to be unsupported by SBo? Both are official ports of > > Slackware and should have at least some basic support. More and more > > systems will use these architectures due to the increased hardware > > performance. ARM is not an isolated issue anymore and it stunts the > ports > > if SBo is too difficult to use on the platforms. > > The main reason SBo builds aren't tested on arm/arm64 is that most > of us apparently don't own or use arm hardware. At least, I don't, > and I very rarely see discussion of arm stuff on the mailing list or > IRC channel. > > Secondary reason is the extra work and time involved: a maintainer > is already expected to test everything on two platforms (x86 and > x86_64). Adding 2 more platforms doubles the test-build time (or worse > than doubles, because most of us would be using qemu or some other > ARM emulator). The SBo admins and maintainers are unpaid volunteers, > and you may have noticed that we don't have a long list of policies > and rules... > > I'd accept patches for my builds that fix ARM-specific problems, but > I'm never going to buy a fast ARM box just to do test compiles on. The > traditional way to work around that would be to use a fast x86_64 box > and cross-compile the ARM stuff... but SlackBuilds aren't generally > set up for cross compiles (try it sometime). > > I know raspberry pi machines are cheap... but looking at their specs, > they're also pretty underpowered as far as compiling lots of software > goes. > > All the above looks very negative... so here are some positive > suggestions: > > We can and should add your SLKCFLAGS stuff to the template. When 15.0 > gets released, we'll be doing a lot of 'housekeeping' stuff to the SBo > repo to get it ready for 15. One of those things might be adding your > SLKCFLAGS to all existing SlackBuilds (at least the ones that ain't > "noarch"). > > Someone, or a team of someones, could volunteer to be the "ARM > maintainer(s)". This would involve testing stuff, actively looking > for problems, and sending patches to fix them. Whoever does this would > ideally follow the weekly update emails and test-build everything that > got upgraded. > > There's a way to set up distccd to work with a cross-compiler. This > would let people run builds on a little raspberry pi and offload > the actual compilation to one or more bigger/faster machines. Unlike > regular cross compiles, this is 'transparent'. I've done this, ages > ago (though not for ARM). I could write a HOWTO specifically for SBo > and ARM, so people could set up "compile servers" to speed things up. > _______________________________________________ > 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 sborg63 at disroot.org Wed Mar 17 14:05:04 2021 From: sborg63 at disroot.org (sborg63) Date: Wed, 17 Mar 2021 14:05:04 +0000 Subject: [Slackbuilds-users] Updates - 20210313.1 SlackBuilds-users Digest, Vol 179, Issue 5 In-Reply-To: References: Message-ID: <20210317140504.20d5bebc@knotsUL> On Tue, 16 Mar 2021 20:04:14 +0000 slackbuilds-users-request at slackbuilds.org wrote: .. > system/opendoas: Added (port of doas from OpenBSD) > system/rEFInd: Updated for version 0.13.1 > system/refind: Updated for version 0.13.1 > system/s6-linux-init: Updated for version 1.0.6.1. > system/s6: Updated for version 2.10.0.2. > +--------------------------+ > > Hi this version of refind (0.13.1) does not build on current. The latest (0.13.2) does... hth Rob From yalhcru at gmail.com Wed Mar 17 19:48:16 2021 From: yalhcru at gmail.com (B Watson) Date: Wed, 17 Mar 2021 15:48:16 -0400 Subject: [Slackbuilds-users] Updates - 20210313.1 SlackBuilds-users Digest, Vol 179, Issue 5 In-Reply-To: <20210317140504.20d5bebc@knotsUL> References: <20210317140504.20d5bebc@knotsUL> Message-ID: On 3/17/21, sborg63 via SlackBuilds-users wrote: > Hi this version of refind (0.13.1) does not build on current. The > latest (0.13.2) does... We don't actually support -current. Look in ponce's unofficial -current repo to see if there's a patch for it: https://github.com/Ponce/slackbuilds/ From kingbeowulf at gmail.com Wed Mar 17 20:28:23 2021 From: kingbeowulf at gmail.com (King Beowulf) Date: Wed, 17 Mar 2021 13:28:23 -0700 Subject: [Slackbuilds-users] Updates - 20210313.1 SlackBuilds-users Digest, Vol 179, Issue 5 In-Reply-To: References: <20210317140504.20d5bebc@knotsUL> Message-ID: On 3/17/21 12:48 PM, B Watson wrote: > On 3/17/21, sborg63 via SlackBuilds-users > wrote: > >> Hi this version of refind (0.13.1) does not build on current. The >> latest (0.13.2) does... > > We don't actually support -current. Look in ponce's unofficial -current > repo to see if there's a patch for it: > > https://github.com/Ponce/slackbuilds/ > _______________________________________________ > 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/ > There is also a report thread on Linuxquestions.org to search and see if already fixed. -Ed -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From arnaud.garcia-fernandez at laposte.net Wed Mar 17 22:32:30 2021 From: arnaud.garcia-fernandez at laposte.net (Arnaud) Date: Wed, 17 Mar 2021 23:32:30 +0100 Subject: [Slackbuilds-users] Allegro 5 and slackware-14.2 Message-ID: <20210317233230.6bb6571b2590b651fb7cc6e0@laposte.net> Hello everybody, Allegro 5.2.7.0 does not build on slackware 14.2 because one of its internal addons (native_dialog) uses gtk3, and 14.2 gtk3 version is too old. There are two ways I can go with this : - conservatism, by sticking to 5.2.6.0 until slackware 15.0 is out. - I-don't-care-ism, by disabling this particular addon. I have no idea what would be the impact of disabling this addon for other slackbuilds, and I don't feel this question warrants more than a passing thought. The middleground I choose is to add a build option to allow for disabling this addon. Then anybody can do a simple version bump to allegro 5.2.7.0. It's an easy enough workaround while waiting for slackware-15.0. So if you don't care, don't change anything. But if you want allegro 5.2.7.0, then build it that way for slackware-14.2 : VERSION=2.5.7.0 ALLEGRO_NATIVE_DIALOG=off ./allegro.Slackbuild And that way for slackware-current : VERSION=2.5.7.0 ./allegro.Slackbuild It's all written in the README, and will be available in the next update. Best regards! - Arnaud. From milgram at cgpp.com Thu Mar 18 15:29:57 2021 From: milgram at cgpp.com (Judah Milgram) Date: Thu, 18 Mar 2021 11:29:57 -0400 Subject: [Slackbuilds-users] Maxima and wxMaxima Message-ID: 1) The wxMaxima package needs to be updated for v16 -> v21. The maintainer hasn't responded to email after a few weeks but if need be I'm willing to take it over. Already have a package ready to go for v21. 2) Earlier, as the Maxima maintainer didn't respond after a couple of months, I volunteered to take it over and got the go-ahead from the SBo leads. Am trying to upload a new package (for v5.44) but no luck - getting "File exists" This is probably from an earlier attempt of my own from a couple of weeks ago. It's not in the pending or ready queues. Is there something I'm doing wrong here? thanks Judah -- Judah Milgram milgram at cgpp.com 301-257-7069 From willysr at slackbuilds.org Sat Mar 20 04:11:12 2021 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sat, 20 Mar 2021 11:11:12 +0700 Subject: [Slackbuilds-users] Updates - 20210320.1 Message-ID: <9037b353-432e-8506-fbd0-eef07b96160e@slackbuilds.org> Sat Mar 20 04:01:39 UTC 2021 academic/Gridcoin-Research: Updated for version 5.3.0.0 academic/fet: Updated for version 5.49.1. academic/maxima: Updated for version 5.44.0. audio/cmus: Updated for version 2.9.1. audio/jack: Updated for version 1.9.17. audio/mda-lv2: Updated for version 1.2.6. audio/qjackctl: Updated for version 0.9.1. development/CImg: Updated for version 2.9.6 development/cc65: Updated for version 2.19. development/cmake-202x: Updated for version 3.19.6. development/codelite: Updated for version 15.0. development/dwz: Updated for version 0.14. development/hugo: Updated for version 0.81.0. development/octant: Updated for version 0.17.0. development/valgrind: Updated for version 3.17.0. development/vscode-bin: Updated for version 1.54.3. development/vscodium: Added (Visual Studio Code FOSS Binary Release) games/commandergenius: Updated for version 2.7.7. games/domination: Updated for version 1.2.3. games/freedink: Update REQUIRES. games/innoextract: Updated for version 1.9 graphics/mozjpeg: Updated for version 4.0.3. graphics/vuescan: Updated for version 9.7.51. libraries/allegro: Build option to allow disabling native_dialog (gtk3) addon libraries/bullet: Updated for version 3.09. libraries/cryptopp: Updated for version 8.5.0. libraries/uriparser: Updated for version 0.9.5. libraries/wayland: Updated for version 1.19.0. multimedia/LBRY: Updated for version 0.50.1. multimedia/MediathekView: Updated for version 13.7.1. network/brave-browser: Updated for version 1.21.77. network/fdns: Added (Firejail DNS-over-HTTPS Proxy Server) network/munge: Updated for version 0.5.14. network/prettyping: Added (Ping wrapper) network/protonmail-bridge: Updated for version 1.6.6. network/qbittorrent: Updated for version 4.3.1. network/qutebrowser: Add adblock notes to README. network/sfeed: Updated for version 0.9.22. network/slurm: Updated for version 20.11.4. network/telegram: Updated for version 2.7.0. network/tor: Updated for version 0.4.5.7. network/varnish: Updated for version 6.5.1. network/wire: Updated for version 3.23.2938. network/wireguard-tools: Updated for version 1.0.20210315. office/MasterPDFEditor: Updated for version 5.7.40. office/onlyoffice-desktopeditors: Updated for version 6.2.0. office/pdfstudio: Updated for version 2020.4.0. office/pdfstudioviewer: Updated for version 2020.4.0. perl/nqp: Fix download URL. perl/rakudo: Fix download URL. python/josepy: Updated for version 1.8.0. python/python-mysql-replication: Fix package documentation. python/python3-aiorpcX: Updated for version 0.21.0. system/aide: Updated for version 0.17.3. system/chkrootkit: Updated for version 0.54. system/epson-inkjet-printer-escpr2: Updated for version 1.1.29. system/fzf: Updated for version 0.26.0. system/man-db: Updated for version 2.9.4. system/modules: Updated for version 4.7.0. system/monitorix: Updated for version 3.13.1. system/mpack: Updated upstream URL. system/nvidia-driver: Updated for version 460.67. system/nvidia-kernel: Updated for version 460.67. system/openmpi: Updated for version 4.1.0. system/osquery-bin: Updated for version 4.7.0. system/prometheus: Updated for version 2.25.2 system/rox-filer: Patch added. system/system76-power: Updated for version 1.1.16. system/telegraf: Updated for version 1.18.0 system/usermin: Updated for version 1.823. system/webmin: Updated for version 1.973. system/xarchiver: Updated for version 0.5.4.17 +--------------------------+ -- Willy Sudiarto Raharjo -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From ricardo at palmtx.com.ar Sun Mar 21 16:46:01 2021 From: ricardo at palmtx.com.ar (Ricardo J. Barberis) Date: Sun, 21 Mar 2021 13:46:01 -0300 Subject: [Slackbuilds-users] Heads-up: rdiff-backup update to 2.0.5 - Incompatible with 1.2.8 Message-ID: Hello all! A few days ago I was asked to update rdiff-backup from 1.2.8 to 2.0.5, but this two versions are incompatible if used remotely (e.g., via ssh) so you have to keep both client and server at the same version. For local backups (e.g. to an external disk) there's no problem. I have added a note and a pointer to the docs. I also took the opportunity to update librsync to 2.3.0 (2.3.1 doesn't compile on Slackware 14.2 due to a too old cmake version). This one should be compatible with librsync 0.9.7 but there's a .so version bump so a recompile is needed. I'll send a sepparate e-mail about this. Lastly, since rdiff-backup has pylibacl and pyxattr as optional dependencies I have prepared slackbuilds for them. I'll probably upload them beforehand. Since this changes are somewhat invasive, I'd like to ask opinions before submitting my updates to SBo: Should I submit them or should I wait for Slackware 15.0 instead? If I send my changes now there's really no need for people to update right away, but I don't want to catch anyone with their guard down :) In the meantime, if anybody wants to test rdiff-backup 2.0.5, the new slackbuilds are in my github repo: https://github.com/richarson/slackbuilds/tree/master/14.2/librsync https://github.com/richarson/slackbuilds/tree/master/14.2/pylibacl https://github.com/richarson/slackbuilds/tree/master/14.2/pyxattr https://github.com/richarson/slackbuilds/tree/master/14.2/rdiff-backup Cheers, -- Living la vida Linux! From ricardo at palmtx.com.ar Sun Mar 21 16:56:56 2021 From: ricardo at palmtx.com.ar (Ricardo J. Barberis) Date: Sun, 21 Mar 2021 13:56:56 -0300 Subject: [Slackbuilds-users] Heads-up: librsync update to 2.3.0 - .so version bump Message-ID: Hello all! As I in my other e-mail, I'm planing to update librsync 2.3.0 (2.3.1 doesn't compile on Slackware 14.2 due to a too old cmake version), which should be compatible with librsync 0.9.7 but there's a .so version bump. librsync is a required dependency of: - rdiff-backup - duplicity - burp I maintain rdiff-backup and have tested upgrading librsync an reinstalling rdiff-backup, everything seems to work fine. I e-mailed the maintainers of duplicity and burp on 2021-03-17 to let them know, no answer so far. I also installed duplicity and successfully ran some basic tests (syncying two local directories). For burp I just recompiled it against librsync 2.3.0 and made sure it started, but I don't know haow to test its funcionallity. If someone who uses duplicity and/or cloud make (or suggest me) some more tests to make it's be really appreciated. Since this change is somewhat invasive, I'd like to ask opinions before submitting to SBo: Should I submit them now or should I wait for Slackware 15.0 instead? If I send my changes now there's really no need for people to update right away, but I don't want to catch anyone with their guard down :) In the meantime, if anybody wants to test duplicity or burp against librsync 2.3.0, the new slackbuilds are in my github repo: https://github.com/richarson/slackbuilds/tree/master/14.2/librsync Cheers, -- Living la vida Linux! From yalhcru at gmail.com Sun Mar 21 18:01:55 2021 From: yalhcru at gmail.com (B Watson) Date: Sun, 21 Mar 2021 14:01:55 -0400 Subject: [Slackbuilds-users] Heads-up: rdiff-backup update to 2.0.5 - Incompatible with 1.2.8 In-Reply-To: References: Message-ID: On 3/21/21, Ricardo J. Barberis wrote: > Hello all! > > A few days ago I was asked to update rdiff-backup from 1.2.8 to 2.0.5, > but this two versions are incompatible if used remotely (e.g., via ssh) > so you have to keep both client and server at the same version. > > Since this changes are somewhat invasive, I'd like to ask opinions > before submitting my updates to SBo: I never used rdiff-backup or even heard of it, so I don't know the answer to this: Are there going to be enough people who won't/can't upgrade (e.g. due to corporate policy) that will be stuck with servers running the old version? If that's real concern, you could provide a rdiff-backup-legacy-client build. Just the client of the 1.2.8 version, with a different filename (so it doesn't conflict with the regular 2.0.5 build). That way people who use rdiff-backup with multiple remotes will be able to keep working with all of them, instead of being stuck with half the remotes running 1.x and half running 2.x. > Should I submit them or should I wait for Slackware 15.0 instead? If you actually do decide to provide a 1.2.8 client-only build, I don't see a reason not to go ahead and do it. From yalhcru at gmail.com Sun Mar 21 18:04:48 2021 From: yalhcru at gmail.com (B Watson) Date: Sun, 21 Mar 2021 14:04:48 -0400 Subject: [Slackbuilds-users] Heads-up: librsync update to 2.3.0 - .so version bump In-Reply-To: References: Message-ID: On 3/21/21, Ricardo J. Barberis wrote: > As I in my other e-mail, I'm planing to update librsync 2.3.0 (2.3.1 > doesn't compile on Slackware 14.2 due to a too old cmake version) There's a much newer cmake available on SBo, called cmake-202x. It doesn't replace or conflict with Slackware's cmake. See: https://slackbuilds.org/slackbuilds/14.2/development/cmake-202x/README_SBo.txt From ricardo at palmtx.com.ar Sun Mar 21 19:00:09 2021 From: ricardo at palmtx.com.ar (Ricardo J. Barberis) Date: Sun, 21 Mar 2021 16:00:09 -0300 Subject: [Slackbuilds-users] Heads-up: librsync update to 2.3.0 - .so version bump In-Reply-To: References: Message-ID: <703ef38f6fddb43ac8fd3561f7d00a50@palmtx.com.ar> El 2021/03/21 15:04, B Watson escribi?: > On 3/21/21, Ricardo J. Barberis wrote: > >> As I in my other e-mail, I'm planing to update librsync 2.3.0 (2.3.1 >> doesn't compile on Slackware 14.2 due to a too old cmake version) > > There's a much newer cmake available on SBo, called cmake-202x. It > doesn't replace or conflict with Slackware's cmake. > > See: > https://slackbuilds.org/slackbuilds/14.2/development/cmake-202x/README_SBo.txt Oh, I hadn't thought of checking SBo for a newer cmake. I'm hesitant to add another dependency but I'll keep it in mind, thanks for the pointer anyway! Cheers, -- Living la vida Linux! From ricardo at palmtx.com.ar Sun Mar 21 19:13:08 2021 From: ricardo at palmtx.com.ar (Ricardo J. Barberis) Date: Sun, 21 Mar 2021 16:13:08 -0300 Subject: [Slackbuilds-users] Heads-up: rdiff-backup update to 2.0.5 - Incompatible with 1.2.8 In-Reply-To: References: Message-ID: El 2021/03/21 15:01, B Watson escribi?: > On 3/21/21, Ricardo J. Barberis wrote: >> Hello all! >> >> A few days ago I was asked to update rdiff-backup from 1.2.8 to 2.0.5, >> but this two versions are incompatible if used remotely (e.g., via >> ssh) >> so you have to keep both client and server at the same version. >> >> Since this changes are somewhat invasive, I'd like to ask opinions >> before submitting my updates to SBo: > > I never used rdiff-backup or even heard of it, so I don't know the > answer to this: Are there going to be enough people who won't/can't > upgrade (e.g. due to corporate policy) that will be stuck with servers > running the old version? I'm not sure, I've been its maintainer for a very short time only. Let's see what other people on the list say about this :) From what I gather at repology.org most of the newer distros (like Fedora, Arch and even CentOS/EPEL 7/8 and Windows!) are already on 2.x but others like openSUSE 15.2/15.3, Debian stable and Ubuntu 18.04 are on 1.x still. > If that's real concern, you could provide a rdiff-backup-legacy-client > build. Just the client of the 1.2.8 version, with a different filename > (so it doesn't conflict with the regular 2.0.5 build). > > That way people who use rdiff-backup with multiple remotes will be > able to keep working with all of them, instead of being stuck with > half the remotes running 1.x and half running 2.x. There is no client/server separation, it's the same "binary", but making a "-legacy" package would be no problem as both versions can work with librsync 0.9.7 or 2.3.0 (so I could even postpone librsync's update). >> Should I submit them or should I wait for Slackware 15.0 instead? > > If you actually do decide to provide a 1.2.8 client-only build, > I don't see a reason not to go ahead and do it. Thank you so much for your input! -- Living la vida Linux! From rshepard at appl-ecosys.com Sun Mar 21 19:25:09 2021 From: rshepard at appl-ecosys.com (Rich Shepard) Date: Sun, 21 Mar 2021 12:25:09 -0700 (PDT) Subject: [Slackbuilds-users] Heads-up: rdiff-backup update to 2.0.5 - Incompatible with 1.2.8 In-Reply-To: References: Message-ID: On Sun, 21 Mar 2021, Ricardo J. Barberis wrote: > I'm not sure, I've been its maintainer for a very short time only. > Let's see what other people on the list say about this :) Ricardo, I've been using dirvish for more than 20 years. It's based on rsync and Just Works(TM). Looking at your rdiff-backup page it does the same thing as dirvish. So I'm one Slacker who has no need for rdiff-backup. HTH, Rich From ricardo at palmtx.com.ar Sun Mar 21 22:33:58 2021 From: ricardo at palmtx.com.ar (Ricardo J. Barberis) Date: Sun, 21 Mar 2021 19:33:58 -0300 Subject: [Slackbuilds-users] Heads-up: rdiff-backup update to 2.0.5 - Incompatible with 1.2.8 In-Reply-To: References: Message-ID: <7ffd9a452d2244c77da6e68a69ae8540@palmtx.com.ar> El 2021/03/21 16:25, Rich Shepard escribi?: > On Sun, 21 Mar 2021, Ricardo J. Barberis wrote: > >> I'm not sure, I've been its maintainer for a very short time only. >> Let's see what other people on the list say about this :) > > Ricardo, > > I've been using dirvish for more than 20 > years. > It's based on rsync and Just Works(TM). Looking at your rdiff-backup > page it > does the same thing as dirvish. So I'm one Slacker who has no need for > rdiff-backup. > > HTH, > > Rich Hi Rich! I'm not gonna drop rdiff-backup, since I use it @home to backup my laptop to an USB drive and @work to backup remotely. It uses rsync's protocol but it keeps differential (a.k.a. "reverse incremental") backups instead of hard-linked copies. I'd like feedback from people actually using rdiff-backup to see if an upgrade to 2.0.5 will be too disruptive, or if a -legacy package is warranted. Thanks! -- Living la vida Linux! From dickson.tim at googlemail.com Mon Mar 22 20:01:34 2021 From: dickson.tim at googlemail.com (Tim Dickson) Date: Mon, 22 Mar 2021 20:01:34 +0000 Subject: [Slackbuilds-users] fop source issue In-Reply-To: <7ffd9a452d2244c77da6e68a69ae8540@palmtx.com.ar> References: <7ffd9a452d2244c77da6e68a69ae8540@palmtx.com.ar> Message-ID: <91dc97a7-2f5a-5bc8-b6f3-dcdcdd6ad400@googlemail.com> The source for fop seems to be down. or at least fontbox is 404'ing it looks like it has been replaced with fontbox-2.0.23.jar this also applies to pdfbox-2.0.23 also used by fop. changing the fop.info file as below, gets everything working. DOWNLOAD="https://archive.apache.org/dist/xmlgraphics/fop/source/fop-2.6-src.tar.gz \ http://mirror.reverse.net/pub/apache/pdfbox/2.0.23/fontbox-2.0.23.jar \ http://mirror.reverse.net/pub/apache/pdfbox/2.0.23/pdfbox-2.0.23.jar \ https://downloads.sourceforge.net/offo/2.2/offo-hyphenation.zip" MD5SUM="1d6bc84d2ab7f971bbc628080e3c307f \ ??????? f9aa90c666c88ff29e3cd34c15d538ca \ ??????? 6b71c42c567d419f068f46f410dcc3a5 \ ??????? bf9c09bf05108ef9661b8f08d91c2336" regards, Tim -- This email has been checked for viruses by AVG. https://www.avg.com From lenardrspencer at gmail.com Mon Mar 22 20:15:23 2021 From: lenardrspencer at gmail.com (Lenard Spencer) Date: Mon, 22 Mar 2021 16:15:23 -0400 Subject: [Slackbuilds-users] fop source issue In-Reply-To: <91dc97a7-2f5a-5bc8-b6f3-dcdcdd6ad400@googlemail.com> References: <7ffd9a452d2244c77da6e68a69ae8540@palmtx.com.ar> <91dc97a7-2f5a-5bc8-b6f3-dcdcdd6ad400@googlemail.com> Message-ID: Thanks. I'll submit an update. On Mon, Mar 22, 2021, 16:01 Tim Dickson via SlackBuilds-users < slackbuilds-users at slackbuilds.org> wrote: > The source for fop seems to be down. or at least fontbox is 404'ing it > looks like it has been replaced with fontbox-2.0.23.jar > this also applies to pdfbox-2.0.23 also used by fop. changing the > fop.info file as below, gets everything working. > > DOWNLOAD=" > https://archive.apache.org/dist/xmlgraphics/fop/source/fop-2.6-src.tar.gz > \ > http://mirror.reverse.net/pub/apache/pdfbox/2.0.23/fontbox-2.0.23.jar \ > http://mirror.reverse.net/pub/apache/pdfbox/2.0.23/pdfbox-2.0.23.jar \ > https://downloads.sourceforge.net/offo/2.2/offo-hyphenation.zip" > MD5SUM="1d6bc84d2ab7f971bbc628080e3c307f \ > f9aa90c666c88ff29e3cd34c15d538ca \ > 6b71c42c567d419f068f46f410dcc3a5 \ > bf9c09bf05108ef9661b8f08d91c2336" > > regards, Tim > > -- > This email has been checked for viruses by AVG. > https://www.avg.com > > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - https://slackbuilds.org/faq/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dickson.tim at googlemail.com Tue Mar 23 07:44:21 2021 From: dickson.tim at googlemail.com (Tim Dickson) Date: Tue, 23 Mar 2021 07:44:21 +0000 Subject: [Slackbuilds-users] openimageio with pybind11 issues Message-ID: <9eba4ecf-c6dd-66a6-a2a4-9919c153aef3@googlemail.com> has anyone had success building openimageio with the new pybind11? ? it is failing for me. it seems to be looking for pybind11 files in /usr/include/python2.7/pybind11? when the pybind11 package has the files in /usr/include/pybind11 regards, Tim -- This email has been checked for viruses by AVG. https://www.avg.com From chris.willing at linux.com Wed Mar 24 07:48:29 2021 From: chris.willing at linux.com (Christoph Willing) Date: Wed, 24 Mar 2021 17:48:29 +1000 Subject: [Slackbuilds-users] openimageio with pybind11 issues In-Reply-To: <9eba4ecf-c6dd-66a6-a2a4-9919c153aef3@googlemail.com> References: <9eba4ecf-c6dd-66a6-a2a4-9919c153aef3@googlemail.com> Message-ID: <3f8abbae-0d40-c58f-ecb1-aac027c312f2@linux.com> On 23/3/21 5:44 pm, Tim Dickson via SlackBuilds-users wrote: > has anyone had success building openimageio with the new pybind11? ? it > is failing for me. it seems to be looking for pybind11 files in > /usr/include/python2.7/pybind11? when the pybind11 package has the files > in /usr/include/pybind11 > I've held pybind11 at version at 2.5.0 - the latest that enables building of openimageio - however not for want of finding include files. With latest pybind11-2.6.2 configuration output says: -- pybind11 2.6.2, include dir: /usr/include i.e. include files are found OK. The error I see is after 92% has compiled: /var/tmp/SBo/oiio-Release-2.0.13/src/python/py_oiio.h:303:47: error: no matching function for call to 'cast(OpenImageIO_v2_0::span::element_type&)' I'm assuming this is due to new definitions in pybind11 which newer versions of openimageio will deal with. However newer versions of openimageio don't build in 14.2 so we're stuck with openimageio-2.0.13 and (therefore) pybind11-2.5.0. chris From dickson.tim at googlemail.com Wed Mar 24 08:55:10 2021 From: dickson.tim at googlemail.com (Tim Dickson) Date: Wed, 24 Mar 2021 08:55:10 +0000 Subject: [Slackbuilds-users] openimageio with pybind11 issues In-Reply-To: <3f8abbae-0d40-c58f-ecb1-aac027c312f2@linux.com> References: <9eba4ecf-c6dd-66a6-a2a4-9919c153aef3@googlemail.com> <3f8abbae-0d40-c58f-ecb1-aac027c312f2@linux.com> Message-ID: On 24/03/2021 07:48, Christoph Willing wrote: > On 23/3/21 5:44 pm, Tim Dickson via SlackBuilds-users wrote: >> has anyone had success building openimageio with the new pybind11? ? it >> is failing for me. it seems to be looking for pybind11 files in >> /usr/include/python2.7/pybind11? when the pybind11 package has the files >> in /usr/include/pybind11 >> > I've held pybind11 at version at 2.5.0 - the latest that enables > building of openimageio - however not for want of finding include files. > With latest pybind11-2.6.2 configuration output says: > -- pybind11 2.6.2, include dir: /usr/include > > i.e. include files are found OK. > > The error I see is after 92% has compiled: > /var/tmp/SBo/oiio-Release-2.0.13/src/python/py_oiio.h:303:47: error: > no matching function for call to 'cast(OpenImageIO_v2_0::span OpenImageIO_v2_0::TypeDesc, -1l>::element_type&)' > > I'm assuming this is due to new definitions in pybind11 which newer > versions of openimageio will deal with. However newer versions of > openimageio don't build in 14.2 so we're stuck with openimageio-2.0.13 > and (therefore) pybind11-2.5.0. > > chris > hmm. i'm using pybind11 2.5.0 all on slackware 14.2 (64bit) the errors i get with openimageio are.... -- robin-map include dir: /usr/include CMake Error at src/cmake/externalpackages.cmake:568 (file): ? file STRINGS file "/usr/include/python2.7/pybind11/common.h" cannot be ? read. Call Stack (most recent call first): ? CMakeLists.txt:206 (find_or_download_pybind11) CMake Error at src/cmake/externalpackages.cmake:570 (file): ? file STRINGS file "/usr/include/python2.7/pybind11/common.h" cannot be ? read. Call Stack (most recent call first): ? CMakeLists.txt:206 (find_or_download_pybind11) CMake Error at src/cmake/externalpackages.cmake:572 (file): ? file STRINGS file "/usr/include/python2.7/pybind11/common.h" cannot be ? read. Call Stack (most recent call first): ? CMakeLists.txt:206 (find_or_download_pybind11) -- pybind11 366.366.366, include dir: /usr/include/python2.7 CMake Error at /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:148 (message): ? Could NOT find PythonInterp: Found unsuitable version "2.7.17", but ? required is at least "3.7.2" (found /usr/bin/python2.7) Call Stack (most recent call first): /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:386 (_FPHSA_FAILURE_MESSAGE) ? /usr/share/cmake-3.5/Modules/FindPythonInterp.cmake:163 (FIND_PACKAGE_HANDLE_STANDARD_ARGS) ? src/python/CMakeLists.txt:4 (find_package) -- Configuring incomplete, errors occurred! See also "/tmp/SBo/oiio-Release-2.0.13/build/CMakeFiles/CMakeOutput.log". See also "/tmp/SBo/oiio-Release-2.0.13/build/CMakeFiles/CMakeError.log". looking at the CMakeEerror.log the complaint is that pthread_create does not exist. gcc is 5.5, the latest for 14.2 and in /usr/include/pthread is extern int pthread_create (pthread_t *__restrict __newthread, ?????????????????????????? const pthread_attr_t *__restrict __attr, ?????????????????????????? void *(*__start_routine) (void *), ?????????????????????????? void *__restrict __arg) __THROWNL __nonnull ((1, 3)); so there is at least a function declaration. the only thing in my setup/config I can think of that might be different is i'm using ffmpeg4 rather than ffmpeg3 regards, Tim -- This email has been checked for viruses by AVG. https://www.avg.com From chris.willing at linux.com Wed Mar 24 11:42:16 2021 From: chris.willing at linux.com (Christoph Willing) Date: Wed, 24 Mar 2021 21:42:16 +1000 Subject: [Slackbuilds-users] openimageio with pybind11 issues In-Reply-To: References: <9eba4ecf-c6dd-66a6-a2a4-9919c153aef3@googlemail.com> <3f8abbae-0d40-c58f-ecb1-aac027c312f2@linux.com> Message-ID: On 24/3/21 6:55 pm, Tim Dickson via SlackBuilds-users wrote: > > > On 24/03/2021 07:48, Christoph Willing wrote: >> On 23/3/21 5:44 pm, Tim Dickson via SlackBuilds-users wrote: >>> has anyone had success building openimageio with the new pybind11? ? it >>> is failing for me. it seems to be looking for pybind11 files in >>> /usr/include/python2.7/pybind11? when the pybind11 package has the files >>> in /usr/include/pybind11 >>> >> I've held pybind11 at version at 2.5.0 - the latest that enables >> building of openimageio - however not for want of finding include files. >> With latest pybind11-2.6.2 configuration output says: >> ???? -- pybind11 2.6.2, include dir: /usr/include >> >> i.e. include files are found OK. >> >> The error I see is after 92% has compiled: >> ???? /var/tmp/SBo/oiio-Release-2.0.13/src/python/py_oiio.h:303:47: error: >> no matching function for call to 'cast(OpenImageIO_v2_0::span> OpenImageIO_v2_0::TypeDesc, -1l>::element_type&)' >> >> I'm assuming this is due to new definitions in pybind11 which newer >> versions of openimageio will deal with. However newer versions of >> openimageio don't build in 14.2 so we're stuck with openimageio-2.0.13 >> and (therefore) pybind11-2.5.0. >> >> chris >> > hmm. i'm using pybind11 2.5.0 all on slackware 14.2 (64bit) the errors i > get with openimageio are.... > > -- robin-map include dir: /usr/include > CMake Error at src/cmake/externalpackages.cmake:568 (file): > ? file STRINGS file "/usr/include/python2.7/pybind11/common.h" cannot be > ? read. > Call Stack (most recent call first): > ? CMakeLists.txt:206 (find_or_download_pybind11) > > CMake Error at src/cmake/externalpackages.cmake:570 (file): > ? file STRINGS file "/usr/include/python2.7/pybind11/common.h" cannot be > ? read. > Call Stack (most recent call first): > ? CMakeLists.txt:206 (find_or_download_pybind11) > > CMake Error at src/cmake/externalpackages.cmake:572 (file): > ? file STRINGS file "/usr/include/python2.7/pybind11/common.h" cannot be > ? read. > Call Stack (most recent call first): > ? CMakeLists.txt:206 (find_or_download_pybind11) > > -- pybind11 366.366.366, include dir: /usr/include/python2.7 > CMake Error at > /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:148 > (message): > ? Could NOT find PythonInterp: Found unsuitable version "2.7.17", but > ? required is at least "3.7.2" (found /usr/bin/python2.7) > Call Stack (most recent call first): > /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:386 > (_FPHSA_FAILURE_MESSAGE) > ? /usr/share/cmake-3.5/Modules/FindPythonInterp.cmake:163 > (FIND_PACKAGE_HANDLE_STANDARD_ARGS) > ? src/python/CMakeLists.txt:4 (find_package) > > -- Configuring incomplete, errors occurred! > See also "/tmp/SBo/oiio-Release-2.0.13/build/CMakeFiles/CMakeOutput.log". > See also "/tmp/SBo/oiio-Release-2.0.13/build/CMakeFiles/CMakeError.log". > > looking at the CMakeEerror.log the complaint is that pthread_create does > not exist. I don't think that's a problem - I see the same pthread problem in CMakeError.log of a successful build. How old is your pybind11 build? In February I updated the SLackBuilkd for pybind11, the main change being to use CMake instead of Python as the build instrument; also to use python3 exclusively instead of python2. I suggest you rebuild/install this latest pybind11, then try openimageio again. chris From dickson.tim at googlemail.com Wed Mar 24 14:30:57 2021 From: dickson.tim at googlemail.com (Tim Dickson) Date: Wed, 24 Mar 2021 14:30:57 +0000 Subject: [Slackbuilds-users] openimageio with pybind11 issues In-Reply-To: References: <9eba4ecf-c6dd-66a6-a2a4-9919c153aef3@googlemail.com> <3f8abbae-0d40-c58f-ecb1-aac027c312f2@linux.com> Message-ID: <64af68bf-d001-ad32-d194-ad0a7bf799cd@googlemail.com> On 24/03/2021 11:42, Christoph Willing wrote: > On 24/3/21 6:55 pm, Tim Dickson via SlackBuilds-users wrote: >> >> On 24/03/2021 07:48, Christoph Willing wrote: >>> On 23/3/21 5:44 pm, Tim Dickson via SlackBuilds-users wrote: >>>> has anyone had success building openimageio with the new pybind11? ? it >>>> is failing for me. it seems to be looking for pybind11 files in >>>> /usr/include/python2.7/pybind11? when the pybind11 package has the files >>>> in /usr/include/pybind11 >>>> >>> I've held pybind11 at version at 2.5.0 - the latest that enables >>> building of openimageio - however not for want of finding include files. >>> With latest pybind11-2.6.2 configuration output says: >>> ???? -- pybind11 2.6.2, include dir: /usr/include >>> >>> i.e. include files are found OK. >>> >>> The error I see is after 92% has compiled: >>> ???? /var/tmp/SBo/oiio-Release-2.0.13/src/python/py_oiio.h:303:47: error: >>> no matching function for call to 'cast(OpenImageIO_v2_0::span>> OpenImageIO_v2_0::TypeDesc, -1l>::element_type&)' >>> >>> I'm assuming this is due to new definitions in pybind11 which newer >>> versions of openimageio will deal with. However newer versions of >>> openimageio don't build in 14.2 so we're stuck with openimageio-2.0.13 >>> and (therefore) pybind11-2.5.0. >>> >>> chris >>> >> hmm. i'm using pybind11 2.5.0 all on slackware 14.2 (64bit) the errors i >> get with openimageio are.... >> >> -- robin-map include dir: /usr/include >> CMake Error at src/cmake/externalpackages.cmake:568 (file): >> ? file STRINGS file "/usr/include/python2.7/pybind11/common.h" cannot be >> ? read. >> Call Stack (most recent call first): >> ? CMakeLists.txt:206 (find_or_download_pybind11) >> >> CMake Error at src/cmake/externalpackages.cmake:570 (file): >> ? file STRINGS file "/usr/include/python2.7/pybind11/common.h" cannot be >> ? read. >> Call Stack (most recent call first): >> ? CMakeLists.txt:206 (find_or_download_pybind11) >> >> CMake Error at src/cmake/externalpackages.cmake:572 (file): >> ? file STRINGS file "/usr/include/python2.7/pybind11/common.h" cannot be >> ? read. >> Call Stack (most recent call first): >> ? CMakeLists.txt:206 (find_or_download_pybind11) >> >> -- pybind11 366.366.366, include dir: /usr/include/python2.7 >> CMake Error at >> /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:148 >> (message): >> ? Could NOT find PythonInterp: Found unsuitable version "2.7.17", but >> ? required is at least "3.7.2" (found /usr/bin/python2.7) >> Call Stack (most recent call first): >> /usr/share/cmake-3.5/Modules/FindPackageHandleStandardArgs.cmake:386 >> (_FPHSA_FAILURE_MESSAGE) >> ? /usr/share/cmake-3.5/Modules/FindPythonInterp.cmake:163 >> (FIND_PACKAGE_HANDLE_STANDARD_ARGS) >> ? src/python/CMakeLists.txt:4 (find_package) >> >> -- Configuring incomplete, errors occurred! >> See also "/tmp/SBo/oiio-Release-2.0.13/build/CMakeFiles/CMakeOutput.log". >> See also "/tmp/SBo/oiio-Release-2.0.13/build/CMakeFiles/CMakeError.log". >> >> looking at the CMakeEerror.log the complaint is that pthread_create does >> not exist. > I don't think that's a problem - I see the same pthread problem in > CMakeError.log of a successful build. > > How old is your pybind11 build? In February I updated the SLackBuilkd > for pybind11, the main change being to use CMake instead of Python as > the build instrument; also to use python3 exclusively instead of > python2. I suggest you rebuild/install this latest pybind11, then try > openimageio again. > > chris > _______________________________________________ > I did have the latest pybind11 installed (I reinstalled it again, just in case). But your info about the change got me thinking, and i've got it going now. (after running rm -r /tmp/SBo/*? ). It looks like previous build artefacts in openimageio messed up the build attempt. thanks for the pointer. From looking at the openimageio.Slackbuild, it tries to remove the wrong temporary directory before extracting the files, thus leaving stale stuff from previous package creation. Because the PRGNAM is "openimageio" but the extracted source is in "oiio-Release" the script never cleans up (removes) any previous contents of oiio-Release A fix for this in the slackbuild is to replace rm -rf PRGNAM-$VERSION with rm -rf $SRCNAM-$VERSION Regards, Tim (and thanks for the slackbuild :-)?? ) -- This email has been checked for viruses by AVG. https://www.avg.com From chris.willing at linux.com Wed Mar 24 20:54:47 2021 From: chris.willing at linux.com (Christoph Willing) Date: Thu, 25 Mar 2021 06:54:47 +1000 Subject: [Slackbuilds-users] openimageio with pybind11 issues In-Reply-To: <64af68bf-d001-ad32-d194-ad0a7bf799cd@googlemail.com> References: <9eba4ecf-c6dd-66a6-a2a4-9919c153aef3@googlemail.com> <3f8abbae-0d40-c58f-ecb1-aac027c312f2@linux.com> <64af68bf-d001-ad32-d194-ad0a7bf799cd@googlemail.com> Message-ID: <4c8d9ef9-48dc-c3ae-e75c-2c6067bf07af@linux.com> On 25/3/21 12:30 am, Tim Dickson wrote: > > From looking at the openimageio.Slackbuild, it tries to remove the wrong > temporary directory before extracting the files, thus leaving stale > stuff from previous package creation. Because the PRGNAM is > "openimageio" but the extracted source is in "oiio-Release" the script > never cleans up (removes) any previous contents of oiio-Release > A fix for this in the slackbuild is to replace > rm -rf PRGNAM-$VERSION > > with > > rm -rf $SRCNAM-$VERSION > Thanks for finding that. Because I always use a fresh VM for my builds, it was never a problem for me. I will fix it. chris From jtcervantes at twc.com Thu Mar 25 23:23:58 2021 From: jtcervantes at twc.com (JT Cervantes) Date: Thu, 25 Mar 2021 16:23:58 -0700 Subject: [Slackbuilds-users] Heads-up: rdiff-backup update to 2.0.5 - Incompatible with 1.2.8 Message-ID: <0ff07921-a848-5a25-87d8-7115754d6dbb@twc.com> HI! I'm using rdiff-backup on all of my machines(a mix of current and 14.2) and I don't think it'll be too disruptive. Just my 2 cents. JT From willysr at slackbuilds.org Sat Mar 27 03:30:35 2021 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sat, 27 Mar 2021 10:30:35 +0700 Subject: [Slackbuilds-users] Updates - 20210327.1 Message-ID: <1e93754d-d87b-e274-3058-ff3371ec75a1@slackbuilds.org> Sat Mar 27 03:24:01 UTC 2021 academic/bcftools: Updated for version 1.12. academic/gcompris-qt: Updated for version 1.1. academic/samtools: Updated for version 1.12. audio/pulseaudio-ctl: Updated for version 1.69. desktop/bukubrow: Updated for version 5.2.0. desktop/gmrun: Updated for version 1.1w. development/git-lfs: Updated for version 2.13.3. development/hugo: Updated for version 0.82.0. development/meson: Version bump to 0.57.1 and update copyright year development/slibtool: Updated for version 0.5.32. development/tidy-html5: Updated for version 5.7.28. development/tiled: updated for version 1.5.0 games/ags: updated for version 3.5.0.31 games/atari++: Add optional no-confirm-quit patch. graphics/openimageio: Clean source directory correctly graphics/vuescan: Updated MD5SUMs. libraries/htslib: Updated for version 1.12. libraries/libinput: Updated for version 1.17.1. libraries/libwacom: Updated for version 1.9. libraries/ocl-icd: Updated for version 2.2.14. libraries/orcania: updated for version 2.2.0 libraries/rhonabwy: updated for version 0.9.99 libraries/ulfius: updated for version 2.7.2 libraries/yder: updated for version 1.4.13 misc/font-unscii: Updated for version 2.1. multimedia/plexmediaserver: Updated for 1.22.1.4228_724c56e62. network/axel: Updated for version 2.17.10. network/discord: Version bump to 0.0.14 and update copyright year network/dropbox: Updated for version 2.6.0. network/onioncat: Updated for version 0.3.8. network/openresolv: Version bump to 3.12.0 and update copyright year network/opera-developer: Updated for version 76.0.3995.0. network/opera: Updated for version 75.0.3969.93. network/qutebrowser-tox: OpenSSL Updated to 1.1.1k. network/rclone: Updated for version 1.54.1. network/telegram: Updated for version 2.7.1. network/tor-browser: Updated for version 10.0.14. network/vivaldi: Updated for version 3.7.2218.49. network/zeek: Updated for version 3.0.13. network/zoom-linux: Updated for version 5.6.13558.0321 office/calibre-bin: Updated for version 5.14.0. office/fop: Update embedded {font,pdf}box. office/pandoc-bin: Updated for version 2.13. office/task: Updated for version 2.5.3. office/timetrap: Updated for version 1.15.2. perl/MoarVM: Updated for version 2021.03 perl/nqp: Updated for version 2021.03 perl/rakudo: Updated for version 2021.03 python/mypy: Updated for version 0.812. python/python3-isort: Updated for version 5.8.0. python/python3-lazy-object-proxy: Updated for version 1.6.0. python/python3-openpyxl: Updated for version 3.0.7. python/python3-soupsieve: Updated for version 2.2.1. python/thonny: Updated for version 3.3.6. ruby/sequel: Updated for version 5.42.0. system/atop: Updated for version 2.6.0. system/jdupes: updated for version 1.19.2 system/lirc: Add pygobject3-python3 to REQUIRES system/mksh: Updated for version R59c. +--------------------------+ -- Willy Sudiarto Raharjo -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From alik at ejik.org Sat Mar 27 15:59:13 2021 From: alik at ejik.org (Alexander Verbovetsky) Date: Sat, 27 Mar 2021 18:59:13 +0300 Subject: [Slackbuilds-users] gtk-vnc failure after meson update In-Reply-To: <1e93754d-d87b-e274-3058-ff3371ec75a1@slackbuilds.org> References: <1e93754d-d87b-e274-3058-ff3371ec75a1@slackbuilds.org> Message-ID: <8668b0ac-4225-44f9-801d-3dbe963cebee@www.fastmail.com> Hello, > development/meson: Version bump to 0.57.1 and update copyright year For me this version change results in failure of gtk-vnc building. Does anybody have such problem? Best regards, Alexander From dwells at alfavinil.com Mon Mar 29 23:14:14 2021 From: dwells at alfavinil.com (David Wells) Date: Mon, 29 Mar 2021 20:14:14 -0300 Subject: [Slackbuilds-users] gtk-vnc and osinfo-db-tools failure after meson update Message-ID: <9fc53baf-8249-3628-e5c1-5cef12f63b8e@alfavinil.com> Hi all! Just to chip in with this issue, reverting back to meson-0.55.3 and the problem gets resolved. Best regards, David Wells. From spycrowsoft at gmail.com Tue Mar 30 10:47:36 2021 From: spycrowsoft at gmail.com (Spycrowsoft) Date: Tue, 30 Mar 2021 12:47:36 +0200 Subject: [Slackbuilds-users] gtk-vnc and osinfo-db-tools failure after meson update In-Reply-To: <9fc53baf-8249-3628-e5c1-5cef12f63b8e@alfavinil.com> References: <9fc53baf-8249-3628-e5c1-5cef12f63b8e@alfavinil.com> Message-ID: libgxps also fails. It did build fine with the previous version of meson. Op 30-03-2021 om 01:14 schreef David Wells: > Hi all! > > Just to chip in with this issue, reverting back to meson-0.55.3 and > the problem gets resolved. > > Best regards, > David Wells. > > _______________________________________________ > 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 jdashiel at panix.com Tue Mar 30 21:46:03 2021 From: jdashiel at panix.com (Jude DaShiell) Date: Tue, 30 Mar 2021 17:46:03 -0400 Subject: [Slackbuilds-users] gusersoundfont credentials mismatch Message-ID: The following packages will be installed: gusersoundfont Fetching README...Done Fetching gusersoundfont.SlackBuild...Done Fetching gusersoundfont.info...Done Fetching slack-desc...Done Fetching https://www.dropbox.com/s/4x27l49kxcwamp5/GeneralUser_GS_1.471.zip...Done MD5SUM mismatch for GeneralUser_GS_1.471.zip From robrown at rogerbrown.info Tue Mar 30 22:22:37 2021 From: robrown at rogerbrown.info (Roger Brown) Date: Wed, 31 Mar 2021 09:22:37 +1100 Subject: [Slackbuilds-users] gusersoundfont credentials mismatch In-Reply-To: References: Message-ID: <27d473ae-57ef-49fc-b493-4aefce3e97d2@rogerbrown.info> Excellent thanks ?Roger Brown robrown at rogerbrown.info? On 31 Mar 2021, 8:46 am, at 8:46 am, Jude DaShiell wrote: >The following packages will be installed: > gusersoundfont >Fetching README...Done >Fetching gusersoundfont.SlackBuild...Done >Fetching gusersoundfont.info...Done >Fetching slack-desc...Done >Fetching >https://www.dropbox.com/s/4x27l49kxcwamp5/GeneralUser_GS_1.471.zip...Done >MD5SUM mismatch for GeneralUser_GS_1.471.zip > >_______________________________________________ >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 jdashiel at panix.com Wed Mar 31 19:20:36 2021 From: jdashiel at panix.com (Jude DaShiell) Date: Wed, 31 Mar 2021 15:20:36 -0400 Subject: [Slackbuilds-users] dosemu now deprecated Message-ID: dosemu 1.x has been deprecated in favor of dosemu 2.x. Would it be possible to get dosemu 1.x replaced by dosemu 2.x in slackbuilds repositories? The usergroup linux-msdos at vger.kernel.org no longer has anyone working on dosemu 1.x and work has moved onto dosemu 2.x and into a private git repository. It may be reasonable to stop with dosemu 1.x due to the private repository (security considerations), so if that's the case I have no problem with such a decision. From yalhcru at gmail.com Wed Mar 31 19:57:34 2021 From: yalhcru at gmail.com (B Watson) Date: Wed, 31 Mar 2021 15:57:34 -0400 Subject: [Slackbuilds-users] dosemu now deprecated In-Reply-To: References: Message-ID: On 3/31/21, Jude DaShiell wrote: > The usergroup linux-msdos at vger.kernel.org no longer has anyone working on > dosemu 1.x and work has moved onto dosemu 2.x and into a private git > repository. > It may be reasonable to stop with dosemu 1.x due to the private repository > (security considerations), so if that's the case I have no problem with > such a decision. This it? https://github.com/dosemu2/dosemu2 If so, it's not so private... if not, are there two separate "dosemu 2" projects? From jdashiel at panix.com Wed Mar 31 20:34:21 2021 From: jdashiel at panix.com (Jude DaShiell) Date: Wed, 31 Mar 2021 16:34:21 -0400 Subject: [Slackbuilds-users] dosemu now deprecated In-Reply-To: References: Message-ID: So far as I know, you have the correct address for the software. On Wed, 31 Mar 2021, B Watson wrote: > On 3/31/21, Jude DaShiell wrote: > >> The usergroup linux-msdos at vger.kernel.org no longer has anyone working on >> dosemu 1.x and work has moved onto dosemu 2.x and into a private git >> repository. >> It may be reasonable to stop with dosemu 1.x due to the private repository >> (security considerations), so if that's the case I have no problem with >> such a decision. > > This it? > > https://github.com/dosemu2/dosemu2 > > If so, it's not so private... if not, are there two separate "dosemu > 2" projects? > _______________________________________________ > 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 jdashiel at panix.com Wed Mar 31 20:37:28 2021 From: jdashiel at panix.com (Jude DaShiell) Date: Wed, 31 Mar 2021 16:37:28 -0400 Subject: [Slackbuilds-users] dosemu now deprecated In-Reply-To: References: Message-ID: dosemu2 uses fdpp and comcom32 and if those aren't already available, they'll represent additional complications. On Wed, 31 Mar 2021, B Watson wrote: > On 3/31/21, Jude DaShiell wrote: > >> The usergroup linux-msdos at vger.kernel.org no longer has anyone working on >> dosemu 1.x and work has moved onto dosemu 2.x and into a private git >> repository. >> It may be reasonable to stop with dosemu 1.x due to the private repository >> (security considerations), so if that's the case I have no problem with >> such a decision. > > This it? > > https://github.com/dosemu2/dosemu2 > > If so, it's not so private... if not, are there two separate "dosemu > 2" projects? > _______________________________________________ > 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/ > >