From willysr at slackbuilds.org Sat Nov 1 02:29:41 2014 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sat, 01 Nov 2014 09:29:41 +0700 Subject: [Slackbuilds-users] Updates - 20141101.1 Message-ID: <54544595.3030709@slackbuilds.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sat Nov 1 02:06:00 UTC 2014 academic/omlibraries: Updated for version svn20141024. academic/pianobooster: Update .info. academic/scipy: Updated for version 0.14.0. academic/sympy: Updated for version 0.7.5. accessibility/espeak: Update slack-desc. accessibility/pastebinit: Update .info. audio/podget: Updated for version 0.7.4. audio/pulseaudio: Patch to enforce prevention of parallel makes. development/SQLAlchemy: Updated for version 0.9.8. development/bpython: Update deps. development/coccinelle: Updated for version 1.0.0_rc22. development/eclipse-java: Fix DOWNLOAD url. development/freetds: Updated for version 0.91.103 development/google-go-lang: Allow disable test. development/inform: Update .info and slack-desc. development/npm2tgz: Updated for version 1.3.1. development/numpy-legacy: Added (Python extension). development/numpy: Updated for version 1.9.0. development/pcc-libs: Removed (included in pcc). development/pcc: Updated for version 1.1.0_beta_20141031. development/qbs: Added (Qt Build Suite). development/xa: Update .info. games/angband: Update docs. games/brickout: Fix script. games/hatari: Fix script and slack-desc. games/hatari_tos_roms: Fix script. gis/Fiona: Updated for version 1.4.7. gis/foxtrotgps: Updated for version 1.2.0. gis/osm2pgsql: Updated for version 0.86.0. gis/qgis: Updated for version 2.6.0. graphics/blender: updated for version 2.72b graphics/fim: Updated for version 0.4_rc1. graphics/maim: Added (screenshot taker). graphics/mcomix: Fix slack-desc. graphics/pdf2png: Updated for version 0.4. graphics/rawtherapee: Updated for version 4.2. libraries/CGAL: Updated for version 4.5. libraries/botocore: Updated for version 0.66.0. libraries/fifechan: Updated for version 0.1.2. libraries/futures: Updated for version 2.2.0. libraries/libsigc++-legacy12: Update script and slack-desc. libraries/live555: Updated for version 2014.10.21. libraries/matplotlib: Updated for version 1.4.1. misc/slop: Added (selection query). multimedia/get_iplayer: Updated for version 2.87. multimedia/makemkv: Updated for version 1.8.14. network/Pafy: Updated for version 0.3.64. network/aldryn-client: Updated for version 0.9.3. network/awscli: Updated for version 1.5.2. network/cyrus-imapd: Fixed building with newer bdb and official mirror network/flexget: Updated for version 1.2.208. network/megatools: Updated for version 1.9.93. network/museek+: Update script. network/node: Updated for version 0.10.33. network/pidgin-whatsapp: Updated for version 30072014. network/radvd: Updated for version 2.8. network/sks-keyserver: Added (OpenPGP keyserver). network/skype: Added info about apulse and fixed some mistakes network/speedtest-cli: Updated for version 0.3.1. network/tor: Updated for version 0.2.5.10. office/libreoffice-helppack: Updated for version 4.3.3. office/libreoffice-langpack: Updated for version 4.3.3. office/libreoffice: Updated for version 4.3.3. office/mdp: Updated for version 0.92.2. office/texstudio: Updated for version 2.8.6. perl/perl-DateTime-TimeZone: Fix DOWNLOAD url. perl/perl-DateTime: Fix DOWNLOAD url. perl/perl-Params-Validate: Fix DOWNLOAD url. python/argh: Updated for version 0.26.0. python/astroid: Updated for version 1.2.1. python/boto: Updated for version 2.34.0. python/curtsies: Updated for version 0.1.11. python/dnspython: Updated for version 1.12.0. python/flake8: Updated for version 2.2.5. python/pytables: Fix compilation with Cython-0.21. python/python-future: Updated for version 0.14.1. python/python-nbxmpp: Added (python non blocking xmpp library). python/python-oauthlib: Updated for version 0.6.3. python/python-swiftclient: Updated for version 2.3.1. python/regex: Updated for version 2014.10.23. python/requests-oauthlib: Updated for version 0.4.2. python/sge-pygame: Updated for version 0.13. python/virtualenv: Update README. system/ansible: Updated for version 1.7.2. system/cbmbasic: Fix README and slack-desc. system/fsviewer: Fix .info. system/kegs: Fix README and slack-desc. system/macutils: Fix .info. system/slpkg: Updated for version 2.0.2. system/suckless-tools: Fix .info. system/the_silver_searcher: Updated for version 0.26.0. system/tty2gif: Added (record your scripts into a gif). system/vcp: Fix .info. system/watch-fs: Updated for version 1.2.2. system/xen: Updated for version 4.3.3 system/z: Added (bash/zsh extension). system/zerofree: Added man page. +--------------------------+ - -- Willy Sudiarto Raharjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlRURZUACgkQiHuDdNczM4GjOwCePjPRuLYqoGVgQPNukfhpD+Ff klMAoKJAhoKP9TnHCAhUyT761rs1FUVx =3dnT -----END PGP SIGNATURE----- From hba.nihilismus at gmail.com Sat Nov 1 02:48:55 2014 From: hba.nihilismus at gmail.com (=?UTF-8?Q?Antonio_Hern=C3=A1ndez_Blas?=) Date: Fri, 31 Oct 2014 20:48:55 -0600 Subject: [Slackbuilds-users] Updates - 20141101.1 In-Reply-To: <54544595.3030709@slackbuilds.org> References: <54544595.3030709@slackbuilds.org> Message-ID: libraries/live555: Updated for version 2014.10.21. Aaaand there is a new version [1], which means that the source code for 2014.10.21 has been already deleted :-) Cheers. [1] http://www.live555.com/liveMedia/public/live.2014.10.28.tar.gz On Fri, Oct 31, 2014 at 8:29 PM, Willy Sudiarto Raharjo < willysr at slackbuilds.org> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Sat Nov 1 02:06:00 UTC 2014 > academic/omlibraries: Updated for version svn20141024. > academic/pianobooster: Update .info. > academic/scipy: Updated for version 0.14.0. > academic/sympy: Updated for version 0.7.5. > accessibility/espeak: Update slack-desc. > accessibility/pastebinit: Update .info. > audio/podget: Updated for version 0.7.4. > audio/pulseaudio: Patch to enforce prevention of parallel makes. > development/SQLAlchemy: Updated for version 0.9.8. > development/bpython: Update deps. > development/coccinelle: Updated for version 1.0.0_rc22. > development/eclipse-java: Fix DOWNLOAD url. > development/freetds: Updated for version 0.91.103 > development/google-go-lang: Allow disable test. > development/inform: Update .info and slack-desc. > development/npm2tgz: Updated for version 1.3.1. > development/numpy-legacy: Added (Python extension). > development/numpy: Updated for version 1.9.0. > development/pcc-libs: Removed (included in pcc). > development/pcc: Updated for version 1.1.0_beta_20141031. > development/qbs: Added (Qt Build Suite). > development/xa: Update .info. > games/angband: Update docs. > games/brickout: Fix script. > games/hatari: Fix script and slack-desc. > games/hatari_tos_roms: Fix script. > gis/Fiona: Updated for version 1.4.7. > gis/foxtrotgps: Updated for version 1.2.0. > gis/osm2pgsql: Updated for version 0.86.0. > gis/qgis: Updated for version 2.6.0. > graphics/blender: updated for version 2.72b > graphics/fim: Updated for version 0.4_rc1. > graphics/maim: Added (screenshot taker). > graphics/mcomix: Fix slack-desc. > graphics/pdf2png: Updated for version 0.4. > graphics/rawtherapee: Updated for version 4.2. > libraries/CGAL: Updated for version 4.5. > libraries/botocore: Updated for version 0.66.0. > libraries/fifechan: Updated for version 0.1.2. > libraries/futures: Updated for version 2.2.0. > libraries/libsigc++-legacy12: Update script and slack-desc. > libraries/live555: Updated for version 2014.10.21. > libraries/matplotlib: Updated for version 1.4.1. > misc/slop: Added (selection query). > multimedia/get_iplayer: Updated for version 2.87. > multimedia/makemkv: Updated for version 1.8.14. > network/Pafy: Updated for version 0.3.64. > network/aldryn-client: Updated for version 0.9.3. > network/awscli: Updated for version 1.5.2. > network/cyrus-imapd: Fixed building with newer bdb and official mirror > network/flexget: Updated for version 1.2.208. > network/megatools: Updated for version 1.9.93. > network/museek+: Update script. > network/node: Updated for version 0.10.33. > network/pidgin-whatsapp: Updated for version 30072014. > network/radvd: Updated for version 2.8. > network/sks-keyserver: Added (OpenPGP keyserver). > network/skype: Added info about apulse and fixed some mistakes > network/speedtest-cli: Updated for version 0.3.1. > network/tor: Updated for version 0.2.5.10. > office/libreoffice-helppack: Updated for version 4.3.3. > office/libreoffice-langpack: Updated for version 4.3.3. > office/libreoffice: Updated for version 4.3.3. > office/mdp: Updated for version 0.92.2. > office/texstudio: Updated for version 2.8.6. > perl/perl-DateTime-TimeZone: Fix DOWNLOAD url. > perl/perl-DateTime: Fix DOWNLOAD url. > perl/perl-Params-Validate: Fix DOWNLOAD url. > python/argh: Updated for version 0.26.0. > python/astroid: Updated for version 1.2.1. > python/boto: Updated for version 2.34.0. > python/curtsies: Updated for version 0.1.11. > python/dnspython: Updated for version 1.12.0. > python/flake8: Updated for version 2.2.5. > python/pytables: Fix compilation with Cython-0.21. > python/python-future: Updated for version 0.14.1. > python/python-nbxmpp: Added (python non blocking xmpp library). > python/python-oauthlib: Updated for version 0.6.3. > python/python-swiftclient: Updated for version 2.3.1. > python/regex: Updated for version 2014.10.23. > python/requests-oauthlib: Updated for version 0.4.2. > python/sge-pygame: Updated for version 0.13. > python/virtualenv: Update README. > system/ansible: Updated for version 1.7.2. > system/cbmbasic: Fix README and slack-desc. > system/fsviewer: Fix .info. > system/kegs: Fix README and slack-desc. > system/macutils: Fix .info. > system/slpkg: Updated for version 2.0.2. > system/suckless-tools: Fix .info. > system/the_silver_searcher: Updated for version 0.26.0. > system/tty2gif: Added (record your scripts into a gif). > system/vcp: Fix .info. > system/watch-fs: Updated for version 1.2.2. > system/xen: Updated for version 4.3.3 > system/z: Added (bash/zsh extension). > system/zerofree: Added man page. > +--------------------------+ > > > > - -- > Willy Sudiarto Raharjo > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iEYEARECAAYFAlRURZUACgkQiHuDdNczM4GjOwCePjPRuLYqoGVgQPNukfhpD+Ff > klMAoKJAhoKP9TnHCAhUyT761rs1FUVx > =3dnT > -----END PGP SIGNATURE----- > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - http://slackbuilds.org/faq/ > > -- Antonio Hern?ndez Blas | Oaxaca, M?xico, Mx. https://github.com/nihilismus | https://bitbucket.org/nihilismus | https://twitter.com/nihilipster -------------- next part -------------- An HTML attachment was scrubbed... URL: From ryan.q at linux.com Sat Nov 1 03:25:25 2014 From: ryan.q at linux.com (Ryan P.C. McQuen) Date: Fri, 31 Oct 2014 20:25:25 -0700 Subject: [Slackbuilds-users] Updates - 20141101.1 In-Reply-To: References: <54544595.3030709@slackbuilds.org> Message-ID: I put the new one on my sourceforge repo in case it updates again after the next update, feel free to use my link Christoph. http://sourceforge.net/projects/slackbuildsdirectlinks/files/live555/live.2014.10.28.tar.gz md5sum = ebde9f96eed53c33c28f17161847d96e - -- --- On Fri, Oct 31, 2014 at 7:48 PM, Antonio Hern?ndez Blas wrote: > libraries/live555: Updated for version 2014.10.21. > > Aaaand there is a new version [1], which means that the source code for > 2014.10.21 has been already deleted :-) > > Cheers. > > [1] http://www.live555.com/liveMedia/public/live.2014.10.28.tar.gz > > > On Fri, Oct 31, 2014 at 8:29 PM, Willy Sudiarto Raharjo > wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Sat Nov 1 02:06:00 UTC 2014 >> academic/omlibraries: Updated for version svn20141024. >> academic/pianobooster: Update .info. >> academic/scipy: Updated for version 0.14.0. >> academic/sympy: Updated for version 0.7.5. >> accessibility/espeak: Update slack-desc. >> accessibility/pastebinit: Update .info. >> audio/podget: Updated for version 0.7.4. >> audio/pulseaudio: Patch to enforce prevention of parallel makes. >> development/SQLAlchemy: Updated for version 0.9.8. >> development/bpython: Update deps. >> development/coccinelle: Updated for version 1.0.0_rc22. >> development/eclipse-java: Fix DOWNLOAD url. >> development/freetds: Updated for version 0.91.103 >> development/google-go-lang: Allow disable test. >> development/inform: Update .info and slack-desc. >> development/npm2tgz: Updated for version 1.3.1. >> development/numpy-legacy: Added (Python extension). >> development/numpy: Updated for version 1.9.0. >> development/pcc-libs: Removed (included in pcc). >> development/pcc: Updated for version 1.1.0_beta_20141031. >> development/qbs: Added (Qt Build Suite). >> development/xa: Update .info. >> games/angband: Update docs. >> games/brickout: Fix script. >> games/hatari: Fix script and slack-desc. >> games/hatari_tos_roms: Fix script. >> gis/Fiona: Updated for version 1.4.7. >> gis/foxtrotgps: Updated for version 1.2.0. >> gis/osm2pgsql: Updated for version 0.86.0. >> gis/qgis: Updated for version 2.6.0. >> graphics/blender: updated for version 2.72b >> graphics/fim: Updated for version 0.4_rc1. >> graphics/maim: Added (screenshot taker). >> graphics/mcomix: Fix slack-desc. >> graphics/pdf2png: Updated for version 0.4. >> graphics/rawtherapee: Updated for version 4.2. >> libraries/CGAL: Updated for version 4.5. >> libraries/botocore: Updated for version 0.66.0. >> libraries/fifechan: Updated for version 0.1.2. >> libraries/futures: Updated for version 2.2.0. >> libraries/libsigc++-legacy12: Update script and slack-desc. >> libraries/live555: Updated for version 2014.10.21. >> libraries/matplotlib: Updated for version 1.4.1. >> misc/slop: Added (selection query). >> multimedia/get_iplayer: Updated for version 2.87. >> multimedia/makemkv: Updated for version 1.8.14. >> network/Pafy: Updated for version 0.3.64. >> network/aldryn-client: Updated for version 0.9.3. >> network/awscli: Updated for version 1.5.2. >> network/cyrus-imapd: Fixed building with newer bdb and official mirror >> network/flexget: Updated for version 1.2.208. >> network/megatools: Updated for version 1.9.93. >> network/museek+: Update script. >> network/node: Updated for version 0.10.33. >> network/pidgin-whatsapp: Updated for version 30072014. >> network/radvd: Updated for version 2.8. >> network/sks-keyserver: Added (OpenPGP keyserver). >> network/skype: Added info about apulse and fixed some mistakes >> network/speedtest-cli: Updated for version 0.3.1. >> network/tor: Updated for version 0.2.5.10. >> office/libreoffice-helppack: Updated for version 4.3.3. >> office/libreoffice-langpack: Updated for version 4.3.3. >> office/libreoffice: Updated for version 4.3.3. >> office/mdp: Updated for version 0.92.2. >> office/texstudio: Updated for version 2.8.6. >> perl/perl-DateTime-TimeZone: Fix DOWNLOAD url. >> perl/perl-DateTime: Fix DOWNLOAD url. >> perl/perl-Params-Validate: Fix DOWNLOAD url. >> python/argh: Updated for version 0.26.0. >> python/astroid: Updated for version 1.2.1. >> python/boto: Updated for version 2.34.0. >> python/curtsies: Updated for version 0.1.11. >> python/dnspython: Updated for version 1.12.0. >> python/flake8: Updated for version 2.2.5. >> python/pytables: Fix compilation with Cython-0.21. >> python/python-future: Updated for version 0.14.1. >> python/python-nbxmpp: Added (python non blocking xmpp library). >> python/python-oauthlib: Updated for version 0.6.3. >> python/python-swiftclient: Updated for version 2.3.1. >> python/regex: Updated for version 2014.10.23. >> python/requests-oauthlib: Updated for version 0.4.2. >> python/sge-pygame: Updated for version 0.13. >> python/virtualenv: Update README. >> system/ansible: Updated for version 1.7.2. >> system/cbmbasic: Fix README and slack-desc. >> system/fsviewer: Fix .info. >> system/kegs: Fix README and slack-desc. >> system/macutils: Fix .info. >> system/slpkg: Updated for version 2.0.2. >> system/suckless-tools: Fix .info. >> system/the_silver_searcher: Updated for version 0.26.0. >> system/tty2gif: Added (record your scripts into a gif). >> system/vcp: Fix .info. >> system/watch-fs: Updated for version 1.2.2. >> system/xen: Updated for version 4.3.3 >> system/z: Added (bash/zsh extension). >> system/zerofree: Added man page. >> +--------------------------+ >> >> >> >> - -- >> Willy Sudiarto Raharjo >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v2 >> >> iEYEARECAAYFAlRURZUACgkQiHuDdNczM4GjOwCePjPRuLYqoGVgQPNukfhpD+Ff >> klMAoKJAhoKP9TnHCAhUyT761rs1FUVx >> =3dnT >> -----END PGP SIGNATURE----- >> _______________________________________________ >> SlackBuilds-users mailing list >> SlackBuilds-users at slackbuilds.org >> http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users >> Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ >> FAQ - http://slackbuilds.org/faq/ >> > > > > -- > Antonio Hern?ndez Blas | Oaxaca, M?xico, Mx. > https://github.com/nihilismus | https://bitbucket.org/nihilismus | > https://twitter.com/nihilipster > > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - http://slackbuilds.org/faq/ > > From willysr at slackbuilds.org Sat Nov 1 03:38:01 2014 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sat, 01 Nov 2014 10:38:01 +0700 Subject: [Slackbuilds-users] Updates - 20141101.1 In-Reply-To: References: <54544595.3030709@slackbuilds.org> Message-ID: <54545599.6010106@slackbuilds.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > libraries/live555: Updated for version 2014.10.21. > > Aaaand there is a new version [1], which means that the source code > for 2014.10.21 has been already deleted :-) > > Cheers. > > [1] http://www.live555.com/liveMedia/public/live.2014.10.28.tar.gz i didn't have a copy of the current version since i have deleted them if anyone have that copy (i assume Christoph has it), can it be hosted somewhere public? I will update the download link in the website - -- Willy Sudiarto Raharjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlRUVZkACgkQiHuDdNczM4Eh2gCfeD2JD2qR2NXzmg04anMtPjTY zrUAn00eDP5d5c+ZmVi9L+s9HOZf/KtW =KWoT -----END PGP SIGNATURE----- From chris.willing at iinet.net.au Sat Nov 1 09:00:24 2014 From: chris.willing at iinet.net.au (Christoph Willing) Date: Sun, 02 Nov 2014 00:00:24 +1000 Subject: [Slackbuilds-users] Updates - 20141101.1 In-Reply-To: <54545599.6010106@slackbuilds.org> References: <54544595.3030709@slackbuilds.org> <54545599.6010106@slackbuilds.org> Message-ID: <5454E778.1090504@iinet.net.au> On 11/01/2014 01:38 PM, Willy Sudiarto Raharjo wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > >> libraries/live555: Updated for version 2014.10.21. >> >> Aaaand there is a new version [1], which means that the source code >> for 2014.10.21 has been already deleted :-) >> >> Cheers. >> >> [1] http://www.live555.com/liveMedia/public/live.2014.10.28.tar.gz > > i didn't have a copy of the current version since i have deleted them > if anyone have that copy (i assume Christoph has it), can it be hosted > somewhere public? > I will update the download link in the website > Keeping our own versions would be useful - there have been several updates recently and if the developers continue updating at this rate, the SlackBuilds will most likely specify out of date (therefore missing) source versions again. Ryan, thanks for hosting the live.2014.10.28.tar.gz tarball. Are you up for keeping an archive of them i.e. adding new versions of the source tarballs as they appear? I'm happy to set up something like that myself (and feel its my responsibility) but since you've already started with this one .. Actually, build failure due to an unavailable (out of date) source tarball could also be seen as a good thing, in that its better to be aware of a more recent (better?) version rather than being able to build old versions through keeping our own archive of older versions. I guess thats the developer's motivation too - they'd prefer everyone is using the latest version, so don't keep old versions available. The problem then is how to know when there's a new version available. To that end, I've made a little script that downloads the source tarball's md5sum and compares it with the local version. If they're different then the script sends me an email so that I know to check what's going on. After some fine tuning, I'll add it to my cron.daily so we should be able to keep the SlackBuild up to date. Any other ideas, comments, ..? chris From ryanpcmcquen at gmail.com Sat Nov 1 10:38:30 2014 From: ryanpcmcquen at gmail.com (Ryan P.C. McQuen) Date: Sat, 1 Nov 2014 08:38:30 -0700 Subject: [Slackbuilds-users] Updates - 20141101.1 In-Reply-To: <5454E778.1090504@iinet.net.au> References: <54544595.3030709@slackbuilds.org> <54545599.6010106@slackbuilds.org> <5454E778.1090504@iinet.net.au> Message-ID: > Are you up for keeping an archive of them i.e. adding new versions of the source tarballs as they appear? Sure, and this goes for any other projects that need file hosting. :^) Christoph, just send me the new tarballs as they drop and I'll upload them to the same folder (maybe I can get you your own login to the project, I'll check ;-). --- > On Nov 1, 2014, at 7:00 AM, Christoph Willing wrote: > > Are you up for keeping an archive of them i.e. adding new versions of the source tarballs as they appear? From rshepard at appl-ecosys.com Sat Nov 1 11:03:28 2014 From: rshepard at appl-ecosys.com (Rich Shepard) Date: Sat, 1 Nov 2014 09:03:28 -0700 (PDT) Subject: [Slackbuilds-users] New Versions: Scribus & R Message-ID: Scribus was upgraded to -1.4.4 and R to -3.1.2. Both build and run with the current scripts when the version number is changed. Rich From gfs1989.listas at gmx.net Sat Nov 1 16:32:33 2014 From: gfs1989.listas at gmx.net (Gilberto F da Silva) Date: Sat, 1 Nov 2014 19:32:33 -0200 Subject: [Slackbuilds-users] Error installing soundconverter 2.1.4 Message-ID: <20141101213233.GA3641@darkstar> Hello! I get the following when I try install soundconverter 2.1.7 checking for python version... 2.7 checking for python platform... linux2 checking for python script directory... ${prefix}/lib64/python2.7/site-packages checking for python extension module directory... ${exec_prefix}/lib64/python2.7/site-packages checking for pygtk 2.24 installed... found checking for python-gnome 2.16 installed... not found configure: error: required python-gnome version not found soundconverter: Would you like to continue processing the rest of the queue or would you like to abort? If this failed package is a dependency of another package in the queue then it may not make sense to continue. (Y)es to continue, (N)o to abort, (R)etry the build?: I use: Slackware 14.1 64 bits Computer HP s5-1220br 4GB RAM Intel Core i3 -- Gilberto F da Silva - gfs1989 at gmx.net - ICQ 136.782.571 Stela dato:2.456.963,432 Loka tempo:2014-11-01 19:21:58 Sabato -==- BEBIDA MATA LENTAMENTE !!! E da?? N?o estou com pressa! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 458 bytes Desc: not available URL: From gfs1989.listas at gmx.net Sat Nov 1 16:52:15 2014 From: gfs1989.listas at gmx.net (Gilberto F da Silva) Date: Sat, 1 Nov 2014 19:52:15 -0200 Subject: [Slackbuilds-users] Error installing libmp3splt Message-ID: <20141101215215.GB3641@darkstar> Hello! I receive the following when I try install libmp3splt: libtool: link: gcc -shared -fPIC -DPIC .libs/libsplt_ogg_la-ogg.o .libs/libsplt_ogg_la-ogg_silence.o .libs/libsplt_ogg_la-ogg_utils.o .libs/libsplt_ogg_la-silence_processors.o .libs/libsplt_ogg_la-ogg_new_stream_handler.o -Wl,-rpath -Wl,/tmp/SBo/libmp3splt-0.9.1a/src/.libs -L../src -L../src/.libs /tmp/SBo/libmp3splt-0.9.1a/src/.libs/libmp3splt.so /usr/lib/libvorbisfile.so -L/usr/lib /usr/lib/libvorbis.so -lm /usr/lib/libogg.so -ldl -O2 -O3 -Wl,-soname -Wl,libsplt_ogg.so.0 -o .libs/libsplt_ogg.so.0.0.0 /usr/lib/libvorbisfile.so: could not read symbols: File in wrong format collect2: error: ld returned 1 exit status make[2]: *** [libsplt_ogg.la] Error 1 make[2]: Leaving directory `/tmp/SBo/libmp3splt-0.9.1a/plugins' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/tmp/SBo/libmp3splt-0.9.1a' make: *** [all] Error 2 Slackware 14.1 computer HP s5-1220-br 4GB RAM intel core i3 -- Gilberto F da Silva - gfs1989 at gmx.net - ICQ 136.782.571 Stela dato:2.456.963,450 Loka tempo:2014-11-01 19:48:04 Sabato -==- Mouser drive n?o encontrado. Bater no gato (s/n)? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 458 bytes Desc: not available URL: From gfs1989.listas at gmx.net Sat Nov 1 17:42:29 2014 From: gfs1989.listas at gmx.net (Gilberto F da Silva) Date: Sat, 1 Nov 2014 20:42:29 -0200 Subject: [Slackbuilds-users] Error with clementine Message-ID: <20141101224229.GA13057@darkstar> Hello: Sbopkg does not install Clementine. The following components WILL NOT be built: Box support (missing Google sparsehash) Crash reporting (disabled in CMake config) Dropbox support (missing Google sparsehash) Gnome sound menu integration (missing indicate-qt) Google Drive support (missing Google sparsehash) Skydrive support (missing Google sparsehash) Sparkle integration (missing Mac OS X, Sparkle) Spotify support: non-GPL binary helper (missing protobuf, libspotify) Ubuntu One file support (missing Google sparsehash) CMake Error: The following variables are used in this project, but they are set to NOTFOUND. Please set them or make sure they are set and tested correctly in the CMake files: PROTOBUF_LIBRARY (ADVANCED) linked by target "libclementine-common" in directory /tmp/SBo/clementine-1.2.1/ext/libclementine-common -- Configuring incomplete, errors occurred! See also "/tmp/SBo/clementine-1.2.1/build/CMakeFiles/CMakeOutput.log". See also "/tmp/SBo/clementine-1.2.1/build/CMakeFiles/CMakeError.log". clementine: Would you like to continue processing the rest of the queue or would you like to abort? If this failed package is a dependency of another package in the queue then it may not make sense to continue. (Y)es to continue, (N)o to abort, (R)etry the build?: -- Gilberto F da Silva - gfs1989 at gmx.net - ICQ 136.782.571 Stela dato:2.456.963,486 Loka tempo:2014-11-01 20:39:32 Sabato -==- Estresse: voc? precisa saber evitar! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 458 bytes Desc: not available URL: From yalhcru at gmail.com Sat Nov 1 19:13:40 2014 From: yalhcru at gmail.com (B Watson) Date: Sat, 1 Nov 2014 20:13:40 -0400 Subject: [Slackbuilds-users] Error installing libmp3splt In-Reply-To: <20141101215215.GB3641@darkstar> References: <20141101215215.GB3641@darkstar> Message-ID: On 11/1/14, Gilberto F da Silva wrote: > /usr/lib/libvorbisfile.so: could not read symbols: File in wrong format This invariably means you're using Slackware 64-bit, with multilib 32-bit packages installed. It's addressed in the FAQ: http://slackbuilds.org/faq/#multilib > Slackware 14.1 ...you mean Slackware64 14.1, yes? From klaatu at straightedgelinux.com Sat Nov 1 20:06:19 2014 From: klaatu at straightedgelinux.com (Klaatu) Date: Sun, 02 Nov 2014 14:06:19 +1300 Subject: [Slackbuilds-users] Error with clementine In-Reply-To: <20141101224229.GA13057@darkstar> References: <20141101224229.GA13057@darkstar> Message-ID: <5455838B.6000006@straightedgelinux.com> Gilberto, Did you install protobuf first? Clementine does appear to depend upon it (you can see that by looking at the Clementine.info file), and I'm guessing that if you install protobuf (which itself depends on pysetuptools), Clementine will build and install successfully. A Slackbuild script does not natively install dependencies. It installs exactly the application that it was written for. No more. Note that sbopkg is not a part of SlackBuilds, so if the error is in the way sbopkg is handling dependencies, then that is an sbopkg bug rather than a Slackbuilds.org bug. But even in sbopkg's case, if I recall correcly, it is not its default behaviour to resolve dependencies. Cheers. - klaatu On 11/02/2014 11:42 AM, Gilberto F da Silva wrote: > Hello: > > Sbopkg does not install Clementine. > > > The following components WILL NOT be built: > Box support (missing Google sparsehash) > Crash reporting (disabled in CMake config) > Dropbox support (missing Google sparsehash) > Gnome sound menu integration (missing indicate-qt) > Google Drive support (missing Google sparsehash) > Skydrive support (missing Google sparsehash) > Sparkle integration (missing Mac OS X, Sparkle) > Spotify support: non-GPL binary helper (missing protobuf, libspotify) > Ubuntu One file support (missing Google sparsehash) > > CMake Error: The following variables are used in this project, but they are set to NOTFOUND. > Please set them or make sure they are set and tested correctly in the CMake files: > PROTOBUF_LIBRARY (ADVANCED) > linked by target "libclementine-common" in directory /tmp/SBo/clementine-1.2.1/ext/libclementine-common > > -- Configuring incomplete, errors occurred! > See also "/tmp/SBo/clementine-1.2.1/build/CMakeFiles/CMakeOutput.log". > See also "/tmp/SBo/clementine-1.2.1/build/CMakeFiles/CMakeError.log". > > clementine: > Would you like to continue processing the rest of the > queue or would you like to abort? If this failed > package is a dependency of another package in the queue > then it may not make sense to continue. > > (Y)es to continue, (N)o to abort, (R)etry the build?: > > > > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - http://slackbuilds.org/faq/ > From willysr at slackbuilds.org Sat Nov 1 20:59:08 2014 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sun, 02 Nov 2014 08:59:08 +0700 Subject: [Slackbuilds-users] Error installing soundconverter 2.1.4 In-Reply-To: <20141101213233.GA3641@darkstar> References: <20141101213233.GA3641@darkstar> Message-ID: <54558FEC.8090303@slackbuilds.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > checking for python-gnome 2.16 installed... not found configure: > error: required python-gnome version not found > > soundconverter: Would you like to continue processing the rest of > the queue or would you like to abort? If this failed package is a > dependency of another package in the queue then it may not make > sense to continue. > > (Y)es to continue, (N)o to abort, (R)etry the build?: You haven't installed the dependencies of soundconverter Here's the deps : gnome-media: ORBit2: pyorbit: libbonobo: gnome-mime-data: gnome-vfs: libgnome: gnome-python: gnome-python-desktop: libgnomecanvas: libbonoboui: libgnomeui: x264: lame: ffmpeg: libmp4v2: faac: gst-python: PyXML: gnome-common: twolame: faad2: aften: a52dec: - -- Willy Sudiarto Raharjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlRVj+wACgkQiHuDdNczM4H7owCfSv/UEmBWlp9qVwrwYWIGnBhJ DW4AniMSWEcEfSfIQD6nHjtzLl3bPrsM =LXTX -----END PGP SIGNATURE----- From willysr at slackbuilds.org Sat Nov 1 21:50:57 2014 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sun, 02 Nov 2014 09:50:57 +0700 Subject: [Slackbuilds-users] Error with clementine In-Reply-To: <5455838B.6000006@straightedgelinux.com> References: <20141101224229.GA13057@darkstar> <5455838B.6000006@straightedgelinux.com> Message-ID: <54559C11.4020306@slackbuilds.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> CMake Error: The following variables are used in this project, >> but they are set to NOTFOUND. Please set them or make sure they >> are set and tested correctly in the CMake files: PROTOBUF_LIBRARY >> (ADVANCED) linked by target "libclementine-common" in directory >> /tmp/SBo/clementine-1.2.1/ext/libclementine-common >> >> -- Configuring incomplete, errors occurred! See also >> "/tmp/SBo/clementine-1.2.1/build/CMakeFiles/CMakeOutput.log". See >> also >> "/tmp/SBo/clementine-1.2.1/build/CMakeFiles/CMakeError.log". >> >> clementine: Would you like to continue processing the rest of >> the queue or would you like to abort? If this failed package is >> a dependency of another package in the queue then it may not make >> sense to continue. >> >> (Y)es to continue, (N)o to abort, (R)etry the build?: This is similar to what you experienced before you are running multilib system, so protobuf wasn't found try to build protobuf in 32 bit environment and see if it work - -- Willy Sudiarto Raharjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlRVnBEACgkQiHuDdNczM4G7YwCgq3uRhlpsFur6FRnT2yeHg7Jp XvwAnRJeY3Aj66gpZK1tGSAqMQwre8AL =tpec -----END PGP SIGNATURE----- From chris.willing at iinet.net.au Sun Nov 2 04:15:30 2014 From: chris.willing at iinet.net.au (Christoph Willing) Date: Sun, 02 Nov 2014 20:15:30 +1000 Subject: [Slackbuilds-users] Updates - 20141101.1 In-Reply-To: <5454E778.1090504@iinet.net.au> References: <54544595.3030709@slackbuilds.org> <54545599.6010106@slackbuilds.org> <5454E778.1090504@iinet.net.au> Message-ID: <54560442.1050009@iinet.net.au> On 11/02/2014 12:00 AM, Christoph Willing wrote: > > > On 11/01/2014 01:38 PM, Willy Sudiarto Raharjo wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >>> libraries/live555: Updated for version 2014.10.21. >>> >>> Aaaand there is a new version [1], which means that the source code >>> for 2014.10.21 has been already deleted :-) >>> >>> Cheers. >>> >>> [1] http://www.live555.com/liveMedia/public/live.2014.10.28.tar.gz >> >> i didn't have a copy of the current version since i have deleted them >> if anyone have that copy (i assume Christoph has it), can it be hosted >> somewhere public? >> I will update the download link in the website >> > > Keeping our own versions would be useful - there have been several > updates recently and if the developers continue updating at this rate, > the SlackBuilds will most likely specify out of date (therefore missing) > source versions again. In fact when I tried to download the "new" 2014.10.28 tarball, it was already gone - superseded by yet another release, version 2014.11.01. A new SlackBuild using that latest version is in the SBo queue for the next round of updates. The new SlackBuild uses Ryan McQuen's archive at sf.net (thanks Ryan) so that the build doesn't break due a missing source tarball at the developer's download site. chris From alien at slackbuilds.org Sun Nov 2 07:03:35 2014 From: alien at slackbuilds.org (Eric Hameleers) Date: Sun, 02 Nov 2014 14:03:35 +0100 Subject: [Slackbuilds-users] Updates - 20141101.1 In-Reply-To: <54560442.1050009@iinet.net.au> References: <54544595.3030709@slackbuilds.org> <54545599.6010106@slackbuilds.org> <5454E778.1090504@iinet.net.au> <54560442.1050009@iinet.net.au> Message-ID: <54562BA7.504@slackbuilds.org> On 11/02/2014 11:15 AM, Christoph Willing wrote: > > > On 11/02/2014 12:00 AM, Christoph Willing wrote: >> >> >> On 11/01/2014 01:38 PM, Willy Sudiarto Raharjo wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- >>> Hash: SHA1 >>> >>>> libraries/live555: Updated for version 2014.10.21. >>>> >>>> Aaaand there is a new version [1], which means that the source code >>>> for 2014.10.21 has been already deleted :-) >>>> >>>> Cheers. >>>> >>>> [1] http://www.live555.com/liveMedia/public/live.2014.10.28.tar.gz >>> >>> i didn't have a copy of the current version since i have deleted them >>> if anyone have that copy (i assume Christoph has it), can it be hosted >>> somewhere public? >>> I will update the download link in the website >>> >> >> Keeping our own versions would be useful - there have been several >> updates recently and if the developers continue updating at this rate, >> the SlackBuilds will most likely specify out of date (therefore missing) >> source versions again. > > In fact when I tried to download the "new" 2014.10.28 tarball, it was > already gone - superseded by yet another release, version 2014.11.01. > A new SlackBuild using that latest version is in the SBo queue for the > next round of updates. > > The new SlackBuild uses Ryan McQuen's archive at sf.net (thanks Ryan) > so that the build doesn't break due a missing source tarball at the > developer's download site. > > chris > > Old versions of the live555 archive are kept here: https://code.google.com/p/live555sourcecontrol/downloads/list Eric From andyv133 at gmail.com Sun Nov 2 08:53:28 2014 From: andyv133 at gmail.com (andy vaselaar) Date: Sun, 2 Nov 2014 08:53:28 -0600 Subject: [Slackbuilds-users] rawstudio & lensfun Message-ID: I tried to compile rawstudio this morning and it failed with: ../../plugins/lensfun/lensfun.c:655:50: error: 'LF_MODIFY_CCI' undeclared (first use in this function) And according to https://bugs.kde.org/show_bug.cgi?id=331523, the CCI feature has been removed from the latest version of lensfun, thus breaking rawstudio. So the way I see it, either rawstudio needs to be updated (which hasn't happened in years), or we have to setup our slackbuild to require an older version of lensfun. Unfortunately, I'm new enough on this list to not really know how this sort of situation is typically handled, or if this is really even the right place to go. Any pointers? Thanks! Andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From willysr at slackbuilds.org Sun Nov 2 09:59:19 2014 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sun, 02 Nov 2014 22:59:19 +0700 Subject: [Slackbuilds-users] rawstudio & lensfun In-Reply-To: References: Message-ID: <545654D7.3010105@slackbuilds.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I tried to compile rawstudio this morning and it failed with: > > ../../plugins/lensfun/lensfun.c:655:50: error: 'LF_MODIFY_CCI' > undeclared (first use in this function) > > And according to https://bugs.kde.org/show_bug.cgi?id=331523, the > CCI feature has been removed from the latest version of lensfun, > thus breaking rawstudio. > > So the way I see it, either rawstudio needs to be updated (which > hasn't happened in years), or we have to setup our slackbuild to > require an older version of lensfun. Unfortunately, I'm new > enough on this list to not really know how this sort of situation > is typically handled, or if this is really even the right place to > go. > > Any pointers? rawstudio hasn't been updated since 2011, so it's pretty clear it's a dead project now you will need to downgrade or build lensfun 0.28 to have rawstudio installed and keep using it Nishant: any other idea? - -- Willy Sudiarto Raharjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlRWVNcACgkQiHuDdNczM4GmfgCdHJL3gvOnaHIJR6aZg3PClxij b4UAnRW5oTIn1TGPBES7Nh3XrH5LR5MX =svxS -----END PGP SIGNATURE----- From yalhcru at gmail.com Sun Nov 2 11:00:39 2014 From: yalhcru at gmail.com (B Watson) Date: Sun, 2 Nov 2014 12:00:39 -0500 Subject: [Slackbuilds-users] rawstudio & lensfun In-Reply-To: References: Message-ID: On 11/2/14, andy vaselaar wrote: > So the way I see it, either rawstudio needs to be updated (which hasn't > happened in years), or we have to setup our slackbuild to require an older > version of lensfun. One way to do it would be to have the rawstudio SlackBuild script compile its own older (preferably statically linked) private copy of lensfun, then link rawstudio with that. I had to do this with irssi_otr, when the libotr on SBo got upgraded and irssi_otr needed the older version. If you look at network/irssi_otr/irssi_otr.SlackBuild, you can see how it's done. Another, much simpler thing to try: look for distro patches for rawstudio, e.g. from Debian, Gentoo, Fedora, perhaps one of them has patched rawstudio so it can be built against the newer lensfun. From vmj at linuxbox.fi Sun Nov 2 11:05:48 2014 From: vmj at linuxbox.fi (Mikko Varri) Date: Sun, 2 Nov 2014 19:05:48 +0200 Subject: [Slackbuilds-users] perl/perl-AnyEvent(-Handle)? Message-ID: <20141102170548.GJ2202@linuxbox.fi> Hi, I was about to add a perl-AnyEvent.SlackBuild, but by chance noticed that perl-AnyEvent-Handle.SlackBuild already installs the whole AnyEvent distibution. AnyEvent::Handle is just one module of that distribution. So, I'd suggest renaming the SlackBuild. If you agree, you can review (and pull) the commits from https://github.com/vmj/slackbuilds/compare/perl-AnyEvent Thanks! -vmj From chris.willing at iinet.net.au Sun Nov 2 16:03:13 2014 From: chris.willing at iinet.net.au (Christoph Willing) Date: Mon, 03 Nov 2014 08:03:13 +1000 Subject: [Slackbuilds-users] Updates - 20141101.1 In-Reply-To: <54562BA7.504@slackbuilds.org> References: <54544595.3030709@slackbuilds.org> <54545599.6010106@slackbuilds.org> <5454E778.1090504@iinet.net.au> <54560442.1050009@iinet.net.au> <54562BA7.504@slackbuilds.org> Message-ID: <5456AA21.3070600@iinet.net.au> On 11/02/2014 11:03 PM, Eric Hameleers wrote: > On 11/02/2014 11:15 AM, Christoph Willing wrote: >> >> >> On 11/02/2014 12:00 AM, Christoph Willing wrote: >>> >>> >>> On 11/01/2014 01:38 PM, Willy Sudiarto Raharjo wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA1 >>>> >>>>> libraries/live555: Updated for version 2014.10.21. >>>>> >>>>> Aaaand there is a new version [1], which means that the source code >>>>> for 2014.10.21 has been already deleted :-) >>>>> >>>>> Cheers. >>>>> >>>>> [1] http://www.live555.com/liveMedia/public/live.2014.10.28.tar.gz >>>> >>>> i didn't have a copy of the current version since i have deleted them >>>> if anyone have that copy (i assume Christoph has it), can it be hosted >>>> somewhere public? >>>> I will update the download link in the website >>>> >>> >>> Keeping our own versions would be useful - there have been several >>> updates recently and if the developers continue updating at this rate, >>> the SlackBuilds will most likely specify out of date (therefore missing) >>> source versions again. >> >> In fact when I tried to download the "new" 2014.10.28 tarball, it was >> already gone - superseded by yet another release, version 2014.11.01. >> A new SlackBuild using that latest version is in the SBo queue for the >> next round of updates. >> >> The new SlackBuild uses Ryan McQuen's archive at sf.net (thanks Ryan) >> so that the build doesn't break due a missing source tarball at the >> developer's download site. >> >> chris >> >> > Old versions of the live555 archive are kept here: > https://code.google.com/p/live555sourcecontrol/downloads/list > > Eric Unfortunately the most recent version I can see archived there is 2011.12.23 so not much use any more. Their idea of keeping an archive was good but they didn't keep it up. chris From enigma77 at gmx.net Mon Nov 3 08:13:07 2014 From: enigma77 at gmx.net (enigma) Date: Mon, 03 Nov 2014 09:13:07 +0100 Subject: [Slackbuilds-users] Error installing libmp3splt In-Reply-To: <20141101215215.GB3641@darkstar> References: <20141101215215.GB3641@darkstar> Message-ID: <8041973.oRkCjDelpc@slackware> Am Samstag, 1. November 2014, 19:52:15 schrieb Gilberto F da Silva: > Hello! > > I receive the following when I try install libmp3splt: > > > libtool: link: gcc -shared -fPIC -DPIC .libs/libsplt_ogg_la-ogg.o .libs/libsplt_ogg_la-ogg_silence.o .libs/libsplt_ogg_la-ogg_utils.o .libs/libsplt_ogg_la-silence_processors.o .libs/libsplt_ogg_la-ogg_new_stream_handler.o -Wl,-rpath -Wl,/tmp/SBo/libmp3splt-0.9.1a/src/.libs -L../src -L../src/.libs /tmp/SBo/libmp3splt-0.9.1a/src/.libs/libmp3splt.so /usr/lib/libvorbisfile.so -L/usr/lib /usr/lib/libvorbis.so -lm /usr/lib/libogg.so -ldl -O2 -O3 -Wl,-soname -Wl,libsplt_ogg.so.0 -o .libs/libsplt_ogg.so.0.0.0 > /usr/lib/libvorbisfile.so: could not read symbols: File in wrong format > collect2: error: ld returned 1 exit status > make[2]: *** [libsplt_ogg.la] Error 1 > make[2]: Leaving directory `/tmp/SBo/libmp3splt-0.9.1a/plugins' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/tmp/SBo/libmp3splt-0.9.1a' > make: *** [all] Error 2 > > > Slackware 14.1 > computer HP s5-1220-br > 4GB RAM > intel core i3 > -- > > Gilberto F da Silva - gfs1989 at gmx.net - ICQ 136.782.571 > Stela dato:2.456.963,450 Loka tempo:2014-11-01 19:48:04 Sabato > -==- > Mouser drive n?o encontrado. Bater no gato (s/n)? What happens when you try to build the Pakage in this Way? # LDFLAGS="-L/usr/lib64" ./NAME.SlackBuild From chris.willing at iinet.net.au Fri Nov 7 22:23:28 2014 From: chris.willing at iinet.net.au (Christoph Willing) Date: Sat, 08 Nov 2014 08:23:28 +1000 Subject: [Slackbuilds-users] Another new live555 version In-Reply-To: <54560442.1050009@iinet.net.au> References: <54544595.3030709@slackbuilds.org> <54545599.6010106@slackbuilds.org> <5454E778.1090504@iinet.net.au> <54560442.1050009@iinet.net.au> Message-ID: <545D4660.7070408@iinet.net.au> On 11/02/2014 08:15 PM, Christoph Willing wrote: > > In fact when I tried to download the "new" 2014.10.28 tarball, it was > already gone - superseded by yet another release, version 2014.11.01. A > new SlackBuild using that latest version is in the SBo queue for the > next round of updates. Since last submission, which is approved but not yet "published" there's been another update (to 2014.11.07). I can't upload another SlackBuild because the last submission is currently in the approved queue. It would be nice to have the latest version used in the SlackBuild. The changes are at: https://github.com/cwilling/slackbuilds/tree/update-live555/libraries/live555 Is it possible for someone to update from there? chris From willysr at slackbuilds.org Fri Nov 7 23:30:51 2014 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sat, 08 Nov 2014 06:30:51 +0700 Subject: [Slackbuilds-users] Another new live555 version In-Reply-To: <545D4660.7070408@iinet.net.au> References: <54544595.3030709@slackbuilds.org> <54545599.6010106@slackbuilds.org> <5454E778.1090504@iinet.net.au> <54560442.1050009@iinet.net.au> <545D4660.7070408@iinet.net.au> Message-ID: <545D562B.8000509@slackbuilds.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Since last submission, which is approved but not yet "published" > there's been another update (to 2014.11.07). I can't upload another > SlackBuild because the last submission is currently in the approved > queue. It would be nice to have the latest version used in the > SlackBuild. The changes are at: > https://github.com/cwilling/slackbuilds/tree/update-live555/libraries/live555 > > > > Is it possible for someone to update from there? Done http://slackbuilds.org/cgit/slackbuilds/commit/?h=willysr&id=4e5644b3ad4c1a3241fe65157f4bb91df921f9f5 - -- Willy Sudiarto Raharjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlRdVisACgkQiHuDdNczM4EH0QCeLo9SbS1fFrNGMnGWmujfvlbS nzIAnRIYStvWj/2fdJdbysD+MtOXCnYt =CnSB -----END PGP SIGNATURE----- From willysr at slackbuilds.org Sat Nov 8 00:33:57 2014 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sat, 08 Nov 2014 07:33:57 +0700 Subject: [Slackbuilds-users] Updates - 20141107.1 Message-ID: <545D64F5.30301@slackbuilds.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fri Nov 7 23:40:46 UTC 2014 academic/R: Updated for version 3.1.2. academic/cld2: Updated for version 20141106. academic/gtypist: Update desktop file. accessibility/xsel: Fix .info. audio/bristol: Fix script. audio/calf: Updated for version 0.0.19kx. audio/fIcy: Fix slack-desc and .info. audio/kid3: Updated for version 3.1.1. audio/pulseaudio: Fix typo. audio/soundkonverter: Fix script. desktop/uwm: Updated for version 0.2.11a. development/brackets: Updated for version 1.0. development/gnustep-startup: Added (GNUstep core packages). development/gputils: Updated for version 1.4.0.1. development/meld3: Updated for version 3.12.1. development/pylint: Updated for version 1.3.1. development/sqlitebrowser: Updated for version 3.4.0. development/tiled-qt: Updated for version 0.10.2. games/freedoom: Updated for version 0.9. gis/libgeotiff: Updated for version 1.4.1. gis/qgis: Reflect upstream md5sum change. graphics/rawstudio: Update DEPS. libraries/OpenAL: Updated for version 1.16.0. libraries/lensfun-legacy: Added (photographic lens database). libraries/libburn: Updated for version 1.3.8. libraries/libearth: Updated for version 0.3.3. libraries/libisoburn: Updated for version 1.3.8. libraries/libisofs: Updated for version 1.3.8. libraries/liburcu: Updated for version 0.8.5. libraries/libvirt-python: Updated for version 1.2.10. libraries/libvirt: Updated for version 1.2.10. libraries/live555: Updated for version 2014.11.07. libraries/logilab-common: Updated for version 0.63.0. misc/dmg2img: Updated for version 1.6.5 + new maintainer. misc/qtkeychain: Updated for version 0.4.0. misc/ykpers: Updated for version 1.16.1. misc/yubikey-personalization-gui: Updated for version 3.1.17. multimedia/cantata: Updated for version 1.5.1. multimedia/mpv: Added (MPlayer fork). multimedia/tstools: Added (Command Line Tools for MPEG data). multimedia/x265: Updated for version 1.4. network/claws-mail: Updated for version 3.11.1. network/fcgiwrap: Added (Simple FastCGI wrapper). network/flexget: Updated for version 1.2.214. network/gajim: Updated for version 0.16 + new maintainer. network/milter-greylist: Added (greylist filter). network/phpmyadmin: Updated for version 4.2.11. network/thttpd: Updated for version 2.26. network/tnftp: Updated for version 20141031. network/wrk: Added (HTTP benchmarking tool). office/MasterPDFEditor: Updated for version 2.1.00. perl/perl-Devel-StackTrace: Updated for version 2.00. perl/perl-Exception-Class: Updated for version 1.39. perl/perl-Test-MockModule: Added (Override subroutines in a module). perl/perl-Test-Simple: Updated for version 1.001009. python/pysetuptools: Updated for version 7.0. python/python-libsass: Updated for version 0.6.1. python/pyzmq: Updated for version 14.4.1. python/regex: Updated for version 2014.11.03. system/cndrvcups-capt: Added (Canon CAPT Printer Driver). system/cndrvcups-common: Added (Canon Printer Driver Common Module). system/docker: Updated for version 1.3.1. system/epson-inkjet-printer-escpr: Updated for version 1.4.3. system/f2fs_tools: Updated for version 1.4.0. system/fr: Updated for version 1.22. system/pgsanity: Updated for version 0.2.8. system/slpkg: Updated for version 2.0.4. system/systrace: Fix .info. system/tilda: Updated for version 1.2.2. system/vagrant: Updated for version 1.6.5. system/vifm: Updated for version 0.7.8. system/wine: Updated for version 1.6.2. +--------------------------+ - -- Willy Sudiarto Raharjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlRdZPUACgkQiHuDdNczM4FxvACgkC7ZhNcfMwF6E6BW/xC2gt/g NQMAn3AulYWm8uOTmpNmAdLAAsWJ/34X =4jSm -----END PGP SIGNATURE----- From tarpit at comcast.net Sat Nov 8 17:21:55 2014 From: tarpit at comcast.net (Tarpit) Date: Sat, 08 Nov 2014 12:21:55 -0500 Subject: [Slackbuilds-users] postfix.SlackBuild single quoting Message-ID: <545E5133.5060000@comcast.net> The 14.1 SlackBuild for Postfix 2.11.1 has single quotes enclosing ${LIBDIRSUFFIX} in two places. The single quotes should be double quotes. Here are the two lines: SASLLIBS='-L/usr/lib${LIBDIRSUFFIX}/sasl2 -lsasl2' ;; DBLIBS='-L/usr/lib${LIBDIRSUFFIX}/mysql -lmysqlclient -lz -lm' ;; Thanks, Duane From mario at slackware.hr Sun Nov 9 21:01:10 2014 From: mario at slackware.hr (Mario Preksavec) Date: Sun, 09 Nov 2014 22:01:10 +0100 Subject: [Slackbuilds-users] postfix.SlackBuild single quoting In-Reply-To: <545E5133.5060000@comcast.net> References: <545E5133.5060000@comcast.net> Message-ID: <545FD616.7000501@slackware.hr> On 11/08/2014 06:21 PM, Tarpit wrote: > The 14.1 SlackBuild for Postfix 2.11.1 has single quotes enclosing > ${LIBDIRSUFFIX} in two places. The single quotes should be double > quotes. Here are the two lines: > > SASLLIBS='-L/usr/lib${LIBDIRSUFFIX}/sasl2 -lsasl2' ;; > DBLIBS='-L/usr/lib${LIBDIRSUFFIX}/mysql -lmysqlclient -lz -lm' ;; > > > Thanks, > Duane > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - http://slackbuilds.org/faq/ > This was just fixed: http://git.slackbuilds.org/cgit/slackbuilds/commit/?id=4471b1bbe3b3fe9c5ea636ac552b306297d73243 -- Mario From ronayne.thomas at gmail.com Tue Nov 11 11:47:32 2014 From: ronayne.thomas at gmail.com (Thomas Ronayne) Date: Tue, 11 Nov 2014 06:47:32 -0500 Subject: [Slackbuilds-users] A Problem With SlackBuilds tar.gz Files on Download Message-ID: <5461F754.8030905@gmail.com> Hi. For some time I've had a problem (a minor annoyance actually) when I download a SlackBuild file: the file is delivered uncompressed although the file name is still; e.g., /yasm.tar.gz/. That is, it's a tar file. I asked about this at LinuxQuestions: Firefox unzips tar.gz Files on Download and got a couple of replies that look like they may be relevant: starting at Number 11 . Don't know if it's me, you or Memorex but I'd sure like to know if I've got something wrong (and what to do about it). This is the case on all my systems (all Slackware 14.1 stable, fully patched, both 32- and 64-bit and Firefox 31.2.0ESR). Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From willysr at slackbuilds.org Tue Nov 11 12:00:02 2014 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Tue, 11 Nov 2014 19:00:02 +0700 Subject: [Slackbuilds-users] A Problem With SlackBuilds tar.gz Files on Download In-Reply-To: <5461F754.8030905@gmail.com> References: <5461F754.8030905@gmail.com> Message-ID: <5461FA42.1070601@slackbuilds.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/11/2014 06:47 PM, Thomas Ronayne wrote: > Hi. > > For some time I've had a problem (a minor annoyance actually) when > I download a SlackBuild file: the file is delivered uncompressed > although the file name is still; e.g., /yasm.tar.gz/. That is, it's > a tar file. > > I asked about this at LinuxQuestions: Firefox unzips tar.gz Files > on Download > > > and got a couple of replies that look like they may be relevant: > starting at Number 11 > . > > > > Don't know if it's me, you or Memorex but I'd sure like to know if > I've got something wrong (and what to do about it). This is the > case on all my systems (all Slackware 14.1 stable, fully patched, > both 32- and 64-bit and Firefox 31.2.0ESR). i wonder why download old version of yasm for 13.1? it's included in 13.37 i tested the one for 13.1 and it works fine here - -- Willy Sudiarto Raharjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlRh+kIACgkQiHuDdNczM4E7egCaA5O4PT2Gon0dqJHW//vnF4fT qWEAoJb4+b+BfVSt0ohwFlOeN1S8hWyo =MsOV -----END PGP SIGNATURE----- From yalhcru at gmail.com Tue Nov 11 19:10:36 2014 From: yalhcru at gmail.com (B Watson) Date: Tue, 11 Nov 2014 14:10:36 -0500 Subject: [Slackbuilds-users] A Problem With SlackBuilds tar.gz Files on Download In-Reply-To: <5461F754.8030905@gmail.com> References: <5461F754.8030905@gmail.com> Message-ID: On 11/11/14, Thomas Ronayne wrote: > For some time I've had a problem (a minor annoyance actually) when I > download a SlackBuild file: the file is delivered uncompressed although > the file name is still; e.g., /yasm.tar.gz/. That is, it's a tar file. Right-click, "copy link location", switch to an xterm or such, type "wget ", then paste. If you're manually downloading build scripts, you're going to end up using a terminal to extract & run them anyway. Or if you prefer a GUI method, try installing uget. Or, just use sbopkg or sbotools to download/build/install stuff from slackbuilds.org. From kingbeowulf at gmail.com Tue Nov 11 23:15:07 2014 From: kingbeowulf at gmail.com (King Beowulf) Date: Tue, 11 Nov 2014 15:15:07 -0800 Subject: [Slackbuilds-users] A Problem With SlackBuilds tar.gz Files on Download In-Reply-To: References: <5461F754.8030905@gmail.com> Message-ID: On Tuesday, November 11, 2014, B Watson wrote: > On 11/11/14, Thomas Ronayne > > wrote: > > > For some time I've had a problem (a minor annoyance actually) when I > > download a SlackBuild file: the file is delivered uncompressed although > > the file name is still; e.g., /yasm.tar.gz/. That is, it's a tar file. > > Right-click, "copy link location", switch to an xterm or such, type > "wget ", then paste. If you're manually downloading build scripts, > you're going to end up using a terminal to extract & run them anyway. > > Or if you prefer a GUI method, try installing uget. > > Or, just use sbopkg or sbotools to download/build/install stuff from > slackbuilds.org. > > Funny thing is, I don't have any issues using Firefox or other browsers to d/l .tar.gz files ( or Even when I just click the link). Just right click the "download link as", although wget is my preferred method. Maybe the OP has a misconfigured browser? -- You! What PLANET is this! -- McCoy, "The City on the Edge of Forever", stardate 3134.0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgrundy at gmail.com Thu Nov 13 01:34:58 2014 From: bgrundy at gmail.com (Barry Grundy) Date: Wed, 12 Nov 2014 20:34:58 -0500 Subject: [Slackbuilds-users] SlackBuild Ettiquette Message-ID: I maintain a particular package, and it's due for an upgrade. I've been playing with one of the options to the package and Iv'e determined that for my use I would rarely run without that particular option. Is it bad practice to have the SlackBuild enable an option by default? Obviously the README would cover the subject. Basically I'm asking to turn an option into a "requirement". The package in question is bulk_extractor (already in SBo), and the option is liblightgrep (I'll be submitting the new SlackBuild concurrently). The .info would reflect the requirement, and the bulk_extractor README would indicate that the requirement could be disabled by removing "--enable-liblightgrep" from the SlackBuild. Is this kosher(ish)? -------------- next part -------------- An HTML attachment was scrubbed... URL: From kingbeowulf at gmail.com Thu Nov 13 03:16:09 2014 From: kingbeowulf at gmail.com (King Beowulf) Date: Wed, 12 Nov 2014 19:16:09 -0800 Subject: [Slackbuilds-users] SlackBuild Ettiquette In-Reply-To: References: Message-ID: On Wednesday, November 12, 2014, Barry Grundy wrote: > I maintain a particular package, and it's due for an upgrade. I've been > playing with one of the options to the package and Iv'e determined that for > my use I would rarely run without that particular option. > > Is it bad practice to have the SlackBuild enable an option by default? > Obviously the README would cover the subject. Basically I'm asking to turn > an option into a "requirement". > > The package in question is bulk_extractor (already in SBo), and the option > is liblightgrep (I'll be submitting the new SlackBuild concurrently). > > The .info would reflect the requirement, and the bulk_extractor README > would indicate that the requirement could be disabled by removing > "--enable-liblightgrep" from the SlackBuild. > > Is this kosher(ish)? > Why not set up a switch, on/off by default, say, so that the option can be run/not run without editing the script: LLG=yes ./blah.SlackBuild This is done in a number of scripts (JDK, qemu, nvidia, ...) -- You! What PLANET is this! -- McCoy, "The City on the Edge of Forever", stardate 3134.0 -------------- next part -------------- An HTML attachment was scrubbed... URL: From melikamp at melikamp.com Thu Nov 13 03:25:25 2014 From: melikamp at melikamp.com (Ivan Zaigralin) Date: Wed, 12 Nov 2014 19:25:25 -0800 Subject: [Slackbuilds-users] SlackBuild Ettiquette In-Reply-To: References: Message-ID: <546424A5.3010708@melikamp.com> Agreed. For example, I did this in R SlackBuild: if [ "${R_SHLIB:-yes}" = "yes" ]; then r_shlib="--enable-R-shlib" else r_shlib="--disable-R-shlib" fi if [ "${BLAS_SHLIB:-yes}" = "yes" ]; then blas_shlib="--enable-BLAS-shlib" else blas_shlib="--disable-BLAS-shlib" fi and then passed these to configure. I opted to enable them by default after I spoke with R devs and was told that literally nothing can go wrong, and the performance impact is negligible for most practical purposes. How to set the default values is entirely up to you as a maintainer, but I would pay attention to what your users want, as well as KISS. On 11/12/2014 07:16 PM, King Beowulf wrote: > On Wednesday, November 12, 2014, Barry Grundy > wrote: > > I maintain a particular package, and it's due for an upgrade.? I've been > playing with one of the options to the package and Iv'e determined that for > my use I would rarely run without that particular option. > > Is it bad practice to have the SlackBuild enable an option by default? > Obviously the README would cover the subject.? Basically I'm asking to turn > an option into a "requirement". ? > > The package in question is bulk_extractor (already in SBo), and the option > is liblightgrep (I'll be submitting the new SlackBuild concurrently). > > The .info would reflect the requirement, and the bulk_extractor README would > indicate that the requirement could be disabled by removing > "--enable-liblightgrep" from the SlackBuild. ? > > Is this kosher(ish)? > > > Why not set up a switch, on/off by default, say, so that the option can be > run/not run? without editing the script: > > LLG=yes ./blah.SlackBuild > > This is done in a number of scripts (JDK, qemu, nvidia, ...) > > ? > > > -- > You! What PLANET is this! > ? ? -- McCoy, "The City on the Edge of Forever", stardate 3134.0 > > > > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - http://slackbuilds.org/faq/ > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From chris.willing at iinet.net.au Thu Nov 13 04:13:22 2014 From: chris.willing at iinet.net.au (Christoph Willing) Date: Thu, 13 Nov 2014 14:13:22 +1000 Subject: [Slackbuilds-users] SlackBuild Ettiquette In-Reply-To: <546424A5.3010708@melikamp.com> References: <546424A5.3010708@melikamp.com> Message-ID: <54642FE2.1070200@iinet.net.au> For many softwares, optional features are either set or unset by default in the configuration script supplied with the source code. In accordance with the general Slackware practice of leaving upstream alone as far as possible, I would suggest that the default values you choose for options should be whatever are the defaults in the software itself, _not_ what you happen to use yourself. Its quite annoying when SlackBuilds choose options contrary to the upstream defaults. One SlackBuild that springs to mind immediately turns off an option that is on by default just because the maintainer himself doesn't use the facility provided by that option. Having it turned on wouldn't force him to use the facility provided by the option but he's actually added code to the SlackBuild to turn it off anyway. chris On 11/13/2014 01:25 PM, Ivan Zaigralin wrote: > Agreed. For example, I did this in R SlackBuild: > > if [ "${R_SHLIB:-yes}" = "yes" ]; then > r_shlib="--enable-R-shlib" > else > r_shlib="--disable-R-shlib" > fi > if [ "${BLAS_SHLIB:-yes}" = "yes" ]; then > blas_shlib="--enable-BLAS-shlib" > else > blas_shlib="--disable-BLAS-shlib" > fi > > and then passed these to configure. I opted to enable them by default > after I spoke with R devs and was told that literally nothing can go > wrong, and the performance impact is negligible for most practical > purposes. How to set the default values is entirely up to you as a > maintainer, but I would pay attention to what your users want, as well > as KISS. > > On 11/12/2014 07:16 PM, King Beowulf wrote: >> On Wednesday, November 12, 2014, Barry Grundy > > wrote: >> >> I maintain a particular package, and it's due for an upgrade.? I've been >> playing with one of the options to the package and Iv'e determined that for >> my use I would rarely run without that particular option. >> >> Is it bad practice to have the SlackBuild enable an option by default? >> Obviously the README would cover the subject.? Basically I'm asking to turn >> an option into a "requirement". ? >> >> The package in question is bulk_extractor (already in SBo), and the option >> is liblightgrep (I'll be submitting the new SlackBuild concurrently). >> >> The .info would reflect the requirement, and the bulk_extractor README would >> indicate that the requirement could be disabled by removing >> "--enable-liblightgrep" from the SlackBuild. ? >> >> Is this kosher(ish)? >> >> >> Why not set up a switch, on/off by default, say, so that the option can be >> run/not run? without editing the script: >> >> LLG=yes ./blah.SlackBuild >> >> This is done in a number of scripts (JDK, qemu, nvidia, ...) >> >> ? >> >> >> -- >> You! What PLANET is this! >> ? ? -- McCoy, "The City on the Edge of Forever", stardate 3134.0 >> >> >> >> _______________________________________________ >> SlackBuilds-users mailing list >> SlackBuilds-users at slackbuilds.org >> http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users >> Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ >> FAQ - http://slackbuilds.org/faq/ >> > > > > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - http://slackbuilds.org/faq/ > From melikamp at melikamp.com Thu Nov 13 04:34:40 2014 From: melikamp at melikamp.com (Ivan Zaigralin) Date: Wed, 12 Nov 2014 20:34:40 -0800 Subject: [Slackbuilds-users] SlackBuild Ettiquette In-Reply-To: <54642FE2.1070200@iinet.net.au> References: <546424A5.3010708@melikamp.com> <54642FE2.1070200@iinet.net.au> Message-ID: <546434E0.4040501@melikamp.com> I agree completely. However, in rare instances the options should or must be tweaked. Just look at the official firefox build, for example. In my case, I personally do NOT use the cited options, and I enabled them after much mulling over, after multiple users requested them. I think I could have been more cautious, but for what end? No one complained so far. I am curious, what is that package that "springs to mind"? On 11/12/2014 08:13 PM, Christoph Willing wrote: > For many softwares, optional features are either set or unset by default in the > configuration script supplied with the source code. In accordance with the > general Slackware practice of leaving upstream alone as far as possible, I would > suggest that the default values you choose for options should be whatever are > the defaults in the software itself, _not_ what you happen to use yourself. > > Its quite annoying when SlackBuilds choose options contrary to the upstream > defaults. One SlackBuild that springs to mind immediately turns off an option > that is on by default just because the maintainer himself doesn't use the > facility provided by that option. Having it turned on wouldn't force him to use > the facility provided by the option but he's actually added code to the > SlackBuild to turn it off anyway. > > chris > > > On 11/13/2014 01:25 PM, Ivan Zaigralin wrote: >> Agreed. For example, I did this in R SlackBuild: >> >> if [ "${R_SHLIB:-yes}" = "yes" ]; then >> r_shlib="--enable-R-shlib" >> else >> r_shlib="--disable-R-shlib" >> fi >> if [ "${BLAS_SHLIB:-yes}" = "yes" ]; then >> blas_shlib="--enable-BLAS-shlib" >> else >> blas_shlib="--disable-BLAS-shlib" >> fi >> >> and then passed these to configure. I opted to enable them by default >> after I spoke with R devs and was told that literally nothing can go >> wrong, and the performance impact is negligible for most practical >> purposes. How to set the default values is entirely up to you as a >> maintainer, but I would pay attention to what your users want, as well >> as KISS. >> >> On 11/12/2014 07:16 PM, King Beowulf wrote: >>> On Wednesday, November 12, 2014, Barry Grundy >> > wrote: >>> >>> I maintain a particular package, and it's due for an upgrade.? I've been >>> playing with one of the options to the package and Iv'e determined that for >>> my use I would rarely run without that particular option. >>> >>> Is it bad practice to have the SlackBuild enable an option by default? >>> Obviously the README would cover the subject.? Basically I'm asking to >>> turn >>> an option into a "requirement". ? >>> >>> The package in question is bulk_extractor (already in SBo), and the option >>> is liblightgrep (I'll be submitting the new SlackBuild concurrently). >>> >>> The .info would reflect the requirement, and the bulk_extractor README >>> would >>> indicate that the requirement could be disabled by removing >>> "--enable-liblightgrep" from the SlackBuild. ? >>> >>> Is this kosher(ish)? >>> >>> >>> Why not set up a switch, on/off by default, say, so that the option can be >>> run/not run? without editing the script: >>> >>> LLG=yes ./blah.SlackBuild >>> >>> This is done in a number of scripts (JDK, qemu, nvidia, ...) >>> >>> ? >>> >>> >>> -- >>> You! What PLANET is this! >>> ? ? -- McCoy, "The City on the Edge of Forever", stardate 3134.0 >>> >>> >>> >>> _______________________________________________ >>> SlackBuilds-users mailing list >>> SlackBuilds-users at slackbuilds.org >>> http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users >>> Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ >>> FAQ - http://slackbuilds.org/faq/ >>> >> >> >> >> _______________________________________________ >> SlackBuilds-users mailing list >> SlackBuilds-users at slackbuilds.org >> http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users >> Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ >> FAQ - http://slackbuilds.org/faq/ >> > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - http://slackbuilds.org/faq/ > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From chris.willing at iinet.net.au Thu Nov 13 06:09:57 2014 From: chris.willing at iinet.net.au (Christoph Willing) Date: Thu, 13 Nov 2014 16:09:57 +1000 Subject: [Slackbuilds-users] SlackBuild Ettiquette In-Reply-To: <546434E0.4040501@melikamp.com> References: <546424A5.3010708@melikamp.com> <54642FE2.1070200@iinet.net.au> <546434E0.4040501@melikamp.com> Message-ID: <54644B35.9090400@iinet.net.au> For sure, options need tweaking occasionally; there are often good reasons (including public demand) for it. However I'm against changing them just to satisfy some personal world view of the maintainer e.g. "users of this package shouldn't build in the optional sudo plugin" (a completely contrived example). I don't want to name names - the particular issue I'm thinking of was discussed briefly on this list already about six months ago and there's little point rehashing the same arguments. In all fairness, I should say that the maintainer offered to revert to vanilla if enough people wanted; I guess not enough people complained. chris On 11/13/2014 02:34 PM, Ivan Zaigralin wrote: > I agree completely. However, in rare instances the options should or must be > tweaked. Just look at the official firefox build, for example. In my case, > I personally do NOT use the cited options, and I enabled them after much > mulling over, after multiple users requested them. I think I could have > been more cautious, but for what end? No one complained so far. > > I am curious, what is that package that "springs to mind"? > > On 11/12/2014 08:13 PM, Christoph Willing wrote: >> For many softwares, optional features are either set or unset by default in the >> configuration script supplied with the source code. In accordance with the >> general Slackware practice of leaving upstream alone as far as possible, I would >> suggest that the default values you choose for options should be whatever are >> the defaults in the software itself, _not_ what you happen to use yourself. >> >> Its quite annoying when SlackBuilds choose options contrary to the upstream >> defaults. One SlackBuild that springs to mind immediately turns off an option >> that is on by default just because the maintainer himself doesn't use the >> facility provided by that option. Having it turned on wouldn't force him to use >> the facility provided by the option but he's actually added code to the >> SlackBuild to turn it off anyway. >> >> chris >> >> >> On 11/13/2014 01:25 PM, Ivan Zaigralin wrote: >>> Agreed. For example, I did this in R SlackBuild: >>> >>> if [ "${R_SHLIB:-yes}" = "yes" ]; then >>> r_shlib="--enable-R-shlib" >>> else >>> r_shlib="--disable-R-shlib" >>> fi >>> if [ "${BLAS_SHLIB:-yes}" = "yes" ]; then >>> blas_shlib="--enable-BLAS-shlib" >>> else >>> blas_shlib="--disable-BLAS-shlib" >>> fi >>> >>> and then passed these to configure. I opted to enable them by default >>> after I spoke with R devs and was told that literally nothing can go >>> wrong, and the performance impact is negligible for most practical >>> purposes. How to set the default values is entirely up to you as a >>> maintainer, but I would pay attention to what your users want, as well >>> as KISS. >>> >>> On 11/12/2014 07:16 PM, King Beowulf wrote: >>>> On Wednesday, November 12, 2014, Barry Grundy >>> > wrote: >>>> >>>> I maintain a particular package, and it's due for an upgrade.? I've been >>>> playing with one of the options to the package and Iv'e determined that for >>>> my use I would rarely run without that particular option. >>>> >>>> Is it bad practice to have the SlackBuild enable an option by default? >>>> Obviously the README would cover the subject.? Basically I'm asking to >>>> turn >>>> an option into a "requirement". ? >>>> >>>> The package in question is bulk_extractor (already in SBo), and the option >>>> is liblightgrep (I'll be submitting the new SlackBuild concurrently). >>>> >>>> The .info would reflect the requirement, and the bulk_extractor README >>>> would >>>> indicate that the requirement could be disabled by removing >>>> "--enable-liblightgrep" from the SlackBuild. ? >>>> >>>> Is this kosher(ish)? >>>> >>>> >>>> Why not set up a switch, on/off by default, say, so that the option can be >>>> run/not run? without editing the script: >>>> >>>> LLG=yes ./blah.SlackBuild >>>> >>>> This is done in a number of scripts (JDK, qemu, nvidia, ...) >>>> >>>> ? >>>> >>>> >>>> -- >>>> You! What PLANET is this! >>>> ? ? -- McCoy, "The City on the Edge of Forever", stardate 3134.0 >>>> >>>> >>>> >>>> _______________________________________________ >>>> SlackBuilds-users mailing list >>>> SlackBuilds-users at slackbuilds.org >>>> http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users >>>> Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ >>>> FAQ - http://slackbuilds.org/faq/ >>>> >>> >>> >>> >>> _______________________________________________ >>> SlackBuilds-users mailing list >>> SlackBuilds-users at slackbuilds.org >>> http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users >>> Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ >>> FAQ - http://slackbuilds.org/faq/ >>> >> _______________________________________________ >> SlackBuilds-users mailing list >> SlackBuilds-users at slackbuilds.org >> http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users >> Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ >> FAQ - http://slackbuilds.org/faq/ >> > > > > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - http://slackbuilds.org/faq/ > From melikamp at melikamp.com Thu Nov 13 06:25:54 2014 From: melikamp at melikamp.com (Ivan Zaigralin) Date: Wed, 12 Nov 2014 22:25:54 -0800 Subject: [Slackbuilds-users] SlackBuild Ettiquette In-Reply-To: <54644B35.9090400@iinet.net.au> References: <546424A5.3010708@melikamp.com> <54642FE2.1070200@iinet.net.au> <546434E0.4040501@melikamp.com> <54644B35.9090400@iinet.net.au> Message-ID: <54644EF2.2020206@melikamp.com> Indeed. Vanilla is my favorite flavor, and in my case I would revert to it if only a single user complained. Going back to OP, > Iv'e determined that for my use I would rarely run without that > particular option IMHO (and I speak as someone who doesn't know the first thing about bulk_extractor) this is not quite enough either. On 11/12/2014 10:09 PM, Christoph Willing wrote: > For sure, options need tweaking occasionally; there are often good reasons > (including public demand) for it. However I'm against changing them just to > satisfy some personal world view of the maintainer e.g. "users of this package > shouldn't build in the optional sudo plugin" (a completely contrived example). > > I don't want to name names - the particular issue I'm thinking of was discussed > briefly on this list already about six months ago and there's little point > rehashing the same arguments. In all fairness, I should say that the maintainer > offered to revert to vanilla if enough people wanted; I guess not enough people > complained. > > chris -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From bocke at mycity.rs Thu Nov 13 09:00:03 2014 From: bocke at mycity.rs (Bojan Popovic) Date: Thu, 13 Nov 2014 10:00:03 +0100 Subject: [Slackbuilds-users] SlackBuild Ettiquette In-Reply-To: <54642FE2.1070200@iinet.net.au> References: <546424A5.3010708@melikamp.com> <54642FE2.1070200@iinet.net.au> Message-ID: <20141113100003.44e087ac@artwo.universe.uni> Hi. Well that's why many SlackBuilds have optional switches. You can choose whatever you want from the command line OPT1=YES OPT2=NO ./package.SlackBuild or in a sbopkg queuefile: package | OPT1=YES OPT2=NO In there are optional switches, then it's not really important what defaults the maintainer chose. My 2,5 cents. Bojan. On Thu, 13 Nov 2014 14:13:22 +1000 Christoph Willing wrote: > For many softwares, optional features are either set or unset by > default in the configuration script supplied with the source code. In > accordance with the general Slackware practice of leaving upstream > alone as far as possible, I would suggest that the default values you > choose for options should be whatever are the defaults in the > software itself, _not_ what you happen to use yourself. > > Its quite annoying when SlackBuilds choose options contrary to the > upstream defaults. One SlackBuild that springs to mind immediately > turns off an option that is on by default just because the maintainer > himself doesn't use the facility provided by that option. Having it > turned on wouldn't force him to use the facility provided by the > option but he's actually added code to the SlackBuild to turn it off > anyway. > > chris > From bocke at mycity.rs Thu Nov 13 09:08:42 2014 From: bocke at mycity.rs (Bojan Popovic) Date: Thu, 13 Nov 2014 10:08:42 +0100 Subject: [Slackbuilds-users] SlackBuild Ettiquette In-Reply-To: <20141113100003.44e087ac@artwo.universe.uni> References: <546424A5.3010708@melikamp.com> <54642FE2.1070200@iinet.net.au> <20141113100003.44e087ac@artwo.universe.uni> Message-ID: <20141113100842.45a94dd2@artwo.universe.uni> Hi. > In there are optional switches, then it's not really important what > defaults the maintainer chose. > If* > My 2,5 cents. Let's round that to 3. :) Bojan. From chris.willing at iinet.net.au Thu Nov 13 10:48:35 2014 From: chris.willing at iinet.net.au (Christoph Willing) Date: Thu, 13 Nov 2014 20:48:35 +1000 Subject: [Slackbuilds-users] SlackBuild Ettiquette In-Reply-To: <20141113100003.44e087ac@artwo.universe.uni> References: <546424A5.3010708@melikamp.com> <54642FE2.1070200@iinet.net.au> <20141113100003.44e087ac@artwo.universe.uni> Message-ID: <54648C83.9060804@iinet.net.au> Yes we know SlackBuilds have switches to set options. What I was referring to below was that these switches have default settings which shouldn't be arbitrarily manipulated. At the first level, before those SlackBuild switches, an option's default is set by the upstream developers - a particular option might be set on or off but can be overridden when running the configure script with something like: --enable-xyz (or --disable-xyz) At the second level are the options set by switches in the SlackBuilds - the one's you describe below. These are precisely the options we're already discussing; in particular what should these options default to? As you probably know, the SlackBuilds themselves will contain (for the example you give below) something like: OPT1=${OPT1:-NO} i.e. at this level, the maintainer has made "NO" the default, which the user must override at the command line with: OPT1=YES ./package.SlackBuild What is (I believe) contentious is when the maintainer explicitly changes an option's default from what was set by the upstream developers. If OPT1 (whatever option it represents) would normally default to "on" if the configure script was run without explicitly setting it to on or off, then I don't think its right (in general) for the maintainer to impose a different default. In this case, the SlackBuild should say: OPT1=${OPT1:-YES} and leave it to those users who don't want the option enabled to say: OPT1=NO ./package.SlackBuild chris On 11/13/2014 07:00 PM, Bojan Popovic wrote: > Hi. > > Well that's why many SlackBuilds have optional switches. You can choose > whatever you want from the command line > > OPT1=YES OPT2=NO ./package.SlackBuild > > or in a sbopkg queuefile: > > package | OPT1=YES OPT2=NO > > In there are optional switches, then it's not really important what > defaults the maintainer chose. > > My 2,5 cents. > > Bojan. > > On Thu, 13 Nov 2014 14:13:22 +1000 > Christoph Willing wrote: > >> For many softwares, optional features are either set or unset by >> default in the configuration script supplied with the source code. In >> accordance with the general Slackware practice of leaving upstream >> alone as far as possible, I would suggest that the default values you >> choose for options should be whatever are the defaults in the >> software itself, _not_ what you happen to use yourself. >> >> Its quite annoying when SlackBuilds choose options contrary to the >> upstream defaults. One SlackBuild that springs to mind immediately >> turns off an option that is on by default just because the maintainer >> himself doesn't use the facility provided by that option. Having it >> turned on wouldn't force him to use the facility provided by the >> option but he's actually added code to the SlackBuild to turn it off >> anyway. >> >> chris >> > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - http://slackbuilds.org/faq/ > > From bgrundy at gmail.com Thu Nov 13 12:01:42 2014 From: bgrundy at gmail.com (Barry Grundy) Date: Thu, 13 Nov 2014 07:01:42 -0500 Subject: [Slackbuilds-users] SlackBuild Ettiquette In-Reply-To: <54642FE2.1070200@iinet.net.au> References: <546424A5.3010708@melikamp.com> <54642FE2.1070200@iinet.net.au> Message-ID: Excellent responses, and all much appreciated. I'll look through some of the examples King Beowulf cited and go that route. On Wed, Nov 12, 2014 at 11:13 PM, Christoph Willing < chris.willing at iinet.net.au> wrote: > In accordance with the general Slackware practice of leaving upstream > alone as far as possible, I would suggest that the default values you > choose for options should be whatever are the defaults in the software > itself, _not_ what you happen to use yourself. > > Its quite annoying when SlackBuilds choose options contrary to the > upstream defaults. > This is the sort of thing I was looking for. I appreciate the explanation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bocke at mycity.rs Thu Nov 13 12:13:04 2014 From: bocke at mycity.rs (Bojan Popovic) Date: Thu, 13 Nov 2014 13:13:04 +0100 Subject: [Slackbuilds-users] SlackBuild Ettiquette In-Reply-To: <54648C83.9060804@iinet.net.au> References: <546424A5.3010708@melikamp.com> <54642FE2.1070200@iinet.net.au> <20141113100003.44e087ac@artwo.universe.uni> <54648C83.9060804@iinet.net.au> Message-ID: <20141113131304.42b26ca4@artwo.universe.uni> Hi. I agree to some point, but that won't happen unless admins start enforcing that policy and I don't see that happenning knowing how busy they can be. I think the bigger problem would be the packages that don't give the possibility of reverting the maintainer's choices (there are some). For example: without switchable options. Bojan. On Thu, 13 Nov 2014 20:48:35 +1000 Christoph Willing wrote: > What I was referring to below was that these switches have default settings > which shouldn't be arbitrarily manipulated. From ryanpcmcquen at gmail.com Thu Nov 13 14:33:54 2014 From: ryanpcmcquen at gmail.com (Ryan P.C. McQuen) Date: Thu, 13 Nov 2014 06:33:54 -0800 Subject: [Slackbuilds-users] SlackBuild Ettiquette In-Reply-To: <20141113131304.42b26ca4@artwo.universe.uni> References: <546424A5.3010708@melikamp.com> <54642FE2.1070200@iinet.net.au> <20141113100003.44e087ac@artwo.universe.uni> <54648C83.9060804@iinet.net.au> <20141113131304.42b26ca4@artwo.universe.uni> Message-ID: <5F461B71-7ECC-48DB-985C-6C45E795F086@gmail.com> > What I was referring to below was that these switches have default settings > which shouldn't be arbitrarily manipulated. Please let me know if any of my builds are this way, I want to keep things as vanilla as possible. ;^) --- On Nov 13, 2014, at 4:13 AM, Bojan Popovic wrote: >> What I was referring to below was that these switches have default settings >> which shouldn't be arbitrarily manipulated. > ______________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From klaatu at straightedgelinux.com Fri Nov 14 06:43:38 2014 From: klaatu at straightedgelinux.com (Klaatu) Date: Fri, 14 Nov 2014 19:43:38 +1300 Subject: [Slackbuilds-users] SlackBuild Ettiquette In-Reply-To: <5F461B71-7ECC-48DB-985C-6C45E795F086@gmail.com> References: <546424A5.3010708@melikamp.com> <54642FE2.1070200@iinet.net.au> <20141113100003.44e087ac@artwo.universe.uni> <54648C83.9060804@iinet.net.au> <20141113131304.42b26ca4@artwo.universe.uni> <5F461B71-7ECC-48DB-985C-6C45E795F086@gmail.com> Message-ID: <5465A49A.5080407@straightedgelinux.com> On 11/14/2014 03:33 AM, Ryan P.C. McQuen wrote: >> What I was referring to below was that these switches have default >> settings >> which shouldn't be arbitrarily manipulated. > > Please let me know if any of my builds are this way, I want to keep > things as vanilla as possible. ;^) > > --- > > > > On Nov 13, 2014, at 4:13 AM, Bojan Popovic > wrote: > >>> What I was referring to below was that these switches have default >>> settings >>> which shouldn't be arbitrarily manipulated. >>> >> ______________ > > > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - http://slackbuilds.org/faq/ > Agreed. If there are any packages that I maintain that are not vanilla, I'd prefer to have names named and packages cited. I wouldn't take it as an insult, I'd just like to know if someone has other ideas of how to package something. - klaatu From willysr at slackbuilds.org Sat Nov 15 01:44:55 2014 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sat, 15 Nov 2014 08:44:55 +0700 Subject: [Slackbuilds-users] Updates - 20141115.1 Message-ID: <5466B017.7070407@slackbuilds.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sat Nov 15 01:32:08 UTC 2014 audio/clam_annotator: fix .info. audio/clam_voice2midi: fix .info and slack-desc. audio/fantasia: fix .info. audio/fluidsynth-dssi: fix .info. audio/ghostess: fix .info. audio/gqradio: Add patches. audio/horgand: fix .info. audio/jack-rack: fix .info. audio/jackmeter: fix .info. audio/lmms: Updated for version 1.0.3. audio/minimodem: Updated for version 0.20. audio/nnls-chroma: fix .info. audio/qmidiroute: fix slack-desc. audio/tap_plugins: fix slack-desc. audio/vocoder-ladspa: fix .info. audio/waon: fix .info and slack-desc. desktop/j4-dmenu-desktop: fix .info. desktop/peksystray: fix .info. desktop/wmmon: fix script. development/THE: Updated for version 3.3RC4. development/dbeaver: Added (a universal database tool). development/nvi: New maintainer + patch DB. development/radare2: Updated for version 0.9.8. development/srecord: fix .info. games/arnold-cpc: Fix homepage. games/dolphin-emu: Update DEPS and README. games/ds-models: fix .info. games/dungeon: fix .info. games/foobillardplus: Updated for version 3.43beta. games/frotz: fix .info. games/glbsp: fix slack-desc. games/gtkballs: fix slack-desc. games/icebreaker: fix .desktop. games/madbomber: fix .desktop. games/micropolis: fix slack-desc. games/nexuiz: fix slack-desc. games/pom1: fix .info. games/skulltag: fix slack-desc. games/steem: Update script. games/tome4: Updated for version 1.2.5. games/typhoon_2001: fix slack-desc and script. games/ucr: fix .info. games/wolf4sdl: fix .info. games/zork: fix .info. games/zsnes: fix .info and .desktop. gis/geopy: Updated for version 1.4.0. graphics/digikam: Updated for version 4.5.0. libraries/GitPython: Updated for version 0.3.2. libraries/dbus-sharp-glib: Updated for version 0.6. libraries/dbus-sharp: Updated for version 0.8.1. libraries/fltk13: Updated for version 1.3.3. libraries/gitdb: Updated for version 0.6.0. libraries/gtk-sharp: Updated for version 2.12.27. libraries/hoedown: Added (Markdown library). libraries/liblightgrep: Added (forensic regexp engine). libraries/libsmf: fix .info. libraries/libtorrent: Fix build on x86. libraries/live555: Updated for version 2014.11.12. libraries/mysql-connector-python: Updated for version 2.0.2. libraries/ogre: Updated for version 1.9. libraries/smmap: Updated for version 0.8.3. misc/xca: Updated for version 1.0.0. multimedia/flashplayer-plugin: Updated for version 11.2.202.418. multimedia/mediainfo-gui: Updated for version 0.7.70. multimedia/mediainfo: Updated for version 0.7.70. multimedia/mtpfs: fix .info. multimedia/nted: fix slack-desc. multimedia/youtube-viewer: fix .info. network/deis: Updated for version 1.0.0. network/flexget: Updated for version 1.2.220. network/glassfish: Updated for version 4.1 + new maintainer. network/hiawatha: Updated for version 9.8. network/hostapd: Updated for version 2.3. network/livestreamer-curses: Updated for version 1.4.0. network/nzbget: Updated for version 14.0. network/p0f: Updated for version 3.08b. network/postfix: Updated for version 2.11.3. network/quassel: Updated for version 0.10.1. network/rtorrent: Fix build on x86. network/surf: fix .info. network/tor-browser: Added (tor-based browser) network/uwsgi: Updated for version 2.0.8. network/yturl: fix .info. office/CherryTree: Updated for version 0.35.4. office/NME: Added (Nyctergatis Markup Engine). office/libreoffice-helppack: Updated for version 4.3.4. office/libreoffice-langpack: Updated for version 4.3.4. office/libreoffice: Updated for version 4.3.4. office/qpdfview: Updated for version 0.4.12. office/zathura-cb: fix .info. office/zathura-djvu: fix .info. perl/perl-Module-Build-Tiny: Updated for version 0.039. perl/perl-Moo: Updated for version 1.006001. perl/perl-Role-Tiny: Updated for version 1.003004. perl/perl-Test-MockObject: Added (interface emulation extension). perl/perl-data-dump: fix .info. python/argcomplete: Updated for version 0.8.3. python/guessit: Updated for version 0.9.4. python/hg-git: Updated for version 0.7.0. python/hgsubversion: Updated for version 1.7. python/python-libnacl: Added (Python binding for libsodium). python/regex: Updated for version 2014.11.13. system/asbt: Updated for version 0.9.9. system/bulk_extractor: Updated for version 1.5.5. system/caprice32: Added (CPC Emulator). system/drbd-tools: Removed (replaced by drbd-utils). system/drbd-utils: Added (Management utilities for DRBD). system/fr: Updated for version 1.24. system/gtk-vnc: Apply permission-fixing just to the sources. system/isight-firmware-tools: Fix typo and add README.SLACKWARE. system/multipath-tools: Added (Device Mapper multipath driver). system/sakura: Updated for version 3.1.5. system/vbindiff: Fix segfault. system/xbattmon: Added (simple battery status bar). system/xen: Local attach support for PHY backends using scripts +--------------------------+ - -- Willy Sudiarto Raharjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlRmsBcACgkQiHuDdNczM4HKyQCeOo37vxdbWa3dr/fy/Qa6VG4c /vAAn2gFWbFfjYl8Tt5dzBUdr0+EyESg =HDWq -----END PGP SIGNATURE----- From yenikf at gmail.com Sat Nov 15 08:37:32 2014 From: yenikf at gmail.com (Jan Feific) Date: Sat, 15 Nov 2014 09:37:32 +0100 Subject: [Slackbuilds-users] QtCurve-{Gtk2,KDE4} md5sum check fails Message-ID: <546710CC.2060909@gmail.com> Hi, the title says it all, really. These two builds fail on md5sum checks: ======================================================= ======================================================= Processing QtCurve-Gtk2 QtCurve-Gtk2: QtCurve-Gtk2 not found in /var/cache/sbopkg. --2014-11-15 09:01:46-- http://craigd.wikispaces.com/file/view/QtCurve-Gtk2-1.8.15.tar.bz2 Resolving craigd.wikispaces.com (craigd.wikispaces.com)... 75.126.104.177, 208.43.192.33 Connecting to craigd.wikispaces.com (craigd.wikispaces.com)|75.126.104.177|:80... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] Saving to: ?QtCurve-Gtk2-1.8.15.tar.bz2? [ <=> ] 33,423 46.4KB/s in 0.7s 2014-11-15 09:01:47 (46.4 KB/s) - ?QtCurve-Gtk2-1.8.15.tar.bz2? saved [33423] Found QtCurve-Gtk2-1.8.15.tar.bz2 in /var/cache/sbopkg. Checking MD5SUM: MD5SUM check for QtCurve-Gtk2-1.8.15.tar.bz2 ... FAILED! Expected: 00054b1923f995fa55e0573730b9f3a6 Found: 27086939728ae70cf65ba29fe6e88db4 Do you want to use the downloaded QtCurve-Gtk2 source: QtCurve-Gtk2-1.8.15.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; or - (R)etry download and continue the build process. (Y)es, (N)o, (R)etry?: ======================================================= Processing QtCurve-KDE4 QtCurve-KDE4: QtCurve-KDE4 not found in /var/cache/sbopkg. --2014-11-15 09:02:09-- http://craigd.wikispaces.com/file/view/QtCurve-KDE4-1.8.14.tar.bz2 Resolving craigd.wikispaces.com (craigd.wikispaces.com)... 208.43.192.33, 75.126.104.177 Connecting to craigd.wikispaces.com (craigd.wikispaces.com)|208.43.192.33|:80... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/html] Saving to: ?QtCurve-KDE4-1.8.14.tar.bz2? [ <=> ] 22,498 42.4KB/s in 0.5s 2014-11-15 09:02:11 (42.4 KB/s) - ?QtCurve-KDE4-1.8.14.tar.bz2? saved [22498] Found QtCurve-KDE4-1.8.14.tar.bz2 in /var/cache/sbopkg. Checking MD5SUM: MD5SUM check for QtCurve-KDE4-1.8.14.tar.bz2 ... FAILED! Expected: b4d7924806058f39e842ce7ffe47a4f8 Found: 006486f614540d092b0e1ce8da3d19a2 Do you want to use the downloaded QtCurve-KDE4 source: QtCurve-KDE4-1.8.14.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; or - (R)etry download and continue the build process. (Y)es, (N)o, (R)etry?: ======================================================= From matteo.bernardini at gmail.com Sat Nov 15 08:51:01 2014 From: matteo.bernardini at gmail.com (Matteo Bernardini) Date: Sat, 15 Nov 2014 09:51:01 +0100 Subject: [Slackbuilds-users] QtCurve-{Gtk2,KDE4} md5sum check fails In-Reply-To: <546710CC.2060909@gmail.com> References: <546710CC.2060909@gmail.com> Message-ID: try loading the links in a browser, like this for example http://craigd.wikispaces.com/file/view/QtCurve-KDE4-1.8.14.tar.bz2 I have the original sources and self host them (I'll fix the download links too) http://ponce.cc/slackware/sources/repo/QtCurve-Gtk2-1.8.15.tar.bz2 http://ponce.cc/slackware/sources/repo/QtCurve-KDE4-1.8.14.tar.bz2 remove the downloaded files you got in /var/cache/sbopkg, download these there instead and relaunch sbopkg. Matteo From yenikf at gmail.com Sat Nov 15 09:01:44 2014 From: yenikf at gmail.com (Jan Feific) Date: Sat, 15 Nov 2014 10:01:44 +0100 Subject: [Slackbuilds-users] QtCurve-{Gtk2,KDE4} md5sum check fails In-Reply-To: References: <546710CC.2060909@gmail.com> Message-ID: <54671678.1000101@gmail.com> The craigd.wikispaces.com website says "Subscription Expired", so the site is probably dead. I can confirm that the tarballs from your site build well, though. Thanks, yf On 11/15/2014 09:51 AM, Matteo Bernardini wrote: > try loading the links in a browser, like this for example > > http://craigd.wikispaces.com/file/view/QtCurve-KDE4-1.8.14.tar.bz2 > > I have the original sources and self host them (I'll fix the download links too) > > http://ponce.cc/slackware/sources/repo/QtCurve-Gtk2-1.8.15.tar.bz2 > http://ponce.cc/slackware/sources/repo/QtCurve-KDE4-1.8.14.tar.bz2 > > remove the downloaded files you got in /var/cache/sbopkg, download > these there instead and relaunch sbopkg. > > Matteo > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - http://slackbuilds.org/faq/ > From artourter at gmail.com Sat Nov 15 12:28:04 2014 From: artourter at gmail.com (Greg' Ar Tourter) Date: Sat, 15 Nov 2014 12:28:04 +0000 Subject: [Slackbuilds-users] QtCurve-{Gtk2,KDE4} md5sum check fails In-Reply-To: <54671678.1000101@gmail.com> References: <546710CC.2060909@gmail.com> <54671678.1000101@gmail.com> Message-ID: it appears that the original maintainer has dropped the project, from the discussion on kdelooks he says: "I no longer actively use, nor maintain, QtCurve. However, there is a project (on GitHub, or projects.kde.org) that is continuing QtCurve development. I suggest you send this patch there." I will investigate the project he is referring to and submit a new build. In the meantime, thanks Mateo for hosting the original sources. Cheers On 15 November 2014 09:01, Jan Feific wrote: > > The craigd.wikispaces.com website says "Subscription Expired", so the > site is probably dead. I can confirm that the tarballs from your site build > well, though. > Thanks, > > yf > > > > On 11/15/2014 09:51 AM, Matteo Bernardini wrote: > >> try loading the links in a browser, like this for example >> >> http://craigd.wikispaces.com/file/view/QtCurve-KDE4-1.8.14.tar.bz2 >> >> I have the original sources and self host them (I'll fix the download >> links too) >> >> http://ponce.cc/slackware/sources/repo/QtCurve-Gtk2-1.8.15.tar.bz2 >> http://ponce.cc/slackware/sources/repo/QtCurve-KDE4-1.8.14.tar.bz2 >> >> remove the downloaded files you got in /var/cache/sbopkg, download >> these there instead and relaunch sbopkg. >> >> Matteo >> _______________________________________________ >> SlackBuilds-users mailing list >> SlackBuilds-users at slackbuilds.org >> http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users >> Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ >> FAQ - http://slackbuilds.org/faq/ >> >> _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - http://slackbuilds.org/faq/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jim.Diamond at acadiau.ca Sat Nov 15 17:52:33 2014 From: Jim.Diamond at acadiau.ca (Jim Diamond) Date: Sat, 15 Nov 2014 13:52:33 -0400 Subject: [Slackbuilds-users] qpdfview (0.5.12) is really 0.4.12 Message-ID: <20141115175233.GA24124@tux.acadiau.ca> Hi all, http://slackbuilds.org/repository/14.1/office/qpdfview/?search=qpdfview says there is 0.5.12 but the source download points to 0.4.12. Cheers. Jim From willysr at slackbuilds.org Sat Nov 15 18:04:44 2014 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sun, 16 Nov 2014 01:04:44 +0700 Subject: [Slackbuilds-users] qpdfview (0.5.12) is really 0.4.12 In-Reply-To: <20141115175233.GA24124@tux.acadiau.ca> References: <20141115175233.GA24124@tux.acadiau.ca> Message-ID: <546795BC.5030809@slackbuilds.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > http://slackbuilds.org/repository/14.1/office/qpdfview/?search=qpdfview > > says there is 0.5.12 but the source download points to 0.4.12. Thanks Fixed on my branch - -- Willy Sudiarto Raharjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlRnlbsACgkQiHuDdNczM4EwfACeNqWYED+a0DrA7D95LStL0JdX YrgAnjo75y7IeG5elB1E/LO5GQly6dZ5 =NT3T -----END PGP SIGNATURE----- From zacts.3.14159 at gmail.com Sat Nov 15 21:23:49 2014 From: zacts.3.14159 at gmail.com (Zachary Storer) Date: Sat, 15 Nov 2014 14:23:49 -0700 Subject: [Slackbuilds-users] [PATCH 1/1] Update mksh to 50d. Message-ID: <1416086629-25324-1-git-send-email-zacts.3.14159@gmail.com> --- system/mksh/mksh.SlackBuild | 2 +- system/mksh/mksh.info | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/system/mksh/mksh.SlackBuild b/system/mksh/mksh.SlackBuild index 2fb4fb6..c5fb3a1 100644 --- a/system/mksh/mksh.SlackBuild +++ b/system/mksh/mksh.SlackBuild @@ -26,7 +26,7 @@ # Markus Reichelt, slackbuilds at mareichelt.de, 0xCCEEF115 PRGNAM=mksh -VERSION=${VERSION:-R50b} +VERSION=${VERSION:-R50d} BUILD=${BUILD:-1} TAG=${TAG:-_SBo} diff --git a/system/mksh/mksh.info b/system/mksh/mksh.info index d56e7b6..f8347c6 100644 --- a/system/mksh/mksh.info +++ b/system/mksh/mksh.info @@ -1,8 +1,8 @@ PRGNAM="mksh" -VERSION="R50b" +VERSION="R50d" HOMEPAGE="http://mirbsd.de/mksh" -DOWNLOAD="http://www.mirbsd.org/MirOS/dist/mir/mksh/mksh-R50b.tgz" -MD5SUM="1821a40dacc44293d7325c6021952b69" +DOWNLOAD="http://www.mirbsd.org/MirOS/dist/mir/mksh/mksh-R50d.tgz" +MD5SUM="1c3882c07a760b23df1ad94ad0b4ed2e" DOWNLOAD_x86_64="" MD5SUM_x86_64="" REQUIRES="" -- 1.8.4 From thomas at beingboiled.info Sun Nov 16 01:03:50 2014 From: thomas at beingboiled.info (Thomas Morper) Date: Sun, 16 Nov 2014 02:03:50 +0100 (CET) Subject: [Slackbuilds-users] qemu annotations Message-ID: Hello there, I've had a closer look at the qemu SlackBuild and now I'm wondering about some of the constructs in there. The checks for libusb, spice and usbredir seem to be completely redundant because qemu's configure will check for availability of these features and enable them when possible. The check for the device tree compiler seems to be even more than redundant, because this isn't even an optional depedency as the dtc has been bundled with qemu since at least version 2.0.0. Most configure options just state the defaults. The OS_CFLAGS parameter is probably meaningless; it's not used anywhere in the makefiles. A propos make... to get a parallel build (e.g. with MAKEFLAGS=-j4) you have to "make config-all-devices.mak config-all-disas.mak" first, otherwise "make" will run a single job only which will take quite a while when building all targets (anybody with a better understanding of "make" care to explain?). Maybe the qemu SlackBuild should get a cleanup (and an update to 2.1.2). Cheers! -- From hba.nihilismus at gmail.com Sun Nov 16 03:09:26 2014 From: hba.nihilismus at gmail.com (=?UTF-8?Q?Antonio_Hern=C3=A1ndez_Blas?=) Date: Sat, 15 Nov 2014 21:09:26 -0600 Subject: [Slackbuilds-users] qemu annotations In-Reply-To: References: Message-ID: Hi Thomas. Two weeks ago, i sent the next message to the current maintainer, no response so far: Hi Edward, i'm writing you to suggest the dropping of esd from qemu.SlackBuild (--audio-drv-list=alsa,oss,sdl,esd) As a reference: * Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633390 * Gentoo & Arch: i don't see them using it in their builds. On Sat, Nov 15, 2014 at 7:03 PM, Thomas Morper wrote: > Hello there, > > I've had a closer look at the qemu SlackBuild and now I'm wondering about > some of the constructs in there. > > The checks for libusb, spice and usbredir seem to be completely redundant > because qemu's configure will check for availability of these features and > enable them when possible. > > The check for the device tree compiler seems to be even more than > redundant, because this isn't even an optional depedency as the dtc has > been bundled with qemu since at least version 2.0.0. > > Most configure options just state the defaults. > > The OS_CFLAGS parameter is probably meaningless; it's not used anywhere in > the makefiles. > > A propos make... to get a parallel build (e.g. with MAKEFLAGS=-j4) you > have to "make config-all-devices.mak config-all-disas.mak" first, > otherwise "make" will run a single job only which will take quite a while > when building all targets (anybody with a better understanding of "make" > care to explain?). > > Maybe the qemu SlackBuild should get a cleanup (and an update to 2.1.2). > > Cheers! > > -- > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - http://slackbuilds.org/faq/ > > -- Antonio Hern?ndez Blas | Oaxaca, M?xico, Mx. https://github.com/nihilismus | https://bitbucket.org/nihilismus | https://twitter.com/nihilipster -------------- next part -------------- An HTML attachment was scrubbed... URL: From hba.nihilismus at gmail.com Sun Nov 16 04:04:42 2014 From: hba.nihilismus at gmail.com (=?UTF-8?Q?Antonio_Hern=C3=A1ndez_Blas?=) Date: Sat, 15 Nov 2014 22:04:42 -0600 Subject: [Slackbuilds-users] qemu annotations In-Reply-To: References: Message-ID: BTW there is a need for an upgrade of libusb in Slackware [1], would it be possible to have an static version of libusb for qemu? [1] http://www.linuxquestions.org/questions/slackware-14/libusb-upgrade-report-4175525421/ On Sat, Nov 15, 2014 at 9:09 PM, Antonio Hern?ndez Blas < hba.nihilismus at gmail.com> wrote: > Hi Thomas. > > Two weeks ago, i sent the next message to the current maintainer, no > response so far: > > Hi Edward, i'm writing you to suggest the dropping of esd from > qemu.SlackBuild (--audio-drv-list=alsa,oss,sdl,esd) > > As a reference: > * Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633390 > * Gentoo & Arch: i don't see them using it in their builds. > > > > On Sat, Nov 15, 2014 at 7:03 PM, Thomas Morper > wrote: > >> Hello there, >> >> I've had a closer look at the qemu SlackBuild and now I'm wondering about >> some of the constructs in there. >> >> The checks for libusb, spice and usbredir seem to be completely redundant >> because qemu's configure will check for availability of these features and >> enable them when possible. >> >> The check for the device tree compiler seems to be even more than >> redundant, because this isn't even an optional depedency as the dtc has >> been bundled with qemu since at least version 2.0.0. >> >> Most configure options just state the defaults. >> >> The OS_CFLAGS parameter is probably meaningless; it's not used anywhere in >> the makefiles. >> >> A propos make... to get a parallel build (e.g. with MAKEFLAGS=-j4) you >> have to "make config-all-devices.mak config-all-disas.mak" first, >> otherwise "make" will run a single job only which will take quite a while >> when building all targets (anybody with a better understanding of "make" >> care to explain?). >> >> Maybe the qemu SlackBuild should get a cleanup (and an update to 2.1.2). >> >> Cheers! >> >> -- >> _______________________________________________ >> SlackBuilds-users mailing list >> SlackBuilds-users at slackbuilds.org >> http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users >> Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ >> FAQ - http://slackbuilds.org/faq/ >> >> > > > -- > Antonio Hern?ndez Blas | Oaxaca, M?xico, Mx. > https://github.com/nihilismus | https://bitbucket.org/nihilismus | > https://twitter.com/nihilipster > -- Antonio Hern?ndez Blas | Oaxaca, M?xico, Mx. https://github.com/nihilismus | https://bitbucket.org/nihilismus | https://twitter.com/nihilipster -------------- next part -------------- An HTML attachment was scrubbed... URL: From willysr at slackbuilds.org Sun Nov 16 04:07:38 2014 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sun, 16 Nov 2014 11:07:38 +0700 Subject: [Slackbuilds-users] qemu annotations In-Reply-To: References: Message-ID: <5468230A.1070501@slackbuilds.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > BTW there is a need for an upgrade of libusb in Slackware [1], > would it be possible to have an static version of libusb for qemu? > > [1] > http://www.linuxquestions.org/questions/slackware-14/libusb-upgrade-report-4175525421/ This > probably be applicable to -current and not in -stable - -- Willy Sudiarto Raharjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlRoIwoACgkQiHuDdNczM4EVOgCgoXw/393BowPHGW3IB2fvN815 vwsAnjELuwWlx+YlPUBkYs4M7zLPCVub =hWlh -----END PGP SIGNATURE----- From Jim.Diamond at acadiau.ca Sun Nov 16 12:52:55 2014 From: Jim.Diamond at acadiau.ca (Jim Diamond) Date: Sun, 16 Nov 2014 08:52:55 -0400 Subject: [Slackbuilds-users] problem compiling entangle 0.6.0 on S64 14.1 Message-ID: <20141116125255.GA1422@tux.acadiau.ca> I'm trying to compile entangle. I have all of the packages which the page says I need. When I try to build it, after it works for a while it says ... GEN Entangle-0.1.gir Couldn't find include 'GExiv2-0.4.gir' (search path: ['.', '.', 'gir-1.0', '/usr/share/gir-1.0', '/usr/share/gir-1.0', '/usr/share/gir-1.0']) I looked around a bit and I'm not sure which package should have that file. Anyone point me in the right direction? This is on a S64 14.1 system without the 32-bit libs installed. Thanks. Jim From willysr at slackbuilds.org Sun Nov 16 14:11:38 2014 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sun, 16 Nov 2014 21:11:38 +0700 Subject: [Slackbuilds-users] problem compiling entangle 0.6.0 on S64 14.1 In-Reply-To: <20141116125255.GA1422@tux.acadiau.ca> References: <20141116125255.GA1422@tux.acadiau.ca> Message-ID: <5468B09A.8050201@slackbuilds.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I'm trying to compile entangle. I have all of the packages which > the page says I need. > > When I try to build it, after it works for a while it says ... GEN > Entangle-0.1.gir Couldn't find include 'GExiv2-0.4.gir' (search > path: ['.', '.', 'gir-1.0', '/usr/share/gir-1.0', > '/usr/share/gir-1.0', '/usr/share/gir-1.0']) > > I looked around a bit and I'm not sure which package should have > that file. Anyone point me in the right direction? i just tested on VM and it worked here LibRaw: MD5SUM check for LibRaw-0.16.0.tar.gz ... OK MD5SUM check for LibRaw-demosaic-pack-GPL2-0.16.0.tar.gz ... OK MD5SUM check for LibRaw-demosaic-pack-GPL3-0.16.0.tar.gz ... OK Building package LibRaw-0.16.0-x86_64-1_SBo.tgz ... OK Installing package LibRaw-0.16.0-x86_64-1_SBo.tgz ... OK libpeas: MD5SUM check for libpeas-1.8.1.tar.xz ... OK Building package libpeas-1.8.1-x86_64-1_SBo.tgz ... OK Installing package libpeas-1.8.1-x86_64-1_SBo.tgz ... OK libgexiv2: MD5SUM check for gexiv2-0.7.0.tar.xz ... OK Building package libgexiv2-0.7.0-x86_64-2_SBo.tgz ... OK Installing package libgexiv2-0.7.0-x86_64-2_SBo.tgz ... OK entangle: MD5SUM check for entangle-0.6.0.tar.gz ... OK Building package entangle-0.6.0-x86_64-1_SBo.tgz ... OK Installing package entangle-0.6.0-x86_64-1_SBo.tgz ... OK i think you missed libgexiv2 - -- Willy Sudiarto Raharjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlRosJkACgkQiHuDdNczM4HbtQCeJ8QvtkBlgMbnDJ1XtWbsG8en u74Anise2fkv289uXthrl6q/4S0pHdFG =4rnr -----END PGP SIGNATURE----- From Jim.Diamond at acadiau.ca Sun Nov 16 17:02:27 2014 From: Jim.Diamond at acadiau.ca (Jim Diamond) Date: Sun, 16 Nov 2014 13:02:27 -0400 Subject: [Slackbuilds-users] problem compiling entangle 0.6.0 on S64 14.1 In-Reply-To: <5468B09A.8050201@slackbuilds.org> References: <20141116125255.GA1422@tux.acadiau.ca> <5468B09A.8050201@slackbuilds.org> Message-ID: <20141116170227.GA10083@tux.acadiau.ca> On Sun, Nov 16, 2014 at 21:11 (+0700), Willy Sudiarto Raharjo wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >> I'm trying to compile entangle. I have all of the packages which >> the page says I need. >> When I try to build it, after it works for a while it says ... GEN >> Entangle-0.1.gir Couldn't find include 'GExiv2-0.4.gir' (search >> path: ['.', '.', 'gir-1.0', '/usr/share/gir-1.0', >> '/usr/share/gir-1.0', '/usr/share/gir-1.0']) >> I looked around a bit and I'm not sure which package should have >> that file. Anyone point me in the right direction? > i just tested on VM and it worked here > libgexiv2: > MD5SUM check for gexiv2-0.7.0.tar.xz ... OK > Building package libgexiv2-0.7.0-x86_64-2_SBo.tgz ... OK > Installing package libgexiv2-0.7.0-x86_64-2_SBo.tgz ... OK > i think you missed libgexiv2 Nope, I had it installed. But given your comment, I removed it and rebuilt it, and now things work. Investigating, I see that I had had libgexiv2-0.7.0-x86_64-1_SBo, not the latest and greatest libgexiv2-0.7.0-x86_64-2_SBo. I guess this is the sort of thing which slips through the crack; sbocheck didn't tell me I had an old version of libgexiv2-0.7.0. Thanks very much for your help. Jim From larryhaja at gmail.com Sun Nov 16 17:27:00 2014 From: larryhaja at gmail.com (Larry Hajali) Date: Sun, 16 Nov 2014 09:27:00 -0800 Subject: [Slackbuilds-users] problem compiling entangle 0.6.0 on S64 14.1 In-Reply-To: <20141116170227.GA10083@tux.acadiau.ca> References: <20141116125255.GA1422@tux.acadiau.ca> <5468B09A.8050201@slackbuilds.org> <20141116170227.GA10083@tux.acadiau.ca> Message-ID: I also had issues building entangle on a Slackware64 14.1, but on a multi-lib system. I know multi-lib is not supported but the problem turned out to be a hard coded libdir to /usr/lib in the libgexiv2 pkgconfig file. Newer versions of libgexiv2 seem to have fixed this, but I haven't tested newer versions. Can we apply the patch in this email to libgexiv2.SlackBuild so that the proper libdir is in the gexiv2.pc file? Thanks, --Larry On Sun, Nov 16, 2014 at 9:02 AM, Jim Diamond wrote: > On Sun, Nov 16, 2014 at 21:11 (+0700), Willy Sudiarto Raharjo wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > >> I'm trying to compile entangle. I have all of the packages which > >> the page says I need. > > >> When I try to build it, after it works for a while it says ... GEN > >> Entangle-0.1.gir Couldn't find include 'GExiv2-0.4.gir' (search > >> path: ['.', '.', 'gir-1.0', '/usr/share/gir-1.0', > >> '/usr/share/gir-1.0', '/usr/share/gir-1.0']) > > >> I looked around a bit and I'm not sure which package should have > >> that file. Anyone point me in the right direction? > > > i just tested on VM and it worked here > > > > > libgexiv2: > > MD5SUM check for gexiv2-0.7.0.tar.xz ... OK > > Building package libgexiv2-0.7.0-x86_64-2_SBo.tgz ... OK > > Installing package libgexiv2-0.7.0-x86_64-2_SBo.tgz ... OK > > > > > i think you missed libgexiv2 > > Nope, I had it installed. But given your comment, I removed it and > rebuilt it, and now things work. > > Investigating, I see that I had had libgexiv2-0.7.0-x86_64-1_SBo, not > the latest and greatest libgexiv2-0.7.0-x86_64-2_SBo. > I guess this is the sort of thing which slips through the crack; > sbocheck didn't tell me I had an old version of libgexiv2-0.7.0. > > Thanks very much for your help. > > Jim > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - http://slackbuilds.org/faq/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: fix-pkgconfig-libdir.patch Type: text/x-patch Size: 554 bytes Desc: not available URL: From kingbeowulf at gmail.com Sun Nov 16 20:20:17 2014 From: kingbeowulf at gmail.com (King Beowulf) Date: Sun, 16 Nov 2014 12:20:17 -0800 Subject: [Slackbuilds-users] qemu annotations In-Reply-To: References: Message-ID: <54690701.8050104@gmail.com> On 11/15/2014 05:03 PM, Thomas Morper wrote: > Hello there, > > I've had a closer look at the qemu SlackBuild and now I'm wondering about > some of the constructs in there. > > The checks for libusb, spice and usbredir seem to be completely redundant > because qemu's configure will check for availability of these features and > enable them when possible. > > The check for the device tree compiler seems to be even more than > redundant, because this isn't even an optional depedency as the dtc has > been bundled with qemu since at least version 2.0.0. > > Most configure options just state the defaults. > > The OS_CFLAGS parameter is probably meaningless; it's not used anywhere in > the makefiles. > > A propos make... to get a parallel build (e.g. with MAKEFLAGS=-j4) you > have to "make config-all-devices.mak config-all-disas.mak" first, > otherwise "make" will run a single job only which will take quite a while > when building all targets (anybody with a better understanding of "make" > care to explain?). > > Maybe the qemu SlackBuild should get a cleanup (and an update to 2.1.2). > > Cheers! > Good points; I'll work on it. There's a lot of cruft left over from qemu-1.x that no longer applies. I've been meaning to get to a cleanup for a while. As for parallel builds, you'll have to define "long time" - minutes, hours, days, weeks? I build in a VM running on an antique Athlon 64 X2 5200+ (2 GB RAM) and haven't noticed speed issues ( it does take a bit)...but then I wander off on other tasks while I'm waiting. -Ed From kingbeowulf at gmail.com Sun Nov 16 20:51:24 2014 From: kingbeowulf at gmail.com (King Beowulf) Date: Sun, 16 Nov 2014 12:51:24 -0800 Subject: [Slackbuilds-users] qemu annotations In-Reply-To: References: Message-ID: <54690E4C.8000202@gmail.com> On 11/15/2014 07:09 PM, Antonio Hern?ndez Blas wrote: > Hi Thomas. > > Two weeks ago, i sent the next message to the current maintainer, no > response so far: > > Hi Edward, i'm writing you to suggest the dropping of esd from > qemu.SlackBuild (--audio-drv-list=alsa,oss,sdl,esd) > > As a reference: > * Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633390 > * Gentoo & Arch: i don't see them using it in their builds. > That's odd, I thought I responded. I was living off a cell phone (the horror...) while traveling for work and did see your email. I'll look into esd; It probably is a dead project at this point. However, I probably won't pull it out of the script until Slackware-stable (and associated programs) drops it. Or replaces it with a better sound server. If qemu esd support bothers you, send a note to our BDFL to move esd tp "pasture." As for Debian, Gentoo and Arch: I've already put in 65% of my projected life span and so don't care to track their decisions - especially those putzes at Debian. -Ed From kingbeowulf at gmail.com Sun Nov 16 21:02:47 2014 From: kingbeowulf at gmail.com (King Beowulf) Date: Sun, 16 Nov 2014 13:02:47 -0800 Subject: [Slackbuilds-users] qemu annotations In-Reply-To: <5468230A.1070501@slackbuilds.org> References: <5468230A.1070501@slackbuilds.org> Message-ID: <546910F7.6000601@gmail.com> On 11/15/2014 08:07 PM, Willy Sudiarto Raharjo wrote: >> BTW there is a need for an upgrade of libusb in Slackware [1], >> would it be possible to have an static version of libusb for qemu? > >> [1] >> http://www.linuxquestions.org/questions/slackware-14/libusb-upgrade-report-4175525421/ > > This > > probably be applicable to -current and not in -stable > > > -- > Willy Sudiarto Raharjo Indeed, when -current hits RC status and includes the newer libusb, that's when I will test updating qemu. The switch is already there if you upgrade libusb on your own, but I can't assume that's the case for everybody. -Ed From yalhcru at gmail.com Sun Nov 16 21:32:35 2014 From: yalhcru at gmail.com (B Watson) Date: Sun, 16 Nov 2014 16:32:35 -0500 Subject: [Slackbuilds-users] qemu annotations In-Reply-To: <54690E4C.8000202@gmail.com> References: <54690E4C.8000202@gmail.com> Message-ID: On 11/16/14, King Beowulf wrote: > If qemu esd support bothers you, send a note to our BDFL to move esd tp > "pasture." You could make it optional, default enabled. Would make everyone happy I suppose. Actually maybe do this: --audio-drv-list="${AUDIODRIVERS:-alsa,oss,sdl,esd}" \ People who don't care will get what the script does now, people who do care will be able to get what they want, and there will be much rejoicing. From chris.willing at iinet.net.au Mon Nov 17 01:07:24 2014 From: chris.willing at iinet.net.au (Christoph Willing) Date: Mon, 17 Nov 2014 11:07:24 +1000 Subject: [Slackbuilds-users] qemu annotations In-Reply-To: References: <54690E4C.8000202@gmail.com> Message-ID: <54694A4C.6020508@iinet.net.au> On 11/17/2014 07:32 AM, B Watson wrote: > On 11/16/14, King Beowulf wrote: > >> If qemu esd support bothers you, send a note to our BDFL to move esd tp >> "pasture." > > You could make it optional, default enabled. Would make everyone happy > I suppose. Actually maybe do this: > > --audio-drv-list="${AUDIODRIVERS:-alsa,oss,sdl,esd}" \ > > People who don't care will get what the script does now, people who do > care will be able to get what they want, and there will be much rejoicing. In a similar vein of thought, could we return to the enabling VNC by default please? This is the "vanilla" case so has some merit for that fact alone. Those who never use vnc with their VMs are not compelled to. Those who really think its a "bad thing" or who need to save 10K in their binary and don't even want it compiled in should be the ones to vary from the default and be required to specify VNC_ENABLE=no (I believe). chris From hba.nihilismus at gmail.com Mon Nov 17 14:28:25 2014 From: hba.nihilismus at gmail.com (=?UTF-8?Q?Antonio_Hern=C3=A1ndez_Blas?=) Date: Mon, 17 Nov 2014 08:28:25 -0600 Subject: [Slackbuilds-users] qemu annotations In-Reply-To: <54694A4C.6020508@iinet.net.au> References: <54690E4C.8000202@gmail.com> <54694A4C.6020508@iinet.net.au> Message-ID: Not the answer i expected but anyway, i'm attaching a patch to add a switch based in B Watson suggestion. At the end i just need alsa/oss support ;-) On Sun, Nov 16, 2014 at 7:07 PM, Christoph Willing < chris.willing at iinet.net.au> wrote: > > > On 11/17/2014 07:32 AM, B Watson wrote: > >> On 11/16/14, King Beowulf wrote: >> >> If qemu esd support bothers you, send a note to our BDFL to move esd tp >>> "pasture." >>> >> >> You could make it optional, default enabled. Would make everyone happy >> I suppose. Actually maybe do this: >> >> --audio-drv-list="${AUDIODRIVERS:-alsa,oss,sdl,esd}" \ >> >> People who don't care will get what the script does now, people who do >> care will be able to get what they want, and there will be much rejoicing. >> > > > In a similar vein of thought, could we return to the enabling VNC by > default please? This is the "vanilla" case so has some merit for that fact > alone. Those who never use vnc with their VMs are not compelled to. Those > who really think its a "bad thing" or who need to save 10K in their binary > and don't even want it compiled in should be the ones to vary from the > default and be required to specify VNC_ENABLE=no (I believe). > > chris > > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - http://slackbuilds.org/faq/ > > -- Antonio Hern?ndez Blas | Oaxaca, M?xico, Mx. https://github.com/nihilismus | https://bitbucket.org/nihilismus | https://twitter.com/nihilipster -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qemu-audiodrivers-switch.patch Type: application/octet-stream Size: 1048 bytes Desc: not available URL: From willysr at slackbuilds.org Mon Nov 17 20:44:56 2014 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Tue, 18 Nov 2014 03:44:56 +0700 Subject: [Slackbuilds-users] problem compiling entangle 0.6.0 on S64 14.1 In-Reply-To: References: <20141116125255.GA1422@tux.acadiau.ca> <5468B09A.8050201@slackbuilds.org> <20141116170227.GA10083@tux.acadiau.ca> Message-ID: <546A5E48.8010404@slackbuilds.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I also had issues building entangle on a Slackware64 14.1, but on > a multi-lib system. I know multi-lib is not supported but the > problem turned out to be a hard coded libdir to /usr/lib in the > libgexiv2 pkgconfig file. Newer versions of libgexiv2 seem to have > fixed this, but I haven't tested newer versions. Can we apply the > patch in this email to libgexiv2.SlackBuild so that the proper > libdir is in the gexiv2.pc file? Applied in my branch Thanks - -- Willy Sudiarto Raharjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlRqXkgACgkQiHuDdNczM4GhZgCfcgNfVFKyADFhTbcITcui38g/ aegAnROsUgq3zxT2inHU/M5zn2b+ua91 =aw5B -----END PGP SIGNATURE----- From larryhaja at gmail.com Tue Nov 18 02:27:24 2014 From: larryhaja at gmail.com (Larry Hajali) Date: Mon, 17 Nov 2014 18:27:24 -0800 Subject: [Slackbuilds-users] problem compiling entangle 0.6.0 on S64 14.1 In-Reply-To: <546A5E48.8010404@slackbuilds.org> References: <20141116125255.GA1422@tux.acadiau.ca> <5468B09A.8050201@slackbuilds.org> <20141116170227.GA10083@tux.acadiau.ca> <546A5E48.8010404@slackbuilds.org> Message-ID: Thanks! --Larry On Mon, Nov 17, 2014 at 12:44 PM, Willy Sudiarto Raharjo < willysr at slackbuilds.org> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > I also had issues building entangle on a Slackware64 14.1, but on > > a multi-lib system. I know multi-lib is not supported but the > > problem turned out to be a hard coded libdir to /usr/lib in the > > libgexiv2 pkgconfig file. Newer versions of libgexiv2 seem to have > > fixed this, but I haven't tested newer versions. Can we apply the > > patch in this email to libgexiv2.SlackBuild so that the proper > > libdir is in the gexiv2.pc file? > > Applied in my branch > Thanks > > - -- > Willy Sudiarto Raharjo > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iEYEARECAAYFAlRqXkgACgkQiHuDdNczM4GhZgCfcgNfVFKyADFhTbcITcui38g/ > aegAnROsUgq3zxT2inHU/M5zn2b+ua91 > =aw5B > -----END PGP SIGNATURE----- > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - http://slackbuilds.org/faq/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lems at gmx.net Thu Nov 20 14:40:43 2014 From: lems at gmx.net (Leonard Schmidt) Date: Thu, 20 Nov 2014 15:40:43 +0100 Subject: [Slackbuilds-users] dillo does not run/compile anymore since last fltk update Message-ID: <0Lw1vh-1Y0omf0cI9-017mkJ@mail.gmx.com> Hello, just a quick note that dillo does not run anymore since I compiled the last update of fltk13 (1.3.3). This is what I get: $ dillo dillo: symbol lookup error: dillo: undefined symbol: fl_oldfocus Compiling dillo results in: g++ -I/usr/include/libpng14 -I/usr/include/fltk13 -I/usr/include/freetype2 -O2 -fPIC -fvisibility-inlines-hidden -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_THREAD_SAFE -D_REENTRANT -O2 -fPIC -Wall -W -Wno-unused-parameter -fno-rtti -fno-exceptions -L/usr/lib64/fltk13 -Wl,-rpath,/usr/lib64/fltk13 -L/usr/local/lib -o dillo dillo.o paths.o tipwin.o ui.o uicmd.o bw.o cookies.o auth.o md5.o digest.o colors.o misc.o history.o prefs.o prefsparser.o keys.o url.o bitvec.o klist.o chain.o utf8.o timeout.o dialog.o web.o nav.o cache.o decode.o dicache.o capi.o domain.o css.o cssparser.o styleengine.o plain.o html.o form.o table.o bookmark.o dns.o gif.o jpeg.o png.o imgbuf.o image.o menu.o dpiapi.o findbar.o xembed.o ../dlib/libDlib.a ../dpip/libDpip.a IO/libDiof.a ../dw/libDw-widgets.a ../dw/libDw-fltk.a ../dw/libDw-core.a ../lout/liblout.a -ljpeg -L/usr/lib64 -lpng14 -L/usr/lib64/fltk13 -Wl,-rpath,/usr/lib64/fltk13 -lfltk -lXcursor -lXfixes -lXext -lXft -lfontconfig -lXinerama -lpthread -ldl -lm -lX11 -lz -lpthread -lX11 ../dw/libDw-fltk.a(libDw_fltk_a-fltkviewbase.o): In function `dw::fltk::FltkViewBase::handle(int)': fltkviewbase.cc:(.text+0x1c83): undefined reference to `fl_oldfocus' collect2: error: ld returned 1 exit status make[3]: *** [dillo] Error 1 make[3]: Leaving directory `/tmp/SBo/dillo-3.0.4/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/tmp/SBo/dillo-3.0.4/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/tmp/SBo/dillo-3.0.4' make: *** [all] Error 2 This is on Slackware64 -current. Leonard From willysr at slackbuilds.org Thu Nov 20 14:53:14 2014 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Thu, 20 Nov 2014 21:53:14 +0700 Subject: [Slackbuilds-users] dillo does not run/compile anymore since last fltk update In-Reply-To: <0Lw1vh-1Y0omf0cI9-017mkJ@mail.gmx.com> References: <0Lw1vh-1Y0omf0cI9-017mkJ@mail.gmx.com> Message-ID: <44F99DFD-8D29-450E-9DFB-D517C6A019DB@slackbuilds.org> > just a quick note that dillo does not run anymore since I compiled the > last update of fltk13 (1.3.3). Already fixed in my branch -- Willy Sudiarto Raharjo -------------- next part -------------- An HTML attachment was scrubbed... URL: From lramos.prof at yahoo.com.br Thu Nov 20 16:59:30 2014 From: lramos.prof at yahoo.com.br (Luiz Carlos Ramos) Date: Thu, 20 Nov 2014 14:59:30 -0200 Subject: [Slackbuilds-users] midori 0.5.9 Message-ID: <1416502770.257305.193419617.5C794D53@webmail.messagingengine.com> Hello, I just tried to use current midori Slackbuild script (for version 0.5.8) for building the last upstream version (0.5.9), and it didn't compile. In fact, it seems the upstream developers decided to deliver source files in another directory (that is, in a subdirectory called midori-0.5.9). Including a line in the slackbuild (that is, moving all that stuff to the parent subdirectory and removing the now empty subdirectory midori-0.5.9) proved sufficient to work around that issue. I'm sending attached a patch, which summarizes the differences between that new version and the latest git version, to your appreciation. Also, if you could advise me about how is the ettiquette related to copyrights... in the first version of this modified script, I placed a copyright just below yours in the script. However in the patch being sent I removed that line, because I am not completely aware of the implications. Thanks, Luiz Ramos S?o Paulo - Brazil lramos dot prof at yahoo dot com dot br -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-network-midori-Updated-to-version-0.5.9.patch Type: application/octet-stream Size: 2121 bytes Desc: not available URL: From matteo.bernardini at gmail.com Thu Nov 20 17:56:50 2014 From: matteo.bernardini at gmail.com (Matteo Bernardini) Date: Thu, 20 Nov 2014 18:56:50 +0100 Subject: [Slackbuilds-users] midori 0.5.9 In-Reply-To: <1416502770.257305.193419617.5C794D53@webmail.messagingengine.com> References: <1416502770.257305.193419617.5C794D53@webmail.messagingengine.com> Message-ID: 2014-11-20 17:59 GMT+01:00 Luiz Carlos Ramos : > Hello, > > I just tried to use current midori Slackbuild script (for version 0.5.8) > for building the last upstream version (0.5.9), and it didn't compile. > > In fact, it seems the upstream developers decided to deliver source > files in another directory (that is, in a subdirectory called > midori-0.5.9). Including a line in the slackbuild (that is, moving all > that stuff to the parent subdirectory and removing the now empty > subdirectory midori-0.5.9) proved sufficient to work around that issue. > > I'm sending attached a patch, which summarizes the differences between > that new version and the latest git version, to your appreciation. > > Also, if you could advise me about how is the ettiquette related to > copyrights... in the first version of this modified script, I placed a > copyright just below yours in the script. However in the patch being > sent I removed that line, because I am not completely aware of the > implications. hi Luiz, thanks for the patch, but this has been reported to me yesterday by Julio Dimitrov: midori developers keeps behaving bad and removing their tarballs as soon as they release a new version, breaking download links. so I have committed yesterday an update to the new version (that I just pushed on our git), self-hosting the tarball (so that building from SBo won't break anymore, even if they update it on their site). Matteo P.S. regarding the copyright: I added mine just because I maintain the script since a while, personally I don't usually do this for just some modifications... From kingbeowulf at gmail.com Fri Nov 21 05:49:29 2014 From: kingbeowulf at gmail.com (King Beowulf) Date: Thu, 20 Nov 2014 21:49:29 -0800 Subject: [Slackbuilds-users] correction to nvidia-driver in "pending" Message-ID: <546ED269.4090307@gmail.com> Willy, You're too fast for me. A couple of typos sneaked through 'nvidia-switch' in the nvidia-driver package. My bad. -------------------------- diff --git a/system/nvidia-driver/nvidia-switch b/system/nvidia-driver/nvidia-switch index 2bf2ff3..8d8a958 100644 --- a/system/nvidia-driver/nvidia-switch +++ b/system/nvidia-driver/nvidia-switch @@ -58,7 +58,7 @@ save_GL(){ mv libGL.so.$GL_VERSION-xorg libGL.so.$GL_VERSION ln -sf libGL.so.$GL_VERSION libGL.so.1 ln -sf libGL.so.$GL_VERSION libGL.so - rm -sf libGL.so.$NV_VERSION + rm -f libGL.so.$NV_VERSION fi cd "$CWD" } @@ -119,7 +119,7 @@ multilib(){ mv libGL.so.$GL_VERSION-xorg libGL.so.$GL_VERSION ln -sf libGL.so.$GL_VERSION libGL.so.1 ln -sf libGL.so.$GL_VERSION libGL.so - rm -sf libGL.so.$NV_VERSION + rm -f libGL.so.$NV_VERSION ;; esac cd "$CWD" --------------------------------- -------------- next part -------------- A non-text attachment was scrubbed... Name: nvidia-driver-switch.diff Type: text/x-patch Size: 829 bytes Desc: not available URL: From willysr at slackbuilds.org Fri Nov 21 06:21:04 2014 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Fri, 21 Nov 2014 13:21:04 +0700 Subject: [Slackbuilds-users] correction to nvidia-driver in "pending" In-Reply-To: <546ED269.4090307@gmail.com> References: <546ED269.4090307@gmail.com> Message-ID: <546ED9D0.8060505@slackbuilds.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > You're too fast for me. A couple of typos sneaked through > 'nvidia-switch' in the nvidia-driver package. My bad. Fixed on my branch already :) - -- Willy Sudiarto Raharjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlRu2dAACgkQiHuDdNczM4F46QCfQ5Ep52cktdhupoOfRBsZQ9Q1 458AmgLjrdZI1QSM2UiMZwLbFiDDurGx =iXUK -----END PGP SIGNATURE----- From yalhcru at gmail.com Fri Nov 21 20:44:12 2014 From: yalhcru at gmail.com (B Watson) Date: Fri, 21 Nov 2014 15:44:12 -0500 Subject: [Slackbuilds-users] GZDoom SlackBuild source link is broken In-Reply-To: References: Message-ID: On 11/21/14, Doogster wrote: > I'll just link you to the LQ post where it was reported: Sometime yesterday, the DNS server for urchlay.naptime.net stopped working. All the sources I host there for SBo are going to fail to download until it gets fixed. For now, the host is up, you can replace 'urchlay.naptime.net' with '204.9.204.226' in the URL... so the gzdoom source would be: http://204.9.204.226/~urchlay/src/gzdoom-1.8.2.tar.gz I'm not paying for the hosting, it's being provided as a favor from someone on IRC, so I'm dependent on him to fix it (if he's going to). From ryan.q at linux.com Fri Nov 21 20:56:48 2014 From: ryan.q at linux.com (Ryan P.C. McQuen) Date: Fri, 21 Nov 2014 20:56:48 +0000 Subject: [Slackbuilds-users] GZDoom SlackBuild source link is broken References: Message-ID: I put gzdoom in my sourceforge repo, link is below: http://sourceforge.net/projects/slackbuildsdirectlinks/files/gzdoom/gzdoom-1.8.2.tar.gz I can give you upload access if you want to put the rest of the tarballs there. :-) On Fri, Nov 21, 2014, 12:44 PM B Watson wrote: > On 11/21/14, Doogster wrote: > > I'll just link you to the LQ post where it was reported: > > Sometime yesterday, the DNS server for urchlay.naptime.net stopped > working. All the sources I host there for SBo are going to fail to > download until it gets fixed. > > For now, the host is up, you can replace 'urchlay.naptime.net' with > '204.9.204.226' in the URL... so the gzdoom source would be: > > http://204.9.204.226/~urchlay/src/gzdoom-1.8.2.tar.gz > > I'm not paying for the hosting, it's being provided as a favor from > someone on IRC, so I'm dependent on him to fix it (if he's going to). > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - http://slackbuilds.org/faq/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From willysr at slackbuilds.org Sat Nov 22 00:36:29 2014 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sat, 22 Nov 2014 07:36:29 +0700 Subject: [Slackbuilds-users] Updates - 20141122.1 Message-ID: <546FDA8D.2050202@slackbuilds.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sat Nov 22 00:21:54 UTC 2014 academic/gwyddion: Updated for version 2.39. audio/non: Added (Modular nonDAW). audio/ntk: Added (GUI Toolkit). audio/qtractor: Updated for version 0.6.3. audio/rebmp: Update email. audio/sunvox: Updated for version 1.8. audio/yoshimi: Updated for version 1.2.5. desktop/9menu: Added (create X menus). desktop/QtCurve-Gtk2: Fixed download link. desktop/QtCurve-KDE4: Fixed download link. desktop/mcwm: Updated DEPS. development/4th: Update email. development/gforth: Updated for version 0.7.3. development/lighttable: Updated for version 0.7.1. development/memchan: Update email. development/pforth: Update email. development/regina-rexx: Updated for version 3.9.0. development/rmlmmc: Fix MD5SUM. development/smartgit: Added (Desktop Git Client). development/smartgithg: Removed (replaced by smartgit). development/snack: Update email. development/tcludp: Updated for version 1.0.11. development/tclvfs: Update email. development/tkdnd: Updated for version 2.7. development/tklib: Updated for version 0.6. development/trf: Update email. games/adom: Updated for version 1.2.0_pre23. games/barrage: Update email. games/cgmadness: Update email. games/crimson: Added (strategy game). games/f1spirit: Update email. gis/geoserver-control-flow: Updated for version 2.6.1. gis/geoserver-css: Updated for version 2.6.1. gis/geoserver-oracle: Updated for version 2.6.1. gis/geoserver-pyramid: Updated for version 2.6.1. gis/geoserver-wps: Updated for version 2.6.1. gis/geoserver: Updated for version 2.6.1. graphics/digikam: Update README. graphics/gtkam: Updated for version 0.2.0. graphics/pho: Update email. libraries/CEGUI: Fix BUILD tag. libraries/GitPython: Updated for version 0.3.2.1. libraries/VTK: provide switches to enable features. libraries/afflib: Updated for version 3.7.4. libraries/async: Updated for version 0.6.2. libraries/audioread: Updated for version 1.2.1. libraries/gtkimageview: Fixed download link. libraries/libgexiv2: Fix pkgconfig path. libraries/mowitz: Update email. libraries/nextaw: Update email. libraries/ogre: Fix wget command. misc/ccze: Update email. misc/dvtm: Updated for version 0.13. misc/vdpauinfo: Updated for version 1.0. multimedia/beets: Updated for version 1.3.9. multimedia/harmonySEQ: Update email. multimedia/makemkv: Updated for version 1.9.0. multimedia/pngnq-s9: Fix build on newer toolchain. network/BitchX: Added (IRC client). network/comgt: Update email. network/connman: Fix script. network/dillo: Fix build against new fltk. network/dnscrypt-wrapper: Updated for version 0.1.13. network/flexget: Updated for version 1.2.222. network/gtkgnutella: Update email. network/hipchat: Updated for version 2.2.1271. network/memcached: Updated for version 1.4.21. network/midori: Updated for version 0.5.9. network/mumble: Updated for version 1.2.8. network/murmur: Updated for version 1.2.8. network/owncloud-server: Updated for version 7.0.3. network/pidgin-opensteamworks: Updated for version 1.5. office/kmymoney: Updated for version 4.7.1. office/mdp: Updated for version 0.92.3. office/qpdfview: Fix VERSION. office/qute: Added (Text Editor). office/siag: Update email. perl/perl-Test-Trap: Updated for version 0.2.5. python/path.py: Updated for version 7.0. python/pipdeptree: Updated for version 0.4.2. system/butterfly: Updated for version 1.5.8. system/google-droid-fonts: Updated for version 20141010. system/nvidia-driver: Updated for version 340.58. system/nvidia-kernel: Updated for version 340.58. system/profile-sync-daemon: Added (Manage browser profiles). system/qemu: Updated for version 2.1.2. system/rsyslog: Updated for version 8.4.2. system/slpkg: Updated for version 2.0.6. system/the_silver_searcher: Updated for version 0.27.0. +--------------------------+ - -- Willy Sudiarto Raharjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlRv2owACgkQiHuDdNczM4F/DQCfULwoQXP9Tnx+ly1nprGlPR/x jS0AoJUz+/pHofWnzeZCYBgp2SiPYLuv =fhTL -----END PGP SIGNATURE----- From chris.willing at iinet.net.au Mon Nov 24 00:37:06 2014 From: chris.willing at iinet.net.au (Christoph Willing) Date: Mon, 24 Nov 2014 10:37:06 +1000 Subject: [Slackbuilds-users] qemu annotations In-Reply-To: <54694A4C.6020508@iinet.net.au> References: <54690E4C.8000202@gmail.com> <54694A4C.6020508@iinet.net.au> Message-ID: <54727DB2.7060408@iinet.net.au> On 11/17/2014 11:07 AM, Christoph Willing wrote: > > > On 11/17/2014 07:32 AM, B Watson wrote: >> On 11/16/14, King Beowulf wrote: >> >>> If qemu esd support bothers you, send a note to our BDFL to move esd tp >>> "pasture." >> >> You could make it optional, default enabled. Would make everyone happy >> I suppose. Actually maybe do this: >> >> --audio-drv-list="${AUDIODRIVERS:-alsa,oss,sdl,esd}" \ >> >> People who don't care will get what the script does now, people who do >> care will be able to get what they want, and there will be much >> rejoicing. > > > In a similar vein of thought, could we return to the enabling VNC by > default please? This is the "vanilla" case so has some merit for that > fact alone. Those who never use vnc with their VMs are not compelled to. > Those who really think its a "bad thing" or who need to save 10K in > their binary and don't even want it compiled in should be the ones to > vary from the default and be required to specify VNC_ENABLE=no (I believe). > Thanks for those changes in the update. chris From kingbeowulf at gmail.com Mon Nov 24 01:16:09 2014 From: kingbeowulf at gmail.com (King Beowulf) Date: Sun, 23 Nov 2014 17:16:09 -0800 Subject: [Slackbuilds-users] qemu annotations In-Reply-To: <54727DB2.7060408@iinet.net.au> References: <54690E4C.8000202@gmail.com> <54694A4C.6020508@iinet.net.au> <54727DB2.7060408@iinet.net.au> Message-ID: <547286D9.1030900@gmail.com> On 11/23/2014 04:37 PM, Christoph Willing wrote: > > > On 11/17/2014 11:07 AM, Christoph Willing wrote: >> >> ---------------- >> >> In a similar vein of thought, could we return to the enabling VNC >> by default please? This is the "vanilla" case so has some merit >> for that fact alone. Those who never use vnc with their VMs are >> not compelled to. Those who really think its a "bad thing" or who >> need to save 10K in their binary and don't even want it compiled >> in should be the ones to vary from the default and be required to >> specify VNC_ENABLE=no (I believe). >> > > Thanks for those changes in the update. > > chris > No problem. The script needed a cleanup anyway. Besides, we Slackers know how to discuss issues and cooperate (usually!), [OT] not like some lately...[/OT] -Ed From hba.nihilismus at gmail.com Mon Nov 24 02:26:27 2014 From: hba.nihilismus at gmail.com (=?UTF-8?Q?Antonio_Hern=C3=A1ndez_Blas?=) Date: Sun, 23 Nov 2014 20:26:27 -0600 Subject: [Slackbuilds-users] qemu annotations In-Reply-To: <547286D9.1030900@gmail.com> References: <54690E4C.8000202@gmail.com> <54694A4C.6020508@iinet.net.au> <54727DB2.7060408@iinet.net.au> <547286D9.1030900@gmail.com> Message-ID: On Sun, Nov 23, 2014 at 7:16 PM, King Beowulf wrote: > No problem. The script needed a cleanup anyway. Besides, we Slackers > know how to discuss issues and cooperate (usually!), [OT] not like some > lately...[/OT] > > I just noticed that you didn't apply my patch for the audio drivers switch :'-( Could you please consider it? Maybe for the next qemu update (currently 2.2.0-rc2). Thanks -- Antonio Hern?ndez Blas | Oaxaca, M?xico, Mx. https://github.com/nihilismus | https://bitbucket.org/nihilismus | https://twitter.com/nihilipster -------------- next part -------------- An HTML attachment was scrubbed... URL: From 1.41421 at gmail.com Mon Nov 24 04:18:33 2014 From: 1.41421 at gmail.com (JCA) Date: Sun, 23 Nov 2014 21:18:33 -0700 Subject: [Slackbuilds-users] Getting package descriptions Message-ID: Is there a simple way of getting the description of each and every package hosted at slackbuilds.org? Many (most?) packages have names that are not all that descriptive, and therefore there are packages in there that one might be interested in, without knowing it. From miguel at thedeanda.com Mon Nov 24 04:56:18 2014 From: miguel at thedeanda.com (Miguel De Anda) Date: Sun, 23 Nov 2014 20:56:18 -0800 Subject: [Slackbuilds-users] Getting package descriptions In-Reply-To: References: Message-ID: sbopkg might be able to do that, git clone the official repo and some fancy cat'ing On Sun, Nov 23, 2014 at 8:18 PM, JCA <1.41421 at gmail.com> wrote: > Is there a simple way of getting the description of each and every > package hosted at slackbuilds.org? Many (most?) packages have names > that are not all that descriptive, and therefore there are packages in > there that one might be interested in, without knowing it. > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - http://slackbuilds.org/faq/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hba.nihilismus at gmail.com Mon Nov 24 05:02:44 2014 From: hba.nihilismus at gmail.com (=?UTF-8?Q?Antonio_Hern=C3=A1ndez_Blas?=) Date: Sun, 23 Nov 2014 23:02:44 -0600 Subject: [Slackbuilds-users] Getting package descriptions In-Reply-To: References: Message-ID: On Sun, Nov 23, 2014 at 10:18 PM, JCA <1.41421 at gmail.com> wrote: > Is there a simple way of getting the description of each and every > package hosted at slackbuilds.org? Many (most?) packages have names > that are not all that descriptive, and therefore there are packages in > there that one might be interested in, without knowing it. > If your SBo local repository is at /usr/ports: find /usr/ports/ -iname "slack-desc" | while read f; do grep '^.*: ' $f | head -1 ;done | sort > /tmp/descs.txt And finally: less -S /tmp/descs.txt - Cheers -- Antonio Hern?ndez Blas | Oaxaca, M?xico, Mx. https://github.com/nihilismus | https://bitbucket.org/nihilismus | https://twitter.com/nihilipster -------------- next part -------------- An HTML attachment was scrubbed... URL: From kingbeowulf at gmail.com Mon Nov 24 05:18:34 2014 From: kingbeowulf at gmail.com (King Beowulf) Date: Sun, 23 Nov 2014 21:18:34 -0800 Subject: [Slackbuilds-users] qemu annotations In-Reply-To: References: <54690E4C.8000202@gmail.com> <54694A4C.6020508@iinet.net.au> <54727DB2.7060408@iinet.net.au> <547286D9.1030900@gmail.com> Message-ID: <5472BFAA.5000303@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/23/2014 06:26 PM, Antonio Hern?ndez Blas wrote: > On Sun, Nov 23, 2014 at 7:16 PM, King Beowulf > > wrote: > > No problem. The script needed a cleanup anyway. Besides, we > Slackers know how to discuss issues and cooperate (usually!), [OT] > not like some lately...[/OT] > > > I just noticed that you didn't apply my patch for the audio > drivers switch :'-( > > Could you please consider it? Maybe for the next qemu update > (currently 2.2.0-rc2). > > Thanks > > -- Antonio Hern?ndez Blas | Oaxaca, M?xico, Mx. Ah, f-udge. I put it into the README but forgot to fix up the script. I just submitted a new slackbuild. Enjoy, Ed -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlRyv6UACgkQXvwMaW61dLeuXwCfSfxU2pbXlAyR9vSTDMWSxQeE IQQAn3EiTw9tXYALJ4u03cBMJLdE9IMI =bHbZ -----END PGP SIGNATURE----- From klaatu at straightedgelinux.com Mon Nov 24 09:18:13 2014 From: klaatu at straightedgelinux.com (Klaatu) Date: Mon, 24 Nov 2014 22:18:13 +1300 Subject: [Slackbuilds-users] Getting package descriptions In-Reply-To: References: Message-ID: <5472F7D5.2030605@straightedgelinux.com> On 11/24/2014 06:02 PM, Antonio Hern?ndez Blas wrote: > On Sun, Nov 23, 2014 at 10:18 PM, JCA <1.41421 at gmail.com > > wrote: > > Is there a simple way of getting the description of each and every > package hosted at slackbuilds.org ? Many > (most?) packages have names > that are not all that descriptive, and therefore there are packages in > there that one might be interested in, without knowing it. > > > If your SBo local repository is at /usr/ports: > > find /usr/ports/ -iname "slack-desc" | while read f; do grep '^.*: ' $f > | head -1 ;done | sort > /tmp/descs.txt > > And finally: > > less -S /tmp/descs.txt > > - Cheers > > -- > Antonio Hern?ndez Blas | Oaxaca, M?xico, Mx. > https://github.com/nihilismus | https://bitbucket.org/nihilismus | > https://twitter.com/nihilipster > > > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - http://slackbuilds.org/faq/ > Someone else keeps their slackbuilds in /usr/ports. And here I thought I was the only one. - klaatu From thedoogster at gmail.com Mon Nov 24 22:02:57 2014 From: thedoogster at gmail.com (Doogster) Date: Mon, 24 Nov 2014 14:02:57 -0800 Subject: [Slackbuilds-users] Circular dependencies Message-ID: Does SBo allow SlackBuilds to have circular dependencies? In other words, if I start at package A, load the info file for each package in its "require" field, do the same for each of those packages, and so on, can I be confident that I won't see a package that requires package A? I'm thinking of writing a faster alternative to sqg, and this is something I'd need to know about. -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at microlinux.fr Mon Nov 24 23:02:11 2014 From: info at microlinux.fr (Niki Kovacs) Date: Tue, 25 Nov 2014 00:02:11 +0100 Subject: [Slackbuilds-users] Updates - 20141122.1 In-Reply-To: <546FDA8D.2050202@slackbuilds.org> References: <546FDA8D.2050202@slackbuilds.org> Message-ID: <5473B8F3.9040800@microlinux.fr> Le 22/11/2014 01:36, Willy Sudiarto Raharjo a ?crit : > graphics/gtkam: Updated for version 0.2.0. Did anybody ever get this software to work? I tried gtkam with my Nikon PTP camera, and... nothing. The camera works OK with gphoto2 and Digikam, though. Niki -- Microlinux - Solutions informatiques 100% Linux et logiciels libres 7, place de l'?glise - 30730 Montpezat Web : http://www.microlinux.fr Mail : info at microlinux.fr T?l. : 04 66 63 10 32 From baildon.research at googlemail.com Mon Nov 24 23:07:22 2014 From: baildon.research at googlemail.com (David Spencer) Date: Mon, 24 Nov 2014 23:07:22 +0000 Subject: [Slackbuilds-users] Circular dependencies In-Reply-To: References: Message-ID: > Does SBo allow SlackBuilds to have circular dependencies? There are none in the set of REQUIRES= at the moment. If your new queue tool raises an error when it finds one, people may be grateful one day :-) Optional deps may be a different matter. The gdal slackbuild has two (!) that can be enabled with options that are documented only in the script's comments, and there may be more like that. If ever there was a case for preferring manual builds over automated tools, and for showing how flexible the whole SBo setup is, this is it. -D. From burningc at SDF.ORG Tue Nov 25 12:26:09 2014 From: burningc at SDF.ORG (Glenn Becker) Date: Tue, 25 Nov 2014 12:26:09 +0000 (UTC) Subject: [Slackbuilds-users] need some advice (re: splix/jbigkit SBos) Message-ID: Hi all, I've been maintaining the SlackBuilds for splix and jbigkit. For a while, printing has been an issue with my Samsung ML-2510, but I've been too lazy to follow it up (obviously I don't print at home very much). Not very responsible of me. Anyhoo, the root problem is that splix development appears to have stopped -- or at least greatly slowed. The current version of splix looks for the library libjbig.2.0.0 ... but the current version of the jbigkit library is libjbig.2.1. splix looks for v. 2.0.0, can't find it and plotzes. I solved the issue on the home front with a symlink, but was wondering what SlackBuild best practice I should use in a case like this. Should I roll back the jbigkit version? Thanks, /Glenn +---------------------------------------------+ Glenn Becker - burningc at sdf.org SDF Public Access UNIX System - http://sdf.org +---------------------------------------------+ From willysr at slackbuilds.org Tue Nov 25 13:54:06 2014 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Tue, 25 Nov 2014 20:54:06 +0700 Subject: [Slackbuilds-users] need some advice (re: splix/jbigkit SBos) In-Reply-To: References: Message-ID: <547489FE.9070409@slackbuilds.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Anyhoo, the root problem is that splix development appears to have > stopped -- or at least greatly slowed. The current version of > splix looks for the library libjbig.2.0.0 ... but the current > version of the jbigkit library is libjbig.2.1. splix looks for v. > 2.0.0, can't find it and plotzes. > > I solved the issue on the home front with a symlink, but was > wondering what SlackBuild best practice I should use in a case like > this. Should I roll back the jbigkit version? so far, only splix is using jbigkit, so i guess creating a symlink is OK - -- Willy Sudiarto Raharjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlR0if0ACgkQiHuDdNczM4HiiQCgkbJDupJzNToE/YczbcKd61fw PhwAnjZNx/W17PAYzL7BAbjMkrghKp0K =VStU -----END PGP SIGNATURE----- From burningc at SDF.ORG Tue Nov 25 16:08:55 2014 From: burningc at SDF.ORG (Glenn Becker) Date: Tue, 25 Nov 2014 16:08:55 +0000 (UTC) Subject: [Slackbuilds-users] need some advice (re: splix/jbigkit SBos) In-Reply-To: <547489FE.9070409@slackbuilds.org> References: <547489FE.9070409@slackbuilds.org> Message-ID: Hi Willy, > so far, only splix is using jbigkit, so i guess creating a symlink is OK Should it just be in the README for the 'Build? Or on the page describing splix and/or jbigkit? /Glenn +---------------------------------------------+ Glenn Becker - burningc at sdf.org SDF Public Access UNIX System - http://sdf.org +---------------------------------------------+ From pprkut at slackbuilds.org Tue Nov 25 16:33:18 2014 From: pprkut at slackbuilds.org (Heinz Wiesinger) Date: Tue, 25 Nov 2014 17:33:18 +0100 Subject: [Slackbuilds-users] need some advice (re: splix/jbigkit SBos) In-Reply-To: References: Message-ID: <6023069.SvpBQMJilR@titania> On Tuesday 25 November 2014 12:26:09 Glenn Becker wrote: > Hi all, > > I've been maintaining the SlackBuilds for splix and jbigkit. For a > while, printing has been an issue with my Samsung ML-2510, but I've > been too lazy to follow it up (obviously I don't print at home very > much). Not very responsible of me. > > Anyhoo, the root problem is that splix development appears to have > stopped -- or at least greatly slowed. The current version of splix > looks for the library libjbig.2.0.0 ... but the current version of > the jbigkit library is libjbig.2.1. splix looks for v. 2.0.0, can't > find it and plotzes. > > I solved the issue on the home front with a symlink, but was wondering > what SlackBuild best practice I should use in a case like this. Should > I roll back the jbigkit version? Did you check how other distros solve the problem? With quick checks I see that both Arch and Fedora seems to have splix using jbigkit 2.1 in their repos. Grs, Heinz -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 213 bytes Desc: This is a digitally signed message part. URL: From ryan.q at linux.com Tue Nov 25 16:58:39 2014 From: ryan.q at linux.com (Ryan P.C. McQuen) Date: Tue, 25 Nov 2014 08:58:39 -0800 Subject: [Slackbuilds-users] need some advice (re: splix/jbigkit SBos) In-Reply-To: <6023069.SvpBQMJilR@titania> References: <6023069.SvpBQMJilR@titania> Message-ID: >I solved the issue on the home front with a symlink The spotify64 build uses symlinks to solve library compatibility issues: http://slackbuilds.org/slackbuilds/14.1/multimedia/spotify64/spotify64.SlackBuild You may find it helpful (although I'm not saying this is the best solution ;-). --- On Nov 25, 2014 8:33 AM, "Heinz Wiesinger" wrote: > On Tuesday 25 November 2014 12:26:09 Glenn Becker wrote: > > Hi all, > > > > I've been maintaining the SlackBuilds for splix and jbigkit. For a > > while, printing has been an issue with my Samsung ML-2510, but I've > > been too lazy to follow it up (obviously I don't print at home very > > much). Not very responsible of me. > > > > Anyhoo, the root problem is that splix development appears to have > > stopped -- or at least greatly slowed. The current version of splix > > looks for the library libjbig.2.0.0 ... but the current version of > > the jbigkit library is libjbig.2.1. splix looks for v. 2.0.0, can't > > find it and plotzes. > > > > I solved the issue on the home front with a symlink, but was wondering > > what SlackBuild best practice I should use in a case like this. Should > > I roll back the jbigkit version? > > Did you check how other distros solve the problem? With quick checks I see > that both Arch and Fedora seems to have splix using jbigkit 2.1 in their > repos. > > Grs, > Heinz > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - http://slackbuilds.org/faq/ > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From burningc at SDF.ORG Tue Nov 25 17:43:42 2014 From: burningc at SDF.ORG (Glenn Becker) Date: Tue, 25 Nov 2014 17:43:42 +0000 (UTC) Subject: [Slackbuilds-users] need some advice (re: splix/jbigkit SBos) In-Reply-To: <6023069.SvpBQMJilR@titania> References: <6023069.SvpBQMJilR@titania> Message-ID: > Did you check how other distros solve the problem? With quick checks I see > that both Arch and Fedora seems to have splix using jbigkit 2.1 in their > repos. No I didn't. Will follow up on that ... thanks! +---------------------------------------------+ Glenn Becker - burningc at sdf.org SDF Public Access UNIX System - http://sdf.org +---------------------------------------------+ From willysr at slackbuilds.org Wed Nov 26 04:48:56 2014 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Wed, 26 Nov 2014 11:48:56 +0700 Subject: [Slackbuilds-users] call for testing: wesnoth-1.12 Message-ID: <54755BB8.2060604@slackbuilds.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all I just pushed wesnoth-scons branch in our git repository http://slackbuilds.org/cgit/slackbuilds/log/?h=wesnoth-scons i would appreciate if anyone who played this game before can try to build and play this game since it's a major release I have changed the build tool to use scons instead of CMake (which failed to build on this version) and thus changed the DEPS from lua to scons. I attached a patch from wesnoth 1.10 SlackBuild to make it easier for you to patch the existing SlackBuild from SBo website. Thanks before - -- Willy Sudiarto Raharjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlR1W7gACgkQiHuDdNczM4G49ACfcKZyBiYZlp5geIyO1wKfMP7H 5JkAniRn+951rngkZ28MPYBxB4XmPw8v =sHsz -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: wesnoth.patch Type: text/x-diff Size: 3559 bytes Desc: not available URL: From willysr at slackbuilds.org Wed Nov 26 14:43:14 2014 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Wed, 26 Nov 2014 21:43:14 +0700 Subject: [Slackbuilds-users] call for testing: wesnoth-1.12 In-Reply-To: <54755BB8.2060604@slackbuilds.org> References: <54755BB8.2060604@slackbuilds.org> Message-ID: <5475E702.8070403@slackbuilds.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I just pushed wesnoth-scons branch in our git repository > http://slackbuilds.org/cgit/slackbuilds/log/?h=wesnoth-scons > > i would appreciate if anyone who played this game before can try > to build and play this game since it's a major release I have > changed the build tool to use scons instead of CMake (which failed > to build on this version) and thus changed the DEPS from lua to > scons. small update has been made and now it correctly install the files and also fixed the incorrect data path while running the game (previously it searched for /tmp/SBo/....) - -- Willy Sudiarto Raharjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlR15wIACgkQiHuDdNczM4Eg9gCgpVfQtbGaOMeJrY9vKVxlnOVw 9TkAoK4TFk7GEGErmnXF7xnMT2tqLtuY =IAN3 -----END PGP SIGNATURE----- From mjjzf at syntaktisk.dk Wed Nov 26 14:47:28 2014 From: mjjzf at syntaktisk.dk (=?UTF-8?Q?Morten_Juhl-Johansen_Z=C3=B6lde-Fej=C3=A9r?=) Date: Wed, 26 Nov 2014 15:47:28 +0100 Subject: [Slackbuilds-users] call for testing: wesnoth-1.12 In-Reply-To: <5475E702.8070403@slackbuilds.org> References: <54755BB8.2060604@slackbuilds.org> <5475E702.8070403@slackbuilds.org> Message-ID: <2d48099b509c62a6682ccbf783f84576@syntaktisk.dk> On 26/11/2014 15:43, Willy Sudiarto Raharjo wrote: >> I just pushed wesnoth-scons branch in our git repository >> http://slackbuilds.org/cgit/slackbuilds/log/?h=wesnoth-scons >> >> i would appreciate if anyone who played this game before can try >> to build and play this game since it's a major release I have >> changed the build tool to use scons instead of CMake (which failed >> to build on this version) and thus changed the DEPS from lua to >> scons. > > small update has been made and now it correctly install the files and > also fixed the incorrect data path while running the game (previously > it searched for /tmp/SBo/....) I will give it a spin when I get home in a couple of hours. All the best, Morten __ Morten Juhl-Johansen Z?lde-Fej?r http://syntaktisk.dk * mjjzf at syntaktisk.dk From ryan.q at linux.com Wed Nov 26 17:27:46 2014 From: ryan.q at linux.com (Ryan P.C. McQuen) Date: Wed, 26 Nov 2014 09:27:46 -0800 Subject: [Slackbuilds-users] call for testing: wesnoth-1.12 In-Reply-To: <2d48099b509c62a6682ccbf783f84576@syntaktisk.dk> References: <54755BB8.2060604@slackbuilds.org> <5475E702.8070403@slackbuilds.org> <2d48099b509c62a6682ccbf783f84576@syntaktisk.dk> Message-ID: Works great on 64-14.1. Just went to the tutorial, sound and gfx are working perfectly. Thanks Willy. --- On Nov 26, 2014 6:47 AM, "Morten Juhl-Johansen Z?lde-Fej?r" < mjjzf at syntaktisk.dk> wrote: > On 26/11/2014 15:43, Willy Sudiarto Raharjo wrote: > >> I just pushed wesnoth-scons branch in our git repository >>> http://slackbuilds.org/cgit/slackbuilds/log/?h=wesnoth-scons >>> >>> i would appreciate if anyone who played this game before can try >>> to build and play this game since it's a major release I have >>> changed the build tool to use scons instead of CMake (which failed >>> to build on this version) and thus changed the DEPS from lua to >>> scons. >>> >> >> small update has been made and now it correctly install the files and >> also fixed the incorrect data path while running the game (previously >> it searched for /tmp/SBo/....) >> > > I will give it a spin when I get home in a couple of hours. > > All the best, > Morten > __ > Morten Juhl-Johansen Z?lde-Fej?r > http://syntaktisk.dk * mjjzf at syntaktisk.dk > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - http://slackbuilds.org/faq/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lacielacie at rocketmail.com Wed Nov 26 21:19:11 2014 From: lacielacie at rocketmail.com (KaMii) Date: Wed, 26 Nov 2014 13:19:11 -0800 Subject: [Slackbuilds-users] call for testing: wesnoth-1.12 In-Reply-To: <5475E702.8070403@slackbuilds.org> References: <54755BB8.2060604@slackbuilds.org> <5475E702.8070403@slackbuilds.org> Message-ID: <20141126131911.1807a093@Andromdeda.andromeda.gal> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Works on 64-current On Wed, 26 Nov 2014 21:43:14 +0700 Willy Sudiarto Raharjo wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > I just pushed wesnoth-scons branch in our git repository > > http://slackbuilds.org/cgit/slackbuilds/log/?h=wesnoth-scons > > > > i would appreciate if anyone who played this game before can try > > to build and play this game since it's a major release I have > > changed the build tool to use scons instead of CMake (which failed > > to build on this version) and thus changed the DEPS from lua to > > scons. > > small update has been made and now it correctly install the files and > also fixed the incorrect data path while running the game (previously > it searched for /tmp/SBo/....) > > > - -- > Willy Sudiarto Raharjo > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iEYEARECAAYFAlR15wIACgkQiHuDdNczM4Eg9gCgpVfQtbGaOMeJrY9vKVxlnOVw > 9TkAoK4TFk7GEGErmnXF7xnMT2tqLtuY > =IAN3 > -----END PGP SIGNATURE----- > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - http://slackbuilds.org/faq/ > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iJwEAQECAAYFAlR2Q88ACgkQkO84ARmAdEBdyAP/TcdclonGO4Wx8JvKVNnOHXDm I8yPnde1yhzHuBYL2NxFNLkM/krtk+GxWO+juJtmjMsqloB7DckBhz8w3Q/VGmBQ /BkZwfLMGD/8RclZ+Fia//TgM9cfrgjxiWBlBLAq8dV6AWVMHjt7uHt9AS19k5Tk 244fd75X0FyS+9GW/kY= =Ob0M -----END PGP SIGNATURE----- From ryan.q at linux.com Thu Nov 27 01:17:59 2014 From: ryan.q at linux.com (Ryan P.C. McQuen) Date: Wed, 26 Nov 2014 17:17:59 -0800 Subject: [Slackbuilds-users] scons 2.3.4 In-Reply-To: References: Message-ID: Hello Slackers! I've just submitted an update for scons 2.3.4 (attached). I've tested it with hydrogen and Willy's new wesnoth-scons build, both compiled and ran perfectly on 32-14.1 vm. :^) If you get a chance please test against any other packages (or architectures). Thanks, Ryan - -- --- -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: scons.tar Type: application/x-tar Size: 10240 bytes Desc: not available URL: From yalhcru at gmail.com Thu Nov 27 02:58:09 2014 From: yalhcru at gmail.com (B Watson) Date: Wed, 26 Nov 2014 21:58:09 -0500 Subject: [Slackbuilds-users] scons 2.3.4 In-Reply-To: References: Message-ID: On 11/26/14, Ryan P.C. McQuen wrote: > If you get a chance please test against any other packages (or > architectures). Tested on slackware64-14.1 against my builds that require scons: audio/clam audio/klick games/jezzball-kazzmir All build fine. For some reason I have scons listed as a dep of network/museek+, but it uses cmake to build, not scons. Will fix soon. Also tested building ardour, which isn't mine, but I use it a lot. Also builds fine. From ryan.q at linux.com Thu Nov 27 03:35:33 2014 From: ryan.q at linux.com (Ryan P.C. McQuen) Date: Wed, 26 Nov 2014 19:35:33 -0800 Subject: [Slackbuilds-users] scons 2.3.4 In-Reply-To: References: Message-ID: Wow! Thank you for the thorough report. Sounds like the scons project may actually be following semantic versioning. ;-) --- On Nov 26, 2014 6:58 PM, "B Watson" wrote: > On 11/26/14, Ryan P.C. McQuen wrote: > > > If you get a chance please test against any other packages (or > > architectures). > > Tested on slackware64-14.1 against my builds that require scons: > > audio/clam > audio/klick > games/jezzball-kazzmir > > All build fine. > > For some reason I have scons listed as a dep of network/museek+, but it > uses cmake to build, not scons. Will fix soon. > > Also tested building ardour, which isn't mine, but I use it a lot. Also > builds fine. > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - http://slackbuilds.org/faq/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From elyk03 at gmail.com Thu Nov 27 09:13:01 2014 From: elyk03 at gmail.com (Kyle Guinn) Date: Thu, 27 Nov 2014 03:13:01 -0600 Subject: [Slackbuilds-users] Clarification of REQUIRES and dependencies Message-ID: Willy and I have a disagreement about this line of http://slackbuilds.org/guidelines/ "The content of REQUIRES should only be first level dependencies (i.e. no deps of deps)." The disagreement occurs when package 1 depends on packages 2 and 3, and package 2 depends on 3. Should 3 be listed in 1's REQUIRES? It's similar in context to overlinking/underlinking for libraries. If you don't know what that is, these two pages describe it with examples: https://wiki.mageia.org/en/Overlinking_issues_in_packaging https://wiki.mageia.org/en/Underlinking_issues_in_packaging I am interpreting this guideline as "Do not overlink", as in don't list the entire tree of dependencies, just those with a depth of 1 ("first level"). Willy is interpreting it as "Underlink wherever possible" (similar to the indirect case on that second page) and will remove a depth=1 dependency from REQUIRES if it happens to appear at some depth > 1 (a "dep of dep"). What is the original intention of that guideline? Can that sentence be updated to distinguish these two interpretations? Possibly a more important question: Does it matter? Are there any SBo tools out there that need the dependency info to be underlinked? Are there any tools that would benefit by not underlinking, or are broken by underlinking? Personally I like having all of the dependency interrelations available to me, to know how all of the packages depend on each other, and I hate having parts of it stripped out to meet Willy's interpretation or some specific tool's needs. If some tool needs the underlinked info, then that can be automatically generated from the complete info -- that's what we have computers for, right? I'd love to hear other opinions and use cases. -Kyle From lramos.prof at yahoo.com.br Thu Nov 27 10:00:03 2014 From: lramos.prof at yahoo.com.br (Luiz Carlos Ramos) Date: Thu, 27 Nov 2014 08:00:03 -0200 Subject: [Slackbuilds-users] Clarification of REQUIRES and dependencies In-Reply-To: References: Message-ID: <20141127100003.GA13051@pace> Not really aware of the whole context, and so what is written below could be completely wrong, but... I think what's really missing is a quick tool to be used to list all dependencies needed for building one given package. Having such tool, for a "casual" user, it would not matter how REQUIRES is implemented. Of course developers would adhere to a common way of doing regarding this, but it would match to that tool's implementation. Just my 2 cents... Luiz On Thu, Nov 27, 2014 at 03:13:01AM -0600, Kyle Guinn wrote: > Willy and I have a disagreement about this line of > http://slackbuilds.org/guidelines/ > > "The content of REQUIRES should only be first level dependencies (i.e. > no deps of deps)." > > The disagreement occurs when package 1 depends on packages 2 and 3, > and package 2 depends on 3. Should 3 be listed in 1's REQUIRES? > > It's similar in context to overlinking/underlinking for libraries. If > you don't know what that is, these two pages describe it with > examples: > https://wiki.mageia.org/en/Overlinking_issues_in_packaging > https://wiki.mageia.org/en/Underlinking_issues_in_packaging > > I am interpreting this guideline as "Do not overlink", as in don't > list the entire tree of dependencies, just those with a depth of 1 > ("first level"). Willy is interpreting it as "Underlink wherever > possible" (similar to the indirect case on that second page) and will > remove a depth=1 dependency from REQUIRES if it happens to appear at > some depth > 1 (a "dep of dep"). What is the original intention of > that guideline? Can that sentence be updated to distinguish these two > interpretations? > > Possibly a more important question: Does it matter? Are there any > SBo tools out there that need the dependency info to be underlinked? > Are there any tools that would benefit by not underlinking, or are > broken by underlinking? > > Personally I like having all of the dependency interrelations > available to me, to know how all of the packages depend on each other, > and I hate having parts of it stripped out to meet Willy's > interpretation or some specific tool's needs. If some tool needs the > underlinked info, then that can be automatically generated from the > complete info -- that's what we have computers for, right? > > I'd love to hear other opinions and use cases. > -Kyle > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - http://slackbuilds.org/faq/ > From baildon.research at googlemail.com Thu Nov 27 11:13:43 2014 From: baildon.research at googlemail.com (David Spencer) Date: Thu, 27 Nov 2014 11:13:43 +0000 Subject: [Slackbuilds-users] Clarification of REQUIRES and dependencies In-Reply-To: References: Message-ID: > The disagreement occurs when package 1 depends on packages 2 and 3, > and package 2 depends on 3. Should 3 be listed in 1's REQUIRES? My amateur opinion: yes, because if 2 eventually drops the dependency on 3, 1 will still need 3. But this is unlikely. Also, if 1's documentation lists 3, some users might freak out if 3 is not listed in REQUIRES. Also, we are saved a *huge* number of these cases because we don't track dependencies within Slackware, so there are not many of these to worry about :D Also, it's a rare situation that doesn't matter much. Friends can disagree about it, but still be friends :-) > It's similar in context to overlinking/underlinking for libraries. If > you don't know what that is, these two pages describe it with > examples: > https://wiki.mageia.org/en/Overlinking_issues_in_packaging Wow. It's a miracle anything works, with so much to worry about. /usr/bin is full of "Unused direct dependencies", but Slackware still rocks. The part that reads "When building a package / You will get a warning as explained here (the check is done by strip_and_check_elf_files from spec-helper)" is 100% rpm rubbish. So I'm filing that page under "evidence that dependency resolving distros are broken". BICBW > https://wiki.mageia.org/en/Underlinking_issues_in_packaging Some of that advice may be out of date -- the linker in gcc-4.7 or 4.8 (can't remember which) was changed, it now refuses to underlink. > Possibly a more important question: Does it matter? Are there any > SBo tools out there that need the dependency info to be underlinked? > Are there any tools that would benefit by not underlinking, or are > broken by underlinking? SBo is now so mature that the answer to most of these questions is: "Apparently it doesn't matter in the real world" ;-) Overlinking can occur in most of the community tools due to the prevalent use of build queues. Most of the time this doesn't matter. It matters if you're publishing packages for other people, who might install an overlinked package without its unintended dependencies. > I'd love to hear other opinions and use cases. Ok, well, what if the dependency of 2 on 3 is optional? To be honest, I'd be grateful for other peoples' opinions, because I'm not very confident that my amateur opinion is correct. This is not the kind of thing they teach on software engineering courses or write books about :-( Best regards to all -D. From willysr at slackbuilds.org Thu Nov 27 11:44:04 2014 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Thu, 27 Nov 2014 18:44:04 +0700 Subject: [Slackbuilds-users] Clarification of REQUIRES and dependencies In-Reply-To: <20141127100003.GA13051@pace> References: <20141127100003.GA13051@pace> Message-ID: <54770E84.9080201@slackbuilds.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I think what's really missing is a quick tool to be used to list > all dependencies needed for building one given package. Having such > tool, for a "casual" user, it would not matter how REQUIRES is > implemented. Of course developers would adhere to a common way of > doing regarding this, but it would match to that tool's > implementation. we already have that tool, made by Chess Griffin called sqg But we can't assume everyone use that tool I have written a blog post about it http://slackblogs.blogspot.com/2014/01/managing-sbo-dependencies-easily.html - -- Willy Sudiarto Raharjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlR3DoQACgkQiHuDdNczM4Fk/ACeMPmJV7fq6zHhZyEyA9ogJM+s pQUAnim1u8W9y0wQPKzdmdxksdiuCMNU =6btw -----END PGP SIGNATURE----- From willysr at slackbuilds.org Thu Nov 27 12:39:08 2014 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Thu, 27 Nov 2014 19:39:08 +0700 Subject: [Slackbuilds-users] Clarification of REQUIRES and dependencies In-Reply-To: References: Message-ID: <54771B6C.7050403@slackbuilds.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 My answer below is my personal opinion and do not represent other admins > The disagreement occurs when package 1 depends on packages 2 and > 3, and package 2 depends on 3. Should 3 be listed in 1's > REQUIRES? for me, it's a no When you want install 2, you will need to install 3 and by then you will have 2 and 3 installed. Adding all deps may not be a problem for a package which doesn't have so many deps, but consider packages that have LOTS of deps, it will be a huge job for the maintainer to track all "direct" deps. > What is the original intention of that guideline? Can that > sentence be updated to distinguish these two interpretations? from my point of view, the sentence was made to simplify things as maintainer. Not all of us can track every "direct" dep for a package, so by listing 1st level dependency, it simplifies our duty. We assume other maintainer did their job to track their package's dependencies and we trust their decision and include their packages. > Possibly a more important question: Does it matter? Are there > any SBo tools out there that need the dependency info to be > underlinked? Are there any tools that would benefit by not > underlinking, or are broken by underlinking? this is not really related to any SBo tools out there since this decision was made long before there's any sbopkg or any other automatic tools. > Personally I like having all of the dependency interrelations > available to me, to know how all of the packages depend on each > other, and I hate having parts of it stripped out to meet Willy's > interpretation or some specific tool's needs. If some tool needs > the underlinked info, then that can be automatically generated from > the complete info -- that's what we have computers for, right? for me, it doesn't really matter since sbopkg + sqg does the job for me, but again, we are not talking about tools. SBo will work with(out) any tool, but at the end, it's our (maintainer) job to handle our packages. - -- Willy Sudiarto Raharjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlR3G2wACgkQiHuDdNczM4Hz2ACfW3Eq7mvWSPQGIRhplzI75J8H nuYAoJGOsEA0pH3TzTNEKL5uiRKgCZEX =UK2p -----END PGP SIGNATURE----- From baildon.research at googlemail.com Thu Nov 27 13:04:55 2014 From: baildon.research at googlemail.com (David Spencer) Date: Thu, 27 Nov 2014 13:04:55 +0000 Subject: [Slackbuilds-users] Clarification of REQUIRES and dependencies In-Reply-To: <54771B6C.7050403@slackbuilds.org> References: <54771B6C.7050403@slackbuilds.org> Message-ID: >> The disagreement occurs when package 1 depends on packages 2 and >> 3, and package 2 depends on 3. Should 3 be listed in 1's >> REQUIRES? > > for me, it's a no > When you want install 2, you will need to install 3 and by then you > will have 2 and 3 installed. > Adding all deps may not be a problem for a package which doesn't have > so many deps, but consider packages that have LOTS of deps, it will be > a huge job for the maintainer to track all "direct" deps. I think you mean "indirect" deps (level 2)? To me, "direct" deps and "level 1" deps are the same thing? But what about updates. If a new version of 3 builds with a different soname, both 1 and 2 need to be rebuilt. If 3 is not listed in 1's REQUIRES=, how will we know that 1 needs to be rebuilt? This is not a theoretical question -- slackrepo already this kind of upgrade automatically. (And it uses dep trees, not queues, so it doesn't overlink accidentally.) Of course if 1 has no code that uses 3, then of course 3 should not be in 1's REQUIRES, but I don't think anything breaks if it is in REQUIRES= ... just some unneccessary rebuilds when 3 is upgraded. Best regards -D. From willysr at slackbuilds.org Thu Nov 27 13:20:41 2014 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Thu, 27 Nov 2014 20:20:41 +0700 Subject: [Slackbuilds-users] Clarification of REQUIRES and dependencies In-Reply-To: References: <54771B6C.7050403@slackbuilds.org> Message-ID: <54772529.9090804@slackbuilds.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> for me, it's a no When you want install 2, you will need to >> install 3 and by then you will have 2 and 3 installed. Adding all >> deps may not be a problem for a package which doesn't have so >> many deps, but consider packages that have LOTS of deps, it will >> be a huge job for the maintainer to track all "direct" deps. > > I think you mean "indirect" deps (level 2)? To me, "direct" deps > and "level 1" deps are the same thing? in this case, 1 requires 2 AND 3, but 2 already cover 3 in REQUIRES if it's indirect, then of course it should not be listed in REQUIRES > But what about updates. If a new version of 3 builds with a different > soname, both 1 and 2 need to be rebuilt. If 3 is not listed in > 1's REQUIRES=, how will we know that 1 needs to be rebuilt? This > is not a theoretical question that's our job as users to take care of those as well we can't ask the maintainer to take notes on every soname bump in README if we don't want to worry about soname bump, we can just keep the current version on our system and choose not to upgrade and it will keep working. This is i guess what Pat does in -stable. He update a package when there's a security vulnerabilities or there's serious or very annoying but in it, but he must make sure that it doesn't introduce soname changes which requires him to rebuilt any other packages depending on that one. - -- Willy Sudiarto Raharjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlR3JSkACgkQiHuDdNczM4H6CwCeKmrlH3N9gxaueYo2r/Y3Czde KK0AoIg9WgvqjQu6mEGtGiNYMiNDt9U7 =/5ch -----END PGP SIGNATURE----- From yalhcru at gmail.com Thu Nov 27 18:20:53 2014 From: yalhcru at gmail.com (B Watson) Date: Thu, 27 Nov 2014 13:20:53 -0500 Subject: [Slackbuilds-users] Clarification of REQUIRES and dependencies In-Reply-To: <54772529.9090804@slackbuilds.org> References: <54771B6C.7050403@slackbuilds.org> <54772529.9090804@slackbuilds.org> Message-ID: On 11/27/14, Willy Sudiarto Raharjo wrote: > in this case, 1 requires 2 AND 3, but 2 already cover 3 in REQUIRES > if it's indirect, then of course it should not be listed in REQUIRES A real-world use case: yesterday Ryan posted his proposed update for scons, asking that we test it with our builds that use scons. If everything that needs scons lists it in REQUIRES=, all that's needed to answer the question "what builds depend on scons?" is a simple grep. Basically the under/over debate doesn't really affect dependency resolution in the forward direction (either manual or automatic with a tool like sqg), but it does affect reverse dependency resolution, getting an answer to the question "what builds depend on the build I'm about to update?"... Unfortunately a lot of maintainers never ask this question, and we get maintainer A updating a build that breaks one of maintainer B's builds, without any notification other than an email from a user (maybe weeks later) saying "hey, your build is broken". OK, off my soapbox now, sorry. From k.venken at online.be Thu Nov 27 22:36:23 2014 From: k.venken at online.be (Karel Venken) Date: Thu, 27 Nov 2014 23:36:23 +0100 Subject: [Slackbuilds-users] Clarification of REQUIRES and dependencies In-Reply-To: <54770E84.9080201@slackbuilds.org> References: <20141127100003.GA13051@pace> <54770E84.9080201@slackbuilds.org> Message-ID: <5477A767.30208@online.be> Willy Sudiarto Raharjo wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > >> I think what's really missing is a quick tool to be used to list >> all dependencies needed for building one given package. Having such >> tool, for a "casual" user, it would not matter how REQUIRES is >> implemented. Of course developers would adhere to a common way of >> doing regarding this, but it would match to that tool's >> implementation. > we already have that tool, made by Chess Griffin called sqg > But we can't assume everyone use that tool > > I have written a blog post about it > http://slackblogs.blogspot.com/2014/01/managing-sbo-dependencies-easily.html > > Hi, A few years ago when I started using slackware (since 13.37), I found that manually going through all the steps of installing something like vlc was too much effort. So I started writing a script doing as much as possible. As the dependency question pops up from time to time in this newsgroup, and my script can show it in somewhat of a tree, I guess I should post it,... The script can do the whole process of downloading, building and installing (sometimes ;-) by itself but I never considered it usefull enough to show it. Reason is - it miserably fails in a lot of cases (of course, think of user and group settings etc...), so you still have to know what your are doing and correct several problems manually - it already exists in some other form as neet tools (eg. sbopkg), so it seems rather duplicate/useless - it blindly ignores the fact that you can set options. - it doesn't care about multilib and a lot of other things - eg. it will systematically refuse building wine on a 64 bit system which turned out to be possible if you install multilib. Well, I couldn't resist the temptation and I just considered it too much fun to try this myself, trying to learn something of Linux, etc... Anyway, (with a lot of doubt and as my scripting scills are probably not there yet) I have added it in following link, with some text around it. It has grown out of control and has several options now. http://users.online.be/~cd003081/slackware/getting_packages.html You can just download the script (you dont need anything else) and make it executable. The script itself is referred in http://users.online.be/~cd003081/slackware/packman/getpkgs The option you need is (as an example for vlc) getpkgs -sH vlc where s tells it only to download sources (you can do this step as regular user) and H to show dependencies recursively. So it will download buildscripts, parse the REQUIRES, download new buildscripts, etc. until all dependencies are found (Guess what happens with circular dependencies,...). First time you will see a lot of wget traffic, second time you run it you get the "nice" treelike output. I was not planning to keep/publish this link, at least not, for a very long time, (actually it is a personal webspace), but if you find it usefull, feel free to get it. Maybe, at least I hope, it can be of some help... kind regards... K. From kingbeowulf at gmail.com Fri Nov 28 00:18:07 2014 From: kingbeowulf at gmail.com (King Beowulf) Date: Thu, 27 Nov 2014 16:18:07 -0800 Subject: [Slackbuilds-users] Clarification of REQUIRES and dependencies In-Reply-To: References: Message-ID: <5477BF3F.2030801@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/27/2014 01:13 AM, Kyle Guinn wrote: > Willy and I have a disagreement about this line of > http://slackbuilds.org/guidelines/ > > "The content of REQUIRES should only be first level dependencies > (i.e. no deps of deps)." > > The disagreement occurs when package 1 depends on packages 2 and > 3, and package 2 depends on 3. Should 3 be listed in 1's > REQUIRES? > > -----------------? > > I'd love to hear other opinions and use cases. -Kyle IMHO, we need to keep things simple. I use a pad of paper to create a dependency tree. Often, this tree is simple (qemu, stellarium), at other times complex (inkscape, vlc). To whit, 1. create branch of direct listed deps (1a. create branch of any optional deps that may be useful) 2. Look up each dep on SBo and create a dep branch (2a. already installed? Done.) 3. repeat until deps tree is complete with dotted lines for overlaps 4. build and install one at a time along each branch (OMG! It took me an HOUR to install this package!) How often and how many times would a typical user install and update SBo packages? I play with A LOT and the time sink is not so great that I crave automagical dendency mumbo jumbo. Security is not an issue. Most packages I use regularly don't get updated unless there is a serious bug that bites me, a new functionality, or a new Slackware install. Seriously, the beauty of Slackware is that we can maintain it anyway we see fit, write scripts to automate many repetitive tasks (thanks Alien Bob!), use slackpg (thanks Piter Punk!), slackpkg+ (thanks zerouno!) and sbopkg (meh...not my cup of tea...); or we can go old school and do it all manually. But lets not go crazy and list every possible deps or deps umteen layes deep in every README or REQUIRES line. What are we, freakin' Debian or Ubuntu? Thanks for reading, Ed -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlR3vz4ACgkQXvwMaW61dLeXoQCeKev3VM/RrnGtPoFO/vsEpj36 BgYAnRKakxWZJPUz1Ss83xSGF+31Iz5B =D9v6 -----END PGP SIGNATURE----- From ryan.q at linux.com Fri Nov 28 17:39:05 2014 From: ryan.q at linux.com (Ryan P.C. McQuen) Date: Fri, 28 Nov 2014 09:39:05 -0800 Subject: [Slackbuilds-users] Clarification of REQUIRES and dependencies In-Reply-To: <5477BF3F.2030801@gmail.com> References: <5477BF3F.2030801@gmail.com> Message-ID: Here's what I do when I'm installing something with a lot of dependencies. I ctrl + click each dependency (on SBo), then ctrl + click each subsequent dependency. When there are no dependencies left, I start at my right-most browser tab and feed a long string of packages to sbopkg. So for inkscape, I end up with something like this: sbopkg -i libsigc++ -i glibmm -i cairomm -i pangomm -i atkmm -i mm-common -i gtkmm -i gsl -i numpy -i BeautifulSoup -i lxml -i inkscape Works every time! If dependencies were listed in multiple places for packages, this process would almost certainly be more frustrating, and I would end up with a lot of redundancy. I agree with Willy's interpretation on this. Best, Ryan - -- --- On Thu, Nov 27, 2014 at 4:18 PM, King Beowulf wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 11/27/2014 01:13 AM, Kyle Guinn wrote: >> Willy and I have a disagreement about this line of >> http://slackbuilds.org/guidelines/ >> >> "The content of REQUIRES should only be first level dependencies >> (i.e. no deps of deps)." >> >> The disagreement occurs when package 1 depends on packages 2 and >> 3, and package 2 depends on 3. Should 3 be listed in 1's >> REQUIRES? >> >> -----------------? >> >> I'd love to hear other opinions and use cases. -Kyle > > IMHO, we need to keep things simple. I use a pad of paper to create a > dependency tree. Often, this tree is simple (qemu, stellarium), at > other times complex (inkscape, vlc). To whit, > 1. create branch of direct listed deps > (1a. create branch of any optional deps that may be useful) > 2. Look up each dep on SBo and create a dep branch > (2a. already installed? Done.) > 3. repeat until deps tree is complete with dotted lines for overlaps > 4. build and install one at a time along each branch > > (OMG! It took me an HOUR to install this package!) > > How often and how many times would a typical user install and update > SBo packages? I play with A LOT and the time sink is not so great > that I crave automagical dendency mumbo jumbo. Security is not an > issue. Most packages I use regularly don't get updated unless there > is a serious bug that bites me, a new functionality, or a new > Slackware install. > > Seriously, the beauty of Slackware is that we can maintain it anyway > we see fit, write scripts to automate many repetitive tasks (thanks > Alien Bob!), use slackpg (thanks Piter Punk!), slackpkg+ (thanks > zerouno!) and sbopkg (meh...not my cup of tea...); or we can go old > school and do it all manually. > > But lets not go crazy and list every possible deps or deps umteen > layes deep in every README or REQUIRES line. What are we, freakin' > Debian or Ubuntu? > > Thanks for reading, > Ed > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iEYEARECAAYFAlR3vz4ACgkQXvwMaW61dLeXoQCeKev3VM/RrnGtPoFO/vsEpj36 > BgYAnRKakxWZJPUz1Ss83xSGF+31Iz5B > =D9v6 > -----END PGP SIGNATURE----- > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - http://slackbuilds.org/faq/ > From bocke at mycity.rs Fri Nov 28 18:31:51 2014 From: bocke at mycity.rs (Bojan Popovic) Date: Fri, 28 Nov 2014 19:31:51 +0100 Subject: [Slackbuilds-users] Clarification of REQUIRES and dependencies In-Reply-To: References: <5477BF3F.2030801@gmail.com> Message-ID: <20141128193151.23db41dd@artwo.universe.uni> Hi, sbopkg has a support for package queues. You can even generate some basic queue files automatically with sqg utility (/usr/doc/sbopkg-0.37.0/contrib/sqg). Although those queue files do require some manual tweaking as they will contain only the requirements present in REQUIRED part of dot info file. It won't contain any optional dependencies or additional options. That's not problem for Inkscape, but might be for some other packages like ffmpeg. Unless you are satisfied with the defaults and don't need additional codec support. The sqf files can contain references to other sqf files. This is something that sqg tool doesn't do automaticaly. But with a bit of tweaking you can easily reduce by few lines a number of auto-generated sqf files. With some attention to possible dependency recursion and incompatiblities you can create really great set of sqf files that fit your need. Sqf file organization aside, that reduces your line to: sbopkg -i inkscape.sqf or: sbopkg -k -i inkscape.sqf See "man sbopkg" for more details on sqf files and less known options of sbopkg. Cheers, Bojan. P.S. I will update "screenfetch" soon. It's really a lower priority for me at the moment, but I haven't forgot. :) Keep nagging me when you notice the new version. ;) Thanx. On Fri, 28 Nov 2014 09:39:05 -0800 "Ryan P.C. McQuen" wrote: > Here's what I do when I'm installing something with a lot of > dependencies. I ctrl + click each dependency (on SBo), then ctrl + > click each subsequent dependency. When there are no dependencies left, > I start at my right-most browser tab and feed a long string of > packages to sbopkg. So for inkscape, I end up with something like > this: > > sbopkg -i libsigc++ -i glibmm -i cairomm -i pangomm -i atkmm -i > mm-common -i gtkmm -i gsl -i numpy -i BeautifulSoup -i lxml -i > inkscape > > > Works every time! If dependencies were listed in multiple places for > packages, this process would almost certainly be more frustrating, and > I would end up with a lot of redundancy. > > I agree with Willy's interpretation on this. > > Best, > > Ryan > - > -- > --- > From baildon.research at googlemail.com Fri Nov 28 19:42:40 2014 From: baildon.research at googlemail.com (David Spencer) Date: Fri, 28 Nov 2014 19:42:40 +0000 Subject: [Slackbuilds-users] Clarification of REQUIRES and dependencies In-Reply-To: References: <5477BF3F.2030801@gmail.com> Message-ID: > Here's what I do when I'm installing something with a lot of > dependencies. I used to do exactly what you do, Ryan; it's a good methodology, but life's too short to do that for hundreds of packages. So I wrote something better. Inkscape is for wimps: here's what I do to install thunar-sendto-clamtk slackrepo build --install thunar-sendto-clamtk And here's what I do to build the *whole* repo. slackrepo build That's all. It takes three days but it *works*. And here's what I do to update the *whole* repo, after every public release. slackrepo update That's all. It works (overnight ;-). All rebuilds automatically taken care of, no broken shared libs. But this new interpretation *breaks* *that* *forever*. Why? Where is the advantage? Could someone explain *Why* please? The more I think about this, I really get quite upset. It even breaks *manual* updates, Ed, because you have no way of knowing for sure whether your existing package was broken by an update for an *unlisted* level one dependency. Nobody supporting this interpretation has addressed what to do about optional deps or updates, except to explain how you all like doing stuff manually. Well, if you all enjoy unnecessary work, a bit more would be good, right? Just because sbopkg can't do better, please do not break second generation tools like slackrepo that go far beyond sbopkg and sqf. If you go through with this interpretation, I might as well give up developing it. If a package has a direct dependency, put it in REQUIRES. It's simple. It's robust when dependencies of dependencies change. Please, what is the *problem* with that? What does it *break*? Sorry for the rant and thanks for listening. -D. From baildon.research at googlemail.com Fri Nov 28 20:47:58 2014 From: baildon.research at googlemail.com (David Spencer) Date: Fri, 28 Nov 2014 20:47:58 +0000 Subject: [Slackbuilds-users] scons 2.3.4 In-Reply-To: References: Message-ID: Everything that depends on scons builds ok here using Willy's branch: audio/ardour audio/clam audio/klick audio/hydrogen libraries/libffado audio/mixxx games/d1x-rebirth games/d2x-rebirth games/fceux games/fifengine games/glob2 games/jezzball-kazzmir games/pingus libraries/tolua++ multimedia/ffmpeg2theora games/wesnoth gis/gpsd graphics/lcdtest graphics/mypaint graphics/yafaray libraries/libsunpinyin libraries/serf multimedia/bombono-dvd network/linuxdcpp network/museek+ system/fuse-exfat system/xboxdrv-linux system/zfs-fuse HTH -D. From pprkut at slackbuilds.org Fri Nov 28 21:06:12 2014 From: pprkut at slackbuilds.org (Heinz Wiesinger) Date: Fri, 28 Nov 2014 22:06:12 +0100 Subject: [Slackbuilds-users] Clarification of REQUIRES and dependencies In-Reply-To: References: Message-ID: <5193240.pSOgqM4u6D@titania> On Thursday 27 November 2014 03:13:01 Kyle Guinn wrote: > Willy and I have a disagreement about this line of > http://slackbuilds.org/guidelines/ > > "The content of REQUIRES should only be first level dependencies (i.e. > no deps of deps)." > > The disagreement occurs when package 1 depends on packages 2 and 3, > and package 2 depends on 3. Should 3 be listed in 1's REQUIRES? > > It's similar in context to overlinking/underlinking for libraries. If > you don't know what that is, these two pages describe it with > examples: > https://wiki.mageia.org/en/Overlinking_issues_in_packaging > https://wiki.mageia.org/en/Underlinking_issues_in_packaging > > I am interpreting this guideline as "Do not overlink", as in don't > list the entire tree of dependencies, just those with a depth of 1 > ("first level"). Willy is interpreting it as "Underlink wherever > possible" (similar to the indirect case on that second page) and will > remove a depth=1 dependency from REQUIRES if it happens to appear at > some depth > 1 (a "dep of dep"). What is the original intention of > that guideline? Can that sentence be updated to distinguish these two > interpretations? > > Possibly a more important question: Does it matter? Are there any > SBo tools out there that need the dependency info to be underlinked? > Are there any tools that would benefit by not underlinking, or are > broken by underlinking? Here's my *personal* stance on this. It's abundantly clear from the replies in this thread that users see REQUIRES primarily as a means for dependency resolution. Various tools facilitate REQUIRES for that very same purpose as well. But, that is not actually its primary function. REQUIRES was introduced as a means to make script approval after submission easier. It is a way for us admins to know the minimum set of other applications/libraries to install in order to be able to verify the SlackBuild successfully. As such Willy's interpretation of what should go into REQUIRES makes perfect sense, as it's just more convenient that way for us. We had a long and thorough discussion among the admins before introducing REQUIRES and afaicr the common agreement was that there's no possible way we can make REQUIRES work perfectly for dependency resolution. Having to consider runtime deps, optional deps, conflicting deps, suggested deps. All existing dependency management systems are broken for that very fact, implementing our own would fare no different from those. And it's the freedom of not having to deal with that mess that makes me love Slackware so much, and from multiple posts on LQ, this mailing list and many other places, so do many other slackers. So we decided whatever becomes of REQUIRES should primarily suit the approval processes of SlackBuilds.org. It could still be used by tools, as long as its limitations are kept in mind. THAT SAID... The stance of SlackBuilds.org admins from the very beginning has always been "This is how we do it. We have good reasons for it, but we're not all-knowing. Make your case and we may consider adapting our processes." In fact, this is exactly how REQUIRES got introduced in the first place. It was a response to users making their case and us adapting our processes. There's no reason we can't reiterate over that. As long as simple things are kept in mind: -) (proper, complete, etc) dependency resolution is just not going to happen... -) don't think about installing packages, think about maintaining SlackBuilds For example, Urchlay's claim for reverse depencency mapping makes perfect sense here. I extensively use this when updating some of my lower level libs to make sure I don't break anything, or to hunt down fixes for things I do break. It can also help admins in the very same ways. As a matter of fact, we already do have reverse dependency mapping exposed in our own tooling. So if we can come up with a good and clear definition of what should go into REQUIRES so that reverse dependency mapping is reliable, I have absolutely no problem with supporting it. Cheers, Heinz -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 213 bytes Desc: This is a digitally signed message part. URL: From willysr at slackbuilds.org Sat Nov 29 01:32:21 2014 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sat, 29 Nov 2014 08:32:21 +0700 Subject: [Slackbuilds-users] Updates - 20141129.1 Message-ID: <54792225.4010209@slackbuilds.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sat Nov 29 01:15:50 UTC 2014 academic/arpack-ng: Add OpenBLAS support. academic/octave: Updated for version 3.8.2. academic/omlibraries: Updated for version svn20141126. academic/openmodelica: Updated for version svn23571. academic/qucs: Updated for version 0.0.18. academic/sage: Updated for version 6.4. academic/scilab: Updated for version 5.5.1. academic/smath-studio: Updated for version 0.97.5346. academic/sundial: Fix library installation. audio/qtractor: Updated for version 0.6.4. desktop/CurseTheWeather: Updated patch. desktop/wmSunMoon: Added (WM dockable app). desktop/wmcube: Added (dockapp). desktop/wminfo: Updated for version 4.1.3. development/CImg: Updated for version 1.5.9. development/android-studio: Added (Android Development Tool). development/gambas3: Updated for version 3.6.2. development/lighttable: Updated for version 0.7.2. development/mcu8051ide: Updated for version 1.4.9. development/mysql-workbench: Updated for version 6.2.4. development/ne: Update HOMEPAGE and DOWNLOAD url. development/rmlmmc: Update VERSION. development/scons: Updated for version 2.3.4 + new maintainer. games/fgo: Updated for version 1.5.4. games/mame: Updated for version 0.155. games/wesnoth: Updated for version 1.12. graphics/converseen: Updated for version 0.8.5. graphics/fontforge: Updated for version 20141014. graphics/librecad: Updated for version 2.0.6. graphics/photivo: Updated for version 20140525. graphics/pngquant: Updated for version 2.3.0. graphics/yed: Updated for version 3.13. libraries/exiftool: Updated for version 9.76. libraries/libsidplayfp: Added (SID Emulation). libraries/libsodium: Updated for version 1.0.1. libraries/libuv: Updated for version 1.0.0. libraries/libwebp: Updated for version 0.4.2. libraries/rarfile: Updated for version 2.7. libraries/tbb: Updated for version 4.3u1. misc/stardict-tools: Added (tool for stardict). multimedia/mpv: Updated for version 0.7.0. multimedia/smplayer: Updated for version 14.9.0. multimedia/smtube: Updated for version 1.4.8.0. network/Pafy: Updated for version 0.3.66. network/amavisd-new: Updated for version 2.10.1. network/connman: Remove patch and add connmanctl. network/copy: Updated for version 1.47.0439. network/fail2ban: Updated for version 0.9.1. network/hexchat: Updated for version 2.10.2. network/hipchat: Updated for version 2.2.1287. network/nagios: Updated for version 4.0.8. network/proxychains: Updated for version 4.8.1 + new maintainer. network/qupzilla: Updated for version 1.8.4. office/htmldoc: Add missing fonts. office/kchmviewer-qt: Updated for version 7.1. perl/perl-Archive-Extract: Updated for version 0.74. perl/perl-Test-Differences: Updated for version 0.63. python/argh: Updated for version 0.26.1. python/astroid: Updated for version 1.3.2. python/cov-core: Updated for version 1.15.0. python/hachoir-core: Added (Python Library). python/hachoir-metadata: Added (Metadata Extractor). python/hachoir-parser: Added (File Parser). python/python-libsass: Updated for version 0.6.2. python/regex: Updated for version 2014.11.14. system/clamav: Updated for version 0.98.5. system/cpuid: Added (CPU Tool). system/daemonize: Updated for version 1.7.5. system/drbd-utils: Fixes for manpages. system/nagios-plugins: Updated for version 2.0.3. system/nvidia-driver: Script cleanup. system/qemu: Added AUDIODRIVERS switch. system/slpkg: Updated for version 2.0.9. system/udiskie: Updated for version 1.1.3. system/winetricks: Updated for version 20140302 + new maintainer. +--------------------------+ - -- Willy Sudiarto Raharjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlR5IiUACgkQiHuDdNczM4HDcwCdE3SbniS/onxfsaXDAIL6FT7h bHgAnRIco8TISRCXICT/nzFeDYu9wsVY =XCS/ -----END PGP SIGNATURE----- From rsamurti at gmail.com Sat Nov 29 01:55:00 2014 From: rsamurti at gmail.com (Ananda Murthy R S) Date: Sat, 29 Nov 2014 07:25:00 +0530 Subject: [Slackbuilds-users] Download link for sage-6.4 not working. Message-ID: Hello, 6.4.1 has come. Can we update this along with this correction? Anand -- Close Windows ! Open source !! Free software from proprietary mafia !!! -------------- next part -------------- An HTML attachment was scrubbed... URL: From willysr at slackbuilds.org Sat Nov 29 02:07:52 2014 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sat, 29 Nov 2014 09:07:52 +0700 Subject: [Slackbuilds-users] Download link for sage-6.4 not working. In-Reply-To: References: Message-ID: <54792A78.90103@slackbuilds.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > 6.4.1 has come. Can we update this along with this correction? I will build this and push it for next week updates, but for now, i will try to find alternative mirror for 6.4 that works if you know any, please let me know Thanks - -- Willy Sudiarto Raharjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlR5KngACgkQiHuDdNczM4F1LwCffYFGHoQmHpapyKk5R2msR8Ec AwEAoIIj7Eb5N4DMAgm6Z8LlMbZArpR+ =NIVt -----END PGP SIGNATURE----- From willysr at slackbuilds.org Sat Nov 29 06:47:13 2014 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sat, 29 Nov 2014 13:47:13 +0700 Subject: [Slackbuilds-users] Updates - 20141129.2 Message-ID: <54796BF1.9040805@slackbuilds.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sat Nov 29 06:41:01 UTC 2014 academic/sage: Updated for version 6.4.1. desktop/xfce4-netload-plugin: Updated for version 1.2.4. development/ebe: Updated for version 2.5.8. development/mysql-workbench: Add symlink to fix missing lib. multimedia/flashplayer-plugin: Updated for version 11.2.202.424. - -- Willy Sudiarto Raharjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlR5a/EACgkQiHuDdNczM4GomgCfXRaVs1qxcOsXt7gEpU1DWNkp a8cAn2bTKI0P3+WVLi58PWFUk5gjDIff =hiH8 -----END PGP SIGNATURE----- From andrew.david.strong at gmail.com Sat Nov 29 07:37:26 2014 From: andrew.david.strong at gmail.com (andrew) Date: Sat, 29 Nov 2014 18:37:26 +1100 Subject: [Slackbuilds-users] Orphaned: Leafnode 2 Message-ID: <20141129073726.GA1639@ilium.andrews-corner.org> I no longer use Leafnode 2 having finally settled in with slrnpull. Is somebody interested in taking over care of this script? Andrew -- You think that's air you're breathing now? From bocke at mycity.rs Sat Nov 29 10:32:45 2014 From: bocke at mycity.rs (Bojan Popovic) Date: Sat, 29 Nov 2014 11:32:45 +0100 Subject: [Slackbuilds-users] Clarification of REQUIRES and dependencies In-Reply-To: <5193240.pSOgqM4u6D@titania> References: <5193240.pSOgqM4u6D@titania> Message-ID: <20141129113245.4370c50c@artwo.universe.uni> Hi, Thanx for the heads up. It's nice to read about the original intentions and it makes sense. But you probably also predicted people will use that in way thay find the most practical. :) Although, I agree: dependency resolution is hard to automate, especially in small teams. And even in big teams like Debian it turns out to be cludgy and bloats the system. And then you enter into the circle of constant and continous automation and abstraction of abstraction of abstraction. And automation of the abstraction that requires additional abstraction to make sense, and so on. That's why I like Slack. It's already simple. There is no need for the additional kludge. That being said, REQUIRES does provides a device for implementing at least some level of dependency resolution. But in no way it is possible to base a complete fool-proof system around it. I see it as more of a build helper than actually auto-dependency utility. That's why I think sbopkg's half-manual approach works great. And the author doesn't even encourage the usage of sbopkg for that. Although you can do it and it works great. Of course, with a manual intervention here and there. Anyway, you guys are doing the great job and I hope you won't give in to the popular demand. We don't need auto-dependency hell/kludge/bloat in Slackware. :) Although having a device for at least some half-automation is great thing. Especially as any dependency conflicts or recursion can be solved manualy. :) Thanx for the great job and cheers, Bojan. On Fri, 28 Nov 2014 22:06:12 +0100 Heinz Wiesinger wrote: > Here's my *personal* stance on this. > > It's abundantly clear from the replies in this thread that users see > REQUIRES primarily as a means for dependency resolution. Various > tools facilitate REQUIRES for that very same purpose as well. But, > that is not actually its primary function. REQUIRES was introduced as > a means to make script approval after submission easier. It is a way > for us admins to know the minimum set of other applications/libraries > to install in order to be able to verify the SlackBuild successfully. > As such Willy's interpretation of what should go into REQUIRES makes > perfect sense, as it's just more convenient that way for us. > > We had a long and thorough discussion among the admins before > introducing REQUIRES and afaicr the common agreement was that there's > no possible way we can make REQUIRES work perfectly for dependency > resolution. Having to consider runtime deps, optional deps, > conflicting deps, suggested deps. All existing dependency management > systems are broken for that very fact, implementing our own would > fare no different from those. And it's the freedom of not having to > deal with that mess that makes me love Slackware so much, and from > multiple posts on LQ, this mailing list and many other places, so do > many other slackers. So we decided whatever becomes of REQUIRES > should primarily suit the approval processes of SlackBuilds.org. It > could still be used by tools, as long as its limitations are kept in > mind. > > THAT SAID... > > The stance of SlackBuilds.org admins from the very beginning has > always been "This is how we do it. We have good reasons for it, but > we're not all-knowing. Make your case and we may consider adapting > our processes." In fact, this is exactly how REQUIRES got introduced > in the first place. It was a response to users making their case and > us adapting our processes. There's no reason we can't reiterate over > that. As long as simple things are kept in mind: > > -) (proper, complete, etc) dependency resolution is just not going to > happen... > -) don't think about installing packages, think about maintaining > SlackBuilds > > For example, Urchlay's claim for reverse depencency mapping makes > perfect sense here. I extensively use this when updating some of my > lower level libs to make sure I don't break anything, or to hunt down > fixes for things I do break. It can also help admins in the very same > ways. As a matter of fact, we already do have reverse dependency > mapping exposed in our own tooling. So if we can come up with a good > and clear definition of what should go into REQUIRES so that reverse > dependency mapping is reliable, I have absolutely no problem with > supporting it. > > Cheers, > Heinz -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From Alfredo.Tomasini at synaptics.com Tue Nov 25 19:01:03 2014 From: Alfredo.Tomasini at synaptics.com (Alfredo Tomasini) Date: Tue, 25 Nov 2014 19:01:03 +0000 Subject: [Slackbuilds-users] patch for HTMLDOC Message-ID: <5474D1EF.1060400@synaptics.com> This patch fix the problem of missing fonts under /usr/share/htmldoc/fonts A. -------------- next part -------------- A non-text attachment was scrubbed... Name: htmldoc.SlackBuild.patch Type: text/x-patch Size: 663 bytes Desc: htmldoc.SlackBuild.patch URL: From willysr at slackbuilds.org Sat Nov 29 23:16:50 2014 From: willysr at slackbuilds.org (Willy Sudiarto Raharjo) Date: Sun, 30 Nov 2014 06:16:50 +0700 Subject: [Slackbuilds-users] patch for HTMLDOC In-Reply-To: <5474D1EF.1060400@synaptics.com> References: <5474D1EF.1060400@synaptics.com> Message-ID: <547A53E2.9080803@slackbuilds.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > This patch fix the problem of missing fonts under > /usr/share/htmldoc/fonts Applied in yesterday's public update Thanks - -- Willy Sudiarto Raharjo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlR6U+IACgkQiHuDdNczM4HccwCdHQhoxYy1GYGFNhndWXFgjeuW HoQAoKG4nExDGdSgF+NcCAYwavtNe6KW =vpFx -----END PGP SIGNATURE-----