From ekinakoglu at tutanota.com Fri Aug 3 11:46:16 2018 From: ekinakoglu at tutanota.com (Ekin Akoglu) Date: Fri, 3 Aug 2018 13:46:16 +0200 (CEST) Subject: [Slackbuilds-users] ganttproject Message-ID: Dear admins , Being the maintainer of ganttproject, I have just submitted an update to the SlackBuild fixing some issues (Missing XFCE menu and prompting slack-desc during installation). Since version 2.8.8, ganttproject is repackaged from Debian binary, hence, please pay attention that the only patch file that is required is now "ganttproject.desktop.patch" and all other previous patches are obsolete! I kindly ask you to remove the other patch files from git repository. Thank you, Ekin -- Securely sent with Tutanota. Claim your encrypted mailbox today! https://tutanota.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From idlemoor at slackbuilds.org Fri Aug 3 21:30:01 2018 From: idlemoor at slackbuilds.org (David Spencer) Date: Fri, 3 Aug 2018 22:30:01 +0100 Subject: [Slackbuilds-users] ganttproject In-Reply-To: References: Message-ID: > Dear admins , > > Being the maintainer of ganttproject, I have just submitted an update to > the SlackBuild fixing some issues (Missing XFCE menu and prompting > slack-desc during installation). > > Since version 2.8.8, ganttproject is repackaged from Debian binary, > hence, please pay attention that the only patch file that is required is > now "ganttproject.desktop.patch" and all other previous patches are > obsolete! I kindly ask you to remove the other patch files from git > repository. Thanks Ekin, I hope I've done it right :) Cheers -D. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From willysr at slackbuilds.org Sat Aug 4 01:53:32 2018 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sat, 4 Aug 2018 08:53:32 +0700 Subject: [Slackbuilds-users] Updates - 20180804.1 Message-ID: Welcome to the first update in August Sat Aug 4 01:43:09 UTC 2018 academic/copasi: Updated for version 4.24.197. academic/scidavis: Patched to fix crashes. academic/sundials: Updated for version 3.1.1. audio/id3tool: New maintainer, minor tweaks. audio/mp4tools: Updated for version 3.6.1. audio/sunvox: Updated for version 1.9.4. audio/tuxguitar: Updated for version 1.5.1. desktop/docfetcher: Updated for version 1.1.21. desktop/xsession-xinitrc: Added (xinitrc integration). development/kotlin: Updated for version 1.2.60. development/pkgconf: Updated for version 1.5.3. development/rstudio-desktop: Updated for version 1.1.456. development/rust: Updated for version 1.27.2. development/yarn: Updated for version 1.9.4. games/RetroArch: Allow building without PA. games/dolphin-emu: Switch homepage to https. games/fortune-starwars: Added (Star Wars fortune file). games/gzdoom: Updated for version 3.5.0. games/innoextract: Updated for version 1.7. games/mame: Updated for version 0.200. games/snes9x-libretro: Removed (please use snes9x). games/snes9x: Add RetroArch support. gis/gdal: Switch homepage and download to https. gis/geopy: Updated for version 1.16.0. gis/opencpn-plugin-oesenc: Fixed unused file. graphics/openimageio: Updated for version 1.8.13 graphics/xcur2png: Added (convert idiotic Xcursor format files). libraries/gupnp: Updated for version 1.0.3. libraries/lensfun: Fix Python build. libraries/libinput: Updated for version 1.11.3. libraries/libxnvctrl: Updated for version 390.77. libraries/orcania: Updated for version 1.2.4. libraries/pgplot: Updated script. libraries/purple-plugin_pack: Removed (renamed purple-plugin-pack). libraries/sqliteodbc: Added (SQLite ODBC Driver). libraries/ulfius: Updated for version 2.3.8. libraries/yder: Updated for version 1.3.4. multimedia/plexmediaserver: Updated for v 1.13.5.5291_6fa5e50a8. network/WireGuard: Updated for version 0.0.20180802. network/aMule: Remove the wrong libupnp-1.8 patch. network/bitcoin: Updated for version 0.16.2. network/brave: Updated for version 0.23.73. network/hiawatha: Updated for version 10.8.2. network/ipxnet: Added (tunnel IPX over TCP/IP). network/megatools: Updated for version 1.10.2. network/opera-developer: Updated for version 56.0.3026.0. network/opera: Updated for version 54.0.2952.64. network/palemoon: Update README. network/purple-plugin-pack: Added (ex libraries/purple-plugin_pack). network/riot-web: Updated for version 0.16.0. network/signal-desktop: Updated for version 1.15.0. network/vivaldi: Updated for version 1.15.1147.55. network/youtube-dl: Updated for version 2018.07.29. office/ganttproject: Fix XFCE menu, etc. office/libreoffice-helppack: Updated for version 6.0.6. office/libreoffice-langpack: Updated for version 6.0.6. office/libreoffice: Update DEP. office/libreoffice: Updated for version 6.0.6. office/pdfstudio2018: Updated for version 18.1.0. perl/perl-Params-ValidationCompiler: Updated for version 0.30. perl/perl-Path-Tiny: Updated for version 0.108. python/PyGreSQL: Updated for version 5.0.6 python/ipython: Upgraded for version 5.8.0. python/python3-django: Updated for version 2.1. python/python3-ipython: Updated for version 6.5.0. python/scikit-learn: Updated for version 0.19.2. ruby/rubygem-yajl-ruby: Switch homepage and download to https. system/Iosevka: Updated for version 2.0.0. system/alacritty: Updated for version git24a74d4. system/ansible: Updated for version 2.6.2. system/bleachbit: Updated for version 2.0 + new maintainer. system/elo-mt-usb: Remove ARM download section. system/epson-inkjet-printer-escpr2: Added (epson printer drivers). system/fatsort: Added (a FAT sorting utility). system/gtk-vnc: Updated for version 0.8.0. system/heirloom-ed: Added (standard POSIX text editor). system/intel-microcode: Updated for version 20180703. system/mariadb-plugin-saslauthd: Updated for version 1.4. system/nvidia-driver: Updated for version 390.77. system/nvidia-kernel: Updated for version 390.77. system/password-store: Updated for version 1.7.3. system/spman: Updated for version 2.1.0. system/ttf-zekton: Switch homepage to https. system/unetbootin: Updated for version 661. +--------------------------+ -- Willy Sudiarto Raharjo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From yalhcru at gmail.com Sat Aug 4 08:48:26 2018 From: yalhcru at gmail.com (B Watson) Date: Sat, 4 Aug 2018 04:48:26 -0400 Subject: [Slackbuilds-users] weekly bad download report Message-ID: Failed downloads from tonight's sbosrcarch run: === academic/copasi : https://github.com/copasi/COPASI/releases/download/Build-197/COPASI-4.24.197-Linux-32bit.tar.gz downloaded, OK : https://github.com/copasi/COPASI/releases/download/Build-197/COPASI-4.24.97-Linux-64bit.tar.gz ! HTTP/1.1 404 Not Found ...actually, checked again a couple hours later, it's no longer 404, but its md5sum doesn't match. Upstream changed the release tarball without changing the version number or filename. Maintainer will have to fix the .info file. === network/brave : https://github.com/brave/browser-laptop/releases/download/v0.23.73/Brave.tar.bz2 ! HTTP/1.1 404 Not Found ...same as above: was 404, now exists, with different md5sum. Maintainer will have to fix the .info file. === audio/sunvox : http://www.warmplace.ru/soft/sunvox/sunvox-1.9.4.zip ! HTTP/1.1 404 Not Found ...this really is gone. Looks like it's one of those sites that deletes old releases as soon as they make a new release (there's a 1.9.4c on the site now). From kjhambrick at gmail.com Sat Aug 4 09:17:16 2018 From: kjhambrick at gmail.com (Konrad J Hambrick) Date: Sat, 4 Aug 2018 04:17:16 -0500 Subject: [Slackbuilds-users] weekly bad download report In-Reply-To: References: Message-ID: Nice report there B Watson. I assume you're running a script that downloads each non-NULL DOWNLOAD= ( and DOWNLOAD64= ) and then checking the corresponding MD5SUMS ? Thank you ! -- kjh On Sat, Aug 4, 2018 at 3:48 AM, B Watson wrote: > Failed downloads from tonight's sbosrcarch run: > > === academic/copasi > : https://github.com/copasi/COPASI/releases/download/ > Build-197/COPASI-4.24.197-Linux-32bit.tar.gz > downloaded, OK > : https://github.com/copasi/COPASI/releases/download/ > Build-197/COPASI-4.24.97-Linux-64bit.tar.gz > ! HTTP/1.1 404 Not Found > > ...actually, checked again a couple hours later, it's no longer 404, but > its md5sum doesn't match. Upstream changed the release tarball without > changing the version number or filename. Maintainer will have to fix > the .info file. > > > === network/brave > : https://github.com/brave/browser-laptop/releases/ > download/v0.23.73/Brave.tar.bz2 > ! HTTP/1.1 404 Not Found > > ...same as above: was 404, now exists, with different md5sum. Maintainer > will have to fix the .info file. > > > === audio/sunvox > : http://www.warmplace.ru/soft/sunvox/sunvox-1.9.4.zip > ! HTTP/1.1 404 Not Found > > ...this really is gone. Looks like it's one of those sites that deletes > old releases as soon as they make a new release (there's a 1.9.4c on > the site now). > _______________________________________________ > 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 yalhcru at gmail.com Sat Aug 4 09:29:42 2018 From: yalhcru at gmail.com (B Watson) Date: Sat, 4 Aug 2018 05:29:42 -0400 Subject: [Slackbuilds-users] weekly bad download report In-Reply-To: References: Message-ID: On 8/4/18, Konrad J Hambrick wrote: > Nice report there B Watson. > > I assume you're running a script that downloads each non-NULL DOWNLOAD= ( > and DOWNLOAD64= ) and then checking the corresponding MD5SUMS ? Yah. That's from the sbosrcarch script's log. I wrote way too much about it here: http://slackware.uk/sbosrcarch/FAQ The tl;dr version is: It follows the git log, and every time there's an update, it tries to download all the source files in all the .info files that have changed since last update. It's not actually trying to download *everything*, just the stuff that's changed, so it won't catch all the bad downloads in the whole repo. Though if there are "old" bad downloads, you can find the missing file(s) in the archive already. From kjhambrick at gmail.com Sat Aug 4 11:02:03 2018 From: kjhambrick at gmail.com (Konrad J Hambrick) Date: Sat, 4 Aug 2018 06:02:03 -0500 Subject: [Slackbuilds-users] ganttproject In-Reply-To: References: Message-ID: Ekin ( and David )-- Very Kool ! I didn't know about ganttproject. I learn all kinds of useful things on the slackbuilds-users mailing list ! I just now built and installed ganttproject on Slackware64 14.2 + Multilib. It seems to work fine ( but now I need to learn how to use it ) One thing that maybe should be fixed is the /usr/bin/ganttproject SymLink: # ls -la /usr/bin/ganttproject lrwxrwxrwx 1 root root 65 Aug 4 04:21 /usr/bin/ganttproject -> /tmp/SBo/package-ganttproject/usr/share/ganttproject/ganttproject Note that it still points into my /tmp/SBo/ directory. I am not sure this is the best way to do it but I fixed the SymLink with a slight mod to the ganttproject.SlackBuild Attached is the `diff -Naur` output suitable for patch -p0 ... After the Patch, I rebuilt and ran upgradepkg on /tmp/ganttproject-2.8.8-x86_64-2_SBo_kjh.tgz The Symlink looks more permanant now :) # ls -la /usr/bin/ganttproject lrwxrwxrwx 1 root root 36 Aug 4 05:49 /usr/bin/ganttproject -> /usr/share/ganttproject/ganttproject Thanks for the SlackBuild Ekin and David ! -- kjh On Fri, Aug 3, 2018 at 4:30 PM, David Spencer wrote: > > Dear admins , > > > > Being the maintainer of ganttproject, I have just submitted an update to > > the SlackBuild fixing some issues (Missing XFCE menu and prompting > > slack-desc during installation). > > > > Since version 2.8.8, ganttproject is repackaged from Debian binary, > > hence, please pay attention that the only patch file that is required is > > now "ganttproject.desktop.patch" and all other previous patches are > > obsolete! I kindly ask you to remove the other patch files from git > > repository. > > Thanks Ekin, I hope I've done it right :) > > Cheers > -D. > > > > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - https://slackbuilds.org/faq/ > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- --- ganttproject.SlackBuild.orig 2018-08-04 04:06:09.813779241 -0500 +++ ganttproject.SlackBuild 2018-08-04 05:59:12.678487370 -0500 @@ -74,7 +74,10 @@ rm -f $PKG/debian-binary mkdir -p $PKG/usr/bin -ln -sf $PKG/usr/share/ganttproject/ganttproject $PKG/usr/bin/ganttproject +( + cd $PKG/usr/bin + ln -sf /usr/share/ganttproject/ganttproject ganttproject +) mkdir -p $PKG/usr/doc/$PRGNAM-$VERSION mv \ From kjhambrick at gmail.com Sat Aug 4 11:26:34 2018 From: kjhambrick at gmail.com (Konrad J Hambrick) Date: Sat, 4 Aug 2018 06:26:34 -0500 Subject: [Slackbuilds-users] weekly bad download report In-Reply-To: References: Message-ID: Thank you B Watson. That is a great service that you and Darren provide ! I'll look for your weekly report before I report any MD5SUM or DOWNLOAD issues :) -- kjh On Sat, Aug 4, 2018 at 4:29 AM, B Watson wrote: > On 8/4/18, Konrad J Hambrick wrote: > > Nice report there B Watson. > > > > I assume you're running a script that downloads each non-NULL DOWNLOAD= ( > > and DOWNLOAD64= ) and then checking the corresponding MD5SUMS ? > > Yah. That's from the sbosrcarch script's log. I wrote way too much about it > here: > > http://slackware.uk/sbosrcarch/FAQ > > The tl;dr version is: It follows the git log, and every time there's > an update, it tries to download all the source files in all the .info > files that have changed since last update. > > It's not actually trying to download *everything*, just the stuff > that's changed, so it won't catch all the bad downloads in the whole > repo. Though if there are "old" bad downloads, you can find the missing > file(s) in the archive already. > _______________________________________________ > 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 rshepard at appl-ecosys.com Sat Aug 4 13:23:36 2018 From: rshepard at appl-ecosys.com (Rich Shepard) Date: Sat, 4 Aug 2018 06:23:36 -0700 (PDT) Subject: [Slackbuilds-users] ganttproject In-Reply-To: References: Message-ID: On Sat, 4 Aug 2018, Konrad J Hambrick wrote: > I didn't know about ganttproject. > It seems to work fine ( but now I need to learn how to use it ) Konrad, Slightly off-topic, but others might also be interested in this information. I need a project management tool for a large, complex wetland mitigation project and looked at what SBo had to offer. Ganttproject is good if all you want is to produce a Gantt chart for display purposes (e.g., in a proposal or report). However, it does not do all that's needed for project management; e.g., resource leveling and cost tracking. If your need is for project management beyond a Gantt chart, download and install taskjuggler-3.6.0 from the repository. It's complex, complete, and powerful. You write text files and the backend compiles them into html files viewed in a browser. You can use it for Critical Path Modeling (CPM) as well as Critical Chain Modeling (which uses constraints/pinch points to determine project duration.) Powerful, complex, and worth the climb up the learning curve. Best of all, the maintainer (and mail list subscribers ) are great help in pointing us learners in the right direction. Rich From willysr at slackbuilds.org Sat Aug 4 13:51:09 2018 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sat, 4 Aug 2018 20:51:09 +0700 Subject: [Slackbuilds-users] ganttproject In-Reply-To: References: Message-ID: <937fde06-2477-229e-2cc9-acb0c050f8c6@slackbuilds.org> > Very Kool ! > > I didn't know about ganttproject. > > I learn all kinds of useful things on the slackbuilds-users mailing list ! > > I just now built and installed ganttproject on Slackware64 14.2 + Multilib. > > It seems to work fine ( but now I need to learn how to use it ) > > One thing that maybe should be fixed is the /usr/bin/ganttproject SymLink: > > # ls -la /usr/bin/ganttproject > ? lrwxrwxrwx 1 root root 65 Aug? 4 04:21 /usr/bin/ganttproject -> > /tmp/SBo/package-ganttproject/usr/share/ganttproject/ganttproject > > Note that it still points into my /tmp/SBo/ directory. > > I am not sure this is the best way to do it but I fixed the SymLink with > a slight mod to the ganttproject.SlackBuild > > Attached is the `diff -Naur` output suitable for patch -p0 ... > > After the Patch, I rebuilt and ran upgradepkg on > /tmp/ganttproject-2.8.8-x86_64-2_SBo_kjh.tgz > > The Symlink looks more permanant now :) > > # ls -la /usr/bin/ganttproject > ? lrwxrwxrwx 1 root root 36 Aug? 4 05:49 /usr/bin/ganttproject -> > /usr/share/ganttproject/ganttproject > > Thanks for the SlackBuild Ekin and David ! Thanks Konrad It's been fixed in my branch now -- Willy Sudiarto Raharjo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From willysr at slackbuilds.org Sat Aug 4 14:59:46 2018 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sat, 4 Aug 2018 21:59:46 +0700 Subject: [Slackbuilds-users] weekly bad download report In-Reply-To: References: Message-ID: <7c439b43-010d-eb0b-1a38-7601d10974ea@slackbuilds.org> > === academic/copasi > : https://github.com/copasi/COPASI/releases/download/Build-197/COPASI-4.24.197-Linux-32bit.tar.gz > downloaded, OK > : https://github.com/copasi/COPASI/releases/download/Build-197/COPASI-4.24.97-Linux-64bit.tar.gz > ! HTTP/1.1 404 Not Found Fixed > === network/brave > : https://github.com/brave/browser-laptop/releases/download/v0.23.73/Brave.tar.bz2 > ! HTTP/1.1 404 Not Found Fixed > === audio/sunvox > : http://www.warmplace.ru/soft/sunvox/sunvox-1.9.4.zip > ! HTTP/1.1 404 Not Found > > ...this really is gone. Looks like it's one of those sites that deletes > old releases as soon as they make a new release (there's a 1.9.4c on > the site now). Fixed -- Willy Sudiarto Raharjo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From kjhambrick at gmail.com Sat Aug 4 16:10:54 2018 From: kjhambrick at gmail.com (Konrad J Hambrick) Date: Sat, 4 Aug 2018 11:10:54 -0500 Subject: [Slackbuilds-users] ganttproject In-Reply-To: References: Message-ID: On Sat, Aug 4, 2018 at 8:23 AM, Rich Shepard wrote: > On Sat, 4 Aug 2018, Konrad J Hambrick wrote: > > I didn't know about ganttproject. >> It seems to work fine ( but now I need to learn how to use it ) >> > > Konrad, > > Slightly off-topic, but others might also be interested in this > information. > > I need a project management tool for a large, complex wetland mitigation > project and looked at what SBo had to offer. > > Ganttproject is good if all you want is to produce a Gantt chart for > display purposes (e.g., in a proposal or report). However, it does not do > all that's needed for project management; e.g., resource leveling and cost > tracking. > > If your need is for project management beyond a Gantt chart, download and > install taskjuggler-3.6.0 from the repository. It's complex, complete, and > powerful. You write text files and the backend compiles them into html > files > viewed in a browser. You can use it for Critical Path Modeling (CPM) as > well > as Critical Chain Modeling (which uses constraints/pinch points to > determine > project duration.) Powerful, complex, and worth the climb up the learning > curve. Best of all, the maintainer (and mail list subscribers ) are great > help in pointing us learners in the right direction. > > Thanks Rich ! I will check out taskjuggler. I do like the idea of text file input and html file output :) -- kjh p.s. And I just now learned that I can prevent gmail from top-posting by expanding and scrolling down :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From artourter at gmail.com Sat Aug 4 16:39:46 2018 From: artourter at gmail.com (Greg' Ar Tourter) Date: Sat, 4 Aug 2018 17:39:46 +0100 Subject: [Slackbuilds-users] apparently abandoned packages. In-Reply-To: <20180731030530.5mtf7h3zo2ka3wj4@viking2.falor> References: <20180721180527.jnve4zut54w4labu@viking2.falor> <20180731030530.5mtf7h3zo2ka3wj4@viking2.falor> Message-ID: Just to update, since B.Watson took over the maintenance of id3tool in this morning's release, I have taken over and submitted an update for pdfpc Cheers Greg On Tue, 31 Jul 2018 at 04:05, Erik Falor wrote: > On Sun, Jul 29, 2018 at 01:11:12PM +0100, Greg' Ar Tourter wrote: > > Just following up on this, Erik, did you get anything back from Markus? I > > haven't. > > No, I have not gotten any word from Markus about development/racket. > > -- > Erik Falor > Registered Linux User #445632 http://unnovative.net > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekinakoglu at tutanota.com Sat Aug 4 18:37:36 2018 From: ekinakoglu at tutanota.com (Ekin Akoglu) Date: Sat, 4 Aug 2018 20:37:36 +0200 (CEST) Subject: [Slackbuilds-users] ganttproject In-Reply-To: References: <> <> Message-ID: Dear Konrad, Thank you for the kind words and also for pointing the mistake in the SlackBuild. I have corrected it in the SlackBuild. Best, Ekin -- Securely sent with Tutanota. Claim your encrypted mailbox today! https://tutanota.com 4. Aug 2018 14:02 by kjhambrick at gmail.com : > Ekin ( and David )-- > > Very Kool ! > > I didn't know about ganttproject. > > I learn all kinds of useful things on the slackbuilds-users mailing list ! > > I just now built and installed ganttproject on Slackware64 14.2 + Multilib. > > It seems to work fine ( but now I need to learn how to use it ) > > One thing that maybe should be fixed is the /usr/bin/ganttproject SymLink: > > # ls -la /usr/bin/ganttproject > ? lrwxrwxrwx 1 root root 65 Aug? 4 04:21 /usr/bin/ganttproject -> /tmp/SBo/package-ganttproject/usr/share/ganttproject/ganttproject > > Note that it still points into my /tmp/SBo/ directory. > > I am not sure this is the best way to do it but I fixed the SymLink with a slight mod to the ganttproject.SlackBuild > > Attached is the `diff -Naur` output suitable for patch -p0 ... > > After the Patch, I rebuilt and ran upgradepkg on /tmp/ganttproject-2.8.8-x86_64-2_SBo_kjh.tgz > > The Symlink looks more permanant now :) > > # ls -la /usr/bin/ganttproject > ? lrwxrwxrwx 1 root root 36 Aug? 4 05:49 /usr/bin/ganttproject -> /usr/share/ganttproject/ganttproject > > Thanks for the SlackBuild Ekin and David ! > > -- kjh > > > On Fri, Aug 3, 2018 at 4:30 PM, David Spencer <> idlemoor at slackbuilds.org > > wrote: > >> > Dear admins , >> > >> > Being the maintainer of ganttproject, I have just submitted an update to >> > the SlackBuild fixing some issues (Missing XFCE menu and prompting >> > slack-desc during installation). >> > >> > Since version 2.8.8, ganttproject is repackaged from Debian binary, >> > hence, please pay attention that the only patch file that is required is >> > now "ganttproject.desktop.patch" and all other previous patches are >> > obsolete! I kindly ask you to remove the other patch files from git >> > repository. >> >> Thanks Ekin, I hope I've done it right :) >> >> Cheers >> -D. >> >> >> >> _______________________________________________ >> 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 ekinakoglu at tutanota.com Sat Aug 4 18:37:36 2018 From: ekinakoglu at tutanota.com (Ekin Akoglu) Date: Sat, 4 Aug 2018 20:37:36 +0200 (CEST) Subject: [Slackbuilds-users] ganttproject In-Reply-To: References: <> <> Message-ID: Dear Konrad, Thank you for the kind words and also for pointing the mistake in the SlackBuild. I have corrected it in the SlackBuild. Best, Ekin -- Securely sent with Tutanota. Claim your encrypted mailbox today! https://tutanota.com 4. Aug 2018 14:02 by kjhambrick at gmail.com : > Ekin ( and David )-- > > Very Kool ! > > I didn't know about ganttproject. > > I learn all kinds of useful things on the slackbuilds-users mailing list ! > > I just now built and installed ganttproject on Slackware64 14.2 + Multilib. > > It seems to work fine ( but now I need to learn how to use it ) > > One thing that maybe should be fixed is the /usr/bin/ganttproject SymLink: > > # ls -la /usr/bin/ganttproject > ? lrwxrwxrwx 1 root root 65 Aug? 4 04:21 /usr/bin/ganttproject -> /tmp/SBo/package-ganttproject/usr/share/ganttproject/ganttproject > > Note that it still points into my /tmp/SBo/ directory. > > I am not sure this is the best way to do it but I fixed the SymLink with a slight mod to the ganttproject.SlackBuild > > Attached is the `diff -Naur` output suitable for patch -p0 ... > > After the Patch, I rebuilt and ran upgradepkg on /tmp/ganttproject-2.8.8-x86_64-2_SBo_kjh.tgz > > The Symlink looks more permanant now :) > > # ls -la /usr/bin/ganttproject > ? lrwxrwxrwx 1 root root 36 Aug? 4 05:49 /usr/bin/ganttproject -> /usr/share/ganttproject/ganttproject > > Thanks for the SlackBuild Ekin and David ! > > -- kjh > > > On Fri, Aug 3, 2018 at 4:30 PM, David Spencer <> idlemoor at slackbuilds.org > > wrote: > >> > Dear admins , >> > >> > Being the maintainer of ganttproject, I have just submitted an update to >> > the SlackBuild fixing some issues (Missing XFCE menu and prompting >> > slack-desc during installation). >> > >> > Since version 2.8.8, ganttproject is repackaged from Debian binary, >> > hence, please pay attention that the only patch file that is required is >> > now "ganttproject.desktop.patch" and all other previous patches are >> > obsolete! I kindly ask you to remove the other patch files from git >> > repository. >> >> Thanks Ekin, I hope I've done it right :) >> >> Cheers >> -D. >> >> >> >> _______________________________________________ >> 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 ekinakoglu at tutanota.com Sat Aug 4 18:38:51 2018 From: ekinakoglu at tutanota.com (Ekin Akoglu) Date: Sat, 4 Aug 2018 20:38:51 +0200 (CEST) Subject: [Slackbuilds-users] ganttproject In-Reply-To: References: <> Message-ID: Dear David, The list of files on the ganttproject page in SBo is correct, however, the SlackBuild tar archive still includes all the obsolete files. Best, Ekin -- Securely sent with Tutanota. Claim your encrypted mailbox today! https://tutanota.com 4. Aug 2018 00:30 by idlemoor at slackbuilds.org : >> Dear admins , >> >> Being the maintainer of ganttproject, I have just submitted an update to >> the SlackBuild fixing some issues (Missing XFCE menu and prompting >> slack-desc during installation). >> >> Since version 2.8.8, ganttproject is repackaged from Debian binary, >> hence, please pay attention that the only patch file that is required is >> now "ganttproject.desktop.patch" and all other previous patches are >> obsolete! I kindly ask you to remove the other patch files from git >> repository. > > Thanks Ekin, I hope I've done it right :) > > Cheers > -D. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekinakoglu at tutanota.com Sat Aug 4 18:38:51 2018 From: ekinakoglu at tutanota.com (Ekin Akoglu) Date: Sat, 4 Aug 2018 20:38:51 +0200 (CEST) Subject: [Slackbuilds-users] ganttproject In-Reply-To: References: <> Message-ID: Dear David, The list of files on the ganttproject page in SBo is correct, however, the SlackBuild tar archive still includes all the obsolete files. Best, Ekin -- Securely sent with Tutanota. Claim your encrypted mailbox today! https://tutanota.com 4. Aug 2018 00:30 by idlemoor at slackbuilds.org : >> Dear admins , >> >> Being the maintainer of ganttproject, I have just submitted an update to >> the SlackBuild fixing some issues (Missing XFCE menu and prompting >> slack-desc during installation). >> >> Since version 2.8.8, ganttproject is repackaged from Debian binary, >> hence, please pay attention that the only patch file that is required is >> now "ganttproject.desktop.patch" and all other previous patches are >> obsolete! I kindly ask you to remove the other patch files from git >> repository. > > Thanks Ekin, I hope I've done it right :) > > Cheers > -D. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekinakoglu at tutanota.com Sat Aug 4 18:56:28 2018 From: ekinakoglu at tutanota.com (Ekin Akoglu) Date: Sat, 4 Aug 2018 20:56:28 +0200 (CEST) Subject: [Slackbuilds-users] ganttproject In-Reply-To: <937fde06-2477-229e-2cc9-acb0c050f8c6@slackbuilds.org> References: <> <> <> <937fde06-2477-229e-2cc9-acb0c050f8c6@slackbuilds.org> Message-ID: Dear Willy, I have just uploaded an amended submission for ganttproject which incorporates the fix by Konrad, plus a correction to the top comment in the script. Please let me remind you once again that the SlackBuild tarball on the web page still comprises the obsolete patches. Kind regards, Ekin -- Securely sent with Tutanota. Claim your encrypted mailbox today! https://tutanota.com 4. Aug 2018 16:51 by willysr at slackbuilds.org : >> Very Kool ! >> >> I didn't know about ganttproject. >> >> I learn all kinds of useful things on the slackbuilds-users mailing list ! >> >> I just now built and installed ganttproject on Slackware64 14.2 + Multilib. >> >> It seems to work fine ( but now I need to learn how to use it ) >> >> One thing that maybe should be fixed is the /usr/bin/ganttproject SymLink: >> >> # ls -la /usr/bin/ganttproject >> ? lrwxrwxrwx 1 root root 65 Aug? 4 04:21 /usr/bin/ganttproject -> >> /tmp/SBo/package-ganttproject/usr/share/ganttproject/ganttproject >> >> Note that it still points into my /tmp/SBo/ directory. >> >> I am not sure this is the best way to do it but I fixed the SymLink with >> a slight mod to the ganttproject.SlackBuild >> >> Attached is the `diff -Naur` output suitable for patch -p0 ... >> >> After the Patch, I rebuilt and ran upgradepkg on >> /tmp/ganttproject-2.8.8-x86_64-2_SBo_kjh.tgz >> >> The Symlink looks more permanant now :) >> >> # ls -la /usr/bin/ganttproject >> ? lrwxrwxrwx 1 root root 36 Aug? 4 05:49 /usr/bin/ganttproject -> >> /usr/share/ganttproject/ganttproject >> >> Thanks for the SlackBuild Ekin and David ! > > Thanks Konrad > It's been fixed in my branch now > > > -- > Willy Sudiarto Raharjo -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekinakoglu at tutanota.com Sat Aug 4 19:15:23 2018 From: ekinakoglu at tutanota.com (Ekin Akoglu) Date: Sat, 4 Aug 2018 21:15:23 +0200 (CEST) Subject: [Slackbuilds-users] ganttproject In-Reply-To: References: <> <> <> <937fde06-2477-229e-2cc9-acb0c050f8c6@slackbuilds.org> <<937fde06-2477-229e-2cc9-acb0c050f8c6@slackbuilds.org>> Message-ID: Apparently it was my mistake to think that the tarball still included the obsolete patches (despite I refreshed the page). I have just tried with another browser and I could get the correct tarball downloaded. Excuse me for the hassle. Best, Ekin -- Securely sent with Tutanota. Claim your encrypted mailbox today! https://tutanota.com 4. Aug 2018 21:56 by ekinakoglu at tutanota.com : > Dear Willy, > > I have just uploaded an amended submission for ganttproject which incorporates the fix by Konrad, plus a correction to the top comment in the script. > > Please let me remind you once again that the SlackBuild tarball on the web page still comprises the obsolete patches. > > Kind regards, > > Ekin > > -- > Securely sent with Tutanota. Claim your encrypted mailbox today! > https://tutanota.com > > 4. Aug 2018 16:51 by > willysr at slackbuilds.org > : > > >>> Very Kool ! >>> >>> I didn't know about ganttproject. >>> >>> I learn all kinds of useful things on the slackbuilds-users mailing list ! >>> >>> I just now built and installed ganttproject on Slackware64 14.2 + Multilib. >>> >>> It seems to work fine ( but now I need to learn how to use it ) >>> >>> One thing that maybe should be fixed is the /usr/bin/ganttproject SymLink: >>> >>> # ls -la /usr/bin/ganttproject >>> ? lrwxrwxrwx 1 root root 65 Aug? 4 04:21 /usr/bin/ganttproject -> >>> /tmp/SBo/package-ganttproject/usr/share/ganttproject/ganttproject >>> >>> Note that it still points into my /tmp/SBo/ directory. >>> >>> I am not sure this is the best way to do it but I fixed the SymLink with >>> a slight mod to the ganttproject.SlackBuild >>> >>> Attached is the `diff -Naur` output suitable for patch -p0 ... >>> >>> After the Patch, I rebuilt and ran upgradepkg on >>> /tmp/ganttproject-2.8.8-x86_64-2_SBo_kjh.tgz >>> >>> The Symlink looks more permanant now :) >>> >>> # ls -la /usr/bin/ganttproject >>> ? lrwxrwxrwx 1 root root 36 Aug? 4 05:49 /usr/bin/ganttproject -> >>> /usr/share/ganttproject/ganttproject >>> >>> Thanks for the SlackBuild Ekin and David ! >> >> Thanks Konrad >> It's been fixed in my branch now >> >> >> -- >> Willy Sudiarto Raharjo -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekinakoglu at tutanota.com Sat Aug 4 19:15:23 2018 From: ekinakoglu at tutanota.com (Ekin Akoglu) Date: Sat, 4 Aug 2018 21:15:23 +0200 (CEST) Subject: [Slackbuilds-users] ganttproject In-Reply-To: References: <> <> <> <937fde06-2477-229e-2cc9-acb0c050f8c6@slackbuilds.org> <<937fde06-2477-229e-2cc9-acb0c050f8c6@slackbuilds.org>> Message-ID: Apparently it was my mistake to think that the tarball still included the obsolete patches (despite I refreshed the page). I have just tried with another browser and I could get the correct tarball downloaded. Excuse me for the hassle. Best, Ekin -- Securely sent with Tutanota. Claim your encrypted mailbox today! https://tutanota.com 4. Aug 2018 21:56 by ekinakoglu at tutanota.com : > Dear Willy, > > I have just uploaded an amended submission for ganttproject which incorporates the fix by Konrad, plus a correction to the top comment in the script. > > Please let me remind you once again that the SlackBuild tarball on the web page still comprises the obsolete patches. > > Kind regards, > > Ekin > > -- > Securely sent with Tutanota. Claim your encrypted mailbox today! > https://tutanota.com > > 4. Aug 2018 16:51 by > willysr at slackbuilds.org > : > > >>> Very Kool ! >>> >>> I didn't know about ganttproject. >>> >>> I learn all kinds of useful things on the slackbuilds-users mailing list ! >>> >>> I just now built and installed ganttproject on Slackware64 14.2 + Multilib. >>> >>> It seems to work fine ( but now I need to learn how to use it ) >>> >>> One thing that maybe should be fixed is the /usr/bin/ganttproject SymLink: >>> >>> # ls -la /usr/bin/ganttproject >>> ? lrwxrwxrwx 1 root root 65 Aug? 4 04:21 /usr/bin/ganttproject -> >>> /tmp/SBo/package-ganttproject/usr/share/ganttproject/ganttproject >>> >>> Note that it still points into my /tmp/SBo/ directory. >>> >>> I am not sure this is the best way to do it but I fixed the SymLink with >>> a slight mod to the ganttproject.SlackBuild >>> >>> Attached is the `diff -Naur` output suitable for patch -p0 ... >>> >>> After the Patch, I rebuilt and ran upgradepkg on >>> /tmp/ganttproject-2.8.8-x86_64-2_SBo_kjh.tgz >>> >>> The Symlink looks more permanant now :) >>> >>> # ls -la /usr/bin/ganttproject >>> ? lrwxrwxrwx 1 root root 36 Aug? 4 05:49 /usr/bin/ganttproject -> >>> /usr/share/ganttproject/ganttproject >>> >>> Thanks for the SlackBuild Ekin and David ! >> >> Thanks Konrad >> It's been fixed in my branch now >> >> >> -- >> Willy Sudiarto Raharjo -------------- next part -------------- An HTML attachment was scrubbed... URL: From larryhaja at gmail.com Sat Aug 4 22:25:57 2018 From: larryhaja at gmail.com (Larry Hajali) Date: Sat, 4 Aug 2018 15:25:57 -0700 Subject: [Slackbuilds-users] qt5 is sorely in need of an update In-Reply-To: <20180731215721.GB9697@blackswan> References: <20180715090718.GE29592@blackswan> <20180725085721.01cbfd07@Akita.witch.org> <20180731215721.GB9697@blackswan> Message-ID: Go ahead. I have no problem giving up qt5, qt5-webkit and PyQt5. I don't have time right now to test big packages like qt5. --Larry On Tue, Jul 31, 2018 at 2:57 PM David Woodfall wrote: > On Wednesday 25 July 2018 08:57, > orbea at fredslev.dk put forth the proposition: > > Given that you are doing great with Qt5 and that Larry has not even > > bothered to reply to your python2-sip comment my suggestion is that you > > should maintain Qt5 from this point on. You clearly seem the most > > willing and capable. > > I have no problem with doing Qt5 and PyQt5 is Larry doesn't want to > keep them updated. > > -- > > .--. oo > (____)// > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~' > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - https://slackbuilds.org/faq/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From willysr at slackbuilds.org Sun Aug 5 01:43:55 2018 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sun, 5 Aug 2018 08:43:55 +0700 Subject: [Slackbuilds-users] qt5 is sorely in need of an update In-Reply-To: References: <20180715090718.GE29592@blackswan> <20180725085721.01cbfd07@Akita.witch.org> <20180731215721.GB9697@blackswan> Message-ID: > Go ahead.? I have no problem giving up qt5, qt5-webkit and PyQt5.? I > don't have time right now to test big packages like qt5. If dave would like to take over Qt5*, i would suggest to do in the following orders: - create a new branch (eg qt5-testing) - update qt5, qt5-webkit, and PyQt5 - submit new scripts for qt5-legacy, qt5-webkit-legacy, and PyQt5-legacy (if needed) - test all new scripts that depends on qt5 against new qt5 - if it doesn't work with newer qt5, change the REQUIRES into qt5-legacy -- Willy Sudiarto Raharjo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From dave at dawoodfall.net Sun Aug 5 06:09:03 2018 From: dave at dawoodfall.net (David Woodfall) Date: Sun, 5 Aug 2018 07:09:03 +0100 Subject: [Slackbuilds-users] qt5 is sorely in need of an update In-Reply-To: References: <20180715090718.GE29592@blackswan> <20180725085721.01cbfd07@Akita.witch.org> <20180731215721.GB9697@blackswan> Message-ID: <20180805060903.GA6543@blackswan> On Sunday 5 August 2018 08:43, Willy Sudiarto Raharjo put forth the proposition: > > Go ahead.? I have no problem giving up qt5, qt5-webkit and PyQt5.? I > > don't have time right now to test big packages like qt5. > > If dave would like to take over Qt5*, i would suggest to do in the > following orders: > - create a new branch (eg qt5-testing) > - update qt5, qt5-webkit, and PyQt5 > - submit new scripts for qt5-legacy, qt5-webkit-legacy, and PyQt5-legacy > (if needed) > - test all new scripts that depends on qt5 against new qt5 > - if it doesn't work with newer qt5, change the REQUIRES into qt5-legacy I haven't used git for submissions yet. Guess it is time. Rather than legacy I'm thinking LTS ought to be the base branch, then a -dev to keep up with the latest. LTS is around 5.9.6 for Qt itself. Not sure about the others. That is, unless there's still something that needs an older Qt? -Dave -- Oh, and this is another kernel in that great and venerable "BugFree(tm)" series of kernels. So be not afraid of bugs, but go out in the streets and deliver this message of joy to the masses. -- Linus, in the announcement for 1.3.27 .--. oo (____)// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~' From yalhcru at gmail.com Sun Aug 5 08:35:11 2018 From: yalhcru at gmail.com (B Watson) Date: Sun, 5 Aug 2018 04:35:11 -0400 Subject: [Slackbuilds-users] qt5 is sorely in need of an update In-Reply-To: <20180805060903.GA6543@blackswan> References: <20180715090718.GE29592@blackswan> <20180725085721.01cbfd07@Akita.witch.org> <20180731215721.GB9697@blackswan> <20180805060903.GA6543@blackswan> Message-ID: On 8/5/18, David Woodfall wrote: > > Rather than legacy I'm thinking LTS ought to be the base branch, then > a -dev to keep up with the latest. LTS is around 5.9.6 for Qt itself. Ugh, don't call it -dev, you'll confuse new users coming from Debian/Redhat. They'll think it's the "development" package, and that they need qt5 and qt5-dev both installed to be able to compile stuff with it... Maybe -staging (like wine-staging), or -latest? Probably a bad idea to call it -current (that name's obviously already used for something else). From dave at dawoodfall.net Sun Aug 5 09:44:23 2018 From: dave at dawoodfall.net (David Woodfall) Date: Sun, 5 Aug 2018 10:44:23 +0100 Subject: [Slackbuilds-users] qt5 is sorely in need of an update In-Reply-To: References: <20180715090718.GE29592@blackswan> <20180725085721.01cbfd07@Akita.witch.org> <20180731215721.GB9697@blackswan> <20180805060903.GA6543@blackswan> Message-ID: <20180805094423.GB6543@blackswan> On Sunday 5 August 2018 04:35, B Watson put forth the proposition: > On 8/5/18, David Woodfall wrote: > > > > Rather than legacy I'm thinking LTS ought to be the base branch, then > > a -dev to keep up with the latest. LTS is around 5.9.6 for Qt itself. > > Ugh, don't call it -dev, you'll confuse new users coming from > Debian/Redhat. They'll think it's the "development" package, and that > they need qt5 and qt5-dev both installed to be able to compile stuff > with it... > > Maybe -staging (like wine-staging), or -latest? Probably a bad idea to > call it -current (that name's obviously already used for something else). Good point. My thoughts are at the moment - update Qt5 to LTS, add the -staging (or whatever) package, and not bother with -legacy unless someone actually has something that really needs 5.7.1, then I'll add it back in. IIRC sip and PyQt5 don't have any kind of LTS versions, but I've used whatever stable versions have been on the guy's site, and they seem to work with everything I've built so far. As for qt5-webkit, I'll try to find what is the LTS version, if there is one, but I'd advise anyone wanting to use it to only use it for projects that need some kind of embedded browser for local files etc. It has too many holes in it to use on the internet at large. For that I'd recommend my qt5-webkit-annulen if possible, but even that is going to be dropped by eg qutebrowser because webengine (the bundled Qt5 browser engine) is more up-to-date and keeps up-to-date with security patches etc. (it has 3rd party Chromium code for one thing). -- ...Unix, MS-DOS, and Windows NT (also known as the Good, the Bad, and the Ugly). -- Matt Welsh .--. oo (____)// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~' From davidnchmelik at gmail.com Tue Aug 7 04:57:06 2018 From: davidnchmelik at gmail.com (David Melik) Date: Mon, 6 Aug 2018 21:57:06 -0700 Subject: [Slackbuilds-users] long-time build errors (open-adventure, notepadqq, sbocheck of adobe-reader & VariCAD) Message-ID: <3658138d-8319-9ff5-cc6e-5b7af783555e@gmail.com> Notepadqq won't work when there's a libwebp version after 0.5.n, though not a dependency (and not dependency of a dependency?)? The maintainer said recompile with a new libwebp.? I did, then notepadqq wouldn't run, and I notified him, but didn't hear back (months ago.)? People need libwebp updated for other SBo packages, so we can't have 'dependency Hell' starting. I have adobe-reader and sbocheck always says it has to be rebuilt as 9.5.5 rather than the current 9.5.5_enu. I have VariCAD and and sbocheck always says it has to be rebuilt for 2013_2.01 rather than the current 2013_2.01_en. I get this error compiling open-adventure (for months.) cc -std=c99 -D_DEFAULT_SOURCE -DVERSION=\"1.4\" -O2 -fPIC -D_FORTIFY_SOURCE=2 -fstack-protector-all? -o advent main.o init.o actions.o score.o misc.o saveresume.o dungeon.o? -ledit -lncurses a2x --doctype manpage --format manpage advent.adoc ERROR: advent.adoc: line 1: malformed manpage title ERROR: advent.adoc: line 4: first section must be named NAME ERROR: advent.adoc: line 7: second section must be named SYNOPSIS a2x: failed: asciidoc --doctype=manpage? -d manpage -b docbook "advent.adoc" Makefile:68: recipe for target 'advent.6' failed make: *** [advent.6] Error 1 -- Sincerely, David From matteo.bernardini at gmail.com Tue Aug 7 05:37:34 2018 From: matteo.bernardini at gmail.com (Matteo Bernardini) Date: Tue, 7 Aug 2018 07:37:34 +0200 Subject: [Slackbuilds-users] long-time build errors (open-adventure, notepadqq, sbocheck of adobe-reader & VariCAD) In-Reply-To: <3658138d-8319-9ff5-cc6e-5b7af783555e@gmail.com> References: <3658138d-8319-9ff5-cc6e-5b7af783555e@gmail.com> Message-ID: 2018-08-07 6:57 GMT+02:00 David Melik : > Notepadqq won't work when there's a libwebp version after 0.5.n, though not > a dependency (and not dependency of a dependency?) The maintainer said > recompile with a new libwebp. I did, then notepadqq wouldn't run, and I > notified him, but didn't hear back (months ago.) People need libwebp > updated for other SBo packages, so we can't have 'dependency Hell' starting. > > I have adobe-reader and sbocheck always says it has to be rebuilt as 9.5.5 > rather than the current 9.5.5_enu. > I have VariCAD and and sbocheck always says it has to be rebuilt for > 2013_2.01 rather than the current 2013_2.01_en. > > I get this error compiling open-adventure (for months.) > > cc -std=c99 -D_DEFAULT_SOURCE -DVERSION=\"1.4\" -O2 -fPIC > -D_FORTIFY_SOURCE=2 -fstack-protector-all -o advent main.o init.o > actions.o score.o misc.o saveresume.o dungeon.o -ledit -lncurses > a2x --doctype manpage --format manpage advent.adoc > ERROR: advent.adoc: line 1: malformed manpage title > ERROR: advent.adoc: line 4: first section must be named NAME > ERROR: advent.adoc: line 7: second section must be named SYNOPSIS > a2x: failed: asciidoc --doctype=manpage -d manpage -b docbook > "advent.adoc" > Makefile:68: recipe for target 'advent.6' failed > make: *** [advent.6] Error 1 Hi David, I've just tried building open-adventure and its dependencies (libedit ad PyYAML) here on a clean and full installation of slackware64-14.2 and I don't have the error you got when a2x (part of linuxdoc-tools) processes its man page. I'm now trying a build of notepadqq and all of its dependencies, having previously installed libwebp, but it will take a little: libwebp it's an optional dependency of qt5-webkit, so I thought that building all of the notepadqq dependencies from scratch might help. I can't answer about sbocheck because I never used it. Matteo P.S. I've tried on stable because that's the supported platform, I don't know if you're running current. From matteo.bernardini at gmail.com Tue Aug 7 07:47:49 2018 From: matteo.bernardini at gmail.com (Matteo Bernardini) Date: Tue, 7 Aug 2018 09:47:49 +0200 Subject: [Slackbuilds-users] long-time build errors (open-adventure, notepadqq, sbocheck of adobe-reader & VariCAD) In-Reply-To: References: <3658138d-8319-9ff5-cc6e-5b7af783555e@gmail.com> Message-ID: 2018-08-07 7:37 GMT+02:00 Matteo Bernardini : > 2018-08-07 6:57 GMT+02:00 David Melik : >> Notepadqq won't work when there's a libwebp version after 0.5.n, though not >> a dependency (and not dependency of a dependency?) The maintainer said >> recompile with a new libwebp. I did, then notepadqq wouldn't run, and I >> notified him, but didn't hear back (months ago.) People need libwebp >> updated for other SBo packages, so we can't have 'dependency Hell' starting. > I'm now trying a build of notepadqq and all of its dependencies, > having previously installed libwebp, but it will take a little: > libwebp it's an optional dependency of qt5-webkit, so I thought that > building all of the notepadqq dependencies from scratch might help. small correction: libwebp is an optional dependency also of qt5, so rebuilding that too might help. BTW, I tested notepadqq and it seems to work fine: I've had just to let it be found in $PATH because it gets installed in /opt, so I committed a little change to the SlackBuild (you might want to apply that too to your local copy) https://git.slackbuilds.org/slackbuilds/commit/?id=289c395b7bf6d2e2c5b7b237c790ac4a79024ea4 Matteo From matteo.bernardini at gmail.com Tue Aug 7 07:52:31 2018 From: matteo.bernardini at gmail.com (Matteo Bernardini) Date: Tue, 7 Aug 2018 09:52:31 +0200 Subject: [Slackbuilds-users] long-time build errors (open-adventure, notepadqq, sbocheck of adobe-reader & VariCAD) In-Reply-To: References: <3658138d-8319-9ff5-cc6e-5b7af783555e@gmail.com> Message-ID: 2018-08-07 9:47 GMT+02:00 Matteo Bernardini : > https://git.slackbuilds.org/slackbuilds/commit/?id=289c395b7bf6d2e2c5b7b237c790ac4a79024ea4 sorry for the confusion, the right commit id is the one below https://git.slackbuilds.org/slackbuilds/commit/?id=bd0b18b04eefe24b7f3f435051427b6ae0ec1669 Matteo From yalhcru at gmail.com Tue Aug 7 08:48:58 2018 From: yalhcru at gmail.com (B Watson) Date: Tue, 7 Aug 2018 04:48:58 -0400 Subject: [Slackbuilds-users] long-time build errors (open-adventure, notepadqq, sbocheck of adobe-reader & VariCAD) In-Reply-To: <3658138d-8319-9ff5-cc6e-5b7af783555e@gmail.com> References: <3658138d-8319-9ff5-cc6e-5b7af783555e@gmail.com> Message-ID: On 8/7/18, David Melik wrote: > > I get this error compiling open-adventure (for months.) > > cc -std=c99 -D_DEFAULT_SOURCE -DVERSION=\"1.4\" -O2 -fPIC > -D_FORTIFY_SOURCE=2 -fstack-protector-all -o advent main.o init.o > actions.o score.o misc.o saveresume.o dungeon.o -ledit -lncurses > a2x --doctype manpage --format manpage advent.adoc > ERROR: advent.adoc: line 1: malformed manpage title > ERROR: advent.adoc: line 4: first section must be named NAME > ERROR: advent.adoc: line 7: second section must be named SYNOPSIS > a2x: failed: asciidoc --doctype=manpage -d manpage -b docbook > "advent.adoc" > Makefile:68: recipe for target 'advent.6' failed > make: *** [advent.6] Error 1 open-adventure is mine... this is the first time I've seen this error, if you reported it before I must have missed it somehow. I can't duplicate your error. I just now built open-adventure on 3 14.2 systems: one 64-bit with lots of extra junk installed, one 64-bit clean system (full install of Slackware, all updates applied with 'slackpkg upgrade-all', nothing extra from SBo or anywhere else), and one 32-bit clean system (same as the 64-bit). It builds correctly on all 3 systems. I even tried it on -current, and it built fine (though if it didn't, I wouldn't care much, I have enough work to do keeping my stuff working on 14.2). I got 2 volunteers on IRC to attempt to build it, and it builds correctly for both of them, too. So something's different between your system and ours... something that renders the a2x command broken, or at least different from what open-adventure was written for. We have to figure out what it is, and fix it. The command that's failing is "a2x". The a2x command comes from the linuxdoc-tools package. What version of this package do you have installed? On both 64-bit boxes: $ cd /var/log/packages/ $ ls linuxdoc-tools* linuxdoc-tools-0.9.69-x86_64-5 My 32-bit system is the same version also (of course i586, not x86_64). Another thought: what do you get from running this command? ls -l `which a2x` You should get: $ ls -l `which a2x` lrwxrwxrwx 1 root root 6 Jul 19 2016 /usr/bin/a2x -> a2x.py* ...Possibly the time/date might be different. If you get anything else, especially a mention of /usr/local/, then you're not using the official Slackware version of a2x... From davidnchmelik at gmail.com Wed Aug 8 04:15:46 2018 From: davidnchmelik at gmail.com (David Melik) Date: Tue, 7 Aug 2018 21:15:46 -0700 Subject: [Slackbuilds-users] long-time build errors (open-adventure, notepadqq, sbocheck of adobe-reader & VariCAD) Message-ID: <2d82813d-ae22-51c0-b766-d54f8d18511c@gmail.com> Matteo Bernardini wrote: >small correction: libwebp is an optional dependency also of qt5, so >rebuilding that too might help [...] Makes sense now.? Recently I hneed libwebp 0.5.1 for kingbeowulf's not- yet-submitted BOINC SlackBuild so might wait until it updates, or might test rebuilding notepadqq and reinstall. I'd like to see notepadqq replace KATE, which has inadequate/broken tab bars. B Watson wrote: >[...] Another thought: what do you get from running this command? >ls -l `which a2x` > >You should get: > >$ ls -l `which a2x` >lrwxrwxrwx 1 root root 6 Jul 19? 2016 /usr/bin/a2x -> a2x.py* > >...Possibly the time/date might be different. > >If you get anything else, especially a mention of /usr/local/, then >you're not using the official Slackware version of a2x... Except for year, it was the same.? The year looked too old (2007) so I reinstalled that package then successfully built open-adventure.? I have no idea what SlackBuild would've installed an old version. My replies didn't show up on Gmane earlier.? I guess it's still read- only? From yalhcru at gmail.com Wed Aug 8 04:34:52 2018 From: yalhcru at gmail.com (B Watson) Date: Wed, 8 Aug 2018 00:34:52 -0400 Subject: [Slackbuilds-users] long-time build errors (open-adventure, notepadqq, sbocheck of adobe-reader & VariCAD) In-Reply-To: <2d82813d-ae22-51c0-b766-d54f8d18511c@gmail.com> References: <2d82813d-ae22-51c0-b766-d54f8d18511c@gmail.com> Message-ID: On 8/8/18, David Melik wrote: > Except for year, it was the same. The year looked too old (2007) so I > reinstalled that package then successfully built open-adventure. I > have no idea what SlackBuild would've installed an old version. Good to know you got it working. From alik at ejik.org Wed Aug 8 12:02:16 2018 From: alik at ejik.org (Alexander Verbovetsky) Date: Wed, 08 Aug 2018 15:02:16 +0300 Subject: [Slackbuilds-users] jdk 404 Not Found Message-ID: <1533729736.3455939.1467385656.58FC28FE@webmail.messagingengine.com> Hello, jdk 8u172 is not found on the Oracle site. The current jdk is: ----- DOWNLOAD="http://download.oracle.com/otn-pub/java/jdk/8u181-b13/96a7b8442fe848ef90c96a2fad6ed6d1/jdk-8u181-linux-i586.tar.gz" MD5SUM="765539c51490081b1eb27382dd7e96b3" DOWNLOAD_x86_64="http://download.oracle.com/otn-pub/java/jdk/8u181-b13/96a7b8442fe848ef90c96a2fad6ed6d1/jdk-8u181-linux-x64.tar.gz" MD5SUM_x86_64="ef599e322eee42f6769991dd3e3b1a31" ----- Best regards, Alexander From willysr at slackbuilds.org Wed Aug 8 14:37:57 2018 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Wed, 8 Aug 2018 21:37:57 +0700 Subject: [Slackbuilds-users] pinta not starting In-Reply-To: <1150072718.4305350.1533708525798@mail.yahoo.com> References: <1150072718.4305350.1533708525798.ref@mail.yahoo.com> <1150072718.4305350.1533708525798@mail.yahoo.com> Message-ID: > I recently installed pinta but it fails to start with this message: > > Unhandled Exception: > System.InvalidOperationException: Type 'Pinta.Core.IExtension' not bound to an extension point. > > I am using Slackware 14.2, 32-bit. Hi Strahil I can confirm your issue, but i can't find any solution at this moment. It was probably caused by newer mono since mono switched to version 5.x while Pinta are not yet updated upstream. I even checked latest master branch, but still no luck. At this point, i'm open for solutions, but if i can't find any, i will probably drop this package soon. I will cc this to -users ML as well so they are aware of the situation. Thanks -- Willy Sudiarto Raharjo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From willysr at slackbuilds.org Wed Aug 8 14:59:18 2018 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Wed, 8 Aug 2018 21:59:18 +0700 Subject: [Slackbuilds-users] jdk 404 Not Found In-Reply-To: <1533729736.3455939.1467385656.58FC28FE@webmail.messagingengine.com> References: <1533729736.3455939.1467385656.58FC28FE@webmail.messagingengine.com> Message-ID: <2f0d6ff7-fdee-4054-7d1e-e34500ee6167@slackbuilds.org> > jdk 8u172 is not found on the Oracle site. The current jdk is: > ----- > DOWNLOAD="http://download.oracle.com/otn-pub/java/jdk/8u181-b13/96a7b8442fe848ef90c96a2fad6ed6d1/jdk-8u181-linux-i586.tar.gz" > MD5SUM="765539c51490081b1eb27382dd7e96b3" > DOWNLOAD_x86_64="http://download.oracle.com/otn-pub/java/jdk/8u181-b13/96a7b8442fe848ef90c96a2fad6ed6d1/jdk-8u181-linux-x64.tar.gz" > MD5SUM_x86_64="ef599e322eee42f6769991dd3e3b1a31" Thanks pushed to my branch -- Willy Sudiarto Raharjo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From kev4321 at fastmail.fm Wed Aug 8 18:39:34 2018 From: kev4321 at fastmail.fm (Kevin McCormick) Date: Wed, 8 Aug 2018 13:39:34 -0500 Subject: [Slackbuilds-users] libspatialite Message-ID: <32660852-1b97-3901-9a17-1b18e77990ff@fastmail.fm> 14.2 > Gis > libspatialite (4.2.0) Build failed: /tmp/SBo/libspatialite-4.2.0/src/.libs/libspatialite.so: undefined reference to `lw_vasprintf' Apparently the solution is described here: https://groups.google.com/forum/#!topic/spatialite-users/LuFirW-60q4 Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From kev4321 at fastmail.fm Wed Aug 8 19:38:24 2018 From: kev4321 at fastmail.fm (Kevin McCormick) Date: Wed, 8 Aug 2018 14:38:24 -0500 Subject: [Slackbuilds-users] libspatialite In-Reply-To: <32660852-1b97-3901-9a17-1b18e77990ff@fastmail.fm> References: <32660852-1b97-3901-9a17-1b18e77990ff@fastmail.fm> Message-ID: <4dfbcf62-0143-8703-7486-005a23c47041@fastmail.fm> The solution I used is in the libspatialite.Slackbuild file as modified: #!/bin/sh # Slackware build script for SpatiaLite # Copyright 2012-2015 Alexander Bruy # All rights reserved. # # Redistribution and use of this script, with or without modification, is # permitted provided that the following conditions are met: # # 1. Redistributions of this script must retain the above copyright #??? notice, this list of conditions and the following disclaimer. # #? THIS SOFTWARE IS PROVIDED BY THE AUTHOR "AS IS" AND ANY EXPRESS OR IMPLIED #? WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF #? MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.? IN NO #? EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, #? SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, #? PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; #? OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, #? WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR #? OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF #? ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. # ====== # SpatiaLite-0ff5d4bb96.tar.gz?? 0ff5d4bb96df117bfe53dc8ec8aae41be22d8732 # https://www.gaia-gis.it/fossil/libspatialite/info/0ff5d4bb96df117b # comment: releasing 4.3.0 "stable" # # rename SpatiaLite-0ff5d4bb96.tar.gz to libspatialite-4.3.0.tar.gz #? add variable PRGNAMDIR? (line 37 and 78) # ====== PRGNAM=libspatialite VERSION=${VERSION:-4.3.0} BUILD=${BUILD:-1} TAG=${TAG:-_SBo} # PRGNAMDIR=SpatiaLite-0ff5d4bb96 # if [ -z "$ARCH" ]; then ? case "$( uname -m )" in ??? i?86) ARCH=i486 ;; ??? arm*) ARCH=arm ;; ?????? *) ARCH=$( uname -m ) ;; ? esac fi CWD=$(pwd) TMP=${TMP:-/tmp/SBo} PKG=$TMP/package-$PRGNAM OUTPUT=${OUTPUT:-/tmp} if [ "$LWGEOM" = "yes" ] ; then ??? LWGEOM_SUPPORT="--enable-lwgeom" fi if [ "$ARCH" = "i486" ]; then ? SLKCFLAGS="-O2 -march=i486 -mtune=i686" ? LIBDIRSUFFIX="" elif [ "$ARCH" = "i686" ]; then ? SLKCFLAGS="-O2 -march=i686 -mtune=i686" ? LIBDIRSUFFIX="" elif [ "$ARCH" = "x86_64" ]; then ? SLKCFLAGS="-O2 -fPIC" ? LIBDIRSUFFIX="64" else ? SLKCFLAGS="-O2" ? LIBDIRSUFFIX="" fi set -e rm -rf $PKG mkdir -p $TMP $PKG $OUTPUT cd $TMP rm -rf $PRGNAM-$VERSION tar xvf $CWD/$PRGNAM-$VERSION.tar.gz #cd $PRGNAM-$VERSION cd $PRGNAMDIR chown -R root:root . find -L . \ ?\( -perm 777 -o -perm 775 -o -perm 750 -o -perm 711 -o -perm 555 \ ? -o -perm 511 \) -exec chmod 755 {} \; -o \ ?\( -perm 666 -o -perm 664 -o -perm 640 -o -perm 600 -o -perm 444 \ ? -o -perm 440 -o -perm 400 \) -exec chmod 644 {} \; CFLAGS="$SLKCFLAGS" \ CXXFLAGS="$SLKCFLAGS" \ LDFLAGS="-ldl" \ ./configure \ ? --prefix=/usr \ ? --libdir=/usr/lib${LIBDIRSUFFIX} \ ? --sysconfdir=/etc \ ? --docdir=/usr/doc/$PRGNAM-$VERSION \ ? --disable-static \ ? --enable-freexl \ ? $LWGEOM_SUPPORT \ ? --build=$ARCH-slackware-linux make make install DESTDIR=$PKG find $PKG -print0 | xargs -0 file | grep -e "executable" -e "shared object" | grep ELF \ ? | cut -f 1 -d : | xargs strip --strip-unneeded 2> /dev/null || true mkdir -p $PKG/usr/doc/$PRGNAM-$VERSION cp -a AUTHORS COPYING INSTALL README README.coverage spatialite-sql-latest.html \ ? $PKG/usr/doc/$PRGNAM-$VERSION cat $CWD/$PRGNAM.SlackBuild > $PKG/usr/doc/$PRGNAM-$VERSION/$PRGNAM.SlackBuild mkdir -p $PKG/install cat $CWD/slack-desc > $PKG/install/slack-desc cd $PKG /sbin/makepkg -l y -c n $OUTPUT/$PRGNAM-$VERSION-$ARCH-$BUILD$TAG.${PKGTYPE:-tgz} On 08/08/2018 01:39 PM, Kevin McCormick wrote: > 14.2 > Gis > libspatialite (4.2.0) > > Build failed: > /tmp/SBo/libspatialite-4.2.0/src/.libs/libspatialite.so: undefined > reference to `lw_vasprintf' > > Apparently the solution is described here: > https://groups.google.com/forum/#!topic/spatialite-users/LuFirW-60q4 > > Thanks > > > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - https://slackbuilds.org/faq/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kingbeowulf at gmail.com Wed Aug 8 20:17:13 2018 From: kingbeowulf at gmail.com (King Beowulf) Date: Wed, 8 Aug 2018 13:17:13 -0700 Subject: [Slackbuilds-users] sage up for grabs UNMAINTAINED Message-ID: <3e1d444e-dc99-0524-20f3-11b76b8838d0@gmail.com> All Anyone who wants to maintain SAGE can have it. I've tried to get a new version working for months. 1. Upstream does not want you to compile as root 2. All modules paths are hard coded during compile 3. relocatable package impossible? - I can't get it to work The devs want the end user to compile as user in $HOME, and so seem hostile to the idea that anyone might not. There are scripts etc to try to fix the directory paths to relocate the folder tree - they use one for the bre-built binary - but I can't get it to work, or generate one for Slackware I give up. I'm dropping this turd. Admins, Please remove my name/email from sage.info and mark as UNMAINTAINED. I'm tired of getting (hate)emails. Thanks Ed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: OpenPGP digital signature URL: From glenn.becker at gmail.com Wed Aug 8 20:22:10 2018 From: glenn.becker at gmail.com (Glenn Becker) Date: Wed, 8 Aug 2018 16:22:10 -0400 Subject: [Slackbuilds-users] sage up for grabs UNMAINTAINED In-Reply-To: <3e1d444e-dc99-0524-20f3-11b76b8838d0@gmail.com> References: <3e1d444e-dc99-0524-20f3-11b76b8838d0@gmail.com> Message-ID: Thanks for your work on this. I know that thing well enough to know it is a #$)*@#$@^T& behemoth. On Wed, Aug 8, 2018 at 4:17 PM, King Beowulf wrote: > All > > Anyone who wants to maintain SAGE can have it. I've tried to get a new > version working for months. > > 1. Upstream does not want you to compile as root > 2. All modules paths are hard coded during compile > 3. relocatable package impossible? - I can't get it to work > > The devs want the end user to compile as user in $HOME, and so seem > hostile to the idea that anyone might not. There are scripts etc to try > to fix the directory paths to relocate the folder tree - they use one > for the bre-built binary - but I can't get it to work, or generate one > for Slackware > > I give up. I'm dropping this turd. > > Admins, > Please remove my name/email from sage.info and mark as UNMAINTAINED. > I'm tired of getting (hate)emails. > > Thanks > Ed > > > > _______________________________________________ > 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 kev4321 at fastmail.fm Wed Aug 8 23:02:55 2018 From: kev4321 at fastmail.fm (Kevin McCormick) Date: Wed, 8 Aug 2018 18:02:55 -0500 Subject: [Slackbuilds-users] libspatialite In-Reply-To: <4dfbcf62-0143-8703-7486-005a23c47041@fastmail.fm> References: <32660852-1b97-3901-9a17-1b18e77990ff@fastmail.fm> <4dfbcf62-0143-8703-7486-005a23c47041@fastmail.fm> Message-ID: <58d9a193-45cd-f299-b223-4f8c5dbbf950@fastmail.fm> The reason it worked was I forgot to add LWGEOM=yes ./libspatialite.SlackBuild.? So my Spatiallite does not have the postgis link. error: /tmp/SBo/SpatiaLite-0ff5d4bb96/src/.libs/libspatialite.so: undefined reference to `lw_vasprintf' On 08/08/2018 02:38 PM, Kevin McCormick wrote: > The solution I used is in the libspatialite.Slackbuild file as modified: > #!/bin/sh > > # Slackware build script for SpatiaLite > # Copyright 2012-2015 Alexander Bruy > # All rights reserved. > # > # Redistribution and use of this script, with or without modification, is > # permitted provided that the following conditions are met: > # > # 1. Redistributions of this script must retain the above copyright > #??? notice, this list of conditions and the following disclaimer. > # > #? THIS SOFTWARE IS PROVIDED BY THE AUTHOR "AS IS" AND ANY EXPRESS OR > IMPLIED > #? WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF > #? MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE > DISCLAIMED.? IN NO > #? EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, > #? SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT > LIMITED TO, > #? PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR > PROFITS; > #? OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF > LIABILITY, > #? WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR > #? OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF > #? ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. > > # ====== > # SpatiaLite-0ff5d4bb96.tar.gz?? 0ff5d4bb96df117bfe53dc8ec8aae41be22d8732 > # https://www.gaia-gis.it/fossil/libspatialite/info/0ff5d4bb96df117b > # comment: releasing 4.3.0 "stable" > # > # rename SpatiaLite-0ff5d4bb96.tar.gz to libspatialite-4.3.0.tar.gz > #? add variable PRGNAMDIR? (line 37 and 78) > # ====== > PRGNAM=libspatialite > VERSION=${VERSION:-4.3.0} > BUILD=${BUILD:-1} > TAG=${TAG:-_SBo} > # > PRGNAMDIR=SpatiaLite-0ff5d4bb96 > # > if [ -z "$ARCH" ]; then > ? case "$( uname -m )" in > ??? i?86) ARCH=i486 ;; > ??? arm*) ARCH=arm ;; > ?????? *) ARCH=$( uname -m ) ;; > ? esac > fi > > CWD=$(pwd) > TMP=${TMP:-/tmp/SBo} > PKG=$TMP/package-$PRGNAM > OUTPUT=${OUTPUT:-/tmp} > > if [ "$LWGEOM" = "yes" ] ; then > ??? LWGEOM_SUPPORT="--enable-lwgeom" > fi > > if [ "$ARCH" = "i486" ]; then > ? SLKCFLAGS="-O2 -march=i486 -mtune=i686" > ? LIBDIRSUFFIX="" > elif [ "$ARCH" = "i686" ]; then > ? SLKCFLAGS="-O2 -march=i686 -mtune=i686" > ? LIBDIRSUFFIX="" > elif [ "$ARCH" = "x86_64" ]; then > ? SLKCFLAGS="-O2 -fPIC" > ? LIBDIRSUFFIX="64" > else > ? SLKCFLAGS="-O2" > ? LIBDIRSUFFIX="" > fi > > set -e > > rm -rf $PKG > mkdir -p $TMP $PKG $OUTPUT > cd $TMP > rm -rf $PRGNAM-$VERSION > tar xvf $CWD/$PRGNAM-$VERSION.tar.gz > #cd $PRGNAM-$VERSION > cd $PRGNAMDIR > chown -R root:root . > find -L . \ > ?\( -perm 777 -o -perm 775 -o -perm 750 -o -perm 711 -o -perm 555 \ > ? -o -perm 511 \) -exec chmod 755 {} \; -o \ > ?\( -perm 666 -o -perm 664 -o -perm 640 -o -perm 600 -o -perm 444 \ > ? -o -perm 440 -o -perm 400 \) -exec chmod 644 {} \; > > CFLAGS="$SLKCFLAGS" \ > CXXFLAGS="$SLKCFLAGS" \ > LDFLAGS="-ldl" \ > ./configure \ > ? --prefix=/usr \ > ? --libdir=/usr/lib${LIBDIRSUFFIX} \ > ? --sysconfdir=/etc \ > ? --docdir=/usr/doc/$PRGNAM-$VERSION \ > ? --disable-static \ > ? --enable-freexl \ > ? $LWGEOM_SUPPORT \ > ? --build=$ARCH-slackware-linux > > make > make install DESTDIR=$PKG > > find $PKG -print0 | xargs -0 file | grep -e "executable" -e "shared > object" | grep ELF \ > ? | cut -f 1 -d : | xargs strip --strip-unneeded 2> /dev/null || true > > mkdir -p $PKG/usr/doc/$PRGNAM-$VERSION > cp -a AUTHORS COPYING INSTALL README README.coverage > spatialite-sql-latest.html \ > ? $PKG/usr/doc/$PRGNAM-$VERSION > cat $CWD/$PRGNAM.SlackBuild > > $PKG/usr/doc/$PRGNAM-$VERSION/$PRGNAM.SlackBuild > > mkdir -p $PKG/install > cat $CWD/slack-desc > $PKG/install/slack-desc > > cd $PKG > /sbin/makepkg -l y -c n > $OUTPUT/$PRGNAM-$VERSION-$ARCH-$BUILD$TAG.${PKGTYPE:-tgz} > > > On 08/08/2018 01:39 PM, Kevin McCormick wrote: >> 14.2 > Gis > libspatialite (4.2.0) >> >> Build failed: >> /tmp/SBo/libspatialite-4.2.0/src/.libs/libspatialite.so: undefined >> reference to `lw_vasprintf' >> >> Apparently the solution is described here: >> https://groups.google.com/forum/#!topic/spatialite-users/LuFirW-60q4 >> >> Thanks >> >> >> _______________________________________________ >> SlackBuilds-users mailing list >> SlackBuilds-users at slackbuilds.org >> https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users >> Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ >> FAQ - https://slackbuilds.org/faq/ >> > > > > _______________________________________________ > 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 fellype at gmail.com Thu Aug 9 14:37:11 2018 From: fellype at gmail.com (Fellype do Nascimento) Date: Thu, 9 Aug 2018 11:37:11 -0300 Subject: [Slackbuilds-users] sage up for grabs UNMAINTAINED In-Reply-To: <3e1d444e-dc99-0524-20f3-11b76b8838d0@gmail.com> References: <3e1d444e-dc99-0524-20f3-11b76b8838d0@gmail.com> Message-ID: <9d4f6839-8a40-d700-e4ac-8fd997936428@gmail.com> On 08/08/2018 05:17 PM, King Beowulf wrote: > 1. Upstream does not want you to compile as root > 2. All modules paths are hard coded during compile > 3. relocatable package impossible? - I can't get it to work > > The devs want the end user to compile as user in $HOME, and so seem > hostile to the idea that anyone might not. There are scripts etc to try > to fix the directory paths to relocate the folder tree - they use one > for the bre-built binary - but I can't get it to work, or generate one > for Slackware > > I give up. I'm dropping this turd. Just a tip for anyone interested in take over maintenance for sage: The AUR guys have made efforts to get the latest version (git) working on Arch Linux (https://aur.archlinux.org/packages/sagemath-git/). Well... there are up to 16 patches applied in order to get sage working :-P Good look for the next sage maintainer... > I'm tired of getting (hate)emails. It's sad to hear this kind of thing. When a SlackBuild script doesn't work I don't blame its maintainer because I know that some environmental variables can affect the build (e.g.: mix SBo packages with software from other 3rdparty repos). I've never tried to build sage from source because I have an underpowered machine, and as I would install the sage just out of curiosity it's not worth the effort. Best wishes, -- Dr. Fellype do Nascimento - fellype (at) gmail.com Center for Semiconductor Components and Nanotechnologies / Laborat?rio de Plasmas State University of Campinas, C.P. 6101, Rua Jo?o Pandia Calogeras, No.90, Cidade Universit?ria Zeferino Vaz, Campinas, SP, 13083-870, Brazil Fone/Phone: +55 19 35217321 -------------- next part -------------- An HTML attachment was scrubbed... URL: From kev4321 at fastmail.fm Thu Aug 9 17:43:25 2018 From: kev4321 at fastmail.fm (Kevin McCormick) Date: Thu, 9 Aug 2018 12:43:25 -0500 Subject: [Slackbuilds-users] ORFEO Toolbox (OTB) Message-ID: <8c73d4d6-b3f8-00e5-52fe-74ad02c292ba@fastmail.fm> Build failed for OTB: OTB 6.6.0 undefined reference to `cblas_dgemm' After installing "cblas" (in addition to the other requirements) the build was successful.? The requirements list "blas" but not "cblas." I did not set the MONTEVERDI=ON switch. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From kingbeowulf at gmail.com Thu Aug 9 17:52:29 2018 From: kingbeowulf at gmail.com (King Beowulf) Date: Thu, 9 Aug 2018 10:52:29 -0700 Subject: [Slackbuilds-users] sage up for grabs UNMAINTAINED In-Reply-To: <9d4f6839-8a40-d700-e4ac-8fd997936428@gmail.com> References: <3e1d444e-dc99-0524-20f3-11b76b8838d0@gmail.com> <9d4f6839-8a40-d700-e4ac-8fd997936428@gmail.com> Message-ID: On 08/09/2018 07:37 AM, Fellype do Nascimento wrote: ..snip... > Just a tip for anyone interested in take over maintenance for sage: > The AUR guys have made efforts to get the latest version (git) working > on Arch Linux (https://aur.archlinux.org/packages/sagemath-git/). > Well... there are up to 16 patches applied in order to get sage working :-P > Good look for the next sage maintainer... ...snip... 16? That's double from last I checked. It just doesn't make any sense to me do go to that trouble. It takes 4+ hrs on my best box to compile - too long a cycle for me to test patches. To have to patch in order to make a relocatable binary is just insane. Here's another tip for my successor - never could get this to work: https://github.com/sagemath/binary-pkg Just to clarify: Sagemath compile does work fine on Slackware stable and current as long as you build in the final target directory. I'm just a simple country chemist. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: OpenPGP digital signature URL: From kingbeowulf at gmail.com Fri Aug 10 01:57:03 2018 From: kingbeowulf at gmail.com (King Beowulf) Date: Thu, 9 Aug 2018 18:57:03 -0700 Subject: [Slackbuilds-users] Smath Studio source archive (ponce.cc) Message-ID: <6466c8e9-5852-83d4-5589-f7370703c61e@gmail.com> The older archives are graciously hosted at ponce.cc and if he would be so kind as to grab the new Smath Studio "source": https://smath.info/file/BaH5L/SMathStudioDesktop.0_99_6671.Mono.tar.gz so that wget can get the file and we can avoid the asshattery of the smath web site download. Thanks Ed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: OpenPGP digital signature URL: From dpross1100 at msn.com Fri Aug 10 02:22:56 2018 From: dpross1100 at msn.com (Daniel Prosser) Date: Fri, 10 Aug 2018 02:22:56 +0000 Subject: [Slackbuilds-users] sage up for grabs UNMAINTAINED In-Reply-To: References: <3e1d444e-dc99-0524-20f3-11b76b8838d0@gmail.com> <9d4f6839-8a40-d700-e4ac-8fd997936428@gmail.com> Message-ID: Perhaps if upstream is fighting so hard to make it *not* possible to package sage, the best course of action is just to honor their intent and stop trying (take it off SBo). Just my two cents as someone who does not use it anyway (so maybe it's actually only worth one cent). Dan On Thursday, August 09, 2018 10:52:29 AM King Beowulf wrote: > On 08/09/2018 07:37 AM, Fellype do Nascimento wrote: > ..snip... > > > Just a tip for anyone interested in take over maintenance for sage: > > The AUR guys have made efforts to get the latest version (git) working > > on Arch Linux (https://aur.archlinux.org/packages/sagemath-git/). > > Well... there are up to 16 patches applied in order to get sage working > > :-P > > Good look for the next sage maintainer... > > ...snip... > > 16? That's double from last I checked. It just doesn't make any sense > to me do go to that trouble. It takes 4+ hrs on my best box to compile > - too long a cycle for me to test patches. To have to patch in order to > make a relocatable binary is just insane. > > Here's another tip for my successor - never could get this to work: > https://github.com/sagemath/binary-pkg > > Just to clarify: > > Sagemath compile does work fine on Slackware stable and current as long > as you build in the final target directory. > > I'm just a simple country chemist. From matteo.bernardini at gmail.com Fri Aug 10 04:50:15 2018 From: matteo.bernardini at gmail.com (Matteo Bernardini) Date: Fri, 10 Aug 2018 06:50:15 +0200 Subject: [Slackbuilds-users] Smath Studio source archive (ponce.cc) In-Reply-To: <6466c8e9-5852-83d4-5589-f7370703c61e@gmail.com> References: <6466c8e9-5852-83d4-5589-f7370703c61e@gmail.com> Message-ID: Il giorno ven 10 ago 2018 alle ore 03:57 King Beowulf ha scritto: > > The older archives are graciously hosted at ponce.cc and if he would be > so kind as to grab the new Smath Studio "source": > > https://smath.info/file/BaH5L/SMathStudioDesktop.0_99_6671.Mono.tar.gz > > so that wget can get the file and we can avoid the asshattery of the > smath web site download. np, it's there! http://ponce.cc/slackware/sources/repo/SMathStudioDesktop.0_99_6671.Mono.tar.gz Matteo From lists at osh.id.au Fri Aug 10 06:50:19 2018 From: lists at osh.id.au (David O'Shaughnessy) Date: Fri, 10 Aug 2018 16:50:19 +1000 Subject: [Slackbuilds-users] Retire MD5 for SHA256 Message-ID: <2d8230f0-78c0-c23f-a9db-3953537434e0@osh.id.au> Hi everyone, since SBo relies on maintainers to individually verify the authenticity of source archives (i.e., check the signature and provide a checksum), the user's link to upstream verification rests on the SBo published checksum. Given that MD5 is badly broken, would it not be more prudent to publish a SHA256 instead? I understand that MD5 is useful for checking for unintentionally corrupted downloads, but it seems to leave open the possibility for a subsequently maliciously altered archive (i.e., one that uses hash collisions to produce the same MD5, but which would fail a GPG signature check). Perhaps something to consider for the 15.0 set? https://en.wikipedia.org/wiki/MD5 http://www.stopusingmd5now.com/home -- Dave From yalhcru at gmail.com Fri Aug 10 07:24:47 2018 From: yalhcru at gmail.com (B Watson) Date: Fri, 10 Aug 2018 03:24:47 -0400 Subject: [Slackbuilds-users] Retire MD5 for SHA256 In-Reply-To: <2d8230f0-78c0-c23f-a9db-3953537434e0@osh.id.au> References: <2d8230f0-78c0-c23f-a9db-3953537434e0@osh.id.au> Message-ID: On 8/10/18, David O'Shaughnessy wrote: > > I understand that MD5 is useful for checking for unintentionally > corrupted downloads, but it seems to leave open the possibility for a > subsequently maliciously altered archive (i.e., one that uses hash > collisions to produce the same MD5, but which would fail a GPG signature > check). This comes up from time to time... I personally am not opposed to it, theoretically it's a good idea, but it'd be a good bit of work for everyone (admins, maintainers, even users would be impacted). What might be feasible: have each maintainer GPG sign the source files and include detached signatures (.asc) in the SlackBuild directory. Would require a way for users to get the maintainers' public keys, but there are public keyservers (and we could do the 'web of trust' thing by signing each others' pub keys). The .info file format wouldn't have to change at all. We'd just start having one or more small .asc files included with the builds. Automated tools could check for them and verify the signatures after the download. If there's no signature, it would just say so, and continue the build. Doing it this way puts the burden on the individual SlackBuild maintainers instead of adding *yet more* work to the admins' workload, and it'd stay backwards compatible... Now that I think of it, this isn't at all my idea, someone on IRC was talking about it. Are you the same person? If so, congratulations, you sold me on the idea well enough that now I'm trying to sell it back to you :) From dickson.tim at googlemail.com Fri Aug 10 13:24:55 2018 From: dickson.tim at googlemail.com (Tim Dickson) Date: Fri, 10 Aug 2018 14:24:55 +0100 Subject: [Slackbuilds-users] Retire MD5 for SHA256 In-Reply-To: References: <2d8230f0-78c0-c23f-a9db-3953537434e0@osh.id.au> Message-ID: <1e46e326-3c80-a085-f65a-4fa8b4b5d0ca@googlemail.com> my 2cents worth... if it aint broke... well, the argument is that it is broke, but... using hash collisions? means either the source can be compromised, in which case it is not reliable, or the compromise is done on the network, in which case the network is not reliable. ?If either network or source are not reliable, then the expected checksum - whatever method used could simply be set to match the interfered-with source code, so the attacker would not need to "crack" the checksum, they could just make what was visible match their version of the compromised source. In other words, as a basic download file corruption check, md5 is simple and convenient; any other assumptions about security depend on other variables far more than the type of checksum used. On 10/08/2018 08:24, B Watson wrote: > On 8/10/18, David O'Shaughnessy wrote: >> I understand that MD5 is useful for checking for unintentionally >> corrupted downloads, but it seems to leave open the possibility for a >> subsequently maliciously altered archive (i.e., one that uses hash >> collisions to produce the same MD5, but which would fail a GPG signature >> check). > This comes up from time to time... I personally am not opposed to it, > theoretically it's a good idea, but it'd be a good bit of work for > everyone (admins, maintainers, even users would be impacted). > > What might be feasible: have each maintainer GPG sign the source files > and include detached signatures (.asc) in the SlackBuild directory. > Would require a way for users to get the maintainers' public keys, > but there are public keyservers (and we could do the 'web of trust' > thing by signing each others' pub keys). > > The .info file format wouldn't have to change at all. We'd just start > having one or more small .asc files included with the builds. Automated > tools could check for them and verify the signatures after the download. > If there's no signature, it would just say so, and continue the build. > > Doing it this way puts the burden on the individual SlackBuild maintainers > instead of adding *yet more* work to the admins' workload, and it'd stay > backwards compatible... > > Now that I think of it, this isn't at all my idea, someone on IRC was > talking about it. Are you the same person? If so, congratulations, you > sold me on the idea well enough that now I'm trying to sell it back to > you :) > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - https://slackbuilds.org/faq/ > > From strahilski at yahoo.com Thu Aug 9 11:39:22 2018 From: strahilski at yahoo.com (Strahil Yordanov) Date: Thu, 9 Aug 2018 11:39:22 +0000 (UTC) Subject: [Slackbuilds-users] pinta not starting References: <1827105523.4977976.1533814762420.ref@mail.yahoo.com> Message-ID: <1827105523.4977976.1533814762420@mail.yahoo.com> Hi Willy, How about you put a link to an older mono on pinta's slackbuld? At least until a better solution is available. I am aware that this might mean creating a separate slackbuild for an older mono ... ;) Regards, Strahil -------------------------------------------- On Wed, 8/8/18, Willy Sudiarto Raharjo wrote: Subject: Re: pinta not starting To: "Strahil Yordanov" , "SlackBuilds.org Users List" Date: Wednesday, August 8, 2018, 2:37 PM > I recently installed pinta but it fails to start with this message: > > Unhandled Exception: > System.InvalidOperationException: Type 'Pinta.Core.IExtension' not bound to an extension point. > > I am using Slackware 14.2, 32-bit. Hi Strahil I can confirm your issue, but i can't find any solution at this moment. It was probably caused by newer mono since mono switched to version 5.x while Pinta are not yet updated upstream. I even checked latest master branch, but still no luck. At this point, i'm open for solutions, but if i can't find any, i will probably drop this package soon. I will cc this to -users ML as well so they are aware of the situation. Thanks -- Willy Sudiarto Raharjo From skaendo at excite.com Fri Aug 10 16:36:15 2018 From: skaendo at excite.com (Ed Ender) Date: Fri, 10 Aug 2018 12:36:15 -0400 Subject: [Slackbuilds-users] pinta not starting Message-ID: <20180810123615.14294@web005.roc2.bluetie.com> I have a SlackBuild for mono-4.8.1.0 that I use. I only did a version bump from the 14.1 repo from version 4.2.2.10. 4.8.1.0 is the latest version that I can get to work with gtk-sharp or gnome-sharp (at least one of those 2). If someone wants to try it, it is here: https://github.com/skaendo/hackbuilds Ed -----Original Message----- From: "Strahil Yordanov via SlackBuilds-users" [slackbuilds-users at slackbuilds.org] Date: 08/10/2018 10:24 AM To: "Strahil Yordanov" , "SlackBuilds.org Users List" , "Willy Sudiarto Raharjo" CC: "Strahil Yordanov" Subject: Re: [Slackbuilds-users] pinta not starting Hi Willy, How about you put a link to an older mono on pinta's slackbuld? At least until a better solution is available. I am aware that this might mean creating a separate slackbuild for an older mono ... ;) Regards, Strahil -------------------------------------------- On Wed, 8/8/18, Willy Sudiarto Raharjo wrote: Subject: Re: pinta not starting To: "Strahil Yordanov" , "SlackBuilds.org Users List" Date: Wednesday, August 8, 2018, 2:37 PM > I recently installed pinta but it fails to start with this message: > > Unhandled Exception: > System.InvalidOperationException: Type 'Pinta.Core.IExtension' not bound to an extension point. > > I am using Slackware 14.2, 32-bit. Hi Strahil I can confirm your issue, but i can't find any solution at this moment. It was probably caused by newer mono since mono switched to version 5.x while Pinta are not yet updated upstream. I even checked latest master branch, but still no luck. At this point, i'm open for solutions, but if i can't find any, i will probably drop this package soon. I will cc this to -users ML as well so they are aware of the situation. Thanks -- Willy Sudiarto Raharjo _______________________________________________ SlackBuilds-users mailing list SlackBuilds-users at slackbuilds.org https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ FAQ - https://slackbuilds.org/faq/ From didier at slint.fr Fri Aug 10 17:23:40 2018 From: didier at slint.fr (Didier Spaier) Date: Fri, 10 Aug 2018 19:23:40 +0200 Subject: [Slackbuilds-users] sage up for grabs UNMAINTAINED In-Reply-To: References: <3e1d444e-dc99-0524-20f3-11b76b8838d0@gmail.com> <9d4f6839-8a40-d700-e4ac-8fd997936428@gmail.com> Message-ID: <107bc49a-f99c-22e0-889b-1644933f99cc@slint.fr> On 08/10/2018 04:22 AM, Daniel Prosser wrote: > Perhaps if upstream is fighting so hard to make it *not* possible to package > sage, the best course of action is just to honor their intent and stop trying > (take it off SBo). Just my two cents as someone who does not use it anyway (so > maybe it's actually only worth one cent). I am not an user either, but I once compiled it as regular user just to check its ability to make png files for graphs, for an actual (and blind) user. I just asked this friend, he is currently using the 8.1 version. As for maths there is nothing close to sage's features I'd suggest not providing a SlackBuild but a README explaining the situation. Just my 0.02?. From didier at slint.fr Fri Aug 10 17:26:14 2018 From: didier at slint.fr (Didier Spaier) Date: Fri, 10 Aug 2018 19:26:14 +0200 Subject: [Slackbuilds-users] sage up for grabs UNMAINTAINED In-Reply-To: <107bc49a-f99c-22e0-889b-1644933f99cc@slint.fr> References: <3e1d444e-dc99-0524-20f3-11b76b8838d0@gmail.com> <9d4f6839-8a40-d700-e4ac-8fd997936428@gmail.com> <107bc49a-f99c-22e0-889b-1644933f99cc@slint.fr> Message-ID: I forgot: his user a set specific user "maths" for that. On 08/10/2018 07:23 PM, Didier Spaier wrote: > > On 08/10/2018 04:22 AM, Daniel Prosser wrote: >> Perhaps if upstream is fighting so hard to make it *not* possible to package >> sage, the best course of action is just to honor their intent and stop trying >> (take it off SBo). Just my two cents as someone who does not use it anyway (so >> maybe it's actually only worth one cent). > > I am not an user either, but I once compiled it as regular user just to check > its ability to make png files for graphs, for an actual (and blind) user. > I just asked this friend, he is currently using the 8.1 version. > > As for maths there is nothing close to sage's features I'd suggest > not providing a SlackBuild but a README explaining the situation. > > Just my 0.02?. > _______________________________________________ > 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 Fri Aug 10 23:58:36 2018 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sat, 11 Aug 2018 06:58:36 +0700 Subject: [Slackbuilds-users] pinta not starting In-Reply-To: <1827105523.4977976.1533814762420@mail.yahoo.com> References: <1827105523.4977976.1533814762420.ref@mail.yahoo.com> <1827105523.4977976.1533814762420@mail.yahoo.com> Message-ID: > How about you put a link to an older mono on pinta's slackbuld? At least until a better solution is available. I am aware that this might mean creating a separate slackbuild for an older mono ... ;) I'm removing it from SBo at this point since i'm not going to ask for another mono script :) Feel free to resubmit and take over if you are interested to build older mono and Pinta -- Willy Sudiarto Raharjo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From willysr at slackbuilds.org Sat Aug 11 00:39:03 2018 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sat, 11 Aug 2018 07:39:03 +0700 Subject: [Slackbuilds-users] Updates - 20180811.1 Message-ID: <4b02fe96-5c3c-8538-5445-d5343f21ed04@slackbuilds.org> Here's summary for this week's work, thanks to all maintainers!! As you noticed, LibreOffice is still at 6.0.x, while libreoffice has been bumped to 6.1.x. Things should sync in the next week updates as LO 6.1 was just released yesterday and it may take time to test the script to build it from source. However there's a minor mistake while updating LibreOffice script. Christoph seems to forgot to update the MD5SUM for one of the source (libreoffice-6.0.6.2.tar.xz) which should be 3f6954b3f704afcb383daeadc4d783c8 Pinta is now dropped as it no longer build against latest mono/mono-addins, even the latest master branch. SAGE is also considered unmaintained for now. Feel free to grab if you found a solution to build newer version. Sat Aug 11 00:24:32 UTC 2018 academic/copasi: Fix DOWNLOAD_x86_64. academic/reduce-algebra: Updated for version 20180808svn4717. academic/sage: Unmaintained. academic/scilab: Updated for version 6.0.1. academic/stellarium: Updated for version 0.18.1. academic/veusz: Updated for version 3.0.1. accessibility/speech-dispatcher: Updated for version 0.8.8. audio/clementine: Updated for version 1.3.1_c7f3ae9. audio/mixxx: Updated for version 2.1.1, changed maintainer. audio/qastools: Switch homepage to https. audio/qmmp-plugin-pack-qt5: Updated for version 1.2.2. audio/qmmp-plugin-pack: Updated for version 0.11.2. audio/qmmp-qt5: Updated for version 1.2.3. audio/qmmp: Updated for version 0.11.2. audio/sunvox: Fix build. desktop/libqtxdg: Updated for version 3.2.0. desktop/py3status: Updated for version 3.12. development/CImg: Updated for version 2.3.3. development/PythonToolkit: Updated for version 18.08. development/ahven: Updated for version 2.7. development/alacritty: Updated for version git1adb5cb. development/beav: Added (curses-based binary/hex editor). development/bed: Added (ncurses-based binary/hex editor). development/cgit: Updated for version 1.2.1. development/dart: Updated for version 2.0.0. development/hexcurse: Added (ncurses-based hex editor). development/hexinator: Added (proprietary graphical hex editor). development/jdk: Updated for version 8u181. development/mono: Switch homepage to https. development/nchexedit: Added (ncurses-based hex editor). development/notepadqq: Allow the binary to be found in $PATH. development/pandas: Updated for version 0.23.4. development/processing: Updated for version 3.4. development/pudb: Changed options. development/rust: Updated for version 1.28.0. development/tweak: Added (ncurses-based hex editor). development/xvi: Added (tiny but full-featured vi clone). games/edgar: Switch homepage to https. games/javacpc: Updated for version 2.9.6f. games/nestopia: Updated for version 1.49. games/wesnoth: Updated for version 1.14.4. gis/geos: Updated for version 3.6.3. gis/mapnik: Switch homepage to https. gis/openorienteering-mapper: Switch homepage to https. gis/python-mapnik: Switch homepage to https. gis/rasterio: Updated for version 1.0.3. graphics/SweetHome3D: Updated for version 5.7. graphics/converseen: Updated for version 0.9.7. graphics/pinta: Removed (No longer build). libraries/BeautifulSoup4: Updated for version 4.6.1. libraries/DevIL: Updated for version 1.8.0. libraries/IMAPClient: Switch homepage to https. libraries/appstream-glib: Updated for version 0.7.11. libraries/gnome-python2-gconf: Change the stripping routine. libraries/gnome-sharp: Switch homepage to https. libraries/gtk-sharp: Switch homepage to https. libraries/libaom: Added (Open Source Video Codec). libraries/libtorrent-rasterbar: Updated for version 1.1.9. libraries/libwps: Updated for version 0.4.10. libraries/libxkbcommon: Updated for version 0.8.2. libraries/live555: Updated for version 2018.08.05 multimedia/mlt: Updated for version 6.10.0. network/TeamSpeak3: Updated for version 3.1.10. network/WireGuard: Updated for version 0.0.20180809. network/aMule: Updated for version 2.3.2. network/brave: Updated for version 0.23.79. network/filezilla: Updated for version 3.35.2. network/frostwire: Switch homepage to https. network/kvirc: Updated for version 20180605_8db6192, changed maint. network/netdiscover: Added (network address discovering tool). network/opera-developer: Updated for version 56.0.3037.0. network/opera: Updated for version 54.0.2952.71. network/prosody-mod-smacks: Updated for version hg3218. network/psi-plus: Updated for version 1.3.400. network/purple-plugin-pack: Patched for identifying on ngircd. network/signal-desktop: Updated for version 1.15.1. network/teamviewer: Updated for version 13.2.13582. network/vivaldi: Updated for version 1.15.1147.64. network/xbuffy: Added (a multi folder biff for X). network/you-get: Updated for version 0.4.1099. network/youtube-dl: Updated for version 2018.08.04. office/LibreOffice: Updated for version 6.0.6.2 office/MasterPDFEditor: Updated for version 5.1.12. office/ganttproject: Fix symlink. office/jstock: Updated for version 1.0.7.35. office/libreoffice-helppack: Updated for version 6.1.0. office/libreoffice-langpack: Updated for version 6.1.0. office/libreoffice: Updated for version 6.1.0. office/pdfpc: Updated for version 4.1.2 + new maintainer. office/smoffice2016: Switch homepage to https. office/smoffice2018: Switch homepage to https. office/texmacs: Updated for version 1.99.7. perl/perl-ExtUtils-ModuleMaker: Updated for version 0.63. perl/perl-Sidef: Updated for version 3.19. perl/perl-file-mimeinfo: Updated for version 0.29. perl/zef: Updated for version 0.4.6. python/Scrapy: Updated for version 1.5.1. python/astroid: Updated for version 2.0.4. python/ndg_httpsclient: Updated for version 0.5.1. python/packaging: Updated for version 17.1. python/pendulum: Updated for version 2.0.3. python/prompt_toolkit: Updated for version 2.0.4. python/pytest: Updated for version 3.7.1. python/python-scandir: Updated for version 1.8. python/python-urllib3: Updated for version 1.23. python/python3-lazy-object-proxy: Added (Python lazy object proxy). python/python3-wrapt: Added (A Python module for decorators). python/regex: Updated for version 2018.07.11. python/selenium: Updated for version 3.14.0. python/tox: Updated for version 3.1.2. python/werkzeug: Updated for version 0.14.1 + new maintainer. ruby/rubygem-ruby-progressbar: Updated for version 1.10.0. system/cabextract: Updated for version 1.7. system/epson-inkjet-printer-escpr: Updated for version 1.6.23. system/gtk-vnc: Update DEP. system/isdct: Updated for version 3.0.14. system/kbfs: Updated for version 2.6.0_20180810160058. system/keybase: Updated for version 2.5.0. system/lynis: Updated for version 2.6.7. system/mariadb-plugin-saslauthd: Updated for version 1.5. system/pspg: Updated for version 1.3.0. system/ranger: Changed option. system/ripgrep: Updated for version 0.9.0. system/spl-solaris: Switch homepage to https. system/wine: Updated for version 3.0.2. system/winetricks: Updated for version 20180603. system/xarchiver: Updated for version 0.5.4.13. system/zfs-on-linux: Switch homepage to https. +--------------------------+ -- Willy Sudiarto Raharjo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From alleytrotter at gmail.com Sat Aug 11 12:48:26 2018 From: alleytrotter at gmail.com (John Yost) Date: Sat, 11 Aug 2018 08:48:26 -0400 Subject: [Slackbuilds-users] LibreOffice sources Message-ID: <2e7d9d8c-b6fb-64a7-afd7-d428cd6b51ec@gmail.com> URL transformed to HTTPS due to an HSTS policy --2018-08-11 08:42:01-- https://sourceforge.net/projects/slackbuildsdirectlinks/files/LibreOffice/libreoffice-6.0.6.2-srcs.tar.xz Resolving sourceforge.net... 216.105.38.13 Connecting to sourceforge.net|216.105.38.13|:443... connected. HTTP request sent, awaiting response... 404 Not Found 2018-08-11 08:42:02 ERROR 404: Not Found. -- John David Yost AlleyTrotter pub 2048D/F3BDEB55 2014-05-23 [expires: Never] -------------- next part -------------- A non-text attachment was scrubbed... Name: 0x2C7AF6BEF3BDEB55.asc Type: application/pgp-keys Size: 2294 bytes Desc: not available URL: From chris.willing at iinet.net.au Sat Aug 11 13:33:16 2018 From: chris.willing at iinet.net.au (Christoph Willing) Date: Sat, 11 Aug 2018 23:33:16 +1000 Subject: [Slackbuilds-users] LibreOffice sources In-Reply-To: <2e7d9d8c-b6fb-64a7-afd7-d428cd6b51ec@gmail.com> References: <2e7d9d8c-b6fb-64a7-afd7-d428cd6b51ec@gmail.com> Message-ID: <402bea34-559d-1396-d81e-b32af6cb0dfc@iinet.net.au> On 11/08/18 22:48, John Yost wrote: > URL transformed to HTTPS due to an HSTS policy > --2018-08-11 08:42:01-- > https://sourceforge.net/projects/slackbuildsdirectlinks/files/LibreOffice/libreoffice-6.0.6.2-srcs.tar.xz > Resolving sourceforge.net... 216.105.38.13 > Connecting to sourceforge.net|216.105.38.13|:443... connected. > HTTP request sent, awaiting response... 404 Not Found > 2018-08-11 08:42:02 ERROR 404: Not Found. > Sorry about that - it's there now. However I've just submitted an update to the next version 6.1.0.3. You could either use the SlackBuild at: https://git.slackbuilds.org/slackbuilds/tree/office/LibreOffice?h=user/chris.willing/updates or simply replace the 6.0.6.2 version string wherever you see it in the existing SlackBuild with 6.1.0.3. chris From alleytrotter at gmail.com Sat Aug 11 13:41:32 2018 From: alleytrotter at gmail.com (John Yost) Date: Sat, 11 Aug 2018 09:41:32 -0400 Subject: [Slackbuilds-users] LibreOffice sources In-Reply-To: <402bea34-559d-1396-d81e-b32af6cb0dfc@iinet.net.au> References: <2e7d9d8c-b6fb-64a7-afd7-d428cd6b51ec@gmail.com> <402bea34-559d-1396-d81e-b32af6cb0dfc@iinet.net.au> Message-ID: On 08/11/2018 09:33 AM, Christoph Willing wrote: > On 11/08/18 22:48, John Yost wrote: >> URL transformed to HTTPS due to an HSTS policy >> --2018-08-11 08:42:01-- >> https://sourceforge.net/projects/slackbuildsdirectlinks/files/LibreOffice/libreoffice-6.0.6.2-srcs.tar.xz >> Resolving sourceforge.net... 216.105.38.13 >> Connecting to sourceforge.net|216.105.38.13|:443... connected. >> HTTP request sent, awaiting response... 404 Not Found >> 2018-08-11 08:42:02 ERROR 404: Not Found. >> > Sorry about that - it's there now. > > However I've just submitted an update to the next version 6.1.0.3. You > could either use the SlackBuild at: > > https://git.slackbuilds.org/slackbuilds/tree/office/LibreOffice?h=user/chris.willing/updates > or simply replace the 6.0.6.2 version string wherever you see it in the > existing SlackBuild with 6.1.0.3. > > chris > _______________________________________________ > 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/ > Thanks chris Using the new SlackBuild (6.1.0.3) now alleyTrotter From orbea at fredslev.dk Sat Aug 11 13:55:04 2018 From: orbea at fredslev.dk (orbea at fredslev.dk) Date: Sat, 11 Aug 2018 06:55:04 -0700 Subject: [Slackbuilds-users] ladspa_sdk sandbox violation and potential segfault Message-ID: <20180811065430.3cb9f493@Akita.witch.org> Hi, As reported in the "SBo scripts not building on current" thread at linuxquestions showed that the tests in the makefile can segfault. https://www.linuxquestions.org/questions/slackware-14/sbo-scripts-not-building-on-current-read-1st-post-pls-4175561999/page91.html#post5890532 Neither ponce or I could reproduce this, but I also noticed they are also sandbox violations which can be easily reproduced with: sandbox ./ladspa_sdk.SlackBuild http://slackbuilds.org/repository/14.2/system/sandbox/ The sandbox violations can be easily worked around by not building the tests, I suspect this would also prevent any segfaults. I have attached a patch for the SlackBuild which should accomplish this. In short: make \ Should be changed to: make targets \ Thanks, Hunter -------------- next part -------------- A non-text attachment was scrubbed... Name: ladspa_sdk.SlackBuild.patch Type: text/x-patch Size: 384 bytes Desc: not available URL: From orbea at fredslev.dk Sat Aug 11 14:20:19 2018 From: orbea at fredslev.dk (orbea at fredslev.dk) Date: Sat, 11 Aug 2018 07:20:19 -0700 Subject: [Slackbuilds-users] Missing and incorrect libreoffice dependencies. Message-ID: <20180811072019.2146d536@Akita.witch.org> Hi, Its been bugging me for a long time that the LibreOffice from source SlackBuild has both incorrect and many missing optional dependencies. The only required dependency is: perl-Archive-Zip The following dependencies are erroneously marked as required and libreoffice will either work fine without them or can provide their own internal versions. python3, apache-ant, openjdk Here is a list of dependencies available at SBo which libreoffice can use and are not currently listed. CoinMP, cppunit, glm, libabw, libcdr, libcmis, libe-book, libeot, libepubgen, libetonyek, libexttextcat, libfreehand, liblangtag, libmspub, libmwaw, liborcus, libpagemaker, libqxp, libstaroffice, libtommath, libwps, libzmf, lpsolve, mdds, mysql-connector-c++, mythes, postgresql, qt5, valgrind, ucpp Also an optional dependency which can not currently be used is: graphite2 It would require harfbuzz in the main tree to be rebuilt with graphite2. Additionally here is a list of optional dependencies in the main tree that libreoffice is not currently using: apr, bluez, bzip2, clucene, libepoxy, libodfgen, openldap-client Can this please be fixed? Thanks, Hunter From yalhcru at gmail.com Sat Aug 11 17:22:04 2018 From: yalhcru at gmail.com (B Watson) Date: Sat, 11 Aug 2018 13:22:04 -0400 Subject: [Slackbuilds-users] ladspa_sdk sandbox violation and potential segfault In-Reply-To: <20180811065430.3cb9f493@Akita.witch.org> References: <20180811065430.3cb9f493@Akita.witch.org> Message-ID: On 8/11/18, orbea at fredslev.dk wrote: > Hi, > > As reported in the "SBo scripts not building on current" thread at > linuxquestions showed that the tests in the makefile can segfault. > > https://www.linuxquestions.org/questions/slackware-14/sbo-scripts-not-building-on-current-read-1st-post-pls-4175561999/page91.html#post5890532 The user's very next post says "A reboot made things work again". So his system was in a screwed-up state. Probably any attempt to play audio with any application would have caused a segfault. Anyway, it's using sndfile-play to play the sound, so it would be sndfile-play segfaulting: not a ladspa_sdk issue at all. > Neither ponce or I could reproduce this, but I also noticed they are > also sandbox violations which can be easily reproduced with: > > sandbox ./ladspa_sdk.SlackBuild All I see are writes to /dev/snd/controlC0 (aka the alsa mixer device for card 0). sndfile-play is linked to libasound, which opens the control device for writing when it's initialized. Nothing to worry about. It's not creating garbage files in the filesystem. > I have attached a patch for the SlackBuild which should accomplish this. I wasn't going to apply your patch since I don't consider the 2 issues above to be real issues... but I thought of a reason to apply it: what if the build host hasn't got a sound card at all? Either because it's got a weird one that the kernel hasn't got a driver for, or because it's a VM and whoever set it up thought "a test build system doesn't need sound" so they didn't enable it... So thanks for looking into this, and I'll patch it in time for the next public update. From matteo.bernardini at gmail.com Sat Aug 11 18:01:48 2018 From: matteo.bernardini at gmail.com (Matteo Bernardini) Date: Sat, 11 Aug 2018 20:01:48 +0200 Subject: [Slackbuilds-users] ladspa_sdk sandbox violation and potential segfault In-Reply-To: References: <20180811065430.3cb9f493@Akita.witch.org> Message-ID: Il giorno sab 11 ago 2018 alle ore 19:22 B Watson ha scritto: > I wasn't going to apply your patch since I don't consider the 2 issues > above to be real issues... but I thought of a reason to apply it: what if > the build host hasn't got a sound card at all? Either because it's got a > weird one that the kernel hasn't got a driver for, or because it's a VM > and whoever set it up thought "a test build system doesn't need sound" > so they didn't enable it... I actually tested this while answering _lord and this is the output (build went fine): --------------------------------------------- First listen to the white noise input signal: --------------------------------------------- sndfile-play ../snd/noise.wav opensoundsys_open_device : open : No such file or directory Playing ../snd/noise.wav make: [makefile:53: test] Error 1 (ignored) ------------------------- Compare to plugin output. ------------------------- Should be a noise band around 6000Hz, repeated quietly after 1s. sndfile-play /tmp/test.wav opensoundsys_open_device : open : No such file or directory Playing /tmp/test.wav make: [makefile:58: test] Error 1 (ignored) Test complete. Matteo From yalhcru at gmail.com Sat Aug 11 18:09:19 2018 From: yalhcru at gmail.com (B Watson) Date: Sat, 11 Aug 2018 14:09:19 -0400 Subject: [Slackbuilds-users] ladspa_sdk sandbox violation and potential segfault In-Reply-To: References: <20180811065430.3cb9f493@Akita.witch.org> Message-ID: On 8/11/18, Matteo Bernardini wrote: > > I actually tested this while answering _lord and this is the output > (build went fine): > ... > opensoundsys_open_device : open : No such file or directory > Playing /tmp/test.wav > make: [makefile:58: test] Error 1 (ignored) > Test complete. Ah, patch not actually needed then, thanks. From slackbuilds at jaxartes.net Sat Aug 11 18:44:43 2018 From: slackbuilds at jaxartes.net (Benjamin Trigona-Harany) Date: Sat, 11 Aug 2018 11:44:43 -0700 Subject: [Slackbuilds-users] ORFEO Toolbox (OTB) In-Reply-To: <8c73d4d6-b3f8-00e5-52fe-74ad02c292ba@fastmail.fm> References: <8c73d4d6-b3f8-00e5-52fe-74ad02c292ba@fastmail.fm> Message-ID: <4333588.YfmZzQa9pV@wintermute.sprawl.net> On Thursday, 9 August 2018 10:43:25 PDT Kevin McCormick wrote: > Build failed for OTB: > OTB 6.6.0 undefined reference to `cblas_dgemm' > > After installing "cblas" (in addition to the other requirements) the > build was successful. The requirements list "blas" but not "cblas." > > I did not set the MONTEVERDI=ON switch. > > Thanks I have not been able to recreate this issue. OTB builds fine on Slackware 64 14.2 with blas and not cblas installed. Is it possible you are linking against another of OTB's dependencies that were previously built when cblas was installed? From orbea at fredslev.dk Sat Aug 11 19:23:01 2018 From: orbea at fredslev.dk (orbea at fredslev.dk) Date: Sat, 11 Aug 2018 12:23:01 -0700 Subject: [Slackbuilds-users] ladspa_sdk sandbox violation and potential segfault In-Reply-To: Message-ID: <20180811122301.5458cf15@Akita.witch.org> > Ah, patch not actually needed then, thanks. While restarting the system may of fixed the issue, it was a non-obvious solution and I think eliminating potential points of failure is good. Also while sandbox may be pedantic here, I personally expect that /dev/ won't be touched when running a SlackBuild script. I think there is value in avoiding it even when trivial. Lastly, if you are now maintaining this script PLEASE update the maintainer information so I actually e-mail the right person! From orbea at fredslev.dk Sat Aug 11 19:53:46 2018 From: orbea at fredslev.dk (orbea at fredslev.dk) Date: Sat, 11 Aug 2018 12:53:46 -0700 Subject: [Slackbuilds-users] Missing and incorrect libreoffice dependencies. In-Reply-To: <20180811072019.2146d536@Akita.witch.org> Message-ID: <20180811125346.2eb23c0b@Akita.witch.org> I looked at the 6.1.0.3 source and found two small corrections. 1. LibreOffice can also use lxml and will apparently build it internally if missing, I am not sure if it needs to be a python3 lxml or not. 2. With 6.1.0.3 libnumbertext is a new optional dependency which is missing from SBo, I have submitted a script for it just now which I was able use when building 6.1.0.3 without issue. If --with-system-libnumbertext is not used then libreoffice will use an internal version. From kev4321 at fastmail.fm Sat Aug 11 20:47:54 2018 From: kev4321 at fastmail.fm (Kevin McCormick) Date: Sat, 11 Aug 2018 15:47:54 -0500 Subject: [Slackbuilds-users] ORFEO Toolbox (OTB) In-Reply-To: <4333588.YfmZzQa9pV@wintermute.sprawl.net> References: <8c73d4d6-b3f8-00e5-52fe-74ad02c292ba@fastmail.fm> <4333588.YfmZzQa9pV@wintermute.sprawl.net> Message-ID: <6519362f-3667-c22b-d9c2-00c248075961@fastmail.fm> I don't think cblas was previously installed.? However, my sbopkg-pkg-log does have references to cblas in numpy, pygsl, and other places. I suppose it is possible that something unique to my computer triggered the need for cblas.? OTB was part of a long sbopkg queuefile and OpenBLAS was higher up on the list.The "blas" packages are confusing to me, but I guess the alternate blas routines can be used even though the generic blas is installed.? I was trying to get qgis and dependencies/options installed, which did work out pretty well except for libaspacialite not linking to postgis. Thanks On 08/11/2018 01:44 PM, Benjamin Trigona-Harany wrote: > On Thursday, 9 August 2018 10:43:25 PDT Kevin McCormick wrote: >> Build failed for OTB: >> OTB 6.6.0 undefined reference to `cblas_dgemm' >> >> After installing "cblas" (in addition to the other requirements) the >> build was successful. The requirements list "blas" but not "cblas." >> >> I did not set the MONTEVERDI=ON switch. >> >> Thanks > I have not been able to recreate this issue. OTB builds fine on Slackware 64 > 14.2 with blas and not cblas installed. Is it possible you are linking against > another of OTB's dependencies that were previously built when cblas was > installed? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From slackbuilds at jaxartes.net Sat Aug 11 21:51:12 2018 From: slackbuilds at jaxartes.net (Benjamin Trigona-Harany) Date: Sat, 11 Aug 2018 21:51:12 +0000 Subject: [Slackbuilds-users] ORFEO Toolbox (OTB) In-Reply-To: <6519362f-3667-c22b-d9c2-00c248075961@fastmail.fm> References: <8c73d4d6-b3f8-00e5-52fe-74ad02c292ba@fastmail.fm> <4333588.YfmZzQa9pV@wintermute.sprawl.net> <6519362f-3667-c22b-d9c2-00c248075961@fastmail.fm> Message-ID: <7EDC5A11-C15E-4820-98FE-14D21937F5C3@jaxartes.net> I admit that I also do not fully understand all the nuances of the blas/cblas/OpenBLAS/atlas options (not to mention lapack). My guess is that if numpy was built against cblas and then cblas wasn't available when OTB was compiled, it could cause such an error. If cblas is uninstalled, can you import numpy in the Python REPL? On August 11, 2018 8:47:54 PM UTC, Kevin McCormick wrote: >I don't think cblas was previously installed.? However, my >sbopkg-pkg-log does have references to cblas in numpy, pygsl, and other >places. I suppose it is possible that something unique to my computer >triggered the need for cblas.? OTB was part of a long sbopkg queuefile >and OpenBLAS was higher up on the list.The "blas" packages are >confusing >to me, but I guess the alternate blas routines can be used even though >the generic blas is installed.? I was trying to get qgis and >dependencies/options installed, which did work out pretty well except >for libaspacialite not linking to postgis. > >Thanks > >On 08/11/2018 01:44 PM, Benjamin Trigona-Harany wrote: >> On Thursday, 9 August 2018 10:43:25 PDT Kevin McCormick wrote: >>> Build failed for OTB: >>> OTB 6.6.0 undefined reference to `cblas_dgemm' >>> >>> After installing "cblas" (in addition to the other requirements) the >>> build was successful. The requirements list "blas" but not "cblas." >>> >>> I did not set the MONTEVERDI=ON switch. >>> >>> Thanks >> I have not been able to recreate this issue. OTB builds fine on >Slackware 64 >> 14.2 with blas and not cblas installed. Is it possible you are >linking against >> another of OTB's dependencies that were previously built when cblas >was >> installed? >> >> >> -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From yalhcru at gmail.com Sun Aug 12 04:52:08 2018 From: yalhcru at gmail.com (B Watson) Date: Sun, 12 Aug 2018 00:52:08 -0400 Subject: [Slackbuilds-users] ladspa_sdk sandbox violation and potential segfault In-Reply-To: <20180811122301.5458cf15@Akita.witch.org> References: <20180811122301.5458cf15@Akita.witch.org> Message-ID: On 8/11/18, orbea at fredslev.dk wrote: > > Lastly, if you are now maintaining this script PLEASE update the > maintainer information so I actually e-mail the right person! Whoops, that was a thinko. I maintain a bunch of ladspa plugins that depend on ladspa_sdk, but not ladspa_sdk itself. So forget I even replied to this... From 414N at slacky.it Sun Aug 12 14:08:53 2018 From: 414N at slacky.it (414N) Date: Sun, 12 Aug 2018 16:08:53 +0200 Subject: [Slackbuilds-users] Updates - 20180811.1 In-Reply-To: <4b02fe96-5c3c-8538-5445-d5343f21ed04@slackbuilds.org> References: <4b02fe96-5c3c-8538-5445-d5343f21ed04@slackbuilds.org> Message-ID: Hi, I have problems upgrading mlt and rust. mlt seems to require a forced 'std-c++11' gcc flag (haven't tried it yet) to successfully compile now: In file included from /usr/include/qt5/QtCore/qglobal.h:83:0, ???????????????? from /usr/include/qt5/QtCore/qcoreapplication.h:43, ???????????????? from /usr/include/qt5/QtWidgets/qapplication.h:43, ???????????????? from /usr/include/qt5/QtWidgets/QApplication:1, ???????????????? from common.cpp:20: /usr/include/qt5/QtCore/qcompilerdetection.h:562:6: error: #error Qt requires a C++11 compiler and yours does not seem to be that. ?#??? error Qt requires a C++11 compiler and yours does not seem to be that. rust seems to be having trouble in stage0 std artifacts building (no clue on how to solve them): Building stage0 std artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu) warning: unused manifest key: package.autobenches warning: unused manifest key: package.autotests warning: unused manifest key: package.autobenches warning: unused manifest key: package.autotests ?? Compiling cc v1.0.15 ?? Compiling core v0.0.0 (file:///tmp/SBo/rustc-1.28.0-src/src/libcore) ?? Compiling build_helper v0.1.0 (file:///tmp/SBo/rustc-1.28.0-src/src/build_helper) ?? Compiling unwind v0.0.0 (file:///tmp/SBo/rustc-1.28.0-src/src/libunwind) error[E0204]: the trait `Copy` may not be implemented for this type ? --> libcore/num/mod.rs:50:22 ?? | 50 |?????????????? #[derive(Copy, Clone, Eq, PartialEq, Ord, PartialOrd, Hash)] ?? |??????????????????????? ^^^^ 51 |?????????????? pub struct $Ty(NonZero<$Int>); ?? |????????????????????????????? -------------- this field does not implement `Copy` Anyone having the same issues? Alan Alberghini SBo clone: GitHub On 11/08/2018 02:39, Willy Sudiarto Raharjo wrote: > Here's summary for this week's work, thanks to all maintainers!! > > As you noticed, LibreOffice is still at 6.0.x, while libreoffice has > been bumped to 6.1.x. Things should sync in the next week updates as LO > 6.1 was just released yesterday and it may take time to test the script > to build it from source. However there's a minor mistake while updating > LibreOffice script. Christoph seems to forgot to update the MD5SUM for > one of the source (libreoffice-6.0.6.2.tar.xz) which should be > 3f6954b3f704afcb383daeadc4d783c8 > > Pinta is now dropped as it no longer build against latest > mono/mono-addins, even the latest master branch. SAGE is also considered > unmaintained for now. Feel free to grab if you found a solution to build > newer version. > > Sat Aug 11 00:24:32 UTC 2018 > academic/copasi: Fix DOWNLOAD_x86_64. > academic/reduce-algebra: Updated for version 20180808svn4717. > academic/sage: Unmaintained. > academic/scilab: Updated for version 6.0.1. > academic/stellarium: Updated for version 0.18.1. > academic/veusz: Updated for version 3.0.1. > accessibility/speech-dispatcher: Updated for version 0.8.8. > audio/clementine: Updated for version 1.3.1_c7f3ae9. > audio/mixxx: Updated for version 2.1.1, changed maintainer. > audio/qastools: Switch homepage to https. > audio/qmmp-plugin-pack-qt5: Updated for version 1.2.2. > audio/qmmp-plugin-pack: Updated for version 0.11.2. > audio/qmmp-qt5: Updated for version 1.2.3. > audio/qmmp: Updated for version 0.11.2. > audio/sunvox: Fix build. > desktop/libqtxdg: Updated for version 3.2.0. > desktop/py3status: Updated for version 3.12. > development/CImg: Updated for version 2.3.3. > development/PythonToolkit: Updated for version 18.08. > development/ahven: Updated for version 2.7. > development/alacritty: Updated for version git1adb5cb. > development/beav: Added (curses-based binary/hex editor). > development/bed: Added (ncurses-based binary/hex editor). > development/cgit: Updated for version 1.2.1. > development/dart: Updated for version 2.0.0. > development/hexcurse: Added (ncurses-based hex editor). > development/hexinator: Added (proprietary graphical hex editor). > development/jdk: Updated for version 8u181. > development/mono: Switch homepage to https. > development/nchexedit: Added (ncurses-based hex editor). > development/notepadqq: Allow the binary to be found in $PATH. > development/pandas: Updated for version 0.23.4. > development/processing: Updated for version 3.4. > development/pudb: Changed options. > development/rust: Updated for version 1.28.0. > development/tweak: Added (ncurses-based hex editor). > development/xvi: Added (tiny but full-featured vi clone). > games/edgar: Switch homepage to https. > games/javacpc: Updated for version 2.9.6f. > games/nestopia: Updated for version 1.49. > games/wesnoth: Updated for version 1.14.4. > gis/geos: Updated for version 3.6.3. > gis/mapnik: Switch homepage to https. > gis/openorienteering-mapper: Switch homepage to https. > gis/python-mapnik: Switch homepage to https. > gis/rasterio: Updated for version 1.0.3. > graphics/SweetHome3D: Updated for version 5.7. > graphics/converseen: Updated for version 0.9.7. > graphics/pinta: Removed (No longer build). > libraries/BeautifulSoup4: Updated for version 4.6.1. > libraries/DevIL: Updated for version 1.8.0. > libraries/IMAPClient: Switch homepage to https. > libraries/appstream-glib: Updated for version 0.7.11. > libraries/gnome-python2-gconf: Change the stripping routine. > libraries/gnome-sharp: Switch homepage to https. > libraries/gtk-sharp: Switch homepage to https. > libraries/libaom: Added (Open Source Video Codec). > libraries/libtorrent-rasterbar: Updated for version 1.1.9. > libraries/libwps: Updated for version 0.4.10. > libraries/libxkbcommon: Updated for version 0.8.2. > libraries/live555: Updated for version 2018.08.05 > multimedia/mlt: Updated for version 6.10.0. > network/TeamSpeak3: Updated for version 3.1.10. > network/WireGuard: Updated for version 0.0.20180809. > network/aMule: Updated for version 2.3.2. > network/brave: Updated for version 0.23.79. > network/filezilla: Updated for version 3.35.2. > network/frostwire: Switch homepage to https. > network/kvirc: Updated for version 20180605_8db6192, changed maint. > network/netdiscover: Added (network address discovering tool). > network/opera-developer: Updated for version 56.0.3037.0. > network/opera: Updated for version 54.0.2952.71. > network/prosody-mod-smacks: Updated for version hg3218. > network/psi-plus: Updated for version 1.3.400. > network/purple-plugin-pack: Patched for identifying on ngircd. > network/signal-desktop: Updated for version 1.15.1. > network/teamviewer: Updated for version 13.2.13582. > network/vivaldi: Updated for version 1.15.1147.64. > network/xbuffy: Added (a multi folder biff for X). > network/you-get: Updated for version 0.4.1099. > network/youtube-dl: Updated for version 2018.08.04. > office/LibreOffice: Updated for version 6.0.6.2 > office/MasterPDFEditor: Updated for version 5.1.12. > office/ganttproject: Fix symlink. > office/jstock: Updated for version 1.0.7.35. > office/libreoffice-helppack: Updated for version 6.1.0. > office/libreoffice-langpack: Updated for version 6.1.0. > office/libreoffice: Updated for version 6.1.0. > office/pdfpc: Updated for version 4.1.2 + new maintainer. > office/smoffice2016: Switch homepage to https. > office/smoffice2018: Switch homepage to https. > office/texmacs: Updated for version 1.99.7. > perl/perl-ExtUtils-ModuleMaker: Updated for version 0.63. > perl/perl-Sidef: Updated for version 3.19. > perl/perl-file-mimeinfo: Updated for version 0.29. > perl/zef: Updated for version 0.4.6. > python/Scrapy: Updated for version 1.5.1. > python/astroid: Updated for version 2.0.4. > python/ndg_httpsclient: Updated for version 0.5.1. > python/packaging: Updated for version 17.1. > python/pendulum: Updated for version 2.0.3. > python/prompt_toolkit: Updated for version 2.0.4. > python/pytest: Updated for version 3.7.1. > python/python-scandir: Updated for version 1.8. > python/python-urllib3: Updated for version 1.23. > python/python3-lazy-object-proxy: Added (Python lazy object proxy). > python/python3-wrapt: Added (A Python module for decorators). > python/regex: Updated for version 2018.07.11. > python/selenium: Updated for version 3.14.0. > python/tox: Updated for version 3.1.2. > python/werkzeug: Updated for version 0.14.1 + new maintainer. > ruby/rubygem-ruby-progressbar: Updated for version 1.10.0. > system/cabextract: Updated for version 1.7. > system/epson-inkjet-printer-escpr: Updated for version 1.6.23. > system/gtk-vnc: Update DEP. > system/isdct: Updated for version 3.0.14. > system/kbfs: Updated for version 2.6.0_20180810160058. > system/keybase: Updated for version 2.5.0. > system/lynis: Updated for version 2.6.7. > system/mariadb-plugin-saslauthd: Updated for version 1.5. > system/pspg: Updated for version 1.3.0. > system/ranger: Changed option. > system/ripgrep: Updated for version 0.9.0. > system/spl-solaris: Switch homepage to https. > system/wine: Updated for version 3.0.2. > system/winetricks: Updated for version 20180603. > system/xarchiver: Updated for version 0.5.4.13. > system/zfs-on-linux: Switch homepage to https. > +--------------------------+ > > > > > _______________________________________________ > 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 -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From rshepard at appl-ecosys.com Sun Aug 12 14:19:05 2018 From: rshepard at appl-ecosys.com (Rich Shepard) Date: Sun, 12 Aug 2018 07:19:05 -0700 (PDT) Subject: [Slackbuilds-users] Updates - 20180811.1 In-Reply-To: References: <4b02fe96-5c3c-8538-5445-d5343f21ed04@slackbuilds.org> Message-ID: On Sun, 12 Aug 2018, 414N wrote: > mlt seems to require a forced 'std-c++11' gcc flag (haven't tried it > yet) to successfully compile now: > /usr/include/qt5/QtCore/qcompilerdetection.h:562:6: error: #error Qt > requires a C++11 compiler and yours does not seem to be that. > ?#??? error Qt requires a C++11 compiler and yours does not seem to be that. Not quite the same issue, but the R package, rgdal, also wants a C++11 compiler, but during the configuration stage finds one present and of appropriate version. This will be a serious PITA to figure out. Rich From dave at dawoodfall.net Sun Aug 12 14:25:45 2018 From: dave at dawoodfall.net (David Woodfall) Date: Sun, 12 Aug 2018 15:25:45 +0100 Subject: [Slackbuilds-users] Updates - 20180811.1 In-Reply-To: References: <4b02fe96-5c3c-8538-5445-d5343f21ed04@slackbuilds.org> Message-ID: <20180812142545.GA23433@blackswan> On Sunday 12 August 2018 16:08, 414N <414N at slacky.it> put forth the proposition: > Hi, > > I have problems upgrading mlt and rust. > > mlt seems to require a forced 'std-c++11' gcc flag (haven't tried it > yet) to successfully compile now: > > In file included from /usr/include/qt5/QtCore/qglobal.h:83:0, > ???????????????? from /usr/include/qt5/QtCore/qcoreapplication.h:43, > ???????????????? from /usr/include/qt5/QtWidgets/qapplication.h:43, > ???????????????? from /usr/include/qt5/QtWidgets/QApplication:1, > ???????????????? from common.cpp:20: > /usr/include/qt5/QtCore/qcompilerdetection.h:562:6: error: #error Qt > requires a C++11 compiler and yours does not seem to be that. > ?#??? error Qt requires a C++11 compiler and yours does not seem to be that. > > > rust seems to be having trouble in stage0 std artifacts building (no > clue on how to solve them): I've just encountered the same error while testing the new Qt5. However, I did test adding -std=c++11 and also -std=gnu++11 to SLKCFLAGS and it still failed. -Dave -- Dijkstra probably hates me. -- Linus Torvalds, in kernel/sched.c .--. oo (____)// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~' From aclemons at runbox.no Sun Aug 12 19:50:44 2018 From: aclemons at runbox.no (Andrew Clemons) Date: Mon, 13 Aug 2018 07:50:44 +1200 Subject: [Slackbuilds-users] Updates - 20180811.1 In-Reply-To: References: <4b02fe96-5c3c-8538-5445-d5343f21ed04@slackbuilds.org> Message-ID: <20180812195043.GA18919@runbox.no> On 2018-08-12 16:08:53 +0200, 414N at slacky.it wrote: > [...] > rust seems to be having trouble in stage0 std artifacts building (no > clue on how to solve them): > > Building stage0 std artifacts (x86_64-unknown-linux-gnu -> > x86_64-unknown-linux-gnu) > [...] > > Anyone having the same issues? How are you bootstrapping? Do you have rust already installed or are you bootstrapping using downloaded mozilla binaries? If rust is already installed, you must use the previous stable to bootstrap the next stable (1.28.0 must be built with 1.27.x). If you have 1.26.x installed, you'll need to build 1.27.x first, install it and then build 1.28 (or uninstall rust and bootstrap from mozilla's pre-built binaries) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From 414N at slacky.it Sun Aug 12 20:41:53 2018 From: 414N at slacky.it (414N) Date: Sun, 12 Aug 2018 22:41:53 +0200 Subject: [Slackbuilds-users] Updates - 20180811.1 In-Reply-To: <20180812195043.GA18919@runbox.no> References: <4b02fe96-5c3c-8538-5445-d5343f21ed04@slackbuilds.org> <20180812195043.GA18919@runbox.no> Message-ID: Good catch Andrew, I've got v1.26.2 installed indeed. I'll try building it again after removing current version. Thanks for the tip! Alan Alberghini SBo clone: GitHub On 12/08/2018 21:50, Andrew Clemons wrote: > On 2018-08-12 16:08:53 +0200, 414N at slacky.it wrote: >> [...] >> rust seems to be having trouble in stage0 std artifacts building (no >> clue on how to solve them): >> >> Building stage0 std artifacts (x86_64-unknown-linux-gnu -> >> x86_64-unknown-linux-gnu) >> [...] >> >> Anyone having the same issues? > How are you bootstrapping? Do you have rust already installed or are you > bootstrapping using downloaded mozilla binaries? If rust is already > installed, you must use the previous stable to bootstrap the next stable > (1.28.0 must be built with 1.27.x). If you have 1.26.x installed, you'll > need to build 1.27.x first, install it and then build 1.28 (or uninstall > rust and bootstrap from mozilla's pre-built binaries) > > > _______________________________________________ > 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 -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From kingbeowulf at gmail.com Sun Aug 12 23:29:52 2018 From: kingbeowulf at gmail.com (King Beowulf) Date: Sun, 12 Aug 2018 16:29:52 -0700 Subject: [Slackbuilds-users] Updates - 20180811.1 In-Reply-To: References: <4b02fe96-5c3c-8538-5445-d5343f21ed04@slackbuilds.org> Message-ID: <56db6310-0971-a94d-7ada-de26920bc984@gmail.com> On 08/12/2018 07:08 AM, 414N wrote: > Hi, > > I have problems upgrading mlt and rust. > > mlt seems to require a forced 'std-c++11' gcc flag (haven't tried it > yet) to successfully compile now: > > In file included from /usr/include/qt5/QtCore/qglobal.h:83:0, > ???????????????? from /usr/include/qt5/QtCore/qcoreapplication.h:43, > ???????????????? from /usr/include/qt5/QtWidgets/qapplication.h:43, > ???????????????? from /usr/include/qt5/QtWidgets/QApplication:1, > ???????????????? from common.cpp:20: > /usr/include/qt5/QtCore/qcompilerdetection.h:562:6: error: #error Qt > requires a C++11 compiler and yours does not seem to be that. > ?#??? error Qt requires a C++11 compiler and yours does not seem to be that. > > ----snip---- mlt compiled here just fine before I submitted the update on stock Slackware64 14.2 and as well as on multilib. IF you tried this on multilib, check your gcc-*5.5.0_multlib installaton as well as your QT5 installation. also, QT5 and mlt (etc) share some optional dependencies, not all of which are listed. Thus, order of compilation will be important. Since mlt works here, I'll categorize this as PEBKAC until, and if, confirmed. -Ed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: OpenPGP digital signature URL: From chris.willing at linux.com Mon Aug 13 01:27:22 2018 From: chris.willing at linux.com (Christoph Willing) Date: Mon, 13 Aug 2018 11:27:22 +1000 Subject: [Slackbuilds-users] Missing and incorrect libreoffice dependencies. In-Reply-To: <20180811072019.2146d536@Akita.witch.org> References: <20180811072019.2146d536@Akita.witch.org> Message-ID: <031915f2-3eae-2dd0-4df1-3ae953dfe0e3@linux.com> On 12/08/18 00:20, orbea at fredslev.dk wrote: > Hi, > > Its been bugging me for a long time that the LibreOffice from source > SlackBuild has both incorrect and many missing optional dependencies. > Hi Hunter, Yes it has been a long time; you've been complaining at LQ for about two years now despite my various attempts to explain the current arrangement. I'll try again, after which could we just agree to disagree? > The only required dependency is: > > perl-Archive-Zip > > The following dependencies are erroneously marked as required and > libreoffice will either work fine without them or can provide their own > internal versions. > > python3, apache-ant, openjdk > In general, most software is able to be built with or without a number of options. Some people seem to believe that building software (hence SlackBuilds) with the fewest possible options enabled is better (by some metric). I don't agree with this philosophy and usually build with all practicable options to ensure maximum feature availability. In the case of LibreOffice, this is alluded to in the README which states: "In seeking a fully functional LibreOffice, most optional features are included by default." Please note the use of "fully functional". While it is, of course, possible to restrict the functionality to suit your personally use case, I don't believe that is an appropriate approach for a general purpose "release". As an advanced user, you are more than capable of modifying the SlackBuild to suit yourself or, as you already have, create and publish your own SlackBuild which includes/excludes whatever you like. The README goes on to mention a few environment variables that may be set in order to change the default build, some of which (VLC, AVAHI) have been at your suggestion. There is also a JAVA variable which may be set, including JAVA=no for those who know they don't need its functionality. I won't go on - I'm sure you've read the README and so already know these things. BTW, you will also know from the libreoffice email list that work is in progress to remove the current java dependency. When this is complete, I will remove the requirement for any java (and related apache-ant). The requirement for python3 relates to a personal use case that is not satisfied by the "internal" python3. I'll continue to exercise my prerogative as maintainer to keep python3 as a requirement. It certainly doesn't reduce functionality and is so common that many (most?) users will already have it installed. > Here is a list of dependencies available at SBo which libreoffice can > use and are not currently listed. > > CoinMP, cppunit, glm, libabw, libcdr, libcmis, libe-book, > libeot, libepubgen, libetonyek, libexttextcat, libfreehand, > liblangtag, libmspub, libmwaw, liborcus, libpagemaker, libqxp, > libstaroffice, libtommath, libwps, libzmf, lpsolve, mdds, > mysql-connector-c++, mythes, postgresql, qt5, valgrind, ucpp > I'm not sure what you mean with this list. I guess that you mean that are SBo packages for each of them which could be used instead of the internal LO versions? Adding them all as requirements would make a pretty onerous build queue. Making them all selectable via environment variables would make for an equally onerous command line for the average builder. The majority are already included (using internal versions) in the default build as I don't believe the average builder/user should have to decide whether they want to include each individual item. If a user has a particular problem with a particular supporting software package that can be fixed by a change to the SlackBuild (without detriment to everyone else), I'm happy to include it. > Also an optional dependency which can not currently be used is: > > graphite2 > > It would require harfbuzz in the main tree to be rebuilt with graphite2. > I'm not sure what to do with that statement. Are you suggesting anything in particular for the SlackBuild? > Additionally here is a list of optional dependencies in the main tree > that libreoffice is not currently using: > > apr, bluez, bzip2, clucene, libepoxy, libodfgen, openldap-client > > Can this please be fixed? > You mean e.g. --with-system-apr etc.? Yes, I'll fix those. Thanks for mentioning them. chris From orbea at fredslev.dk Mon Aug 13 02:08:20 2018 From: orbea at fredslev.dk (orbea at fredslev.dk) Date: Sun, 12 Aug 2018 19:08:20 -0700 Subject: [Slackbuilds-users] Missing and incorrect libreoffice dependencies. In-Reply-To: <031915f2-3eae-2dd0-4df1-3ae953dfe0e3@linux.com> Message-ID: <20180812190820.1f97ca4c@Akita.witch.org> On Mon, 13 Aug 2018 11:27:22 +1000 Christoph Willing wrote: > On 12/08/18 00:20, orbea at fredslev.dk wrote: > > Hi, > > > > Its been bugging me for a long time that the LibreOffice from source > > SlackBuild has both incorrect and many missing optional > > dependencies. > Hi Hunter, > > Yes it has been a long time; you've been complaining at LQ for about > two years now despite my various attempts to explain the current > arrangement. I'll try again, after which could we just agree to > disagree? > > > The only required dependency is: > > > > perl-Archive-Zip > > > > The following dependencies are erroneously marked as required and > > libreoffice will either work fine without them or can provide their > > own internal versions. > > > > python3, apache-ant, openjdk > > > In general, most software is able to be built with or without a number > of options. Some people seem to believe that building software (hence > SlackBuilds) with the fewest possible options enabled is better (by > some metric). I don't agree with this philosophy and usually build > with all practicable options to ensure maximum feature availability. > In the case of LibreOffice, this is alluded to in the README which > states: "In seeking a fully functional LibreOffice, most optional > features are included by default." > > Please note the use of "fully functional". While it is, of course, > possible to restrict the functionality to suit your personally use > case, I don't believe that is an appropriate approach for a general > purpose "release". As an advanced user, you are more than capable of > modifying the SlackBuild to suit yourself or, as you already have, > create and publish your own SlackBuild which includes/excludes > whatever you like. > > The README goes on to mention a few environment variables that may be > set in order to change the default build, some of which (VLC, AVAHI) > have been at your suggestion. There is also a JAVA variable which may > be set, including JAVA=no for those who know they don't need its > functionality. I won't go on - I'm sure you've read the README and so > already know these things. > > BTW, you will also know from the libreoffice email list that work is > in progress to remove the current java dependency. When this is > complete, I will remove the requirement for any java (and related > apache-ant). > > The requirement for python3 relates to a personal use case that is not > satisfied by the "internal" python3. I'll continue to exercise my > prerogative as maintainer to keep python3 as a requirement. It > certainly doesn't reduce functionality and is so common that many > (most?) users will already have it installed. I do not agree, I think such choices should be left up to the user especially with arguably undesirable dependencies like java. As for python3 its easy to prefer the system python3 and fallback to the internal one if its missing. if pkg-config --exists python3; then .... That said would you mind elaborating on your use case that requires the system python3? This is the first I recall hearing about it and would be interested in knowing more. > > Here is a list of dependencies available at SBo which libreoffice > > can use and are not currently listed. > > > > CoinMP, cppunit, glm, libabw, libcdr, libcmis, libe-book, > > libeot, libepubgen, libetonyek, libexttextcat, libfreehand, > > liblangtag, libmspub, libmwaw, liborcus, libpagemaker, libqxp, > > libstaroffice, libtommath, libwps, libzmf, lpsolve, mdds, > > mysql-connector-c++, mythes, postgresql, qt5, valgrind, ucpp > > > I'm not sure what you mean with this list. I guess that you mean that > are SBo packages for each of them which could be used instead of the > internal LO versions? Adding them all as requirements would make a > pretty onerous build queue. Making them all selectable via environment > variables would make for an equally onerous command line for the > average builder. The majority are already included (using internal > versions) in the default build as I don't believe the average > builder/user should have to decide whether they want to include each > individual item. > > If a user has a particular problem with a particular supporting > software package that can be fixed by a change to the SlackBuild > (without detriment to everyone else), I'm happy to include it. There are two very good reasons to support these. 1. When a dependency of a dependency is updated instead of rebuilding all of libreoffice the user only needs to rebuild a few system dependencies. 2. It can shave off a significant amount of build time when using the system dependencies. There is also the argument that I spent a lot of effort supporting these for libreoffice before and after your script was added where they have gone unused. Its pretty easy to determine if they are installed with pkg-config , checking the existence of include directories and/or binaries requiring no environment variables and not much more than documentation in the README. > > Also an optional dependency which can not currently be used is: > > > > graphite2 > > > > It would require harfbuzz in the main tree to be rebuilt with > > graphite2. > I'm not sure what to do with that statement. Are you suggesting > anything in particular for the SlackBuild? > > > > Additionally here is a list of optional dependencies in the main > > tree that libreoffice is not currently using: > > > > apr, bluez, bzip2, clucene, libepoxy, libodfgen, openldap-client > > > > Can this please be fixed? > > > You mean e.g. --with-system-apr etc.? Yes, I'll fix those. Thanks for > mentioning them. > > chris Yes, thanks! I would also suggest checking if they exist with pkg-config or other methods before hardcoding them. Some of them like bluez are not always desirable or installed. From kingbeowulf at gmail.com Mon Aug 13 02:10:03 2018 From: kingbeowulf at gmail.com (King Beowulf) Date: Sun, 12 Aug 2018 19:10:03 -0700 Subject: [Slackbuilds-users] Error in wxGTK3 buildscript Message-ID: When creating the /usr/bin/wx-config symlink, code needs to be added in case the user compiles with STATIC=yes ---------8<-------------- --- /data/slackware/builds/libraries/wxGTK3/wxGTK3.SlackBuild 2018-03-24 17:19:40.661155000 -0700 +++ /tmp/medit-1-tmpdir-2d497bf8/tmpfile-001 2018-08-12 19:06:53.356083390 -0700 @@ -119,8 +119,13 @@ find $PKG -print0 | xargs -0 file | grep | cut -f 1 -d : | xargs strip --strip-unneeded 2> /dev/null || true # Now let's fix the broken symlink created by the package -ln -fs /usr/lib${LIBDIRSUFFIX}/wx/config/gtk2-unicode-3.0 \ +if [ "${STATIC:-no}" = "yes" ]; then +ln -fs /usr/lib${LIBDIRSUFFIX}/wx/config/gtk2-unicode-static-3.0 \ $PKG/usr/bin/wx-config +else + ln -fs /usr/lib${LIBDIRSUFFIX}/wx/config/gtk2-unicode-3.0 \ + $PKG/usr/bin/wx-config +fi mkdir -p $PKG/usr/doc/$PRGNAM-$VERSION cp -a docs/* $PKG/usr/doc/$PRGNAM-$VERSION --------->8-------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: OpenPGP digital signature URL: From dave at dawoodfall.net Mon Aug 13 05:46:16 2018 From: dave at dawoodfall.net (David Woodfall) Date: Mon, 13 Aug 2018 06:46:16 +0100 Subject: [Slackbuilds-users] Updates - 20180811.1 In-Reply-To: References: <4b02fe96-5c3c-8538-5445-d5343f21ed04@slackbuilds.org> Message-ID: <20180813054616.GA1319@blackswan> On Sunday 12 August 2018 16:08, 414N <414N at slacky.it> put forth the proposition: > Hi, > > I have problems upgrading mlt and rust. > > mlt seems to require a forced 'std-c++11' gcc flag (haven't tried it > yet) to successfully compile now: > > In file included from /usr/include/qt5/QtCore/qglobal.h:83:0, > ???????????????? from /usr/include/qt5/QtCore/qcoreapplication.h:43, > ???????????????? from /usr/include/qt5/QtWidgets/qapplication.h:43, > ???????????????? from /usr/include/qt5/QtWidgets/QApplication:1, > ???????????????? from common.cpp:20: > /usr/include/qt5/QtCore/qcompilerdetection.h:562:6: error: #error Qt > requires a C++11 compiler and yours does not seem to be that. > ?#??? error Qt requires a C++11 compiler and yours does not seem to be that. This fixed it for me: Firstly, I was testing Qt5-5.9.6, so this may not apply for the current Qt5 version on SBo at the moment, but I built Qt5 with an extra configure option: -c++std c++11 \ I also added -std=c++11 to CXXFLAGS. For mlt change CFLAGS="$SLKCFLAGS" \ CXXFLAGS="$SLKCFLAGS" \ to export CFLAGS="$SLKCFLAGS" export CXXFLAGS="$SLKCFLAGS -std=c++11" and comment out or remove the old make line and add just 'make' so it looks like this make clean make make install DESTDIR=$PKG -Dave -- Windows without the X is like making love without a partner. Sex, Drugs & Linux Rules win-nt from the people who invented edlin. Apples have meant trouble since eden. Linux, the way to get rid of boot viruses -- MaDsen Wikholm, mwikholm at at8.abo.fi .--. oo (____)// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~' From kev4321 at fastmail.fm Mon Aug 13 12:51:26 2018 From: kev4321 at fastmail.fm (Kevin McCormick) Date: Mon, 13 Aug 2018 07:51:26 -0500 Subject: [Slackbuilds-users] ORFEO Toolbox (OTB) In-Reply-To: <7EDC5A11-C15E-4820-98FE-14D21937F5C3@jaxartes.net> References: <8c73d4d6-b3f8-00e5-52fe-74ad02c292ba@fastmail.fm> <4333588.YfmZzQa9pV@wintermute.sprawl.net> <6519362f-3667-c22b-d9c2-00c248075961@fastmail.fm> <7EDC5A11-C15E-4820-98FE-14D21937F5C3@jaxartes.net> Message-ID: <39cdeea0-8da4-9a43-1e4e-1e8d8a889a89@fastmail.fm> I did "removepkg cblas" and then "python" and ">> import numpy" and there were no complaints.? So I did sbopkg -i cblas to reinstall it.? Now I think I should remove numpy and reinstall it to get the blas routines referenced. Kevin On 08/11/2018 04:51 PM, Benjamin Trigona-Harany wrote: > I admit that I also do not fully understand all the nuances of the > blas/cblas/OpenBLAS/atlas options (not to mention lapack). My guess is > that if numpy was built against cblas and then cblas wasn't available > when OTB was compiled, it could cause such an error. > > If cblas is uninstalled, can you import numpy in the Python REPL? > > On August 11, 2018 8:47:54 PM UTC, Kevin McCormick > wrote: > > I don't think cblas was previously installed.? However, my > sbopkg-pkg-log does have references to cblas in numpy, pygsl, and > other places. I suppose it is possible that something unique to my > computer triggered the need for cblas.? OTB was part of a long > sbopkg queuefile and OpenBLAS was higher up on the list.The "blas" > packages are confusing to me, but I guess the alternate blas > routines can be used even though the generic blas is installed.? I > was trying to get qgis and dependencies/options installed, which > did work out pretty well except for libaspacialite not linking to > postgis. > > Thanks > > On 08/11/2018 01:44 PM, Benjamin Trigona-Harany wrote: >> On Thursday, 9 August 2018 10:43:25 PDT Kevin McCormick wrote: >>> Build failed for OTB: >>> OTB 6.6.0 undefined reference to `cblas_dgemm' >>> >>> After installing "cblas" (in addition to the other requirements) the >>> build was successful. The requirements list "blas" but not "cblas." >>> >>> I did not set the MONTEVERDI=ON switch. >>> >>> Thanks >> I have not been able to recreate this issue. OTB builds fine on Slackware 64 >> 14.2 with blas and not cblas installed. Is it possible you are linking against >> another of OTB's dependencies that were previously built when cblas was >> installed? >> >> >> > > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From 414N at slacky.it Mon Aug 13 15:14:47 2018 From: 414N at slacky.it (414N) Date: Mon, 13 Aug 2018 17:14:47 +0200 Subject: [Slackbuilds-users] Updates - 20180811.1 In-Reply-To: References: <4b02fe96-5c3c-8538-5445-d5343f21ed04@slackbuilds.org> <20180812195043.GA18919@runbox.no> Message-ID: I can confirm that removing rust-1.26.x prior to building the 1.28 version works ok! Alan Alberghini SBo clone: GitHub On 12/08/2018 22:41, 414N wrote: > Good catch Andrew, I've got v1.26.2 installed indeed. > > I'll try building it again after removing current version. > > Thanks for the tip! > > Alan Alberghini > > SBo clone: GitHub > > On 12/08/2018 21:50, Andrew Clemons wrote: >> On 2018-08-12 16:08:53 +0200, 414N at slacky.it wrote: >>> [...] >>> rust seems to be having trouble in stage0 std artifacts building (no >>> clue on how to solve them): >>> >>> Building stage0 std artifacts (x86_64-unknown-linux-gnu -> >>> x86_64-unknown-linux-gnu) >>> [...] >>> >>> Anyone having the same issues? >> How are you bootstrapping? Do you have rust already installed or are you >> bootstrapping using downloaded mozilla binaries? If rust is already >> installed, you must use the previous stable to bootstrap the next stable >> (1.28.0 must be built with 1.27.x). If you have 1.26.x installed, you'll >> need to build 1.27.x first, install it and then build 1.28 (or uninstall >> rust and bootstrap from mozilla's pre-built binaries) >> >> >> _______________________________________________ >> 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 -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From atelszewski at gmail.com Mon Aug 13 15:16:56 2018 From: atelszewski at gmail.com (Andrzej Telszewski) Date: Mon, 13 Aug 2018 17:16:56 +0200 Subject: [Slackbuilds-users] qt5 is sorely in need of an update In-Reply-To: <20180805094423.GB6543@blackswan> References: <20180715090718.GE29592@blackswan> <20180725085721.01cbfd07@Akita.witch.org> <20180731215721.GB9697@blackswan> <20180805060903.GA6543@blackswan> <20180805094423.GB6543@blackswan> Message-ID: <2b8bf5ee-eed5-3644-00ab-070ba2b920f6@gmail.com> Hi, Is the script for updated Qt5 available somewhere? I'd like to give it a try. -- Best regards / Pozdrawiam, Andrzej Telszewski From atelszewski at gmail.com Mon Aug 13 15:19:23 2018 From: atelszewski at gmail.com (Andrzej Telszewski) Date: Mon, 13 Aug 2018 17:19:23 +0200 Subject: [Slackbuilds-users] Updates - 20180811.1 In-Reply-To: References: <4b02fe96-5c3c-8538-5445-d5343f21ed04@slackbuilds.org> <20180812195043.GA18919@runbox.no> Message-ID: <1fb9594f-42bf-4ffc-9869-cc9c05c4e120@gmail.com> On 13/08/2018 17:14, 414N wrote: > I can confirm that removing rust-1.26.x prior to building the 1.28 > version works ok! > Count me in ;-) Building 1.28.0 worked for me just fine, when bootstrapping using the previously built version 1.27.x. Cheers. -- Best regards / Pozdrawiam, Andrzej Telszewski From kingbeowulf at gmail.com Mon Aug 13 15:47:17 2018 From: kingbeowulf at gmail.com (King Beowulf) Date: Mon, 13 Aug 2018 08:47:17 -0700 Subject: [Slackbuilds-users] Updates - 20180811.1 In-Reply-To: <20180813054616.GA1319@blackswan> References: <4b02fe96-5c3c-8538-5445-d5343f21ed04@slackbuilds.org> <20180813054616.GA1319@blackswan> Message-ID: <55c4c216-72de-67dc-5c78-637ce950bd9f@gmail.com> On 08/12/2018 10:46 PM, David Woodfall wrote: > On Sunday 12 August 2018 16:08, > 414N <414N at slacky.it> put forth the proposition: >> Hi, >> >> I have problems upgrading mlt and rust. >> >> mlt seems to require a forced 'std-c++11' gcc flag (haven't tried it >> yet) to successfully compile now: >> >> In file included from /usr/include/qt5/QtCore/qglobal.h:83:0, >> ???????????????? from /usr/include/qt5/QtCore/qcoreapplication.h:43, >> ???????????????? from /usr/include/qt5/QtWidgets/qapplication.h:43, >> ???????????????? from /usr/include/qt5/QtWidgets/QApplication:1, >> ???????????????? from common.cpp:20: >> /usr/include/qt5/QtCore/qcompilerdetection.h:562:6: error: #error Qt >> requires a C++11 compiler and yours does not seem to be that. >> ?#??? error Qt requires a C++11 compiler and yours does not seem to be that. > > This fixed it for me: > > Firstly, I was testing Qt5-5.9.6, so this may not apply for the > current Qt5 version on SBo at the moment, but I built Qt5 with an > extra configure option: > > -c++std c++11 \ > > I also added -std=c++11 to CXXFLAGS. > > For mlt change > > CFLAGS="$SLKCFLAGS" \ > CXXFLAGS="$SLKCFLAGS" \ > > to > > export CFLAGS="$SLKCFLAGS" > export CXXFLAGS="$SLKCFLAGS -std=c++11" > > and comment out or remove the old make line and add just 'make' so it looks > like this > > make clean > make > make install DESTDIR=$PKG > > -Dave > This appears to be the fix for the SBo qt5-5.7.1 as well. I was using Alien Bob's qt5 in which mlt fails the qt5 test and thus defaults to qt4. (lazy!). I'm testing now with SBo qt5 but this will take a few hrs to compile (!); stay tuned. -Ed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: OpenPGP digital signature URL: From kingbeowulf at gmail.com Mon Aug 13 19:35:19 2018 From: kingbeowulf at gmail.com (King Beowulf) Date: Mon, 13 Aug 2018 12:35:19 -0700 Subject: [Slackbuilds-users] CONFIRMED: mlt with qt5 requires C++11 (was: Updates - 20180811.1) In-Reply-To: <20180813054616.GA1319@blackswan> References: <4b02fe96-5c3c-8538-5445-d5343f21ed04@slackbuilds.org> <20180813054616.GA1319@blackswan> Message-ID: <15f81525-2e76-f841-7f49-b1abf6566105@gmail.com> All: If one uses Alien Bob's QT5-5.7.1 package, the mlt build defaults to QT4. To use QT5, you need to compile the SBo QT5 with c++11 and then compile mlt with c++11 This was a requirement since mlt-6.6.0 but I never noticed during testing - because I never built with QT5. This is a moot point for Kdenlive on SBo, since the new KDE QT5 framework is not available in 14.2. But for flowblade (I think, will test tonight) or other mlt based s/w, qt5 with c++11 (or C++14) may be required. --------------------- qt5-5.7.1 SBo version ===================== Modify the following: export CFLAGS="$SLKCFLAGS" export CXXFLAGS="$SLKCFLAGS -std=c++11" ./configure -v -c++std c++11 \ ... mlt-6.10.0 SBo version ====================== Modification are: # Use qt5 if present, otherwise system default if pkg-config --exists Qt5 ; then qt="--qt-libdir=$(pkg-config Qt5 --variable=libdir) --qt-includedir=$(pkg-config Qt5 --variable=headerdir)" QTCXX="-std=c++11" else qt="--qt-libdir=$(pkg-config Qt --variable=libdir) --qt-includedir=$(pkg-config Qt --variable=headerdir)" fi and export CFLAGS="$SLKCFLAGS" export CXXFLAGS="$SLKCFLAGS $QTCXX" ./configure \ ... make clean make make install DESTDIR=$PKG ------------------------- both now compile. For QT5 maybe add a user switch for c++11 rather than have it be the default. -Ed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: OpenPGP digital signature URL: From yth at ythogtha.org Mon Aug 13 19:42:14 2018 From: yth at ythogtha.org (Ythogtha) Date: Mon, 13 Aug 2018 21:42:14 +0200 Subject: [Slackbuilds-users] Does anyone have trouble building DevIL ? Message-ID: <20180813214214.cc338f6544c7e8378972f504@ythogtha.org> Here is what happens when I try to build DevIL 1.8.0 (I already have 1.7.8 built and installed) : [ 40%] Building CXX object src-IL/CMakeFiles/IL.dir/src/il_dds-save.cpp.o /tmp/SBo/DevIL/DevIL/src-IL/src/il_dds-save.cpp: In function 'ILuint Compress(ILimage*, ILenum)': /tmp/SBo/DevIL/DevIL/src-IL/src/il_dds-save.cpp:711:32: error: invalid conversion from 'void*' to 'ILubyte* {aka unsigned char*}' [-fpermissive] ByteData = ilConvertBuffer(Image->SizeOfData, Image->Format, IL_BGRA, Image->Type, IL_UNSIGNED_BYTE, NULL, Image->Data); ^ src-IL/CMakeFiles/IL.dir/build.make:1094: recipe for target 'src-IL/CMakeFiles/IL.dir/src/il_dds-save.cpp.o' failed make[2]: *** [src-IL/CMakeFiles/IL.dir/src/il_dds-save.cpp.o] Error 1 make[2]: *** Waiting for unfinished jobs.... CMakeFiles/Makefile2:85: recipe for target 'src-IL/CMakeFiles/IL.dir/all' failed make[1]: *** [src-IL/CMakeFiles/IL.dir/all] Error 2 Makefile:127: recipe for target 'all' failed make: *** [all] Error 2 Does anyone have the same issue ? Any idea ? -- Arnaud From yalhcru at gmail.com Tue Aug 14 03:04:51 2018 From: yalhcru at gmail.com (B Watson) Date: Mon, 13 Aug 2018 23:04:51 -0400 Subject: [Slackbuilds-users] Does anyone have trouble building DevIL ? In-Reply-To: <20180813214214.cc338f6544c7e8378972f504@ythogtha.org> References: <20180813214214.cc338f6544c7e8378972f504@ythogtha.org> Message-ID: On 8/13/18, Ythogtha wrote: > Here is what happens when I try to build DevIL 1.8.0 (I already have 1.7.8 > built and installed) : > [ 40%] Building CXX object src-IL/CMakeFiles/IL.dir/src/il_dds-save.cpp.o > /tmp/SBo/DevIL/DevIL/src-IL/src/il_dds-save.cpp: In function 'ILuint > Compress(ILimage*, ILenum)': > /tmp/SBo/DevIL/DevIL/src-IL/src/il_dds-save.cpp:711:32: error: invalid > conversion from 'void*' to 'ILubyte* {aka unsigned char*}' [-fpermissive] > ByteData = ilConvertBuffer(Image->SizeOfData, Image->Format, IL_BGRA, > Image->Type, IL_UNSIGNED_BYTE, NULL, Image->Data); > > Does anyone have the same issue ? No, but... > Any idea ? It's telling you what to do in the very error message itself: add -fpermissive to the compile command. Easy way would be to add it to SLKCFLAGS just after the if/else block that sets it: SLKCFLAGS="$SLKCFLAGS -fpermissive" You on -current, or did you get this error on 14.2? From thedoogster at gmail.com Tue Aug 14 03:52:50 2018 From: thedoogster at gmail.com (Doogster) Date: Mon, 13 Aug 2018 20:52:50 -0700 Subject: [Slackbuilds-users] Does anyone have trouble building DevIL ? In-Reply-To: References: <20180813214214.cc338f6544c7e8378972f504@ythogtha.org> Message-ID: I was sent this patch to get 17.8 to build on -current. I didn?t incorporate it because it?s not needed on 14.2. http://gentoo.kevag-telekom.net/rsync/media-libs/devil/files/devil-1.7.8-jasper-remove-uchar.patch On Mon, Aug 13, 2018 at 8:04 PM B Watson wrote: > On 8/13/18, Ythogtha wrote: > > Here is what happens when I try to build DevIL 1.8.0 (I already have > 1.7.8 > > built and installed) : > > [ 40%] Building CXX object src-IL/CMakeFiles/IL.dir/src/il_dds-save.cpp.o > > /tmp/SBo/DevIL/DevIL/src-IL/src/il_dds-save.cpp: In function 'ILuint > > Compress(ILimage*, ILenum)': > > /tmp/SBo/DevIL/DevIL/src-IL/src/il_dds-save.cpp:711:32: error: invalid > > conversion from 'void*' to 'ILubyte* {aka unsigned char*}' [-fpermissive] > > ByteData = ilConvertBuffer(Image->SizeOfData, Image->Format, > IL_BGRA, > > Image->Type, IL_UNSIGNED_BYTE, NULL, Image->Data); > > > > Does anyone have the same issue ? > > No, but... > > > Any idea ? > > It's telling you what to do in the very error message itself: add > -fpermissive to the compile command. Easy way would be to add it to > SLKCFLAGS just after the if/else block that sets it: > > SLKCFLAGS="$SLKCFLAGS -fpermissive" > > You on -current, or did you get this error on 14.2? > _______________________________________________ > 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 yalhcru at gmail.com Tue Aug 14 05:17:53 2018 From: yalhcru at gmail.com (B Watson) Date: Tue, 14 Aug 2018 01:17:53 -0400 Subject: [Slackbuilds-users] Does anyone have trouble building DevIL ? In-Reply-To: References: <20180813214214.cc338f6544c7e8378972f504@ythogtha.org> Message-ID: On 8/13/18, Doogster wrote: > I was sent this patch to get 17.8 to build on -current. I didn t > incorporate it because it s not needed on 14.2. > > http://gentoo.kevag-telekom.net/rsync/media-libs/devil/files/devil-1.7.8-jasper-remove-uchar.patch If it doesn't actually do any harm on 14.2, you might as well include it. You're going to have to (or somebody's going to have to) when 15.0 is released, might as well get ahead now. Not saying you should go actively looking for compile issues on -current, but if someone hands me a patch like that I apply it to save myself future work... From thedoogster at gmail.com Tue Aug 14 05:47:00 2018 From: thedoogster at gmail.com (Doogster) Date: Mon, 13 Aug 2018 22:47:00 -0700 Subject: [Slackbuilds-users] Does anyone have trouble building DevIL ? In-Reply-To: References: <20180813214214.cc338f6544c7e8378972f504@ythogtha.org> Message-ID: ?You?re going to have to when 15 is released?? You don?t know that. I?ll deal with 15 compatibility when a release candidate is out, not before. On Mon, Aug 13, 2018 at 10:18 PM B Watson wrote: > On 8/13/18, Doogster wrote: > > I was sent this patch to get 17.8 to build on -current. I didn t > > incorporate it because it s not needed on 14.2. > > > > > http://gentoo.kevag-telekom.net/rsync/media-libs/devil/files/devil-1.7.8-jasper-remove-uchar.patch > > If it doesn't actually do any harm on 14.2, you might as well include > it. You're going to have to (or somebody's going to have to) when 15.0 > is released, might as well get ahead now. > > Not saying you should go actively looking for compile issues on -current, > but if someone hands me a patch like that I apply it to save myself > future work... > _______________________________________________ > 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 yth at ythogtha.org Tue Aug 14 08:10:15 2018 From: yth at ythogtha.org (Ythogtha) Date: Tue, 14 Aug 2018 10:10:15 +0200 Subject: [Slackbuilds-users] Does anyone have trouble building DevIL ? In-Reply-To: References: <20180813214214.cc338f6544c7e8378972f504@ythogtha.org> Message-ID: <20180814101015.5250823ace9c3ee5a169d7b1@ythogtha.org> > On 8/13/18, Ythogtha wrote: > > Here is what happens when I try to build DevIL 1.8.0 (I already have 1.7.8 > > built and installed) : > > [ 40%] Building CXX object src-IL/CMakeFiles/IL.dir/src/il_dds-save.cpp.o > > /tmp/SBo/DevIL/DevIL/src-IL/src/il_dds-save.cpp: In function 'ILuint > > Compress(ILimage*, ILenum)': > > /tmp/SBo/DevIL/DevIL/src-IL/src/il_dds-save.cpp:711:32: error: invalid > > conversion from 'void*' to 'ILubyte* {aka unsigned char*}' [-fpermissive] > > ByteData = ilConvertBuffer(Image->SizeOfData, Image->Format, IL_BGRA, > > Image->Type, IL_UNSIGNED_BYTE, NULL, Image->Data); > > > > Does anyone have the same issue ? > > No, but... > > > Any idea ? > > It's telling you what to do in the very error message itself: add > -fpermissive to the compile command. Easy way would be to add it to > SLKCFLAGS just after the if/else block that sets it: > > SLKCFLAGS="$SLKCFLAGS -fpermissive" > > You on -current, or did you get this error on 14.2? I'm on 14.2, that's why I'm raising the issue. If nobody else has the same problem then it probably comes from my own box, but the error does not point to an interference with another slackbuilded package... I don't have a problem with adding -fpermissive on my own DevIL slackbuild, but if I need to tweak on my up-to-date-and-fully-patched 14.2 whereas other don't, then my box might be somehow broken... The problem might come from the multilib install, but again, I don't see anything relevant to that in the error message. -- Arnaud From orbea at fredslev.dk Tue Aug 14 14:54:59 2018 From: orbea at fredslev.dk (orbea at fredslev.dk) Date: Tue, 14 Aug 2018 07:54:59 -0700 Subject: [Slackbuilds-users] Does anyone have trouble building DevIL ? In-Reply-To: Message-ID: <20180814075459.65ed2008@Akita.witch.org> > ?You?re going to have to when 15 is released?? You don?t know that. > I?ll deal with 15 compatibility when a release candidate is out, not > before. I just want to point out that I tried to compile DevIL on current and found no build issues. I next built it again without issues on a clean 14.2 chroot. Ythogtha's system may not necessarily be broken though, it could be interesting to know what the difference is. From yth at ythogtha.org Tue Aug 14 17:50:06 2018 From: yth at ythogtha.org (Ythogtha) Date: Tue, 14 Aug 2018 19:50:06 +0200 Subject: [Slackbuilds-users] Does anyone have trouble building DevIL ? In-Reply-To: <20180814075459.65ed2008@Akita.witch.org> References: <20180814075459.65ed2008@Akita.witch.org> Message-ID: <20180814195006.8d526b2eef0c33c254fa59a3@ythogtha.org> > > ?You?re going to have to when 15 is released?? You don?t know that. > > > I?ll deal with 15 compatibility when a release candidate is out, not > > before. > > I just want to point out that I tried to compile DevIL on current and > found no build issues. I next built it again without issues on a clean > 14.2 chroot. Ythogtha's system may not necessarily be broken though, it > could be interesting to know what the difference is. > _______________________________________________ > 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/ > And so, I found the culprit! Addind -fpermissive actually goes to another error implicating the package "nvidia-texture-tools", precisely nvcore/Memory.h. After removing this package, DevIL builds perfectly fine, even without -fpermissive. So there seems to be an incompatibility between those two packages -- Arnaud From skaendo at excite.com Wed Aug 15 11:21:40 2018 From: skaendo at excite.com (Ed Ender) Date: Wed, 15 Aug 2018 07:21:40 -0400 Subject: [Slackbuilds-users] qt5 is sorely in need of an update Message-ID: <20180815072140.27083@web001.roc2.bluetie.com> Has it been mentioned that qt 5.7.x is no longer even available from qt.io? http://download.qt.io/official_releases/qt/ If it has please ignore me. -Ed From yalhcru at gmail.com Wed Aug 15 18:40:41 2018 From: yalhcru at gmail.com (B Watson) Date: Wed, 15 Aug 2018 14:40:41 -0400 Subject: [Slackbuilds-users] Does anyone have trouble building DevIL ? In-Reply-To: References: <20180813214214.cc338f6544c7e8378972f504@ythogtha.org> Message-ID: On 8/14/18, Doogster wrote: > You re going to have to when 15 is released ? You don t know that. What I meant by that badly-worded statement was: if it had turned out to be an incompatibility between the code and -current's newer compiler, so -fpermissive was required by the new gcc/g++, then 15's compiler would have the same issue (it will be the same or newer than the gcc in -current). gcc/g++ gets more & more strict with each release. Code that used to compile either needs extra compiler flags or patches. That's what I meant by having to deal with it eventually. In this case that wasn't the real issue (the guy wasn't even running -current), so that advice was useless to you, but the point still stands in general. From didier at slint.fr Wed Aug 15 19:06:04 2018 From: didier at slint.fr (Didier Spaier) Date: Wed, 15 Aug 2018 21:06:04 +0200 Subject: [Slackbuilds-users] Does anyone have trouble building DevIL ? In-Reply-To: References: <20180813214214.cc338f6544c7e8378972f504@ythogtha.org> Message-ID: <1385bc8b-a698-1226-6863-d91869d9f648@slint.fr> On 08/15/2018 08:40 PM, B Watson wrote: >... but the point still stands in general.Then the maintainer should not stand still when the time comes. Sorry, I couldn't resist. I can't remember in the lyrics of which opera I heard "stand still". Anyone? From atelszewski at gmail.com Fri Aug 17 16:20:47 2018 From: atelszewski at gmail.com (Andrzej Telszewski) Date: Fri, 17 Aug 2018 18:20:47 +0200 Subject: [Slackbuilds-users] libvirt 4.6.0 is a mess Message-ID: Hi, I've been contacting Robby, but since I haven't received any reply nor I see any correction in the git, I decided to come to the list, so you can take action before the next public update. With version 4.6.0, libvirt has switched from yajl to Jansson. Unfortunately, this switch comes with more problems than it solves: https://bugzilla.redhat.com/show_bug.cgi?id=1614959 https://bugzilla.redhat.com/show_bug.cgi?id=1614569 I've actually experienced the bugs mentioned in the above threads. libvirt team has already switched back for yajl for the next version. What I propose is that you withdraw the 4.6.0 update. Alternatively, you can update for version 4.5.0; the only change needed is changing back to yajl in REQUIRES and --with-yajl. Hope this helps. -- Best regards / Pozdrawiam, Andrzej Telszewski From didier at slint.fr Fri Aug 17 16:35:28 2018 From: didier at slint.fr (Didier Spaier) Date: Fri, 17 Aug 2018 18:35:28 +0200 Subject: [Slackbuilds-users] libvirt 4.6.0 is a mess In-Reply-To: References: Message-ID: <5a84390d-a1c6-8a38-4dcc-9e4c483364ce@slint.fr> Hi, On 08/17/2018 06:20 PM, Andrzej Telszewski wrote: > Hi, > > I've been contacting Robby, but since I haven't received any reply nor I see any correction in the git, I decided to come to the list, so you can take action before the next public update. > > With version 4.6.0, libvirt has switched from yajl to Jansson. > Unfortunately, this switch comes with more problems than it solves: > > https://bugzilla.redhat.com/show_bug.cgi?id=1614959 > https://bugzilla.redhat.com/show_bug.cgi?id=1614569 > > I've actually experienced the bugs mentioned in the above threads. > > libvirt team has already switched back for yajl for the next version. > > What I propose is that you withdraw the 4.6.0 update. > Alternatively, you can update for version 4.5.0; the only change needed is changing back to yajl in REQUIRES and --with-yajl. But the version in https://slackbuilds.org/repository/14.2/libraries/libvirt/ is 4.0.O at time of writing so I don't understand what you request Robby to do, nor why there should be a correction in git. Did you request an upgrade to 4.6.0 to Robby already, and want to withdraw this request? Didier From atelszewski at gmail.com Fri Aug 17 16:41:00 2018 From: atelszewski at gmail.com (Andrzej Telszewski) Date: Fri, 17 Aug 2018 18:41:00 +0200 Subject: [Slackbuilds-users] libvirt 4.6.0 is a mess In-Reply-To: <5a84390d-a1c6-8a38-4dcc-9e4c483364ce@slint.fr> References: <5a84390d-a1c6-8a38-4dcc-9e4c483364ce@slint.fr> Message-ID: <3bed7ee6-3323-f59f-31bd-85877a2601c5@gmail.com> On 17/08/2018 18:35, Didier Spaier wrote: > Hi, > > On 08/17/2018 06:20 PM, Andrzej Telszewski wrote: >> Hi, >> >> I've been contacting Robby, but since I haven't received any reply nor I see any correction in the git, I decided to come to the list, so you can take action before the next public update. >> >> With version 4.6.0, libvirt has switched from yajl to Jansson. >> Unfortunately, this switch comes with more problems than it solves: >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1614959 >> https://bugzilla.redhat.com/show_bug.cgi?id=1614569 >> >> I've actually experienced the bugs mentioned in the above threads. >> >> libvirt team has already switched back for yajl for the next version. >> >> What I propose is that you withdraw the 4.6.0 update. >> Alternatively, you can update for version 4.5.0; the only change needed is changing back to yajl in REQUIRES and --with-yajl. > > But the version in https://slackbuilds.org/repository/14.2/libraries/libvirt/ is 4.0.O at time of writing so I don't understand what you request Robby to do, nor why there should be a correction in git. > > Did you request an upgrade to 4.6.0 to Robby already, and want to withdraw this request? > > Didier I'd like those to be withdrawn: https://git.slackbuilds.org/slackbuilds/commit/?id=dee223978 https://git.slackbuilds.org/slackbuilds/commit/?id=92f08be5b before the public update. -- Best regards / Pozdrawiam, Andrzej Telszewski From didier at slint.fr Fri Aug 17 18:43:21 2018 From: didier at slint.fr (Didier Spaier) Date: Fri, 17 Aug 2018 20:43:21 +0200 Subject: [Slackbuilds-users] libvirt 4.6.0 is a mess In-Reply-To: <3bed7ee6-3323-f59f-31bd-85877a2601c5@gmail.com> References: <5a84390d-a1c6-8a38-4dcc-9e4c483364ce@slint.fr> <3bed7ee6-3323-f59f-31bd-85877a2601c5@gmail.com> Message-ID: On 08/17/2018 06:41 PM, Andrzej Telszewski wrote: > On 17/08/2018 18:35, Didier Spaier wrote: >> Hi, >> >> On 08/17/2018 06:20 PM, Andrzej Telszewski wrote: >>> Hi, >>> >>> I've been contacting Robby, but since I haven't received any reply nor I see any correction in the git, I decided to come to the list, so you can take action before the next public update. >>> >>> With version 4.6.0, libvirt has switched from yajl to Jansson. >>> Unfortunately, this switch comes with more problems than it solves: >>> >>> https://bugzilla.redhat.com/show_bug.cgi?id=1614959 >>> https://bugzilla.redhat.com/show_bug.cgi?id=1614569 >>> >>> I've actually experienced the bugs mentioned in the above threads. >>> >>> libvirt team has already switched back for yajl for the next version. >>> >>> What I propose is that you withdraw the 4.6.0 update. >>> Alternatively, you can update for version 4.5.0; the only change needed is changing back to yajl in REQUIRES and --with-yajl. >> >> But the version in? https://slackbuilds.org/repository/14.2/libraries/libvirt/ is 4.0.O at time of writing so I don't understand what you request Robby to do, nor why there should be a correction in git. >> >> Did you request an upgrade to 4.6.0 to Robby already, and want to withdraw this request? >> >> Didier > > I'd like those to be withdrawn: > > https://git.slackbuilds.org/slackbuilds/commit/?id=dee223978 > https://git.slackbuilds.org/slackbuilds/commit/?id=92f08be5b > > before the public update. I looked in the 14.2 branch, sorry. Didier From willysr at slackbuilds.org Sat Aug 18 02:42:52 2018 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sat, 18 Aug 2018 09:42:52 +0700 Subject: [Slackbuilds-users] Updates - 20180818.1 Message-ID: <8b249eae-a1d9-a604-c89c-ea15add508e2@slackbuilds.org> Hi we have some security updates in this batch: nodejs, nodejs6, webkit2gtk, flashplayer, pepperflash, intel-microcode. LibreOffice from source is now in sync with the repackage version Sat Aug 18 01:41:06 UTC 2018 academic/ITK: Remove unnecessary pkg-config file. academic/boinc: Added (Open-source software for grid computing). desktop/ctwm: New maintainer. desktop/cwm: New maintainer. desktop/docfetcher: Updated for version 1.1.22. desktop/oomox: Updated for version 1.7.0.1. desktop/tint2: Updated for version 16.6. desktop/xkblayout-state: Updated for version 1b_git20180812. development/bless: Added (GUI hex editor). development/composer: Updated for version 1.7.1 development/d-tools: Updated for version 2.081.2 development/dmd: Updated for version 2.081.2 development/hopper: Updated for version 4.3.27. development/ioncube-loader: Updated for version 10.2.4 development/jupyter-qtconsole: Updated for version 4.4.0. development/nchexedit: Add Debian bugfix patches. development/neovim-qt: Updated for version 0.2.9. development/nodejs6: Updated for version 6.14.4. development/nodejs: Updated for version 8.11.4. development/pycharm: Updated for version 2018.2.1. development/slibtool: Updated for version 0.5.25. development/tanya: Updated for version 0.11.1 development/textadept: Updated for version 10.0. development/universal-ctags: Updated for version a0206b0 games/OpenRA: Updated for version 20180307. games/SameBoy: Updated for version 0.11.1. games/alephone: Fix build without ffmpeg. games/libretro-ppsspp: Removed (please use ppsspp instead). games/lutris: Updated for version 0.4.18. games/ppsspp: Updated for version 1.6.3. games/stone_soup: Updated for version 0.22.0. gis/gpxsee: Updated for version 5.16. gis/openorienteering-mapper: Updated for version 0.8.2. graphics/graphite2: Updated for version 1.3.12. libraries/GtkD: Updated for version 3.8.3. libraries/Impacket: Updated for version 0.9.17. libraries/jansson: Updated for version 2.11 libraries/libcmis: Updated to build with boost-1.68 in -current. libraries/libmirage: Updated for version 3.2.0 + new maintainer. libraries/libnumbertext: Added (Number & money text conversion lib). libraries/libuv: Updated for version 1.23.0. libraries/libvirt-glib: Updated download location to use https libraries/protobuf-c: Updated for version 1.3.1. libraries/webkit2gtk: Updated for version 2.20.5. libraries/wxGTK3: Fix symlink for static build. misc/gramps: Updated for version 5.0.0. multimedia/flashplayer-plugin: Updated for version 30.0.0.154. multimedia/pepperflash-plugin: Updated for version 30.0.0.154. network/liferea: Updated for version 1.12.4. network/r8168: Updated for version 8.046.00. network/signal-desktop: Updated for version 1.15.4. network/sqlmap: Updated for version 1.2.8. network/yle-dl: Updated for version 2.35. office/LibreOffice: Updated for version 6.1.0.3 office/pdf2djvu: Updated for version 0.9.10. perl/perl-IO-Socket-SSL: Updated for version 2.059. python/astroid: Downgraded for version 1.6.5. python/bleach: Updated for version 2.1.4. python/bsddb3: Updated for version 6.2.6. python/mini-amf: Updated REQUIRES. python/munch: Add Python 3 support. python/phply: Updated for version 1.2.5. python/pyotp: Added (Python one-time password library). python/pyperclip: Updated for version 1.6.4. python/python-pcapy: Updated for version 0.11.4. python/python-prometheus_client: Updated for version 0.3.1. python/python-vulndb: Updated for version 0.1.0. python/python3-astroid: Added (new abstract syntax tree). python/python3-isort: Added (sort imports alphabetically). python/python3-mccabe: Added (Complexity checker for Python). python/setuptools-scm: Updated for version 3.1.0. python/typed_ast: Added (abstract syntax tree parser). schroot: Updated for version 1.6.10. system/asbt: Updated for version 1.9.2. system/borgbackup: Updated for version 1.1.7. system/cdemu-client: Updated for version 3.2.0 + new maintainer. system/cdemu-daemon: Updated for version 3.2.1 + new maintainer. system/fio: Updated for version 3.8. system/gcdemu: Updated for version 3.2.0. system/image-analyzer: Updated for version 3.2.0. system/intel-microcode: Updated for version 20180807. system/man-db: Updated for version 2.8.4. system/openstego: Updated for version 0.7.3, new maintainer. system/qtfm: Updated for version 6.1.0 + new maintainer. system/refind: Updated for version 0.11.3. system/the_silver_searcher: Updated for version 2.2.0. system/tilix: Updated for version 1.8.1. system/trashy: Updated for version 2.3. system/vhba-module: New maintainer. +--------------------------+ -- Willy Sudiarto Raharjo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From idlemoor at slackbuilds.org Sat Aug 18 09:36:49 2018 From: idlemoor at slackbuilds.org (David Spencer) Date: Sat, 18 Aug 2018 10:36:49 +0100 Subject: [Slackbuilds-users] Serious regression on Github archive URLs Message-ID: <120f5429-0e2e-5a7b-5e36-c7295331a7d8@slackbuilds.org> Hey folks, Github has just broken the download of about 1000 of our SlackBuilds. If you get problems downloading with wget, or curl, or sbopkg, there are 2 things you can do: (1) Download manually with a browser -- this still seems to work; or (2) Visit sbosrcarch at http://slackware.uk/sbosrcarch/by-name/ Below is the text of a grumpy email I just sent to Github support. Have a great day everybody! -D. ----------------------------------------- Hi, Within the last 24 hours, for every repo on Github, archive URLS of the form https://github.com///archive//-.tar.gz have stopped working. They now return 404 from within codeload.github.com even though the github.com front end still accepts them as valid. I've attached a log for a typical test case: https://github.com/geopython/OWSLib/archive/0.16.0/OWSLib-0.16.0.tar.gz Strangely, this works for manual downloads within some browsers, but it is a serious regression that this suddenly no longer works with scriptable downloaders like curl and wget. As far as we can determine, every repo in Github is affected. Please advise. ----------------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From slackbuilds at jaxartes.net Sat Aug 18 13:52:14 2018 From: slackbuilds at jaxartes.net (Benjamin Trigona-Harany) Date: Sat, 18 Aug 2018 06:52:14 -0700 Subject: [Slackbuilds-users] Serious regression on Github archive URLs In-Reply-To: <120f5429-0e2e-5a7b-5e36-c7295331a7d8@slackbuilds.org> References: <120f5429-0e2e-5a7b-5e36-c7295331a7d8@slackbuilds.org> Message-ID: <1687752.ETMLi4S0Ay@wintermute.sprawl.net> On Saturday, 18 August 2018 02:36:49 PDT David Spencer wrote: > Hey folks, > > Github has just broken the download of about 1000 of our SlackBuilds. > > If you get problems downloading with wget, or curl, or sbopkg, there are > 2 things you can do: > > (1) Download manually with a browser -- this still seems to work; or If you are logged into GitHub that is ... > (2) Visit sbosrcarch at http://slackware.uk/sbosrcarch/by-name/ > (3) Hack it Here's a terrible work-around: GitHub is still redirecting our SBo URLs correctly, but only if you are authenticated. By inspecting your browser's http traffic with GitHub, you could grab your cookie and add it as a line to .wgetrc, giving something like: header=Cookie: logged_in=yes; user_session=xxx; __Host- user_session_same_site=xxx; dotcom_user=bosth; _gh_sess=xxx I don't actually suggest doing this since using wget with any other website will be sharing your session via HTTP headers. You could probably put your GitHub username and password in .wgetrc but that's an even worse idea? > Below is the text of a grumpy email I just sent to Github support. > > Have a great day everybody! > -D. > > > ----------------------------------------- > > Hi, > > Within the last 24 hours, for every repo on Github, archive URLS of the form > > https://github.com///archive//-.tar.gz > > have stopped working. They now return 404 from within > codeload.github.com even though the github.com front end still accepts > them as valid. > > I've attached a log for a typical test case: > > https://github.com/geopython/OWSLib/archive/0.16.0/OWSLib-0.16.0.tar.gz > > Strangely, this works for manual downloads within some browsers, but it > is a serious regression that this suddenly no longer works with > scriptable downloaders like curl and wget. > > As far as we can determine, every repo in Github is affected. > > Please advise. > > ----------------------------------------- From slackbuilds at jaxartes.net Sat Aug 18 16:17:05 2018 From: slackbuilds at jaxartes.net (Benjamin Trigona-Harany) Date: Sat, 18 Aug 2018 09:17:05 -0700 Subject: [Slackbuilds-users] Serious regression on Github archive URLs In-Reply-To: <1687752.ETMLi4S0Ay@wintermute.sprawl.net> References: <120f5429-0e2e-5a7b-5e36-c7295331a7d8@slackbuilds.org> <1687752.ETMLi4S0Ay@wintermute.sprawl.net> Message-ID: <12488921.vaq0dhzCk6@wintermute.sprawl.net> Here is what I believe to be a reasonably safe way of getting wget to work again as long as you have a GitHub account: 1. In GitHub's settings, find "Developer Settings" 2. Click "Personal access tokens" 3. Click "Generate new token" 4. Select "public_repo" (nothing else!) 5. Click "Generate token" 6. Add the following line to .wgetrc (replacing TOKEN with the token you just generated header=Authorization: token TOKEN As far as I can tell, the drawback is that you are exposing your GitHub token to every server wget interacts with, but (1) there is no indication that it's a GitHub token and (2) the only permission the token has is to interact with public repositories. "public_repo: Grants read/write access to code, commit statuses, collaborators, and deployment statuses for public repositories and organizations. Also required for starring public repositories." If this works for your user account and you are comfortable with the paragraph above, you can then add the line to /etc/wgetrc and normal service will be resumed. From artourter at gmail.com Sat Aug 18 16:41:18 2018 From: artourter at gmail.com (Greg' Ar Tourter) Date: Sat, 18 Aug 2018 17:41:18 +0100 Subject: [Slackbuilds-users] Serious regression on Github archive URLs In-Reply-To: <12488921.vaq0dhzCk6@wintermute.sprawl.net> References: <120f5429-0e2e-5a7b-5e36-c7295331a7d8@slackbuilds.org> <1687752.ETMLi4S0Ay@wintermute.sprawl.net> <12488921.vaq0dhzCk6@wintermute.sprawl.net> Message-ID: Thanks for the heads up David and nice find Benjamin. Not ideal as it requires users to actually have a github account but still gets people back and running until github stop being idiots. I have added the token to sbopkg.conf instead as at least it will only be used when using sbopkg rather than every time I use wget. Cheers Greg On Sat, 18 Aug 2018 at 17:12, Benjamin Trigona-Harany wrote: > > Here is what I believe to be a reasonably safe way of getting wget to work > again as long as you have a GitHub account: > > 1. In GitHub's settings, find "Developer Settings" > 2. Click "Personal access tokens" > 3. Click "Generate new token" > 4. Select "public_repo" (nothing else!) > 5. Click "Generate token" > 6. Add the following line to .wgetrc (replacing TOKEN with the token you just > generated > header=Authorization: token TOKEN > > As far as I can tell, the drawback is that you are exposing your GitHub token > to every server wget interacts with, but (1) there is no indication that it's > a GitHub token and (2) the only permission the token has is to interact with > public repositories. > > "public_repo: Grants read/write access to code, commit statuses, > collaborators, and deployment statuses for public repositories and > organizations. Also required for starring public repositories." > > If this works for your user account and you are comfortable with the paragraph > above, you can then add the line to /etc/wgetrc and normal service will be > resumed. > > > _______________________________________________ > 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 slackbuilds at jaxartes.net Sat Aug 18 17:42:45 2018 From: slackbuilds at jaxartes.net (Benjamin Trigona-Harany) Date: Sat, 18 Aug 2018 10:42:45 -0700 Subject: [Slackbuilds-users] Serious regression on Github archive URLs In-Reply-To: <12488921.vaq0dhzCk6@wintermute.sprawl.net> References: <120f5429-0e2e-5a7b-5e36-c7295331a7d8@slackbuilds.org> <1687752.ETMLi4S0Ay@wintermute.sprawl.net> <12488921.vaq0dhzCk6@wintermute.sprawl.net> Message-ID: <3189680.DuRiLmyTp8@wintermute.sprawl.net> Hopefully my last email on this topic. Here's my recommended solution that should be fully safe even if it does still requires a GitHub account: 1. Get your token as in my previous email 2. Add a .netrc for root with the following line: machine github.com login TOKEN password slack 3. Make sure wget is being called with the --auth-no-challenge flag. For exampl,e I have the following in my sbopkg.conf: WGETFLAGS="${WGETFLAGS:--c --progress=bar:force --timeout=30 --tries=5} -- auth-no-challenge" As far as I can tell you need *something* for a password in .netrc - blank won't do - hence the "slack". In any case, .netrc will restrict the use of your GitHub token to only the GitHub domain. Unfortunately, wget needed the extra --auth-no-challenge flag, unlike cURL, but adding this as a default is less disruptive than updating 1000-odd SlackBuilds to accommodate the change in how GitHub is handling these URLs. Ben From eric.b.pratt at gmail.com Sat Aug 18 18:10:45 2018 From: eric.b.pratt at gmail.com (Eric Pratt) Date: Sat, 18 Aug 2018 11:10:45 -0700 Subject: [Slackbuilds-users] Serious regression on Github archive URLs In-Reply-To: <3189680.DuRiLmyTp8@wintermute.sprawl.net> References: <120f5429-0e2e-5a7b-5e36-c7295331a7d8@slackbuilds.org> <1687752.ETMLi4S0Ay@wintermute.sprawl.net> <12488921.vaq0dhzCk6@wintermute.sprawl.net> <3189680.DuRiLmyTp8@wintermute.sprawl.net> Message-ID: On Sat, Aug 18, 2018 at 10:37 AM Benjamin Trigona-Harany wrote: > > Hopefully my last email on this topic. Here's my recommended solution that > should be fully safe even if it does still requires a GitHub account: > > 1. Get your token as in my previous email > 2. Add a .netrc for root with the following line: > machine github.com login TOKEN password slack > 3. Make sure wget is being called with the --auth-no-challenge flag. For > exampl,e I have the following in my sbopkg.conf: > WGETFLAGS="${WGETFLAGS:--c --progress=bar:force --timeout=30 --tries=5} -- > auth-no-challenge" > > As far as I can tell you need *something* for a password in .netrc - blank > won't do - hence the "slack". In any case, .netrc will restrict the use of > your GitHub token to only the GitHub domain. > > Unfortunately, wget needed the extra --auth-no-challenge flag, unlike cURL, > but adding this as a default is less disruptive than updating 1000-odd > SlackBuilds to accommodate the change in how GitHub is handling these URLs. > > Ben I'm not sure I fully understand the problem, but here's what I found. It looks like the URL pattern has changed to: https://github.com///archive/. So this works: $ ls $ wget -q https://github.com/geopython/OWSLib/archive/0.16.0.tar.gz $ ls 0.16.0.tar.gz $ tar -xzf 0.16.0.tar.gz $ ls 0.16.0.tar.gz OWSLib-0.16.0/ $ I tried this with a few projects with github DOWNLOAD URLs in the sbo repo and it's working for all of them. No account is needed. On a side note, it appears that out of 1468 DOWNLOAD= entries in the repo that use github, 7 of them are using http while the rest are using https. $ grep -r '^DOWNLOAD=' * | grep -o 'http[s]*://github.*$' | wc -l 1468 $ grep -r '^DOWNLOAD=' * | grep -o 'http://github.*$' | wc -l 7 $ grep -r '^DOWNLOAD=' * | grep -o 'https://github.*$' | wc -l 1461 It might be a good time to change all github downloads to use https URLs. I know it's a minor issue. But I stumbled across it while looking into this and thought I would do a one-time nag in case it matters. From thedoogster at gmail.com Sat Aug 18 18:56:58 2018 From: thedoogster at gmail.com (Doogster) Date: Sat, 18 Aug 2018 11:56:58 -0700 Subject: [Slackbuilds-users] Serious regression on Github archive URLs In-Reply-To: References: <120f5429-0e2e-5a7b-5e36-c7295331a7d8@slackbuilds.org> <1687752.ETMLi4S0Ay@wintermute.sprawl.net> <12488921.vaq0dhzCk6@wintermute.sprawl.net> <3189680.DuRiLmyTp8@wintermute.sprawl.net> Message-ID: Yeah, the changed URL clearly seen in the user-facing "Releases" page. I can confirm that this works: wget --content-disposition https://github.com/geopython/OWSLib/archive/0.16.0.tar.gz That downloads the following file: OWSLib-0.16.0.tar.gz Honestly, all 1000 SlackBuilds can probably be fixed with one sed command. On Sat, Aug 18, 2018 at 11:11 AM Eric Pratt wrote: > > On Sat, Aug 18, 2018 at 10:37 AM Benjamin Trigona-Harany > wrote: > > > > Hopefully my last email on this topic. Here's my recommended solution that > > should be fully safe even if it does still requires a GitHub account: > > > > 1. Get your token as in my previous email > > 2. Add a .netrc for root with the following line: > > machine github.com login TOKEN password slack > > 3. Make sure wget is being called with the --auth-no-challenge flag. For > > exampl,e I have the following in my sbopkg.conf: > > WGETFLAGS="${WGETFLAGS:--c --progress=bar:force --timeout=30 --tries=5} -- > > auth-no-challenge" > > > > As far as I can tell you need *something* for a password in .netrc - blank > > won't do - hence the "slack". In any case, .netrc will restrict the use of > > your GitHub token to only the GitHub domain. > > > > Unfortunately, wget needed the extra --auth-no-challenge flag, unlike cURL, > > but adding this as a default is less disruptive than updating 1000-odd > > SlackBuilds to accommodate the change in how GitHub is handling these URLs. > > > > Ben > > I'm not sure I fully understand the problem, but here's what I found. > It looks like the URL pattern has changed to: > > https://github.com///archive/. > > So this works: > > $ ls > $ wget -q https://github.com/geopython/OWSLib/archive/0.16.0.tar.gz > $ ls > 0.16.0.tar.gz > $ tar -xzf 0.16.0.tar.gz > $ ls > 0.16.0.tar.gz OWSLib-0.16.0/ > $ > > I tried this with a few projects with github DOWNLOAD URLs in the sbo > repo and it's working for all of them. No account is needed. > > On a side note, it appears that out of 1468 DOWNLOAD= entries in the > repo that use github, 7 of them are using http while the rest are > using https. > > $ grep -r '^DOWNLOAD=' * | grep -o 'http[s]*://github.*$' | wc -l > 1468 > $ grep -r '^DOWNLOAD=' * | grep -o 'http://github.*$' | wc -l > 7 > $ grep -r '^DOWNLOAD=' * | grep -o 'https://github.*$' | wc -l > 1461 > > It might be a good time to change all github downloads to use https > URLs. I know it's a minor issue. But I stumbled across it while > looking into this and thought I would do a one-time nag in case it > matters. > _______________________________________________ > 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 eric.b.pratt at gmail.com Sat Aug 18 19:26:31 2018 From: eric.b.pratt at gmail.com (Eric Pratt) Date: Sat, 18 Aug 2018 12:26:31 -0700 Subject: [Slackbuilds-users] Serious regression on Github archive URLs In-Reply-To: References: <120f5429-0e2e-5a7b-5e36-c7295331a7d8@slackbuilds.org> <1687752.ETMLi4S0Ay@wintermute.sprawl.net> <12488921.vaq0dhzCk6@wintermute.sprawl.net> <3189680.DuRiLmyTp8@wintermute.sprawl.net> Message-ID: On Sat, Aug 18, 2018 at 11:56 AM Doogster wrote: > > Yeah, the changed URL clearly seen in the user-facing "Releases" page. > I can confirm that this works: > > wget --content-disposition > https://github.com/geopython/OWSLib/archive/0.16.0.tar.gz > > That downloads the following file: > > OWSLib-0.16.0.tar.gz > > Honestly, all 1000 SlackBuilds can probably be fixed with one sed command. FYI, my previous wget example wont download with the proper name, but using wget with --content-disposition does. Curl has a similar option. So to improve my previous example, either of these would get you the proper filename: wget -q --content-disposition https://github.com/geopython/OWSLib/archive/0.16.0.tar.gz curl -JLOs https://github.com/geopython/OWSLib/archive/0.16.0.tar.gz And I agree that it would be easier just to make a quick change to the github DOWNLOAD links in the repo. From idlemoor at slackbuilds.org Sat Aug 18 19:27:50 2018 From: idlemoor at slackbuilds.org (David Spencer) Date: Sat, 18 Aug 2018 20:27:50 +0100 Subject: [Slackbuilds-users] Serious regression on Github archive URLs In-Reply-To: References: <120f5429-0e2e-5a7b-5e36-c7295331a7d8@slackbuilds.org> <1687752.ETMLi4S0Ay@wintermute.sprawl.net> <12488921.vaq0dhzCk6@wintermute.sprawl.net> <3189680.DuRiLmyTp8@wintermute.sprawl.net> Message-ID: <62df1106-5fd0-17b1-2e57-783dc35a75a5@slackbuilds.org> > Yeah, the changed URL clearly seen in the user-facing "Releases" page. > I can confirm that this works: > > wget --content-disposition > https://github.com/geopython/OWSLib/archive/0.16.0.tar.gz > > That downloads the following file: > > OWSLib-0.16.0.tar.gz Sorry, Eric and Dugan, but no. The whole point of using the URLs we have standardised on, and not the above pattern of URL (which has always been around), is to eliminate the difference between having content disposition and not having content disposition. And it's not just the .info files we would need to modify but also all the SlackBuild files, to reinstate all the '|| tar xvf $VERSION.tar.gz' clauses (in their many variants) that we've worked so long to remove. This is a *regression*. Github broke it and they need to fix it. Cheers -D. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From slackbuilds at jaxartes.net Sat Aug 18 19:35:39 2018 From: slackbuilds at jaxartes.net (Benjamin Trigona-Harany) Date: Sat, 18 Aug 2018 19:35:39 +0000 Subject: [Slackbuilds-users] Serious regression on Github archive URLs In-Reply-To: <62df1106-5fd0-17b1-2e57-783dc35a75a5@slackbuilds.org> References: <120f5429-0e2e-5a7b-5e36-c7295331a7d8@slackbuilds.org> <1687752.ETMLi4S0Ay@wintermute.sprawl.net> <12488921.vaq0dhzCk6@wintermute.sprawl.net> <3189680.DuRiLmyTp8@wintermute.sprawl.net> <62df1106-5fd0-17b1-2e57-783dc35a75a5@slackbuilds.org> Message-ID: <6B00F268-E0F3-4C0E-87A5-2AA7249553B3@jaxartes.net> On August 18, 2018 7:27:50 PM UTC, David Spencer wrote: >Sorry, Eric and Dugan, but no. > >The whole point of using the URLs we have standardised on, and not the >above pattern of URL (which has always been around), is to eliminate >the >difference between having content disposition and not having content >disposition. > >And it's not just the .info files we would need to modify but also all >the SlackBuild files, to reinstate all the '|| tar xvf $VERSION.tar.gz' >clauses (in their many variants) that we've worked so long to remove. > >This is a *regression*. Github broke it and they need to fix it. To echo David, my hope is that the old behaviour will be restored without having to make modifications to all the scripts, which is why the netrc trick is nice to tide folks over until that fix comes. It isn't meant to be a permanent solution. Ben From kingbeowulf at gmail.com Sat Aug 18 20:28:08 2018 From: kingbeowulf at gmail.com (King Beowulf) Date: Sat, 18 Aug 2018 13:28:08 -0700 Subject: [Slackbuilds-users] compiling mlt-6.10 with qt5-5.7.1 SBo version Message-ID: <46b93484-a93a-27e8-2101-a2223ce42a8b@gmail.com> Hello! The details are here: https://www.linuxquestions.org/questions/slackware-14/can%27t-compile-mlt-6-10-0-on-stable-4175636167/#post5890571 If you need to compile mlt with QT5 support, QT5 must be compile with C++11, and mlt needs added flag to tell configure about c++11. Otherwise compile/install mlt first (defaults to qt4) and then compile/install qt5. Attached are 2 diffs against today's SBo master to resolve this issue. Have fun. -Ed -------------- next part -------------- A non-text attachment was scrubbed... Name: qt5_with_c11.diff Type: text/x-patch Size: 849 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: mlt_with_qt5.diff Type: text/x-patch Size: 1301 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: OpenPGP digital signature URL: From jgraham at compukix.net Sun Aug 19 04:34:07 2018 From: jgraham at compukix.net (Jason Graham) Date: Sun, 19 Aug 2018 00:34:07 -0400 Subject: [Slackbuilds-users] Fix for iotop issue with 4.4.144 kernel Message-ID: Hi, iotop is broken with the latest Slackware kernel. I've included the maintainer here, but also posting the note and a patch for the iotop SlackBuild to the list for further review. A few comments regarding the issue and patch: Recent kernels, including Slackware's 4.4.144 kernel, have introduced at least one blank line in /proc//status which breaks the parse_proc_pid_status() function in iotop/data.py. The added patch fix-proc-status-read.patch updates this function to skip empty lines. Additional reports of this issue can be found here:? ??? [1] https://bugzilla.redhat.com/show_bug.cgi?id=1584612? ??? [2] https://unix.stackexchange.com/questions/446624/error-with-command-iotop-on-centos? ??? [3] https://bugs.launchpad.net/pkg-website/+bug/1773383 The fix is based on the report in [2]. Best, Jason -- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-for-iotop-issue-with-4.4.144-kernel.patch Type: text/x-patch Size: 2252 bytes Desc: not available URL: From idlemoor at slackbuilds.org Mon Aug 20 08:28:57 2018 From: idlemoor at slackbuilds.org (David Spencer) Date: Mon, 20 Aug 2018 09:28:57 +0100 Subject: [Slackbuilds-users] Github has now fixed the download problem Message-ID: Hi folks, It seems to be fixed now; if any of you still have problems, please let us know and we'll follo it up. They replied nine hours ago to say: Thanks for reaching out to GitHub Support, and sorry for the trouble. We're currently investigating similar reports regarding this issue, and we've added your report to our list. While we can't share a specific ETA just yet, we'll be sure to update you as soon as there's any news to share! and then they replied six hours ago: I just wanted to let you know that our engineers have recently deployed a fix for this issue, so it should now be resolved. Thanks for your patience, and for taking the time to report the trouble! Let us know if there's anything else we can do. (I was asleep when this happened, so apologies for the delay passing on the good news.) You'll be pleased to know their emails are reply-at-the-top, HTML formatted, with broken quoting of HTML-sensitive characters like < and > *Thanks* to everybody who helped with this, especially bosth, who diagnosed it in detail and created the workround, and yustin, who prepared an emergency mass update in case Github replied with "notfound wontfix". Cheers everybody -D. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From rshepard at appl-ecosys.com Mon Aug 20 14:06:34 2018 From: rshepard at appl-ecosys.com (Rich Shepard) Date: Mon, 20 Aug 2018 07:06:34 -0700 (PDT) Subject: [Slackbuilds-users] gdal-2.3.1 build issue Message-ID: Hi All, I wrote to David 9 days ago about this issue and have not seen any response; perhaps others here can help me build the latest gdal-2.3.1. The SBo version is still 2.2.4. I'm having problems building rgdal and want to learn if a local gdal upgrade from 2.3.0 to 2.3.1 will fix that problem. I've tried building the 2.3.1 version by changing the version number in the script, but hit a curious problem: ... /opt/SBo/gdal-2.3.1/install-sh -d /opt/SBo/package-gdal/usr/doc/gdal-2.3.1/gdal cp html/*.* /opt/SBo/package-gdal/usr/doc/gdal-2.3.1/gdal cp: cannot stat 'COMMITERS': No such file or directory Yet in the untarred source (gdal-2.3.1/) that file is present in the root directory: $ ls COMMITTERS apps/ html/ Have you any thoughts on how to get the build script to recognize that file? TIA, Rich From slackbuilds at jaxartes.net Mon Aug 20 14:14:34 2018 From: slackbuilds at jaxartes.net (Benjamin Trigona-Harany) Date: Mon, 20 Aug 2018 14:14:34 +0000 Subject: [Slackbuilds-users] gdal-2.3.1 build issue In-Reply-To: References: Message-ID: <1F2D885A-B29C-419F-9C9B-2C7C5B4E925E@jaxartes.net> On August 20, 2018 2:06:34 PM UTC, Rich Shepard wrote: > >/opt/SBo/gdal-2.3.1/install-sh -d >/opt/SBo/package-gdal/usr/doc/gdal-2.3.1/gdal >cp html/*.* /opt/SBo/package-gdal/usr/doc/gdal-2.3.1/gdal >cp: cannot stat 'COMMITERS': No such file or directory > >Yet in the untarred source (gdal-2.3.1/) that file is present in the >root >directory: > >$ ls >COMMITTERS apps/ html/ The spelling has been corrected to add the extra T. >Have you any thoughts on how to get the build script to recognize that >file? > >TIA, > >Rich From slackbuilds at jaxartes.net Mon Aug 20 15:48:04 2018 From: slackbuilds at jaxartes.net (Benjamin Trigona-Harany) Date: Mon, 20 Aug 2018 08:48:04 -0700 Subject: [Slackbuilds-users] Github has now fixed the download problem In-Reply-To: References: Message-ID: <6c4508ba-2d14-ef05-46ca-0457b126e09c@jaxartes.net> On 2018-08-20 1:28 a.m., David Spencer wrote: > *Thanks* to everybody who helped with this, especially bosth, who > diagnosed it in detail and created the workround, and yustin, who > prepared an emergency mass update in case Github replied with "notfound > wontfix". If you added a GitHub Personal access token as part of the workaround, don't forget to delete it now! Ben From fernando.lopezjr at gmail.com Mon Aug 20 15:51:37 2018 From: fernando.lopezjr at gmail.com (Fernando Lopez) Date: Mon, 20 Aug 2018 09:51:37 -0600 Subject: [Slackbuilds-users] Github has now fixed the download problem In-Reply-To: <6c4508ba-2d14-ef05-46ca-0457b126e09c@jaxartes.net> References: <6c4508ba-2d14-ef05-46ca-0457b126e09c@jaxartes.net> Message-ID: they probably moved to M$ servers. ?? On Mon, Aug 20, 2018, 9:48 AM Benjamin Trigona-Harany < slackbuilds at jaxartes.net> wrote: > On 2018-08-20 1:28 a.m., David Spencer wrote: > > *Thanks* to everybody who helped with this, especially bosth, who > > diagnosed it in detail and created the workround, and yustin, who > > prepared an emergency mass update in case Github replied with "notfound > > wontfix". > > If you added a GitHub Personal access token as part of the workaround, > don't forget to delete it now! > > Ben > > _______________________________________________ > 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 yalhcru at gmail.com Mon Aug 20 19:20:40 2018 From: yalhcru at gmail.com (B Watson) Date: Mon, 20 Aug 2018 15:20:40 -0400 Subject: [Slackbuilds-users] signal-desktop In-Reply-To: References: Message-ID: (apologies if this is a duplicate message...) signal-desktop doesn't keep old versions, so the download link keeps breaking... but someone packages it for gentoo, so you could use their distfiles server as the download link in your .info file. Here's the file, with md5sum that matches your .info file: https://distfiles.gentoo.org/distfiles/signal-desktop_1.15.4_amd64.deb Also there's a newer version: https://distfiles.gentoo.org/distfiles/signal-desktop_1.15.5_amd64.deb Gentoo distfiles links tend to be stable, and you can see the older version is still there after the new one's released.... From audrius at neutrino.lt Mon Aug 20 20:30:46 2018 From: audrius at neutrino.lt (Audrius =?utf-8?Q?Ka=C5=BEukauskas?=) Date: Mon, 20 Aug 2018 23:30:46 +0300 Subject: [Slackbuilds-users] Fix for iotop issue with 4.4.144 kernel In-Reply-To: <29f90bd7-202a-22b0-cc39-f5e16ccb7456@gmail.com> References: <29f90bd7-202a-22b0-cc39-f5e16ccb7456@gmail.com> Message-ID: <20180820203046.GA15948@varna> Hi, Jason, On Sun, 2018-08-19 at 00:27:25 -0400, Jason Graham wrote: > Hi, > > iotop is broken with the latest Slackware kernel. I've included the > maintainer here, but also posting the note and a patch for the iotop > SlackBuild to the list for further review. > > A few comments regarding the issue and patch: > > Recent kernels, including Slackware's 4.4.144 kernel, have introduced at > least one blank line in /proc//status which breaks the > parse_proc_pid_status() function in iotop/data.py. The patch > fix-proc-status-read.patch updates this > function to skip empty lines. > > Additional reports of this issue can be found here: > > ?[1] https://bugzilla.redhat.com/show_bug.cgi?id=1584612 > ?[2] > https://unix.stackexchange.com/questions/446624/error-with-command-iotop-on-centos > ?[3] https://bugs.launchpad.net/pkg-website/+bug/1773383 > > The fix is based on the report in [2]. Thanks for the heads up. I was on holiday for the last couple of weeks and just now getting back to computer stuff (including SlackBuilds). I'll submit the fix as soon as I can. -- Audrius Ka?ukauskas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: not available URL: From lists at osh.id.au Tue Aug 21 00:55:45 2018 From: lists at osh.id.au (David O'Shaughnessy) Date: Tue, 21 Aug 2018 10:55:45 +1000 Subject: [Slackbuilds-users] signal-desktop In-Reply-To: References: Message-ID: On 08/21/2018 05:20 AM, B Watson wrote: > signal-desktop doesn't keep old versions, so the download link keeps > breaking... but someone packages it for gentoo, so you could use their > distfiles server as the download link in your .info file. I noticed this problem and have been uploading archives to the sbodirectlinks site (also for riot-web), but they didn't seem to be propagating down to sbosrcarch for some reason. I can see that signal-desktop_1.15.4_amd64.deb is on sbosrcarch now, but I'm not sure if that was manual or it propagated from my upload to sbodirectlinks. Do I need to do anything else after uploading an archive to the sbodirectlinks site? -- Dave From chris.willing at linux.com Tue Aug 21 02:55:14 2018 From: chris.willing at linux.com (Christoph Willing) Date: Tue, 21 Aug 2018 12:55:14 +1000 Subject: [Slackbuilds-users] Missing and incorrect libreoffice dependencies. In-Reply-To: <20180812190820.1f97ca4c@Akita.witch.org> References: <20180812190820.1f97ca4c@Akita.witch.org> Message-ID: On 13/08/18 12:08, orbea at fredslev.dk wrote: >> The README goes on to mention a few environment variables that may be >> set in order to change the default build, some of which (VLC, AVAHI) >> have been at your suggestion. There is also a JAVA variable which may >> be set, including JAVA=no for those who know they don't need its >> functionality. I won't go on - I'm sure you've read the README and so >> already know these things. >> >> BTW, you will also know from the libreoffice email list that work is >> in progress to remove the current java dependency. When this is >> complete, I will remove the requirement for any java (and related >> apache-ant). >> >> The requirement for python3 relates to a personal use case that is not >> satisfied by the "internal" python3. I'll continue to exercise my >> prerogative as maintainer to keep python3 as a requirement. It >> certainly doesn't reduce functionality and is so common that many >> (most?) users will already have it installed.> > I do not agree, I think such choices should be left up to the user > especially with arguably undesirable dependencies like java. > > As for python3 its easy to prefer the system python3 and fallback to > the internal one if its missing. > > if pkg-config --exists python3; then > .... > Python3 usage is a slightly special case compared with the optional packages you've listed below, where configuring with --with-system-pkgnam prefers a locally preinstalled version of pkgnam to an internal fallback version. These are build time flags. The --enable-python configuration option refers to Python support at run time, not build time (although there can be a build time implication). Hence --enable-python=system means that the system installed python should be used when running python related LibreOffice features - PyUno in particular (which requires python3). In this case the system python3 is also required at build time in order to build those features. Other --enable-python= possibilities are no, auto, internal and fully-internal which can use the internal fallback python3. However all of these constrain how PyUno can be used i.e. the resulting LibreOffice is not "fully functional" (as is my stated goal). > That said would you mind elaborating on your use case that requires the > system python3? This is the first I recall hearing about it and would > be interested in knowing more. > LibreOffice components are externally controllable with python scripting via PyUno - a python binding of UNO (see: http://www.openoffice.org/udk/) which provides the capability of remote interaction with LibreOffice. I believe there's also a java binding (which I haven't used). A "hello world" example is at: http://lucasmanual.com/mywiki/OpenOffice (however I suggest to invoke the initial empty document with "swriter" not "soffice" as described there). Using system python3 in both LibreOffice build and the runtime example, all works OK. However internal LibreOffice python3 will fail when using the system python3 at runtime for the hello world example and, more importantly, all other real world apps using this feature. An even simpler failure can be seen just by running the system python3 and trying to "import uno". It fails with a ModuleNotFoundError: No module named 'uno' - understandable because it was made for a different python3 installation (the LibreOffice internal installation). You could perhaps work around that by not using the system python, but instead use LibreOffice's built in python3 by starting your script(s) with something like: #!/usr/lib64/libreoffice/programs/python which actually works for the example above but which, if you think about it, is clearly impracticable for anything beyond this type of single file application. So, although it's possible to use the internal python3 supplied by LibreOffice, it's a considerably constrained usage requiring lots of hoop jumping for real world applications. It's much smarter to just use the system python3. What's more, if a system version of either of liborcus or qt5 is used (encouragement of which I believe is the purpose of the list below) then python3 will be required anyway. chris >>> Here is a list of dependencies available at SBo which libreoffice >>> can use and are not currently listed. >>> >>> CoinMP, cppunit, glm, libabw, libcdr, libcmis, libe-book, >>> libeot, libepubgen, libetonyek, libexttextcat, libfreehand, >>> liblangtag, libmspub, libmwaw, liborcus, libpagemaker, libqxp, >>> libstaroffice, libtommath, libwps, libzmf, lpsolve, mdds, >>> mysql-connector-c++, mythes, postgresql, qt5, valgrind, ucpp >>> From yalhcru at gmail.com Tue Aug 21 06:22:20 2018 From: yalhcru at gmail.com (B Watson) Date: Tue, 21 Aug 2018 02:22:20 -0400 Subject: [Slackbuilds-users] signal-desktop In-Reply-To: References: Message-ID: On 8/20/18, David O'Shaughnessy wrote: > I noticed this problem and have been uploading archives to the > sbodirectlinks site (also for riot-web), but they didn't seem to be > propagating down to sbosrcarch for some reason. The URL sbosrcarch was trying (and failed) to download: https://updates.signal.org/desktop/apt/pool/main/s/signal-desktop/signal-desktop_1.15.4_amd64.deb ...straight from the .info file: DOWNLOAD_x86_64="https://updates.signal.org/desktop/apt/pool/main/s/signal-desktop/signal-desktop_1.15.4_amd64.deb" No mention of sbodirectlinks in that URL... same thing for riot-web, you've got the original download site (riot.im) listed in the .info file. If you want sbodirectlinks to be your download URL, you have to change the .info file to point to it, e.g. DOWNLOAD_x86_64="http://sourceforge.net/projects/slackbuildsdirectlinks/files/signal-desktop/signal-desktop_1.15.5_amd64.deb" > I can see that signal-desktop_1.15.4_amd64.deb is on sbosrcarch now, but > I'm not sure if that was manual or it propagated from my upload to > sbodirectlinks. I added it manually, by downloading it from the gentoo distfiles server. > Do I need to do anything else after uploading an archive > to the sbodirectlinks site? Yes. Actually change the download link in the .info file to point to the sbodirectlinks URL. Not much point uploading it there, otherwise... From lists at osh.id.au Tue Aug 21 07:03:44 2018 From: lists at osh.id.au (David O'Shaughnessy) Date: Tue, 21 Aug 2018 17:03:44 +1000 Subject: [Slackbuilds-users] signal-desktop In-Reply-To: References: Message-ID: On 08/21/2018 04:22 PM, B Watson wrote: > On 8/20/18, David O'Shaughnessy wrote: >> Do I need to do anything else after uploading an archive >> to the sbodirectlinks site? > > Yes. Actually change the download link in the .info file to point to > the sbodirectlinks URL. Not much point uploading it there, otherwise... Ah right, I misunderstood how it all works then. I thought there was some kind of script running that archived stuff from sbodirectlinks to sbosrcarch in case of failed downloads from upstream. I'll amend the links then. -- Dave From pfeifer.felix at gmail.com Tue Aug 21 10:43:12 2018 From: pfeifer.felix at gmail.com (Felix Pfeifer) Date: Tue, 21 Aug 2018 12:43:12 +0200 Subject: [Slackbuilds-users] Installation directory of binaries Message-ID: <0f352c2e-d170-9764-f83d-bd442d5090e1@gmail.com> Hi, I am confused. Is it okay to install a binary into /tmp? I found a package like this: ls -l /usr/bin/... lrwxrwxrwx 1 root root 47 Aug 21 12:36 /usr/bin/... -> /tmp/SBo/package-.../usr/share/.../...* I assume this is not correct but as the package found it's way into the repository maybe I did miss something? Cheers, Felix From willysr at slackbuilds.org Tue Aug 21 11:34:36 2018 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Tue, 21 Aug 2018 18:34:36 +0700 Subject: [Slackbuilds-users] Installation directory of binaries In-Reply-To: <0f352c2e-d170-9764-f83d-bd442d5090e1@gmail.com> References: <0f352c2e-d170-9764-f83d-bd442d5090e1@gmail.com> Message-ID: <076dfcb0-d91c-76bf-b630-40ee54b17215@slackbuilds.org> > I am confused. Is it okay to install a binary into > /tmp? I found a package like this: > > ls -l /usr/bin/... > lrwxrwxrwx 1 root root 47 Aug 21 12:36 /usr/bin/... -> > /tmp/SBo/package-.../usr/share/.../...* > > I assume this is not correct but as the package found > it's way into the repository maybe I did miss something? Hi Felix That's not the correct behavior we expected can you let us know which package that have that incorrect behavior? -- Willy Sudiarto Raharjo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From 1.41421 at gmail.com Mon Aug 13 15:08:46 2018 From: 1.41421 at gmail.com (JCA) Date: Mon, 13 Aug 2018 09:08:46 -0600 Subject: [Slackbuilds-users] sage up for grabs UNMAINTAINED In-Reply-To: References: <3e1d444e-dc99-0524-20f3-11b76b8838d0@gmail.com> <9d4f6839-8a40-d700-e4ac-8fd997936428@gmail.com> <107bc49a-f99c-22e0-889b-1644933f99cc@slint.fr> Message-ID: Why not use the Debian binary tarball that is available in the Sage website? I have just tried (for Sage 8.3) and it seems to work fine. Here is what I did: 1. As root, unpacked the tarball in /opt. This create /opt/SageMath. 2. cd /opt/SageMath. 3. ./sage. This patches up Sage's files (black magic?) and launches Sage. You end up at the Sage CLI. It can be checked out that it works, at least for simple operations - like, e.g. an integration. 4. Exit Sage. 5. cd /usr/local/bin. 6. ln -s /opt/SageMath/sage ./sage. 7. Exit root. 8. Assuming that /usr/local/bin is in your path, launch Sage by invoking the sage command. 9. Verify that it works. Assuming that the above keeps working when using more esoteric Sage capabilities, getting a Slackbuilds script to do all that should be straightforward. I haven't tried building for sources, but I find it difficult to believe that the Debian binary tarball is created using some knowledge available to members of the inner circle alone. If I am missing something here please let me know. On Fri, Aug 10, 2018 at 11:26 AM, Didier Spaier wrote: > I forgot: his user a set specific user "maths" for that. > > On 08/10/2018 07:23 PM, Didier Spaier wrote: > > > > On 08/10/2018 04:22 AM, Daniel Prosser wrote: > >> Perhaps if upstream is fighting so hard to make it *not* possible to > package > >> sage, the best course of action is just to honor their intent and stop > trying > >> (take it off SBo). Just my two cents as someone who does not use it > anyway (so > >> maybe it's actually only worth one cent). > > > > I am not an user either, but I once compiled it as regular user just to > check > > its ability to make png files for graphs, for an actual (and blind) user. > > I just asked this friend, he is currently using the 8.1 version. > > > > As for maths there is nothing close to sage's features I'd suggest > > not providing a SlackBuild but a README explaining the situation. > > > > Just my 0.02?. > > _______________________________________________ > > 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 thyr at airmail.cc Tue Aug 21 11:32:32 2018 From: thyr at airmail.cc (thyr at airmail.cc) Date: Tue, 21 Aug 2018 14:32:32 +0300 Subject: [Slackbuilds-users] MD5 hash sums Message-ID: <502111537ab820dc57d5c13b3400ce89@airmail.cc> Hello. I have a question about DOWNLOAD and MD5SUM variables in the .info files. As this page https://www.gnupg.org/faq/weak-digest-algos.html states: > It is better to entirely avoid the MD5 algorithm and don't put any > value in signatures based on MD5. Would that be a valid concern for the .info files? A lot of DOWNLOAD links are plain http ones and thus are suspectible to MITM tinkering on the ISP side... From pfeifer.felix at gmail.com Tue Aug 21 12:04:57 2018 From: pfeifer.felix at gmail.com (Felix Pfeifer) Date: Tue, 21 Aug 2018 14:04:57 +0200 Subject: [Slackbuilds-users] Installation directory of binaries In-Reply-To: <076dfcb0-d91c-76bf-b630-40ee54b17215@slackbuilds.org> References: <0f352c2e-d170-9764-f83d-bd442d5090e1@gmail.com> <076dfcb0-d91c-76bf-b630-40ee54b17215@slackbuilds.org> Message-ID: <94300f94-d1db-0815-53c0-3a8578d1bdb6@gmail.com> >> I am confused. Is it okay to install a binary into >> /tmp? I found a package like this: >> >> ls -l /usr/bin/... >> lrwxrwxrwx 1 root root 47 Aug 21 12:36 /usr/bin/... -> >> /tmp/SBo/package-.../usr/share/.../...* >> >> I assume this is not correct but as the package found >> it's way into the repository maybe I did miss something? > > Hi Felix > > That's not the correct behavior we expected > can you let us know which package that have that incorrect behavior? Hi Willy, it is GitEye. I checked once more. Everything is fine, it's just that link in /usr/bin that is pointing to /tmp/SBo/package-GitEye/usr/share/GitEye/GitEye instead of /usr/share/GitEye/GitEye. I guess it is created by doinst.sh. Thanks, Felix -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From pfeifer.felix at gmail.com Tue Aug 21 13:20:25 2018 From: pfeifer.felix at gmail.com (Felix Pfeifer) Date: Tue, 21 Aug 2018 15:20:25 +0200 Subject: [Slackbuilds-users] missing dependency in vscode Message-ID: Hi, in order to run installation of vscode without errors I had to install an additional software: npm install --save-dev gulp-watch Cheers, Felix From petru at vienvity.net Tue Aug 21 13:32:07 2018 From: petru at vienvity.net (Petru) Date: Tue, 21 Aug 2018 16:32:07 +0300 Subject: [Slackbuilds-users] missing dependency in vscode In-Reply-To: References: Message-ID: Hi, Me too, although I did it without --save-dev. On Tue, Aug 21, 2018, 4:22 PM Felix Pfeifer wrote: > Hi, > > in order to run installation of vscode without > errors I had to install an additional software: > npm install --save-dev gulp-watch > > Cheers, > Felix > _______________________________________________ > 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 lists at osh.id.au Tue Aug 21 14:46:00 2018 From: lists at osh.id.au (David O'Shaughnessy) Date: Wed, 22 Aug 2018 00:46:00 +1000 Subject: [Slackbuilds-users] Retire MD5 for SHA256 In-Reply-To: <1e46e326-3c80-a085-f65a-4fa8b4b5d0ca@googlemail.com> References: <2d8230f0-78c0-c23f-a9db-3953537434e0@osh.id.au> <1e46e326-3c80-a085-f65a-4fa8b4b5d0ca@googlemail.com> Message-ID: On 08/10/2018 11:24 PM, Tim Dickson via SlackBuilds-users wrote: > my 2cents worth... > if it aint broke... > well, the argument is that it is broke, but... using hash collisions? > means either the source can be compromised, in which case it is not > reliable, or the compromise is done on the network, in which case the > network is not reliable. > ?If either network or source are not reliable, then the expected > checksum - whatever method used could simply be set to match the > interfered-with source code, so the attacker would not need to "crack" > the checksum, they could just make what was visible match their version > of the compromised source. If SBo maintainers are generating authentic MD5 checksums in the first place (i.e., GPG verifying the upstream signatures, assuming that they exist), and SBo admins are then signing off on those checksums, then it seems unlikely that an attacker could modify the source and the expected checksums too. However, a subsequent malicious alteration that utilizes hash collisions (which would seem to be an ideal situation for an attacker, short of gaining access to signing keys) is undetectable since the SBo user, in the end, is left with only an MD5 sum as their link to archive integrity. The problem then is that the MD5 cannot guarantee that a given (future) source archive is identical to the one that the maintainer originally downloaded, and that the SBo admin signed off on. Obviously though if the attacker has access to the upstream signing keys then it's busted from the start and the whole checksum thing is irrelevant anyway. > In other words, as a basic download file corruption check, md5 is simple > and convenient; any other assumptions about security depend on other > variables far more than the type of checksum used. True, it's convenient for that and there are many other variables, but having the user rely on MD5 still seems like an unnecessary weak spot to me. -- Dave From lists at osh.id.au Tue Aug 21 14:46:07 2018 From: lists at osh.id.au (David O'Shaughnessy) Date: Wed, 22 Aug 2018 00:46:07 +1000 Subject: [Slackbuilds-users] Retire MD5 for SHA256 In-Reply-To: References: <2d8230f0-78c0-c23f-a9db-3953537434e0@osh.id.au> Message-ID: <55abd738-cd77-586f-4008-f7b0b9aacf7b@osh.id.au> On 08/10/2018 05:24 PM, B Watson wrote: > This comes up from time to time... I personally am not opposed to it, > theoretically it's a good idea, but it'd be a good bit of work for > everyone (admins, maintainers, even users would be impacted). > > What might be feasible: have each maintainer GPG sign the source files > and include detached signatures (.asc) in the SlackBuild directory. > Would require a way for users to get the maintainers' public keys, > but there are public keyservers (and we could do the 'web of trust' > thing by signing each others' pub keys). > > The .info file format wouldn't have to change at all. We'd just start > having one or more small .asc files included with the builds. Automated > tools could check for them and verify the signatures after the download. > If there's no signature, it would just say so, and continue the build. > > Doing it this way puts the burden on the individual SlackBuild maintainers > instead of adding *yet more* work to the admins' workload, and it'd stay > backwards compatible... > > Now that I think of it, this isn't at all my idea, someone on IRC was > talking about it. Are you the same person? If so, congratulations, you > sold me on the idea well enough that now I'm trying to sell it back to > you :) I wasn't the one who suggested this, but it seems like a pretty reasonable solution! -- Dave From fernando.lopezjr at gmail.com Tue Aug 21 17:29:27 2018 From: fernando.lopezjr at gmail.com (Fernando Lopez) Date: Tue, 21 Aug 2018 11:29:27 -0600 Subject: [Slackbuilds-users] how can i define data_dir in makefile? Message-ID: this is the error i get when i run my program... *"ERROR: DATA_DIR not found. Define in make file or run in src dir"* this is how i am doing it: make \ CFLAGS="$SLKCFLAGS" \ DATA_DIR=$PKG/usr/share/icsim -- ------------ Regards, Fernando Lopez Jr. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at dawoodfall.net Tue Aug 21 17:31:29 2018 From: dave at dawoodfall.net (David Woodfall) Date: Tue, 21 Aug 2018 18:31:29 +0100 Subject: [Slackbuilds-users] how can i define data_dir in makefile? In-Reply-To: References: Message-ID: <20180821173129.GC27099@blackswan> On Tuesday 21 August 2018 11:29, Fernando Lopez put forth the proposition: > this is the error i get when i run my program... > *"ERROR: DATA_DIR not found. Define in make file or run in src dir"* > > this is how i am doing it: > > make \ > CFLAGS="$SLKCFLAGS" \ > DATA_DIR=$PKG/usr/share/icsim Try putting in front of make or exporting it: DATA_DIR=bla \ CFLAGS="$SLKCFLAGS" \ make -- > If you don't need X then little VT-100 terminals are available for real > cheap. Should be able to find decent ones used for around $40 each. > For that price, they're a must for the kitchen, den, bathrooms, etc.. :) You're right. Can you explain this to my wife? -- Seen on c.o.l.development.system, on the subject of extra terminals .--. oo (____)// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~' From fernando.lopezjr at gmail.com Tue Aug 21 17:33:45 2018 From: fernando.lopezjr at gmail.com (Fernando Lopez) Date: Tue, 21 Aug 2018 11:33:45 -0600 Subject: [Slackbuilds-users] how can i define data_dir in makefile? In-Reply-To: <20180821173129.GC27099@blackswan> References: <20180821173129.GC27099@blackswan> Message-ID: didnt work. =\ On Tue, Aug 21, 2018 at 11:31 AM David Woodfall wrote: > On Tuesday 21 August 2018 11:29, > Fernando Lopez put forth the proposition: > > this is the error i get when i run my program... > > *"ERROR: DATA_DIR not found. Define in make file or run in src dir"* > > > > this is how i am doing it: > > > > make \ > > CFLAGS="$SLKCFLAGS" \ > > DATA_DIR=$PKG/usr/share/icsim > > Try putting in front of make or exporting it: > > DATA_DIR=bla \ > CFLAGS="$SLKCFLAGS" \ > make > -- > > > If you don't need X then little VT-100 terminals are available for real > > cheap. Should be able to find decent ones used for around $40 each. > > For that price, they're a must for the kitchen, den, bathrooms, etc.. :) > You're right. Can you explain this to my wife? > -- Seen on c.o.l.development.system, on the subject of extra terminals > > .--. oo > (____)// > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~' > _______________________________________________ > 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/ > > -- ------------ Regards, Fernando Lopez Jr. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave at dawoodfall.net Tue Aug 21 17:37:00 2018 From: dave at dawoodfall.net (David Woodfall) Date: Tue, 21 Aug 2018 18:37:00 +0100 Subject: [Slackbuilds-users] how can i define data_dir in makefile? In-Reply-To: References: <20180821173129.GC27099@blackswan> Message-ID: <20180821173659.GD27099@blackswan> On Tuesday 21 August 2018 11:33, Fernando Lopez put forth the proposition: > didnt work. =\ You could try: export DATA_DIR=bla But it does say to put it in the make file, so maybe you'll have to sed it in or make a patch. -Dave Well it does say to put it in the makefile > On Tue, Aug 21, 2018 at 11:31 AM David Woodfall wrote: > > > On Tuesday 21 August 2018 11:29, > > Fernando Lopez put forth the proposition: > > > this is the error i get when i run my program... > > > *"ERROR: DATA_DIR not found. Define in make file or run in src dir"* > > > > > > this is how i am doing it: > > > > > > make \ > > > CFLAGS="$SLKCFLAGS" \ > > > DATA_DIR=$PKG/usr/share/icsim > > > > Try putting in front of make or exporting it: > > > > DATA_DIR=bla \ > > CFLAGS="$SLKCFLAGS" \ > > make > > -- -- How do I type "for i in *.dvi do xdvi $i done" in a GUI? -- Discussion in comp.os.linux.misc on the intuitiveness of interfaces .--. oo (____)// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~' From dave at dawoodfall.net Tue Aug 21 17:44:25 2018 From: dave at dawoodfall.net (David Woodfall) Date: Tue, 21 Aug 2018 18:44:25 +0100 Subject: [Slackbuilds-users] how can i define data_dir in makefile? In-Reply-To: <20180821173659.GD27099@blackswan> References: <20180821173129.GC27099@blackswan> <20180821173659.GD27099@blackswan> Message-ID: <20180821174425.GE27099@blackswan> On Tuesday 21 August 2018 18:37, Dave Woodfall put forth the proposition: > On Tuesday 21 August 2018 11:33, > Fernando Lopez put forth the proposition: > > didnt work. =\ > > You could try: > > export DATA_DIR=bla > > But it does say to put it in the make file, so maybe you'll have to > sed it in or make a patch. By the way, CFLAGS="$SLKCFLAGS" \ ought to be before the make command anyway. -Dave > -Dave > > Well it does say to put it in the makefile > > On Tue, Aug 21, 2018 at 11:31 AM David Woodfall wrote: > > > > > On Tuesday 21 August 2018 11:29, > > > Fernando Lopez put forth the proposition: > > > > this is the error i get when i run my program... > > > > *"ERROR: DATA_DIR not found. Define in make file or run in src dir"* > > > > > > > > this is how i am doing it: > > > > > > > > make \ > > > > CFLAGS="$SLKCFLAGS" \ > > > > DATA_DIR=$PKG/usr/share/icsim > > > > > > Try putting in front of make or exporting it: > > > > > > DATA_DIR=bla \ > > > CFLAGS="$SLKCFLAGS" \ > > > make -- One of the things that hamper Linux's climb to world domination is the shortage of bad Computer Role Playing Games, or CRaPGs. No operating system can be considered respectable without one. -- Brian O'Donnell, odonnllb at tcd.ie .--. oo (____)// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~' From fernando.lopezjr at gmail.com Tue Aug 21 18:06:50 2018 From: fernando.lopezjr at gmail.com (Fernando Lopez) Date: Tue, 21 Aug 2018 12:06:50 -0600 Subject: [Slackbuilds-users] how can i define data_dir in makefile? In-Reply-To: <20180821174425.GE27099@blackswan> References: <20180821173129.GC27099@blackswan> <20180821173659.GD27099@blackswan> <20180821174425.GE27099@blackswan> Message-ID: not working... not working =\ On Tue, Aug 21, 2018 at 11:44 AM David Woodfall wrote: > On Tuesday 21 August 2018 18:37, > Dave Woodfall put forth the proposition: > > On Tuesday 21 August 2018 11:33, > > Fernando Lopez put forth the proposition: > > > didnt work. =\ > > > > You could try: > > > > export DATA_DIR=bla > > > > But it does say to put it in the make file, so maybe you'll have to > > sed it in or make a patch. > > By the way, CFLAGS="$SLKCFLAGS" \ ought to be before the make command > anyway. > > -Dave > > > -Dave > > > > Well it does say to put it in the makefile > > > On Tue, Aug 21, 2018 at 11:31 AM David Woodfall > wrote: > > > > > > > On Tuesday 21 August 2018 11:29, > > > > Fernando Lopez put forth the > proposition: > > > > > this is the error i get when i run my program... > > > > > *"ERROR: DATA_DIR not found. Define in make file or run in src > dir"* > > > > > > > > > > this is how i am doing it: > > > > > > > > > > make \ > > > > > CFLAGS="$SLKCFLAGS" \ > > > > > DATA_DIR=$PKG/usr/share/icsim > > > > > > > > Try putting in front of make or exporting it: > > > > > > > > DATA_DIR=bla \ > > > > CFLAGS="$SLKCFLAGS" \ > > > > make > > -- > > One of the things that hamper Linux's climb to world domination is the > shortage of bad Computer Role Playing Games, or CRaPGs. No operating system > can be considered respectable without one. > -- Brian O'Donnell, odonnllb at tcd.ie > > .--. oo > (____)// > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~' > _______________________________________________ > 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/ > > -- ------------ Regards, Fernando Lopez Jr. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fernando.lopezjr at gmail.com Tue Aug 21 18:18:28 2018 From: fernando.lopezjr at gmail.com (Fernando Lopez) Date: Tue, 21 Aug 2018 12:18:28 -0600 Subject: [Slackbuilds-users] how can i define data_dir in makefile? In-Reply-To: <20180821174425.GE27099@blackswan> References: <20180821173129.GC27099@blackswan> <20180821173659.GD27099@blackswan> <20180821174425.GE27099@blackswan> Message-ID: help https://www.dropbox.com/s/lxx4qg3fb1vnsz1/ICSim.tar.bz2?dl=0 On Tue, Aug 21, 2018 at 11:44 AM David Woodfall wrote: > On Tuesday 21 August 2018 18:37, > Dave Woodfall put forth the proposition: > > On Tuesday 21 August 2018 11:33, > > Fernando Lopez put forth the proposition: > > > didnt work. =\ > > > > You could try: > > > > export DATA_DIR=bla > > > > But it does say to put it in the make file, so maybe you'll have to > > sed it in or make a patch. > > By the way, CFLAGS="$SLKCFLAGS" \ ought to be before the make command > anyway. > > -Dave > > > -Dave > > > > Well it does say to put it in the makefile > > > On Tue, Aug 21, 2018 at 11:31 AM David Woodfall > wrote: > > > > > > > On Tuesday 21 August 2018 11:29, > > > > Fernando Lopez put forth the > proposition: > > > > > this is the error i get when i run my program... > > > > > *"ERROR: DATA_DIR not found. Define in make file or run in src > dir"* > > > > > > > > > > this is how i am doing it: > > > > > > > > > > make \ > > > > > CFLAGS="$SLKCFLAGS" \ > > > > > DATA_DIR=$PKG/usr/share/icsim > > > > > > > > Try putting in front of make or exporting it: > > > > > > > > DATA_DIR=bla \ > > > > CFLAGS="$SLKCFLAGS" \ > > > > make > > -- > > One of the things that hamper Linux's climb to world domination is the > shortage of bad Computer Role Playing Games, or CRaPGs. No operating system > can be considered respectable without one. > -- Brian O'Donnell, odonnllb at tcd.ie > > .--. oo > (____)// > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~' > _______________________________________________ > 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/ > > -- ------------ Regards, Fernando Lopez Jr. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matteo.bernardini at gmail.com Tue Aug 21 18:20:14 2018 From: matteo.bernardini at gmail.com (Matteo Bernardini) Date: Tue, 21 Aug 2018 20:20:14 +0200 Subject: [Slackbuilds-users] how can i define data_dir in makefile? In-Reply-To: References: <20180821173129.GC27099@blackswan> <20180821173659.GD27099@blackswan> <20180821174425.GE27099@blackswan> Message-ID: Fernando, when you are asking for help you should put a link to the sources that you are trying to build, if it's not clear which ones: are they these? https://github.com/zombieCraig/ICSim if they are I just cloned it here and run a simple command $ grep -r DATA_DIR controls.c:#ifndef DATA_DIR controls.c:#define DATA_DIR "./data/" controls.c:#define DEFAULT_CAN_TRAFFIC DATA_DIR "sample-can.log" controls.c: if(strlen(DATA_DIR) + strlen(fname) > 255) return NULL; controls.c: strncpy(data_file, DATA_DIR, 255); icsim.c:#ifndef DATA_DIR icsim.c:#define DATA_DIR "./data/" // Needs trailing slash icsim.c: if(strlen(DATA_DIR) + strlen(fname) > 255) return NULL; icsim.c: strncpy(data_file, DATA_DIR, 255); icsim.c: if(stat(DATA_DIR, &dirstat) == -1) { icsim.c: printf("ERROR: DATA_DIR not found. Define in make file or run in src dir\n"); the Makefile is this CC=gcc CFLAGS=-I/usr/include/SDL2 LDFLAGS=-lSDL2 -lSDL2_image all: icsim controls icsim: icsim.o lib.o $(CC) $(CFLAGS) -o icsim icsim.c lib.o $(LDFLAGS) controls: controls.o $(CC) $(CFLAGS) -o controls controls.c $(LDFLAGS) lib.o: $(CC) lib.c clean: rm -rf icsim controls icsim.o controls.o this is a very basic software still in a very early stage. if you want to build using your CFLAGS and adding a DATA_DIR you should edit the Makefile before building usind sed, adding a line like this DATA_DIR=/usr/share/icsim after the LDFLAGS one in the Makefile and modifying the CFLAGS one adding $SLKCFLAGS (expanded). From gdiaz at qswarm.com Tue Aug 21 18:21:21 2018 From: gdiaz at qswarm.com (Gabriel Diaz) Date: Tue, 21 Aug 2018 18:21:21 +0000 Subject: [Slackbuilds-users] how can i define data_dir in makefile? In-Reply-To: References: <20180821173129.GC27099@blackswan> <20180821173659.GD27099@blackswan> <20180821174425.GE27099@blackswan> Message-ID: hello in the source code of icsim.c there is a #ifndef DATA_DIR #define DATA_DIR "./data/" // Needs trailing slash #endif and then if(stat(DATA_DIR, &dirstat) == -1) { printf("ERROR: DATA_DIR not found. Define in make file or run in src dir\n"); exit(34); } so if there is no DATA_DIR defined, you might try to create a "data" diretory on the same path you?re running icsim. another option is to add -DDATA_DIR=/var/lib/iscsim or something like that to the CFLAGS so the DATA_DIR is defined to your liking. probably a good option is to define -DDATA_DIR in the CFLAGS and instruct the buildscript to define a DATA_DIR variable by default or pick one from the environment. my 2 cents. gabi Sent with ProtonMail Secure Email. ??????? Original Message ??????? On 21 August 2018 8:06 PM, Fernando Lopez wrote: > not working... not working =\ > > On Tue, Aug 21, 2018 at 11:44 AM David Woodfall wrote: > > > On Tuesday 21 August 2018 18:37, > > Dave Woodfall put forth the proposition: > > > On Tuesday 21 August 2018 11:33, > > > Fernando Lopez put forth the proposition: > > > > didnt work. =\ > > > > > > You could try: > > > > > > export DATA_DIR=bla > > > > > > But it does say to put it in the make file, so maybe you'll have to > > > sed it in or make a patch. > > > > By the way, CFLAGS="$SLKCFLAGS" \ ought to be before the make command > > anyway. > > > > -Dave > > > > > -Dave > > > > > > Well it does say to put it in the makefile > > > > On Tue, Aug 21, 2018 at 11:31 AM David Woodfall wrote: > > > > > > > > > On Tuesday 21 August 2018 11:29, > > > > > Fernando Lopez put forth the proposition: > > > > > > this is the error i get when i run my program... > > > > > > *"ERROR: DATA_DIR not found.? Define in make file or run in src dir"* > > > > > > > > > > > > this is how i am doing it: > > > > > > > > > > > > make \ > > > > > >? ?CFLAGS="$SLKCFLAGS" \ > > > > > >? ?DATA_DIR=$PKG/usr/share/icsim > > > > > > > > > > Try putting in front of make or exporting it: > > > > > > > > > > DATA_DIR=bla \ > > > > > CFLAGS="$SLKCFLAGS" \ > > > > > make > > > > -- > > > > One of the things that hamper Linux's climb to world domination is the > > shortage of bad Computer Role Playing Games, or CRaPGs. No operating system > > can be considered respectable without one. > > ? -- Brian O'Donnell, odonnllb at tcd.ie > > > > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? .--.? oo > > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?(____)// > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~' > > _______________________________________________ > > 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/ > > -- > > ------------ > Regards, > ? ? Fernando Lopez Jr. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 855 bytes Desc: OpenPGP digital signature URL: From dave at dawoodfall.net Tue Aug 21 18:36:13 2018 From: dave at dawoodfall.net (David Woodfall) Date: Tue, 21 Aug 2018 19:36:13 +0100 Subject: [Slackbuilds-users] how can i define data_dir in makefile? In-Reply-To: References: <20180821173129.GC27099@blackswan> <20180821173659.GD27099@blackswan> <20180821174425.GE27099@blackswan> Message-ID: <20180821183613.GF27099@blackswan> On Tuesday 21 August 2018 12:18, Fernando Lopez put forth the proposition: > help > > https://www.dropbox.com/s/lxx4qg3fb1vnsz1/ICSim.tar.bz2?dl=0 Did you actually create the directory? It looks like you need to do that as well as set the variable. -Dave > On Tue, Aug 21, 2018 at 11:44 AM David Woodfall wrote: > > > On Tuesday 21 August 2018 18:37, > > Dave Woodfall put forth the proposition: > > > On Tuesday 21 August 2018 11:33, > > > Fernando Lopez put forth the proposition: > > > > didnt work. =\ > > > > > > You could try: > > > > > > export DATA_DIR=bla > > > > > > But it does say to put it in the make file, so maybe you'll have to > > > sed it in or make a patch. > > > > By the way, CFLAGS="$SLKCFLAGS" \ ought to be before the make command > > anyway. > > > > -Dave > > > > > -Dave > > > > > > Well it does say to put it in the makefile > > > > On Tue, Aug 21, 2018 at 11:31 AM David Woodfall > > wrote: > > > > > > > > > On Tuesday 21 August 2018 11:29, > > > > > Fernando Lopez put forth the > > proposition: > > > > > > this is the error i get when i run my program... > > > > > > *"ERROR: DATA_DIR not found. Define in make file or run in src > > dir"* > > > > > > > > > > > > this is how i am doing it: > > > > > > > > > > > > make \ > > > > > > CFLAGS="$SLKCFLAGS" \ > > > > > > DATA_DIR=$PKG/usr/share/icsim > > > > > > > > > > Try putting in front of make or exporting it: > > > > > > > > > > DATA_DIR=bla \ > > > > > CFLAGS="$SLKCFLAGS" \ > > > > > make -- Once upon a time there was a DOS user who saw Unix, and saw that it was good. After typing cp on his DOS machine at home, he downloaded GNU's unix tools ported to DOS and installed them. He rm'd, cp'd, and mv'd happily for many days, and upon finding elvis, he vi'd and was happy. After a long day at work (on a Unix box) he came home, started editing a file, and couldn't figure out why he couldn't suspend vi (w/ ctrl-z) to do a compile. -- Erik Troan, ewt at tipper.oit.unc.edu .--. oo (____)// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~' From fernando.lopezjr at gmail.com Tue Aug 21 18:36:42 2018 From: fernando.lopezjr at gmail.com (Fernando Lopez) Date: Tue, 21 Aug 2018 12:36:42 -0600 Subject: [Slackbuilds-users] how can i define data_dir in makefile? In-Reply-To: <20180821183613.GF27099@blackswan> References: <20180821173129.GC27099@blackswan> <20180821173659.GD27099@blackswan> <20180821174425.GE27099@blackswan> <20180821183613.GF27099@blackswan> Message-ID: yes i am creating it on the package itself... On Tue, Aug 21, 2018 at 12:36 PM David Woodfall wrote: > On Tuesday 21 August 2018 12:18, > Fernando Lopez put forth the proposition: > > help > > > > https://www.dropbox.com/s/lxx4qg3fb1vnsz1/ICSim.tar.bz2?dl=0 > > Did you actually create the directory? It looks like you need to do > that as well as set the variable. > > -Dave > > > On Tue, Aug 21, 2018 at 11:44 AM David Woodfall > wrote: > > > > > On Tuesday 21 August 2018 18:37, > > > Dave Woodfall put forth the proposition: > > > > On Tuesday 21 August 2018 11:33, > > > > Fernando Lopez put forth the > proposition: > > > > > didnt work. =\ > > > > > > > > You could try: > > > > > > > > export DATA_DIR=bla > > > > > > > > But it does say to put it in the make file, so maybe you'll have to > > > > sed it in or make a patch. > > > > > > By the way, CFLAGS="$SLKCFLAGS" \ ought to be before the make command > > > anyway. > > > > > > -Dave > > > > > > > -Dave > > > > > > > > Well it does say to put it in the makefile > > > > > On Tue, Aug 21, 2018 at 11:31 AM David Woodfall < > dave at dawoodfall.net> > > > wrote: > > > > > > > > > > > On Tuesday 21 August 2018 11:29, > > > > > > Fernando Lopez put forth the > > > proposition: > > > > > > > this is the error i get when i run my program... > > > > > > > *"ERROR: DATA_DIR not found. Define in make file or run in src > > > dir"* > > > > > > > > > > > > > > this is how i am doing it: > > > > > > > > > > > > > > make \ > > > > > > > CFLAGS="$SLKCFLAGS" \ > > > > > > > DATA_DIR=$PKG/usr/share/icsim > > > > > > > > > > > > Try putting in front of make or exporting it: > > > > > > > > > > > > DATA_DIR=bla \ > > > > > > CFLAGS="$SLKCFLAGS" \ > > > > > > make > > -- > > Once upon a time there was a DOS user who saw Unix, and saw that it was > good. After typing cp on his DOS machine at home, he downloaded GNU's > unix tools ported to DOS and installed them. He rm'd, cp'd, and mv'd > happily for many days, and upon finding elvis, he vi'd and was happy. > After > a long day at work (on a Unix box) he came home, started editing a file, > and couldn't figure out why he couldn't suspend vi (w/ ctrl-z) to do > a compile. > -- Erik Troan, ewt at tipper.oit.unc.edu > > .--. oo > (____)// > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~' > _______________________________________________ > 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/ > > -- ------------ Regards, Fernando Lopez Jr. -------------- next part -------------- An HTML attachment was scrubbed... URL: From idlemoor at slackbuilds.org Tue Aug 21 19:02:33 2018 From: idlemoor at slackbuilds.org (David Spencer) Date: Tue, 21 Aug 2018 20:02:33 +0100 Subject: [Slackbuilds-users] how can i define data_dir in makefile? In-Reply-To: References: <20180821173129.GC27099@blackswan> <20180821173659.GD27099@blackswan> <20180821174425.GE27099@blackswan> Message-ID: <15b9d3fa-af65-8a4b-01eb-b545cda77b9c@slackbuilds.org> Hi, gabi gets my vote :D -D. On 21/08/18 19:21, Gabriel Diaz wrote: > hello > > in the source code of icsim.c there is a > > #ifndef DATA_DIR > #define DATA_DIR "./data/" // Needs trailing slash > #endif > > > and then > > > if(stat(DATA_DIR, &dirstat) == -1) { > printf("ERROR: DATA_DIR not found. Define in make file or run in src dir\n"); > exit(34); > } > > so if there is no DATA_DIR defined, you might try to create a "data" diretory on the same path you?re running icsim. > > > another option is to add -DDATA_DIR=/var/lib/iscsim or something like that to the CFLAGS so the DATA_DIR is defined to your liking. > > probably a good option is to define -DDATA_DIR in the CFLAGS and instruct the buildscript to define a DATA_DIR variable by default or pick one from the environment. > > my 2 cents. > > gabi From duncan_roe at optusnet.com.au Tue Aug 21 23:49:47 2018 From: duncan_roe at optusnet.com.au (Duncan Roe) Date: Wed, 22 Aug 2018 09:49:47 +1000 Subject: [Slackbuilds-users] sage up for grabs UNMAINTAINED In-Reply-To: References: <3e1d444e-dc99-0524-20f3-11b76b8838d0@gmail.com> <9d4f6839-8a40-d700-e4ac-8fd997936428@gmail.com> <107bc49a-f99c-22e0-889b-1644933f99cc@slint.fr> Message-ID: <20180821234947.GA2263@dimstar.local.net> On Mon, Aug 13, 2018 at 09:08:46AM -0600, JCA wrote: > Why not use the Debian binary tarball that is available in the Sage > website? I have just tried (for Sage 8.3) and it seems to work fine. Here > is what I did: > > 1. As root, unpacked the tarball in /opt. This create /opt/SageMath. > 2. cd /opt/SageMath. > 3. ./sage. This patches up Sage's files (black magic?) and launches Sage. > You end up at the Sage CLI. It can be checked out that it works, at least > for simple operations - like, e.g. an integration. > 4. Exit Sage. > 5. cd /usr/local/bin. > 6. ln -s /opt/SageMath/sage ./sage. > 7. Exit root. > 8. Assuming that /usr/local/bin is in your path, launch Sage by invoking > the sage command. > 9. Verify that it works. > > Assuming that the above keeps working when using more esoteric Sage > capabilities, getting a Slackbuilds script to do all that should be > straightforward. I haven't tried building for sources, but I find it > difficult to believe that the Debian binary tarball is created using some > knowledge available to members of the inner circle alone. > > If I am missing something here please let me know. > Hi JCA, Sounds like it should be easy enough to automate into a build script using mkchroot. I can give it a go (but I'm not a sage user). Could you please clarify a couple if items: 1. Does ./sage really work after cd-ing to a freshly created directory? 2. I assume checking with an integration is not essential to the build process - is that correct? Cheers ... Duncan. > > On Fri, Aug 10, 2018 at 11:26 AM, Didier Spaier wrote: > > > I forgot: his user a set specific user "maths" for that. > > > > On 08/10/2018 07:23 PM, Didier Spaier wrote: > > > > > > On 08/10/2018 04:22 AM, Daniel Prosser wrote: > > >> Perhaps if upstream is fighting so hard to make it *not* possible to > > package > > >> sage, the best course of action is just to honor their intent and stop > > trying > > >> (take it off SBo). Just my two cents as someone who does not use it > > anyway (so > > >> maybe it's actually only worth one cent). > > > > > > I am not an user either, but I once compiled it as regular user just to > > check > > > its ability to make png files for graphs, for an actual (and blind) user. > > > I just asked this friend, he is currently using the 8.1 version. > > > > > > As for maths there is nothing close to sage's features I'd suggest > > > not providing a SlackBuild but a README explaining the situation. > > > > > > Just my 0.02???. From lists at osh.id.au Wed Aug 22 02:45:51 2018 From: lists at osh.id.au (David O'Shaughnessy) Date: Wed, 22 Aug 2018 12:45:51 +1000 Subject: [Slackbuilds-users] Retire MD5 for SHA256 In-Reply-To: References: <2d8230f0-78c0-c23f-a9db-3953537434e0@osh.id.au> <1e46e326-3c80-a085-f65a-4fa8b4b5d0ca@googlemail.com> Message-ID: On 08/22/2018 12:46 AM, David O'Shaughnessy wrote: > The problem then is that the MD5 cannot guarantee that a given (future) > source archive is identical to the one that the maintainer originally > downloaded, and that the SBo admin signed off on. Obviously though if > the attacker has access to the upstream signing keys then it's busted > from the start and the whole checksum thing is irrelevant anyway. I've been doing some more reading on this and the scenario of an attacker changing a file without the MD5 also changing is actually a 2nd preimage attack (not a collision), and everything I've looked at says that this is computationally infeasible using current methods. Therefore it seems that an authentic (signed) MD5 is not broken as a file verification method. Still, I think that switching to a stronger hash function would be good long-term insurance. -- Dave From lists at osh.id.au Wed Aug 22 04:09:17 2018 From: lists at osh.id.au (David O'Shaughnessy) Date: Wed, 22 Aug 2018 14:09:17 +1000 Subject: [Slackbuilds-users] MD5 hash sums In-Reply-To: <502111537ab820dc57d5c13b3400ce89@airmail.cc> References: <502111537ab820dc57d5c13b3400ce89@airmail.cc> Message-ID: <96acc17b-78d7-90f9-a244-2bd53556c812@osh.id.au> On 08/21/2018 09:32 PM, thyr at airmail.cc wrote: > Hello. > > I have a question about DOWNLOAD and MD5SUM variables in the > .info files. > > As this page https://www.gnupg.org/faq/weak-digest-algos.html states: > >> It is better to entirely avoid the MD5 algorithm and don't put any >> value in signatures based on MD5. > > Would that be a valid concern for the .info files? > > A lot of DOWNLOAD links are plain http ones and thus are suspectible to > MITM tinkering on the ISP side... Each SlackBuild archive is signed by the SBo devs, so any modifications on the server (or in-between) would fail subsequent verification. In that case it's the GPG signature that you trust to verify the .info file contents (and all the rest of the SlackBuild stuff), not the MD5 sum or whatever else is inside it. -- Dave From thyr at airmail.cc Wed Aug 22 14:55:54 2018 From: thyr at airmail.cc (thyr at airmail.cc) Date: Wed, 22 Aug 2018 17:55:54 +0300 Subject: [Slackbuilds-users] MD5 hash sums In-Reply-To: <96acc17b-78d7-90f9-a244-2bd53556c812@osh.id.au> Message-ID: <0b55b7022d14c57953ae737f19f4e656@airmail.cc> > Each SlackBuild archive is signed by the SBo devs, so any modifications > on the server (or in-between) would fail subsequent verification. In > that case it's the GPG signature that you trust to verify the .info > file contents (and all the rest of the SlackBuild stuff), not the MD5 > sum or whatever else is inside it. Sorry, the question I had in mind was about MD5 sums inside it. Seems kind of strange that SlackBuild archive is protected by GPG signature, but the actual source tarball is not signed and is protected by (obsolete) MD5 checksum. Aren't this situation an opportunity to MITM the source tarball itself, since some DOWNLOAD links are provided trough plain HTTP? GnuPG FAQ quote (https://gnupg.org/faq/gnupg-faq.html#define_sha): > SHA-224, 256, 384, or 512: This is a massively-overhauled SHA-1 which > generates larger hashes (224, 256, 384, or 512 bits). Right now, these > are the strongest hashes in GnuPG. vs > MD5 is a 128-bit cryptographic hash function invented by Ron Rivest > (the ?R? of ?RSA?) in the early 1990s. For many years it was one of the > standard algorithms of the field, but is now completely obsolete. For > that reason, MD5 is not supported by GnuPG. Wouldn't it be better to use, say, SHA512 instead? From kristofru at gmail.com Wed Aug 22 20:13:26 2018 From: kristofru at gmail.com (Chris Abela) Date: Wed, 22 Aug 2018 22:13:26 +0200 Subject: [Slackbuilds-users] Metacharacters in package names Message-ID: <33d2862e-5bd4-3657-9526-930acab76283@gmail.com> Hi, I have written a short script that lists built packages on which no other package depends: https://github.com/ChrisAbela/apex/blob/master/apex.sh It assumes that the user is using sbopkg and relies on rigorously maintained queue files. The script wrongly lists tolua++ as an "apex package" as egrep (at line 52) interprets the "+" metacharacter. May I suggest to avoid metacharacters in package names. In this case toluapp would have been a better choice, as per homepage: https://github.com/LuaDist/toluapp. Thanks to all that maintain scripts. You make Slackware a better experience. Chris Abela From sb at rbn.im Wed Aug 22 20:42:03 2018 From: sb at rbn.im (Ruben Schuller) Date: Wed, 22 Aug 2018 22:42:03 +0200 Subject: [Slackbuilds-users] Metacharacters in package names In-Reply-To: <33d2862e-5bd4-3657-9526-930acab76283@gmail.com> References: <33d2862e-5bd4-3657-9526-930acab76283@gmail.com> Message-ID: <20180822224203.147b6d4c@kiwi.kuchen> Hi, On Wed, 22 Aug 2018 22:13:26 +0200 Chris Abela wrote: > The script wrongly lists tolua++ as an "apex package" as egrep (at > line 52) interprets the "+" metacharacter. May I suggest to avoid > metacharacters in package names. In this case toluapp would have been > a better choice, as per homepage: https://github.com/LuaDist/toluapp. I'd say that, even if special characters are avoided in package names, you should sanitize/filter the inputs accordingly to where they are used. IMHO package renaming should only be done in really pressing cases, as there are other things which don't work without friction then (upgrading the package for example). Furthermore, each artificial restriction will be a requirement soon, as other things will depend on it. This could be a good solution for the problem in your script: https://stackoverflow.com/a/16951928 Kind Regards Ruben From yalhcru at gmail.com Wed Aug 22 21:38:07 2018 From: yalhcru at gmail.com (B Watson) Date: Wed, 22 Aug 2018 17:38:07 -0400 Subject: [Slackbuilds-users] Metacharacters in package names In-Reply-To: <20180822224203.147b6d4c@kiwi.kuchen> References: <33d2862e-5bd4-3657-9526-930acab76283@gmail.com> <20180822224203.147b6d4c@kiwi.kuchen> Message-ID: On 8/22/18, Ruben Schuller wrote: > > This could be a good solution for the problem in your script: > https://stackoverflow.com/a/16951928 My eyes! The goggles, they do nothing! Using grep instead of egrep would also be a solution to this issue. grep can do everything (or maybe almost everything?) egrep does, just needs extra \ in front of some of the metacharacters to make them meta. From dickson.tim at googlemail.com Wed Aug 22 21:53:34 2018 From: dickson.tim at googlemail.com (Tim Dickson) Date: Wed, 22 Aug 2018 22:53:34 +0100 Subject: [Slackbuilds-users] MD5 hash sums In-Reply-To: <0b55b7022d14c57953ae737f19f4e656@airmail.cc> References: <0b55b7022d14c57953ae737f19f4e656@airmail.cc> Message-ID: On 22/08/2018 15:55, thyr at airmail.cc wrote: >> Each SlackBuild archive is signed by the SBo devs, so any >> modifications on the server (or in-between) would fail subsequent >> verification. In that case it's the GPG signature that you trust to >> verify the .info file contents (and all the rest of the SlackBuild >> stuff), not the MD5 sum or whatever else is inside it. > > Sorry, the question I had in mind was about MD5 sums inside it. Seems > kind of strange that SlackBuild archive is protected by GPG signature, > but the actual source tarball is not signed and is protected by > (obsolete) MD5 checksum. Aren't this situation an opportunity to MITM > the source tarball itself, since some DOWNLOAD links are provided > trough plain HTTP? unless you are running over public wifi or internet cafe, a MITM attack on a source gz is less likely than someone breaking in to your hoise/business and planting malware on your pc/laptop. It would mean your ISP was compromised, in? which case you have bigger issues to worry about than sourcde code frome some sites being changed on the fly. When you bear in mind that source code is usually compressed, it is not so easy to change bits while keeping the md5 sum the same and also not causing the archive to be un-openable because of the changes.- the changes would break the checksums inside the gz file format. > > GnuPG FAQ quote (https://gnupg.org/faq/gnupg-faq.html#define_sha): > >> SHA-224, 256, 384, or 512: This is a massively-overhauled SHA-1 which >> generates larger hashes (224, 256, 384, or 512 bits). Right now, >> these are the strongest hashes in GnuPG. > > vs > >> MD5 is a 128-bit cryptographic hash function invented by Ron Rivest >> (the ?R? of ?RSA?) in the early 1990s. For many years it was one of >> the standard algorithms of the field, but is now completely obsolete. >> For that reason, MD5 is not supported by GnuPG. > > Wouldn't it be better to use, say, SHA512 instead? > _______________________________________________ > 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 erik at slackbuilds.org Thu Aug 23 00:41:25 2018 From: erik at slackbuilds.org (Erik Hanson) Date: Wed, 22 Aug 2018 19:41:25 -0500 Subject: [Slackbuilds-users] MD5 hash sums In-Reply-To: <0b55b7022d14c57953ae737f19f4e656@airmail.cc> References: <0b55b7022d14c57953ae737f19f4e656@airmail.cc> Message-ID: <1de56b9c-2d20-2600-81e9-2bb2b3519130@slackbuilds.org> On 8/22/18 9:55 AM, thyr at airmail.cc wrote: >> Each SlackBuild archive is signed by the SBo devs, so any >> modifications on the server (or in-between) would fail subsequent >> verification. In that case it's the GPG signature that you trust to >> verify the .info file contents (and all the rest of the SlackBuild >> stuff), not the MD5 sum or whatever else is inside it. > > Sorry, the question I had in mind was about MD5 sums inside it. Seems > kind of strange that SlackBuild archive is protected by GPG signature, > but the actual source tarball is not signed and is protected by > (obsolete) MD5 checksum. Aren't this situation an opportunity to MITM > the source tarball itself, since some DOWNLOAD links are provided trough > plain HTTP? Sources are not protected by us. We do not provide the MD5 sum as any sort of security measure, it shouldn't be treated as one. We have no agency over upstream sources, and we purposefully do not host them, so we cannot provide any signature or sum that could be considered a token of security. -- Erik -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From lists at osh.id.au Thu Aug 23 03:15:14 2018 From: lists at osh.id.au (David O'Shaughnessy) Date: Thu, 23 Aug 2018 13:15:14 +1000 Subject: [Slackbuilds-users] MD5 hash sums In-Reply-To: <0b55b7022d14c57953ae737f19f4e656@airmail.cc> References: <0b55b7022d14c57953ae737f19f4e656@airmail.cc> Message-ID: <980bee46-9041-11c7-63f9-8b4ae834f48d@osh.id.au> On 08/23/2018 12:55 AM, thyr at airmail.cc wrote: > Sorry, the question I had in mind was about MD5 sums inside it. Seems > kind of strange that SlackBuild archive is protected by GPG signature, > but the actual source tarball is not signed and is protected by > (obsolete) MD5 checksum. Aren't this situation an opportunity to MITM > the source tarball itself, since some DOWNLOAD links are provided trough > plain HTTP? Let's say the user has a SlackBuild + .info file, both of which have been signed by the SBo dev team and are authentic (thus including the MD5). The assumption here is that the maintainer actually checks signatures upon downloading (and that upstream devs even sign in the first place), so the stuff in the .info is "safe". Now the user goes to download the source listed in .info, and unbeknown to them it has been maliciously tampered with (either on the server or MITM, so either TLS or not, it doesn't matter). The MD5 of that altered archive will not match the authentic MD5 found in the .info file. For an attacker to change the upstream source archive without changing the MD5 requires a 2nd preimage attack, which as far as I understand is not computationally feasible at present. This is different to a much simpler collision attack, where the attacker generates two _new_ archives with new (and matching) MD5s. So, as long as SlackBuild maintainers are actually verifying the signatures on source archives and not blindly trusting checksums (of any variety) published on upstream websites, then using MD5 in this way seems OK. That said, I do think that it would be safer practice to just use a stronger hash function anyway (https://blake2.net/ ?), as things can change suddenly (who knows what's around the corner). -- Dave From t3slider at gmail.com Thu Aug 23 05:45:44 2018 From: t3slider at gmail.com (T3 slider) Date: Thu, 23 Aug 2018 01:45:44 -0400 Subject: [Slackbuilds-users] MD5 hash sums In-Reply-To: <980bee46-9041-11c7-63f9-8b4ae834f48d@osh.id.au> References: <0b55b7022d14c57953ae737f19f4e656@airmail.cc> <980bee46-9041-11c7-63f9-8b4ae834f48d@osh.id.au> Message-ID: On Wed, Aug 22, 2018, 11:15 PM David O'Shaughnessy wrote: > For an > attacker to change the upstream source archive without changing the MD5 > requires a 2nd preimage attack, which as far as I understand is not > computationally feasible at present. This is different to a much simpler > collision attack, where the attacker generates two _new_ archives with > new (and matching) MD5s. > The download files do not necessarily have to be tar archives, and in some cases (generally those with multiple download files and therefore multiple checksums), individual files can be included for download. Intentional PDF collisions have been around for ages (see https://www.mscs.dal.ca/~selinger/md5collision/ ), so if a SlackBuild includes some documentation as a download link, and the upstream server has since been compromised, a user could definitely be stuck with a malicious file even if the SlackBuild maintainer did everything right and verified upstream signatures. It is probably more difficult to generate tarballs with collisions but I'm guessing it isn't quite as difficult as we're pretending it is, and it's irrelevant since unzipped files can be passed as download links. Simply put, this is bad security. Anyone who disagrees doesn't understand the problem. Can't we just add an optional sha256sum in the .info file and maintainers can gradually add these checksums to their SlackBuilds, targeting some point in the future that these fields will be required (and possibly the md5s retired)? -T3slider > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kristofru at gmail.com Thu Aug 23 06:33:36 2018 From: kristofru at gmail.com (Chris Abela) Date: Thu, 23 Aug 2018 08:33:36 +0200 Subject: [Slackbuilds-users] Metacharacters in package names In-Reply-To: References: <33d2862e-5bd4-3657-9526-930acab76283@gmail.com> <20180822224203.147b6d4c@kiwi.kuchen> Message-ID: <0f4d8df6-4944-e4ce-7d42-b3d7aa9a5e1c@gmail.com> > On 8/22/18, Ruben Schuller wrote: >> This could be a good solution for the problem in your script: >> https://stackoverflow.com/a/16951928 > My eyes! The goggles, they do nothing! > > Using grep instead of egrep would also be a solution to this issue. I confess that I had to look up that meme. I understand that you wanted to express your dislike on the previous solutions kindly offered by the previous interlocutor. I don't like it as well. My preferred solution would be to distract the author of this application and plug out the '+' key from his/her keyboard. Or else I can rely on the undocumented and exclusive pkgtool feature to rename installed packages on the fly using the mv command: mv /var/log/packages/tolua++ /var/log/packages/toluapp (and prove once again that Slackware is unbreakable). There are many solutions but my intention was not to request assistance on my script. The script is just a cosmetic addition to sbopkg anyway. My intention was to solicit your reconsideration on the inclusion of metacharacters in package names. They are a nuisance, ugly and they break things. Which characters are acceptable? Would you also accept white spaces and semi-colons? Chris Abela -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at osh.id.au Thu Aug 23 07:07:22 2018 From: lists at osh.id.au (David O'Shaughnessy) Date: Thu, 23 Aug 2018 17:07:22 +1000 Subject: [Slackbuilds-users] MD5 hash sums In-Reply-To: References: <0b55b7022d14c57953ae737f19f4e656@airmail.cc> <980bee46-9041-11c7-63f9-8b4ae834f48d@osh.id.au> Message-ID: On 08/23/2018 03:45 PM, T3 slider wrote: > The download files do not necessarily have to be tar archives, and in > some cases (generally those with multiple download files and therefore > multiple checksums), individual files can be included for download. > Intentional PDF collisions have been around for ages > (see?https://www.mscs.dal.ca/~selinger/md5collision/ > ?), so if a > SlackBuild includes some documentation as a download link, and the > upstream server has since been compromised, a user could definitely be > stuck with a malicious file even if the SlackBuild maintainer did > everything right and verified upstream signatures. It is probably more > difficult to generate tarballs with collisions but I'm guessing it isn't > quite as difficult as we're pretending it is, and it's irrelevant since > unzipped files can be passed as download links. I don't see how this works if each individual download (either archive or single uncompressed file) has its own MD5. My understanding of collisions is that one can easily create two differing files with matching MD5 sums (so the original innocuous file A plus a malicious new file B), but that this necessarily creates a new (shared) MD5 sum. If the target MD5 is given beforehand (i.e., the one(s) in the info file), then a preimage attack is required which is impractical. > > Simply put, this is bad security. Anyone who disagrees doesn't > understand the problem. Can't we just add an optional sha256sum in the > .info file and maintainers can gradually add these checksums to their > SlackBuilds, targeting some point in the future that these fields will > be required (and possibly the md5s retired)? An optional sha256sum field seems reasonable to me. -- Dave From didier at slint.fr Thu Aug 23 09:06:37 2018 From: didier at slint.fr (Didier Spaier) Date: Thu, 23 Aug 2018 11:06:37 +0200 Subject: [Slackbuilds-users] Metacharacters in package names In-Reply-To: <0f4d8df6-4944-e4ce-7d42-b3d7aa9a5e1c@gmail.com> References: <33d2862e-5bd4-3657-9526-930acab76283@gmail.com> <20180822224203.147b6d4c@kiwi.kuchen> <0f4d8df6-4944-e4ce-7d42-b3d7aa9a5e1c@gmail.com> Message-ID: On 08/23/2018 08:33 AM, Chris Abela wrote: > My intention was to solicit your reconsideration on the inclusion of metacharacters in package names. They are a nuisance, ugly and they break things. Which characters are acceptable? Would you also accept white spaces and semi-colons? Let's distinguish between '+', spaces and semi-colons '+' is special only in extended regular expression according to POSIX and can then be escaped, cf. ?9.4.3 ERE Special Characters http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html#tag_09_04 The POSIX specification requires that sed supports the basic regular expressions but supporting the EREs is not required, cf. Regular Expressions in sed: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sed.html#tag_20_116_13_02. A BRE can always be used instead of an ERE as far as I know. Anyway, the '+" character is used in names of packages shipped in Slackware: didier[/var/log/packages]$ ls /var/log/packages|grep '+' biff+comsat-0.17-x86_64-1 dvd+rw-tools-7.1-x86_64-2 gcc-g++-5.5.0-x86_64-1_slack14.2 gtk+-1.2.10-x86_64-5 gtk+2-2.24.31-x86_64-1_slack14.2 gtk+3-3.18.9-x86_64-1 libcdio-paranoia-10.2+0.93+1-x86_64-1 libsigc++-2.6.2-x86_64-1 didier[/var/log/packages]$ spaces an semi-colons instead shall be quoted if they are to represent themselves, cf. the POSIX specification, Shell Command Language ?2.2 Quoting: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_02 So in this case not using them in package names is wise. All this being said I am not a SBo admin, and this is just my opinion. Didier From yalhcru at gmail.com Thu Aug 23 10:34:49 2018 From: yalhcru at gmail.com (B Watson) Date: Thu, 23 Aug 2018 06:34:49 -0400 Subject: [Slackbuilds-users] Metacharacters in package names In-Reply-To: References: <33d2862e-5bd4-3657-9526-930acab76283@gmail.com> <20180822224203.147b6d4c@kiwi.kuchen> <0f4d8df6-4944-e4ce-7d42-b3d7aa9a5e1c@gmail.com> Message-ID: On 8/23/18, Didier Spaier wrote: > > Anyway, the '+" character is used in names of packages shipped in Slackware: > biff+comsat-0.17-x86_64-1 > dvd+rw-tools-7.1-x86_64-2 > gcc-g++-5.5.0-x86_64-1_slack14.2 > gtk+-1.2.10-x86_64-5 > gtk+2-2.24.31-x86_64-1_slack14.2 > gtk+3-3.18.9-x86_64-1 > libcdio-paranoia-10.2+0.93+1-x86_64-1 > libsigc++-2.6.2-x86_64-1 Bingo. Pat never wrote any formal package-naming spec for Slackware, so all we have to go by is looking at the names he uses and deducing a set of rules from them. It means + is allowed... and I wish it weren't, 'cause package names with + in them have caused problems for my pet project too (sbosrcarch). It also means it's OK to randomly use names like MPlayer (capital letters), which drives me insane (because they're effectively random. If the caps had a meaning, like ClassName and methodName in OO languages, I'd be less insane...) How about UTF-8 accented/umlauted characters in package names? Slackware doesn't ship any packages like that... so we can say "no, not allowed". If Pat did start shipping a package with an umlaut in the name[*], would that open the door for all of Unicode? You think + is annoying to deal with, wait'll you have to handle emoticons, Linear-B, Klingon, Sanskrit, cuneiform, braille (visually represented) and something like 30,000 Chinese characters... [*] That's at least theoretically possible: "love" on SBo is actually called "L?VE" by its developers (that's an umlauted O, in case gmail mangles it). Er, and what point am I making? Not sure. How about this: $ ls | grep -v SBo | rev | cut -d- -f4- | rev | sed 's,.,&\n,g' | sort -u | grep -v '[A-Za-z0-9]' | xargs echo + - _ (That's on a full install with nothing but Slackware and SBo packages...) So, plus, hyphen, and underscore are the only non-alphanumeric characters Pat uses. And they're 7-bit ASCII only. Those should be our rules, too. I'd even go so far as to say we should stick to that even if Pat changes his rules (because Pat doesn't have to care about his package names breaking sbopkg, sbotools, etc, and we do, or at least should). From rellis at dp100.com Thu Aug 23 10:58:50 2018 From: rellis at dp100.com (Richard Ellis) Date: Thu, 23 Aug 2018 06:58:50 -0400 Subject: [Slackbuilds-users] MD5 hash sums In-Reply-To: References: <0b55b7022d14c57953ae737f19f4e656@airmail.cc> <980bee46-9041-11c7-63f9-8b4ae834f48d@osh.id.au> Message-ID: <20180823105850.GA28830@d820.dp100.com> On Thu, Aug 23, 2018 at 01:45:44AM -0400, T3 slider wrote: > On Wed, Aug 22, 2018, 11:15 PM David O'Shaughnessy wrote: > > > For an attacker to change the upstream source archive without > > changing the MD5 requires a 2nd preimage attack, which as far as > > I understand is not computationally feasible at present. This is > > different to a much simpler collision attack, where the attacker > > generates two _new_ archives with new (and matching) MD5s. > > > > The download files do not necessarily have to be tar archives, and > in some cases (generally those with multiple download files and > therefore multiple checksums), individual files can be included for > download. Intentional PDF collisions have been around for ages > (see https://www.mscs.dal.ca/~selinger/md5collision/ ), so if a > SlackBuild includes some documentation as a download link, and the > upstream server has since been compromised, a user could definitely > be stuck with a malicious file even if the SlackBuild maintainer > did everything right and verified upstream signatures. The reason the slackbuild MD5's do not fall victim to the "pdf collision" attack is a subtle distinction between what crytographers define as a "collision" attack vs. a second pre-image attack. The pdf attack you describe above is a "collision" attack. A collision attack is defined by cryptographers as "find any two files, A and B, which produce the same hash" [1]. That was how the PDF attack worked, it was just constrained to "the A and B files need to be valid PDF files". But, a collision attack does not allow an attacker (MITM, etc.) to simply substitute the upstream file with a new file that matches the same hash as the origional file. In order for an attacker to substitute a different upstream file for the origional file, the attacker has to find a new file that matches the MD5 hash of the existing file. This attack is what cryptographers define as a "second pre-image" attack. And it means "given a file G, find another file C which has an identical hash" [2]. This is the attack that a MITM ISP or a cracker breaking in to an upstream repository has to perform to substitute a different file that matches the MD5 in the SBO. The reason is that the SBO files contain an MD5 sum of a known file G (the origional). And the SBO file is then protected by a GPG signature. If a user verifies that the downloaded SBO and GPG signature are valid, then the user knows that the SBO has not been altered. Therefore the user knows the MD5 sum within the SBO has also not been altered (by a MITM or other attack). Therefore, in order for the downloaded file (tar ball, zip, pdf, whatever) to be altered, but still match the MD5 sum in the SBO, a second pre-image attack is requred. This is because the valid MD5 sum in the SBO is now the sum of a single given file G, and the MITM has to find a new file C which hashes to the same MD5 of the given file G. MD5 has not (yet) been shown to be vulnerable to this attack (second pre-image) in any feasable timeframe [3][4]. Yes, a day is going to arrive sometime in the future where it will likely fall to a second pre-image attack, so upgrading to a stronger hash function is also a good idea. But the MD5's are not (yet) a security risk. > It is probably more difficult to generate tarballs > with collisions but I'm guessing it isn't quite as difficult as we're > pretending it is, and it's irrelevant since unzipped files can be passed as > download links. Cryptographers don't care about what the stream of bytes represent. The attack types are defined over the set of "all possible byte combinations of inputs to the hash function". > Simply put, this is bad security. Anyone who disagrees doesn't understand > the problem. Well, anyone who confuses collision attacks (which have been shown against MD5) with second pre-image attacks (which is what the GPG protected MD5 hashes in the SBO force an attacker to achieve) is also not fully up to speed on the meaning of the different attacks and the security properties they provide and falls into the trap of "criticis[ing] MD5 and SHA1 for the wrong reasons" [4]. > Can't we just add an optional sha256sum in the .info file and > maintainers can gradually add these checksums to their SlackBuilds, > targeting some point in the future that these fields will be required (and > possibly the md5s retired)? Upgrading to sha256 is not a bad idea, but the MD5's do not yet present a "the sky is falling" risk given the way they are verified via the GPG signature protecting the SBO file. [1] https://en.wikipedia.org/wiki/Collision_attack [2] https://en.wikipedia.org/wiki/Preimage_attack [3] http://www.cs.cmu.edu/~perspectives/md5.html (paragraph beginning "To understand the implications" up through the paragraph ending "Perspectives requires only second preimage resistance of MD5") [4] https://en.wikibooks.org/wiki/Cryptography/Breaking_Hash_Algorithms "The MD5 and SHA-1 hash functions, in applications that do not actually require collision resistance, are still considered adequate. Many people criticise MD5 and SHA1 for the wrong reasons. [4] There is no known practical or almost-practical preimage attack on MD5 or SHA-1, much less second-preimage attacks, only collision attacks.[5][6] From didier at slint.fr Thu Aug 23 11:53:09 2018 From: didier at slint.fr (Didier Spaier) Date: Thu, 23 Aug 2018 13:53:09 +0200 Subject: [Slackbuilds-users] Metacharacters in package names In-Reply-To: References: <33d2862e-5bd4-3657-9526-930acab76283@gmail.com> <20180822224203.147b6d4c@kiwi.kuchen> <0f4d8df6-4944-e4ce-7d42-b3d7aa9a5e1c@gmail.com> Message-ID: On 08/23/2018 12:34 PM, B Watson wrote: > So, plus, hyphen, and underscore are the only non-alphanumeric characters > Pat uses. And they're 7-bit ASCII only. Those should be our rules, > too. I'd even go so far as to say we should stick to that even if Pat > changes his rules (because Pat doesn't have to care about his package > names breaking sbopkg, sbotools, etc, and we do, or at least should) In my opinion tools like sbotool sbopkg and such should be adapted to handle filenames including other characters than alpha-numeric, plus, hyphen, and underscore if they appear in Slackware package names. I don't expect that all 137,374 characters listed in Unicode 11.O will be used though, anyway less than half of them have an associated glyph even among the GNU Unifont and Noto fonts ;) But of course we'd better avoid to use those that can need to be quoted listed in http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_02 Namely: | & ; < > ( ) $ ` \ " ' and also: * ? [ # ? = % Didier From gdiaz at qswarm.com Thu Aug 23 12:41:36 2018 From: gdiaz at qswarm.com (Gabriel Diaz) Date: Thu, 23 Aug 2018 12:41:36 +0000 Subject: [Slackbuilds-users] MD5 hash sums In-Reply-To: <20180823105850.GA28830@d820.dp100.com> References: <0b55b7022d14c57953ae737f19f4e656@airmail.cc> <980bee46-9041-11c7-63f9-8b4ae834f48d@osh.id.au> <20180823105850.GA28830@d820.dp100.com> Message-ID: Hello, I think this is not a big deal, changing to another hash function should be easy enough. But I also think slackbuilds should stay away of the security discussion. Providing a secure distribution channel is in the hands of the code owner only. If the source is already weak there is no encryption in the world to protect you. And even though I just mirrored sbosrcarch, I would say slackbuilds should stay away from being a third party code distributor. Anyway I think there is nothing wrong adding SHA1 in the info file, tools can ignore or check it as they like. Just don't make it a requirement. saludos, gabi ??????? Original Message ??????? On August 23, 2018 12:58 PM, Richard Ellis via SlackBuilds-users wrote: > On Thu, Aug 23, 2018 at 01:45:44AM -0400, T3 slider wrote: > > > On Wed, Aug 22, 2018, 11:15 PM David O'Shaughnessy lists at osh.id.au wrote: > > > > > For an attacker to change the upstream source archive without > > > changing the MD5 requires a 2nd preimage attack, which as far as > > > I understand is not computationally feasible at present. This is > > > different to a much simpler collision attack, where the attacker > > > generates two new archives with new (and matching) MD5s. > > > > The download files do not necessarily have to be tar archives, and > > in some cases (generally those with multiple download files and > > therefore multiple checksums), individual files can be included for > > download. Intentional PDF collisions have been around for ages > > (see https://www.mscs.dal.ca/~selinger/md5collision/ ), so if a > > SlackBuild includes some documentation as a download link, and the > > upstream server has since been compromised, a user could definitely > > be stuck with a malicious file even if the SlackBuild maintainer > > did everything right and verified upstream signatures. > > The reason the slackbuild MD5's do not fall victim to the "pdf > collision" attack is a subtle distinction between what crytographers > define as a "collision" attack vs. a second pre-image attack. > > The pdf attack you describe above is a "collision" attack. A > collision attack is defined by cryptographers as "find any two files, > A and B, which produce the same hash" [1]. That was how the PDF > attack worked, it was just constrained to "the A and B files need to > be valid PDF files". But, a collision attack does not allow an > attacker (MITM, etc.) to simply substitute the upstream file with a > new file that matches the same hash as the origional file. > > In order for an attacker to substitute a different upstream file for > the origional file, the attacker has to find a new file that matches > the MD5 hash of the existing file. This attack is what > cryptographers define as a "second pre-image" attack. And it means > "given a file G, find another file C which has an identical hash" > [2]. This is the attack that a MITM ISP or a cracker breaking in to > an upstream repository has to perform to substitute a different file > that matches the MD5 in the SBO. > > The reason is that the SBO files contain an MD5 sum of a known file G > (the origional). And the SBO file is then protected by a GPG > signature. If a user verifies that the downloaded SBO and GPG > signature are valid, then the user knows that the SBO has not been > altered. Therefore the user knows the MD5 sum within the SBO has > also not been altered (by a MITM or other attack). > > Therefore, in order for the downloaded file (tar ball, zip, pdf, > whatever) to be altered, but still match the MD5 sum in the SBO, a > second pre-image attack is requred. This is because the valid MD5 > sum in the SBO is now the sum of a single given file G, and the MITM > has to find a new file C which hashes to the same MD5 of the given > file G. > > MD5 has not (yet) been shown to be vulnerable to this attack (second > pre-image) in any feasable timeframe [3][4]. Yes, a day is going to > arrive sometime in the future where it will likely fall to a second > pre-image attack, so upgrading to a stronger hash function is also a > good idea. But the MD5's are not (yet) a security risk. > > > It is probably more difficult to generate tarballs > > with collisions but I'm guessing it isn't quite as difficult as we're > > pretending it is, and it's irrelevant since unzipped files can be passed as > > download links. > > Cryptographers don't care about what the stream of bytes represent. > The attack types are defined over the set of "all possible byte > combinations of inputs to the hash function". > > > Simply put, this is bad security. Anyone who disagrees doesn't understand > > the problem. > > Well, anyone who confuses collision attacks (which have been shown > against MD5) with second pre-image attacks (which is what the GPG > protected MD5 hashes in the SBO force an attacker to achieve) is also > not fully up to speed on the meaning of the different attacks and the > security properties they provide and falls into the trap of > "criticis[ing] MD5 and SHA1 for the wrong reasons" [4]. > > > Can't we just add an optional sha256sum in the .info file and > > maintainers can gradually add these checksums to their SlackBuilds, > > targeting some point in the future that these fields will be required (and > > possibly the md5s retired)? > > Upgrading to sha256 is not a bad idea, but the MD5's do not yet > present a "the sky is falling" risk given the way they are verified > via the GPG signature protecting the SBO file. > > [1] https://en.wikipedia.org/wiki/Collision_attack > [2] https://en.wikipedia.org/wiki/Preimage_attack > [3] http://www.cs.cmu.edu/~perspectives/md5.html (paragraph beginning > "To understand the implications" up through the paragraph ending > "Perspectives requires only second preimage resistance of MD5") > > [4] https://en.wikibooks.org/wiki/Cryptography/Breaking_Hash_Algorithms > "The MD5 and SHA-1 hash functions, in applications that do not > actually require collision resistance, are still considered > adequate. > > Many people criticise MD5 and SHA1 for the wrong reasons. [4] > There is no known practical or almost-practical preimage attack on > MD5 or SHA-1, much less second-preimage attacks, only collision > attacks.[5][6] > > 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 -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 855 bytes Desc: OpenPGP digital signature URL: From thyr at airmail.cc Thu Aug 23 22:59:59 2018 From: thyr at airmail.cc (thyr at airmail.cc) Date: Fri, 24 Aug 2018 01:59:59 +0300 Subject: [Slackbuilds-users] MD5 hash sums In-Reply-To: <1de56b9c-2d20-2600-81e9-2bb2b3519130@slackbuilds.org> References: <0b55b7022d14c57953ae737f19f4e656@airmail.cc> <1de56b9c-2d20-2600-81e9-2bb2b3519130@slackbuilds.org> Message-ID: <980380c19ac3890d1d8f68e17a292984@airmail.cc> >>> Each SlackBuild archive is signed by the SBo devs, so any >>> modifications on the server (or in-between) would fail subsequent >>> verification. In that case it's the GPG signature that you trust to >>> verify the .info file contents (and all the rest of the SlackBuild >>> stuff), not the MD5 sum or whatever else is inside it. >> >> Sorry, the question I had in mind was about MD5 sums inside it. Seems >> kind of strange that SlackBuild archive is protected by GPG signature, >> but the actual source tarball is not signed and is protected by >> (obsolete) MD5 checksum. Aren't this situation an opportunity to MITM >> the source tarball itself, since some DOWNLOAD links are provided >> trough >> plain HTTP? > > Sources are not protected by us. We do not provide the MD5 sum as any > sort of security measure, it shouldn't be treated as one. We have no > agency over upstream sources, and we purposefully do not host them, so > we cannot provide any signature or sum that could be considered a token > of security. Thanks for the clarification. I'm still struggling getting the grasp of it's effect though.. Quoting the FAQ from https://slackbuilds.org/faq/#asc > What are all of those .asc files in the repository? > > Those files are GPG signatures. They can be used to verify that the > SlackBuild script tarball is exactly the one that we placed on the > site. So, one can verify the authenticity of the SlackBuild script, but the authenticity of the source tarball itself used by the aforementioned script is uncertain? If that's the case then why would one bother with verifying authenticity at all? (Something authentic) x (Something that may or may not be authentic) == (Something that may or may not be authentic), right? From brent at exitstatusone.com Thu Aug 23 23:17:25 2018 From: brent at exitstatusone.com (Brenton Earl) Date: Thu, 23 Aug 2018 17:17:25 -0600 Subject: [Slackbuilds-users] MD5 hash sums In-Reply-To: <980380c19ac3890d1d8f68e17a292984@airmail.cc> References: <0b55b7022d14c57953ae737f19f4e656@airmail.cc> <1de56b9c-2d20-2600-81e9-2bb2b3519130@slackbuilds.org> <980380c19ac3890d1d8f68e17a292984@airmail.cc> Message-ID: <1535066245.13669.4.camel@exitstatusone.com> On Fri, 2018-08-24 at 01:59 +0300, thyr at airmail.cc wrote: > > > > Each SlackBuild archive is signed by the SBo devs, so any > > > > modifications on the server (or in-between) would fail > > > > subsequent > > > > verification. In that case it's the GPG signature that you > > > > trust to > > > > verify the .info file contents (and all the rest of the > > > > SlackBuild > > > > stuff), not the MD5 sum or whatever else is inside it. > > > > > > Sorry, the question I had in mind was about MD5 sums inside it. > > > Seems > > > kind of strange that SlackBuild archive is protected by GPG > > > signature, > > > but the actual source tarball is not signed and is protected by > > > (obsolete) MD5 checksum. Aren't this situation an opportunity to > > > MITM > > > the source tarball itself, since some DOWNLOAD links are > > > provided? > > > trough > > > plain HTTP? > > > > Sources are not protected by us. We do not provide the MD5 sum as > > any > > sort of security measure, it shouldn't be treated as one. We have > > no > > agency over upstream sources, and we purposefully do not host them, > > so > > we cannot provide any signature or sum that could be considered a > > token > > of security. > > Thanks for the clarification. I'm still struggling getting the grasp > of? > it's effect though.. > > Quoting the FAQ from https://slackbuilds.org/faq/#asc > > > What are all of those .asc files in the repository? > > > > Those files are GPG signatures. They can be used to verify that > > the? > > SlackBuild script tarball is exactly the one that we placed on the? > > site. > > So, one can verify the authenticity of the SlackBuild script, but > the? > authenticity of the source tarball itself used by the aforementioned? > script is uncertain? If that's the case then why would one bother > with? > verifying authenticity at all? (Something authentic) x (Something > that? > may or may not be authentic) == (Something that may or may not be? > authentic), right? The maintainer is supposed to take the GPG signature, MD5 or SHA check sum from the upstream developer and use it to authenticate the source prior to uploading a new/updated SlackBuild. It is the maintainer's job to verify the source before putting their own check sum into the .info file. -- Brenton Earl -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: This is a digitally signed message part URL: From rellis at dp100.com Thu Aug 23 23:18:21 2018 From: rellis at dp100.com (Richard Ellis) Date: Thu, 23 Aug 2018 19:18:21 -0400 Subject: [Slackbuilds-users] MD5 hash sums In-Reply-To: <980380c19ac3890d1d8f68e17a292984@airmail.cc> References: <0b55b7022d14c57953ae737f19f4e656@airmail.cc> <1de56b9c-2d20-2600-81e9-2bb2b3519130@slackbuilds.org> <980380c19ac3890d1d8f68e17a292984@airmail.cc> Message-ID: <20180823231820.GC28830@d820.dp100.com> On Fri, Aug 24, 2018 at 01:59:59AM +0300, thyr at airmail.cc wrote: > >What are all of those .asc files in the repository? > > > >Those files are GPG signatures. They can be used to verify that the > >SlackBuild script tarball is exactly the one that we placed on the site. > > So, one can verify the authenticity of the SlackBuild script, The .asc files protect the entire slackbuild package. They verify that the entire *.tar.gz file has not been modified since the SBo admins posted the *.tar.gz file to the site. > but the authenticity of the source tarball itself used by the > aforementioned script is uncertain? No. The MD5 sum being discussed in *inside* the SBo *.tar.gz file in the *.info file contained therein. The *.asc file authenticating the *.tar.gz SBo package allows you (assuming you check the GPG signature) to determine that the *.tar.gz was not modified, which by extension means the *.info inside was also not modified since the package was posted. Now you know that the *.info was not modified (due to the GPG *.asc file). If the *.info file was not modified, then the MD5 sum inside was also not modified and represents exactly what the maintainer placed inside the *.info file when they created it. So with a MD5 sum that you know to have been unmodified (due to checking the *.asc on the whole bundle) you can verify that the package source you download from the download link matches the unmodified MD5 sum in the *.info file. If they match, you have verified that the downloaded source package you received is identical to that which was used by the SBo package maintainer when they created the SBo *.info file. The reason this works is that to break this (substitute a different download package for the origional download package) the attacker has to perform a second pre-image attack, which remains computationaly infeasable today even for MD5. > If that's the case then why would one bother with verifying > authenticity at all? (Something authentic) x (Something that may > or may not be authentic) == (Something that may or may not be > authentic), right? The authenticity verification is so you can be sure someone did not substitute a different copy of myapp.tar.gz from the copy used by the SBo maintainer when they created the buildscript and *.info file. An attacker might try to insert "evil virus" into the download package, hoping someone would download it in the future and without checking the hashes compile it up, install it, and now the attacker has a victim. From erik at slackbuilds.org Fri Aug 24 03:36:05 2018 From: erik at slackbuilds.org (Erik Hanson) Date: Thu, 23 Aug 2018 22:36:05 -0500 Subject: [Slackbuilds-users] MD5 hash sums In-Reply-To: <980380c19ac3890d1d8f68e17a292984@airmail.cc> References: <0b55b7022d14c57953ae737f19f4e656@airmail.cc> <1de56b9c-2d20-2600-81e9-2bb2b3519130@slackbuilds.org> <980380c19ac3890d1d8f68e17a292984@airmail.cc> Message-ID: <62eca7d4-a7fe-ea0a-c8e0-2e6306730af9@slackbuilds.org> On 8/23/18 5:59 PM, thyr at airmail.cc wrote: > So, one can verify the authenticity of the SlackBuild script, but the > authenticity of the source tarball itself used by the aforementioned > script is uncertain? If that's the case then why would one bother with > verifying authenticity at all? (Something authentic) x (Something that > may or may not be authentic) == (Something that may or may not be > authentic), right? It's been mentioned in this thread enough times that MD5 has not fallen to the attack you think it has, so I won't repeat that talking point, but I will try and clarify something.. The checksums are not there to verify authenticity. Everyone seems to be putting far too much stock in the MD5 sums in the .info files. I can't stress this enough: they're not there for security. You could almost think of it as a version number. If the file you download matches the MD5 sum provided, then you know it's the same file the maintainer used, and the same file the SlackBuild was tested against by a SlackBuilds.org admin. This helps to ensure the SlackBuild will work as intended, creating a valid package. What the MD5 sum can, and does do on a regular basis, is raise a red flag when it mismatches. Possibly the source has gone missing, or been replaced by upstream without a change to the file name. These things happen often enough that it's important we have a checksum, and that people use it rather than complain that a SlackBuild is broken. However, you absolutely cannot assume that because the MD5 sum matches that the file is in any way "safe" or was not tampered with /before/ the maintainer got to it. Auditing or policing upstream sources is far beyond the scope of this project. We could use the strongest hashing algorithm available, but telling people it's a mark of authenticity would be nothing but theater. -- Erik -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From gen-bch at useyouresp.org.uk Fri Aug 24 06:46:08 2018 From: gen-bch at useyouresp.org.uk (Habs) Date: Fri, 24 Aug 2018 07:46:08 +0100 (BST) Subject: [Slackbuilds-users] MD5 hash sums In-Reply-To: <62eca7d4-a7fe-ea0a-c8e0-2e6306730af9@slackbuilds.org> References: <0b55b7022d14c57953ae737f19f4e656@airmail.cc> <1de56b9c-2d20-2600-81e9-2bb2b3519130@slackbuilds.org> <980380c19ac3890d1d8f68e17a292984@airmail.cc> <62eca7d4-a7fe-ea0a-c8e0-2e6306730af9@slackbuilds.org> Message-ID: On Thu, 23 Aug 2018, Erik Hanson wrote: > On 8/23/18 5:59 PM, thyr at airmail.cc wrote: > >> So, one can verify the authenticity of the SlackBuild script, but the >> authenticity of the source tarball itself used by the aforementioned >> script is uncertain? If that's the case then why would one bother with >> verifying authenticity at all? (Something authentic) x (Something that >> may or may not be authentic) == (Something that may or may not be >> authentic), right? > > It's been mentioned in this thread enough times that MD5 has not fallen > to the attack you think it has, so I won't repeat that talking point, > but I will try and clarify something.. > > The checksums are not there to verify authenticity. Everyone seems to be > putting far too much stock in the MD5 sums in the .info files. I can't > stress this enough: they're not there for security. > > You could almost think of it as a version number. If the file you > download matches the MD5 sum provided, then you know it's the same file > the maintainer used, and the same file the SlackBuild was tested against > by a SlackBuilds.org admin. This helps to ensure the SlackBuild will > work as intended, creating a valid package. > > What the MD5 sum can, and does do on a regular basis, is raise a red > flag when it mismatches. Possibly the source has gone missing, or been > replaced by upstream without a change to the file name. These things > happen often enough that it's important we have a checksum, and that > people use it rather than complain that a SlackBuild is broken. > > However, you absolutely cannot assume that because the MD5 sum matches > that the file is in any way "safe" or was not tampered with /before/ the > maintainer got to it. Auditing or policing upstream sources is far > beyond the scope of this project. We could use the strongest hashing > algorithm available, but telling people it's a mark of authenticity > would be nothing but theater. > > > -- > Erik > > It seems clear enough to me and has done since it was explained to me a while back. Effectively, if the maintainer unfortunately has used an 'unsafe' source, created its checksum for that source and then uploaded the build package, then all the checksum is doing when use it, is validating it was that original unsafe source (assuming it hasn't again been altered); or more preferably and likely the 'safe' source - as said, there is nothing SBo can do about unsafe sources and updating to better checksums etc won't help that it seems to me. I think the current approach is 'safe enough' once one accepts the above to prove nothing was tampered with when we get it - or at least will let us know. I stand to be corrected, however. Habs --- Sent using Alpine/Pine, a text based MUA --- From thyr at airmail.cc Fri Aug 24 11:03:26 2018 From: thyr at airmail.cc (thyr at airmail.cc) Date: Fri, 24 Aug 2018 14:03:26 +0300 Subject: [Slackbuilds-users] MD5 hash sums In-Reply-To: <62eca7d4-a7fe-ea0a-c8e0-2e6306730af9@slackbuilds.org> References: <0b55b7022d14c57953ae737f19f4e656@airmail.cc> <1de56b9c-2d20-2600-81e9-2bb2b3519130@slackbuilds.org> <980380c19ac3890d1d8f68e17a292984@airmail.cc> <62eca7d4-a7fe-ea0a-c8e0-2e6306730af9@slackbuilds.org> Message-ID: <099eed279a359a2ee6bab0ca022b339a@airmail.cc> > However, you absolutely cannot assume that because the MD5 sum matches > that the file is in any way "safe" or was not tampered with /before/ > the maintainer got to it. Can I assume that because MD5 sum matches that the file was not tampered after the maintainer got it? I believe this was the original scope of the thread in the first place. Quoting https://en.wikipedia.org/wiki/MD5#Preimage_vulnerability > In April 2009, a preimage attack against MD5 was published that breaks > MD5's preimage resistance. This attack is only theoretical, ... It was theoretical in 2009. The question is whether or not it was made practical in the past nine years? There are two possible outcomes. One: it was made practical and is not yet published. Two: it is still theoretical. Do you really want to wait until it becomes practical *and* published? From korgie at gmail.com Fri Aug 24 11:28:36 2018 From: korgie at gmail.com (=?utf-8?B?zpzOuc+HzqzOu863z4IgzpzOuc+HzrHOu86/z43OtM63z4I=?=) Date: Fri, 24 Aug 2018 14:28:36 +0300 Subject: [Slackbuilds-users] MD5 hash sums In-Reply-To: <099eed279a359a2ee6bab0ca022b339a@airmail.cc> References: <0b55b7022d14c57953ae737f19f4e656@airmail.cc> <1de56b9c-2d20-2600-81e9-2bb2b3519130@slackbuilds.org> <980380c19ac3890d1d8f68e17a292984@airmail.cc> <62eca7d4-a7fe-ea0a-c8e0-2e6306730af9@slackbuilds.org> <099eed279a359a2ee6bab0ca022b339a@airmail.cc> Message-ID: <78853F79-860D-4C2A-9679-DF7DE71F8C24@gmail.com> 24 ??? 2018, 2:03 ??, ? ??????? ?thyr at airmail.cc? ??????: > Do you really want to wait until it becomes practical *and* published? There is no ending to security measures. You stop to take measures when they?re is no threat, not possibility of threat. 1. Crackers are not stupid to waste time to tamper source code to match the same md5sum, it?s way too much complicated. And it?s very easy to notice. It?s easier for them to write a virus for autorun usb flash?s for other kind of users, not for slackers. 2. If the original coder can?t understand the difference in code after the tampering (I suppose will be huge) whatever measure is useless. (Excuse my English) From kjhambrick at gmail.com Fri Aug 24 11:36:11 2018 From: kjhambrick at gmail.com (Konrad J Hambrick) Date: Fri, 24 Aug 2018 06:36:11 -0500 Subject: [Slackbuilds-users] MD5 hash sums In-Reply-To: <099eed279a359a2ee6bab0ca022b339a@airmail.cc> References: <0b55b7022d14c57953ae737f19f4e656@airmail.cc> <1de56b9c-2d20-2600-81e9-2bb2b3519130@slackbuilds.org> <980380c19ac3890d1d8f68e17a292984@airmail.cc> <62eca7d4-a7fe-ea0a-c8e0-2e6306730af9@slackbuilds.org> <099eed279a359a2ee6bab0ca022b339a@airmail.cc> Message-ID: All -- IMO ( and ITO of other SBo Customers ), The MD5SUM= field in the .info file is to verify that the DOWNLOAD= files that you downloaded the same files that the Maintainer downloaded. Nothing more than that. It is not for security -- the SBo Maintainer cannot guarantee that the source files are secure -- that is the Upstream Developer's duty. IOW, What Habs said. -- kjh On Fri, Aug 24, 2018 at 6:03 AM, wrote: > However, you absolutely cannot assume that because the MD5 sum matches >> that the file is in any way "safe" or was not tampered with /before/ the >> maintainer got to it. >> > > Can I assume that because MD5 sum matches that the file was not tampered > after the maintainer got it? I believe this was the original scope of the > thread in the first place. > > Quoting https://en.wikipedia.org/wiki/MD5#Preimage_vulnerability > > In April 2009, a preimage attack against MD5 was published that breaks >> MD5's preimage resistance. This attack is only theoretical, ... >> > > It was theoretical in 2009. The question is whether or not it was made > practical in the past nine years? There are two possible outcomes. One: it > was made practical and is not yet published. Two: it is still theoretical. > Do you really want to wait until it becomes practical *and* published? > > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - https://slackbuilds.org/faq/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From willysr at slackbuilds.org Sat Aug 25 05:29:36 2018 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sat, 25 Aug 2018 12:29:36 +0700 Subject: [Slackbuilds-users] Updates - 20180825.1 Message-ID: <45f615c9-8852-8850-0b8e-ea6f86a19bc4@slackbuilds.org> Hi all David has submitted qt5-legacy, qt5-webkit-legacy, and PyQt5-legacy (5.7.1) in a separate branch. We will use this branch for testing new qt5 LTS release (5.9.x) soon. Sat Aug 25 03:00:23 UTC 2018 academic/ITK: Support for Slackware current. academic/pari: Updated for version 2.11.0. business/maltego: Added (osint and forensics). business/stansoft: Updated for version 7.14. desktop/Zafiro-icons: Updated for version 0.4. desktop/jgmenu: Updated for version 1.2. desktop/qt5ct: Updated for version 0.36. desktop/simplenote: Updated for version 1.1.7. development/GitEye: Fix symlink. development/Sphinx: Updated for version 1.7.7. development/apitrace: Fixed download. development/beautysh: Updated for version 3.11. development/dte: Added (small and easy to use console text editor). development/envytools: Fixed download. development/jupyter-ipywidgets: Updated for version 7.4.0. development/jupyter-widgetsnbextension: Upgraded for version 3.4.0. development/libretro-samples: Fixed download. development/mutagen: Updated for version 1.41.1. development/radare2: Updated for version 2.8.0. development/sbcl: Updated for version 1.4.10. games/4do-libretro: Fixed download. games/Craft-libretro: Fixed download. games/Gearboy: Fixed download. games/Gearsystem: Fixed download. games/Genesis-Plus-GX: Fixed download. games/QuickNES-Core: Fixed download. games/RetroArch: Patched for upstream regression. games/beetle-bsnes-libretro: Fixed download. games/beetle-gba-libretro: Fixed download. games/beetle-lynx-libretro: Fixed download. games/beetle-ngp-libretro: Fixed download. games/beetle-pce-fast-libretro: Fixed download. games/beetle-pcfx-libretro: Fixed download. games/beetle-psx-libretro: Fixed download. games/beetle-saturn-libretro: Fixed download. games/beetle-supergrafx-libretro: Fixed download. games/beetle-vb-libretro: Fixed download. games/beetle-wswan-libretro: Fixed download. games/blastem-libretro: Fixed download. games/blueMSX-libretro: Fixed download. games/bnes-libretro: Fixed download. games/bsnes-libretro: Fixed download. games/bsnes-mercury: Fixed download. games/cannonball-libretro: Fixed download. games/exult: Fixed download. games/fbalpha: Fixed download. games/fmsx-libretro: Fixed download. games/fortune-ASR: Fixed typo. games/gambatte-libretro: Fixed download. games/gpsp-libretro: Fixed download. games/gw-libretro: Fixed download. games/higan-libretro: Fixed download. games/libretro-2048: Fixed download. games/libretro-desmume: Fixed download. games/libretro-fceumm: Fixed download. games/libretro-handy: Fixed download. games/libretro-lutro: Fixed download. games/libretro-prboom: Fixed download. games/libretro-reicast: Fixed download. games/libretro-vecx: Fixed download. games/libretro-yabause: Fixed download. games/mame2000-libretro: Fixed download. games/mame2010-libretro: Fixed download. games/mame2014-libretro: Fixed download. games/meteor-libretro: Fixed download. games/mupen64plus-libretro: Fixed download. games/nSide-libretro: Fixed download. games/nuvie: Fixed download. games/nxengine-libretro: Fixed download. games/parallel-n64: Fixed download. games/pcsx-rearmed: Fixed download. games/pcsx2: Fixed download. games/picodrive: Fixed download. games/planetblupi: Updated for version 1.13.0. games/prosystem-libretro: Fixed download. games/scid_vs_pc: Updated for version 4.19 + new maintainer. games/scummvm-libretro: Fixed download. games/snes9x2002: Fixed download. games/snes9x2005: Fixed download. games/snes9x2010: Fixed download. games/stella-libretro: Fixed download. games/tyrquake-libretro: Fixed download. games/vba-next: Fixed download. games/vbam-libretro: Fixed download. games/virtualjaguar-libretro: Fixed download. games/z26v3: Added (an Atari 2600 emulator). gis/gpxsee: Updated for version 5.17. gis/ossim: Updated for version 2.5.0. gis/pktools: Updated for version 2.6.7.4. ham/hamlib: Updated for version 3.3 libraries/SDL_kitchensink: Updated for version 1.0.4. libraries/appstream-glib: Updated for version 0.7.12. libraries/levmar: Fixed library symlinks. libraries/libvirt-python: Updated for version 4.5.0. libraries/libvirt: Updated for version 4.5.0. libraries/libwacom: Updated for version 0.31. libraries/msgpack-c: Updated for version 3.1.0. libraries/pgplot: Updated with small fix in profile.d scripts. misc/mosquitto: Updated for version 1.5.1 multimedia/obs-studio: Updated for version 22.0.1 multimedia/opera-developer-ffmpeg-codecs: Updated for version 0.32. multimedia/opera-ffmpeg-codecs: Updated for version 0.32.3. network/claws-mail: Updated for version 3.17.0. network/opera-developer: Updated for version 56.0.3051.0. network/opera: Updated for version 55.0.2994.44. network/palemoon-bin: Updated for version 28.0.0. network/palemoon: Updated for version 28.0.0. network/phpmyadmin: Updated for version 4.8.3. network/riot-web: Updated for version 0.16.1. network/riot-web: Updated for version 0.16.2. network/signal-desktop: Updated for version 1.15.5. network/slimjet: Updated for version 19.0.9.0. network/spice-gtk: Added opus as mandatory dependency. network/wireshark: Update for lua52 dep. office/keepassxc: Updated for version 2.3.4. perl/perl-Module-ScanDeps: Updated for version 1.25. python/pycryptodome: Updated for version 3.6.6. python/python3-pylint: Added (python code checker). python/websocket-client: Updated for version 0.49.0. ruby/ruby-build: Updated for version 20180822. system/capstone: Updated for version 3.0.5 (stable version). system/dosbox-dev: Updated for version 0.74.r4139. system/fd: Updated for version 7.1.0. system/nano-syntax-highlighting: Updated for version 20180815. system/noto-emoji: Updated for version 20180810. system/openrc-services: Updated for version 20180819. system/passwordsafe: Updated for version 1.06BETA. system/picocom: Updated for version 3.1 + new maintainer. system/wiimms-iso-tools: Fixed download. system/wine-staging: Updated for version 3.14. +--------------------------+ -- Willy Sudiarto Raharjo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From lksj at yandex.ru Sat Aug 25 07:57:56 2018 From: lksj at yandex.ru (=?utf-8?B?0JrQsNGA0LDQsdCw0L3QvtCyINCQ0LvQtdC60YHQtdC5?=) Date: Sat, 25 Aug 2018 10:57:56 +0300 Subject: [Slackbuilds-users] iotop longer not work Message-ID: <9495251535183876@iva3-0d9a30469759.qloud-c.yandex.net> Hello. After update to Slackware 14.2 i found crash iotop. Function parse_proc_pid_status(pid) in module data.py read lines from /proc/*/status and split them by ':\t' delimiter. Status file can contain empty strings (EOL only). Therefore, function can't split line. I created very simple patch for iotop v0.6 to check exist delimiter in string. However, in git repository http://repo.or.cz/iotop.git/shortlog exist commits for fixed this problem. I provide use my patch or use newer version for git repo. Patch attached. -- ? ?????????, ?.????????? -------------- next part -------------- A non-text attachment was scrubbed... Name: iotop.patch Type: text/x-diff Size: 635 bytes Desc: not available URL: From willysr at slackbuilds.org Sat Aug 25 10:23:07 2018 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sat, 25 Aug 2018 17:23:07 +0700 Subject: [Slackbuilds-users] Fix for iotop issue with 4.4.144 kernel In-Reply-To: References: Message-ID: <35a68686-553e-cc5d-804c-7e1f4a5deff7@slackbuilds.org> > iotop is broken with the latest Slackware kernel. I've included the > maintainer here, but also posting the note and a patch for the iotop > SlackBuild to the list for further review. > > A few comments regarding the issue and patch: Recent kernels, including > Slackware's 4.4.144 kernel, have introduced at least one blank line in > /proc//status which breaks the parse_proc_pid_status() function in > iotop/data.py. The added patch fix-proc-status-read.patch updates this > function to skip empty lines. > > Additional reports of this issue can be found here:? > > ??? [1] https://bugzilla.redhat.com/show_bug.cgi?id=1584612? > ??? [2] > https://unix.stackexchange.com/questions/446624/error-with-command-iotop-on-centos? > > ??? [3] https://bugs.launchpad.net/pkg-website/+bug/1773383 > > The fix is based on the report in [2]. Thanks for the information i have tested and pushed the patch to my branch which will be included in the next public update. -- Willy Sudiarto Raharjo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From willysr at slackbuilds.org Sat Aug 25 10:23:47 2018 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sat, 25 Aug 2018 17:23:47 +0700 Subject: [Slackbuilds-users] iotop longer not work In-Reply-To: <9495251535183876@iva3-0d9a30469759.qloud-c.yandex.net> References: <9495251535183876@iva3-0d9a30469759.qloud-c.yandex.net> Message-ID: <1adbf213-b8fd-35ce-c5fe-adbe1b182c4d@slackbuilds.org> > After update to Slackware 14.2 i found crash iotop. > Function parse_proc_pid_status(pid) in module data.py read lines from /proc/*/status > and split them by ':\t' delimiter. > Status file can contain empty strings (EOL only). > Therefore, function can't split line. > > I created very simple patch for iotop v0.6 to check exist delimiter in string. > > However, in git repository http://repo.or.cz/iotop.git/shortlog > exist commits for fixed this problem. > > I provide use my patch or use newer version for git repo. I have pushed a patch from another member and tested to work in my branch. It will be part of the next public update. -- Willy Sudiarto Raharjo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From sborg63 at disroot.org Sun Aug 26 16:00:37 2018 From: sborg63 at disroot.org (sborg63) Date: Sun, 26 Aug 2018 17:00:37 +0100 Subject: [Slackbuilds-users] Python, pip and SlackBuilds.... Fw: [leo-editor/leo-editor] "python setup.py install" does not complete (#810) Message-ID: <20180826170037.7b34cc9c@knotsUL> Hi all, There are python programs that no longer depend on setup.py scripts using install but exclusively on those that use pip (for example LEO, as described below). How are we dealing with this? Is there a way of adapting the Slackbuilds for such programs or do we accept that pip becomes another way of dealing with python (It already is part of the python distribution in current)? Or do we ask upstream to keep providing a setup.py that can use install? Background: As a response to my request for a setup.py install script for the LEO editor (https://github.com/leo-editor/leo-editor/issues/810), the answer is to use pip: The recent version has changed to a complete pip-install and bypasses the possibility of using the setup.py install method. The latter is -as far as I have been using python modules/packages in Slackware- the method of choice to build a package via a SlackBuild which produces a tgz-package that can then be installed/updated using the common slackware tools. The idea behind the pip-only install is that determining updates/dependencies is much easier (with the presumed improvements linked below). At the moment on SBo these dependencies have been sorted out (and SlackBuilds made available) which allows a slacker to use one install-method (the distribution-specific tools) instead of a mixture of tools (distribitution plus tool-specific methods (like pip for python)). Cheers, Rob Begin forwarded message: Date: Sun, 26 Aug 2018 01:05:16 -0700 From: matt wilkie To: leo-editor/leo-editor Cc: brobr , Author Subject: Re: [leo-editor/leo-editor] "python setup.py install" does not complete (#810) > Could such a setup.py be restored in the 'leo/dist/' folder of 5.7 > [...} The 5.6 setup.py and friends can be found at https://github.com/leo-editor/leo-editor/tree/5.6/leo/dist and will be there for as long as Github is. Copying from the Github tag to root of a local Leo folder is functionally equivalent to copying from local dist folder to root: wget https://raw.githubusercontent.com/leo-editor/leo-editor/5.6/leo/dist/setup.py \ -O=~/my-leo-distrib/setup.py > ...for those who like to create distribution-specific packages (and > want to bypass pip)? There have a been changes in setup.py since 5.6 not specifically related to pip. Sooner or later using the old version will probably stop working. [Pip solves a lot of problems](https://stackoverflow.com/a/15731459/14420), are you sure you can't use it? If there are specific reasons you can't, re-open this issue and we can explore what might be done. I'll need information and feedback though as I don't know about building distribution packages. -- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/leo-editor/leo-editor/issues/810#issuecomment-416021532 -------------- next part -------------- An HTML attachment was scrubbed... URL: From kingbeowulf at gmail.com Mon Aug 27 00:52:52 2018 From: kingbeowulf at gmail.com (King Beowulf) Date: Sun, 26 Aug 2018 17:52:52 -0700 Subject: [Slackbuilds-users] Announce: Gridcoin-Research Message-ID: <9c6dd348-0b97-d315-3901-4cc2d9a28c11@gmail.com> Gridcoin-Research is now in the pending queue. Gridcoin (GRC) is a cryptocurrency based on bitcoin, but instead of burning up the electrical grid, the GRC awards are based on participation in BOINC scientific computing projects. Send bug reports to the usual places. Enjoy. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: OpenPGP digital signature URL: From duncan_roe at optusnet.com.au Mon Aug 27 01:13:03 2018 From: duncan_roe at optusnet.com.au (Duncan Roe) Date: Mon, 27 Aug 2018 11:13:03 +1000 Subject: [Slackbuilds-users] Python, pip and SlackBuilds.... Fw: [leo-editor/leo-editor] "python setup.py install" does not complete (#810) In-Reply-To: <20180826170037.7b34cc9c@knotsUL> References: <20180826170037.7b34cc9c@knotsUL> Message-ID: <20180827011303.GA18455@dimstar.local.net> Ui Rob, On Sun, Aug 26, 2018 at 05:00:37PM +0100, sborg63 wrote: > Hi all, > > There are python programs that no longer depend on setup.py scripts > using install but exclusively on those that use pip (for example LEO, as > described below). How are we dealing with this? Is there a way of > adapting the Slackbuilds for such programs or do we accept that pip > becomes another way of dealing with python (It already is part of the > python distribution in current)? Or do we ask upstream to keep providing > a setup.py that can use install? > > Background: > As a response to my request for a setup.py install script for the > LEO editor (https://github.com/leo-editor/leo-editor/issues/810), the > answer is to use pip: The recent version has changed to a complete > pip-install and bypasses the possibility of using the setup.py install > method. The latter is -as far as I have been using python > modules/packages in Slackware- the method of choice to build a package > via a SlackBuild which produces a tgz-package that can then be > installed/updated using the common slackware tools. > > The idea behind the pip-only install is that determining > updates/dependencies is much easier (with the presumed improvements > linked below). At the moment on SBo these dependencies have been sorted > out (and SlackBuilds made available) which allows a slacker to use one > install-method (the distribution-specific tools) instead of a mixture > of tools (distribitution plus tool-specific methods (like pip for > python)). > > Cheers, > > Rob > > Begin forwarded message: [...] Yes leo only has a whheel, not a tar.gz. This is unusual and unfortunate, because pip2tgz needs a source archive of some kind. I tried pip2tgz on a couple od snapshots, but it always fails with: running install_egg_info Copying leo.egg-info to /tmp/SBo/package-leo-editor/usr/lib64/python2.7/site-packages/leo-5.7.3-py2.7.egg-info running install_scripts Traceback (most recent call last): File "", line 1, in File "/tmp/pip-req-build-FnJDwJ/setup.py", line 164, in 'gui_scripts': ['leo = leo.core.runLeo:run'] File "/usr/lib64/python2.7/distutils/core.py", line 151, in setup dist.run_commands() File "/usr/lib64/python2.7/distutils/dist.py", line 953, in run_commands self.run_command(cmd) File "/usr/lib64/python2.7/distutils/dist.py", line 972, in run_command cmd_obj.run() File "/usr/lib64/python2.7/site-packages/setuptools/command/install.py", line 61, in run return orig.install.run(self) File "/usr/lib64/python2.7/distutils/command/install.py", line 575, in run self.run_command(cmd_name) File "/usr/lib64/python2.7/distutils/cmd.py", line 326, in run_command self.distribution.run_command(command) File "/usr/lib64/python2.7/distutils/dist.py", line 972, in run_command cmd_obj.run() File "/usr/lib64/python2.7/site-packages/setuptools/command/install_scripts.py", line 35, in run bw_cmd = self.get_finalized_command("bdist_wininst") File "/usr/lib64/python2.7/distutils/cmd.py", line 312, in get_finalized_command cmd_obj.ensure_finalized() File "/usr/lib64/python2.7/distutils/cmd.py", line 109, in ensure_finalized self.finalize_options() File "/usr/lib64/python2.7/distutils/command/bdist_wininst.py", line 112, in finalize_options for script in self.distribution.scripts: TypeError: 'NoneType' object is not iterable I can't fix this. Anyone?? Cheers ... Duncan. From nikos.giotis at gmail.com Mon Aug 27 18:02:59 2018 From: nikos.giotis at gmail.com (Nikos Giotis) Date: Mon, 27 Aug 2018 21:02:59 +0300 Subject: [Slackbuilds-users] Remove vms from the next update Message-ID: Hi, is it possible to remove the vms.SlackBuild, so that I can upload a new one updated for the latest version? Nikos From nikos.giotis at gmail.com Mon Aug 27 18:27:36 2018 From: nikos.giotis at gmail.com (Nikos Giotis) Date: Mon, 27 Aug 2018 21:27:36 +0300 Subject: [Slackbuilds-users] Announce: Introducing vms Message-ID: <0b19a700-53ad-3c64-265c-9b18f29bd197@gmail.com> Hi, I am announcing vms. It is a set of command line tools for managing and creating qemu virtual machines. The code is here, it is written in bash and has minimal dependencies https://bitbucket.org/yotis/vms A ready slackware package with version 0.1.3 is here https://bitbucket.org/yotis/vms/downloads/vms-0.1.3-noarch-1did.tgz A command line is provided called vms that is to be used by a normal user. It has a simple interface. I have started a thread on linuxquestions here https://www.linuxquestions.org/questions/slackware-14/%5Bann%5D-introducing-vms-more-qemu-virtual-machines-4175637126/ Viewable links to the man pages are here https://bitbucket.org/yotis/vms/src/master/doc/man/man1/vms.1.md https://bitbucket.org/yotis/vms/src/master/doc/man/man5/vms.conf.5.md https://bitbucket.org/yotis/vms/src/master/doc/man/man8/rc.vms.8.md https://bitbucket.org/yotis/vms/src/master/doc/man/man5/rc.vms.conf.5.md It is useful for me for some years now, any feedback is more than welcome Nikos From ts at websafe.pl Tue Aug 28 13:37:54 2018 From: ts at websafe.pl (Thomas Szteliga) Date: Tue, 28 Aug 2018 15:37:54 +0200 Subject: [Slackbuilds-users] PHP 7.x Message-ID: <1c0f6d92-abb0-7c2b-174e-16347c5b05bf@websafe.pl> Hello, is there any reason why PHP 7.x (7.0, 7.1, 7.2, 7.3) is not available on Slackbuilds.org? I know about: ~~~~ As a general rule, we do not accept SlackBuild scripts of software that is included as part of Slackware; however, exceptions may be made by the admin staff on a case-by-case basis. ~~~~ There is with Python 2.7 in the official repo. Would a PHP 7.x slackbuild be accepted by the admin staff? -- Thomas Szteliga -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3719 bytes Desc: Kryptograficzna sygnatura S/MIME URL: From belka at caraus.de Tue Aug 28 13:55:31 2018 From: belka at caraus.de (Eugen Wissner) Date: Tue, 28 Aug 2018 15:55:31 +0200 Subject: [Slackbuilds-users] PHP 7.x In-Reply-To: <1c0f6d92-abb0-7c2b-174e-16347c5b05bf@websafe.pl> References: <1c0f6d92-abb0-7c2b-174e-16347c5b05bf@websafe.pl> Message-ID: <1535464531.1689.7.camel@caraus.de> Hi, I don't see any reason why it wouldn't be. Name it php7 or php72 and don't override any files from php5. I already have one and it is already used on a production server. It should be only cleaned up a bit. I can send it you if you'd like. Regards Eugene Am Dienstag, den 28.08.2018, 15:37 +0200 schrieb Thomas Szteliga: > Hello, > > is there any reason why PHP 7.x (7.0, 7.1, 7.2, 7.3) is not available > on Slackbuilds.org? I know about: > > ~~~~ > As a general rule, we do not accept SlackBuild scripts of software > that is > included as part of Slackware; however, exceptions may be made by the > admin > staff on a case-by-case basis. > > ~~~~ > > > There is > with Python 2.7 in the official repo. > > Would a PHP 7.x slackbuild be accepted by the admin staff? > > > _______________________________________________ > 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 artourter at gmail.com Tue Aug 28 14:03:02 2018 From: artourter at gmail.com (Greg' Ar Tourter) Date: Tue, 28 Aug 2018 15:03:02 +0100 Subject: [Slackbuilds-users] PHP 7.x In-Reply-To: <1535464531.1689.7.camel@caraus.de> References: <1c0f6d92-abb0-7c2b-174e-16347c5b05bf@websafe.pl> <1535464531.1689.7.camel@caraus.de> Message-ID: Well I guess that one of the reason for php7 not being in sbo is that since it is now in -current, it would be a bit of a wasted effort to create one now only to have it removed when slackware-15 gets released. I don't think it would get rejected though. Greg On Tue, 28 Aug 2018 at 14:55, Eugen Wissner wrote: > > Hi, > > I don't see any reason why it wouldn't be. Name it php7 or php72 and > don't override any files from php5. I already have one and it is > already used on a production server. It should be only cleaned up a > bit. I can send it you if you'd like. > > Regards > Eugene > > Am Dienstag, den 28.08.2018, 15:37 +0200 schrieb Thomas Szteliga: > > Hello, > > > > is there any reason why PHP 7.x (7.0, 7.1, 7.2, 7.3) is not available > > on Slackbuilds.org? I know about: > > > > ~~~~ > > As a general rule, we do not accept SlackBuild scripts of software > > that is > > included as part of Slackware; however, exceptions may be made by the > > admin > > staff on a case-by-case basis. > > > > ~~~~ > > > > > > There is > > with Python 2.7 in the official repo. > > > > Would a PHP 7.x slackbuild be accepted by the admin staff? > > > > > > _______________________________________________ > > 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 belka at caraus.de Tue Aug 28 14:12:51 2018 From: belka at caraus.de (Eugen Wissner) Date: Tue, 28 Aug 2018 16:12:51 +0200 Subject: [Slackbuilds-users] PHP 7.x In-Reply-To: References: <1c0f6d92-abb0-7c2b-174e-16347c5b05bf@websafe.pl> <1535464531.1689.7.camel@caraus.de> Message-ID: <1535465571.1689.11.camel@caraus.de> Hm.. I won't update a production server to 15.0 on the day of its release :) and more and more apps require php7. php7 from -current isn't compatible with php5 and some people need to run both. Slackware 15.0 has a long way, it is not in beta, there are will be betas and several Release Candidates before. Unfortunately SBo will be closed once Slackware 15 is released, but normally only the php version in the script should be updated and it works. I wouldn't call it "wasted effort" anyway. There is some chance Pat will update php to php7 for slackware 14.2 once php5 reached EOL. We should ask Pat to change php paths to version specific paths, so one can run two versions simultaneously. Eugene Am Dienstag, den 28.08.2018, 15:03 +0100 schrieb Greg' Ar Tourter: > Well I guess that one of the reason for php7 not being in sbo is that > since it is now in -current, it would be a bit of a wasted effort to > create one now only to have it removed when slackware-15 gets > released. > > I don't think it would get rejected though. > > Greg > On Tue, 28 Aug 2018 at 14:55, Eugen Wissner wrote: > > > > Hi, > > > > I don't see any reason why it wouldn't be. Name it php7 or php72 > > and > > don't override any files from php5. I already have one and it is > > already used on a production server. It should be only cleaned up a > > bit. I can send it you if you'd like. > > > > Regards > > Eugene > > > > Am Dienstag, den 28.08.2018, 15:37 +0200 schrieb Thomas Szteliga: > > > Hello, > > > > > > is there any reason why PHP 7.x (7.0, 7.1, 7.2, 7.3) is not > > > available > > > on Slackbuilds.org? I know about: > > > > > > ~~~~ > > > As a general rule, we do not accept SlackBuild scripts of > > > software > > > that is > > > included as part of Slackware; however, exceptions may be made by > > > the > > > admin > > > staff on a case-by-case basis. > > > > > > ~~~~ > > > > > > > > > There is > > > > > > with Python 2.7 in the official repo. > > > > > > Would a PHP 7.x slackbuild be accepted by the admin staff? > > > > > > > > > _______________________________________________ > > > SlackBuilds-users mailing list > > > SlackBuilds-users at slackbuilds.org > > > https://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > > > Archives - https://lists.slackbuilds.org/pipermail/slackbuilds-us > > > ers/ > > > 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-user > > s/ > > 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 Tue Aug 28 15:41:33 2018 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Tue, 28 Aug 2018 22:41:33 +0700 Subject: [Slackbuilds-users] PHP 7.x In-Reply-To: <1535465571.1689.11.camel@caraus.de> References: <1c0f6d92-abb0-7c2b-174e-16347c5b05bf@websafe.pl> <1535464531.1689.7.camel@caraus.de> <1535465571.1689.11.camel@caraus.de> Message-ID: <1b206068-a827-6d20-7f8e-dec65462c613@slackbuilds.org> > Slackware 15.0 has a long way, it is not in beta, there are will be > betas and several Release Candidates before. Unfortunately SBo will be > closed once Slackware 15 is released, but normally only the php version > in the script should be updated and it works. I wouldn't call it > "wasted effort" anyway. There is some chance Pat will update php to > php7 for slackware 14.2 once php5 reached EOL. SBo will be closed for new submission when Alpha/Beta is announced so we have enough time to test all scripts (we have over 7000+ now) to be working with future Slackware 15.0. Hopefully, we can publish 15.0 repository on the same day as Slackware 15.0 gets released just as what we did with 14.2 repository. -- Willy Sudiarto Raharjo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From fernando.lopezjr at gmail.com Thu Aug 30 02:42:29 2018 From: fernando.lopezjr at gmail.com (Fernando Lopez) Date: Wed, 29 Aug 2018 20:42:29 -0600 Subject: [Slackbuilds-users] filezilla wrong checksum. Message-ID: .. connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] Saving to: ?FileZilla_3.35.2_src.tar.bz2? FileZilla_3.35.2_sr [ <=> ] 7.95K 12.1KB/s in 0.7s 2018-08-29 20:41:59 (12.1 KB/s) - ?FileZilla_3.35.2_src.tar.bz2? saved [8140] Found FileZilla_3.35.2_src.tar.bz2 in /var/cache/sbopkg. Checking MD5SUM: MD5SUM check for FileZilla_3.35.2_src.tar.bz2 ... FAILED! Expected: bf3e44c081771bb4be917ae7817689ce Found: 1ddde56dc54bda0e25c10fa35f072efa Do you want to use the downloaded filezilla source: FileZilla_3.35.2_src.tar.bz2 in /var/cache/sbopkg? You can choose among the following options: - (Y)es, keep the source and continue the build process; - (N)o, delete the source and abort the build process; - (R)etry download and continue the build process; or - (A)ttempt to download from third party source repository. (Y)es, (N)o, (R)etry, (A)lternative ?: -- ------------ Regards, Fernando Lopez Jr. -------------- next part -------------- An HTML attachment was scrubbed... URL: From willysr at slackbuilds.org Thu Aug 30 03:31:46 2018 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Thu, 30 Aug 2018 10:31:46 +0700 Subject: [Slackbuilds-users] filezilla wrong checksum. In-Reply-To: References: Message-ID: <5846f386-baec-5690-8bee-c4aa910c4086@slackbuilds.org> > HTTP request sent, awaiting response... 200 OK > Length: unspecified [text/html] > Saving to: ?FileZilla_3.35.2_src.tar.bz2? > > FileZilla_3.35.2_sr [ <=> ] 7.95K 12.1KB/s in > 0.7s > > 2018-08-29 20:41:59 (12.1 KB/s) - ?FileZilla_3.35.2_src.tar.bz2? saved > [8140] > > Found FileZilla_3.35.2_src.tar.bz2 in /var/cache/sbopkg. > Checking MD5SUM: > MD5SUM check for FileZilla_3.35.2_src.tar.bz2 ... FAILED! > Expected: bf3e44c081771bb4be917ae7817689ce > Found: 1ddde56dc54bda0e25c10fa35f072efa > > Do you want to use the downloaded filezilla source: > FileZilla_3.35.2_src.tar.bz2 in /var/cache/sbopkg? > > You can choose among the following options: > - (Y)es, keep the source and continue the build process; > - (N)o, delete the source and abort the build process; > - (R)etry download and continue the build process; or > - (A)ttempt to download from third party source repository. > (Y)es, (N)o, (R)etry, (A)lternative ?: You didn't get the correct file (html instead of tar.bz2), so it's normal that you will get different checksum :) anyway, i have pushed 3.36.0 on my branch -- Willy Sudiarto Raharjo -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From yth at ythogtha.org Fri Aug 31 09:07:30 2018 From: yth at ythogtha.org (Arnaud) Date: Fri, 31 Aug 2018 11:07:30 +0200 Subject: [Slackbuilds-users] DosBox is releasing... Message-ID: <20180831110730.f00c4b765ac8040e7b2dbe05@ythogtha.org> Hi everybody, yesterday something happened. DosBox released a new version. After more than 8 years on 0.74, we will be entering into the future with the next update on version 0.74-2 ! Seriouslier (Yeah, I know), it seems there's a 0.75 coming. And as they really don't want to break any working game, this 0.74-2 only changes a very few maintenance things over 0.74, for example no more need of a patch to compile on modern gcc. So I think that as soon as 0.75 is delivered, I'll keep 0.74-2 on a new package named dosbox74, which might not change for the foreseeable future, and the dosbox package will follow the 0.75 release. I will also keep dosbox-dev, because nothing indicates that they'll release 0.76 before 2026, eight years from now. If this happens not to be true, and they start to release more often, less frightened to break compatibility because 0.74 will still be there and working for all the games with which it is already working... well, we'll see then ! Happy Retro Gaming Folks ! -- Arnaud From thedoogster at gmail.com Fri Aug 31 13:44:17 2018 From: thedoogster at gmail.com (Doogster) Date: Fri, 31 Aug 2018 06:44:17 -0700 Subject: [Slackbuilds-users] DosBox is releasing... In-Reply-To: <20180831110730.f00c4b765ac8040e7b2dbe05@ythogtha.org> References: <20180831110730.f00c4b765ac8040e7b2dbe05@ythogtha.org> Message-ID: OH MY GOD! On Fri, Aug 31, 2018 at 2:15 AM Arnaud wrote: > > Hi everybody, > > yesterday something happened. > DosBox released a new version. > After more than 8 years on 0.74, we will be entering into the future with the > next update on version 0.74-2 ! > > Seriouslier (Yeah, I know), it seems there's a 0.75 coming. > And as they really don't want to break any working game, this 0.74-2 only > changes a very few maintenance things over 0.74, for example no more need of a > patch to compile on modern gcc. > > So I think that as soon as 0.75 is delivered, I'll keep 0.74-2 on a new > package named dosbox74, which might not change for the foreseeable future, and > the dosbox package will follow the 0.75 release. > I will also keep dosbox-dev, because nothing indicates that they'll > release 0.76 before 2026, eight years from now. If this happens not to be true, > and they start to release more often, less frightened to break compatibility > because 0.74 will still be there and working for all the games with which it is > already working... well, we'll see then ! > > Happy Retro Gaming Folks ! > > -- > Arnaud > _______________________________________________ > 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 fernando.lopezjr at gmail.com Tue Aug 21 18:16:37 2018 From: fernando.lopezjr at gmail.com (Fernando Lopez) Date: Tue, 21 Aug 2018 18:16:37 -0000 Subject: [Slackbuilds-users] how can i define data_dir in makefile? In-Reply-To: References: <20180821173129.GC27099@blackswan> <20180821173659.GD27099@blackswan> <20180821174425.GE27099@blackswan> Message-ID: help On Tue, Aug 21, 2018 at 12:06 PM Fernando Lopez wrote: > not working... not working =\ > > On Tue, Aug 21, 2018 at 11:44 AM David Woodfall > wrote: > >> On Tuesday 21 August 2018 18:37, >> Dave Woodfall put forth the proposition: >> > On Tuesday 21 August 2018 11:33, >> > Fernando Lopez put forth the proposition: >> > > didnt work. =\ >> > >> > You could try: >> > >> > export DATA_DIR=bla >> > >> > But it does say to put it in the make file, so maybe you'll have to >> > sed it in or make a patch. >> >> By the way, CFLAGS="$SLKCFLAGS" \ ought to be before the make command >> anyway. >> >> -Dave >> >> > -Dave >> > >> > Well it does say to put it in the makefile >> > > On Tue, Aug 21, 2018 at 11:31 AM David Woodfall >> wrote: >> > > >> > > > On Tuesday 21 August 2018 11:29, >> > > > Fernando Lopez put forth the >> proposition: >> > > > > this is the error i get when i run my program... >> > > > > *"ERROR: DATA_DIR not found. Define in make file or run in src >> dir"* >> > > > > >> > > > > this is how i am doing it: >> > > > > >> > > > > make \ >> > > > > CFLAGS="$SLKCFLAGS" \ >> > > > > DATA_DIR=$PKG/usr/share/icsim >> > > > >> > > > Try putting in front of make or exporting it: >> > > > >> > > > DATA_DIR=bla \ >> > > > CFLAGS="$SLKCFLAGS" \ >> > > > make >> >> -- >> >> One of the things that hamper Linux's climb to world domination is the >> shortage of bad Computer Role Playing Games, or CRaPGs. No operating >> system >> can be considered respectable without one. >> -- Brian O'Donnell, odonnllb at tcd.ie >> >> .--. oo >> (____)// >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~' >> _______________________________________________ >> 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/ >> >> > > -- > > ------------ > Regards, > Fernando Lopez Jr. > -- ------------ Regards, Fernando Lopez Jr. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ICSim.tar.bz2 Type: application/x-bzip Size: 850608 bytes Desc: not available URL: From 1.41421 at gmail.com Wed Aug 22 00:13:24 2018 From: 1.41421 at gmail.com (JCA) Date: Wed, 22 Aug 2018 00:13:24 -0000 Subject: [Slackbuilds-users] sage up for grabs UNMAINTAINED In-Reply-To: <20180821234947.GA2263@dimstar.local.net> References: <3e1d444e-dc99-0524-20f3-11b76b8838d0@gmail.com> <9d4f6839-8a40-d700-e4ac-8fd997936428@gmail.com> <107bc49a-f99c-22e0-889b-1644933f99cc@slint.fr> <20180821234947.GA2263@dimstar.local.net> Message-ID: On Tue, Aug 21, 2018 at 5:49 PM, Duncan Roe wrote: > On Mon, Aug 13, 2018 at 09:08:46AM -0600, JCA wrote: > > Why not use the Debian binary tarball that is available in the Sage > > website? I have just tried (for Sage 8.3) and it seems to work fine. Here > > is what I did: > > > > 1. As root, unpacked the tarball in /opt. This create /opt/SageMath. > > 2. cd /opt/SageMath. > > 3. ./sage. This patches up Sage's files (black magic?) and launches Sage. > > You end up at the Sage CLI. It can be checked out that it works, at least > > for simple operations - like, e.g. an integration. > > 4. Exit Sage. > > 5. cd /usr/local/bin. > > 6. ln -s /opt/SageMath/sage ./sage. > > 7. Exit root. > > 8. Assuming that /usr/local/bin is in your path, launch Sage by invoking > > the sage command. > > 9. Verify that it works. > > > > Assuming that the above keeps working when using more esoteric Sage > > capabilities, getting a Slackbuilds script to do all that should be > > straightforward. I haven't tried building for sources, but I find it > > difficult to believe that the Debian binary tarball is created using some > > knowledge available to members of the inner circle alone. > > > > If I am missing something here please let me know. > > > Hi JCA, > > Sounds like it should be easy enough to automate into a build script using > mkchroot. I can give it a go (but I'm not a sage user). Could you please > clarify a couple if items: > > 1. Does ./sage really work after cd-ing to a freshly created directory? > I am not sure I understand your question. What I describe allows one to install the Sage executable under /usr/local/bin, and launch it from anywhere, provided that /usr/local/bin is in your path. You would only invoked ./sage from /usr/local/bin, but - why would you want to that? > > 2. I assume checking with an integration is not essential to the build > process - > is that correct? > That integration is nothing but a very basic functional test of the installed product. I just used the Debian package - I did not build Sage myself, for it takes ages and a serious system. I am merely pointing out that, following the steps I described above, one ends up with a Sage environment that seems to work fine, and one does not have to suffer the punishment that the original maintainer described in order to install it in a sensible location. I have tried a few other things in the resulting Sage, and they all seem to work. > Cheers ... Duncan. > > > > On Fri, Aug 10, 2018 at 11:26 AM, Didier Spaier wrote: > > > > > I forgot: his user a set specific user "maths" for that. > > > > > > On 08/10/2018 07:23 PM, Didier Spaier wrote: > > > > > > > > On 08/10/2018 04:22 AM, Daniel Prosser wrote: > > > >> Perhaps if upstream is fighting so hard to make it *not* possible to > > > package > > > >> sage, the best course of action is just to honor their intent and > stop > > > trying > > > >> (take it off SBo). Just my two cents as someone who does not use it > > > anyway (so > > > >> maybe it's actually only worth one cent). > > > > > > > > I am not an user either, but I once compiled it as regular user just > to > > > check > > > > its ability to make png files for graphs, for an actual (and blind) > user. > > > > I just asked this friend, he is currently using the 8.1 version. > > > > > > > > As for maths there is nothing close to sage's features I'd suggest > > > > not providing a SlackBuild but a README explaining the situation. > > > > > > > > Just my 0.02???. > _______________________________________________ > 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: