From molbolom at gmail.com Sun Jul 1 01:24:04 2012 From: molbolom at gmail.com (Charles Kauffman) Date: Sat, 30 Jun 2012 20:24:04 -0500 Subject: [Slackbuilds-users] Want the latest vifm.tar.gz removed from pending queue. In-Reply-To: <20120630224232.GO5332@pc21.mareichelt.com> References: <20120630224232.GO5332@pc21.mareichelt.com> Message-ID: I think I already have that taken care of, https://dl.dropbox.com/u/8119425/slackbuilds/vifm.diff, (Though didn't think about removing the comments in the slackbuild). Also, this is for 0.7.3a. Anyway, right now I'm trying to find the documentation explaining slackbuilds.org/cgit. Thanks. Charles quoting http://slackbuilds.org/ready/ > > 23-Jun-2012 09:35 vifm > > if you plan to submit a newer version, please base your updates on > this: > > http://slackbuilds.org/cgit/slackbuilds/commit/?h=gizzmo&id=2aaa36a6649a5e59ac220cc5f8cb85707b577798 > > which will be included in the upcoming public www update. > > -- > left blank, right bald > > _______________________________________________ > 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 rworkman at slackbuilds.org Sun Jul 1 02:38:46 2012 From: rworkman at slackbuilds.org (Robby Workman) Date: Sat, 30 Jun 2012 21:38:46 -0500 Subject: [Slackbuilds-users] Updates - 20120701.1 Message-ID: <20120630213846.07f185f0@liberty.rlwhome.lan> commit bff9d3f82786e334ce7929d2a9aedfb2fe0c429b Author: Robby Workman Date: Sat Jun 30 20:58:25 2012 -0500 Public www update: Sun Jul 1 01:58:10 UTC 2012 David put in some overtime on this batch ;-) academic/PhyML: Updated for version 20120412. academic/free42: Added (HP-42S calculator and HP-82240 printer) academic/g3data: Updated for version 1.5.4. academic/mathomatic: Updated for version 15.8.5. academic/seaview: Updated for version 4.3.4. academic/smath-studio: Updated for version 0.95. accessibility/pastebinit: Added (command-line pastebin client) audio/lash: Added HTML manual to docs. audio/mp3check: Updated for version 0.8.7. audio/mpc: Updated for version 0.22. audio/mutagen: Updated for version 1.20. desktop/Xfce-Theme-Manager: Updated for version 0.1.11. desktop/clipit: Added (lightweight fully featured clipboard manager) desktop/compiz-boxmenu: Updated for version 1.1.1. desktop/emerald-themes: Updated download link. desktop/i3: Updated for version 4.2. desktop/i3status: Updated for version 2.5.1. desktop/lxappearance: Updated for version 0.5.2, moved from misc. desktop/qlandkartegt: Updated for version 1.4.2. desktop/slack-wallpapers: Updated for version 0.116. desktop/xmms-skins-almond: Added (Almond skins for XMMS) desktop/xmobar: Updated for version 0.15. desktop/xmonad: Adjust build for ghc 7.4.x. development/alex: Updated for version 3.0.2. development/cgit: Updated for version 20120318_f50be7f. development/codeblocks: Updated download link. development/darcs: Updated for version 2.8.1. development/geany: Updated for version 1.22. development/happy: Updated for version 1.18.9. development/love: Updated for version 0.8.0. development/regexxer: Added (nifty GUI search/replace tool) development/scite: Updated for version 3.20. development/spl: Updated patches and fixed ncurses. development/tiled-qt: Updated for version 0.8.1. development/x86-mingw32-build: Added (Minimalistic GNU for Windows) games/ioquake3: Updated for version r2252. games/neverball: Updated for version 1.5.4. games/openarena: Updated for version 0.8.8. games/peg-e: Added (peg solitaire game) games/vbam: Updated for version 1.8.0.1054. games/yabause: Updated for version 0.9.11. games/yamagi-quake2: Updated for version 4.21. graphics/gnome-web-photo: Added (GNOME Web Photo) graphics/qrencode: Updated for version 3.3.1. haskell/ghc: Updated for version 7.4.2. haskell/haskell-Diff: Adjust build for ghc 7.4.x. haskell/haskell-GLURaw: Updated for version 1.2.0.0. haskell/haskell-GLUT: Updated for version 2.3.0.0. haskell/haskell-HTTP: Updated for version 4000.2.3. haskell/haskell-HUnit: Updated for version 1.2.4.3. haskell/haskell-MonadCatchIO-mtl: Adjust build for ghc 7.4.x. haskell/haskell-ObjectName: Adjust build for ghc 7.4.x. haskell/haskell-OpenGL: Updated for version 2.5.0.0. haskell/haskell-OpenGLRaw: Updated for version 1.2.0.0. haskell/haskell-QuickCheck: Adjust build for ghc 7.4.x. haskell/haskell-StateVar: Adjust build for ghc 7.4.x. haskell/haskell-Tensor: Adjust build for ghc 7.4.x. haskell/haskell-X11-xft: Updated for version 0.3.1. haskell/haskell-X11: Updated for version 1.6.0. haskell/haskell-ansi-terminal: Adjust build for ghc 7.4.x. haskell/haskell-ansi-wl-pprint: Updated for version 0.6.4. haskell/haskell-base64-bytestring: Updated for version 0.1.1.3. haskell/haskell-binary: Removed, included in ghc now. haskell/haskell-blaze-builder: Added (Efficient buffered output) haskell/haskell-blaze-html: Added (HTML combinator library) haskell/haskell-blaze-markup: Added (markup combinator library) haskell/haskell-bmp: Updated for version 1.2.1.1. haskell/haskell-cgi: Adjust build for ghc 7.4.x. haskell/haskell-citeproc-hs: Updated for version 0.3.4. haskell/haskell-dataenc: Adjust build for ghc 7.4.x. haskell/haskell-deepsec: Removed, included in ghc now. haskell/haskell-digest: Updated for version 0.0.1.1. haskell/haskell-dlist: Adjust build for ghc 7.4.x. haskell/haskell-editline: Adjust build for ghc 7.4.x. haskell/haskell-fgl: Adjust build for ghc 7.4.x. haskell/haskell-ghc-paths: Adjust build for ghc 7.4.x. haskell/haskell-gloss: Updated for version 1.7.4.1. haskell/haskell-hashed-storage: Adjust build for ghc 7.4.x. haskell/haskell-haskeline: Updated for version 0.6.4.7. haskell/haskell-haskell-src: Adjust build for ghc 7.4.x. haskell/haskell-highlighting-kate: Added (Syntax highlighting) haskell/haskell-hinotify: Updated for version 0.3.2. haskell/haskell-hostname: Adjust build for ghc 7.4.x. haskell/haskell-html: Adjust build for ghc 7.4.x. haskell/haskell-json: Updated for version 0.5. haskell/haskell-lcs: Adjust build for ghc 7.4.x. haskell/haskell-mmap: Adjust build for ghc 7.4.x. haskell/haskell-mtl: Updated for version 2.1.1. haskell/haskell-network: Updated for version 2.3.0.14. haskell/haskell-packedstring: Removed does not compile with GHC 7.4 haskell/haskell-pandoc-types: Updated for version 1.9.1. haskell/haskell-parallel: Updated for version 3.2.0.3. haskell/haskell-parsec: Updated for version 3.1.3. haskell/haskell-primitive: Added (Wrappers for primitive operations) haskell/haskell-random: Added (random number library) haskell/haskell-regex-base: Adjust build for ghc 7.4.x. haskell/haskell-regex-compat: Adjust build for ghc 7.4.x. haskell/haskell-regex-pcre-builtin: Added (PCRE backend) haskell/haskell-regex-posix: Updated for version 0.95.2. haskell/haskell-stm: Updated for version 2.3. haskell/haskell-syb: Updated for version 0.3.6.1. haskell/haskell-tagsoup: Updated for version 0.12.6. haskell/haskell-tar: Updated for version 0.4.0.0. haskell/haskell-temporary: Added (temporary file and dir. support) haskell/haskell-terminfo: Adjust build for ghc 7.4.x. haskell/haskell-test-framework-hunit: Updated for version 0.2.7. haskell/haskell-test-framework-quickcheck2: Updated for 0.2.12.2. haskell/haskell-test-framework: Updated for version 0.6. haskell/haskell-texmath: Updated for version 0.6.0.6. haskell/haskell-text: Updated for version 0.11.2.2. haskell/haskell-transformers: Updated for version 0.3.0.0. haskell/haskell-utf8-string: Adjust build for ghc 7.4.x. haskell/haskell-vector: Added (Efficient Arrays) haskell/haskell-xhtml: Updated for version 3000.2.1. haskell/haskell-xml: Updated for version 1.3.12. haskell/haskell-zip-archive: Updated for version 0.1.1.8. haskell/haskell-zlib: Updated for version 0.5.3.3. haskell/xmonad-contrib: Adjust build for ghc 7.4.x. libraries/Botan: Updated for version 1.10.2. libraries/c-ares: Updated for version 1.9.1. libraries/ecore: Updated for version 1.2.1. libraries/edje: Updated for version 1.2.1. libraries/eet: Updated for version 1.6.1. libraries/eina: Updated for version 1.2.1. libraries/evas: Updated for version 1.2.1. libraries/exempi: Updated for version 2.2.0. libraries/libeXosip2: Updated for version 3.6.0. libraries/libosip2: Updated for version 3.6.0. libraries/libspatialindex: Added (spatial indexing methods) libraries/mxml: Updated for version 2.7. libraries/php-pgsql: Added (PostgreSQL bindings for PHP) libraries/yaz: Updated for version 4.2.33. libraries/zfec: Updated for version 1.4.24. misc/figlet: Updated for version 2.2.5. misc/igal2: Added (image gallery generator) misc/ophcrack: Updated for version 3.4.0. multimedia/LiVES: Updated for version 1.6.1. multimedia/cueplayer: Updated for version svn_251. multimedia/flash-player-plugin: Updated for version 11.2.202.236. multimedia/miro: Updated for version 5.0.1. multimedia/rtmpdump: Updated for version 20120308_7340f6d. network/bitlbee: Updated for version 3.0.5. network/claws-mail-extra-plugins: Updated for version 3.8.1. network/claws-mail: Updated for version 3.8.1. network/exim: Updated for version 4.80. network/hiawatha: Updated for version 8.3.2. network/hydra: Updated for version 7.3. network/icecat: Updated for version 12.0. network/linphone: Updated for version 3.5.2. network/mosh: Updated for version 1.2.2. network/nicotine+: Updated download link. network/opera: Updated for version 12.00. network/smb4k: Updated for version 1.0.2. network/sshfs-fuse: Updated for version 2.4 (+new maintainer) network/tor: Updated for version 0.2.2.37. network/uwsgi: Updated for version 1.2.3. network/vidalia: Updated for version 0.2.19. network/weechat: Updated for version 0.3.8. network/wireshark: Updated for version 1.8.0. office/cups-pdf: Updated for version 3.0beta1. office/grisbi: Updated for version 0.8.9. office/myrulib: Updated for version 0.29.8. office/mytetra: Added (personal manager for information) office/texmaker: Updated for version 3.3.4. office/texstudio: Updated for version 2.3. perl/perl-DBD-SQLite: Updated for version 1.37. perl/perl-gtk2: Updated README. python/boto: Updated for version 2.4.1. python/distribute: Updated for version 0.6.27. python/foolscap: Updated for version 0.6.4, moved from libraries. python/mock: Updated for version 0.8.0. python/pyasn1: Updated for version 0.1.3. python/pycryptopp: Updated for version 0.6.0.120... python/python-twisted: Updated for version 12.1.0. python/pyutil: Updated for version 1.9.3. system/autojump: Updated for version 19. system/avfs: Added (virtual file system) system/cdwrite: Updated for version 3.5. system/clamav: Updated for version 0.97.5. system/dfc: Added (disk usage in color) system/emelfm2: Updated for version 0.8.1. system/gsettings-desktop-schemas: Added (GSettings Desktop Schemas) system/htop: Updated for version 1.0.1. system/laptop-mode-tools: Updated for version 1.61. system/postgresql: Updated for version 9.1.4. system/redis: Updated for version 2.4.14. system/rsyslog: Updated for version 5.8.12. system/scalpel: Added (A Frugal, High Performance File Carver) system/scanmem: Added (simple interactive debugging utility) system/terminus-font: Updated for version 4.36. system/unetbootin: Updated for version 575. system/vifm: Updated for version 0.7.3. system/virt-viewer: Updated for version 0.5.3. system/worker: Updated for version 2.19.3. +--------------------------+ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From rworkman at slackbuilds.org Sun Jul 1 02:39:58 2012 From: rworkman at slackbuilds.org (Robby Workman) Date: Sat, 30 Jun 2012 21:39:58 -0500 Subject: [Slackbuilds-users] Want the latest vifm.tar.gz removed from pending queue. In-Reply-To: References: <20120630224232.GO5332@pc21.mareichelt.com> Message-ID: <20120630213958.5dacf002@liberty.rlwhome.lan> On Sat, 30 Jun 2012 20:24:04 -0500 Charles Kauffman wrote: > I think I already have that taken care of, > https://dl.dropbox.com/u/8119425/slackbuilds/vifm.diff, (Though didn't > think about removing the comments in the slackbuild). Also, this is > for 0.7.3a. > > Anyway, right now I'm trying to find the documentation explaining > slackbuilds.org/cgit. Just do a git clone and look at everything in a shell - it's much easier (IMHO). Check out the Pro Git book (available for free online) for a primer on using git. -RW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From jabolopes at gmail.com Sun Jul 1 02:25:15 2012 From: jabolopes at gmail.com (=?ISO-8859-1?Q?Jos=E9_Lopes?=) Date: Sun, 01 Jul 2012 03:25:15 +0100 Subject: [Slackbuilds-users] gnome-theme-extras bug Message-ID: <4FEFB50B.7050904@gmail.com> Hello, When compiling package "gnome-theme-extras" the following line appears during "configure" stage: ./configure: line 13573: oc: command not found I have never heard of command "oc". This is a bug, right? Cheers, Jos? From rworkman at slackbuilds.org Sun Jul 1 03:02:37 2012 From: rworkman at slackbuilds.org (Robby Workman) Date: Sat, 30 Jun 2012 22:02:37 -0500 Subject: [Slackbuilds-users] libunrar In-Reply-To: <4F37F8F5.1040307@gmail.com> References: <4F37F8F5.1040307@gmail.com> Message-ID: <20120630220237.7ceac9d7@liberty.rlwhome.lan> On Sun, 12 Feb 2012 18:37:57 +0100 Niklas Nille ?kerstr?m wrote: > Since libunrar uses the same source as unrar maybe the SlackBuilds > should be merged. > Also whats the point with "include" containing most of the source > code? Most distributions only include dll.hpp Hi Nille, This would be be addressed with the maintainer (CC'd), as I had no strong opinion either way, and what he submitted worked fine (as usual). -RW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From molbolom at gmail.com Sun Jul 1 03:30:11 2012 From: molbolom at gmail.com (Charles Kauffman) Date: Sat, 30 Jun 2012 22:30:11 -0500 Subject: [Slackbuilds-users] Want the latest vifm.tar.gz removed from pending queue. In-Reply-To: <20120630213958.5dacf002@liberty.rlwhome.lan> References: <20120630224232.GO5332@pc21.mareichelt.com> <20120630213958.5dacf002@liberty.rlwhome.lan> Message-ID: Hi! Thanks, but git wasn't what I was wanting to know. I was wanting to understand the purpose of the diff. When MR had written "if you plan to submit a newer version, please base your updates on this:", I wasn't exactly sure what he was talking about since I had thought I already made most if not all of those changes that are in the diff. Unfortunately, I couldn't find anything to explain what the purpose was, so if you or MR will, could I get a little help in understanding what was meant by "base your updates on this"? Thanks. Charles On Sat, Jun 30, 2012 at 9:39 PM, Robby Workman wrote: > On Sat, 30 Jun 2012 20:24:04 -0500 > Charles Kauffman wrote: > > > I think I already have that taken care of, > > https://dl.dropbox.com/u/8119425/slackbuilds/vifm.diff, (Though didn't > > think about removing the comments in the slackbuild). Also, this is > > for 0.7.3a. > > > > Anyway, right now I'm trying to find the documentation explaining > > slackbuilds.org/cgit. > > > Just do a git clone and look at everything in a shell - it's much > easier (IMHO). Check out the Pro Git book (available for free > online) for a primer on using git. > > -RW > > _______________________________________________ > 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 rworkman at slackbuilds.org Sun Jul 1 03:37:35 2012 From: rworkman at slackbuilds.org (Robby Workman) Date: Sat, 30 Jun 2012 22:37:35 -0500 Subject: [Slackbuilds-users] Want the latest vifm.tar.gz removed from pending queue. In-Reply-To: References: <20120630224232.GO5332@pc21.mareichelt.com> <20120630213958.5dacf002@liberty.rlwhome.lan> Message-ID: <20120630223735.381e30cb@liberty.rlwhome.lan> On Sat, 30 Jun 2012 22:30:11 -0500 Charles Kauffman wrote: > Thanks, but git wasn't what I was wanting to know. I was wanting to > understand the purpose of the diff. > When MR had written "if you plan to submit a newer version, please > base your updates on this:", I wasn't exactly sure what he was > talking about since I had thought I already made most if not all of > those changes that are in the diff. > Unfortunately, I couldn't find anything to explain what the purpose > was, so if you or MR will, could I get a little help in understanding > what was meant by "base your updates on this"? Oh, basically, it just means that new updates to anything in our repo should be based on what is in the repo (as opposed to the maintainer's local copy). -RW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From rworkman at slackbuilds.org Sun Jul 1 04:17:53 2012 From: rworkman at slackbuilds.org (Robby Workman) Date: Sat, 30 Jun 2012 23:17:53 -0500 Subject: [Slackbuilds-users] shntool, shorten, and xmms-shn websites have changed In-Reply-To: References: Message-ID: <20120630231753.463b47da@liberty.rlwhome.lan> On Sat, 16 Jun 2012 14:32:20 -0700 Josiah Boothby wrote: > shntool and shorten are no longer being hosted on freeshell.org, but > rather etree.org: > > shntool: > http://www.etree.org/shnutils/shntool/ > http://www.etree.org/shnutils/shntool/dist/src/shntool-3.0.10.tar.gz Someone else reported this one earlier, so it's fixed but credited to them. > shorten: > http://www.etree.org/shnutils/shorten/ > http://www.etree.org/shnutils/shorten/dist/src/shorten-3.6.1.tar.gz > > xmms-shn: > http://www.etree.org/shnutils/xmms-shn/ > http://www.etree.org/shnutils/xmms-shn/dist/src/xmms-shn-2.4.1.tar.gz These two are now fixed in my git branch (credited to you). Thanks! -RW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From rworkman at slackbuilds.org Sun Jul 1 04:20:49 2012 From: rworkman at slackbuilds.org (Robby Workman) Date: Sat, 30 Jun 2012 23:20:49 -0500 Subject: [Slackbuilds-users] tbb and libtbb In-Reply-To: References: Message-ID: <20120630232049.5455811a@liberty.rlwhome.lan> On Sun, 29 Apr 2012 19:52:53 +0500 Ozan T?rky?lmaz wrote: > From: Ozan T?rky?lmaz > To: "SlackBuilds.org Users List" > Subject: [Slackbuilds-users] tbb and libtbb > Date: Sun, 29 Apr 2012 19:52:53 +0500 > Reply-To: "SlackBuilds.org Users List" > Sender: > slackbuilds-users-bounces at slackbuilds.org > > Hello Everyone, > > I noticed that there are tbb and libtbb in the repo. They are same > thing expect that tbb is better maintained so I propose that admins > delete my script (libtbb) from the repo, make a note in the checngelog > about migrating to tbb and be done with it. Committed in my git branch. Thanks! -RW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From rworkman at slackbuilds.org Sun Jul 1 04:40:40 2012 From: rworkman at slackbuilds.org (Robby Workman) Date: Sat, 30 Jun 2012 23:40:40 -0500 Subject: [Slackbuilds-users] new maintainer for Weboob SlackBuild In-Reply-To: <20120514220228.GC48980@banh-bao.fr> References: <20120514220228.GC48980@banh-bao.fr> Message-ID: <20120630234040.64973075@liberty.rlwhome.lan> On Tue, 15 May 2012 00:02:28 +0200 Brice Lopez wrote: > From: Brice Lopez > To: slackbuilds-users at slackbuilds.org > Subject: [Slackbuilds-users] new maintainer for Weboob SlackBuild > Date: Tue, 15 May 2012 00:02:28 +0200 > Reply-To: Brice Lopez , > "SlackBuilds.org Users List" > Sender: slackbuilds-users-bounces at slackbuilds.org > User-Agent: Mutt/1.4.2.3i > > Hi, > > I am the current maintainer of the weboob Slackbuild. > This software evolve really quickly, and I can't update the slackbuild > for each release. > > Brandon, a guy from the development team, has proposed to become the > maintainer. By this way, weboob and the slackbuild will stay > synchronized. > > So, it was just to say I allow him to become the maintainer of this > script. > > New maintainer : > Brandon Soonaye > brandonsoonaye at live.fr Done in my git branch. -RW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From rworkman at slackbuilds.org Sun Jul 1 04:45:27 2012 From: rworkman at slackbuilds.org (Robby Workman) Date: Sat, 30 Jun 2012 23:45:27 -0500 Subject: [Slackbuilds-users] Date-Manip-6.25.tar.gz link is dead In-Reply-To: References: Message-ID: <20120630234527.3e7a5fa4@liberty.rlwhome.lan> On Sat, 14 Apr 2012 17:09:21 -0600 JCA <1.41421 at gmail.com> wrote: > The link to the Date-Manip-6.25.tar.gz tarball is dead. Fixed in my git branch. -RW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From rworkman at slackbuilds.org Sun Jul 1 04:57:21 2012 From: rworkman at slackbuilds.org (Robby Workman) Date: Sat, 30 Jun 2012 23:57:21 -0500 Subject: [Slackbuilds-users] ftgl script: some linking problems under -current In-Reply-To: <20120421233855.GA5078@skamandros.andrews-corner.org> References: <20120421233855.GA5078@skamandros.andrews-corner.org> Message-ID: <20120630235721.19f19036@liberty.rlwhome.lan> On Sun, 22 Apr 2012 09:38:56 +1000 andrew wrote: > Hi, > > I realise that -current is not really supported here but I thought I > might mention that there are some linking problems with ftgl under > -current and compile fails (I have not tested under 1337). Compilation > succeeds when these are added: > > make GLUT_LIBS="$(GLUT_LIBS) -lglut -lGLU -lGL -lm" > > which I have stolen from Debian packaging of ftgl. Committed into my git branch (with slight modification). -RW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From rworkman at slackbuilds.org Sun Jul 1 05:00:59 2012 From: rworkman at slackbuilds.org (Robby Workman) Date: Sun, 1 Jul 2012 00:00:59 -0500 Subject: [Slackbuilds-users] unixODBC In-Reply-To: References: Message-ID: <20120701000059.088a2c5a@liberty.rlwhome.lan> On Sat, 7 Apr 2012 11:24:51 -0500 (CDT) "Mr. B-o-B" wrote: > I just wanted you all to know that going forward I will be > maintaining the unixODBC package. I rely heavily on this package, > and Henrique (the original maintainer) mentioned he no longer uses it. Done in my git branch. Thanks! -RW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From mario at slackverse.org Sun Jul 1 10:09:09 2012 From: mario at slackverse.org (Mario) Date: Sun, 01 Jul 2012 12:09:09 +0200 Subject: [Slackbuilds-users] libunrar In-Reply-To: <20120630220237.7ceac9d7@liberty.rlwhome.lan> References: <4F37F8F5.1040307@gmail.com> <20120630220237.7ceac9d7@liberty.rlwhome.lan> Message-ID: <4FF021C5.1060702@slackverse.org> On 07/01/2012 05:02 AM, Robby Workman wrote: > On Sun, 12 Feb 2012 18:37:57 +0100 > Niklas Nille ?kerstr?m wrote: > >> Since libunrar uses the same source as unrar maybe the SlackBuilds >> should be merged. >> Also whats the point with "include" containing most of the source >> code? Most distributions only include dll.hpp > > > Hi Nille, > > This would be be addressed with the maintainer (CC'd), as > I had no strong opinion either way, and what he submitted > worked fine (as usual). > > -RW > Hey guys, 1. maintainer of the unrar SlackBuild never replied about adding includes into his SlackBuild, and eventualy I gave in and made it simple 2. libunrar is required by rar2fs 3. as far as I can remember, whole include is required to build rar2fs m. From klaatu at straightedgelinux.com Sun Jul 1 11:29:06 2012 From: klaatu at straightedgelinux.com (Klaatu) Date: Sun, 1 Jul 2012 07:29:06 -0400 Subject: [Slackbuilds-users] gnome-theme-extras bug In-Reply-To: <4FEFB50B.7050904@gmail.com> References: <4FEFB50B.7050904@gmail.com> Message-ID: <201207010729.06260.klaatu@straightedgelinux.com> > Hello, > > When compiling package "gnome-theme-extras" the following line appears > during "configure" stage: > ./configure: line 13573: oc: command not found > > I have never heard of command "oc". This is a bug, right? > > Cheers, > Jos? > _______________________________________________ > 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/ In my experience so far, errors during the ./configure are caused by missing dependencies. Do have a GTK theme engine installed? The gnome-theme-extras README file says you have to have GTK-engines installed (although I think qt- gtk-engine would work too). It bult for me just now when I tried it, so I'd check to make sure you're working on a stable full install of Slackware, with a GTK theme engine installed. Hope that helps. -- klaatu From ozan.turkyilmaz at gmail.com Sun Jul 1 13:09:25 2012 From: ozan.turkyilmaz at gmail.com (=?UTF-8?B?T3phbiBUw7xya3nEsWxtYXo=?=) Date: Sun, 1 Jul 2012 18:09:25 +0500 Subject: [Slackbuilds-users] libunrar In-Reply-To: <4FF021C5.1060702@slackverse.org> References: <4F37F8F5.1040307@gmail.com> <20120630220237.7ceac9d7@liberty.rlwhome.lan> <4FF021C5.1060702@slackverse.org> Message-ID: 2012/7/1 Mario : > Hey guys, > > 1. maintainer of the unrar SlackBuild never replied about adding includes > into his SlackBuild, and eventualy I gave in and made it simple > 2. libunrar is required by rar2fs > 3. as far as I can remember, whole include is required to build rar2fs It's been a while since I played with unrar but that was what I remember as well. You need whole includes for better usage -- Ozan, BSc, BEng From mr.chew.baka at gmail.com Sun Jul 1 14:23:37 2012 From: mr.chew.baka at gmail.com (=?utf-8?B?bXIuY2hldy5iYWthQGdtYWlsLmNvbQ==?=) Date: Sun, 01 Jul 2012 09:23:37 -0500 Subject: [Slackbuilds-users] =?utf-8?q?unixODBC?= Message-ID: <4ff05d62.8124320a.1bcf.fffff05a@mx.google.com> Thanks! Bob Sent via my mobile handheld communications device ----- Reply message ----- From: "Robby Workman" To: "SlackBuilds.org Users List" Cc: Subject: [Slackbuilds-users] unixODBC Date: Sun, Jul 1, 2012 00:00 On Sat, 7 Apr 2012 11:24:51 -0500 (CDT) "Mr. B-o-B" wrote: > I just wanted you all to know that going forward I will be > maintaining the unixODBC package. I rely heavily on this package, > and Henrique (the original maintainer) mentioned he no longer uses it. Done in my git branch. Thanks! -RW -------------- next part -------------- An HTML attachment was scrubbed... URL: From c at catcons.co.uk Sun Jul 1 09:34:37 2012 From: c at catcons.co.uk (Charles) Date: Sun, 01 Jul 2012 10:34:37 +0100 Subject: [Slackbuilds-users] spideroak "source" changed Message-ID: <4FF019AD.1080802@catcons.co.uk> The network/spideroak package fails because the MD5 sum is incorrect because the "source" (actually an ubuntu lucid .deb) has been updated. This was confirmed by spideroak support. I mailed the maintainer on 14 June but have had no reply. AFAIK, the version is now 4.6.9945 and the MD5 sum for the 32-bit .deb is 3c99dc20ca1554fd5ad87f7078814db9 From asido4 at gmail.com Sun Jul 1 19:15:42 2012 From: asido4 at gmail.com (Arvydas Sidorenko) Date: Sun, 01 Jul 2012 21:15:42 +0200 Subject: [Slackbuilds-users] gnome-theme-extras bug In-Reply-To: <4FEFB50B.7050904@gmail.com> References: <4FEFB50B.7050904@gmail.com> Message-ID: <4FF0A1DE.2010608@gmail.com> On 07/01/2012 04:25 AM, Jos? Lopes wrote: > Hello, > > When compiling package "gnome-theme-extras" the following line appears > during "configure" stage: > ./configure: line 13573: oc: command not found > > I have never heard of command "oc". This is a bug, right? > > Cheers, > Jos? > _______________________________________________ > 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/ > `oc` is obviously not a command. It specifies Occitanian language. There is a bug in configure.in:46 - missing quotes or added extra space. If you are reporting because the build breaks - look for something else in the output because it does not break the build. if you are reporting because it caught your eye - that should go to upstream as a bug report. Arvydas Sidorenko From biolizard.mail at gmail.com Sun Jul 1 21:32:14 2012 From: biolizard.mail at gmail.com (=?UTF-8?B?Sm9zw6kgTG9wZXM=?=) Date: Sun, 01 Jul 2012 22:32:14 +0100 Subject: [Slackbuilds-users] gnome-theme-extras bug In-Reply-To: <4FF0A1DE.2010608@gmail.com> References: <4FEFB50B.7050904@gmail.com> <4FF0A1DE.2010608@gmail.com> Message-ID: <4FF0C1DE.1010109@gmail.com> Hey Arvydas, It does NOT break the build. In fact, it installs and works great! I was just wondering whether anybody had some thoughts on that. Cheers, Jos? On Dom 01 Jul 2012 20:15:42 WEST, Arvydas Sidorenko wrote: > On 07/01/2012 04:25 AM, Jos? Lopes wrote: >> Hello, >> >> When compiling package "gnome-theme-extras" the following line >> appears during "configure" stage: >> ./configure: line 13573: oc: command not found >> >> I have never heard of command "oc". This is a bug, right? >> >> Cheers, >> Jos? >> _______________________________________________ >> 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/ >> > `oc` is obviously not a command. It specifies Occitanian language. > There is a bug in configure.in:46 - missing quotes or added extra space. > If you are reporting because the build breaks - look for something > else in the output because it does not break the build. > if you are reporting because it caught your eye - that should go to > upstream as a bug report. > > Arvydas Sidorenko > > _______________________________________________ > 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 rworkman at slackbuilds.org Mon Jul 2 06:24:14 2012 From: rworkman at slackbuilds.org (Robby Workman) Date: Mon, 2 Jul 2012 01:24:14 -0500 Subject: [Slackbuilds-users] Updates - 20120702.1 Message-ID: <20120702012414.2db3358d@liberty.rlwhome.lan> commit 76e28cd63176659c6b686a9972b1a77f591c6264 Author: Robby Workman Date: Mon Jul 2 01:17:24 2012 -0500 Public www update: Mon Jul 2 06:16:36 UTC 2012 Mon Jul 2 06:16:36 UTC 2012 academic/units: Updated for version 2.00. audio/shntool: Fixed homepage and download link audio/shorten: Fixed homepage and download link audio/xmms-shn: Fixed homepage and download link development/source-highlight: Updated for version 3.1.7. libraries/avr-libc: Updated for version 1.8.0. libraries/ftgl: Fixed build with newer gcc libraries/libtbb: Removed (use libraries/tbb instead) libraries/unixODBC: New maintainer network/skype: Updated for version 4.0.0.7. network/weboob: Change of maintainer office/evince: Note GConf dependency office/mu: Updated for version 0.9.8.4. office/notmuch: Updated for version 0.13.2. perl/perl-Date-Manip: Fixed download link system/rodent: Updated for version 4.8.0. system/wine: Updated for version 1.4.1. system/worker: Noted avfs requirement in README +--------------------------+ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From lukenshiro at ngi.it Mon Jul 2 07:21:32 2012 From: lukenshiro at ngi.it (LukenShiro) Date: Mon, 2 Jul 2012 09:21:32 +0200 Subject: [Slackbuilds-users] qupzilla download links Message-ID: <20120702092132.50d69c03@hamalay.mnt> Current download links for qupzilla are broken. New download links are: https://github.com/downloads/QupZilla/qupzilla/qupzilla_1.2.0_i386.tar.gz and https://github.com/downloads/QupZilla/qupzilla/qupzilla_1.2.0_amd64.tar.gz -- GNU/Linux * Slackware64 current LU #210970 SU #12583 LM #98222/#412913 From ppetrov at mail.student.oulu.fi Mon Jul 2 09:26:26 2012 From: ppetrov at mail.student.oulu.fi (Petar Petrov) Date: Mon, 02 Jul 2012 12:26:26 +0300 Subject: [Slackbuilds-users] fltk13 download link In-Reply-To: <20120627161958.EEEE6223@m0005299.ppops.net> References: <20120627161958.EEEE6223@m0005299.ppops.net> Message-ID: <20120702122626.z5d1jrpoo6cckok4@webmail.oulu.fi> hi to all the download link for fltk13 does not work anymore: http://ftp.funet.fi/pub/mirrors/ftp.easysw.com/pub/fltk/snapshots/fltk-1.3.x-r9204.tar.bz2 heh, the download link for seaview does not work anymore either, so i will have to submit an update again soon. regards, petar From cancellor2 at gmail.com Mon Jul 2 11:38:49 2012 From: cancellor2 at gmail.com (Fridrich von Stauffenberg) Date: Mon, 02 Jul 2012 14:38:49 +0300 Subject: [Slackbuilds-users] qupzilla download links In-Reply-To: <20120702092132.50d69c03@hamalay.mnt> References: <20120702092132.50d69c03@hamalay.mnt> Message-ID: <4FF18849.3040300@gmail.com> Fixed. 02.07.2012 10:21, LukenShiro ?????: > Current download links for qupzilla are broken. > New download links are: > https://github.com/downloads/QupZilla/qupzilla/qupzilla_1.2.0_i386.tar.gz > and > https://github.com/downloads/QupZilla/qupzilla/qupzilla_1.2.0_amd64.tar.gz From lukenshiro at ngi.it Mon Jul 2 12:09:28 2012 From: lukenshiro at ngi.it (LukenShiro) Date: Mon, 2 Jul 2012 14:09:28 +0200 Subject: [Slackbuilds-users] fltk13 download link In-Reply-To: <20120702122626.z5d1jrpoo6cckok4@webmail.oulu.fi> References: <20120627161958.EEEE6223@m0005299.ppops.net> <20120702122626.z5d1jrpoo6cckok4@webmail.oulu.fi> Message-ID: <20120702140928.41db3ca1@hamalay.mnt> Il giorno Mon, 02 Jul 2012 12:26:26 +0300 Petar Petrov ha scritto: > hi to all > > the download link for fltk13 does not work anymore: > > http://ftp.funet.fi/pub/mirrors/ftp.easysw.com/pub/fltk/snapshots/fltk-1.3.x-r9204.tar.bz2 Thank you. I will submit a more recent snapshot ASAP :-) Regards. -- GNU/Linux * Slackware64 current LU #210970 SU #12583 LM #98222/#412913 From ppetrov at mail.student.oulu.fi Mon Jul 2 12:52:13 2012 From: ppetrov at mail.student.oulu.fi (Petar Petrov) Date: Mon, 02 Jul 2012 15:52:13 +0300 Subject: [Slackbuilds-users] fltk13 download link In-Reply-To: <20120702140928.41db3ca1@hamalay.mnt> References: <20120627161958.EEEE6223@m0005299.ppops.net> <20120702122626.z5d1jrpoo6cckok4@webmail.oulu.fi> <20120702140928.41db3ca1@hamalay.mnt> Message-ID: <20120702155213.ycuqdtlt0kgg8cww@webmail.oulu.fi> hi again it seems the download link for fltk2 does not work anymore either -petar From dcharles at alumni.concordia.ca Mon Jul 2 10:08:49 2012 From: dcharles at alumni.concordia.ca (Didier Charles) Date: Mon, 2 Jul 2012 06:08:49 -0400 Subject: [Slackbuilds-users] difference in repository listing and SLACKBUILDS.TXT (re: sshfs-fuse) Message-ID: I use http://slackbuilds.org/slackbuilds/13.37/SLACKBUILDS.TXT to look for changes in installed slackbuilds. Today, when I did so I noticed that sshfs-fuse had been updated. When I went to the address listed in "SLACKBUILD LOCATION: ./network/sshfs-fuse" (i.e. http://slackbuilds.org/repository/13.37/network/sshfs-fuse/ ) I was met with a "Page Not Found" notice. When I looked it up on the website, it came up as http://slackbuilds.org/repository/13.37/system/sshfs-fuse/ In other words the SLACKBUILDS.TXT doesn't accord with the repository. I haven't run into this before. -------------- next part -------------- An HTML attachment was scrubbed... URL: From invitations at linkedin.com Mon Jul 2 11:06:01 2012 From: invitations at linkedin.com (Gaddiel Espinosa (LinkedIn Invitations)) Date: Mon, 2 Jul 2012 11:06:01 +0000 (UTC) Subject: [Slackbuilds-users] Reminder about your invitation from Gaddiel Espinosa Message-ID: <922587035.3515602.1341227161999.JavaMail.app@ela4-bed46.prod> LinkedIn ------------ This is a reminder that on June 26, Gaddiel Espinosa sent you an invitation to become part of their professional network at LinkedIn. Accept Gaddiel Espinosa's Invitation ---------- On June 26, Gaddiel Espinosa wrote: > To: slackbuilds [slackbuilds-users at slackbuilds.org] > From: Gaddiel Espinosa [gaddiel.espinosa at gmail.com] > Subject: Invitation to connect on LinkedIn > > I'd like to add you to my professional network on LinkedIn. > > - Gaddiel ---------- You are receiving Reminder emails for pending invitations. Click to unsubscribe: http://www.linkedin.com/e/buoez-h45g0tjf-p/qh2erSQbBHCWcylzqTUaN8QB1CaGlf_zCu6AegNbi2ne5tr1dr/goo/slackbuilds-users%40slackbuilds%2Eorg/20060/I2584554391_1/?hs=false&tok=3R0v8gnVxW5Rk1 (c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rworkman at slackbuilds.org Mon Jul 2 13:22:59 2012 From: rworkman at slackbuilds.org (Robby Workman) Date: Mon, 2 Jul 2012 08:22:59 -0500 Subject: [Slackbuilds-users] Reminder about your invitation from Gaddiel Espinosa In-Reply-To: <922587035.3515602.1341227161999.JavaMail.app@ela4-bed46.prod> References: <922587035.3515602.1341227161999.JavaMail.app@ela4-bed46.prod> Message-ID: <20120702082259.3efb8b48@liberty.rlwhome.lan> Eek, sorry - I got click-happy doing the list moderation :/ -RW On Mon, 2 Jul 2012 11:06:01 +0000 (UTC) "Gaddiel Espinosa (LinkedIn Invitations)" wrote: > LinkedIn > ------------ > > > This is a reminder that on June 26, Gaddiel Espinosa sent you an > invitation to become part of their professional network at LinkedIn. > > Accept Gaddiel Espinosa's Invitation > > ---------- > On June 26, Gaddiel Espinosa wrote: > > > To: slackbuilds [slackbuilds-users at slackbuilds.org] > > From: Gaddiel Espinosa [gaddiel.espinosa at gmail.com] > > Subject: Invitation to connect on LinkedIn > > > > I'd like to add you to my professional network on LinkedIn. > > > > - Gaddiel > > ---------- > > You are receiving Reminder emails for pending invitations. Click to > unsubscribe: > http://www.linkedin.com/e/buoez-h45g0tjf-p/qh2erSQbBHCWcylzqTUaN8QB1CaGlf_zCu6AegNbi2ne5tr1dr/goo/slackbuilds-users%40slackbuilds%2Eorg/20060/I2584554391_1/?hs=false&tok=3R0v8gnVxW5Rk1 > > (c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA > 94043, USA. > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From rworkman at slackbuilds.org Mon Jul 2 13:25:16 2012 From: rworkman at slackbuilds.org (Robby Workman) Date: Mon, 2 Jul 2012 08:25:16 -0500 Subject: [Slackbuilds-users] difference in repository listing and SLACKBUILDS.TXT (re: sshfs-fuse) In-Reply-To: References: Message-ID: <20120702082516.35d73b76@liberty.rlwhome.lan> On Mon, 2 Jul 2012 06:08:49 -0400 Didier Charles wrote: > I use http://slackbuilds.org/slackbuilds/13.37/SLACKBUILDS.TXT to > look for changes in installed slackbuilds. Today, when I did so I > noticed that sshfs-fuse had been updated. When I went to the address > listed in "SLACKBUILD LOCATION: ./network/sshfs-fuse" (i.e. > http://slackbuilds.org/repository/13.37/network/sshfs-fuse/ ) I was > met with a "Page Not Found" notice. > When I looked it up on the website, it came up as > http://slackbuilds.org/repository/13.37/system/sshfs-fuse/ > In other words the SLACKBUILDS.TXT doesn't accord with the > repository. I haven't run into this before. Error on our end - sorry about that. It's fixed now. -RW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From lukenshiro at ngi.it Mon Jul 2 17:39:51 2012 From: lukenshiro at ngi.it (LukenShiro) Date: Mon, 2 Jul 2012 19:39:51 +0200 Subject: [Slackbuilds-users] gnubg download link Message-ID: <20120702193951.7aa42adf@hamalay.mnt> Hi all, download link for gnubg appears to be broken (source file has been removed). BTW last snapshot (20120702) compiles (I've just used an explicit --datadir flag in ./configure, as /usr/share/doc seemed ugly to me :P) and runs well (at first sight). TIA. Regards. -- GNU/Linux * Slackware64 current LU #210970 SU #12583 LM #98222/#412913 From slackware at caisteal.net Mon Jul 2 16:53:38 2012 From: slackware at caisteal.net (W. Dean Milner) Date: Mon, 02 Jul 2012 13:53:38 -0300 Subject: [Slackbuilds-users] Reminder about your invitation from Gaddiel Espinosa In-Reply-To: <20120702082259.3efb8b48@liberty.rlwhome.lan> References: <922587035.3515602.1341227161999.JavaMail.app@ela4-bed46.prod> <20120702082259.3efb8b48@liberty.rlwhome.lan> Message-ID: <4FF1D212.7020608@caisteal.net> Such invitations should be made individually and blanket invites to entire lists should be treated as spam. Just MHO. On 2012.07.02 10:22, Robby Workman wrote: > Eek, sorry - I got click-happy doing the list moderation :/ > > -RW > > On Mon, 2 Jul 2012 11:06:01 +0000 (UTC) > "Gaddiel Espinosa (LinkedIn Invitations)" > wrote: > >> LinkedIn >> ------------ >> >> >> This is a reminder that on June 26, Gaddiel Espinosa sent you an >> invitation to become part of their professional network at LinkedIn. >> >> Accept Gaddiel Espinosa's Invitation >> >> ---------- >> On June 26, Gaddiel Espinosa wrote: >> >>> To: slackbuilds [slackbuilds-users at slackbuilds.org] >>> From: Gaddiel Espinosa [gaddiel.espinosa at gmail.com] >>> Subject: Invitation to connect on LinkedIn >>> >>> I'd like to add you to my professional network on LinkedIn. >>> >>> - Gaddiel >> >> ---------- >> >> You are receiving Reminder emails for pending invitations. Click to >> unsubscribe: >> http://www.linkedin.com/e/buoez-h45g0tjf-p/qh2erSQbBHCWcylzqTUaN8QB1CaGlf_zCu6AegNbi2ne5tr1dr/goo/slackbuilds-users%40slackbuilds%2Eorg/20060/I2584554391_1/?hs=false&tok=3R0v8gnVxW5Rk1 >> >> (c) 2012 LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA >> 94043, USA. >> >> >> >> _______________________________________________ >> 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 rworkman at slackbuilds.org Mon Jul 2 21:31:55 2012 From: rworkman at slackbuilds.org (Robby Workman) Date: Mon, 2 Jul 2012 16:31:55 -0500 Subject: [Slackbuilds-users] Reminder about your invitation from Gaddiel Espinosa In-Reply-To: <4FF1D212.7020608@caisteal.net> References: <922587035.3515602.1341227161999.JavaMail.app@ela4-bed46.prod> <20120702082259.3efb8b48@liberty.rlwhome.lan> <4FF1D212.7020608@caisteal.net> Message-ID: <20120702163155.72fcc261@liberty.rlwhome.lan> On Mon, 02 Jul 2012 13:53:38 -0300 "W. Dean Milner" wrote: > Such invitations should be made individually and blanket invites to > entire lists should be treated as spam. Just MHO. Yes, that was my point. I normally just delete those when I'm doing list moderation, but I accidentally clicked "Accept" on that one and another (which was valid). I generally place list members who do that on moderation too :-) -RW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From matteo.bernardini at gmail.com Thu Jul 5 16:20:29 2012 From: matteo.bernardini at gmail.com (Matteo Bernardini) Date: Thu, 5 Jul 2012 18:20:29 +0200 Subject: [Slackbuilds-users] qemu and qemu-kvm merge Message-ID: Hi folks, I'm back with the proposal of a few months ago about a merge of qemu and qemu-kvm to avoid incompatibilities between the two generated packages, so that we can use qemu-kvm for our native (x86 and x86_64) emulation needs and qemu for emulating arm and other archs. I spotted a nice option in the configure, --with-confsuffix: specifying --with-confsuffix=/qemu-kvm for qemu-kvm let us install firmware in /usr/share/qemu-kvm and configurations in /etc/qemu-kvm, avoiding the fatal overlapping. This way only some non-influent binaries like qemu-nbd and qemu-img overlap, but we can safely use the ones from qemu. I'm using the resulting qemu package on my virtualizers with no problems. If you want to have a look at the modifications, they're here (I made also another notable addition to the configure, --disable-debug-info: this way I eliminated two seds) http://cgit.ponce.cc/slackbuilds/commit/?h=qemu I attach also a tarball, to let you try more easily. Let me know if you like it: obviously I'm not maintaining any of the two packages and I will be very happy to hear some opinion on this from them. :) Matteo P.S. Obviously, incompatibilities can be avoided also using simply the --with-confsuffix=/qemu-kvm in the qemu-kvm.SlackBuild, but I liked the idea of the single package. -------------- next part -------------- A non-text attachment was scrubbed... Name: qemu.tar.gz Type: application/x-gzip Size: 5170 bytes Desc: not available URL: From j at dawnrazor.net Mon Jul 9 16:20:42 2012 From: j at dawnrazor.net (J) Date: Mon, 09 Jul 2012 11:20:42 -0500 Subject: [Slackbuilds-users] requirements in README files Message-ID: <20120709112042.Horde.im3MDogBVY5P_wTaY8lf2xA@mail.dawnrazor.net> I'm wondering if there's any hope at all of perhaps enforcing slackbuilds to have a consistent format in their README files for listing requirements. Currently we see a very wide variety of formats. While the most popular looks something like: This requires perl-Params-Validate, perl-DateTime-Locale, perl-DateTime-TimeZone, perl-Test-Exception, perl-Sub-Uplevel perl-Math-Round. There are many, many variations, even on this theme, and many others besides. Here are some fun examples: Requires: perl-Convert-BinHex perl-IO-stringy perl-MailTools This package requires perl-Class-Gomor and libdnet, from SlackBuilds.org perl-Mail-SPF requires (in that order): 1. perl-digest-sha1 2. perl-digest-hmac 3. perl-NetAddr-IP 4. perl-Net-DNS 5. perl-Net-DNS-Resolver-Programmable Xplanet is required to use PlasmaXPlanet. Here's a really nice one: This requires zope.component and gaphas. To build, this requires pysetuptools, setuptools-git and nose. And those are only examples which contain the word "require". Needless to say, this makes it highly non-trivial to parse requirements out of README files. An ideal solution would be add this info in a file somewhere, for example into the .info file. But they would still need to be in the README, cause that just makes good sense. So it makes some sort of sense to just have them in the README. Consistency in that regard would be very useful. I understand it may not make the most sense to apply this to all existent slackbuilds, but that's okay, cause 14.0 is on the horizon; perhaps this could be applied starting with 14.0? I appreciate your time and consideration. J From Hullen at t-online.de Mon Jul 9 16:58:00 2012 From: Hullen at t-online.de (Helmut Hullen) Date: 09 Jul 2012 18:58:00 +0200 Subject: [Slackbuilds-users] requirements in README files In-Reply-To: <20120709112042.Horde.im3MDogBVY5P_wTaY8lf2xA@mail.dawnrazor.net> Message-ID: Hallo, J, Du meintest am 09.07.12: > I'm wondering if there's any hope at all of perhaps enforcing > slackbuilds to have a consistent format in their README files for > listing requirements. The README is created from the author/maintainer of the program. The SBO maintainer should not change it. > Currently we see a very wide variety of formats. While the most > popular looks something like: > This requires perl-Params-Validate, perl-DateTime-Locale, > perl-DateTime-TimeZone, perl-Test-Exception, perl-Sub-Uplevel > perl-Math-Round. That's another problem - these informations should be put into "install/ slack-required". And that could be a job for the SBO maintainer. Viele Gruesse! Helmut From ml at mareichelt.com Mon Jul 9 17:24:47 2012 From: ml at mareichelt.com (markus reichelt) Date: Mon, 9 Jul 2012 19:24:47 +0200 Subject: [Slackbuilds-users] requirements in README files In-Reply-To: <20120709112042.Horde.im3MDogBVY5P_wTaY8lf2xA@mail.dawnrazor.net> References: <20120709112042.Horde.im3MDogBVY5P_wTaY8lf2xA@mail.dawnrazor.net> Message-ID: <20120709172447.GA28012@pc21.mareichelt.com> * J wrote: > I'm wondering if there's any hope at all of perhaps enforcing > slackbuilds to have a consistent format in their README files for > listing requirements. So far, the status quo of README files has worked for me. One is supposed to read them anyway, remember? Maybe sbopkg is more tuned to your frequency. -- left blank, right bald -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From panych.y at gmail.com Mon Jul 9 18:26:10 2012 From: panych.y at gmail.com (Yaroslav Panych) Date: Mon, 9 Jul 2012 21:26:10 +0300 Subject: [Slackbuilds-users] requirements in README files In-Reply-To: <20120709112042.Horde.im3MDogBVY5P_wTaY8lf2xA@mail.dawnrazor.net> References: <20120709112042.Horde.im3MDogBVY5P_wTaY8lf2xA@mail.dawnrazor.net> Message-ID: I am absolutely against of such enforcement. Because next step will be automatic dependency resolver and I don't think somebody wants it. I'm not an author of any public SlackBuild's, just ordinary user. I think it will bring more harm than profit. I know how hard to determinate requirements manually, but I sure it worth to do. It will filter noobs aside(less noobs - less maintainers headache, less maintainers headache - better maintainer work). For those who inexperienced yet we have queue files already. 2012/7/9 J : > I'm wondering if there's any hope at all of perhaps enforcing slackbuilds to > have a consistent format in their README files for listing requirements. From thedoogster at gmail.com Mon Jul 9 19:23:39 2012 From: thedoogster at gmail.com (Doogster) Date: Mon, 9 Jul 2012 12:23:39 -0700 Subject: [Slackbuilds-users] requirements in README files In-Reply-To: <20120709112042.Horde.im3MDogBVY5P_wTaY8lf2xA@mail.dawnrazor.net> References: <20120709112042.Horde.im3MDogBVY5P_wTaY8lf2xA@mail.dawnrazor.net> Message-ID: You're trying to parse requirements out of README files? Are you trying to to write something like Portage for SBo? On Mon, Jul 9, 2012 at 9:20 AM, J wrote: > I'm wondering if there's any hope at all of perhaps enforcing slackbuilds to > have a consistent format in their README files for listing requirements. > > Currently we see a very wide variety of formats. While the most popular > looks something like: > > This requires perl-Params-Validate, perl-DateTime-Locale, > perl-DateTime-TimeZone, perl-Test-Exception, perl-Sub-Uplevel > perl-Math-Round. > > There are many, many variations, even on this theme, and many others > besides. Here are some fun examples: > > Requires: perl-Convert-BinHex perl-IO-stringy perl-MailTools > > This package requires perl-Class-Gomor and libdnet, from SlackBuilds.org > > perl-Mail-SPF requires (in that order): > 1. perl-digest-sha1 > 2. perl-digest-hmac > 3. perl-NetAddr-IP > 4. perl-Net-DNS > 5. perl-Net-DNS-Resolver-Programmable > > Xplanet is required to use PlasmaXPlanet. > > > Here's a really nice one: > > This requires zope.component and gaphas. > > To build, this requires pysetuptools, setuptools-git and nose. > > > And those are only examples which contain the word "require". Needless to > say, this makes it highly non-trivial to parse requirements out of README > files. An ideal solution would be add this info in a file somewhere, for > example into the .info file. But they would still need to be in the README, > cause that just makes good sense. So it makes some sort of sense to just > have them in the README. Consistency in that regard would be very useful. I > understand it may not make the most sense to apply this to all existent > slackbuilds, but that's okay, cause 14.0 is on the horizon; perhaps this > could be applied starting with 14.0? > > I appreciate your time and consideration. > J > > _______________________________________________ > 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 j at dawnrazor.net Mon Jul 9 20:24:52 2012 From: j at dawnrazor.net (J) Date: Mon, 09 Jul 2012 15:24:52 -0500 Subject: [Slackbuilds-users] requirements in README files In-Reply-To: References: <20120709112042.Horde.im3MDogBVY5P_wTaY8lf2xA@mail.dawnrazor.net> Message-ID: <20120709152452.Horde.QoYmYYgBVY5P_z4UvpOXMbA@mail.dawnrazor.net> Quoting Doogster : > You're trying to parse requirements out of README files? > > Are you trying to to write something like Portage for SBo? No, something like FreeBSD's pkgtools: http://dawnrazor.net/sbotools/ Quoting Yaroslav Panych : > I am absolutely against of such enforcement. Because next step will be > automatic dependency resolver and I don't think somebody wants it. This is a leap of login akin to saying that publicly available condoms will lead to no children being born. I have written the option to parse requirements into sbotools because the current method - look up sbo, find list of requirements, open new tab, look up requirement, find list of requirements, etc etc, is a usability and sanity failure. The fact is that the sort of consistency in the READMEs in which I'm interested is good for the users who don't care to utilize such an option as well, because it's easier to identify - pattern recognition, basic human interface to the world. > think it will bring more harm than profit. I know how hard to > determinate requirements manually, but I sure it worth to do. It will > filter noobs aside(less noobs - less maintainers headache, less > maintainers headache - better maintainer work). Requirements would still be determined manually. The only change I am proposing is consistency in documenting them. Quoting Hullen at t-online.de (Helmut Hullen): > The README is created from the author/maintainer of the program. The SBO > maintainer should not change it. And yet, other parts of slackbuilds will get changed by maintainers. >> This requires perl-Params-Validate, perl-DateTime-Locale, >> perl-DateTime-TimeZone, perl-Test-Exception, perl-Sub-Uplevel >> perl-Math-Round. > > That's another problem - these informations should be put into "install/ > slack-required". And that could be a job for the SBO maintainer. These would be a valid solution, but I'm not sure it makes a lot of sense, personally. It not only duplicates the data, but I'm apparently the only person who is dead sick and tired of crawling through 20 tabs of slackbuilds to get the requirements together for a single one, and who doesn't feel that sbopkg and queue files are a solution that fits the problem. And that's fine, and doesn't warrant an individual file - though it would be nice. But consistency amongst READMEs is easy to achieve, better for usability, and as noted, there is already a precedent since other files will get edited. J From t3slider at gmail.com Mon Jul 9 20:56:43 2012 From: t3slider at gmail.com (T3slider) Date: Mon, 9 Jul 2012 16:56:43 -0400 Subject: [Slackbuilds-users] requirements in README files In-Reply-To: <20120709152452.Horde.QoYmYYgBVY5P_z4UvpOXMbA@mail.dawnrazor.net> References: <20120709112042.Horde.im3MDogBVY5P_wTaY8lf2xA@mail.dawnrazor.net> <20120709152452.Horde.QoYmYYgBVY5P_z4UvpOXMbA@mail.dawnrazor.net> Message-ID: <20120709205643.GA3297@KeithPC.phub.net.cable.rogers.com> See here: http://slackbuilds.org/faq/#deps The omission of parsable information is an intentional one as far as I know. In order for dependency resolution to come to SBo, there would need to be a way of identifying mandatory vs. optional dependencies. Additionally, if there is special information regarding a certain application or SlackBuild (for example, if a unique user is needed/advised to build/run the application) then this would be impossible to portray in a parsable format. Significant planning is required to produce a good template to follow that provides for all of the complications of dependency resolution, and further, another level of verification on the behalf of the SBo admins would be required to ensure that this information is correct. slackbuilds.org is not setup to be a do-everything script repository -- users are expected to read the README files. If you are blindly accepting the options given by a dependency resolver, then you likely have not read the READMEs and are expecting everything to just work. With sbopkg I currently have no need for anything more sophisticated -- I can read the README for each element, ensure that requirements are met, and just add each dependency to a queue. I don't know what you're doing but it certainly doesn't take me hours to do, with the possible exception of setting up my system after a new Slackware release, which requires going through a whole new SBo repository and making sure things will work (and waiting for things to compile). And if you really are too lazy to read the READMEs there are queuefiles available already. I maintain only a few SlackBuilds but in those there is information that I cannot accurately portray in a standardized format (for example, remind has tons of configure options, and a *run-time* dependency that may or may not be needed depending on your needs). If you're not reading the READMEs for a SlackBuild then you're asking for trouble. Your solution may work for trivial software but in the real world dependency resolution requires an awful lot of work. On Mon, Jul 09, 2012 at 03:24:52PM -0500, J wrote: > Quoting Doogster : > > >You're trying to parse requirements out of README files? > > > >Are you trying to to write something like Portage for SBo? > > No, something like FreeBSD's pkgtools: > > http://dawnrazor.net/sbotools/ > > > Quoting Yaroslav Panych : > > >I am absolutely against of such enforcement. Because next step will be > >automatic dependency resolver and I don't think somebody wants it. > > This is a leap of login akin to saying that publicly available > condoms will lead to no children being born. I have written the > option to parse requirements into sbotools because the current > method - look up sbo, find list of requirements, open new tab, look > up requirement, find list of requirements, etc etc, is a usability > and sanity failure. The fact is that the sort of consistency in the > READMEs in which I'm interested is good for the users who don't care > to utilize such an option as well, because it's easier to identify - > pattern recognition, basic human interface to the world. > > >think it will bring more harm than profit. I know how hard to > >determinate requirements manually, but I sure it worth to do. It will > >filter noobs aside(less noobs - less maintainers headache, less > >maintainers headache - better maintainer work). > > Requirements would still be determined manually. The only change I > am proposing is consistency in documenting them. > > Quoting Hullen at t-online.de (Helmut Hullen): > > >The README is created from the author/maintainer of the program. The SBO > >maintainer should not change it. > > And yet, other parts of slackbuilds will get changed by maintainers. > > >>This requires perl-Params-Validate, perl-DateTime-Locale, > >>perl-DateTime-TimeZone, perl-Test-Exception, perl-Sub-Uplevel > >>perl-Math-Round. > > > >That's another problem - these informations should be put into "install/ > >slack-required". And that could be a job for the SBO maintainer. > > These would be a valid solution, but I'm not sure it makes a lot of > sense, personally. It not only duplicates the data, but I'm > apparently the only person who is dead sick and tired of crawling > through 20 tabs of slackbuilds to get the requirements together for > a single one, and who doesn't feel that sbopkg and queue files are a > solution that fits the problem. And that's fine, and doesn't warrant > an individual file - though it would be nice. But consistency > amongst READMEs is easy to achieve, better for usability, and as > noted, there is already a precedent since other files will get > edited. > > J > > _______________________________________________ > 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 c.willing at uq.edu.au Mon Jul 9 22:32:13 2012 From: c.willing at uq.edu.au (Christoph Willing) Date: Tue, 10 Jul 2012 08:32:13 +1000 Subject: [Slackbuilds-users] requirements in README files In-Reply-To: <20120709205643.GA3297@KeithPC.phub.net.cable.rogers.com> References: <20120709112042.Horde.im3MDogBVY5P_wTaY8lf2xA@mail.dawnrazor.net> <20120709152452.Horde.QoYmYYgBVY5P_z4UvpOXMbA@mail.dawnrazor.net> <20120709205643.GA3297@KeithPC.phub.net.cable.rogers.com> Message-ID: <33C2D732-76C1-4FE9-8804-DA345B6B487D@uq.edu.au> I believe the OP was just suggesting a less ad-hoc way to describe build dependencies. Of course thats not always uncomplicated; nevertheless for some large percentage of software, the prerequisite packages required to build some new software are quite clear. Why not accommodate these cases? Whatever the format for describing the prerequisites, any builder has the option of ignoring them. In my own situation, I add a PREREQUISITES="...." line to the SBo's .info file. This can be used (or not) at build time to ensure that the prerequisite packages are installed. The parsing & checking can be done in the .SlackBuild script itself or, if purity is paramount, can be left to a separate wrapper script which parses the .info file, checks the prerequisite packages are installed and then runs the .SlackBuild. Yes, "garbage in, garbage out". If the PRERQUISITES field contains rubbish, its not useful; but thats also true of anything in existing SBo's. The same really applies for slack-required files too (for runtime dependencies). They're not compulsory! /sbin/installpkg & friends ignore them; so can everyone else. Why should we prevent SBo authors including them and why should we prevent arbitrary users reading them? Of course they're useless if they contain bogus information but we generally trust SBo authors' scripts to be otherwise well behaved etc. There's nothing "dangerous" going on here, just more knowledge. If they offend you, don't look. chris On 10/07/2012, at 6:56 AM, T3slider wrote: > See here: http://slackbuilds.org/faq/#deps > The omission of parsable information is an intentional one as far as I > know. In order for dependency resolution to come to SBo, there would > need to be a way of identifying mandatory vs. optional dependencies. > Additionally, if there is special information regarding a certain > application or SlackBuild (for example, if a unique user is > needed/advised to build/run the application) then this would be > impossible to portray in a parsable format. Significant planning is > required to produce a good template to follow that provides for all of > the complications of dependency resolution, and further, another level > of verification on the behalf of the SBo admins would be required to > ensure that this information is correct. > > slackbuilds.org is not setup to be a do-everything script repository > -- > users are expected to read the README files. If you are blindly > accepting the options given by a dependency resolver, then you likely > have not read the READMEs and are expecting everything to just work. > With sbopkg I currently have no need for anything more sophisticated > -- > I can read the README for each element, ensure that requirements are > met, and just add each dependency to a queue. I don't know what you're > doing but it certainly doesn't take me hours to do, with the possible > exception of setting up my system after a new Slackware release, which > requires going through a whole new SBo repository and making sure > things > will work (and waiting for things to compile). And if you really are > too > lazy to read the READMEs there are queuefiles available already. > > I maintain only a few SlackBuilds but in those there is information > that > I cannot accurately portray in a standardized format (for example, > remind has tons of configure options, and a *run-time* dependency that > may or may not be needed depending on your needs). If you're not > reading > the READMEs for a SlackBuild then you're asking for trouble. Your > solution may work for trivial software but in the real world > dependency > resolution requires an awful lot of work. > > On Mon, Jul 09, 2012 at 03:24:52PM -0500, J wrote: >> Quoting Doogster : >> >>> You're trying to parse requirements out of README files? >>> >>> Are you trying to to write something like Portage for SBo? >> >> No, something like FreeBSD's pkgtools: >> >> http://dawnrazor.net/sbotools/ >> >> >> Quoting Yaroslav Panych : >> >>> I am absolutely against of such enforcement. Because next step >>> will be >>> automatic dependency resolver and I don't think somebody wants it. >> >> This is a leap of login akin to saying that publicly available >> condoms will lead to no children being born. I have written the >> option to parse requirements into sbotools because the current >> method - look up sbo, find list of requirements, open new tab, look >> up requirement, find list of requirements, etc etc, is a usability >> and sanity failure. The fact is that the sort of consistency in the >> READMEs in which I'm interested is good for the users who don't care >> to utilize such an option as well, because it's easier to identify - >> pattern recognition, basic human interface to the world. >> >>> think it will bring more harm than profit. I know how hard to >>> determinate requirements manually, but I sure it worth to do. It >>> will >>> filter noobs aside(less noobs - less maintainers headache, less >>> maintainers headache - better maintainer work). >> >> Requirements would still be determined manually. The only change I >> am proposing is consistency in documenting them. >> >> Quoting Hullen at t-online.de (Helmut Hullen): >> >>> The README is created from the author/maintainer of the program. >>> The SBO >>> maintainer should not change it. >> >> And yet, other parts of slackbuilds will get changed by maintainers. >> >>>> This requires perl-Params-Validate, perl-DateTime-Locale, >>>> perl-DateTime-TimeZone, perl-Test-Exception, perl-Sub-Uplevel >>>> perl-Math-Round. >>> >>> That's another problem - these informations should be put into >>> "install/ >>> slack-required". And that could be a job for the SBO maintainer. >> >> These would be a valid solution, but I'm not sure it makes a lot of >> sense, personally. It not only duplicates the data, but I'm >> apparently the only person who is dead sick and tired of crawling >> through 20 tabs of slackbuilds to get the requirements together for >> a single one, and who doesn't feel that sbopkg and queue files are a >> solution that fits the problem. And that's fine, and doesn't warrant >> an individual file - though it would be nice. But consistency >> amongst READMEs is easy to achieve, better for usability, and as >> noted, there is already a precedent since other files will get >> edited. >> >> J >> >> _______________________________________________ >> 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/ > Christoph Willing +61 7 3365 8316 Research Computing Centre University of Queensland From artourter at gmail.com Mon Jul 9 22:57:40 2012 From: artourter at gmail.com (Greg' Ar Tourter) Date: Mon, 9 Jul 2012 23:57:40 +0100 Subject: [Slackbuilds-users] requirements in README files In-Reply-To: <20120709205643.GA3297@KeithPC.phub.net.cable.rogers.com> References: <20120709112042.Horde.im3MDogBVY5P_wTaY8lf2xA@mail.dawnrazor.net> <20120709152452.Horde.QoYmYYgBVY5P_z4UvpOXMbA@mail.dawnrazor.net> <20120709205643.GA3297@KeithPC.phub.net.cable.rogers.com> Message-ID: sbopkg has a queue file facility which allows your to create list of package to build in a certain order. Mauro used to maintain a repository of queue file for all packages available in slackbuilds.org but I suspect he has been busy with other things lately. you can get the queue files from http://gitorious.org/sbopkg-slackware-queues/. Adding dependency management is the not slackware way of doing thing and it is a can of worm that most people here would not want to see open. Slackbuilds.org follows very closely the way Slackware works and the slack-required file is not part of slackware package standard and therefore doesn't really have a place in the slackbuild packages made available here. As T3slider mentions, dependency resolution is extremely complex and rarely done well. In addition to optional vs mendatory dependency, some compile options may be required for some and not for other. (I am thinking in particular about some package which will not build if wx widgets is compiled with UTF-8 support). ArTourter On 9 July 2012 21:56, T3slider wrote: > See here: http://slackbuilds.org/faq/#deps > The omission of parsable information is an intentional one as far as I > know. In order for dependency resolution to come to SBo, there would > need to be a way of identifying mandatory vs. optional dependencies. > Additionally, if there is special information regarding a certain > application or SlackBuild (for example, if a unique user is > needed/advised to build/run the application) then this would be > impossible to portray in a parsable format. Significant planning is > required to produce a good template to follow that provides for all of > the complications of dependency resolution, and further, another level > of verification on the behalf of the SBo admins would be required to > ensure that this information is correct. > > slackbuilds.org is not setup to be a do-everything script repository -- > users are expected to read the README files. If you are blindly > accepting the options given by a dependency resolver, then you likely > have not read the READMEs and are expecting everything to just work. > With sbopkg I currently have no need for anything more sophisticated -- > I can read the README for each element, ensure that requirements are > met, and just add each dependency to a queue. I don't know what you're > doing but it certainly doesn't take me hours to do, with the possible > exception of setting up my system after a new Slackware release, which > requires going through a whole new SBo repository and making sure things > will work (and waiting for things to compile). And if you really are too > lazy to read the READMEs there are queuefiles available already. > > I maintain only a few SlackBuilds but in those there is information that > I cannot accurately portray in a standardized format (for example, > remind has tons of configure options, and a *run-time* dependency that > may or may not be needed depending on your needs). If you're not reading > the READMEs for a SlackBuild then you're asking for trouble. Your > solution may work for trivial software but in the real world dependency > resolution requires an awful lot of work. > > On Mon, Jul 09, 2012 at 03:24:52PM -0500, J wrote: >> Quoting Doogster : >> >> >You're trying to parse requirements out of README files? >> > >> >Are you trying to to write something like Portage for SBo? >> >> No, something like FreeBSD's pkgtools: >> >> http://dawnrazor.net/sbotools/ >> >> >> Quoting Yaroslav Panych : >> >> >I am absolutely against of such enforcement. Because next step will be >> >automatic dependency resolver and I don't think somebody wants it. >> >> This is a leap of login akin to saying that publicly available >> condoms will lead to no children being born. I have written the >> option to parse requirements into sbotools because the current >> method - look up sbo, find list of requirements, open new tab, look >> up requirement, find list of requirements, etc etc, is a usability >> and sanity failure. The fact is that the sort of consistency in the >> READMEs in which I'm interested is good for the users who don't care >> to utilize such an option as well, because it's easier to identify - >> pattern recognition, basic human interface to the world. >> >> >think it will bring more harm than profit. I know how hard to >> >determinate requirements manually, but I sure it worth to do. It will >> >filter noobs aside(less noobs - less maintainers headache, less >> >maintainers headache - better maintainer work). >> >> Requirements would still be determined manually. The only change I >> am proposing is consistency in documenting them. >> >> Quoting Hullen at t-online.de (Helmut Hullen): >> >> >The README is created from the author/maintainer of the program. The SBO >> >maintainer should not change it. >> >> And yet, other parts of slackbuilds will get changed by maintainers. >> >> >>This requires perl-Params-Validate, perl-DateTime-Locale, >> >>perl-DateTime-TimeZone, perl-Test-Exception, perl-Sub-Uplevel >> >>perl-Math-Round. >> > >> >That's another problem - these informations should be put into "install/ >> >slack-required". And that could be a job for the SBO maintainer. >> >> These would be a valid solution, but I'm not sure it makes a lot of >> sense, personally. It not only duplicates the data, but I'm >> apparently the only person who is dead sick and tired of crawling >> through 20 tabs of slackbuilds to get the requirements together for >> a single one, and who doesn't feel that sbopkg and queue files are a >> solution that fits the problem. And that's fine, and doesn't warrant >> an individual file - though it would be nice. But consistency >> amongst READMEs is easy to achieve, better for usability, and as >> noted, there is already a precedent since other files will get >> edited. >> >> J >> >> _______________________________________________ >> 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 dragonwisard at gmail.com Mon Jul 9 23:00:02 2012 From: dragonwisard at gmail.com (Ben Mendis) Date: Mon, 9 Jul 2012 19:00:02 -0400 Subject: [Slackbuilds-users] requirements in README files In-Reply-To: <33C2D732-76C1-4FE9-8804-DA345B6B487D@uq.edu.au> References: <20120709112042.Horde.im3MDogBVY5P_wTaY8lf2xA@mail.dawnrazor.net> <20120709152452.Horde.QoYmYYgBVY5P_z4UvpOXMbA@mail.dawnrazor.net> <20120709205643.GA3297@KeithPC.phub.net.cable.rogers.com> <33C2D732-76C1-4FE9-8804-DA345B6B487D@uq.edu.au> Message-ID: I have to agree with this. 95% of the time I vastly prefer the classical Slackware approach to package management to what I've seen in other distros or other Unix(-like) systems. However there are a few cases where build-time or run-time dependency trees can get pretty crazy. Many of the multimedia packages are prime examples of this, especially the video editors which depend on long chains of audio and video codes, libraries, and frameworks. Try building avidemux or cinelerra on a clean Slackware system without looking at a slack-required file and only using the hints in the README files. I'm not saying it needs to be mandatory, but if a maintainer would like to go to the extra effort to include it then why shouldn't it be allowed? On Mon, Jul 9, 2012 at 6:32 PM, Christoph Willing wrote: > I believe the OP was just suggesting a less ad-hoc way to describe build > dependencies. > > Of course thats not always uncomplicated; nevertheless for some large > percentage of software, the prerequisite packages required to build some > new software are quite clear. Why not accommodate these cases? Whatever the > format for describing the prerequisites, any builder has the option of > ignoring them. > > In my own situation, I add a PREREQUISITES="...." line to the SBo's .info > file. This can be used (or not) at build time to ensure that the > prerequisite packages are installed. The parsing & checking can be done in > the .SlackBuild script itself or, if purity is paramount, can be left to a > separate wrapper script which parses the .info file, checks the > prerequisite packages are installed and then runs the .SlackBuild. > > Yes, "garbage in, garbage out". If the PRERQUISITES field contains > rubbish, its not useful; but thats also true of anything in existing SBo's. > > The same really applies for slack-required files too (for runtime > dependencies). They're not compulsory! /sbin/installpkg & friends ignore > them; so can everyone else. Why should we prevent SBo authors including > them and why should we prevent arbitrary users reading them? Of course > they're useless if they contain bogus information but we generally trust > SBo authors' scripts to be otherwise well behaved etc. There's nothing > "dangerous" going on here, just more knowledge. If they offend you, don't > look. > > > chris > > > > On 10/07/2012, at 6:56 AM, T3slider wrote: > > See here: http://slackbuilds.org/faq/#**deps >> The omission of parsable information is an intentional one as far as I >> know. In order for dependency resolution to come to SBo, there would >> need to be a way of identifying mandatory vs. optional dependencies. >> Additionally, if there is special information regarding a certain >> application or SlackBuild (for example, if a unique user is >> needed/advised to build/run the application) then this would be >> impossible to portray in a parsable format. Significant planning is >> required to produce a good template to follow that provides for all of >> the complications of dependency resolution, and further, another level >> of verification on the behalf of the SBo admins would be required to >> ensure that this information is correct. >> >> slackbuilds.org is not setup to be a do-everything script repository -- >> users are expected to read the README files. If you are blindly >> accepting the options given by a dependency resolver, then you likely >> have not read the READMEs and are expecting everything to just work. >> With sbopkg I currently have no need for anything more sophisticated -- >> I can read the README for each element, ensure that requirements are >> met, and just add each dependency to a queue. I don't know what you're >> doing but it certainly doesn't take me hours to do, with the possible >> exception of setting up my system after a new Slackware release, which >> requires going through a whole new SBo repository and making sure things >> will work (and waiting for things to compile). And if you really are too >> lazy to read the READMEs there are queuefiles available already. >> >> I maintain only a few SlackBuilds but in those there is information that >> I cannot accurately portray in a standardized format (for example, >> remind has tons of configure options, and a *run-time* dependency that >> may or may not be needed depending on your needs). If you're not reading >> the READMEs for a SlackBuild then you're asking for trouble. Your >> solution may work for trivial software but in the real world dependency >> resolution requires an awful lot of work. >> >> On Mon, Jul 09, 2012 at 03:24:52PM -0500, J wrote: >> >>> Quoting Doogster : >>> >>> You're trying to parse requirements out of README files? >>>> >>>> Are you trying to to write something like Portage for SBo? >>>> >>> >>> No, something like FreeBSD's pkgtools: >>> >>> http://dawnrazor.net/sbotools/ >>> >>> >>> Quoting Yaroslav Panych : >>> >>> I am absolutely against of such enforcement. Because next step will be >>>> automatic dependency resolver and I don't think somebody wants it. >>>> >>> >>> This is a leap of login akin to saying that publicly available >>> condoms will lead to no children being born. I have written the >>> option to parse requirements into sbotools because the current >>> method - look up sbo, find list of requirements, open new tab, look >>> up requirement, find list of requirements, etc etc, is a usability >>> and sanity failure. The fact is that the sort of consistency in the >>> READMEs in which I'm interested is good for the users who don't care >>> to utilize such an option as well, because it's easier to identify - >>> pattern recognition, basic human interface to the world. >>> >>> think it will bring more harm than profit. I know how hard to >>>> determinate requirements manually, but I sure it worth to do. It will >>>> filter noobs aside(less noobs - less maintainers headache, less >>>> maintainers headache - better maintainer work). >>>> >>> >>> Requirements would still be determined manually. The only change I >>> am proposing is consistency in documenting them. >>> >>> Quoting Hullen at t-online.de (Helmut Hullen): >>> >>> The README is created from the author/maintainer of the program. The SBO >>>> maintainer should not change it. >>>> >>> >>> And yet, other parts of slackbuilds will get changed by maintainers. >>> >>> This requires perl-Params-Validate, perl-DateTime-Locale, >>>>> perl-DateTime-TimeZone, perl-Test-Exception, perl-Sub-Uplevel >>>>> perl-Math-Round. >>>>> >>>> >>>> That's another problem - these informations should be put into "install/ >>>> slack-required". And that could be a job for the SBO maintainer. >>>> >>> >>> These would be a valid solution, but I'm not sure it makes a lot of >>> sense, personally. It not only duplicates the data, but I'm >>> apparently the only person who is dead sick and tired of crawling >>> through 20 tabs of slackbuilds to get the requirements together for >>> a single one, and who doesn't feel that sbopkg and queue files are a >>> solution that fits the problem. And that's fine, and doesn't warrant >>> an individual file - though it would be nice. But consistency >>> amongst READMEs is easy to achieve, better for usability, and as >>> noted, there is already a precedent since other files will get >>> edited. >>> >>> J >>> >>> ______________________________**_________________ >>> 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/ >> >> > Christoph Willing +61 7 3365 8316 > Research Computing Centre > University of Queensland > > > > > ______________________________**_________________ > 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 insomniactoo at localnet.com Mon Jul 9 23:29:27 2012 From: insomniactoo at localnet.com (insomniactoo at localnet.com) Date: Mon, 9 Jul 2012 18:29:27 -0500 Subject: [Slackbuilds-users] requirements in README files In-Reply-To: References: <20120709112042.Horde.im3MDogBVY5P_wTaY8lf2xA@mail.dawnrazor.net> <20120709152452.Horde.QoYmYYgBVY5P_z4UvpOXMbA@mail.dawnrazor.net> <20120709205643.GA3297@KeithPC.phub.net.cable.rogers.com> Message-ID: <20120709182927.61f11fd6@oogah> On Mon, 9 Jul 2012 23:57:40 +0100 "Greg' Ar Tourter" wrote: > Adding dependency management is the not slackware way of doing thing > and it is a can of worm that most people here would not want to see > open. Slackbuilds.org follows very closely the way Slackware works and > the slack-required file is not part of slackware package standard and > therefore doesn't really have a place in the slackbuild packages made > available here. > > > ArTourter > +1. Sure, having a few tabs open can be a PITA, but I'd rather do it that way than have software that can't possibly do it correctly, no matter how good it is. Doing it all myself I *know* it's done right and that I have all I need and that it all built right and got installed correctly. Besides, those of us on dial-up couldn't do the 'dependency software' thing without it tying up the phone line for who knows how long. That's a major reason I came to Slackware - the dependency stuff isn't *mandatory* like on many other distros. I can get the one app I'm looking for and the 1 or 10 dependencies that that app *only* needs, not 30 that my whole system needs to make it run and would take days to download on dial-up. -- Powered by Slackware Linux 13.37 In-ep-toc-ra-cy \in-ep-'t?k-r?-s?\ n, 1 A system of government where the least capable to lead are elected by the least capable of producing, and where the members of society least likely to sustain themselves or succeed, are rewarded with goods and services paid for by the confiscated wealth of a diminishing number of producers. <~Obama regime> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From klaatu at straightedgelinux.com Mon Jul 9 23:40:39 2012 From: klaatu at straightedgelinux.com (Klaatu) Date: Mon, 9 Jul 2012 19:40:39 -0400 Subject: [Slackbuilds-users] requirements in README files In-Reply-To: <20120709152452.Horde.QoYmYYgBVY5P_z4UvpOXMbA@mail.dawnrazor.net> References: <20120709112042.Horde.im3MDogBVY5P_wTaY8lf2xA@mail.dawnrazor.net> <20120709152452.Horde.QoYmYYgBVY5P_z4UvpOXMbA@mail.dawnrazor.net> Message-ID: <201207091940.39393.klaatu@straightedgelinux.com> > Quoting Doogster : > > You're trying to parse requirements out of README files? > > > > Are you trying to to write something like Portage for SBo? > > No, something like FreeBSD's pkgtools: > > http://dawnrazor.net/sbotools/ > > Quoting Yaroslav Panych : > > I am absolutely against of such enforcement. Because next step will be > > automatic dependency resolver and I don't think somebody wants it. > > This is a leap of login akin to saying that publicly available condoms > will lead to no children being born. I have written the option to > parse requirements into sbotools because the current method - look up > sbo, find list of requirements, open new tab, look up requirement, > find list of requirements, etc etc, is a usability and sanity failure. > The fact is that the sort of consistency in the READMEs in which I'm > interested is good for the users who don't care to utilize such an > option as well, because it's easier to identify - pattern recognition, > basic human interface to the world. > > > think it will bring more harm than profit. I know how hard to > > determinate requirements manually, but I sure it worth to do. It will > > filter noobs aside(less noobs - less maintainers headache, less > > maintainers headache - better maintainer work). > > Requirements would still be determined manually. The only change I am > proposing is consistency in documenting them. > > Quoting Hullen at t-online.de (Helmut Hullen): > > The README is created from the author/maintainer of the program. The SBO > > maintainer should not change it. > > And yet, other parts of slackbuilds will get changed by maintainers. > > >> This requires perl-Params-Validate, perl-DateTime-Locale, > >> perl-DateTime-TimeZone, perl-Test-Exception, perl-Sub-Uplevel > >> perl-Math-Round. > > > > That's another problem - these informations should be put into "install/ > > slack-required". And that could be a job for the SBO maintainer. > > These would be a valid solution, but I'm not sure it makes a lot of > sense, personally. It not only duplicates the data, but I'm apparently > the only person who is dead sick and tired of crawling through 20 tabs > of slackbuilds to get the requirements together for a single one, and > who doesn't feel that sbopkg and queue files are a solution that fits > the problem. And that's fine, and doesn't warrant an individual file - > though it would be nice. But consistency amongst READMEs is easy to > achieve, better for usability, and as noted, there is already a > precedent since other files will get edited. > > J > > _______________________________________________ > 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/ J, I would not mind following an informal "spec" for a portion of the README. I'm not interested in automated dep resolution for myself, but flexibility is a strength of Free Software, so let me know what you want to see in the README to make your scripts work, and I'll try to write my README files accordingly. Obvious exceptions would be when a dep is particularly optional or whatever, in which case I guess I'd just list it as a dep and assume that anyone using automated dependency resolution tools is foresaking optional-ness. I imagine the easiest thing to do would be to stick the deps at the tail of the README file; presumably, you're looking for some kind of tell-tale Start line + some delimited list of deps + some kind of End-of-List marker, right? I could do that on any new builds I submit. (I won't go back and change any builds just for this, but I'd be happy to adapt them upon their next update.) - klaatu From c.willing at uq.edu.au Tue Jul 10 00:42:10 2012 From: c.willing at uq.edu.au (Christoph Willing) Date: Tue, 10 Jul 2012 10:42:10 +1000 Subject: [Slackbuilds-users] requirements in README files In-Reply-To: References: <20120709112042.Horde.im3MDogBVY5P_wTaY8lf2xA@mail.dawnrazor.net> <20120709152452.Horde.QoYmYYgBVY5P_z4UvpOXMbA@mail.dawnrazor.net> <20120709205643.GA3297@KeithPC.phub.net.cable.rogers.com> Message-ID: <5FB83E4C-6A33-4258-AD68-CECD0912BD87@uq.edu.au> On 10/07/2012, at 8:57 AM, Greg' Ar Tourter wrote: > sbopkg has a queue file facility which allows your to create list of > package to build in a certain order. Mauro used to maintain a > repository of queue file for all packages available in slackbuilds.org > but I suspect he has been busy with other things lately. you can get > the queue files from http://gitorious.org/sbopkg-slackware-queues/. > > Adding dependency management is the not slackware way of doing thing > and it is a can of worm that most people here would not want to see > open. Slackbuilds.org follows very closely the way Slackware works and > the slack-required file is not part of slackware package standard and > therefore doesn't really have a place in the slackbuild packages made > available here. Neither is a .SlackBuild file part of a regular Slackware package, yet every SBo .SlackBuild I've seen contains the line: cat $CWD/$PRGNAM.SlackBuild > $PKG/usr/doc/$PRGNAM-$VERSION/ $PRGNAM.SlackBuild In principle then, its not against the law to include additional files or information that may or may not be useful to the average user. Therefore we could leave other potentially useful information in /usr/ doc/$PRGNAM-$VERSION (for instance) too, couldn't we? It could be in a separate file or added to an existing README. It could be laid in a regular format so that interested software and humans could easily parse it. It could be completely ignored by disinterested parties (as I suspect the included .SlackBuild is ignored 99.73% of the time). A listing of build prerequisites is even more innocuous - no particular need for that to appear in a final package at all. My suggestion would be for a PREREQS="..." line in the .info file (which doesn't by default appear in the final package). > As T3slider mentions, dependency resolution is extremely complex and > rarely done well. In addition to optional vs mendatory dependency, > some compile options may be required for some and not for other. (I am > thinking in particular about some package which will not build if wx > widgets is compiled with UTF-8 support). For software whose build (or runtime) requirements are beyond human understanding, a listing of the requirements could just be omitted or you could ignore it (recall, none of this is compulsory). In that case, you're no worse off than you are now building that particular package that needs a non UTF-8 wxWidgets. chris Christoph Willing +61 7 3365 8316 Research Computing Centre University of Queensland From baildon.research at googlemail.com Tue Jul 10 01:00:15 2012 From: baildon.research at googlemail.com (David Spencer) Date: Tue, 10 Jul 2012 02:00:15 +0100 Subject: [Slackbuilds-users] requirements in README files In-Reply-To: <20120709182927.61f11fd6@oogah> References: <20120709112042.Horde.im3MDogBVY5P_wTaY8lf2xA@mail.dawnrazor.net> <20120709152452.Horde.QoYmYYgBVY5P_z4UvpOXMbA@mail.dawnrazor.net> <20120709205643.GA3297@KeithPC.phub.net.cable.rogers.com> <20120709182927.61f11fd6@oogah> Message-ID: For simple cases, I've noticed over the past year, or maybe more, that some of the admins do impose a consistent form of words on new submissions and updates, so the situation is probably getting better (statistically). And now that I have seen the form of words that the admins seem to like, I try to imitate it. For more complex cases, I would have no problem with stating direct dependencies in XML, or queue files, or whatever, provided that the formal language is equally as expressive as a description in English. But I need to say things like "If you happen to have postgres installed, gdal will automatically notice it and add some stuff that you probably don't want, so please think about that and then tell the SlackBuild to disable it kthxbai" which may be tricky in XML :-) Yeah, long chains of indirect dependencies are a pain. They'd be even more of a pain if our flexible source-based locally-managed dependency resolution was more rigid. There's nothing better than noticing that a tricky dependency turns out to be optional, contrary to expectations :-) By the way, I'm noticing more and more upstream packages shipping 'internal' versions of their dependencies. For all sorts of reasons that's not good, but it tells us something about how other distros' dependency management pans out in the real world. -D. From baildon.research at googlemail.com Tue Jul 10 01:11:31 2012 From: baildon.research at googlemail.com (David Spencer) Date: Tue, 10 Jul 2012 02:11:31 +0100 Subject: [Slackbuilds-users] requirements in README files In-Reply-To: <5FB83E4C-6A33-4258-AD68-CECD0912BD87@uq.edu.au> References: <20120709112042.Horde.im3MDogBVY5P_wTaY8lf2xA@mail.dawnrazor.net> <20120709152452.Horde.QoYmYYgBVY5P_z4UvpOXMbA@mail.dawnrazor.net> <20120709205643.GA3297@KeithPC.phub.net.cable.rogers.com> <5FB83E4C-6A33-4258-AD68-CECD0912BD87@uq.edu.au> Message-ID: > My suggestion would be for a > PREREQS="..." line in the .info file Maybe that could be X-PREREQS, in an homage to Usenet headers :-) -D. From dragonwisard at gmail.com Tue Jul 10 01:45:27 2012 From: dragonwisard at gmail.com (Ben Mendis) Date: Mon, 9 Jul 2012 21:45:27 -0400 Subject: [Slackbuilds-users] requirements in README files In-Reply-To: References: <20120709112042.Horde.im3MDogBVY5P_wTaY8lf2xA@mail.dawnrazor.net> <20120709152452.Horde.QoYmYYgBVY5P_z4UvpOXMbA@mail.dawnrazor.net> <20120709205643.GA3297@KeithPC.phub.net.cable.rogers.com> <20120709182927.61f11fd6@oogah> Message-ID: On Mon, Jul 9, 2012 at 9:00 PM, David Spencer < baildon.research at googlemail.com> wrote: > > Yeah, long chains of indirect dependencies are a pain. They'd be even > more of a pain if our flexible source-based locally-managed dependency > resolution was more rigid. There's nothing better than noticing that > a tricky dependency turns out to be optional, contrary to expectations > :-) > > Right! In no way am I asking for more rigidity or even for an automated solution. What I would find nice, however, is a standard syntax for indicating the names of direct dependencies (whether mandatory or optional) so that I can write tools to resolve a rough outline of a dependency graph and at least get some idea of which packages I *might* need or want and approximately what order they should be installed in. Even something as noncommittal as that is currently a challenge to automate and requires a lot of manual foot work. Isn't the point of computing to automate the mundane tasks so that we can focus our minds and efforts on the truly interesting problems? Why are people on this list so vehemently opposed to the idea of OPTIONAL metadata? It wouldn't have any impact on your current way of doing things, but it might be of value to people who aren't quite as masochistic. I love Slackware, and I love the way Slackware's package management works. That said, I'm not blind to the fact that it has trade-offs and shortcomings. Proposals like this are a very non-intrusive way to experiment with potential improvements without forcing work on anyone or taking away any functionality or flexibility. You can love and respect something, but still want to improve it. Package and dependency management are clearly not "solved" problems, and while Slackware is better than most, it's not perfect. -------------- next part -------------- An HTML attachment was scrubbed... URL: From j at dawnrazor.net Tue Jul 10 03:51:19 2012 From: j at dawnrazor.net (J) Date: Mon, 09 Jul 2012 22:51:19 -0500 Subject: [Slackbuilds-users] requirements in README files In-Reply-To: References: <20120709112042.Horde.im3MDogBVY5P_wTaY8lf2xA@mail.dawnrazor.net> <20120709152452.Horde.QoYmYYgBVY5P_z4UvpOXMbA@mail.dawnrazor.net> <20120709205643.GA3297@KeithPC.phub.net.cable.rogers.com> <20120709182927.61f11fd6@oogah> Message-ID: <20120709225119.Horde.L90oAogBVY5P_6a3Vv5nMbA@mail.dawnrazor.net> Hello folks. Have to go to work shortly so I don't have time to say much. Even if I did, I wouldn't reply to the "raging-against-dependency" emails, cause that's a dead-horse we've been beating for over a decade, so long that I don't even care anymore; these days I care about things that work, and work well, which is a great place to be cause I can love Slackware's package management and FreeBSD's package management equally well, even one does not resolves dependencies and one does. So have fun getting all bent out of shape about that, it's not going to make a bit of difference to me. What I will do is clarify a few points of my stance on this: 1. Optional dependencies are stated as optional currently. I didn't even bring them up - for a reason. The reason is that the system used there is perfect as it stands. I am not trying to parse optional dependencies, for several reasons. 2. This discussion is really not about "dependencies" - it is about requirements, hard and fast. "A requires B, and will not build without B", sort of thing. These are hard and fast rules, simple logic chains, and I have not seen a case where such a simple line of reasoning is not trivially automated. 3. I am not imposing or trying to impose anything on anyone, anywhere. I do not really even care if anyone else ever uses sbotools - I wrote it for myself. 4. sbotools has an option to not show the user a slackbuild's README prior to building/upgrading. If the user chooses this option, requirement-parsing WILL NOT happen. I believe in reading the README too, cause that makes the system work well. I'll get back to those of you who had something to add to this conversation tomorrow. Thanks a bunch. J From chess at chessgriffin.com Tue Jul 10 04:54:27 2012 From: chess at chessgriffin.com (Chess Griffin) Date: Tue, 10 Jul 2012 00:54:27 -0400 Subject: [Slackbuilds-users] requirements in README files In-Reply-To: <20120709225119.Horde.L90oAogBVY5P_6a3Vv5nMbA@mail.dawnrazor.net> References: <20120709112042.Horde.im3MDogBVY5P_wTaY8lf2xA@mail.dawnrazor.net> <20120709152452.Horde.QoYmYYgBVY5P_z4UvpOXMbA@mail.dawnrazor.net> <20120709205643.GA3297@KeithPC.phub.net.cable.rogers.com> <20120709182927.61f11fd6@oogah> <20120709225119.Horde.L90oAogBVY5P_6a3Vv5nMbA@mail.dawnrazor.net> Message-ID: <1341896067.11438.140661100011705.4FEC53E5@webmail.messagingengine.com> First, a couple of disclaimers: 1. I started the sbopkg project and was soon joined by slakmagik and Mauro Giachero, both of whom made sbopkg far better than I ever could have done by myself. I retired in 2010 and handed the project over to slakmagik who has done a great job in continuing to maintain it along with help by Mauro. I thank them both for their past and future help. 2. I used to be a SlackBuilds.org admin but also retired from that role. I know what it's like to be an admin and to test the submissions. It's a lot of work, and what I did paled in comparison to what the other admins did, and continue to do. I am not an admin any longer, so I don't speak for the SBo project in any capacity. Having said that, I think the point made earlier by T3slider that the SBo project is not intended to be a do-everything script repository is spot on. IMHO, the SBo project is simply intended to provide a repository of SlackBuild scripts just like the ones that Pat creates for official Slackware packages. Since those official SlackBuild scripts don't have any kind of dependency information, neither do the SBo scripts (other than what the maintainer decides to put in the README). When slackmagik, Mauro, and I came up with the idea of the sbopkg queuefiles, the point was to only try to automate what the user would otherwise do manually. We've all sat down with a paper and pencil and written out our list of SBo packages to build and, after reading through the READMEs, figured out the right order of build dependencies. The queuefiles is intended to be simply a way to "save" that information to make it easier to build the packages again later on. Is sbopkg or its queuefiles perfect? Certainly not. But, it really was written with the "Slackware way" in mind and I think overall, it works well. Sbopkg doesn't try to figure out anything for you -- the user still has to put in the initial work -- but sbopkg can make life a little easier by saving this information in a simple text file we call a queuefile for future use. I understand the OP's point and yes, I can see a case where having a standardized format for including compile-time dependencies in the README or .info file would be helpful. But that's never been the Slackware way so putting that in place would move the SBo project from its original purpose, at least as I see it. Finally, and here is where I put on my "former SBo admin" hat on, if the SBo project were to change things and start requiring that build-time dependencies be included in the README or .info file, then this would definitely lead to more work for the current SBo admins, who already put in a lot of time in maintaining SBo. The fact is that many SlackBuild script maintainers are not that communicative (and I've been guilty of this myself -- I only just now got to updating OpenArena after /many/ requests -- sorry!) and either the admins would have to try and track down all the maintainers to update their submissions to the new format or do it themselves. And, of course, test the listed dependencies. What if someone forgot to add a dependency? Each submission would have to be tested on a clean, newly installed system in a VM or something to ensure that the dependencies were listed correctly and in the right order. That's a lot of work. Ultimately, I think Slackware, and the SBo project, are geared toward those who are willing to put in some of their own effort when it comes to adding third-party software. I use FreeBSD (and OpenBSD) as well so I am familiar with their ports and packages systems. And, for the most part, they work well. And I was even a FreeBSD port maintainer for awhile. But those systems were built with that kind of dependency tracking from the outset and Slackware SlackBuild scripts were not. Therefore, any such dependency tracking is a bolted-on solution. I have no idea if the current SBo admins are considering adding dependency information like the OP suggested. Maybe so, maybe not. And whatever they decide is fine by me. Either way, I really appreciate all the hard work the SBo admins and the SBo Slackbuild script maintainers put in. The SBo project is a huge, and I mean HUGE, benefit to the Slackware community. Just my < $0.02. :-) -- Chess Griffin From lukenshiro at ngi.it Tue Jul 10 07:02:45 2012 From: lukenshiro at ngi.it (LukenShiro) Date: Tue, 10 Jul 2012 09:02:45 +0200 Subject: [Slackbuilds-users] requirements in README files In-Reply-To: <5FB83E4C-6A33-4258-AD68-CECD0912BD87@uq.edu.au> References: <20120709112042.Horde.im3MDogBVY5P_wTaY8lf2xA@mail.dawnrazor.net> <20120709152452.Horde.QoYmYYgBVY5P_z4UvpOXMbA@mail.dawnrazor.net> <20120709205643.GA3297@KeithPC.phub.net.cable.rogers.com> <5FB83E4C-6A33-4258-AD68-CECD0912BD87@uq.edu.au> Message-ID: <20120710090245.480b4b44@hamalay.mnt> Il giorno Tue, 10 Jul 2012 10:42:10 +1000 Christoph Willing ha scritto: > A listing of build prerequisites is even more innocuous - no > particular need for that to appear in a final package at all. My > suggestion would be for a PREREQS="..." line in the .info file > (which doesn't by default appear in the final package). I am not absolutely against this idea, but it is not so simple. First, there are several types of prerequisites: - mandatory build dependencies; - optional build dependencies; - mandatory runtime dependencies; - optional runtime dependencies; - build and/or runtime dependencies who relies on one o more flags users can pass to .SlackBuild. To complicate the scenario ;) upstream developers sometimes use library auto-detection in their configure files, so maybe it should taken into the account, too. Moreover, it would also make sense to note reverse dependencies (a prerequisite upgrade, particularly for a shared library, often entails a new compilation of packages who uses it). -- GNU/Linux * Slackware64 current/multilib LU #210970 SU #12583 LM #98222/#412913 From c.willing at uq.edu.au Tue Jul 10 10:24:24 2012 From: c.willing at uq.edu.au (Christoph Willing) Date: Tue, 10 Jul 2012 20:24:24 +1000 Subject: [Slackbuilds-users] requirements in README files In-Reply-To: <20120710090245.480b4b44@hamalay.mnt> References: <20120709112042.Horde.im3MDogBVY5P_wTaY8lf2xA@mail.dawnrazor.net> <20120709152452.Horde.QoYmYYgBVY5P_z4UvpOXMbA@mail.dawnrazor.net> <20120709205643.GA3297@KeithPC.phub.net.cable.rogers.com> <5FB83E4C-6A33-4258-AD68-CECD0912BD87@uq.edu.au> <20120710090245.480b4b44@hamalay.mnt> Message-ID: On 10/07/2012, at 5:02 PM, LukenShiro wrote: > Il giorno Tue, 10 Jul 2012 10:42:10 +1000 > Christoph Willing ha scritto: >> A listing of build prerequisites is even more innocuous - no >> particular need for that to appear in a final package at all. My >> suggestion would be for a PREREQS="..." line in the .info file >> (which doesn't by default appear in the final package). > > I am not absolutely against this idea, but it is not so simple. > First, there are several types of prerequisites: > - mandatory build dependencies; > - optional build dependencies; The PREREQS="..." line, as I use it already, is only used for build dependencies. Let me say right now that I suggest this mechanism largely because I have been using it myself for some time. In the lab that I'm responsible for, we have many specialist softwares that have various build dependencies. I have a number of my own build scripts which specify the build depenednecies but over the last year or so I have been modifying SBo scripts (when they already exist) to include a PREREQS= line in the info file. If PREREQS were already included, I wouldn't have to maintain my own versions of them. However the effort in doing so is worth it, so I do. I general, the PREREQS field is most useful for mandatory build dependencies - my unsubstantiated guestimate is that this probably covers about 80-90% of all cases. Other cases can be dealt with specifically in the .SlackBuild script itself. However even if an optional dependency is listed in PREREQS but not actually used (i.e. we needlessly treat even an optional dependency as mandatory), so what? Its just another package that happens to be installed while you're building - whether its used or not. In general, any given system has probably hundreds of packages installed that are not needed to build a particular software package. > - mandatory runtime dependencies; > - optional runtime dependencies; I believe runtime dependencies should be a different topic. I don't use the PREREQS= entry for that. > - build and/or runtime dependencies who relies on one o more flags > users can pass to .SlackBuild. As above, an SBo author could also "blindly" treat any optional build dependencies as mandatory and include them in the PREREQS field. Whether such optional dependencies are actually used could depend on flags passed to the .SlackBuild > To complicate the scenario ;) upstream developers sometimes use > library > auto-detection in their configure files, so maybe it should taken into > the account, too. Setting up a useful PREREQS field can actually make use of that mechanism i.e. as a configure script fails due to a missing package, that package can be added to the PREREQS field. If the PREREQS field is used to ensure that its members are installed at build time (after all, this is the purpose of the PREREQS field) then the previously missing package will be installed next time the build script is run. After dealing with a number of such failures, a reliable PREREQS field will have been constructed. By the time such an SBO script reaches an ordinary user, it will just work because all the build dependencies have already been transparently specified. chris > > Moreover, it would also make sense to note reverse dependencies (a > prerequisite upgrade, particularly for a shared library, often > entails a new compilation of packages who uses it). > > -- > GNU/Linux * Slackware64 current/multilib > LU #210970 SU #12583 LM #98222/#412913 > _______________________________________________ > 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/ > Christoph Willing +61 7 3365 8316 Research Computing Centre University of Queensland From jens at tuxane.com Tue Jul 10 11:29:55 2012 From: jens at tuxane.com (TuxaneMedia) Date: Tue, 10 Jul 2012 13:29:55 +0200 Subject: [Slackbuilds-users] requirements in README files In-Reply-To: References: <20120709112042.Horde.im3MDogBVY5P_wTaY8lf2xA@mail.dawnrazor.net> <20120709152452.Horde.QoYmYYgBVY5P_z4UvpOXMbA@mail.dawnrazor.net> <20120709205643.GA3297@KeithPC.phub.net.cable.rogers.com> <5FB83E4C-6A33-4258-AD68-CECD0912BD87@uq.edu.au> <20120710090245.480b4b44@hamalay.mnt> Message-ID: <4FFC1233.5090009@tuxane.com> Am 10.07.2012 06:54, schrieb Chess Griffin: > I have no idea if the current SBo admins are considering adding > dependency information like the OP suggested. Maybe so, maybe not. And > whatever they decide is fine by me. I don't know if I remember it 100% correctly, but I think we had the subject of how to mention the deps in README files not long ago. As far as I remember, the conclusion was to add only deps from SBo to a README and to assume user had done a *full* Slackware installation before. The admins do alter README files and it looks like this is getting the way to go: "This requires zope.component and gaphas " Generally speaking I like portage on my gentoo box, but everytime I get a "Slot conflict" or a "package block" I wish I could go the Slackware way and just go on and compile the package, maybe even with a "runtime dep" missing. -------------- next part -------------- An HTML attachment was scrubbed... URL: From baildon.research at googlemail.com Tue Jul 10 12:00:06 2012 From: baildon.research at googlemail.com (David Spencer) Date: Tue, 10 Jul 2012 13:00:06 +0100 Subject: [Slackbuilds-users] requirements in README files In-Reply-To: <4FFC1233.5090009@tuxane.com> References: <20120709112042.Horde.im3MDogBVY5P_wTaY8lf2xA@mail.dawnrazor.net> <20120709152452.Horde.QoYmYYgBVY5P_z4UvpOXMbA@mail.dawnrazor.net> <20120709205643.GA3297@KeithPC.phub.net.cable.rogers.com> <5FB83E4C-6A33-4258-AD68-CECD0912BD87@uq.edu.au> <20120710090245.480b4b44@hamalay.mnt> <4FFC1233.5090009@tuxane.com> Message-ID: For the record I'm personally not 100% hostile to the idea. I could live with a formal mechanism for declaring mandatory direct dependencies, but I wouldn't stay up late myself to make it happen. If it ever did happen, I'd hope that both build-time and run-time dependencies should be included with no distinction. The end users would be freaked out if packages failed to run despite meeting what they would see as formally documented deps. It's reassuring that nobody is advocating version dependency, you know the sort of thing: gnome-stuff >= 2.34.56. You're not all completely mad and I respect you for that :D > "This requires zope.component and gaphas " Just imagine the chaos for automatic parsing if there was a package named 'and' :-) -D. From joshuakwood at gmail.com Tue Jul 10 12:20:56 2012 From: joshuakwood at gmail.com (JK Wood) Date: Tue, 10 Jul 2012 07:20:56 -0500 Subject: [Slackbuilds-users] requirements in README files In-Reply-To: References: <20120709112042.Horde.im3MDogBVY5P_wTaY8lf2xA@mail.dawnrazor.net> <20120709152452.Horde.QoYmYYgBVY5P_z4UvpOXMbA@mail.dawnrazor.net> <20120709205643.GA3297@KeithPC.phub.net.cable.rogers.com> <5FB83E4C-6A33-4258-AD68-CECD0912BD87@uq.edu.au> <20120710090245.480b4b44@hamalay.mnt> <4FFC1233.5090009@tuxane.com> Message-ID: On Jul 10, 2012 7:00 AM, "David Spencer" wrote: > > For the record I'm personally not 100% hostile to the idea. I could > live with a formal mechanism for declaring mandatory direct > dependencies, but I wouldn't stay up late myself to make it happen. > If it ever did happen, I'd hope that both build-time and run-time > dependencies should be included with no distinction. The end users > would be freaked out if packages failed to run despite meeting what > they would see as formally documented deps. > > It's reassuring that nobody is advocating version dependency, you know > the sort of thing: gnome-stuff >= 2.34.56. You're not all completely > mad and I respect you for that :D But, that's exactly the problem. Sometimes, there is a minimum necessary version required to build a package. Other times, there is a maximum required (I'm thinking of Python in particular, but I know there are other, non-official packages that have had this problem.) In theory, the current admin system in use at SBo should keep this from being a problem. In practice, maybe not. But then, we can't really just include version information, because that's a whole nother ball of wax. What's newer, 1.54 or r1076? > > > "This requires zope.component and gaphas " > > Just imagine the chaos for automatic parsing if there was a package > named 'and' :-) > > -D. And what if more than one package fits the bill? The wxWidgets packages come to mind. I believe at one point, there were three different packages, any of which would satisfy that one dependency, and any of which required a fairly large source download and a fairly lengthy compile. You definitely didn't want to build all three! > _______________________________________________ > 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 dragonwisard at gmail.com Tue Jul 10 13:07:42 2012 From: dragonwisard at gmail.com (Ben Mendis) Date: Tue, 10 Jul 2012 09:07:42 -0400 Subject: [Slackbuilds-users] requirements in README files In-Reply-To: <1341896067.11438.140661100011705.4FEC53E5@webmail.messagingengine.com> References: <20120709112042.Horde.im3MDogBVY5P_wTaY8lf2xA@mail.dawnrazor.net> <20120709152452.Horde.QoYmYYgBVY5P_z4UvpOXMbA@mail.dawnrazor.net> <20120709205643.GA3297@KeithPC.phub.net.cable.rogers.com> <20120709182927.61f11fd6@oogah> <20120709225119.Horde.L90oAogBVY5P_6a3Vv5nMbA@mail.dawnrazor.net> <1341896067.11438.140661100011705.4FEC53E5@webmail.messagingengine.com> Message-ID: I truly respect all of this reverence for "the Slackware way", however that really feels like an excuse. A few years ago it wasn't "the Slackware way" to run on 64-bit x86, but now it is. It also wasn't "the Slackware way" to use xz compression, but now it is. Before that it wasn't "the Slackware way" to use an automated tool to download and install/update packages, but then slackpkg was added. And so on. What is or isn't "the Slackware way" isn't set in stone. It's a combination of how we, as Slackware's user community, choose to run Slackware and Pat V's whim. While I generally trust Pat V's whim, I think that his perspective in this specific case may be biased. What he and his team do to maintain the Slackware OS is different in some fundamental ways from how the user community interacts with the system and especially with third-party software like the stuff on SBo. Look, nobody here is claiming that dependency resolution is an easy problem to solve generically for all cases. However, just because it's a hard problem doesn't mean we should ignore the problem or lie to ourselves and call it a "feature". Let's acknowledge it. Dependency resolution is a very hard problem. Nobody else has a perfect solution for how to do it either. But just because it's a hard problem doesn't me we have to throw our hands up and not do anything. Just because there are corner cases and exceptions doesn't mean that it's useless to even try. This isn't about solving a problem which may, in fact, be an unsolvable problem. It's about making that problem a little less annoying in some of the most common and easiest to handle cases. The vast majority of cases on SBo are low-hanging fruit in problem space of dependency resolution. Currently, Slackware's package tools wouldn't even know that dependency information exists, let alone how to enforce it. And nobody here has suggested that that should change. All that we're saying is that it would be nice if it were possible to _partially_ automate the resolution of the dependency graph. And when you run into those corner cases that everyone keeps harping on like wx* and different version requirements and optional dependencies or whatever else, then the it would still be the sysadmin's role (YOU) to resolve those just as manually as you always did before. I'm not saying I want portage. If I did I would be using Gentoo instead of Slackware. I *love* the way that Slackware handle's packages, and I love how the package tools deal with dependencies (specifically, that they don't). However I think that having optional tools that help resolve dependency graphs would still be a HUGE improvement over the hours-of-tab-hell-using-paper-and-pencil method that we have now. It would cut out the low-hanging fruit in the process leaving you to just verify the list and fill in some blanks. Minutes of manual work instead of hours of manual work. On Tue, Jul 10, 2012 at 12:54 AM, Chess Griffin wrote: > First, a couple of disclaimers: > > 1. I started the sbopkg project and was soon joined by slakmagik and > Mauro Giachero, both of whom made sbopkg far better than I ever could > have done by myself. I retired in 2010 and handed the project over to > slakmagik who has done a great job in continuing to maintain it along > with help by Mauro. I thank them both for their past and future help. > > 2. I used to be a SlackBuilds.org admin but also retired from that > role. I know what it's like to be an admin and to test the submissions. > It's a lot of work, and what I did paled in comparison to what the > other admins did, and continue to do. I am not an admin any longer, so > I don't speak for the SBo project in any capacity. > > Having said that, I think the point made earlier by T3slider that the > SBo project is not intended to be a do-everything script repository is > spot on. IMHO, the SBo project is simply intended to provide a > repository of SlackBuild scripts just like the ones that Pat creates for > official Slackware packages. Since those official SlackBuild scripts > don't have any kind of dependency information, neither do the SBo > scripts (other than what the maintainer decides to put in the README). > > When slackmagik, Mauro, and I came up with the idea of the sbopkg > queuefiles, the point was to only try to automate what the user would > otherwise do manually. We've all sat down with a paper and pencil and > written out our list of SBo packages to build and, after reading through > the READMEs, figured out the right order of build dependencies. The > queuefiles is intended to be simply a way to "save" that information to > make it easier to build the packages again later on. Is sbopkg or its > queuefiles perfect? Certainly not. But, it really was written with the > "Slackware way" in mind and I think overall, it works well. Sbopkg > doesn't try to figure out anything for you -- the user still has to put > in the initial work -- but sbopkg can make life a little easier by > saving this information in a simple text file we call a queuefile for > future use. > > I understand the OP's point and yes, I can see a case where having a > standardized format for including compile-time dependencies in the > README or .info file would be helpful. But that's never been the > Slackware way so putting that in place would move the SBo project from > its original purpose, at least as I see it. > > Finally, and here is where I put on my "former SBo admin" hat on, if the > SBo project were to change things and start requiring that build-time > dependencies be included in the README or .info file, then this would > definitely lead to more work for the current SBo admins, who already put > in a lot of time in maintaining SBo. The fact is that many SlackBuild > script maintainers are not that communicative (and I've been guilty of > this myself -- I only just now got to updating OpenArena after /many/ > requests -- sorry!) and either the admins would have to try and track > down all the maintainers to update their submissions to the new format > or do it themselves. And, of course, test the listed dependencies. > What if someone forgot to add a dependency? Each submission would have > to be tested on a clean, newly installed system in a VM or something to > ensure that the dependencies were listed correctly and in the right > order. That's a lot of work. > > Ultimately, I think Slackware, and the SBo project, are geared toward > those who are willing to put in some of their own effort when it comes > to adding third-party software. I use FreeBSD (and OpenBSD) as well so > I am familiar with their ports and packages systems. And, for the most > part, they work well. And I was even a FreeBSD port maintainer for > awhile. But those systems were built with that kind of dependency > tracking from the outset and Slackware SlackBuild scripts were not. > Therefore, any such dependency tracking is a bolted-on solution. > > I have no idea if the current SBo admins are considering adding > dependency information like the OP suggested. Maybe so, maybe not. And > whatever they decide is fine by me. Either way, I really appreciate all > the hard work the SBo admins and the SBo Slackbuild script maintainers > put in. The SBo project is a huge, and I mean HUGE, benefit to the > Slackware community. > > Just my < $0.02. :-) > > -- > Chess Griffin > _______________________________________________ > 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 nickblizzard1776 at gmail.com Tue Jul 10 13:10:37 2012 From: nickblizzard1776 at gmail.com (Nick Blizzard) Date: Tue, 10 Jul 2012 09:10:37 -0400 Subject: [Slackbuilds-users] requirements in README files In-Reply-To: References: <20120709112042.Horde.im3MDogBVY5P_wTaY8lf2xA@mail.dawnrazor.net> <20120709152452.Horde.QoYmYYgBVY5P_z4UvpOXMbA@mail.dawnrazor.net> <20120709205643.GA3297@KeithPC.phub.net.cable.rogers.com> <20120709182927.61f11fd6@oogah> <20120709225119.Horde.L90oAogBVY5P_6a3Vv5nMbA@mail.dawnrazor.net> <1341896067.11438.140661100011705.4FEC53E5@webmail.messagingengine.com> Message-ID: With respect, changing a compression scheme or moving on to x64 hardware isn't core to Slackware... the simplicity of the package management system, and not being forced to include any dependencies, managing those yourself... that's core to slackware. is there any way to make this pointless debate / discussion end? On Tue, Jul 10, 2012 at 9:07 AM, Ben Mendis wrote: > I truly respect all of this reverence for "the Slackware way", however that > really feels like an excuse. A few years ago it wasn't "the Slackware way" > to run on 64-bit x86, but now it is. It also wasn't "the Slackware way" to > use xz compression, but now it is. Before that it wasn't "the Slackware way" > to use an automated tool to download and install/update packages, but then > slackpkg was added. And so on. What is or isn't "the Slackware way" isn't > set in stone. It's a combination of how we, as Slackware's user community, > choose to run Slackware and Pat V's whim. > > While I generally trust Pat V's whim, I think that his perspective in this > specific case may be biased. What he and his team do to maintain the > Slackware OS is different in some fundamental ways from how the user > community interacts with the system and especially with third-party software > like the stuff on SBo. > > Look, nobody here is claiming that dependency resolution is an easy problem > to solve generically for all cases. However, just because it's a hard > problem doesn't mean we should ignore the problem or lie to ourselves and > call it a "feature". Let's acknowledge it. > > Dependency resolution is a very hard problem. Nobody else has a perfect > solution for how to do it either. > > But just because it's a hard problem doesn't me we have to throw our hands > up and not do anything. Just because there are corner cases and exceptions > doesn't mean that it's useless to even try. This isn't about solving a > problem which may, in fact, be an unsolvable problem. It's about making that > problem a little less annoying in some of the most common and easiest to > handle cases. The vast majority of cases on SBo are low-hanging fruit in > problem space of dependency resolution. > > Currently, Slackware's package tools wouldn't even know that dependency > information exists, let alone how to enforce it. And nobody here has > suggested that that should change. All that we're saying is that it would be > nice if it were possible to _partially_ automate the resolution of the > dependency graph. And when you run into those corner cases that everyone > keeps harping on like wx* and different version requirements and optional > dependencies or whatever else, then the it would still be the sysadmin's > role (YOU) to resolve those just as manually as you always did before. > > > I'm not saying I want portage. If I did I would be using Gentoo instead of > Slackware. I *love* the way that Slackware handle's packages, and I love how > the package tools deal with dependencies (specifically, that they don't). > However I think that having optional tools that help resolve dependency > graphs would still be a HUGE improvement over the > hours-of-tab-hell-using-paper-and-pencil method that we have now. It would > cut out the low-hanging fruit in the process leaving you to just verify the > list and fill in some blanks. Minutes of manual work instead of hours of > manual work. > > On Tue, Jul 10, 2012 at 12:54 AM, Chess Griffin > wrote: >> >> First, a couple of disclaimers: >> >> 1. I started the sbopkg project and was soon joined by slakmagik and >> Mauro Giachero, both of whom made sbopkg far better than I ever could >> have done by myself. I retired in 2010 and handed the project over to >> slakmagik who has done a great job in continuing to maintain it along >> with help by Mauro. I thank them both for their past and future help. >> >> 2. I used to be a SlackBuilds.org admin but also retired from that >> role. I know what it's like to be an admin and to test the submissions. >> It's a lot of work, and what I did paled in comparison to what the >> other admins did, and continue to do. I am not an admin any longer, so >> I don't speak for the SBo project in any capacity. >> >> Having said that, I think the point made earlier by T3slider that the >> SBo project is not intended to be a do-everything script repository is >> spot on. IMHO, the SBo project is simply intended to provide a >> repository of SlackBuild scripts just like the ones that Pat creates for >> official Slackware packages. Since those official SlackBuild scripts >> don't have any kind of dependency information, neither do the SBo >> scripts (other than what the maintainer decides to put in the README). >> >> When slackmagik, Mauro, and I came up with the idea of the sbopkg >> queuefiles, the point was to only try to automate what the user would >> otherwise do manually. We've all sat down with a paper and pencil and >> written out our list of SBo packages to build and, after reading through >> the READMEs, figured out the right order of build dependencies. The >> queuefiles is intended to be simply a way to "save" that information to >> make it easier to build the packages again later on. Is sbopkg or its >> queuefiles perfect? Certainly not. But, it really was written with the >> "Slackware way" in mind and I think overall, it works well. Sbopkg >> doesn't try to figure out anything for you -- the user still has to put >> in the initial work -- but sbopkg can make life a little easier by >> saving this information in a simple text file we call a queuefile for >> future use. >> >> I understand the OP's point and yes, I can see a case where having a >> standardized format for including compile-time dependencies in the >> README or .info file would be helpful. But that's never been the >> Slackware way so putting that in place would move the SBo project from >> its original purpose, at least as I see it. >> >> Finally, and here is where I put on my "former SBo admin" hat on, if the >> SBo project were to change things and start requiring that build-time >> dependencies be included in the README or .info file, then this would >> definitely lead to more work for the current SBo admins, who already put >> in a lot of time in maintaining SBo. The fact is that many SlackBuild >> script maintainers are not that communicative (and I've been guilty of >> this myself -- I only just now got to updating OpenArena after /many/ >> requests -- sorry!) and either the admins would have to try and track >> down all the maintainers to update their submissions to the new format >> or do it themselves. And, of course, test the listed dependencies. >> What if someone forgot to add a dependency? Each submission would have >> to be tested on a clean, newly installed system in a VM or something to >> ensure that the dependencies were listed correctly and in the right >> order. That's a lot of work. >> >> Ultimately, I think Slackware, and the SBo project, are geared toward >> those who are willing to put in some of their own effort when it comes >> to adding third-party software. I use FreeBSD (and OpenBSD) as well so >> I am familiar with their ports and packages systems. And, for the most >> part, they work well. And I was even a FreeBSD port maintainer for >> awhile. But those systems were built with that kind of dependency >> tracking from the outset and Slackware SlackBuild scripts were not. >> Therefore, any such dependency tracking is a bolted-on solution. >> >> I have no idea if the current SBo admins are considering adding >> dependency information like the OP suggested. Maybe so, maybe not. And >> whatever they decide is fine by me. Either way, I really appreciate all >> the hard work the SBo admins and the SBo Slackbuild script maintainers >> put in. The SBo project is a huge, and I mean HUGE, benefit to the >> Slackware community. >> >> Just my < $0.02. :-) >> >> -- >> Chess Griffin >> _______________________________________________ >> 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 dragonwisard at gmail.com Tue Jul 10 13:21:21 2012 From: dragonwisard at gmail.com (Ben Mendis) Date: Tue, 10 Jul 2012 09:21:21 -0400 Subject: [Slackbuilds-users] requirements in README files In-Reply-To: References: <20120709112042.Horde.im3MDogBVY5P_wTaY8lf2xA@mail.dawnrazor.net> <20120709152452.Horde.QoYmYYgBVY5P_z4UvpOXMbA@mail.dawnrazor.net> <20120709205643.GA3297@KeithPC.phub.net.cable.rogers.com> <20120709182927.61f11fd6@oogah> <20120709225119.Horde.L90oAogBVY5P_6a3Vv5nMbA@mail.dawnrazor.net> <1341896067.11438.140661100011705.4FEC53E5@webmail.messagingengine.com> Message-ID: On Tue, Jul 10, 2012 at 9:10 AM, Nick Blizzard wrote: > With respect, changing a compression scheme or moving on to x64 > hardware isn't core to Slackware... the simplicity of the package > management system, and not being forced to include any dependencies, > managing those yourself... that's core to slackware. Nick, NOBODY is talking about forcing any kind of dependency management. There would be no change to the package format or the package management tools. There would only be a SEPARATE and OPTIONAL tool for partially resolving a dependency graph. Nobody is gonna get up in your grille. If you don't like optional tools that make useful suggestions than you can ignore this whole thread because even if it were implemented it wouldn't affect you in the slightest. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragonwisard at gmail.com Tue Jul 10 13:23:09 2012 From: dragonwisard at gmail.com (Ben Mendis) Date: Tue, 10 Jul 2012 09:23:09 -0400 Subject: [Slackbuilds-users] requirements in README files In-Reply-To: References: <20120709112042.Horde.im3MDogBVY5P_wTaY8lf2xA@mail.dawnrazor.net> <20120709152452.Horde.QoYmYYgBVY5P_z4UvpOXMbA@mail.dawnrazor.net> <20120709205643.GA3297@KeithPC.phub.net.cable.rogers.com> <20120709182927.61f11fd6@oogah> <20120709225119.Horde.L90oAogBVY5P_6a3Vv5nMbA@mail.dawnrazor.net> <1341896067.11438.140661100011705.4FEC53E5@webmail.messagingengine.com> Message-ID: Optional dependency graph resolution is NOT a slippery slope to turning Slackware into Debian or Gentoo. On Tue, Jul 10, 2012 at 9:21 AM, Ben Mendis wrote: > > > On Tue, Jul 10, 2012 at 9:10 AM, Nick Blizzard > wrote: > >> With respect, changing a compression scheme or moving on to x64 >> hardware isn't core to Slackware... the simplicity of the package >> management system, and not being forced to include any dependencies, >> managing those yourself... that's core to slackware. > > > Nick, NOBODY is talking about forcing any kind of dependency management. > There would be no change to the package format or the package management > tools. There would only be a SEPARATE and OPTIONAL tool for partially > resolving a dependency graph. > > Nobody is gonna get up in your grille. If you don't like optional tools > that make useful suggestions than you can ignore this whole thread because > even if it were implemented it wouldn't affect you in the slightest. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jens at tuxane.com Tue Jul 10 11:28:46 2012 From: jens at tuxane.com (TuxaneMedia) Date: Tue, 10 Jul 2012 13:28:46 +0200 Subject: [Slackbuilds-users] requirements in README files In-Reply-To: <1341896067.11438.140661100011705.4FEC53E5@webmail.messagingengine.com> References: <20120709112042.Horde.im3MDogBVY5P_wTaY8lf2xA@mail.dawnrazor.net> <20120709152452.Horde.QoYmYYgBVY5P_z4UvpOXMbA@mail.dawnrazor.net> <20120709205643.GA3297@KeithPC.phub.net.cable.rogers.com> <20120709182927.61f11fd6@oogah> <20120709225119.Horde.L90oAogBVY5P_6a3Vv5nMbA@mail.dawnrazor.net> <1341896067.11438.140661100011705.4FEC53E5@webmail.messagingengine.com> Message-ID: <4FFC11EE.1090408@tuxane.com> Am 10.07.2012 06:54, schrieb Chess Griffin: > I have no idea if the current SBo admins are considering adding > dependency information like the OP suggested. Maybe so, maybe not. And > whatever they decide is fine by me. I don't know if I remember it 100% correctly, but I think we had the subject of how to mention the deps in README files not long ago. As far as I remember, the conclusion was to add only deps from SBo to a README and to assume user had done a *full* Slackware installation before. The admins do alter README files and it looks like this is getting the way to go: "This requires zope.component and gaphas " Generally speaking I like portage on my gentoo box, but everytime I get a "Slot conflict" or a "package block" I wish I could go the Slackware way and just go on and compile the package, maybe even with a "runtime dep" missing. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jens at tuxane.com Tue Jul 10 11:19:43 2012 From: jens at tuxane.com (TuxaneMedia) Date: Tue, 10 Jul 2012 13:19:43 +0200 Subject: [Slackbuilds-users] requirements in README files In-Reply-To: <1341896067.11438.140661100011705.4FEC53E5@webmail.messagingengine.com> References: <20120709112042.Horde.im3MDogBVY5P_wTaY8lf2xA@mail.dawnrazor.net> <20120709152452.Horde.QoYmYYgBVY5P_z4UvpOXMbA@mail.dawnrazor.net> <20120709205643.GA3297@KeithPC.phub.net.cable.rogers.com> <20120709182927.61f11fd6@oogah> <20120709225119.Horde.L90oAogBVY5P_6a3Vv5nMbA@mail.dawnrazor.net> <1341896067.11438.140661100011705.4FEC53E5@webmail.messagingengine.com> Message-ID: <4FFC0FCF.5050801@tuxane.com> Am 10.07.2012 06:54, schrieb Chess Griffin: > I have no idea if the current SBo admins are considering adding > dependency information like the OP suggested. Maybe so, maybe not. And > whatever they decide is fine by me. I don't know if I remember it 100% correctly, but I think we had the subject of how to mention the deps in README files not long ago. As far as I remember, the conclusion was to add only deps from SBo to a README and to assume user had done a *full* Slackware installation before. The admins do alter README files and it looks like this is getting the way to go: "This requires zope.component and gaphas " Generally speaking I like portage on my gentoo box, but everytime I get a "Slot conflict" or a "package block" I wish I could go the Slackware way and just go on and compile the package, maybe even with a "runtime dep" missing. From j at dawnrazor.net Tue Jul 10 16:31:23 2012 From: j at dawnrazor.net (J) Date: Tue, 10 Jul 2012 11:31:23 -0500 Subject: [Slackbuilds-users] requirements in README files Message-ID: <20120710113123.Horde.so73a4gBVY5P-Fjbdl6TOAA@mail.dawnrazor.net> Well, morning folks. why is it always morning when one works nightshift? so not fair. anyway. so, first off, sbotools already exists and has some requirement-parsing, it is how I deal with slackbuilds.org myself. and I continue to hack on the parsing code to improve it for the gazillion corner-cases. so let's talk about some of the irrelevancies that keep cropping up for a moment, so that we can hopefully stop talking about them, stop all this bikeshedding, and focus on the subject at hand. 1. portage - I don't think anyone here has any interest in duplicating that mess. I certainly don't. 2. the "slackware way" - if you feel that manually dealing with your sbo requirements keep you true and pure to the "way" - fine, so what, and who cares? this has nothing to do with you, so please stop bikeshedding. 3. Buildtime, optional, etc - I talked about this already. I am only interested in consistency about how hard and fast requirements are documented in README files, and that is *it*. I am not interested in changing anything else, anywhere, including how optional dependencies are or are not documented. 4. sbopkg and queue files - that idea is cool, but as a solution to this problem it represents not only a massive repeating of work, but also a massive amount of extremely inelegant brute-forcing. I've seen a few times mention of adding this stuff to the SlackBuild, or a separate file. As I mentioned, that would be ideal - it is by the far the easiest solution to handle programatically. but it doesn't make sense here, and I personally am not terribly interested in seeing this happen. requirements *must* be listed in the README - so, since they're there already, that will do, if we can get some consistency. With that, then in the following case: Quoting Christoph Willing : > specify the build depenednecies but over the last year or so I have > been modifying SBo scripts (when they already exist) to include a > PREREQS= line in the info file. If PREREQS were already included, I > wouldn't have to maintain my own versions of them. However the > effort in doing so is worth it, so I do. Christoph could easily write his own parser to deal with his use-case. anyway. Quoting TuxaneMedia : > The admins do alter README files and it looks like this is getting the > way to go: > > "This requires zope.component and gaphas " is this absolute fact? can we get some admins to chime in? if this is fact, and all admins are doing it and following the same format, then this means that for 14.0 we'll have consistency, and my work here is done. Quoting Chess Griffin : > Finally, and here is where I put on my "former SBo admin" hat on, if the > SBo project were to change things and start requiring that build-time > dependencies be included in the README or .info file, then this would > definitely lead to more work for the current SBo admins, who already put > in a lot of time in maintaining SBo. The fact is that many SlackBuild > script maintainers are not that communicative (and I've been guilty of > this myself -- I only just now got to updating OpenArena after /many/ > requests -- sorry!) and either the admins would have to try and track > down all the maintainers to update their submissions to the new format > or do it themselves. And, of course, test the listed dependencies. > What if someone forgot to add a dependency? Each submission would have > to be tested on a clean, newly installed system in a VM or something to > ensure that the dependencies were listed correctly and in the right > order. That's a lot of work. I think this is both true and false. regarding the work load, you're absolutely right, and I would be absolutely *delighted* to handle the format-ensuring stuff. where you're dead wrong is the stuff about testing. what in the world does all that have to do with anything? the testing process wouldn't change one iota from where it currently stands. well, thanks to the folks who've made intelligent and well-thought out points on both sides. hopefully we can get some maintainers to weight in now. maintainers? thanks folks. J From joshuakwood at gmail.com Tue Jul 10 16:52:49 2012 From: joshuakwood at gmail.com (JK Wood) Date: Tue, 10 Jul 2012 11:52:49 -0500 Subject: [Slackbuilds-users] requirements in README files In-Reply-To: <20120710113123.Horde.so73a4gBVY5P-Fjbdl6TOAA@mail.dawnrazor.net> References: <20120710113123.Horde.so73a4gBVY5P-Fjbdl6TOAA@mail.dawnrazor.net> Message-ID: On Jul 10, 2012 11:31 AM, "J" wrote: > > > Well, morning folks. why is it always morning when one works nightshift? so not fair. anyway. > > so, first off, sbotools already exists and has some requirement-parsing, it is how I deal with slackbuilds.org myself. and I continue to hack on the parsing code to improve it for the gazillion corner-cases. > > so let's talk about some of the irrelevancies that keep cropping up for a moment, so that we can hopefully stop talking about them, stop all this bikeshedding, and focus on the subject at hand. > > 1. portage - I don't think anyone here has any interest in duplicating that mess. I certainly don't. > 2. the "slackware way" - if you feel that manually dealing with your sbo requirements keep you true and pure to the "way" - fine, so what, and who cares? this has nothing to do with you, so please stop bikeshedding. Maintainer of a number of scripts here. This has EVERYTHING to do with us. You're asking me to take it upon myself to make a change that doesn't benefit me, but benefits you? A change that allows you to go against the philosophy that I subscribe to? Good luck, friend. > 3. Buildtime, optional, etc - I talked about this already. I am only interested in consistency about how hard and fast requirements are documented in README files, and that is *it*. I am not interested in changing anything else, anywhere, including how optional dependencies are or are not documented. > 4. sbopkg and queue files - that idea is cool, but as a solution to this problem it represents not only a massive repeating of work, but also a massive amount of extremely inelegant brute-forcing. > > I've seen a few times mention of adding this stuff to the SlackBuild, or a separate file. As I mentioned, that would be ideal - it is by the far the easiest solution to handle programatically. but it doesn't make sense here, and I personally am not terribly interested in seeing this happen. requirements *must* be listed in the README - so, since they're there already, that will do, if we can get some consistency. With that, then in the following case: > > > Quoting Christoph Willing : > >> specify the build depenednecies but over the last year or so I have been modifying SBo scripts (when they already exist) to include a PREREQS= line in the info file. If PREREQS were already included, I wouldn't have to maintain my own versions of them. However the effort in doing so is worth it, so I do. > > > Christoph could easily write his own parser to deal with his use-case. > > anyway. > > > Quoting TuxaneMedia : > >> The admins do alter README files and it looks like this is getting the >> way to go: >> >> "This requires zope.component and gaphas " > > > is this absolute fact? can we get some admins to chime in? if this is fact, and all admins are doing it and following the same format, then this means that for 14.0 we'll have consistency, and my work here is done. > > > Quoting Chess Griffin : > >> Finally, and here is where I put on my "former SBo admin" hat on, if the >> SBo project were to change things and start requiring that build-time >> dependencies be included in the README or .info file, then this would >> definitely lead to more work for the current SBo admins, who already put >> in a lot of time in maintaining SBo. The fact is that many SlackBuild >> script maintainers are not that communicative (and I've been guilty of >> this myself -- I only just now got to updating OpenArena after /many/ >> requests -- sorry!) and either the admins would have to try and track >> down all the maintainers to update their submissions to the new format >> or do it themselves. And, of course, test the listed dependencies. >> What if someone forgot to add a dependency? Each submission would have >> to be tested on a clean, newly installed system in a VM or something to >> ensure that the dependencies were listed correctly and in the right >> order. That's a lot of work. > > > I think this is both true and false. regarding the work load, you're absolutely right, and I would be absolutely *delighted* to handle the format-ensuring stuff. where you're dead wrong is the stuff about testing. what in the world does all that have to do with anything? the testing process wouldn't change one iota from where it currently stands. > > well, thanks to the folks who've made intelligent and well-thought out points on both sides. hopefully we can get some maintainers to weight in now. maintainers? > > thanks folks. > > J > > _______________________________________________ > 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 j at dawnrazor.net Tue Jul 10 17:05:09 2012 From: j at dawnrazor.net (J) Date: Tue, 10 Jul 2012 12:05:09 -0500 Subject: [Slackbuilds-users] requirements in README files In-Reply-To: References: <20120710113123.Horde.so73a4gBVY5P-Fjbdl6TOAA@mail.dawnrazor.net> Message-ID: <20120710120509.Horde.HC2eWogBVY5P-GDFwV7xDJY@mail.dawnrazor.net> Would you be so kind as to read a little further down? Perhaps the bit where I replied to Chess? Quoting JK Wood : > On Jul 10, 2012 11:31 AM, "J" wrote: >> >> >> Well, morning folks. why is it always morning when one works nightshift? > so not fair. anyway. >> >> so, first off, sbotools already exists and has some requirement-parsing, > it is how I deal with slackbuilds.org myself. and I continue to hack on the > parsing code to improve it for the gazillion corner-cases. >> >> so let's talk about some of the irrelevancies that keep cropping up for a > moment, so that we can hopefully stop talking about them, stop all this > bikeshedding, and focus on the subject at hand. >> >> 1. portage - I don't think anyone here has any interest in duplicating > that mess. I certainly don't. >> 2. the "slackware way" - if you feel that manually dealing with your sbo > requirements keep you true and pure to the "way" - fine, so what, and who > cares? this has nothing to do with you, so please stop bikeshedding. > > Maintainer of a number of scripts here. This has EVERYTHING to do with us. > You're asking me to take it upon myself to make a change that doesn't > benefit me, but benefits you? A change that allows you to go against the > philosophy that I subscribe to? Good luck, friend. > >> 3. Buildtime, optional, etc - I talked about this already. I am only > interested in consistency about how hard and fast requirements are > documented in README files, and that is *it*. I am not interested in > changing anything else, anywhere, including how optional dependencies are > or are not documented. >> 4. sbopkg and queue files - that idea is cool, but as a solution to this > problem it represents not only a massive repeating of work, but also a > massive amount of extremely inelegant brute-forcing. >> >> I've seen a few times mention of adding this stuff to the SlackBuild, or > a separate file. As I mentioned, that would be ideal - it is by the far the > easiest solution to handle programatically. but it doesn't make sense here, > and I personally am not terribly interested in seeing this happen. > requirements *must* be listed in the README - so, since they're there > already, that will do, if we can get some consistency. With that, then in > the following case: >> >> >> Quoting Christoph Willing : >> >>> specify the build depenednecies but over the last year or so I have been > modifying SBo scripts (when they already exist) to include a PREREQS= line > in the info file. If PREREQS were already included, I wouldn't have to > maintain my own versions of them. However the effort in doing so is worth > it, so I do. >> >> >> Christoph could easily write his own parser to deal with his use-case. >> >> anyway. >> >> >> Quoting TuxaneMedia : >> >>> The admins do alter README files and it looks like this is getting the >>> way to go: >>> >>> "This requires zope.component and gaphas " >> >> >> is this absolute fact? can we get some admins to chime in? if this is > fact, and all admins are doing it and following the same format, then this > means that for 14.0 we'll have consistency, and my work here is done. >> >> >> Quoting Chess Griffin : >> >>> Finally, and here is where I put on my "former SBo admin" hat on, if the >>> SBo project were to change things and start requiring that build-time >>> dependencies be included in the README or .info file, then this would >>> definitely lead to more work for the current SBo admins, who already put >>> in a lot of time in maintaining SBo. The fact is that many SlackBuild >>> script maintainers are not that communicative (and I've been guilty of >>> this myself -- I only just now got to updating OpenArena after /many/ >>> requests -- sorry!) and either the admins would have to try and track >>> down all the maintainers to update their submissions to the new format >>> or do it themselves. And, of course, test the listed dependencies. >>> What if someone forgot to add a dependency? Each submission would have >>> to be tested on a clean, newly installed system in a VM or something to >>> ensure that the dependencies were listed correctly and in the right >>> order. That's a lot of work. >> >> >> I think this is both true and false. regarding the work load, you're > absolutely right, and I would be absolutely *delighted* to handle the > format-ensuring stuff. where you're dead wrong is the stuff about testing. > what in the world does all that have to do with anything? the testing > process wouldn't change one iota from where it currently stands. >> >> well, thanks to the folks who've made intelligent and well-thought out > points on both sides. hopefully we can get some maintainers to weight in > now. maintainers? >> >> thanks folks. >> >> J >> >> _______________________________________________ >> 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 erik at slackbuilds.org Tue Jul 10 17:21:39 2012 From: erik at slackbuilds.org (Erik Hanson) Date: Tue, 10 Jul 2012 12:21:39 -0500 Subject: [Slackbuilds-users] requirements in README files In-Reply-To: References: <20120710113123.Horde.so73a4gBVY5P-Fjbdl6TOAA@mail.dawnrazor.net> Message-ID: <20120710122139.4c0ad9a2@shaggy.doo> On Tue, 10 Jul 2012 11:52:49 -0500 JK Wood wrote: > > Quoting TuxaneMedia : > > > >> The admins do alter README files and it looks like this is getting the > >> way to go: > >> > >> "This requires zope.component and gaphas " > > is this absolute fact? can we get some admins to chime in? if this is > fact, and all admins are doing it and following the same format, then this > means that for 14.0 we'll have consistency, and my work here is done. This is not a fact. We may change them at our discretion if they are messy, confusing, or wrong. There is no policy in place, written or otherwise, to make them consistent. -- Erik Hanson From matteo.bernardini at gmail.com Tue Jul 10 17:28:16 2012 From: matteo.bernardini at gmail.com (Matteo Bernardini) Date: Tue, 10 Jul 2012 19:28:16 +0200 Subject: [Slackbuilds-users] requirements in README files In-Reply-To: <20120710120509.Horde.HC2eWogBVY5P-GDFwV7xDJY@mail.dawnrazor.net> References: <20120710113123.Horde.so73a4gBVY5P-Fjbdl6TOAA@mail.dawnrazor.net> <20120710120509.Horde.HC2eWogBVY5P-GDFwV7xDJY@mail.dawnrazor.net> Message-ID: eh, I think you're assuming that every maintainer on SBo would be happy that you will make modifications to the README of the stuff they're maintaining to make your tool happy, but I won't be that sure of this. remember that nobody stops you to fork the repo and modify the slackbuilds as you like: I personally have chosen this path for my stuff for -current. Matteo From j at dawnrazor.net Tue Jul 10 17:32:17 2012 From: j at dawnrazor.net (J) Date: Tue, 10 Jul 2012 12:32:17 -0500 Subject: [Slackbuilds-users] requirements in README files In-Reply-To: <20120710122139.4c0ad9a2@shaggy.doo> References: <20120710113123.Horde.so73a4gBVY5P-Fjbdl6TOAA@mail.dawnrazor.net> <20120710122139.4c0ad9a2@shaggy.doo> Message-ID: <20120710123217.Horde.eWwoDYgBVY5P-GchQySzOAA@mail.dawnrazor.net> Understood. So what is the opinion of admins on this? Quoting Erik Hanson : > On Tue, 10 Jul 2012 11:52:49 -0500 > JK Wood wrote: > >> > Quoting TuxaneMedia : >> > >> >> The admins do alter README files and it looks like this is getting the >> >> way to go: >> >> >> >> "This requires zope.component and gaphas " >> >> is this absolute fact? can we get some admins to chime in? if this is >> fact, and all admins are doing it and following the same format, then this >> means that for 14.0 we'll have consistency, and my work here is done. > > This is not a fact. We may change them at our discretion if they are messy, > confusing, or wrong. There is no policy in place, written or otherwise, to > make them consistent. > > > -- > Erik Hanson > _______________________________________________ > 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 chess at chessgriffin.com Tue Jul 10 17:32:59 2012 From: chess at chessgriffin.com (Chess Griffin) Date: Tue, 10 Jul 2012 13:32:59 -0400 Subject: [Slackbuilds-users] requirements in README files In-Reply-To: <20120710113123.Horde.so73a4gBVY5P-Fjbdl6TOAA@mail.dawnrazor.net> References: <20120710113123.Horde.so73a4gBVY5P-Fjbdl6TOAA@mail.dawnrazor.net> Message-ID: <1341941579.19862.140661100288401.297EDFDF@webmail.messagingengine.com> On Tue, Jul 10, 2012, at 11:31 AM, J wrote: > where you're dead wrong is the stuff about > testing. what in the world does all that have to do with anything? the > testing process wouldn't change one iota from where it currently stands. > Right now, it's up each maintainer to list the dependencies in the README. Yes, there is some vetting of this information by the admins but essentially the burden remains with the maintainer. However, if the admins were to adopt an official SBo policy on dependency handling and naming convention in the README file, then it seems to me each submission would therefore need to be checked and tested against this policy, both for completeness and accuracy. And that would fall on the admins. -- Chess Griffin From jens at tuxane.com Tue Jul 10 17:35:42 2012 From: jens at tuxane.com (TuxaneMedia) Date: Tue, 10 Jul 2012 19:35:42 +0200 Subject: [Slackbuilds-users] requirements in README files In-Reply-To: <20120710113123.Horde.so73a4gBVY5P-Fjbdl6TOAA@mail.dawnrazor.net> References: <20120710113123.Horde.so73a4gBVY5P-Fjbdl6TOAA@mail.dawnrazor.net> Message-ID: <4FFC67EE.6070904@tuxane.com> Am 10.07.2012 18:31, schrieb J: > is this absolute fact? can we get some admins to chime in? if this is > fact, and all admins are doing it and following the same format, then > this means that for 14.0 we'll have consistency, and my work here is > done. No, not fact, but experience (just from the little two SlackBuilds I maintain), the admins correct bad english, bad programming and all the other evil Together with that discussion took place some time ago, I used to think so. I really don't remember the subject of that discussion , but there has been a similar to this one here: http://lists.slackbuilds.org/pipermail/slackbuilds-users/2010-October/006526.html I wouldn't be against a tool which could handle build order in an automated way, actually the queue files are a good thing, but they migth be too hard too maintain to have them for everything always up to date . Everybody who is using sbopkg uses a "not slackware genuine" tool and if you want to be purist, you could download every slackbuild manually and get the sources and compile them. So everything you *could* use to save time and efford is good in the first place But did you ever think of getting the info you need from another source as the SlackBuild ? Deps should always be almost the same for a package Maybe think of the LFS Project which lists dependencies always the same way , even required and optional ones. -------------- next part -------------- An HTML attachment was scrubbed... URL: From j at dawnrazor.net Tue Jul 10 17:44:58 2012 From: j at dawnrazor.net (J) Date: Tue, 10 Jul 2012 12:44:58 -0500 Subject: [Slackbuilds-users] requirements in README files In-Reply-To: <1341941579.19862.140661100288401.297EDFDF@webmail.messagingengine.com> References: <20120710113123.Horde.so73a4gBVY5P-Fjbdl6TOAA@mail.dawnrazor.net> <1341941579.19862.140661100288401.297EDFDF@webmail.messagingengine.com> Message-ID: <20120710124458.Horde.0rVgX4gBVY5P-GoahYZnMbA@mail.dawnrazor.net> Thanks for clearing that up, I now see where you're coming from. And I believe you're misunderstanding; please all me an attempt to clarify: My request is related *strictly* to formatting, and goes absolutely no further. So that if someone submits a slackbuild with the requirement listed, for example, like this: Depends on: x, y, and z Then it gets corrected by the admin, who is already making corrections, and would only need to change that line to: This requires x, y, and z. since that is currently the most popular format and so it makes sense to adopt that as the format in question. And, as mentioned, I would be very happy to take up this part of the work. So, again: my concern is strictly limited to formatting, and only for actual hard and fast requirements, not optionals. This represents a minor formatting change *at worst*. And that, I believe, requires no change to the testing currently done by admins. Quoting Chess Griffin : > On Tue, Jul 10, 2012, at 11:31 AM, J wrote: > >> where you're dead wrong is the stuff about >> testing. what in the world does all that have to do with anything? the >> testing process wouldn't change one iota from where it currently stands. >> > > Right now, it's up each maintainer to list the dependencies in the > README. Yes, there is some vetting of this information by the admins > but essentially the burden remains with the maintainer. However, if the > admins were to adopt an official SBo policy on dependency handling and > naming convention in the README file, then it seems to me each > submission would therefore need to be checked and tested against this > policy, both for completeness and accuracy. And that would fall on the > admins. > > -- > Chess Griffin > _______________________________________________ > 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 j at dawnrazor.net Tue Jul 10 17:51:21 2012 From: j at dawnrazor.net (J) Date: Tue, 10 Jul 2012 12:51:21 -0500 Subject: [Slackbuilds-users] requirements in README files In-Reply-To: <4FFC67EE.6070904@tuxane.com> References: <20120710113123.Horde.so73a4gBVY5P-Fjbdl6TOAA@mail.dawnrazor.net> <4FFC67EE.6070904@tuxane.com> Message-ID: <20120710125121.Horde.61ZFQYgBVY5P-GuZrX7DN9A@mail.dawnrazor.net> Quoting TuxaneMedia : > But did you ever think of getting the info you need from another source > as the SlackBuild ? > Deps should always be almost the same for a package > Maybe think of the LFS Project which lists dependencies always the same > way , even required and optional ones. I think that doing this would likely create dependency-hell for the person utilizing the tool - whereas the current system works very well, if extremely manually. That it works is, of course, the most important part. In fact, it's so simple that it works so solidly that it's a simple thing to automate, excepting the formatting, which is fairly willy-nilly. I think keeping it that way (simple - not willy-nilly) is highly desirable, and I think that the sort of dependency-checking that starts mucking with optional stuff and concerning itself with system packages is not something I care to try to deal with. From pwcazenave at gmail.com Tue Jul 10 18:09:26 2012 From: pwcazenave at gmail.com (Pierre Cazenave) Date: Tue, 10 Jul 2012 19:09:26 +0100 Subject: [Slackbuilds-users] requirements in README files In-Reply-To: <20120710124458.Horde.0rVgX4gBVY5P-GoahYZnMbA@mail.dawnrazor.net> References: <20120710113123.Horde.so73a4gBVY5P-Fjbdl6TOAA@mail.dawnrazor.net> <1341941579.19862.140661100288401.297EDFDF@webmail.messagingengine.com> <20120710124458.Horde.0rVgX4gBVY5P-GoahYZnMbA@mail.dawnrazor.net> Message-ID: <4FFC6FD6.1030805@gmail.com> On 10/07/2012 18:44, J wrote: > Thanks for clearing that up, I now see where you're coming from. And > I believe you're misunderstanding; please all me an attempt to > clarify: > > My request is related *strictly* to formatting, and goes absolutely > no further. So that if someone submits a slackbuild with the > requirement listed, for example, like this: > > Depends on: x, y, and z > > Then it gets corrected by the admin, who is already making > corrections, and would only need to change that line to: > > This requires x, y, and z. > > since that is currently the most popular format and so it makes sense > to adopt that as the format in question. > > And, as mentioned, I would be very happy to take up this part of the > work. > > So, again: my concern is strictly limited to formatting, and only for > actual hard and fast requirements, not optionals. This represents a > minor formatting change *at worst*. And that, I believe, requires no > change to the testing currently done by admins. > > Quoting Chess Griffin : > >> On Tue, Jul 10, 2012, at 11:31 AM, J wrote: >> >>> where you're dead wrong is the stuff about testing. what in the >>> world does all that have to do with anything? the testing process >>> wouldn't change one iota from where it currently stands. >>> >> >> Right now, it's up each maintainer to list the dependencies in the >> README. Yes, there is some vetting of this information by the >> admins but essentially the burden remains with the maintainer. >> However, if the admins were to adopt an official SBo policy on >> dependency handling and naming convention in the README file, then >> it seems to me each submission would therefore need to be checked >> and tested against this policy, both for completeness and accuracy. >> And that would fall on the admins. >> >> -- Chess Griffin _______________________________________________ >> 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/ > I have no objection to being asked to list the dependencies in the READMEs in my packages with a specific format. Since I tend to write them on a single line at the end of the packages, it's not the end of the world if I always use the same style. That being said, I've noticed that Eric Hameleers has a few slack-required files in his repository. I'm not sure if that's an indication that there's a move towards some automation there... Besides altering the README, I'm inclined to think that a new field in the .info is the most programatically sensible. It's readily parseable, will cause almost zero false positives (a line of prose in a README might be slightly more difficult to parse), and is little extra work for the maintainer. I suppose the difficulty is the retroactive application of these potential changes. There are currently 3296 build scripts in the repository. I'm not volunteering to go through all of those and manually update the format of the dependencies. On the whole, however, I think this would be a positive for building Slackware packages. As has already been mentioned, it changes relatively little for those who wish to ignore this information whilst making building packages less tiresome for those who choose to use it. Pierre From matteo.bernardini at gmail.com Tue Jul 10 17:54:54 2012 From: matteo.bernardini at gmail.com (Matteo Bernardini) Date: Tue, 10 Jul 2012 19:54:54 +0200 Subject: [Slackbuilds-users] requirements in README files In-Reply-To: <20120710124458.Horde.0rVgX4gBVY5P-GoahYZnMbA@mail.dawnrazor.net> References: <20120710113123.Horde.so73a4gBVY5P-Fjbdl6TOAA@mail.dawnrazor.net> <1341941579.19862.140661100288401.297EDFDF@webmail.messagingengine.com> <20120710124458.Horde.0rVgX4gBVY5P-GoahYZnMbA@mail.dawnrazor.net> Message-ID: 2012/7/10 J : > This requires x, y, and z. > > since that is currently the most popular format and so it makes sense to > adopt that as the format in question. a small thing that comes to mind: this form is easily parseable with perl, but it won't be that easy with other scripting languages, like bash. so, in the evenience, maybe another more parsing-friendly should be preferred (any choiche shouldn't be a problem for your perl scripts). Matteo From dragonwisard at gmail.com Tue Jul 10 18:48:48 2012 From: dragonwisard at gmail.com (Ben Mendis) Date: Tue, 10 Jul 2012 14:48:48 -0400 Subject: [Slackbuilds-users] requirements in README files In-Reply-To: References: <20120710113123.Horde.so73a4gBVY5P-Fjbdl6TOAA@mail.dawnrazor.net> <1341941579.19862.140661100288401.297EDFDF@webmail.messagingengine.com> <20120710124458.Horde.0rVgX4gBVY5P-GoahYZnMbA@mail.dawnrazor.net> Message-ID: I did it. ==== #!/bin/bash read LINE LINE=${LINE/This requires /} # Remove the leading 'This requires' LINE=${LINE/and /} # Remove the 'and ' LINE=${LINE%.} # Remove the trailing '.' while [ ${#LINE} != "0" ] # loop until the line is empty (fully-processed) do PKG=${LINE%%, *} # grab the text up to the first comma (if any) echo Dep: $PKG LINE=${LINE:${#PKG}} # subtract that string from the beginning of the line LINE=${LINE#, } # remove the leading ', ' if any done ==== On Tue, Jul 10, 2012 at 1:54 PM, Matteo Bernardini < matteo.bernardini at gmail.com> wrote: > 2012/7/10 J : > > This requires x, y, and z. > > > > since that is currently the most popular format and so it makes sense to > > adopt that as the format in question. > > a small thing that comes to mind: this form is easily parseable with > perl, but it won't be that easy with other scripting languages, like > bash. > so, in the evenience, maybe another more parsing-friendly should be > preferred (any choiche shouldn't be a problem for your perl scripts). > > 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/ > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cancellor2 at gmail.com Tue Jul 10 19:33:25 2012 From: cancellor2 at gmail.com (Fridrich von Stauffenberg) Date: Tue, 10 Jul 2012 22:33:25 +0300 Subject: [Slackbuilds-users] requirements in README files In-Reply-To: References: <20120710113123.Horde.so73a4gBVY5P-Fjbdl6TOAA@mail.dawnrazor.net> <1341941579.19862.140661100288401.297EDFDF@webmail.messagingengine.com> <20120710124458.Horde.0rVgX4gBVY5P-GoahYZnMbA@mail.dawnrazor.net> Message-ID: <4FFC8385.5010206@gmail.com> Or just sed 's/^This requires //;s/, /\n/g;s/ and /\n/g;s/.$//' :-) 10.07.2012 21:48, Ben Mendis ?????: > #!/bin/bash > > read LINE > > LINE=${LINE/This requires /} # Remove the leading 'This requires' > LINE=${LINE/and /} # Remove the 'and ' > LINE=${LINE%.} # Remove the trailing '.' > > while [ ${#LINE} != "0" ] # loop until the line is empty (fully-processed) > do > PKG=${LINE%%, *} # grab the text up to the first comma (if any) > echo Dep: $PKG > LINE=${LINE:${#PKG}} # subtract that string from the beginning of the line > LINE=${LINE#, } # remove the leading ', ' if any > done From janherrygers at dommel.be Tue Jul 10 21:02:35 2012 From: janherrygers at dommel.be (Jan Herrygers) Date: Tue, 10 Jul 2012 23:02:35 +0200 Subject: [Slackbuilds-users] requirements in README files In-Reply-To: <20120710124458.Horde.0rVgX4gBVY5P-GoahYZnMbA@mail.dawnrazor.net> References: <20120710113123.Horde.so73a4gBVY5P-Fjbdl6TOAA@mail.dawnrazor.net> <1341941579.19862.140661100288401.297EDFDF@webmail.messagingengine.com> <20120710124458.Horde.0rVgX4gBVY5P-GoahYZnMbA@mail.dawnrazor.net> Message-ID: <1478831.zMnUzH2qOU@qetesh> Op dinsdag 10 juli 2012 12:44:58 schreef J: > Thanks for clearing that up, I now see where you're coming from. And I > believe you're misunderstanding; please all me an attempt to clarify: You want to build a tool that simplifies building a dependency graph. You already stated that this "simplificating tool" shouldn't be and won't be a replacement for reading the READme. > My request is related *strictly* to formatting, and goes absolutely no > further. So that if someone submits a slackbuild [...] > it gets corrected by the admin, who is already making > corrections, and would only need to change that line [...] Let me quote Erik Hanson on this: Op dinsdag 10 juli 2012 12:21:39 schreef Erik Hanson: > This is not a fact. We may change them at our discretion if they are messy, > confusing, or wrong. There is no policy in place, written or otherwise, to > make them consistent. So maintainers don't edit READMEs, unless it is needen really badly. That is my interpretatiion of Erik's words, anyway. Let me think a little outside the box. Bear with me, or skip this section, whatever you like. You want to read every README (I'm not going to emphasise the fact that both words contain "read" again,... oops seems like I did anyway). You also want a tool that frees you of the duty to open a new browser tab every time a dependency/requirement/neat-plugin-that-you-may-want is mentioned. Perhaps a tool, some variation of less, more, vim, Emacs, cat,... , can be written in which you simply highlight the name of a dependency, and the text that you highlighted is added to a dependency list. When you are finished reading a readme, you move on to the readme for the next package on the dependency list. And so on ad infinitum (or until you have finished your list). That way you aren't dependent on any formatting being present, but you still get a nice dependency tree. (I have no idea how one would build such a program, but I'm optimistic about the feasability and feature set of the mythical deptree tool I described above.) Op dinsdag 10 juli 2012 12:44:58 schreef J: > So, again: my concern is strictly limited to formatting, and only for > actual hard and fast requirements, not optionals. This represents a > minor formatting change *at worst*. And that, I believe, requires no > change to the testing currently done by admins. Back in the box again. A recommendation on how to list dependencies in a readme would be nice. But asking the admins to either edit the recommended format into every readme, or to give you write access to the repo, is a lot to ask. I wouldn't count on a standard that gets enforced to the point that it can be parsed with awk, regexes, or something like that. But publishing a recommendation doesn't hurt, and it can be beneficial for the human reader too. I woul like a list delimited by newlines and/or tabs (perhaps multiple spaces?) That would IMHO be much more readable than separated by "," or "and" delimiters. Those who want to follow the recommendation, can do so, and those who don't want to, can keep doing what it is that they do want to do. From dragonwisard at gmail.com Tue Jul 10 21:20:20 2012 From: dragonwisard at gmail.com (Ben Mendis) Date: Tue, 10 Jul 2012 17:20:20 -0400 Subject: [Slackbuilds-users] requirements in README files In-Reply-To: <1478831.zMnUzH2qOU@qetesh> References: <20120710113123.Horde.so73a4gBVY5P-Fjbdl6TOAA@mail.dawnrazor.net> <1341941579.19862.140661100288401.297EDFDF@webmail.messagingengine.com> <20120710124458.Horde.0rVgX4gBVY5P-GoahYZnMbA@mail.dawnrazor.net> <1478831.zMnUzH2qOU@qetesh> Message-ID: On Tue, Jul 10, 2012 at 5:02 PM, Jan Herrygers wrote: > But publishing a recommendation doesn't hurt, and it can be beneficial for > the > human reader too. > I woul like a list delimited by newlines and/or tabs (perhaps multiple > spaces?) That would IMHO be much more readable than separated by "," or > "and" > delimiters. > Those who want to follow the recommendation, can do so, and those who don't > want to, can keep doing what it is that they do want to do. This. I can't speak for anyone else on this thread, but this is what I would like to see. This is exactly what I am supporting. A _recommendation_ for how to format the list of requirements which most maintainers are already documenting in their README files. And it would be completely opt-in. If a maintainer doesn't feel like doing it, it was only a recommendation anyways. If other people don't care about using dep-graph tools, it's still completely human-readable (and perhaps even a little easier for humans to read, too). The admins wouldn't have anything new to enforce, so their job doesn't get any harder. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jens at tuxane.com Tue Jul 10 22:31:22 2012 From: jens at tuxane.com (TuxaneMedia) Date: Wed, 11 Jul 2012 00:31:22 +0200 Subject: [Slackbuilds-users] requirements in README files In-Reply-To: References: <20120710113123.Horde.so73a4gBVY5P-Fjbdl6TOAA@mail.dawnrazor.net> <1341941579.19862.140661100288401.297EDFDF@webmail.messagingengine.com> <20120710124458.Horde.0rVgX4gBVY5P-GoahYZnMbA@mail.dawnrazor.net> <1478831.zMnUzH2qOU@qetesh> Message-ID: <4FFCAD3A.5040800@tuxane.com> Am 10.07.2012 23:20, schrieb Ben Mendis: > > I can't speak for anyone else on this thread, but this is what I would > like to see. This is exactly what I am supporting. > Me too, I did a quick incomplete and inacurate search on the README files in the 13.37 repo and it seems that a minimum of 800 are using the pattern "This requires" . Where a search on "depends" gives only 300 . Which made me think that it is "best practise" to use "the requires" ... From j at dawnrazor.net Wed Jul 11 04:01:58 2012 From: j at dawnrazor.net (J) Date: Tue, 10 Jul 2012 23:01:58 -0500 Subject: [Slackbuilds-users] requirements in README files In-Reply-To: <1478831.zMnUzH2qOU@qetesh> References: <20120710113123.Horde.so73a4gBVY5P-Fjbdl6TOAA@mail.dawnrazor.net> <1341941579.19862.140661100288401.297EDFDF@webmail.messagingengine.com> <20120710124458.Horde.0rVgX4gBVY5P-GoahYZnMbA@mail.dawnrazor.net> <1478831.zMnUzH2qOU@qetesh> Message-ID: <20120710230158.Horde.RFyuAYgBVY5P-Pq24MoHMbA@mail.dawnrazor.net> Quoting Jan Herrygers : > Op dinsdag 10 juli 2012 12:44:58 schreef J: >> Thanks for clearing that up, I now see where you're coming from. And I >> believe you're misunderstanding; please all me an attempt to clarify: > > You want to build a tool that simplifies building a dependency graph. You > already stated that this "simplificating tool" shouldn't be and won't be a > replacement for reading the READme. That's wrong and right - wrong about "want to", because I've already done, but there are so many variations to the formatting - even among those using the "This requires" format - that it's increasingly non-trivial to handle... and as other emails in this thread have indicated, I am not the only one who'd find this useful. right about the rest, because it will only attempt to parse requirements if the user has not chosen to skip viewing the README file. otherwise, it will care about requirements exactly as the slackbuild itself would have if the user were interacting with it completely manually - ie not at all. > Let me think a little outside the box. Bear with me, or skip this section, > whatever you like. I have read virtually ever word in this thread :) > Perhaps a tool, some variation of less, more, vim, Emacs, cat,... , can be > written in which you simply highlight the name of a dependency, and the text > that you highlighted is added to a dependency list. > When you are finished reading a readme, you move on to the readme > for the next > package on the dependency list. And so on ad infinitum (or until you have > finished your list). > > That way you aren't dependent on any formatting being present, but you still > get a nice dependency tree. (I have no idea how one would build such a > program, but I'm optimistic about the feasability and feature set of the > mythical deptree tool I described above.) This is a neat idea - but it still requires a parser. And once the parsing is done, then it's a matter of actually running the slackbuilds, so we're back to the doing the same exact manual steps over and over and over again - and that's stupid, in my opinion. personally, where I find myself doing the same manual steps over and over, I automate. so, we have the parser, and we have the repeated steps. ergo, my tool. it makes sense to me, anyway. > Op dinsdag 10 juli 2012 12:44:58 schreef J: >> So, again: my concern is strictly limited to formatting, and only for >> actual hard and fast requirements, not optionals. This represents a >> minor formatting change *at worst*. And that, I believe, requires no >> change to the testing currently done by admins. > > Back in the box again. > A recommendation on how to list dependencies in a readme would be nice. But > asking the admins to either edit the recommended format into every readme, or > to give you write access to the repo, is a lot to ask. I wouldn't count on a > standard that gets enforced to the point that it can be parsed with awk, > regexes, or something like that. > > But publishing a recommendation doesn't hurt, and it can be > beneficial for the > human reader too. > I woul like a list delimited by newlines and/or tabs (perhaps multiple > spaces?) That would IMHO be much more readable than separated by "," or "and" > delimiters. > Those who want to follow the recommendation, can do so, and those who don't > want to, can keep doing what it is that they do want to do. not ideal of course, but this would be a start. couple things, then, given this (not arguments, but discussion to possibly move it forward): 1. how does such a recommendation get communicated to slackbuild maintainers? admins out there, would you be willing to publish such a recommendation on slackbuilds.org? after all, if it weren't stated there, it wouldn't exactly be worth much. 2. formatting - newline/tab/multiple-space delimited, any of these is easily parseable, so I would be happy with any of these options or anything else that is easily parsed. but I do think it makes sense to stick with the currently most popular format - otherwise we end up with even more different types of formatting than we already have. off to work for me. thanks. J From c.willing at uq.edu.au Wed Jul 11 05:56:42 2012 From: c.willing at uq.edu.au (Christoph Willing) Date: Wed, 11 Jul 2012 15:56:42 +1000 Subject: [Slackbuilds-users] requirements in README files In-Reply-To: <20120710230158.Horde.RFyuAYgBVY5P-Pq24MoHMbA@mail.dawnrazor.net> References: <20120710113123.Horde.so73a4gBVY5P-Fjbdl6TOAA@mail.dawnrazor.net> <1341941579.19862.140661100288401.297EDFDF@webmail.messagingengine.com> <20120710124458.Horde.0rVgX4gBVY5P-GoahYZnMbA@mail.dawnrazor.net> <1478831.zMnUzH2qOU@qetesh> <20120710230158.Horde.RFyuAYgBVY5P-Pq24MoHMbA@mail.dawnrazor.net> Message-ID: On 11/07/2012, at 2:01 PM, J wrote: [snip] > 1. how does such a recommendation get communicated to slackbuild > maintainers? admins out there, would you be willing to publish such > a recommendation on slackbuilds.org? after all, if it weren't stated > there, it wouldn't exactly be worth much. > 2. formatting - newline/tab/multiple-space delimited, any of these > is easily parseable, so I would be happy with any of these options > or anything else that is easily parsed. but I do think it makes > sense to stick with the currently most popular format - otherwise we > end up with even more different types of formatting than we already > have. Hey J, in your first email which started this thread you said: > An ideal solution would be add this info in a file somewhere, for > example into the .info file. But they would still need to be in the > README, cause that just makes good sense. So it makes some sort of > sense to just have them in the README. As you know by now, I fully support the general thrust of your proposal. However I don't really follow the logic of how the ideal place for this information goes from being the .info file to the README file (especially exclusively, as seems to be suggested). I think the ideal place is the .info file - exactly where you started out. So now to the formatting. Apart from satisfying my own idea of "good sense", another reason that the .info file is the ideal location for this info is that its already formatted in a manner that makes parsing just about a non event. The .info file is currently just a bunch of shell declarations so that after adding a new field something like: PREREQS="foo bar alpha beta" it means that any shell script (the Slackware way?) can just source the .info file and instantly have the build requirements contained in a shell variable. You can trivially do things like: . myApp.info for package in $PREREQS ; do check_something_about $package ;# is it installed, for instance? # do anything else relevant to $package done Even if PREREQS doesn't exist (since it may not a compulsory field), the above loop still behaves nicely. Its such a no brainer - trivial to implement, _all_ of "newline/tab/ multiple-space delimited" are OK, transparent to current build scripts, _nothing_ to do with run time dependencies ... Can I also add that others' comments about this proposal creating additional workload for SBo admins just don't stack up. If the admins already test each build script, including compilation and package generation, then surely a comprehensive list of packages needed for successful compilation makes their job easier - not harder. If some package is needed but not installed already or mentioned somewhere so that it can be, then the first compilation test will fail; now add whatever time it takes to resolve that which is wrong. Surely its better - faster - to have some clear mechanism for specifying the build requirements. Its surely not the admins role to spend time figuring all that out, of course; its the package maintainers. The admin just sees the list of prerequisites and ensures they're installed (very easy to script :), then runs the .SlackBuild. A well described list of build prerequisites will assist success, however on "fail", return to maintainer. The clearer the build requirements, the easier the admins work. Did I mention that none of this has anything to do with run time dependencies? We're talking about listing stuff that has to be installed before you can compile something using an SBo. One way or another, you have to know what that stuff is - we just want an "approved", easily machine readable way to list that stuff that you have to know anyway. chris Christoph Willing +61 7 3365 8316 Research Computing Centre University of Queensland From j at dawnrazor.net Wed Jul 11 07:18:38 2012 From: j at dawnrazor.net (J) Date: Wed, 11 Jul 2012 02:18:38 -0500 Subject: [Slackbuilds-users] requirements in README files In-Reply-To: References: <20120710113123.Horde.so73a4gBVY5P-Fjbdl6TOAA@mail.dawnrazor.net> <1341941579.19862.140661100288401.297EDFDF@webmail.messagingengine.com> <20120710124458.Horde.0rVgX4gBVY5P-GoahYZnMbA@mail.dawnrazor.net> <1478831.zMnUzH2qOU@qetesh> <20120710230158.Horde.RFyuAYgBVY5P-Pq24MoHMbA@mail.dawnrazor.net> Message-ID: <20120711021838.Horde.SDF3QYgBVY5P-SjOGP5DN9A@mail.dawnrazor.net> Quoting Christoph Willing : > On 11/07/2012, at 2:01 PM, J wrote: > [snip] >> 1. how does such a recommendation get communicated to slackbuild >> maintainers? admins out there, would you be willing to publish such >> a recommendation on slackbuilds.org? after all, if it weren't >> stated there, it wouldn't exactly be worth much. >> 2. formatting - newline/tab/multiple-space delimited, any of these >> is easily parseable, so I would be happy with any of these options >> or anything else that is easily parsed. but I do think it makes >> sense to stick with the currently most popular format - otherwise >> we end up with even more different types of formatting than we >> already have. > > Hey J, in your first email which started this thread you said: > >> An ideal solution would be add this info in a file somewhere, for >> example into the .info file. But they would still need to be in the >> README, cause that just makes good sense. So it makes some sort of >> sense to just have them in the README. > > As you know by now, I fully support the general thrust of your > proposal. However I don't really follow the logic of how the ideal > place for this information goes from being the .info file to the > README file (especially exclusively, as seems to be suggested). I > think the ideal place is the .info file - exactly where you started > out. Well, speaking strictly programmatically, something like this in the .info file is absolutely ideal: PREREQS="thinga thingb thingc" That is super easy to handle; bash can source it, and I can very trivially pull that info with perl. absolutely desirable. But with the system we already have, where we're already defining the info somewhere else, it seems saner to me to just deal with it where it already is. I am not at all against the .info idea, or the slack-required idea for that matter, it just isn't my focus. J From j at dawnrazor.net Wed Jul 11 07:30:39 2012 From: j at dawnrazor.net (J) Date: Wed, 11 Jul 2012 02:30:39 -0500 Subject: [Slackbuilds-users] requirements in README files In-Reply-To: <20120710230158.Horde.RFyuAYgBVY5P-Pq24MoHMbA@mail.dawnrazor.net> References: <20120710113123.Horde.so73a4gBVY5P-Fjbdl6TOAA@mail.dawnrazor.net> <1341941579.19862.140661100288401.297EDFDF@webmail.messagingengine.com> <20120710124458.Horde.0rVgX4gBVY5P-GoahYZnMbA@mail.dawnrazor.net> <1478831.zMnUzH2qOU@qetesh> <20120710230158.Horde.RFyuAYgBVY5P-Pq24MoHMbA@mail.dawnrazor.net> Message-ID: <20120711023039.Horde.eUApOYgBVY5P-SufzcQBDJY@mail.dawnrazor.net> Another thing which has been mentioned a few times, and which I have considered off and on myself, is a fork of the repo. There are several reasons I have not pursued this idea; it constitutes an amount of work which would keep me busy doing that for an unrealistic amount of time, or it requires a parser able to grok our random requirement listings, and I'm back to square one. I don't like the inelegant, brute-force nature of it, either. All that said, I do think it would be realistically possible, feasible, and perhaps even a bit sane, with more than one person working on it. And once the main body of work is completed, then it's on to 14.0, and once that is completely, significantly less work would be required moving forward. until $VERSION++, but that can be dealt with when it's reached. So, all that said. There are a number of replies from people who would like to see this happen. If there is anyone who would be interested in forking the repo, then building a system to achieve this, please send an email to me personally. In the end, all the work involved might be easier. J Quoting J : > Quoting Jan Herrygers : > >> Op dinsdag 10 juli 2012 12:44:58 schreef J: >>> Thanks for clearing that up, I now see where you're coming from. And I >>> believe you're misunderstanding; please all me an attempt to clarify: >> >> You want to build a tool that simplifies building a dependency graph. You >> already stated that this "simplificating tool" shouldn't be and won't be a >> replacement for reading the READme. > > That's wrong and right - wrong about "want to", because I've already > done, but there are so many variations to the formatting - even > among those using the "This requires" format - that it's > increasingly non-trivial to handle... and as other emails in this > thread have indicated, I am not the only one who'd find this useful. > right about the rest, because it will only attempt to parse > requirements if the user has not chosen to skip viewing the README > file. otherwise, it will care about requirements exactly as the > slackbuild itself would have if the user were interacting with it > completely manually - ie not at all. > >> Let me think a little outside the box. Bear with me, or skip this section, >> whatever you like. > > I have read virtually ever word in this thread :) > >> Perhaps a tool, some variation of less, more, vim, Emacs, cat,... , can be >> written in which you simply highlight the name of a dependency, and the text >> that you highlighted is added to a dependency list. >> When you are finished reading a readme, you move on to the readme >> for the next >> package on the dependency list. And so on ad infinitum (or until you have >> finished your list). >> >> That way you aren't dependent on any formatting being present, but you still >> get a nice dependency tree. (I have no idea how one would build such a >> program, but I'm optimistic about the feasability and feature set of the >> mythical deptree tool I described above.) > > This is a neat idea - but it still requires a parser. And once the > parsing is done, then it's a matter of actually running the > slackbuilds, so we're back to the doing the same exact manual steps > over and over and over again - and that's stupid, in my opinion. > personally, where I find myself doing the same manual steps over and > over, I automate. so, we have the parser, and we have the repeated > steps. ergo, my tool. it makes sense to me, anyway. > >> Op dinsdag 10 juli 2012 12:44:58 schreef J: >>> So, again: my concern is strictly limited to formatting, and only for >>> actual hard and fast requirements, not optionals. This represents a >>> minor formatting change *at worst*. And that, I believe, requires no >>> change to the testing currently done by admins. >> >> Back in the box again. >> A recommendation on how to list dependencies in a readme would be nice. But >> asking the admins to either edit the recommended format into every >> readme, or >> to give you write access to the repo, is a lot to ask. I wouldn't count on a >> standard that gets enforced to the point that it can be parsed with awk, >> regexes, or something like that. >> >> But publishing a recommendation doesn't hurt, and it can be >> beneficial for the >> human reader too. >> I woul like a list delimited by newlines and/or tabs (perhaps multiple >> spaces?) That would IMHO be much more readable than separated by >> "," or "and" >> delimiters. >> Those who want to follow the recommendation, can do so, and those who don't >> want to, can keep doing what it is that they do want to do. > > not ideal of course, but this would be a start. couple things, then, > given this (not arguments, but discussion to possibly move it > forward): > 1. how does such a recommendation get communicated to slackbuild > maintainers? admins out there, would you be willing to publish such > a recommendation on slackbuilds.org? after all, if it weren't stated > there, it wouldn't exactly be worth much. > 2. formatting - newline/tab/multiple-space delimited, any of these > is easily parseable, so I would be happy with any of these options > or anything else that is easily parsed. but I do think it makes > sense to stick with the currently most popular format - otherwise we > end up with even more different types of formatting than we already > have. > > off to work for me. > thanks. > J > > _______________________________________________ > 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 mr.chew.baka at gmail.com Wed Jul 11 16:41:30 2012 From: mr.chew.baka at gmail.com (=?utf-8?B?bXIuY2hldy5iYWthQGdtYWlsLmNvbQ==?=) Date: Wed, 11 Jul 2012 11:41:30 -0500 Subject: [Slackbuilds-users] =?utf-8?q?requirements_in_README_files?= Message-ID: <4ffdacbf.884aec0a.595f.ffff9d22@mx.google.com> I say leave it as is. Although I like the idea of dependency checks it scares me if there is an either or when you have neither installed. Sent via my mobile handheld communications device ----- Reply message ----- From: "Ben Mendis" To: "SlackBuilds.org Users List" Subject: [Slackbuilds-users] requirements in README files Date: Mon, Jul 9, 2012 20:45 On Mon, Jul 9, 2012 at 9:00 PM, David Spencer < baildon.research at googlemail.com> wrote: > > Yeah, long chains of indirect dependencies are a pain. They'd be even > more of a pain if our flexible source-based locally-managed dependency > resolution was more rigid. There's nothing better than noticing that > a tricky dependency turns out to be optional, contrary to expectations > :-) > > Right! In no way am I asking for more rigidity or even for an automated solution. What I would find nice, however, is a standard syntax for indicating the names of direct dependencies (whether mandatory or optional) so that I can write tools to resolve a rough outline of a dependency graph and at least get some idea of which packages I *might* need or want and approximately what order they should be installed in. Even something as noncommittal as that is currently a challenge to automate and requires a lot of manual foot work. Isn't the point of computing to automate the mundane tasks so that we can focus our minds and efforts on the truly interesting problems? Why are people on this list so vehemently opposed to the idea of OPTIONAL metadata? It wouldn't have any impact on your current way of doing things, but it might be of value to people who aren't quite as masochistic. I love Slackware, and I love the way Slackware's package management works. That said, I'm not blind to the fact that it has trade-offs and shortcomings. Proposals like this are a very non-intrusive way to experiment with potential improvements without forcing work on anyone or taking away any functionality or flexibility. You can love and respect something, but still want to improve it. Package and dependency management are clearly not "solved" problems, and while Slackware is better than most, it's not perfect. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kristofru at gmail.com Wed Jul 11 18:10:51 2012 From: kristofru at gmail.com (Chris Abela) Date: Wed, 11 Jul 2012 20:10:51 +0200 Subject: [Slackbuilds-users] recode.SlackBuild Message-ID: <4FFDC1AB.4080706@gmail.com> I was informed that the recode source link is dead. The source code is however available from a git repositoryhttps://github.com/pinard/recode As I am not using recode anymore, I am offering the maintenance of the SlackBuild to anyone willing to take up the job. Also, any offers to host the source code would be appreciated as I do not own a server. For the time being the source code may be downloaded from my dropbox account: https://dl.dropbox.com/u/49744080/recode-3.6.tar.gz Chris Abela From kristofru at gmail.com Wed Jul 11 18:17:36 2012 From: kristofru at gmail.com (Chris Abela) Date: Wed, 11 Jul 2012 20:17:36 +0200 Subject: [Slackbuilds-users] requirements in README files In-Reply-To: References: Message-ID: <4FFDC340.8070007@gmail.com> Normally I avoid charged and lengthy discussions but as the opinion of other maintainers was solicited in this correspondence, I thought I'd let you know my modest opinion as briefly as possible: Facilitating dependency queuing for possible optional parsing tools is a logical evolution of the current set-up. The feasibility of such a proposal is a complicated issue that the administrators may wish to evaluate. This is their repository and it is up to them to decide. Nevertheless this argument is symptomatic of an active community that is willing to contribute. Chris From burningc at SDF.ORG Wed Jul 11 18:17:55 2012 From: burningc at SDF.ORG (Glenn Becker) Date: Wed, 11 Jul 2012 18:17:55 +0000 (UTC) Subject: [Slackbuilds-users] haskell-platform SlackBuild In-Reply-To: References: Message-ID: Hi all - > I emailed the maintainer for the 13.1 SlackBuild of haskell-platform to > ask whether he had any plans to update it for 13.37. He told me that he > did not, and transferred SlackBuild maintenance responsibility to me. > > I don't yet have an accurate idea of how much work this might require, > but I thought I'd send an email to the list nonetheless. If I find it > beyond my admittedly meager capabilities I will follow up. OK, here's my follow up, and I apologize for the delay. Embarrassed as I am to admit it, I don't think there is any way I can get to this in a reasonable period of time. If anyone is interested in taking it on, it is up for grabs. Regretfully, Glenn +---------------------------------------------+ Glenn Becker - burningc at sdf.org SDF Public Access UNIX System - http://sdf.org +---------------------------------------------+ From klaatu at straightedgelinux.com Wed Jul 11 19:38:30 2012 From: klaatu at straightedgelinux.com (Klaatu) Date: Wed, 11 Jul 2012 15:38:30 -0400 Subject: [Slackbuilds-users] recode.SlackBuild In-Reply-To: <4FFDC1AB.4080706@gmail.com> References: <4FFDC1AB.4080706@gmail.com> Message-ID: <201207111538.30899.klaatu@straightedgelinux.com> > I was informed that the recode source link is dead. The source code is > however available from a git repositoryhttps://github.com/pinard/recode As > I am not using recode anymore, I am offering the maintenance of the > SlackBuild to anyone willing to take up the job. > > Also, any offers to host the source code would be appreciated as I do not > own a server. For the time being the source code may be downloaded from my > dropbox account: https://dl.dropbox.com/u/49744080/recode-3.6.tar.gz > > Chris Abela > > _______________________________________________ > 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/ Hosted at http://slackermedia.info/slackbuilds/recode-3.6.tar.gz - klaatu From joshuakwood at gmail.com Wed Jul 11 19:56:21 2012 From: joshuakwood at gmail.com (JK Wood) Date: Wed, 11 Jul 2012 14:56:21 -0500 Subject: [Slackbuilds-users] recode.SlackBuild In-Reply-To: <4FFDC1AB.4080706@gmail.com> References: <4FFDC1AB.4080706@gmail.com> Message-ID: On Jul 11, 2012 1:11 PM, "Chris Abela" wrote: > > I was informed that the recode source link is dead. The source code is however available from a git repositoryhttps://github.com/pinard/recode > As I am not using recode anymore, I am offering the maintenance of the SlackBuild to anyone willing to take up the job. > > Also, any offers to host the source code would be appreciated as I do not own a server. For the time being the source code may be downloaded from my dropbox account: > https://dl.dropbox.com/u/49744080/recode-3.6.tar.gz > > Chris Abela > > GitHub has a free download service for all projects. They really should be using that. _______________________________________________ > 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 c.willing at uq.edu.au Thu Jul 12 05:39:59 2012 From: c.willing at uq.edu.au (Christoph Willing) Date: Thu, 12 Jul 2012 15:39:59 +1000 Subject: [Slackbuilds-users] haskell-platform SlackBuild In-Reply-To: References: Message-ID: On 12/07/2012, at 4:17 AM, Glenn Becker wrote: > > Hi all - > >> I emailed the maintainer for the 13.1 SlackBuild of haskell- >> platform to ask whether he had any plans to update it for 13.37. He >> told me that he did not, and transferred SlackBuild maintenance >> responsibility to me. >> >> I don't yet have an accurate idea of how much work this might >> require, but I thought I'd send an email to the list nonetheless. >> If I find it beyond my admittedly meager capabilities I will follow >> up. > > OK, here's my follow up, and I apologize for the delay. > > Embarrassed as I am to admit it, I don't think there is any way I > can get to this in a reasonable period of time. If anyone is > interested in taking it on, it is up for grabs. I'll grab it if no one else has a strong yearning for it. I've just made 32 & 64bit builds from the latest source code - they seem to work OK. I could submit an updated SBo script later tonight. chris Christoph Willing +61 7 3365 8316 Research Computing Centre University of Queensland From c.willing at uq.edu.au Thu Jul 12 13:39:45 2012 From: c.willing at uq.edu.au (Christoph Willing) Date: Thu, 12 Jul 2012 23:39:45 +1000 Subject: [Slackbuilds-users] forking SBo In-Reply-To: <20120711023039.Horde.eUApOYgBVY5P-SufzcQBDJY@mail.dawnrazor.net> References: <20120710113123.Horde.so73a4gBVY5P-Fjbdl6TOAA@mail.dawnrazor.net> <1341941579.19862.140661100288401.297EDFDF@webmail.messagingengine.com> <20120710124458.Horde.0rVgX4gBVY5P-GoahYZnMbA@mail.dawnrazor.net> <1478831.zMnUzH2qOU@qetesh> <20120710230158.Horde.RFyuAYgBVY5P-Pq24MoHMbA@mail.dawnrazor.net> <20120711023039.Horde.eUApOYgBVY5P-SufzcQBDJY@mail.dawnrazor.net> Message-ID: <87E1F9BB-A66D-462A-954E-EF65F8E5C344@uq.edu.au> On 11/07/2012, at 5:30 PM, J wrote: > Another thing which has been mentioned a few times, and which I have > considered off and on myself, is a fork of the repo. There are > several reasons I have not pursued this idea; it constitutes an > amount of work which would keep me busy doing that for an > unrealistic amount of time, or it requires a parser able to grok our > random requirement listings, and I'm back to square one. I don't > like the inelegant, brute-force nature of it, either. All that said, > I do think it would be realistically possible, feasible, and perhaps > even a bit sane, with more than one person working on it. And once > the main body of work is completed, then it's on to 14.0, and once > that is completely, significantly less work would be required moving > forward. until $VERSION++, but that can be dealt with when it's > reached. > > So, all that said. There are a number of replies from people who > would like to see this happen. If there is anyone who would be > interested in forking the repo, then building a system to achieve > this, please send an email to me personally. In the end, all the > work involved might be easier. Hi J, Without wanting to make a real commitment right now, I would be quite interested in being involved. I already have a collection of SBo's for which I've added PREREQS field to the .info file. If that approach is acceptable, they could used more or less straight away. Building a web interface to the whole thing will be time consuming though ... What I'd like to try first is to submit one or two new SBo scripts with PREREQS added in and see what the reaction is. I've made a tentative claim on the haskall-platform package which was offered earlier today. It needs updating and, if no one else wants it, I'll submit a new SBo that includes a PREREQS line. If the admins accept it, then that would be a sign in favour of not forking. I guess its another thing to convince all the maintainers they should add PREREQS (or whatever mechanism is finally used) to their SBo's too. chris Christoph Willing +61 7 3365 8316 Research Computing Centre University of Queensland From erik at slackbuilds.org Thu Jul 12 14:30:50 2012 From: erik at slackbuilds.org (Erik Hanson) Date: Thu, 12 Jul 2012 09:30:50 -0500 Subject: [Slackbuilds-users] forking SBo In-Reply-To: <87E1F9BB-A66D-462A-954E-EF65F8E5C344@uq.edu.au> References: <20120710113123.Horde.so73a4gBVY5P-Fjbdl6TOAA@mail.dawnrazor.net> <1341941579.19862.140661100288401.297EDFDF@webmail.messagingengine.com> <20120710124458.Horde.0rVgX4gBVY5P-GoahYZnMbA@mail.dawnrazor.net> <1478831.zMnUzH2qOU@qetesh> <20120710230158.Horde.RFyuAYgBVY5P-Pq24MoHMbA@mail.dawnrazor.net> <20120711023039.Horde.eUApOYgBVY5P-SufzcQBDJY@mail.dawnrazor.net> <87E1F9BB-A66D-462A-954E-EF65F8E5C344@uq.edu.au> Message-ID: <20120712093050.01c7a503@shaggy.doo> On Thu, 12 Jul 2012 23:39:45 +1000 Christoph Willing wrote: > What I'd like to try first is to submit one or two new SBo scripts > with PREREQS added in and see what the reaction is. Please wait, we're not oblivious to this discussion. We have our own going on internally. We're mostly settled on doing something but it's not going to happen overnight. Give us time to hammer out the details. Whatever happens, it will coincide with the next release of Slackware. -- Erik Hanson From j at dawnrazor.net Thu Jul 12 15:57:29 2012 From: j at dawnrazor.net (J) Date: Thu, 12 Jul 2012 10:57:29 -0500 Subject: [Slackbuilds-users] forking SBo In-Reply-To: <20120712093050.01c7a503@shaggy.doo> References: <20120710113123.Horde.so73a4gBVY5P-Fjbdl6TOAA@mail.dawnrazor.net> <1341941579.19862.140661100288401.297EDFDF@webmail.messagingengine.com> <20120710124458.Horde.0rVgX4gBVY5P-GoahYZnMbA@mail.dawnrazor.net> <1478831.zMnUzH2qOU@qetesh> <20120710230158.Horde.RFyuAYgBVY5P-Pq24MoHMbA@mail.dawnrazor.net> <20120711023039.Horde.eUApOYgBVY5P-SufzcQBDJY@mail.dawnrazor.net> <87E1F9BB-A66D-462A-954E-EF65F8E5C344@uq.edu.au> <20120712093050.01c7a503@shaggy.doo> Message-ID: <20120712105729.Horde.WIDBbIgBVY5P-vPpKegxDJY@mail.dawnrazor.net> Thanks for giving us a status update, Erik. Quoting Erik Hanson : > On Thu, 12 Jul 2012 23:39:45 +1000 > Christoph Willing wrote: > >> What I'd like to try first is to submit one or two new SBo scripts >> with PREREQS added in and see what the reaction is. > > Please wait, we're not oblivious to this discussion. We have our own going > on internally. We're mostly settled on doing something but it's not going > to happen overnight. Give us time to hammer out the details. Whatever > happens, it will coincide with the next release of Slackware. > > > -- > Erik Hanson > _______________________________________________ > 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 kingbeowulf at gmail.com Thu Jul 12 19:57:34 2012 From: kingbeowulf at gmail.com (King Beowulf) Date: Thu, 12 Jul 2012 12:57:34 -0700 Subject: [Slackbuilds-users] forking SBo In-Reply-To: <20120712105729.Horde.WIDBbIgBVY5P-vPpKegxDJY@mail.dawnrazor.net> References: <20120710113123.Horde.so73a4gBVY5P-Fjbdl6TOAA@mail.dawnrazor.net> <1341941579.19862.140661100288401.297EDFDF@webmail.messagingengine.com> <20120710124458.Horde.0rVgX4gBVY5P-GoahYZnMbA@mail.dawnrazor.net> <1478831.zMnUzH2qOU@qetesh> <20120710230158.Horde.RFyuAYgBVY5P-Pq24MoHMbA@mail.dawnrazor.net> <20120711023039.Horde.eUApOYgBVY5P-SufzcQBDJY@mail.dawnrazor.net> <87E1F9BB-A66D-462A-954E-EF65F8E5C344@uq.edu.au> <20120712093050.01c7a503@shaggy.doo> <20120712105729.Horde.WIDBbIgBVY5P-vPpKegxDJY@mail.dawnrazor.net> Message-ID: I would rather not see a fork at all but see what the admins come up with and work within that framework. One of the drawbacks of F/OSS is fragmentation and forks from every tom, dick and harry and various fanboys having some fit because the admins don't work fast enough, some pansy-ass disagreement or whatever. A fork can be a good idea (e.g. Libreoffice) but in SBo's case - no. Of course, we are all free to start our own repo, however, in terms of SBo I'd like to see more consolidation, not more fragmentation. Should a fork occur, I will adjust the licenses of my scripts to be SBo specific. -Ed On 7/12/12, J wrote: > Thanks for giving us a status update, Erik. > > Quoting Erik Hanson : > >> On Thu, 12 Jul 2012 23:39:45 +1000 >> Christoph Willing wrote: >> >>> What I'd like to try first is to submit one or two new SBo scripts >>> with PREREQS added in and see what the reaction is. >> >> Please wait, we're not oblivious to this discussion. We have our own >> going >> on internally. We're mostly settled on doing something but it's not going >> to happen overnight. Give us time to hammer out the details. Whatever >> happens, it will coincide with the next release of Slackware. >> >> >> -- >> Erik Hanson >> _______________________________________________ >> 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/ > > -- Sent from my mobile device You! What PLANET is this! -- McCoy, "The City on the Edge of Forever", stardate 3134.0 From Bradley at NorthTech.US Thu Jul 12 22:42:11 2012 From: Bradley at NorthTech.US (Bradley D. Thornton) Date: Thu, 12 Jul 2012 15:42:11 -0700 Subject: [Slackbuilds-users] Was forking SBo (Hijacked) - Now: Why bother forking? In-Reply-To: <87E1F9BB-A66D-462A-954E-EF65F8E5C344@uq.edu.au> References: <20120710113123.Horde.so73a4gBVY5P-Fjbdl6TOAA@mail.dawnrazor.net> <1341941579.19862.140661100288401.297EDFDF@webmail.messagingengine.com> <20120710124458.Horde.0rVgX4gBVY5P-GoahYZnMbA@mail.dawnrazor.net> <1478831.zMnUzH2qOU@qetesh> <20120710230158.Horde.RFyuAYgBVY5P-Pq24MoHMbA@mail.dawnrazor.net> <20120711023039.Horde.eUApOYgBVY5P-SufzcQBDJY@mail.dawnrazor.net> <87E1F9BB-A66D-462A-954E-EF65F8E5C344@uq.edu.au> Message-ID: <4FFF52C3.6080902@NorthTech.US> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 On 07/12/2012 06:39 AM, Christoph Willing wrote: > > On 11/07/2012, at 5:30 PM, J wrote: > >> Another thing which has been mentioned a few times, and which I have >> considered off and on myself, is a fork of the repo. There are several I thought I had missed something here. But really, after realizing that I had previously read the quote above, so there was no topic openener (w/o the "Re:"). The thread was hijacked. Please, when you do something like this, Put a "WAS" or something in the subject line to show some continuity so people aren't looking for the original post that doesn't exist. There was another post in this very long and interesting thread that mentioned three things: 1.) The situation where there is an XOR in the deps. The example used was wxPython and wxGTK. 2.) The situation where the dep for a package must be >=, <=, or between some version values. 3.) The situation where the scheme for versioning suddenly changes. Personally, I think that talk of mucking about with the .info is actually the best way to handle dependency checking. Perhaps it would be easier to use an entirely new construct in the form of a .dep file - one dependency per line, and when the dependencies are an XOR requirement, then placing both on the same line. For example: # dvdstyler.dep dvdauthor ffmpeg libavc1394 libmspack libquicktime mjpegtools mpgtx wxPython wxGTK wxsvg Of course, in the example above, I didn't bother to check the order in which these deps must be installed, or address the fact that build options may need to be passed to any particular SBo. A layer specifying such build options could easily be implemented in such a .dep file. Maybe it would look like this? # dvdstyler.dep 'dvdauthor' 'ffmpeg FAAC=yes FREI0R=yes LAME=yes X264=yes XVID=yes' 'libavc1394' 'libmspack' 'libquicktime' 'mjpegtools' 'mpgtx' 'wxPython' 'wxGTK' 'wxsvg' And of course we've introduced five additional dependencies at this point into the quagmire. Not addressed is what do do when the version must be greater than and less than some value. Also, in sbopkg we have the "-k" switch, which in the case of using queuefiles would skip borking the ffmpeg that most of us chose to use from Eric's offshore package repo. And that kind of brings us full circle doesn't it? I mean, if you want dependency checking and resolution, isn't the following a much simpler model to use? # cd /var/lib/sbopkg # git clone git://gitorious.org/sbopkg-slackware-queues/sbopkg-slackware-queues.git queues # sbopkg -i dvdstyler.sqf -k And so far the discussion of automatic dependency resolution doesn't even begin to address issues like OpenCascade, which needs ~2.6GB of /tmp space and build options like "INSTALL_FULL_DOCS=yes ./OpenCASCADE.SlackBuild", or optional dependencies such as FreeImage, libtbb and gl2ps (From http://slackbuilds.org/repository/13.37/graphics/OpenCASCADE/ ) - which is one of the main strengths of NOT having dependency checking in Slackware in the first place! No offense, but what does Salix do for situations like this? Make the decisions for you? I think that's why they make distros especially for stupid people, like the distro for stupid people - ewboontew. Even Fedora and Debian make all of these choices for you, and in the case of things like ffmpeg, one has to learn enough about how to use alternative (I hate that word) repos, which just brings us back to why Slackware is so strong in this area. sbopkg is a wonderful tool, itself capable of dependency resolution by incorporating the example I gave above, but in doing so, we're making the conscious decision to let someone else make those decisions for us which may yield the expected outcome if you don't first do your homework at SBo.org. i.e., "sbopkg -i dvdstyler.sqf" or "sbopkg -i OpenCASCADE.sqf", for a couple of real world examples. I remember years ago when I was sailing (not motoring, which means I pretty much had the right of way regardless) into Newport. Some fricken Cap'n Crunch in one of those Grand Banks motoryachts was makin' a beeline for me and didn't yield. I honked at him with the airhorn and tacked to avoid the collision, seeing that the asshat wasn't going to alter his heading. Considering the amount of traffic in and out of that harbor it was more than a little scary, seeing that big motoryacht bearing down on us in such an arrogant and condescending manner (Not to mention illegal). As that vessel passed on its way out to the ocean, we starting yelling and cussing until it was obvious that no one was at the wheel. This was back in the beginning of the GPS days, and there were indeed idiots that went so far as to plug in several waypoints to navigate their way in and out of anchorages - as insane as that is. Well, when that boat got about a hundred yards astern of us we saw Cap'n Crunch emerge from the salon to the deck w/a fresh cocktail in one hand, and what looked to be a plate of fingerfood in the other, all decked out with his little skipper hat and his yacht club jacket. I was so livid I didn't bother to get the name off the stern of that boat, but looking back, I'm sure it read: "EwBoonTew Newport Beach, CA". Maritime law dictates that you will ALWAYS have a man on watch when underway. But so does common sense. Hey, it would be wonderful if I could just type something like "slackstall get vlc wireshark geany handbrake --askops" and be able to choose from a dialog of every possible option for every possible dep and their respective options - but cloning SBo is not going to come anywhere near to that. I actually believe in the layers of separation that afford innovation and encourage the research and development of greater levels of sophistication, built upon the accomplishments of others who maintain systems already sufficiently vetted by the Slackware community. slackpkg is one such tool that was entered into the mainline distro, while sbopkg is built upon the stability of SBo. It would become increasingly difficult to continually heap more and greater responsibilities upon the volunteer SBo package maintainers, and the only real complaints to the model have been in the form of naysayers of Slackware (It's not official), or people who want dependency resolution. There have been, and in fact are still, tools and distros that already address this in some fashion or another. Slapt-get, SalixOS, and others, but in following in series after package management solutions that are already considered by most to be stable, reliable, and accepted/adopted by the largest cross-section of the Slackware community, I can think of two things that might take advantage of this layering upon previous schemes, while insuring that work is not duplicated or even having to recreate the wheel. 1.) A dedicated group to maintain sbopkg queuefiles into the future. 2.) a new (bash or curses/dialog based) tool to parse those queuefiles for all possible deps and their associated options, including additional optional deps and build time options, that acts upon that queue prior to invoking sbopkg. This approach would ensure that existing methods for customization and installation and tracking are still maintained and available, as well as permitting higher levels of usage that build upon existing tools, instead of re-inventing the wheel. Even then, that's no excuse for not looking at the readme for each slackbuild. I hope that helps :) - -- Bradley D. Thornton Manager Network Services NorthTech Computer TEL: +1.310.388.9469 (US) TEL: +44.203.318.2755 (UK) TEL: +41.43.508.05.10 (CH) http://NorthTech.US -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Find this cert at x-hkp://pool.sks-keyservers.net iQEcBAEBAwAGBQJP/1LCAAoJEE1wgkIhr9j3yPUH/jNgJnS2bjli5eIPQ7q00vGl zSezfVBKcRnKShr0EE2TSayXi1tgmPq9LJmyAYHdWU3bQ+OcAZq65VdQKtCuSvmj M1mqfa4YHjdzuROA9UpXTQUPnE0EPNo+azlezv771A5mV6m7I5sLjq1LIGjWnsYB jcu4ejZ9B3emivCQ0M0pnOQw4RjnJJU5CLC5ZPJ3OS0fty07R+oQoKpY8+7G7J8c P9YdWy52jf9NiseWsVrdJoIvU15SoX5Kq6IyxAHMgBzAlS04B8bdbKSHmfjdG6lQ PKPYKl8SS5Jx6V2pt0YgnHvd/Xbloobw5+LxQ+Y4t2CJN82DECsKcWYHeS1ymPk= =l0f8 -----END PGP SIGNATURE----- From mario at slackverse.org Fri Jul 13 21:26:11 2012 From: mario at slackverse.org (Mario) Date: Fri, 13 Jul 2012 23:26:11 +0200 Subject: [Slackbuilds-users] gtk-kde4 In-Reply-To: References: Message-ID: <50009273.5050202@slackverse.org> On 06/26/2012 05:01 AM, Mathieu Dovan wrote: > Source is missing. Link is dead. > > Cheers > Sorry for late reply, but I no longer use KDE and if someone else wants to take this one over, be my guest (CC). Bumping version could probably fix it, but I don't want to submit something that I haven't tested. :-) Best, mario From Bradley at NorthTech.US Sat Jul 14 21:48:31 2012 From: Bradley at NorthTech.US (Bradley D. Thornton) Date: Sat, 14 Jul 2012 14:48:31 -0700 Subject: [Slackbuilds-users] Concerning: [slackware-security] pidgin (SSA:2012-195-02) In-Reply-To: References: Message-ID: <5001E92F.90400@NorthTech.US> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 On 07/14/2012 11:49 AM, Slackware Security Team wrote: > > [slackware-security] pidgin (SSA:2012-195-02) > > New pidgin packages are available for Slackware 12.2, 13.0, 13.1, 13.37, > and -current to fix security issues. Something that I had thought about bringing up in the past but always ended up not being addressed due to other 'things' I needed to do... Anyway, I was taken aback for a second when I got the email above, but only for a second. I had to think to myself, "Is Pidgin Mainline Slack? Oh yeah, it is.", that's why I'm getting the alert. But there are plenty of SBo's that we don't get any sort of security notification on, and while it is prudent to follow the security lists for any such app that you install, I think that with regards to SBo's most of us don't follow the upstream devs security announcement lists. Has there been any discussion on SBo providing links or any sort of distribution of security news or announcements for SBo's supported here? IOW, once an SBo, say 'htop' goes mainline Slack, then security issues for that app are monitored by the Slackware team and we receive announcements via the Slackware Security list or via a tail of the Changelog. So it may be a good thing if we had something like that here at SBo for announcements concerning SlackBuilds that are carried here. Kindest regards, - -- Bradley D. Thornton Manager Network Services NorthTech Computer TEL: +1.310.388.9469 (US) TEL: +44.203.318.2755 (UK) TEL: +41.43.508.05.10 (CH) http://NorthTech.US -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Find this cert at x-hkp://pool.sks-keyservers.net iQEcBAEBAwAGBQJQAekuAAoJEE1wgkIhr9j3QYMH/jwZE9W62tqVFcjHuKz8qLy2 KS86WFuV5aJt6WCgNfBP+0SMpIAVWoz+IOLHMOUdJB9eb6nKpyZv7IsykVtODcsQ ZN+JQyCJxzxxMoVAaybXdvozEkP+guktBJDPn81wD0W2owXoGYWGC0QpQKxbwF4a cvWMoqON0YG0wx54ETbsUfvtS+YBIWtaTbRR1Y/Bg2WAV5KydltHM7Gfqk/xZGV0 blWNSREMO9U+J8IcjrIQ+Fhd1iQvG/k5O5AeTT/ldcswvFwRd9C8gUG0encChEy2 M1ti0+94mJEsA8GQAkT8uHbyUX8DDbKNnt2johWu1QT2DEH/MxjCwzZUNfTbZaw= =D7VZ -----END PGP SIGNATURE----- From t3slider at gmail.com Sat Jul 14 22:28:35 2012 From: t3slider at gmail.com (T3slider) Date: Sat, 14 Jul 2012 18:28:35 -0400 Subject: [Slackbuilds-users] Concerning: [slackware-security] pidgin (SSA:2012-195-02) In-Reply-To: <5001E92F.90400@NorthTech.US> References: <5001E92F.90400@NorthTech.US> Message-ID: <20120714222835.GA3262@KeithPC.phub.net.cable.rogers.com> I personally keep any packages built by SBo SlackBuilds up to date with the version hosted on slackbuilds.org (sbopkg makes this easy). If there is reason not to for a specific application, then it is my job to make sure it is patched. Other than that, SBo relies on its maintainers for security updates (and version updates), and while I have a quick bash script that lists the packages submitted to pending/approved that I currently have installed (meaning there is an update waiting), I generally depend on the maintainers to keep SlackBuilds up to date. My opinion is that, if you are worried about security, you should keep up with the latest package versions from SBo and if you're paranoid then you can check versions submitted to pending/approved in case there is a long wait before updates are pushed public. There should probably be a bigger focus on pushing security updates public (from pending/approved) versus simple version bumps, but that would be up to the admins I suppose. If even that is not enough (if you're worried that maintainers are falling behind) then you'd have to follow everything upstream, but obviously there's not much SBo could do about that. I find that the "Updates" e-mails on this list are sufficient for me to go through and sbopkg makes identifying any updates to installed packages easy enough for me to check. Of course, I wouldn't object to a Slackbuilds-security mailing list or some such thing but I'm not sure it would really be very effective given the current distribution of labour, which relies heavily on the maintainers (who currently have low accountability). -T3slider On Sat, Jul 14, 2012 at 02:48:31PM -0700, Bradley D. Thornton wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: RIPEMD160 > > > > On 07/14/2012 11:49 AM, Slackware Security Team wrote: > > > > [slackware-security] pidgin (SSA:2012-195-02) > > > > New pidgin packages are available for Slackware 12.2, 13.0, 13.1, 13.37, > > and -current to fix security issues. > > Something that I had thought about bringing up in the past but always > ended up not being addressed due to other 'things' I needed to do... > > Anyway, I was taken aback for a second when I got the email above, but > only for a second. I had to think to myself, "Is Pidgin Mainline Slack? > Oh yeah, it is.", that's why I'm getting the alert. > > But there are plenty of SBo's that we don't get any sort of security > notification on, and while it is prudent to follow the security lists > for any such app that you install, I think that with regards to SBo's > most of us don't follow the upstream devs security announcement lists. > > Has there been any discussion on SBo providing links or any sort of > distribution of security news or announcements for SBo's supported here? > > IOW, once an SBo, say 'htop' goes mainline Slack, then security issues > for that app are monitored by the Slackware team and we receive > announcements via the Slackware Security list or via a tail of the > Changelog. > > So it may be a good thing if we had something like that here at SBo for > announcements concerning SlackBuilds that are carried here. > > Kindest regards, > > > - -- > Bradley D. Thornton > Manager Network Services > NorthTech Computer > TEL: +1.310.388.9469 (US) > TEL: +44.203.318.2755 (UK) > TEL: +41.43.508.05.10 (CH) > http://NorthTech.US > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Find this cert at x-hkp://pool.sks-keyservers.net > > iQEcBAEBAwAGBQJQAekuAAoJEE1wgkIhr9j3QYMH/jwZE9W62tqVFcjHuKz8qLy2 > KS86WFuV5aJt6WCgNfBP+0SMpIAVWoz+IOLHMOUdJB9eb6nKpyZv7IsykVtODcsQ > ZN+JQyCJxzxxMoVAaybXdvozEkP+guktBJDPn81wD0W2owXoGYWGC0QpQKxbwF4a > cvWMoqON0YG0wx54ETbsUfvtS+YBIWtaTbRR1Y/Bg2WAV5KydltHM7Gfqk/xZGV0 > blWNSREMO9U+J8IcjrIQ+Fhd1iQvG/k5O5AeTT/ldcswvFwRd9C8gUG0encChEy2 > M1ti0+94mJEsA8GQAkT8uHbyUX8DDbKNnt2johWu1QT2DEH/MxjCwzZUNfTbZaw= > =D7VZ > -----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 black_rider at esdebian.org Sun Jul 15 10:49:52 2012 From: black_rider at esdebian.org (Black Rider) Date: Sun, 15 Jul 2012 12:49:52 +0200 Subject: [Slackbuilds-users] Concerning: [slackware-security] pidgin (SSA:2012-195-02) In-Reply-To: <5001E92F.90400@NorthTech.US> References: <5001E92F.90400@NorthTech.US> Message-ID: <20120715124952.558be452@whitestar.whitestar.net> I keep an eye on the following sites to know of software vulnerabilities: http://web.nvd.nist.gov/view/vuln/search http://packetstormsecurity.org/ There are times when vulnerabilities are not quickly addressed in SBo, because it takes time to update/approve the new updates in the repository. However, I must sincerely declare that I use over 50 SlackBuilded packages and they rarely have brought a meaningful security hole to my system. El Sat, 14 Jul 2012 14:48:31 -0700 "Bradley D. Thornton" escribi?: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: RIPEMD160 > > > > On 07/14/2012 11:49 AM, Slackware Security Team wrote: > > > > [slackware-security] pidgin (SSA:2012-195-02) > > > > New pidgin packages are available for Slackware 12.2, 13.0, 13.1, > > 13.37, and -current to fix security issues. > > Something that I had thought about bringing up in the past but always > ended up not being addressed due to other 'things' I needed to do... > > Anyway, I was taken aback for a second when I got the email above, but > only for a second. I had to think to myself, "Is Pidgin Mainline > Slack? Oh yeah, it is.", that's why I'm getting the alert. > > But there are plenty of SBo's that we don't get any sort of security > notification on, and while it is prudent to follow the security lists > for any such app that you install, I think that with regards to SBo's > most of us don't follow the upstream devs security announcement lists. > > Has there been any discussion on SBo providing links or any sort of > distribution of security news or announcements for SBo's supported > here? > > IOW, once an SBo, say 'htop' goes mainline Slack, then security issues > for that app are monitored by the Slackware team and we receive > announcements via the Slackware Security list or via a tail of the > Changelog. > > So it may be a good thing if we had something like that here at SBo > for announcements concerning SlackBuilds that are carried here. > > Kindest regards, > > > - -- > Bradley D. Thornton > Manager Network Services > NorthTech Computer > TEL: +1.310.388.9469 (US) > TEL: +44.203.318.2755 (UK) > TEL: +41.43.508.05.10 (CH) > http://NorthTech.US > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Find this cert at x-hkp://pool.sks-keyservers.net > > iQEcBAEBAwAGBQJQAekuAAoJEE1wgkIhr9j3QYMH/jwZE9W62tqVFcjHuKz8qLy2 > KS86WFuV5aJt6WCgNfBP+0SMpIAVWoz+IOLHMOUdJB9eb6nKpyZv7IsykVtODcsQ > ZN+JQyCJxzxxMoVAaybXdvozEkP+guktBJDPn81wD0W2owXoGYWGC0QpQKxbwF4a > cvWMoqON0YG0wx54ETbsUfvtS+YBIWtaTbRR1Y/Bg2WAV5KydltHM7Gfqk/xZGV0 > blWNSREMO9U+J8IcjrIQ+Fhd1iQvG/k5O5AeTT/ldcswvFwRd9C8gUG0encChEy2 > M1ti0+94mJEsA8GQAkT8uHbyUX8DDbKNnt2johWu1QT2DEH/MxjCwzZUNfTbZaw= > =D7VZ > -----END PGP SIGNATURE----- > ---------- My GPG keys are available in various keyservers. To retrieve the one used for signing this mesage, use "gpg --keyserver hkp://keys.gnupg.net --recv-keys 0x6D0B9F27" under GNU/Linux. Windows rises the cost of your computer up to a 20%. Don't let them pull your leg! Use free operating systems. See the websites of Knoppix, Debian, Slackware... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 230 bytes Desc: not available URL: From mjjzf at syntaktisk.dk Sun Jul 15 16:09:19 2012 From: mjjzf at syntaktisk.dk (Morten Juhl-Johansen =?UTF-8?B?WsO2bGRlLUZlamVy?=) Date: Sun, 15 Jul 2012 18:09:19 +0200 Subject: [Slackbuilds-users] Concerning: [slackware-security] pidgin (SSA:2012-195-02) In-Reply-To: <5001E92F.90400@NorthTech.US> References: <5001E92F.90400@NorthTech.US> Message-ID: <20120715180919.3dd86113@AsusEEE.hkf44ms> On Sat, 14 Jul 2012 14:48:31 -0700 "Bradley D. Thornton" wrote: [...] > There are plenty of SBo's that we don't get any sort of security > notification on, and while it is prudent to follow the security lists > for any such app that you install, I think that with regards to SBo's > most of us don't follow the upstream devs security announcement lists. > > Has there been any discussion on SBo providing links or any sort of > distribution of security news or announcements for SBo's supported > here? [...] > So it may be a good thing if we had something like that here at SBo > for announcements concerning SlackBuilds that are carried here. It would certainly be useful in the case where the maintainer (who we assume to have a bit of knowledge around the app) knows that the latest submission solves a particularly egregious issue - be it security, stability or whatever - and makes a note of this with the submission, so it cam be mentioned in the update. Yours, M __ Morten Juhl-Johansen Z?lde-Fejer http://syntaktisk.dk * mjjzf at syntaktisk.dk From kingbeowulf at gmail.com Tue Jul 17 01:52:30 2012 From: kingbeowulf at gmail.com (King Beowulf) Date: Mon, 16 Jul 2012 18:52:30 -0700 Subject: [Slackbuilds-users] [Slackbuilds-user] nvidia update Message-ID: <5004C55E.3010402@gmail.com> Just an FYI to the list: I've submitted new proprietary nvidia scripts for the 302.17 Short Lived Branch as there were tons of useful updates and improvements. There are a few caveats: 1. nvidia-switch is for install and and removal only. I will no longer support switching nvidia and F/OSS on-the-fly. Pick one and stick with it. 2. No support for any hybrid systems. It's not as simple as just swapping xorg.conf since nvidia stomps on several files. I will revisit this issue when I have more time. There are a couple of ways to support this seamlessly and I have to check some kernel parameters. 3. Although the nvidia-driver script can add the 32-bit files for Slackware64 multilib systems, multilib is still not supported. If you use the COMPAT32 option, make sure you keep any eye on "/usr/lib" when you remove the nvidia drivers and go back to F/OSS 32-bit compatibility packages. -Ed From kingbeowulf at gmail.com Tue Jul 17 01:54:59 2012 From: kingbeowulf at gmail.com (King Beowulf) Date: Mon, 16 Jul 2012 18:54:59 -0700 Subject: [Slackbuilds-users] submission error Message-ID: <5004C5F3.4050507@gmail.com> I was able to upload nvidia-driver and nvidia-kernel, but libvdpau results in: There was a problem with your upload. Please check the file and try again. If the problem persists, contact an admin. Yep, so I am contacting the admins. Thanks, Ed From jamesslack at omnitude.net Wed Jul 18 05:00:06 2012 From: jamesslack at omnitude.net (James Smith) Date: Wed, 18 Jul 2012 15:00:06 +1000 Subject: [Slackbuilds-users] Lapack SlackBuild Message-ID: <20120718150006.143472qapd368ceu@webmail.omnitude.net> I attempted to contact the Lapack maintainer with a patch a few weeks ago and got no reply. Could one of the admins be so kind as to apply this patch? Thanks James ----- Forwarded message from jamesslack at omnitude.net ----- Date: Thu, 28 Jun 2012 16:52:23 +1000 From: James Smith Subject: Lapack SlackBuild To: easuter at gmail.com Hi Eugene, I found a problem with your Lapack slackbuild. I'd created a SlackBuild for the Haskell library hmatrix and I found when loading it in ghci that there was a function missing from liblapack.so- cswap_. That function is from blas. I resolved it by the following: --- lapack.SlackBuild 2011-05-30 00:49:04.000000000 +1000 +++ lapack.SlackBuild.sbopkg 2012-06-28 16:02:53.000000000 +1000 @@ -74 +74 @@ - gcc -fPIC -lgfortran -shared *.o -Wl,-soname,lib$PRGNAM.so.$MAJOR \ + gcc -fPIC -lgfortran -lblas -shared *.o -Wl,-soname,lib$PRGNAM.so.$MAJOR \ i.e. adding "-lblas" to the .so creation. I had a look at the Debian and Fedora package sources and they also do "-lblas" when creating the .so. Incidentally the script works fine with 3.4.1. In upgrading to 3.4.1 I also compared your make.inc and its make.inc.example... which led me to use TIMER=INT_ETIME instead of TIMER=NONE and that worked fine too. Regards James Smith ----- End forwarded message ----- From ozan.turkyilmaz at gmail.com Wed Jul 18 07:26:47 2012 From: ozan.turkyilmaz at gmail.com (=?UTF-8?B?T3phbiBUw7xya3nEsWxtYXo=?=) Date: Wed, 18 Jul 2012 12:26:47 +0500 Subject: [Slackbuilds-users] Small patch to games/fortune-ASR/fortune-ASR.SlackBuild Message-ID: Hey all, A small patch to fortune-ASR.SlackBuild. It fixes missing "s" in the cp/mkdir commands. -- Ozan, BSc, BEng -------------- next part -------------- A non-text attachment was scrubbed... Name: fortune-ASR.diff Type: application/octet-stream Size: 733 bytes Desc: not available URL: From adis at linux.org.ba Wed Jul 18 08:25:12 2012 From: adis at linux.org.ba (Adis Nezirovic) Date: Wed, 18 Jul 2012 10:25:12 +0200 Subject: [Slackbuilds-users] Concerning: [slackware-security] pidgin (SSA:2012-195-02) In-Reply-To: <20120715180919.3dd86113@AsusEEE.hkf44ms> References: <5001E92F.90400@NorthTech.US> <20120715180919.3dd86113@AsusEEE.hkf44ms> Message-ID: Most of the time, security update is minor version update, so it's enough to change version numbers in slackbuild, end everything should build fine. So, there is no need to wait for anyone, this is Slackware, You take care of yourself :-) Best regards, Adis From serban.udrea at skmail.ikp.physik.tu-darmstadt.de Wed Jul 18 09:52:08 2012 From: serban.udrea at skmail.ikp.physik.tu-darmstadt.de (Serban Udrea) Date: Wed, 18 Jul 2012 11:52:08 +0200 Subject: [Slackbuilds-users] Lapack SlackBuild In-Reply-To: <20120718150006.143472qapd368ceu@webmail.omnitude.net> References: <20120718150006.143472qapd368ceu@webmail.omnitude.net> Message-ID: <50068748.8000106@skmail.ikp.physik.tu-darmstadt.de> On 07/18/2012 07:00 AM, James Smith wrote: > I attempted to contact the Lapack maintainer with a patch a few weeks > ago and got no reply. Could one of the admins be so kind as to apply > this patch? >... > I found a problem with your Lapack slackbuild. I'd created a SlackBuild > for the Haskell library hmatrix and I found when loading it in ghci that > there was a function missing from liblapack.so- cswap_. That function is > from blas. >... > i.e. adding "-lblas" to the .so creation. I had a look at the Debian and > Fedora package sources and they also do "-lblas" when creating the .so. > ... Hello James, I'm the maintainer of the lapack-atlas slackbuild. Since this is a variation of Eugene's one I also don't link against blas (in my case atlas). Nevertheless I use several software packages compiled against lapack-atlas and never had a problem like yours. Moreover I definitely doubt that lapack should by any means provide a blas function. Thus I rather suppose that there is a problem with the way the Haskell library gets linked. BTW, did you consider using ATLAS instead of the reference blas? Best regards, Serban Udrea From jamesslack at omnitude.net Wed Jul 18 13:23:00 2012 From: jamesslack at omnitude.net (James Smith) Date: Wed, 18 Jul 2012 23:23:00 +1000 Subject: [Slackbuilds-users] Lapack SlackBuild In-Reply-To: <50068748.8000106@skmail.ikp.physik.tu-darmstadt.de> References: <20120718150006.143472qapd368ceu@webmail.omnitude.net> <50068748.8000106@skmail.ikp.physik.tu-darmstadt.de> Message-ID: <20120718232300.35614egdh0v73t10@omnitude.net> > Nevertheless I use several software packages compiled against > lapack-atlas and never had a problem like yours. Moreover I > definitely doubt that lapack should by any means provide a blas > function. Thus I rather suppose that there is a problem with the way > the Haskell library gets linked. It's not providing the blas function to users of the library, it's providing it to the library itself. -l specifies to link against that library because some function from it is referenced. It takes the shared library in preference to the static because -static is not specified. So just like -lgfortran which it already has... those libraries are also used by lapack. If lapack uses blas it must link against it, otherwise it can't call the code. I imagine these other applications are linking against blas themselves, which provides blas to lapack, whereas hmatrix isn't. But blas is a dependency of lapack, not of hmatrix, so that is correct in my opinion, although I don't know the conventions. Like Eugene comments in his SlackBuild it really would be nice if lapack built the .so themselves :P All I had for reference was the Debian and Fedora packages and who knows if we should trust them. > BTW, did you consider using ATLAS instead of the reference blas? I did, but for what I'm using it for I'm not too interested in performance, and it seemed like a fair amount of effort :-) It might be worth it now to see if it exhibits the same problem. Regards James From serban.udrea at skmail.ikp.physik.tu-darmstadt.de Wed Jul 18 14:51:05 2012 From: serban.udrea at skmail.ikp.physik.tu-darmstadt.de (Serban Udrea) Date: Wed, 18 Jul 2012 16:51:05 +0200 Subject: [Slackbuilds-users] Lapack SlackBuild In-Reply-To: <20120718232300.35614egdh0v73t10@omnitude.net> References: <20120718150006.143472qapd368ceu@webmail.omnitude.net> <50068748.8000106@skmail.ikp.physik.tu-darmstadt.de> <20120718232300.35614egdh0v73t10@omnitude.net> Message-ID: <5006CD59.9040002@skmail.ikp.physik.tu-darmstadt.de> On 07/18/2012 03:23 PM, James Smith wrote: >> ... Moreover I definitely doubt that lapack should by any means provide >> a blas function... > > It's not providing the blas function to users of the library, it's > providing it to the library itself... OK, got it. > > If lapack uses blas it must link against it, otherwise it can't call the > code. I imagine these other applications are linking against blas > themselves, which provides blas to lapack, whereas hmatrix isn't. But > blas is a dependency of lapack, not of hmatrix, so that is correct in my > opinion, although I don't know the conventions. Indeed, any piece of software(*) I use, got linked both to lapack and blas (in my case atlas). So from this point of view hmatrix is the only one I heard about doing it differently. (*) Which has something to do with lapack, e.g. scipy and umfpack. > Like Eugene comments in his SlackBuild it really would be nice if lapack > built the .so themselves :P All I had for reference was the Debian and > Fedora packages and who knows if we should trust them. Well, I'm also a Debian user, so I do think I trust them too. >> BTW, did you consider using ATLAS instead of the reference blas? > > I did, but for what I'm using it for I'm not too interested in > performance, and it seemed like a fair amount of effort :-) It might be > worth it now to see if it exhibits the same problem. > Hmm, I thought I took something like 90% of the effort off, by providing the SlackBuilds for atlas and lapack-atlas. Actually, the default settings to these scripts should work for most use cases. As with the problem, I would be surprised if it wouldn't be there, since, as I wrote, I basically do the same as Eugene when building the dynamic libraries. Best regards, Serban From jamesslack at omnitude.net Thu Jul 19 03:36:11 2012 From: jamesslack at omnitude.net (James Smith) Date: Thu, 19 Jul 2012 13:36:11 +1000 Subject: [Slackbuilds-users] Lapack SlackBuild In-Reply-To: <5006CD59.9040002@skmail.ikp.physik.tu-darmstadt.de> References: <20120718150006.143472qapd368ceu@webmail.omnitude.net> <50068748.8000106@skmail.ikp.physik.tu-darmstadt.de> <20120718232300.35614egdh0v73t10@omnitude.net> <5006CD59.9040002@skmail.ikp.physik.tu-darmstadt.de> Message-ID: <20120719133611.17074td0ti0j73jf@webmail.omnitude.net> On Thu, 19 Jul 2012, Serban Udrea wrote: > Indeed, any piece of software(*) I use, got linked both to lapack > and blas (in my case atlas). So from this point of view hmatrix is > the only one I heard about doing it differently. Well hmatrix does have an "autodetect" mechanism because apparently there are some distro-specific differences about the names of the libraries it links to (no doubt due to issues like netlib not building the .so). But it doesn't seem to work detecting that lapack needs blas linked in too. > Hmm, I thought I took something like 90% of the effort off, by > providing the SlackBuilds for atlas and lapack-atlas. Actually, the > default settings to these scripts should work for most use cases. You did, but that effort was still slightly more than "run the reference blas slackbuild" :P And given I didn't care about performance it seemed unnecessary. I'll probably need the performance sometime, so I'll switch over to atlas once that happens. Thanks for your comments. So you agree with my patch then? ;-) James From serban.udrea at skmail.ikp.physik.tu-darmstadt.de Thu Jul 19 09:47:39 2012 From: serban.udrea at skmail.ikp.physik.tu-darmstadt.de (Serban Udrea) Date: Thu, 19 Jul 2012 11:47:39 +0200 Subject: [Slackbuilds-users] Lapack SlackBuild In-Reply-To: <20120719133611.17074td0ti0j73jf@webmail.omnitude.net> References: <20120718150006.143472qapd368ceu@webmail.omnitude.net> <50068748.8000106@skmail.ikp.physik.tu-darmstadt.de> <20120718232300.35614egdh0v73t10@omnitude.net> <5006CD59.9040002@skmail.ikp.physik.tu-darmstadt.de> <20120719133611.17074td0ti0j73jf@webmail.omnitude.net> Message-ID: <5007D7BB.4050702@skmail.ikp.physik.tu-darmstadt.de> On 07/19/2012 05:36 AM, James Smith wrote: >... > Thanks for your comments. So you agree with my patch then? ;-) > ... Not yet. Besides, even if I would agree, it's not against a script I maintain. For a final opinion, I need to check, if the change you propose(#) would impact at least on numpy and scipy, which I maintain -- not to speak about things I have in work, or the fact that others may need to check what happens with the lapack related software they provide a SlackBuild for(*). Sincerely speaking, it might be much easier to just patch hmatrix to also link against wathever kind of blas is installed. Still, it may not be the right way to go. Best regards, Serban (#) And a similar one applied to lapack-atlas. (*) My feeling is that there would be no impact at all, but checking is better. Nevertheless, this would take me some time. From jamesslack at omnitude.net Thu Jul 19 11:53:57 2012 From: jamesslack at omnitude.net (James Smith) Date: Thu, 19 Jul 2012 21:53:57 +1000 Subject: [Slackbuilds-users] Lapack SlackBuild In-Reply-To: <5007D7BB.4050702@skmail.ikp.physik.tu-darmstadt.de> References: <20120718150006.143472qapd368ceu@webmail.omnitude.net> <50068748.8000106@skmail.ikp.physik.tu-darmstadt.de> <20120718232300.35614egdh0v73t10@omnitude.net> <5006CD59.9040002@skmail.ikp.physik.tu-darmstadt.de> <20120719133611.17074td0ti0j73jf@webmail.omnitude.net> <5007D7BB.4050702@skmail.ikp.physik.tu-darmstadt.de> Message-ID: <20120719215357.28075ul4li9fj2ad@omnitude.net> That sounds like a wise approach! Thanks again. James On Thu, 19 Jul 2012, Serban Udrea wrote: > On 07/19/2012 05:36 AM, James Smith wrote: >> ... >> Thanks for your comments. So you agree with my patch then? ;-) >> ... > > Not yet. Besides, even if I would agree, it's not against a script I > maintain. > > For a final opinion, I need to check, if the change you propose(#) > would impact at least on numpy and scipy, which I maintain -- not > to speak about things I have in work, or the fact that others may > need to check what happens with the lapack related software they > provide a SlackBuild for(*). Sincerely speaking, it might be much > easier to just patch hmatrix to also link against wathever kind of > blas is installed. Still, it may not be the right way to go. > > Best regards, > > Serban > > (#) And a similar one applied to lapack-atlas. > > (*) My feeling is that there would be no impact at all, but checking > is better. Nevertheless, this would take me some time. > _______________________________________________ > 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 easuter at gmail.com Thu Jul 19 21:58:01 2012 From: easuter at gmail.com (=?ISO-8859-1?Q?Eug=E9ne_Suter?=) Date: Thu, 19 Jul 2012 22:58:01 +0100 Subject: [Slackbuilds-users] Lapack SlackBuild In-Reply-To: <20120719215357.28075ul4li9fj2ad@omnitude.net> References: <20120718150006.143472qapd368ceu@webmail.omnitude.net> <50068748.8000106@skmail.ikp.physik.tu-darmstadt.de> <20120718232300.35614egdh0v73t10@omnitude.net> <5006CD59.9040002@skmail.ikp.physik.tu-darmstadt.de> <20120719133611.17074td0ti0j73jf@webmail.omnitude.net> <5007D7BB.4050702@skmail.ikp.physik.tu-darmstadt.de> <20120719215357.28075ul4li9fj2ad@omnitude.net> Message-ID: Well, I'm late for the party but since this is about a SlackBuild I maintain I may as well chip in :) Firstly: James, I apologize for not replying sooner, but I've not had time to deal with my SlackBuilds... Which leads me to my next point: if you're interested in taking over my BLAS/Lapack packages please feel free to do so! However, IMHO, I would recommend Serban's SlackBuilds for cblas and Lapack rather than mine seeing that Atlas gives you an optimized build rather than just a reference implementation of the libraries. Cheers, Eug?ne On 19 July 2012 12:53, James Smith wrote: > That sounds like a wise approach! > > Thanks again. > James > > > > On Thu, 19 Jul 2012, Serban Udrea physik.tu-darmstadt.de > > wrote: > > On 07/19/2012 05:36 AM, James Smith wrote: >> >>> ... >>> Thanks for your comments. So you agree with my patch then? ;-) >>> ... >>> >> >> Not yet. Besides, even if I would agree, it's not against a script I >> maintain. >> >> For a final opinion, I need to check, if the change you propose(#) would >> impact at least on numpy and scipy, which I maintain -- not to speak about >> things I have in work, or the fact that others may need to check what >> happens with the lapack related software they provide a SlackBuild for(*). >> Sincerely speaking, it might be much easier to just patch hmatrix to also >> link against wathever kind of blas is installed. Still, it may not be the >> right way to go. >> >> Best regards, >> >> Serban >> >> (#) And a similar one applied to lapack-atlas. >> >> (*) My feeling is that there would be no impact at all, but checking is >> better. Nevertheless, this would take me some time. >> ______________________________**_________________ >> 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 c.willing at uq.edu.au Thu Jul 19 22:57:02 2012 From: c.willing at uq.edu.au (Christoph Willing) Date: Fri, 20 Jul 2012 08:57:02 +1000 Subject: [Slackbuilds-users] Plans for jdk, jre Message-ID: <83064F45-E283-47B9-9F39-09698F655338@uq.edu.au> Since jre & jdk packages have been removed from -current, is anyone already planning relevant 14.0 SlackBuilds for SBo? Alternatively is there a better strategy for making a jdk available for those other SlackBuilds which assume its available? Alienbob's recipe perhaps - or could he be persuaded to make an SBo SlackBuild for it ...? chris Christoph Willing +61 7 3365 8316 Research Computing Centre University of Queensland From yalhcru at gmail.com Thu Jul 19 23:46:17 2012 From: yalhcru at gmail.com (B Watson) Date: Thu, 19 Jul 2012 19:46:17 -0400 Subject: [Slackbuilds-users] Plans for jdk, jre In-Reply-To: <83064F45-E283-47B9-9F39-09698F655338@uq.edu.au> References: <83064F45-E283-47B9-9F39-09698F655338@uq.edu.au> Message-ID: On 7/19/12, Christoph Willing wrote: > Since jre & jdk packages have been removed from -current, is anyone > already planning relevant 14.0 SlackBuilds for SBo? As I understand it, the jdk and jre slackbuilds from slackware itself can still legally be used to make packages (although the packages can't be distributed). Maybe the existing slackbuilds could be on the install DVD in /extra, like flashplayer-plugin was in 13.37... I'd wait & see if this happens, before adding jre/jdk packages to SBo. (Of course, I'm just some random guy with an opinion, don't think I speak authoritatively or anything) From j at dawnrazor.net Fri Jul 20 03:46:02 2012 From: j at dawnrazor.net (J) Date: Thu, 19 Jul 2012 22:46:02 -0500 Subject: [Slackbuilds-users] Plans for jdk, jre In-Reply-To: <83064F45-E283-47B9-9F39-09698F655338@uq.edu.au> References: <83064F45-E283-47B9-9F39-09698F655338@uq.edu.au> Message-ID: <20120719224602.Horde.n2aaYogBVY5QCNR6eInXMbA@mail.dawnrazor.net> When Oracle made their jre/jdk not-distributable, they also made it no longer the reference implementation - and promoted openjre/jdk as the new reference. The message from Oracle is quite clear - use open, not Oracle. So, it seems likely to me that Pat will be replacing the oracle jre/jdk with the open jre/jdk. Quoting Christoph Willing : > Since jre & jdk packages have been removed from -current, is anyone > already planning relevant 14.0 SlackBuilds for SBo? > > Alternatively is there a better strategy for making a jdk available > for those other SlackBuilds which assume its available? Alienbob's > recipe perhaps - or could he be persuaded to make an SBo SlackBuild > for it ...? > > > chris > > > Christoph Willing +61 7 3365 8316 > Research Computing Centre > University of Queensland > > > > _______________________________________________ > 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 j at dawnrazor.net Fri Jul 20 05:18:07 2012 From: j at dawnrazor.net (J) Date: Fri, 20 Jul 2012 00:18:07 -0500 Subject: [Slackbuilds-users] liblrdf and ardour patches and stuff Message-ID: <20120720001807.Horde.MKNTL4gBVY5QCOoPH1P-2xA@mail.dawnrazor.net> I'm including a few things here both for Heinz, who maintains these slackbuilds, and for anyone running -current who uses them and wants to continue doing so on -current. Heinz, I haven't tested this stuff with 13.37, just was getting these packages going on -current and figured that when it comes time to update the slackbuilds for 14 this should save some work. First is a patch against the liblrdf source to compile against raptor2 instead of raptor. I borrowed this from Arch and added my own patch to lrdf.h to include raptor2/raptor2.h, which lets ardour build against it. Second is a patch to the liblrdf.SlackBuild to utilize the first patch. Third is a patch against the ardour source to compile with the new glib changes, and fourth is a patch against the ardour.SlackBuild to utilize the glib patch. Once liblrdf is compiled against raptor2, ardour (with this patch applied) builds and runs. I spent a small amount of time looking at ardour-2.8.13, but since it won't build against its own libs, its external dependencies are numerous, and not all are on slackbuilds.org at present, so I wanted to get this up and running now. I may or may not create slackbuilds for the missing deps. J -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-raptor2.diff Type: application/octet-stream Size: 7193 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: liblrdf-build.patch Type: application/octet-stream Size: 312 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: glib.patch Type: application/octet-stream Size: 13730 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ardour-build.patch Type: application/octet-stream Size: 334 bytes Desc: not available URL: From Bradley at NorthTech.US Fri Jul 20 05:50:26 2012 From: Bradley at NorthTech.US (Bradley D. Thornton) Date: Thu, 19 Jul 2012 22:50:26 -0700 Subject: [Slackbuilds-users] Plans for jdk, jre In-Reply-To: <20120719224602.Horde.n2aaYogBVY5QCNR6eInXMbA@mail.dawnrazor.net> References: <83064F45-E283-47B9-9F39-09698F655338@uq.edu.au> <20120719224602.Horde.n2aaYogBVY5QCNR6eInXMbA@mail.dawnrazor.net> Message-ID: <5008F1A2.2040803@NorthTech.US> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 On 07/19/2012 08:46 PM, J wrote: > When Oracle made their jre/jdk not-distributable, they also made it no > longer the reference implementation - and promoted openjre/jdk as the > new reference. The message from Oracle is quite clear - use open, not > Oracle. So, it seems likely to me that Pat will be replacing the oracle > jre/jdk with the open jre/jdk. Yeah, a bit off topic, but I find myself to ask in the community here, what possible benefit can derived from this deterministic auto-exsanguination that EllisonCo seems so committed to? OpenSolaris, OpenOffice, arguably MySQL, and now Java - These were the feathers in Sun's cap. Is VirtualBox next? Kindest regards, - -- Bradley D. Thornton Manager Network Services NorthTech Computer TEL: +1.310.388.9469 (US) TEL: +44.203.318.2755 (UK) TEL: +41.43.508.05.10 (CH) http://NorthTech.US -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Find this cert at x-hkp://pool.sks-keyservers.net iQEcBAEBAwAGBQJQCPGhAAoJEE1wgkIhr9j38cgIALfI9CU68pkm3sT8HaZrntBV upFxZ2iCl8xFpTNvy1e+XL5ZZY6zJcqx7zS26LhGpAd7umUQbwezLGwvo5Ij5uMb 30QPJDY/FJmBYsaiktyWrVtxFU5XweZc/EdCIr7ufjtWMALL+Mfc2yQqrCqSrFBU OvN/cCvZxYLwg1V9R398I5olhYBIOOs6eM8S7uaa9O9eSoDjGPaNdZeXE7a4skyl FLuw7C8F0etXZwe/8tpWR5Z8h8p91QUs1m+lnj+Xu2r9rUc+g4Dth8PSPnKCR5wY tYPmYP1zUbkF2/+73HN46koKDU88b8vTuMT+Hxk1FGF8ww/XG8wYFc6bl3vemco= =dSnA -----END PGP SIGNATURE----- From info at microlinux.fr Fri Jul 20 08:18:14 2012 From: info at microlinux.fr (Nicolas Kovacs) Date: Fri, 20 Jul 2012 10:18:14 +0200 Subject: [Slackbuilds-users] recode no more maintained Message-ID: <50091446.3030307@microlinux.fr> Hi, To my great dismay, the 'recode' package isn't maintained anymore. Or, well, sort of. There's a stale beta of a new version on github. But in any case, the initial download link doesn't work anymore. Sad news, as I'm using this software quite often. (And BTW, I was surprised to discover that the initial SlackBuild on slackbuilds.org was submitted by myself :oD) There are some archives who still offer recode-3.6.tar.gz for downloading though. Works well for me. Cheers from South France, Niki Kovacs -- 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 ppetrov at mail.student.oulu.fi Fri Jul 20 19:21:38 2012 From: ppetrov at mail.student.oulu.fi (Petar Petrov) Date: Fri, 20 Jul 2012 22:21:38 +0300 Subject: [Slackbuilds-users] perl-cairo In-Reply-To: <50091446.3030307@microlinux.fr> References: <50091446.3030307@microlinux.fr> Message-ID: <20120720222138.5brbjzpzoc04gcks@webmail.oulu.fi> hi perl-cairo has a broken download link. It seems that the version available for download is 1.100. regards, petar From erik at slackbuilds.org Sat Jul 21 01:41:23 2012 From: erik at slackbuilds.org (Erik Hanson) Date: Fri, 20 Jul 2012 20:41:23 -0500 Subject: [Slackbuilds-users] Updates - 20120721.1 Message-ID: <20120720204123.5ea40ac4@shaggy.doo> Sat Jul 21 01:33:18 UTC 2012 desktop/ccsm: Updated download link. desktop/emerald: Updated download link. desktop/qlandkartegt: Updated for version 1.5.0. development/eric: Updated for version 4.5.4. development/mono-basic: Updated download link. games/gnubg: Updated for version 0.90.0_20120701. games/nethack: Minor cleanups. libraries/afflib: Updated for version 3.7.1. libraries/c++-gtk-utils: Updated for version 2.0.10. libraries/compiz-bcop: Updated download link. libraries/compiz-plugins-extra: Updated download link. libraries/compiz-plugins-main: Updated download link. libraries/compiz-plugins-unsupported: Updated download link. libraries/compizconfig-backend-kconfig4: Updated download link. libraries/compizconfig-python: Updated download link. libraries/fltk2: Updated for version 2.0.x_alpha_r9296. libraries/hdf5: Updated for version 1.8.9. libraries/libcompizconfig: Updated download link. libraries/tbb: Updated for version 4.0u5. multimedia/kdenlive: Updated for version 0.9.2. multimedia/mlt: Updated for version 0.8.0. network/allmydata-tahoe: Updated for version 1.9.2. network/choqok: Updated for version 1.3. network/nginx: Updated for version 1.2.2. network/qupzilla: Fixed download links. office/myrulib: Updated for version 0.29.9. office/pandoc: Updated for version 1.9.4.2. system/dar: Updated for version 2.4.7. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From binhnguyen at fastmail.fm Sat Jul 21 13:43:48 2012 From: binhnguyen at fastmail.fm (Binh Nguyen) Date: Sat, 21 Jul 2012 20:43:48 +0700 Subject: [Slackbuilds-users] perl-cairo In-Reply-To: <20120720222138.5brbjzpzoc04gcks@webmail.oulu.fi> References: <50091446.3030307@microlinux.fr> <20120720222138.5brbjzpzoc04gcks@webmail.oulu.fi> Message-ID: <1342878228.28464.140661104884741.75C0242D@webmail.messagingengine.com> On Fri, Jul 20, 2012, at 10:21 PM, Petar Petrov wrote: > hi > > perl-cairo has a broken download link. It seems that the version > available for download is 1.100. > > regards, > > petar > Thanks for the heads-up. I've just submitted the SlackBuild for version 1.100. It's ridiculous that they delete older sources on CPAN when a new version comes up. -- http://www.fastmail.fm - A no graphics, no pop-ups email service From serban.udrea at skmail.ikp.physik.tu-darmstadt.de Sat Jul 21 14:03:43 2012 From: serban.udrea at skmail.ikp.physik.tu-darmstadt.de (Serban Udrea) Date: Sat, 21 Jul 2012 16:03:43 +0200 Subject: [Slackbuilds-users] Lapack SlackBuild In-Reply-To: References: <20120718150006.143472qapd368ceu@webmail.omnitude.net> <50068748.8000106@skmail.ikp.physik.tu-darmstadt.de> <20120718232300.35614egdh0v73t10@omnitude.net> <5006CD59.9040002@skmail.ikp.physik.tu-darmstadt.de> <20120719133611.17074td0ti0j73jf@webmail.omnitude.net> <5007D7BB.4050702@skmail.ikp.physik.tu-darmstadt.de> <20120719215357.28075ul4li9fj2ad@omnitude.net> Message-ID: <500AB6BF.8060604@skmail.ikp.physik.tu-darmstadt.de> On 07/19/2012 11:58 PM, Eug?ne Suter wrote: > ... > Which leads me to my next point: if you're interested in taking over my > BLAS/Lapack packages please feel free to do so! > > However, IMHO, I would recommend Serban's SlackBuilds for cblas and Lapack > rather than mine seeing that Atlas gives you an optimized build rather than > just a reference implementation of the libraries. > ... Hello! Nice to hear from you Eug?ne! The blas and lapack SlackBuilds are important to maintain, IMHO exactly because they are the reference. Thus, if James doesn't have the time to take them over I can do it. Best regards, Serban From easuter at gmail.com Sat Jul 21 15:39:32 2012 From: easuter at gmail.com (=?ISO-8859-1?Q?Eug=E9ne_Suter?=) Date: Sat, 21 Jul 2012 16:39:32 +0100 Subject: [Slackbuilds-users] Lapack SlackBuild In-Reply-To: <500AB6BF.8060604@skmail.ikp.physik.tu-darmstadt.de> References: <20120718150006.143472qapd368ceu@webmail.omnitude.net> <50068748.8000106@skmail.ikp.physik.tu-darmstadt.de> <20120718232300.35614egdh0v73t10@omnitude.net> <5006CD59.9040002@skmail.ikp.physik.tu-darmstadt.de> <20120719133611.17074td0ti0j73jf@webmail.omnitude.net> <5007D7BB.4050702@skmail.ikp.physik.tu-darmstadt.de> <20120719215357.28075ul4li9fj2ad@omnitude.net> <500AB6BF.8060604@skmail.ikp.physik.tu-darmstadt.de> Message-ID: On 21 July 2012 15:03, Serban Udrea < serban.udrea at skmail.ikp.physik.tu-darmstadt.de> wrote: > On 07/19/2012 11:58 PM, Eug?ne Suter wrote: > >> ... >> Which leads me to my next point: if you're interested in taking over my >> BLAS/Lapack packages please feel free to do so! >> >> However, IMHO, I would recommend Serban's SlackBuilds for cblas and Lapack >> rather than mine seeing that Atlas gives you an optimized build rather >> than >> just a reference implementation of the libraries. >> ... >> > > Hello! > > Nice to hear from you Eug?ne! > > The blas and lapack SlackBuilds are important to maintain, IMHO exactly > because they are the reference. Thus, if James doesn't have the time to > take them over I can do it. > Well in that case please feel free to do so! :) > > Best regards, > > Serban Cheers, Eug?ne -------------- next part -------------- An HTML attachment was scrubbed... URL: From jamesslack at omnitude.net Sun Jul 22 08:29:12 2012 From: jamesslack at omnitude.net (James Smith) Date: Sun, 22 Jul 2012 18:29:12 +1000 Subject: [Slackbuilds-users] Lapack SlackBuild In-Reply-To: References: <20120718150006.143472qapd368ceu@webmail.omnitude.net> <50068748.8000106@skmail.ikp.physik.tu-darmstadt.de> <20120718232300.35614egdh0v73t10@omnitude.net> <5006CD59.9040002@skmail.ikp.physik.tu-darmstadt.de> <20120719133611.17074td0ti0j73jf@webmail.omnitude.net> <5007D7BB.4050702@skmail.ikp.physik.tu-darmstadt.de> <20120719215357.28075ul4li9fj2ad@omnitude.net> <500AB6BF.8060604@skmail.ikp.physik.tu-darmstadt.de> Message-ID: <20120722182912.1053277ruk7hu3fc@omnitude.net> Sorry about the slow reply; was destroying/building a wall all weekend. >> Nice to hear from you Eug?ne! Indeed :-) >> The blas and lapack SlackBuilds are important to maintain, IMHO exactly >> because they are the reference. Thus, if James doesn't have the time to >> take them over I can do it. >> > > Well in that case please feel free to do so! :) Yeah, I think that's for the best- I'm new to the Lapack game and don't use the library directly. Besides, Serban already maintains the others ;-) Kind regards James From kristofru at gmail.com Mon Jul 23 06:58:18 2012 From: kristofru at gmail.com (Chris Abela) Date: Mon, 23 Jul 2012 08:58:18 +0200 Subject: [Slackbuilds-users] recode no more maintained In-Reply-To: <50091446.3030307@microlinux.fr> References: <50091446.3030307@microlinux.fr> Message-ID: Hi Niki, Yes I had inherited the maintenance of this SlackBuild from you as I wanted a slight modification to build recode on Slack 13.0. I have just submitted an update for recode.info: DOWNLOAD="http://slackermedia.info/slackbuilds/recode-3.6.tar.gz (thanks to klaatu) Presently I am looking for a new maintainer for this SlackBuild, so please let me know if you want it back. Chris P.S. Welcome back to Slackware On Fri, Jul 20, 2012 at 10:18 AM, Nicolas Kovacs wrote: > Hi, > > To my great dismay, the 'recode' package isn't maintained anymore. Or, well, > sort of. There's a stale beta of a new version on github. But in any case, > the initial download link doesn't work anymore. > > Sad news, as I'm using this software quite often. (And BTW, I was surprised > to discover that the initial SlackBuild on slackbuilds.org was submitted by > myself :oD) > > There are some archives who still offer recode-3.6.tar.gz for downloading > though. Works well for me. > > Cheers from South France, > > Niki Kovacs > -- > 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 > _______________________________________________ > 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 jbernts at broadpark.no Mon Jul 23 07:40:05 2012 From: jbernts at broadpark.no (Jostein Berntsen) Date: Mon, 23 Jul 2012 09:40:05 +0200 Subject: [Slackbuilds-users] recode no more maintained In-Reply-To: <50091446.3030307@microlinux.fr> References: <50091446.3030307@microlinux.fr> Message-ID: <20120723074005.GA9361@josteinb> On 20.07.12,10:18, Nicolas Kovacs wrote: > Hi, > > To my great dismay, the 'recode' package isn't maintained anymore. > Or, well, sort of. There's a stale beta of a new version on github. > But in any case, the initial download link doesn't work anymore. > > Sad news, as I'm using this software quite often. (And BTW, I was > surprised to discover that the initial SlackBuild on slackbuilds.org > was submitted by myself :oD) > > There are some archives who still offer recode-3.6.tar.gz for > downloading though. Works well for me. > There is also the 3.7-beta2 version which is available from Freecode: http://freecode.com/projects/freerecode Jostein $ From slava18 at gmail.com Tue Jul 24 09:56:22 2012 From: slava18 at gmail.com (V'yacheslav Stetskevych) Date: Tue, 24 Jul 2012 12:56:22 +0300 Subject: [Slackbuilds-users] Please check the link for perl-Test-Inter In-Reply-To: References: Message-ID: On Tue, Jul 24, 2012 at 7:17 AM, Branden Capell wrote: > http://search.cpan.org/CPAN/authors/id/S/SB/SBECK/Test-Inter-1.01.tar.gz > > Sorry we keep meeting like this, or talking only when things are broken on > SBo. I'm no longer maintaining these packages, sorry. Forwarding this to slackbuilds-users. -- Vyacheslav -- If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby Digital and all the music is free... http://www.getgnulinux.org From matteo.bernardini at gmail.com Tue Jul 24 10:24:15 2012 From: matteo.bernardini at gmail.com (Matteo Bernardini) Date: Tue, 24 Jul 2012 12:24:15 +0200 Subject: [Slackbuilds-users] Please check the link for perl-Test-Inter In-Reply-To: References: Message-ID: if can be useful, I have updated locally to 1.03 http://cgit.ponce.cc/slackbuilds/commit/?h=perl-Test-Inter From matteo.bernardini at gmail.com Tue Jul 24 12:48:44 2012 From: matteo.bernardini at gmail.com (Matteo Bernardini) Date: Tue, 24 Jul 2012 14:48:44 +0200 Subject: [Slackbuilds-users] Please check the link for perl-Test-Inter In-Reply-To: References: Message-ID: I was submitting another tarball for a broken download link for nxclient (just a change of ip) and I noticed that submissions are closed in preparation for the new slackware release. We will think about this too later :) I just grab the occasion to thank the admins for their work. :) Matteo From tobias.columbus at googlemail.com Tue Jul 24 12:51:00 2012 From: tobias.columbus at googlemail.com (Tobias Columbus) Date: Tue, 24 Jul 2012 14:51:00 +0200 Subject: [Slackbuilds-users] Small error in google-go-lang SlackBuild Message-ID: <20120724125100.GA16311@leviathan.localdomain> Hi folks, I stumbled upon a tiny bug in the google-go-lang Slackbuild. If there is an $ARCH environment variable set, then the local variable $GARCH is not properly initialized. Patch attached. By the way, thanks to all maintainers and admins for the great work! Tobias -------------- next part -------------- *** original --- modified *************** *** 34,43 **** if [ -z "$ARCH" ]; then case "$( uname -m )" in ! i?86) ARCH=i486; GARCH=386 ;; ! x86_64) ARCH=x86_64; GARCH=amd64 ;; *) ARCH=$( uname -m ) ;; esac fi CWD=$(pwd) TMP=${TMP:-/tmp/SBo} --- 34,49 ---- if [ -z "$ARCH" ]; then case "$( uname -m )" in ! i?86) ARCH=i486 ;; ! x86_64) ARCH=x86_64 ;; *) ARCH=$( uname -m ) ;; esac fi + case "$ARCH" in + i?86) GARCH=386 ;; + x86_64) GARCH=amd64 ;; + *) ;; + esac + CWD=$(pwd) TMP=${TMP:-/tmp/SBo} From tobias.columbus at googlemail.com Tue Jul 24 13:03:14 2012 From: tobias.columbus at googlemail.com (Tobias Columbus) Date: Tue, 24 Jul 2012 15:03:14 +0200 Subject: [Slackbuilds-users] Small error in google-go-lang SlackBuild Message-ID: <20120724130314.GB16311@leviathan.localdomain> Hi folks, I stumbled upon a tiny bug in the google-go-lang Slackbuild. If there is an $ARCH environment variable set, then the local variable $GARCH is not properly initialized. Patch attached. By the way, thanks to all maintainers and admins for the great work! Tobias P.S.: If this happens to be a double post, I apologize... I switched my subscription address and do not know if sending the mail actually works. -------------- next part -------------- *** original --- modified *************** *** 34,43 **** if [ -z "$ARCH" ]; then case "$( uname -m )" in ! i?86) ARCH=i486; GARCH=386 ;; ! x86_64) ARCH=x86_64; GARCH=amd64 ;; *) ARCH=$( uname -m ) ;; esac fi CWD=$(pwd) TMP=${TMP:-/tmp/SBo} --- 34,49 ---- if [ -z "$ARCH" ]; then case "$( uname -m )" in ! i?86) ARCH=i486 ;; ! x86_64) ARCH=x86_64 ;; *) ARCH=$( uname -m ) ;; esac fi + case "$ARCH" in + i?86) GARCH=386 ;; + x86_64) GARCH=amd64 ;; + *) ;; + esac + CWD=$(pwd) TMP=${TMP:-/tmp/SBo} From info at microlinux.fr Wed Jul 25 09:30:27 2012 From: info at microlinux.fr (Nicolas Kovacs) Date: Wed, 25 Jul 2012 11:30:27 +0200 Subject: [Slackbuilds-users] webcore-fonts vs. ARCH Message-ID: <500FBCB3.80709@microlinux.fr> Hi, I'm currently busy writing a series of SlackBuild scripts for a full-blown bells & whistles XFCE 4.8 desktop for Slackware 13.37. As an aside, let me state that slackbuilds.org is an extremely valuable resource for me. For almost every package, application, library, ... I have an existing SlackBuild script which I use as a starting point. I just built the 'webcore-fonts' package and noticed the ARCH stanza. As far as I understand, ARCH can be hardcoded for this package: ARCH=noarch Cheers from the sunny South of France, Niki PS: For the curious, here's the work in progress. $ svn co svn://svn.tuxfamily.org/svnroot/slackware/slick -- 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 klaatu at straightedgelinux.com Wed Jul 25 10:35:13 2012 From: klaatu at straightedgelinux.com (Klaatu) Date: Wed, 25 Jul 2012 06:35:13 -0400 Subject: [Slackbuilds-users] webcore-fonts vs. ARCH In-Reply-To: <500FBCB3.80709@microlinux.fr> References: <500FBCB3.80709@microlinux.fr> Message-ID: <201207250635.13987.klaatu@straightedgelinux.com> Sounds cool. Although did you know that the next Slackware release is pretty close and that XFCE 4.10 will be included in it? But anyway, the ARCH variable helps decides whether /usr/lib or /usr/lib64 is used when installing during the `make install` step, so setting it to "noarch" could be bad if you actually need to use /usr/lib* for anything in that particular script. But I imagine for fonts, you wouldn't be installing to lib so setting it to "noarch" would probably work. -klaatu > Hi, > > I'm currently busy writing a series of SlackBuild scripts for a > full-blown bells & whistles XFCE 4.8 desktop for Slackware 13.37. As an > aside, let me state that slackbuilds.org is an extremely valuable > resource for me. For almost every package, application, library, ... I > have an existing SlackBuild script which I use as a starting point. > > I just built the 'webcore-fonts' package and noticed the ARCH stanza. As > far as I understand, ARCH can be hardcoded for this package: > > ARCH=noarch > > Cheers from the sunny South of France, > > Niki > > PS: For the curious, here's the work in progress. > > $ svn co svn://svn.tuxfamily.org/svnroot/slackware/slick - klaatu From slava18 at gmail.com Wed Jul 25 10:46:06 2012 From: slava18 at gmail.com (V'yacheslav Stetskevych) Date: Wed, 25 Jul 2012 13:46:06 +0300 Subject: [Slackbuilds-users] webcore-fonts vs. ARCH In-Reply-To: <201207250635.13987.klaatu@straightedgelinux.com> References: <500FBCB3.80709@microlinux.fr> <201207250635.13987.klaatu@straightedgelinux.com> Message-ID: >> I'm currently busy writing a series of SlackBuild scripts for a >> full-blown bells & whistles XFCE 4.8 desktop for Slackware 13.37. Just a quote from http://slackware.osuosl.org/slackware-current/ChangeLog.txt Sun Jul 22 22:38:36 UTC 2012 Howdy! Lots of shiny stuff here, including the long awaited Xfce 4.10! Cheers! --Vyacheslav -- If you think of MS-DOS as mono, and Windows as stereo, then Linux is Dolby Digital and all the music is free... http://www.getgnulinux.org From info at microlinux.fr Wed Jul 25 11:09:43 2012 From: info at microlinux.fr (Nicolas Kovacs) Date: Wed, 25 Jul 2012 13:09:43 +0200 Subject: [Slackbuilds-users] webcore-fonts vs. ARCH In-Reply-To: <201207250635.13987.klaatu@straightedgelinux.com> References: <500FBCB3.80709@microlinux.fr> <201207250635.13987.klaatu@straightedgelinux.com> Message-ID: <500FD3F7.3010405@microlinux.fr> Le 25/07/2012 12:35, Klaatu a ?crit : > Sounds cool. Although did you know that the next Slackware release is pretty > close and that XFCE 4.10 will be included in it? Yes, I know this. So it will be easier for me to configure a full-blown XFCE desktop with Slackware 14.0. But in the meantime, I need something working for 13.37, since it's meant to be a replacement for my currently Debian+KDE-based "Microlinux Enterprise Desktop". See here for the details: * http://www.microlinux.fr/desktop_linux.php > > But anyway, the ARCH variable helps decides whether /usr/lib or /usr/lib64 is > used when installing during the `make install` step, so setting it to "noarch" > could be bad if you actually need to use /usr/lib* for anything in that > particular script. But I imagine for fonts, you wouldn't be installing to lib > so setting it to "noarch" would probably work. I know this. But if you take a peek at the script, you'll notice that there's no stuff in /usr/lib*, but only in /usr/share/fonts, which is architecture-agnostic. Cheers, 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 mjjzf at syntaktisk.dk Wed Jul 25 11:12:54 2012 From: mjjzf at syntaktisk.dk (=?UTF-8?Q?Morten_Juhl-Johansen_Z=C3=B6lde-Fej=C3=A9r?=) Date: Wed, 25 Jul 2012 13:12:54 +0200 Subject: [Slackbuilds-users] webcore-fonts vs. ARCH In-Reply-To: <500FD3F7.3010405@microlinux.fr> References: <500FBCB3.80709@microlinux.fr> <201207250635.13987.klaatu@straightedgelinux.com> <500FD3F7.3010405@microlinux.fr> Message-ID: <759e473428d894671dba56ef642e8f09@syntaktisk.dk> Mr. Workman has done this: http://connie.slackware.com/~rworkman/xfce-4.8/ - where the deps are included. I used it because I got confused with the build order! Yours, M On 25.07.2012 13:09, Nicolas Kovacs wrote: > Le 25/07/2012 12:35, Klaatu a ?crit : >> Sounds cool. Although did you know that the next Slackware release >> is pretty >> close and that XFCE 4.10 will be included in it? > > Yes, I know this. So it will be easier for me to configure a > full-blown XFCE desktop with Slackware 14.0. But in the meantime, I > need something working for 13.37, since it's meant to be a > replacement > for my currently Debian+KDE-based "Microlinux Enterprise Desktop". > See > here for the details: > > * http://www.microlinux.fr/desktop_linux.php > >> >> But anyway, the ARCH variable helps decides whether /usr/lib or >> /usr/lib64 is >> used when installing during the `make install` step, so setting it >> to "noarch" >> could be bad if you actually need to use /usr/lib* for anything in >> that >> particular script. But I imagine for fonts, you wouldn't be >> installing to lib >> so setting it to "noarch" would probably work. > > I know this. But if you take a peek at the script, you'll notice that > there's no stuff in /usr/lib*, but only in /usr/share/fonts, which is > architecture-agnostic. > > Cheers, > > Niki -- Morten Juhl-Johansen Z?lde-Fej?r http://syntaktisk.dk * mjjzf at syntaktisk.dk From auto327094 at hushmail.com Wed Jul 25 14:52:03 2012 From: auto327094 at hushmail.com (Ric Foust) Date: Wed, 25 Jul 2012 10:52:03 -0400 Subject: [Slackbuilds-users] Bad link for source on FLdigi Message-ID: <0d846308568e978e75948a0b152a255e@smtp.hushmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Slackbuilds, The source link for Fldigi no longer works. Also the latest Fldigi appears to be 3.21.49. Thanks RF Links: Slackbuild page: http://slackbuilds.org/repository/13.37/network/fldigi/ Slackbuilds Fldigi source link: http://www.w1hkj.com/downloads/fldigi/fldigi-3.21.33.tar.gz Fldigi homepage: http://www.w1hkj.com/Fldigi.html Fldigi download link: http://www.w1hkj.com/downloads/fldigi/ - -- You can not get anything worthwhile done without raising a sweat. -- The First Law Of Thermodynamics What ever you want is going to cost a little more than it is worth. -- The Second Law Of Thermodynamics You can not win the game, and you are not allowed to stop playing. -- The Third Law Of Thermodynamics -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAQCBMACgkQftiJ/ZUnSD0AJwCgpphE0zr8yHqdgBfGWWqk4YD+ i40AoJRQG3tgzqryqnd15Zt9hEXfi83A =w7s2 -----END PGP SIGNATURE----- From alien at slackbuilds.org Thu Jul 26 06:48:18 2012 From: alien at slackbuilds.org (Eric Hameleers (SBo)) Date: Thu, 26 Jul 2012 08:48:18 +0200 Subject: [Slackbuilds-users] Plans for jdk, jre In-Reply-To: <83064F45-E283-47B9-9F39-09698F655338@uq.edu.au> References: <83064F45-E283-47B9-9F39-09698F655338@uq.edu.au> Message-ID: <5010E832.3060301@slackbuilds.org> Op 20-7-2012 0:57, Christoph Willing schreef: > Since jre & jdk packages have been removed from -current, is anyone > already planning relevant 14.0 SlackBuilds for SBo? > > Alternatively is there a better strategy for making a jdk available > for those other SlackBuilds which assume its available? Alienbob's > recipe perhaps - or could he be persuaded to make an SBo SlackBuild > for it ...? > I won't be doing such a thing as adapting my own OpenJDK scripts for SBo. Nobody wants to compile OpenJDK from scratch, it takes way too long. Also, finding out all the source tarballs to use for a new release is not trivial. Either use my prebuilt packages, or do as Pat always did: download the official Oracle binaries and wrap them into a package. If anything, that would also have to be what a jdk.SlackBuild does if that gets hosted at slackbuilds.org. Perhaps I will even maintain the SBo version for that. Eric From info at microlinux.fr Thu Jul 26 07:43:19 2012 From: info at microlinux.fr (Nicolas Kovacs) Date: Thu, 26 Jul 2012 09:43:19 +0200 Subject: [Slackbuilds-users] webcore-fonts vs. ARCH In-Reply-To: <759e473428d894671dba56ef642e8f09@syntaktisk.dk> References: <500FBCB3.80709@microlinux.fr> <201207250635.13987.klaatu@straightedgelinux.com> <500FD3F7.3010405@microlinux.fr> <759e473428d894671dba56ef642e8f09@syntaktisk.dk> Message-ID: <5010F517.1060008@microlinux.fr> Le 25/07/2012 13:12, Morten Juhl-Johansen Z?lde-Fej?r a ?crit : > Mr. Workman has done this: > http://connie.slackware.com/~rworkman/xfce-4.8/ > - where the deps are included. I used it because I got confused with the > build order! Yeah, I know his work. I mainly used his SlackBuild script as a starting point. But I do add some tweaks, leave out some packages and build some others agains additional libs, so it was more simple to start again on my own (I'm not a "lazy Slacker", according to Salix' slogan :oD). Cheers, 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 rworkman at slackbuilds.org Fri Jul 27 19:38:54 2012 From: rworkman at slackbuilds.org (Robby Workman) Date: Fri, 27 Jul 2012 14:38:54 -0500 Subject: [Slackbuilds-users] Bad link for source on FLdigi In-Reply-To: <0d846308568e978e75948a0b152a255e@smtp.hushmail.com> References: <0d846308568e978e75948a0b152a255e@smtp.hushmail.com> Message-ID: <20120727143854.0b064a6d@liberty.rlwhome.lan> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 25 Jul 2012 10:52:03 -0400 Ric Foust wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Slackbuilds, > > The source link for Fldigi no longer works. Also the latest > Fldigi appears to be 3.21.49. CC'ing JK Wood on this... - -RW -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlAS7k4ACgkQvGy9tf6lsvu8SgCffWRhIPssweytiUZlEC93A9+n ehgAn0VdrasHWIrZMamPXP/ARgcqn/Q9 =TpSe -----END PGP SIGNATURE----- From rworkman at slackbuilds.org Fri Jul 27 19:40:20 2012 From: rworkman at slackbuilds.org (Robby Workman) Date: Fri, 27 Jul 2012 14:40:20 -0500 Subject: [Slackbuilds-users] webcore-fonts vs. ARCH In-Reply-To: <500FBCB3.80709@microlinux.fr> References: <500FBCB3.80709@microlinux.fr> Message-ID: <20120727144020.2c0e93e6@liberty.rlwhome.lan> On Wed, 25 Jul 2012 11:30:27 +0200 Nicolas Kovacs wrote: > I'm currently busy writing a series of SlackBuild scripts for a > full-blown bells & whistles XFCE 4.8 desktop for Slackware 13.37. As > an aside, let me state that slackbuilds.org is an extremely valuable > resource for me. For almost every package, application, library, ... > I have an existing SlackBuild script which I use as a starting point. > > I just built the 'webcore-fonts' package and noticed the ARCH stanza. > As far as I understand, ARCH can be hardcoded for this package: > > ARCH=noarch I'm not sure what you're seeing, but it looks correct in my git checkout here... -RW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From rworkman at slackbuilds.org Fri Jul 27 19:44:56 2012 From: rworkman at slackbuilds.org (Robby Workman) Date: Fri, 27 Jul 2012 14:44:56 -0500 Subject: [Slackbuilds-users] Small error in google-go-lang SlackBuild In-Reply-To: <20120724130314.GB16311@leviathan.localdomain> References: <20120724130314.GB16311@leviathan.localdomain> Message-ID: <20120727144456.1fec4fd1@liberty.rlwhome.lan> On Tue, 24 Jul 2012 15:03:14 +0200 Tobias Columbus wrote: > Hi folks, > > I stumbled upon a tiny bug in the google-go-lang Slackbuild. > If there is an $ARCH environment variable set, then the local variable > $GARCH is not properly initialized. Patch attached. I just committed this into a misc-fixes branch, which will be merged with the next public update. -RW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From joshuakwood at gmail.com Fri Jul 27 21:22:28 2012 From: joshuakwood at gmail.com (JK Wood) Date: Fri, 27 Jul 2012 16:22:28 -0500 Subject: [Slackbuilds-users] Bad link for source on FLdigi In-Reply-To: <20120727143854.0b064a6d@liberty.rlwhome.lan> References: <0d846308568e978e75948a0b152a255e@smtp.hushmail.com> <20120727143854.0b064a6d@liberty.rlwhome.lan> Message-ID: On Fri, Jul 27, 2012 at 2:38 PM, Robby Workman wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Wed, 25 Jul 2012 10:52:03 -0400 > Ric Foust wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > Slackbuilds, > > > > The source link for Fldigi no longer works. Also the latest > > Fldigi appears to be 3.21.49. > > > CC'ing JK Wood on this... > > - -RW > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.12 (GNU/Linux) > > iEYEARECAAYFAlAS7k4ACgkQvGy9tf6lsvu8SgCffWRhIPssweytiUZlEC93A9+n > ehgAn0VdrasHWIrZMamPXP/ARgcqn/Q9 > =TpSe > -----END PGP SIGNATURE----- > 1) I love that signature, Ric. 2) Sorry about that. I've been a little lax on my SlackBuild updates lately - I've moved three times in the past year, and have had some other life events in between. I'll try to get a new build submitted this evening, as well as updating the rest of my SlackBuilds. -------------- next part -------------- An HTML attachment was scrubbed... URL: From joshuakwood at gmail.com Fri Jul 27 22:55:36 2012 From: joshuakwood at gmail.com (JK Wood) Date: Fri, 27 Jul 2012 17:55:36 -0500 Subject: [Slackbuilds-users] Bad link for source on FLdigi In-Reply-To: References: <0d846308568e978e75948a0b152a255e@smtp.hushmail.com> <20120727143854.0b064a6d@liberty.rlwhome.lan> Message-ID: On Fri, Jul 27, 2012 at 4:22 PM, JK Wood wrote: > > > On Fri, Jul 27, 2012 at 2:38 PM, Robby Workman wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> On Wed, 25 Jul 2012 10:52:03 -0400 >> Ric Foust wrote: >> >> > -----BEGIN PGP SIGNED MESSAGE----- >> > Hash: SHA1 >> > >> > Slackbuilds, >> > >> > The source link for Fldigi no longer works. Also the latest >> > Fldigi appears to be 3.21.49. >> >> >> CC'ing JK Wood on this... >> >> - -RW >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.12 (GNU/Linux) >> >> iEYEARECAAYFAlAS7k4ACgkQvGy9tf6lsvu8SgCffWRhIPssweytiUZlEC93A9+n >> ehgAn0VdrasHWIrZMamPXP/ARgcqn/Q9 >> =TpSe >> -----END PGP SIGNATURE----- >> > > 1) I love that signature, Ric. > > 2) Sorry about that. I've been a little lax on my SlackBuild updates > lately - I've moved three times in the past year, and have had some other > life events in between. I'll try to get a new build submitted this > evening, as well as updating the rest of my SlackBuilds. > As anyone who has been paying any attention at all would know, I am unable to submit a new script, since submissions are closed in anticipation of the release of 14.0. Anyone who wants an updated build script for fldigi can find it at my Github repo (a fork of the official SlackBuilds.org repo) at https://github.com/JKtheSlacker/slackbuilds. Do note that you'll want the 'jkwood' branch if you download through git. You'll still want that branch if you just pull it from the website. I also moved it from the 'network' category to the 'ham' category, as it more properly belongs there. -------------- next part -------------- An HTML attachment was scrubbed... URL: From serban.udrea at skmail.ikp.physik.tu-darmstadt.de Tue Jul 31 09:40:14 2012 From: serban.udrea at skmail.ikp.physik.tu-darmstadt.de (Serban Udrea) Date: Tue, 31 Jul 2012 11:40:14 +0200 Subject: [Slackbuilds-users] Lapack SlackBuild In-Reply-To: <20120722182912.1053277ruk7hu3fc@omnitude.net> References: <20120718150006.143472qapd368ceu@webmail.omnitude.net> <50068748.8000106@skmail.ikp.physik.tu-darmstadt.de> <20120718232300.35614egdh0v73t10@omnitude.net> <5006CD59.9040002@skmail.ikp.physik.tu-darmstadt.de> <20120719133611.17074td0ti0j73jf@webmail.omnitude.net> <5007D7BB.4050702@skmail.ikp.physik.tu-darmstadt.de> <20120719215357.28075ul4li9fj2ad@omnitude.net> <500AB6BF.8060604@skmail.ikp.physik.tu-darmstadt.de> <20120722182912.1053277ruk7hu3fc@omnitude.net> Message-ID: <5017A7FE.2020607@skmail.ikp.physik.tu-darmstadt.de> On 07/22/2012 10:29 AM, James Smith wrote: > ... > Yeah, I think that's for the best- I'm new to the Lapack game and don't > use the library directly. Besides, Serban already maintains the others ;-) > ... Hello! Thus, I'll take them over and submit the change as soon as this is possible again. Best regards, Serban PS. Sorry for the late confirmation! From rworkman at slackbuilds.org Tue Jul 31 15:49:01 2012 From: rworkman at slackbuilds.org (Robby Workman) Date: Tue, 31 Jul 2012 10:49:01 -0500 Subject: [Slackbuilds-users] Lapack SlackBuild In-Reply-To: <5017A7FE.2020607@skmail.ikp.physik.tu-darmstadt.de> References: <20120718150006.143472qapd368ceu@webmail.omnitude.net> <50068748.8000106@skmail.ikp.physik.tu-darmstadt.de> <20120718232300.35614egdh0v73t10@omnitude.net> <5006CD59.9040002@skmail.ikp.physik.tu-darmstadt.de> <20120719133611.17074td0ti0j73jf@webmail.omnitude.net> <5007D7BB.4050702@skmail.ikp.physik.tu-darmstadt.de> <20120719215357.28075ul4li9fj2ad@omnitude.net> <500AB6BF.8060604@skmail.ikp.physik.tu-darmstadt.de> <20120722182912.1053277ruk7hu3fc@omnitude.net> <5017A7FE.2020607@skmail.ikp.physik.tu-darmstadt.de> Message-ID: <20120731104901.44bf7b32@liberty.rlwhome.lan> On Tue, 31 Jul 2012 11:40:14 +0200 Serban Udrea wrote: > On 07/22/2012 10:29 AM, James Smith wrote: > > ... > > Yeah, I think that's for the best- I'm new to the Lapack game and > > don't use the library directly. Besides, Serban already maintains > > the others ;-) ... > > Hello! > > Thus, I'll take them over and submit the change as soon as this is > possible again. > Send me a patch (or patchset) using "git format-patch" and I'll take care of it - this needs to be addressed before 14.0 releases. -RW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From ppetrov at mail.student.oulu.fi Tue Jul 31 18:37:54 2012 From: ppetrov at mail.student.oulu.fi (Petar Petrov) Date: Tue, 31 Jul 2012 21:37:54 +0300 Subject: [Slackbuilds-users] Slackware 14 In-Reply-To: <20120731104901.44bf7b32@liberty.rlwhome.lan> References: <20120718150006.143472qapd368ceu@webmail.omnitude.net> <50068748.8000106@skmail.ikp.physik.tu-darmstadt.de> <20120718232300.35614egdh0v73t10@omnitude.net> <5006CD59.9040002@skmail.ikp.physik.tu-darmstadt.de> <20120719133611.17074td0ti0j73jf@webmail.omnitude.net> <5007D7BB.4050702@skmail.ikp.physik.tu-darmstadt.de> <20120719215357.28075ul4li9fj2ad@omnitude.net> <500AB6BF.8060604@skmail.ikp.physik.tu-darmstadt.de> <20120722182912.1053277ruk7hu3fc@omnitude.net> <5017A7FE.2020607@skmail.ikp.physik.tu-darmstadt.de> <20120731104901.44bf7b32@liberty.rlwhome.lan> Message-ID: <20120731213754.1ebgfcgzqn8gg4w8@webmail.oulu.fi> Hi to all Since I joined SBo a year ago and have so far maintained scripts for only one Slackware release, I have the following question: What shall I do before the new Slackware release comes out? Am I supposed to start testing my slackbuilds when Slackware -current becomes RC1? Then if something needs patching, submit an update? The upload form is closed now, so what are you guys up to? Sorry if the questions sound silly, I read the mailing lists archives from a year ago when Slackware became 13.37, but did not find an answer. Regards, Petar From alien at slackbuilds.org Tue Jul 31 20:41:10 2012 From: alien at slackbuilds.org (Eric Hameleers) Date: Tue, 31 Jul 2012 22:41:10 +0200 Subject: [Slackbuilds-users] Slackware 14 In-Reply-To: <20120731213754.1ebgfcgzqn8gg4w8@webmail.oulu.fi> References: <20120718150006.143472qapd368ceu@webmail.omnitude.net> <50068748.8000106@skmail.ikp.physik.tu-darmstadt.de> <20120718232300.35614egdh0v73t10@omnitude.net> <5006CD59.9040002@skmail.ikp.physik.tu-darmstadt.de> <20120719133611.17074td0ti0j73jf@webmail.omnitude.net> <5007D7BB.4050702@skmail.ikp.physik.tu-darmstadt.de> <20120719215357.28075ul4li9fj2ad@omnitude.net> <500AB6BF.8060604@skmail.ikp.physik.tu-darmstadt.de> <20120722182912.1053277ruk7hu3fc@omnitude.net> <5017A7FE.2020607@skmail.ikp.physik.tu-darmstadt.de> <20120731104901.44bf7b32@liberty.rlwhome.lan> <20120731213754.1ebgfcgzqn8gg4w8@webmail.oulu.fi> Message-ID: <501842E6.7060002@slackbuilds.org> On 07/31/2012 08:37 PM, Petar Petrov wrote: > Hi to all > > Since I joined SBo a year ago and have so far maintained scripts for > only one Slackware release, I have the following question: What shall > I do before the new Slackware release comes out? Am I supposed to > start testing my slackbuilds when Slackware -current becomes RC1? Then > if something needs patching, submit an update? The upload form is > closed now, so what are you guys up to? > > Sorry if the questions sound silly, I read the mailing lists archives > from a year ago when Slackware became 13.37, but did not find an answer. > > Regards, > > Petar Yes, that is the idea. If you test your SlackBuilds against Slackware 14 RC and report success (or send us updates) then that will help the admins immensely in getting a Slackware 14 repository live at the time of release. You will have noticed that with every new Slackware release, several SlackBuilds.org entries will disappear. The reason for this is that the maintainer has not reported whether his submission(s) work for the new release. The SlackBuild database is so big these days that the admins can no longer test all the scripts in the short time between closing the submissions form and the new Slackware release. We rely on the maintainers to tell us it's OK to copy scripts from one to the next database. Cheers, Eric From gilcio.amaral at gmail.com Tue Jul 31 21:23:47 2012 From: gilcio.amaral at gmail.com (Gilcio Amaral-Martins) Date: Tue, 31 Jul 2012 18:23:47 -0300 Subject: [Slackbuilds-users] Slackware 14 In-Reply-To: <501842E6.7060002@slackbuilds.org> References: <20120718150006.143472qapd368ceu@webmail.omnitude.net> <50068748.8000106@skmail.ikp.physik.tu-darmstadt.de> <20120718232300.35614egdh0v73t10@omnitude.net> <5006CD59.9040002@skmail.ikp.physik.tu-darmstadt.de> <20120719133611.17074td0ti0j73jf@webmail.omnitude.net> <5007D7BB.4050702@skmail.ikp.physik.tu-darmstadt.de> <20120719215357.28075ul4li9fj2ad@omnitude.net> <500AB6BF.8060604@skmail.ikp.physik.tu-darmstadt.de> <20120722182912.1053277ruk7hu3fc@omnitude.net> <5017A7FE.2020607@skmail.ikp.physik.tu-darmstadt.de> <20120731104901.44bf7b32@liberty.rlwhome.lan> <20120731213754.1ebgfcgzqn8gg4w8@webmail.oulu.fi> <501842E6.7060002@slackbuilds.org> Message-ID: Hi Eric, I've tested my slackbuilds against slack 14. Submissions page is closed. How can I send the updates? Gilcio 2012/7/31 Eric Hameleers > On 07/31/2012 08:37 PM, Petar Petrov wrote: > > Hi to all > > > > Since I joined SBo a year ago and have so far maintained scripts for > > only one Slackware release, I have the following question: What shall > > I do before the new Slackware release comes out? Am I supposed to > > start testing my slackbuilds when Slackware -current becomes RC1? Then > > if something needs patching, submit an update? The upload form is > > closed now, so what are you guys up to? > > > > Sorry if the questions sound silly, I read the mailing lists archives > > from a year ago when Slackware became 13.37, but did not find an answer. > > > > Regards, > > > > Petar > Yes, that is the idea. > If you test your SlackBuilds against Slackware 14 RC and report success > (or send us updates) then that will help the admins immensely in getting > a Slackware 14 repository live at the time of release. > > You will have noticed that with every new Slackware release, several > SlackBuilds.org entries will disappear. The reason for this is that the > maintainer has not reported whether his submission(s) work for the new > release. The SlackBuild database is so big these days that the admins > can no longer test all the scripts in the short time between closing the > submissions form and the new Slackware release. We rely on the > maintainers to tell us it's OK to copy scripts from one to the next > database. > > Cheers, Eric > _______________________________________________ > 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: