From ilgar_eroglu at yahoo.com Fri May 1 11:15:17 2009 From: ilgar_eroglu at yahoo.com (Kemal Ilgar Eroglu) Date: Fri, 1 May 2009 04:15:17 -0700 (PDT) Subject: [Slackbuilds-users] Missing .info in Phalanx Message-ID: <955420.12118.qm@web58203.mail.re3.yahoo.com> Hi all, It looks like the .info file is missing from the package Phalanx (chess engine, under games/). Trying to build it causes sbopkg to quit with error cp: cannot stat `./games/Phalanx/Phalanx.info': No such file or directory /usr/bin/sbopkg: line 2364: ./games/Phalanx/Phalanx.info.build: No such file or directory Just wanted to bring it to the maintainer's attention... Cheers, Ilgar From melmothx at gmail.com Fri May 1 11:33:21 2009 From: melmothx at gmail.com (Marco Pessotto) Date: Fri, 1 May 2009 13:33:21 +0200 Subject: [Slackbuilds-users] Missing .info in Phalanx In-Reply-To: <955420.12118.qm@web58203.mail.re3.yahoo.com> References: <955420.12118.qm@web58203.mail.re3.yahoo.com> Message-ID: <20090501113320.GA5917@universe> On Fri, May 01, 2009 at 04:15:17AM -0700, Kemal Ilgar Eroglu wrote: > > Hi all, > > It looks like the .info file is missing from the package Phalanx (chess engine, under games/). Trying to build it causes sbopkg to quit with error > > cp: cannot stat `./games/Phalanx/Phalanx.info': No such file or directory > /usr/bin/sbopkg: line 2364: ./games/Phalanx/Phalanx.info.build: No such file or directory > > Just wanted to bring it to the maintainer's attention... > > Cheers, > Ilgar It looks like sbopkg gets confused by the lowercase. The actual name of the .info file is phalanx.info. Should I uppercase this and repost? Cheers -- Marco From xgizzmo at slackbuilds.org Fri May 1 11:37:57 2009 From: xgizzmo at slackbuilds.org (xgizzmo at slackbuilds.org) Date: Fri, 1 May 2009 07:37:57 -0400 Subject: [Slackbuilds-users] Missing .info in Phalanx In-Reply-To: <955420.12118.qm@web58203.mail.re3.yahoo.com> References: <955420.12118.qm@web58203.mail.re3.yahoo.com> Message-ID: <200905010737.57600.xgizzmo@slackbuilds.org> On Friday 01 May 2009 07:15:17 Kemal Ilgar Eroglu wrote: > > cp: cannot stat `./games/Phalanx/Phalanx.info': No such file or directory > /usr/bin/sbopkg: line 2364: ./games/Phalanx/Phalanx.info.build: No such file or directory > > Just wanted to bring it to the maintainer's attention... > > Cheers, > Ilgar > Fixed renamed phalanx.info to Phalanx.info. --dsomero From melmothx at gmail.com Fri May 1 11:38:51 2009 From: melmothx at gmail.com (Marco Pessotto) Date: Fri, 1 May 2009 13:38:51 +0200 Subject: [Slackbuilds-users] Missing .info in Phalanx In-Reply-To: <200905010737.57600.xgizzmo@slackbuilds.org> References: <955420.12118.qm@web58203.mail.re3.yahoo.com> <200905010737.57600.xgizzmo@slackbuilds.org> Message-ID: <20090501113851.GA6164@universe> On Fri, May 01, 2009 at 07:37:57AM -0400, xgizzmo at slackbuilds.org wrote: > Fixed renamed phalanx.info to Phalanx.info. > > --dsomero Thank you -- Marco From ilgar_eroglu at yahoo.com Fri May 1 23:00:40 2009 From: ilgar_eroglu at yahoo.com (Kemal Ilgar Eroglu) Date: Fri, 1 May 2009 16:00:40 -0700 (PDT) Subject: [Slackbuilds-users] gnubg link broken Message-ID: <906037.58307.qm@web58207.mail.re3.yahoo.com> Hi all, Here's my second bugreport from the games/ section today: The source package link for gnubg is broken. The current script attempts to download http://www.gnubg.org/media/sources/gnubg-source-SNAPSHOT-20090125.tar.gz but this file doesn't exist. On the gnubg site there are a few SVN snapshots from Jan 2009 or later. I modified my local script to use gnubg-source-SNAPSHOT-20090501.tar.gz and it works well. Cheers, Ilgar From erik at slackbuilds.org Sat May 2 00:08:15 2009 From: erik at slackbuilds.org (Erik Hanson) Date: Fri, 1 May 2009 19:08:15 -0500 Subject: [Slackbuilds-users] gnubg link broken In-Reply-To: <906037.58307.qm@web58207.mail.re3.yahoo.com> References: <906037.58307.qm@web58207.mail.re3.yahoo.com> Message-ID: <20090501190815.7feb243f@shaggy.scooby> On May 01, 2009, at 4:00 PM, Kemal Ilgar Eroglu wrote: > http://www.gnubg.org/media/sources/gnubg-source-SNAPSHOT-20090125.tar.gz > > but this file doesn't exist. On the gnubg site there are a few SVN snapshots > from Jan 2009 or later. I modified my local script to use > gnubg-source-SNAPSHOT-20090501.tar.gz and it works well. Thanks, I've submitted an update. -- Erik Hanson http://slackbuilds.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From audrius at neutrino.lt Sat May 2 08:40:37 2009 From: audrius at neutrino.lt (Audrius =?utf-8?Q?Ka=C5=BEukauskas?=) Date: Sat, 2 May 2009 11:40:37 +0300 Subject: [Slackbuilds-users] nicotine-plus and psyco Message-ID: <20090502084037.GA2511@kiras.geris> Hi, Just a couple of small observations: 1) full path to icon needs to be provided for nicotine-plus in its .desktop file, otherwise KDE4 won't find it; 2) it would be more appropriate for psyco to use i486 as ARCH -- after all it's a C extension, not an ordinary Python code; -- Audrius Ka?ukauskas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From dave at frop.net Sat May 2 23:34:06 2009 From: dave at frop.net (David Miller) Date: Sat, 2 May 2009 18:34:06 -0500 Subject: [Slackbuilds-users] spf breaks submission form email validation Message-ID: <20090502233406.GB7998@pretender.frop.net> Hi, my mailserver rejects whatever valid email check the submission form does. It appears that the test message comes FROM the same adress that it is TO. Since I am using spf, the mail is rejected because I publish an spf record that says only my machines may send mail from my domain. here's what I get in the log Received-SPF: fail (pretender.frop .net: SPF record at frop.net does not designate 208.67.159.178 as permitted sender) It seems like the valid email checker should use a from address other than the destination address. I was able to submit my slackbuild under another address. Thanks. -- David Miller dave at frop.net http://dave.frop.net/ Saturday 5/2/09 6:34pm CDT From xgizzmo at slackbuilds.org Sun May 3 13:36:48 2009 From: xgizzmo at slackbuilds.org (xgizzmo at slackbuilds.org) Date: Sun, 3 May 2009 09:36:48 -0400 Subject: [Slackbuilds-users] Updates - 20090503 Message-ID: <200905030936.48851.xgizzmo@slackbuilds.org> Sun May 3 11:48:43 UTC 2009 academic/stellarium: Updated for version 0.10.2. Thanks to Alan Alberghini. --dsomero desktop/enlightenment: Updated for version 0.16.999.060. Thanks to Aleksandar Samardzic. --dsomero desktop/wmbiff: Added a sample config. Thanks to Cezary M. Kruk. --dsomero desktop/wmmixer: Added a sample config. Thanks to Cezary M. Kruk. --dsomero development/Cython: Updated for version 0.11.1. Thanks to Larry Hajali. --dsomero development/acpica: Updated for version 20090422. Thanks to Heinz Wiesinger. --dsomero development/apache-maven: Updated for version 2.1.0. Thanks to Heinz Wiesinger. --dsomero development/colordiff: Updated for version 1.0.9. Thanks to Grigorios Bouzakis. --dsomero development/egenix-mx-base: Updated for version 3.1.2. Thanks to Heinz Wiesinger. --dsomero development/jbigkit: Updated for version 2.0. Thanks to Iskar Enev. --dsomero development/pyparsing: Updated for version 1.5.2. Thanks to Heinz Wiesinger. --dsomero development/yasm: Updated for version 0.8.0. Thanks to Heinz Wiesinger. --dsomero games/desmume: Updated for version 0.9.2. Thanks to Larry Hajali. --dsomero games/xbill: Updated for version 2.1. Thanks to Menno E. Duursma. --dsomero games/xmoto: Updated for version 0.5.1. Thanks to Alex Word. --dsomero graphics/rawstudio: Updated for version 1.2. Thanks to Nishant Limbachia. --rworkman libraries/cryptopp: Updated for version 5.6.0. Thanks to Iskar Enev. --dsomero libraries/e_dbus: Updated for version 0.5.0.060. Thanks to Aleksandar Samardzic. --dsomero libraries/ecore: Updated for version 0.9.9.060. Thanks to Aleksandar Samardzic. --dsomero libraries/edje: Updated for version 0.9.92.060. Thanks to Aleksandar Samardzic. --dsomero libraries/eet: Updated for version 1.2.0. Thanks to Aleksandar Samardzic. --dsomero libraries/efreet: Updated for version 0.5.0.060. Thanks to Aleksandar Samardzic. --dsomero libraries/eina: Added - eina is a multi-platform library that provides optimized data types and a few tools that could be used for projects. Thanks to Aleksandar Samardzic. --dsomero libraries/embryo: Updated for version 0.9.9.060. Thanks to Aleksandar Samardzic. --dsomero libraries/evas: Updated for version 0.9.9.060. Thanks to Aleksandar Samardzic. --dsomero libraries/iso-codes: Updated for version 3.8. Thanks to Heinz Wiesinger. --dsomero libraries/libarchive: Updated for version 2.7.0. Thanks to Heinz Wiesinger. --dsomero libraries/libv4l: Updated for version 0.5.97. Thanks to Mauro Giachero. --dsomero libraries/libzrtpcpp: Updated for version 1.4.3. Thanks to Mauro Giachero. --dsomero misc/kvm: Updated for version 85. Thanks to Murat D. Kadirov. --dsomero multimedia/gpodder: Updated for version 0.15.2. Thanks to Chess Griffin. --dsomero network/dnstop: Updated for version 20080502. Thanks to Menno Duursma. --dsomero network/dnstracer: Updated for version 1.9. Thanks to Menno Duursma. --dsomero network/dynamips: Added - dynamips is intended as as a training platform for Cisco devices. Thanks to Alam Guntur Nugroho. --rworkman network/iperf: Updated contact info. Thanks to nullboy. --dsomero network/iw: Updated for version 0.9.13. Thanks to nullboy. --dsomero network/mod_limitipconn: Updated for version 0.23. Thanks to Menno Duursma. --dsomero network/shorewall-common: Updated for version 4.2.8. Thanks to Gregory Tourte. --dsomero network/shorewall-perl: Updated for version 4.2.8.2. Thanks to Gregory Tourte. --dsomero network/shorewall-shell: Updated for version 4.2.8. Thanks to Gregory Tourte. --dsomero network/shorewall6: Updated for version 4.2.8. Thanks to Gregory Tourte. --dsomero network/transmission: Updated for version 1.52. Thanks to Iskar Enev. --dsomero network/twinkle: Updated for version 1.4.2. Thanks to Mauro Giachero. --dsomero network/unfs3: Updated for version 0.9.22. Thanks to Menno Duursma. --dsomero office/scribus: Updated for version 1.3.3.13. Thanks to Heinz Wiesinger. --dsomero system/fish: Updated for version 1.23.0. Thanks to Pierre Cazenave. --dsomero system/p7zip: Updated for version 4.65. Thanks to Heinz Wiesinger. --dsomero system/vice: Updated for version 2.1. Thanks to Mauro Giachero. --dsomero From rworkman at slackbuilds.org Mon May 4 03:33:30 2009 From: rworkman at slackbuilds.org (Robby Workman) Date: Sun, 3 May 2009 22:33:30 -0500 Subject: [Slackbuilds-users] nicotine-plus and psyco In-Reply-To: <20090502084037.GA2511@kiras.geris> References: <20090502084037.GA2511@kiras.geris> Message-ID: <20090503223330.083760a6@liberty.rlwhome.lan> On Sat, 2 May 2009 11:40:37 +0300 Audrius Ka?ukauskas wrote: > Hi, > > Just a couple of small observations: > > 1) full path to icon needs to be provided for nicotine-plus in its > .desktop file, otherwise KDE4 won't find it; This should not be necessary *if* the following criteria is met: 1. the icon should be in one of the standard directories -- /usr/share/pixmaps, /usr/share/icons/$theme/ 2. the icon is called like this in the .desktop file: Icon=iconname 3. the icon's full name is "iconname.png" If one of these is messed up, please mail the maintainer and ask him/her to fix it. > 2) it would be more appropriate for psyco to use i486 as ARCH -- after > all it's a C extension, not an ordinary Python code; Agreed. We've got quite a few of those wrong and are fixing them as we come across them for other reasons. Please mail the maintainer and ask him/her to submit an update. -RW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From erik at slackbuilds.org Mon May 4 03:59:28 2009 From: erik at slackbuilds.org (Erik Hanson) Date: Sun, 3 May 2009 22:59:28 -0500 Subject: [Slackbuilds-users] spf breaks submission form email validation In-Reply-To: <20090502233406.GB7998@pretender.frop.net> References: <20090502233406.GB7998@pretender.frop.net> Message-ID: <20090503225928.09aeaaff@shaggy.scooby> On May 02, 2009, at 6:34 PM, David Miller wrote: > Hi, Hello, > It seems like the valid email checker should use a from address other than > the destination address. I've taken care of it, manually tested against your MX and it should work now. Thanks for the report. -- Erik Hanson http://slackbuilds.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From slackware.wagnerm at arcor.de Mon May 4 07:44:18 2009 From: slackware.wagnerm at arcor.de (Michael Wagner) Date: Mon, 04 May 2009 09:44:18 +0200 Subject: [Slackbuilds-users] Orphan packages Message-ID: <49FE9CD2.70702@arcor.de> Dear list, I would like to orphan the following packages: lxpanel gnubiff moc Feel free to adopt them, Michael From adamsonj at email.unc.edu Mon May 4 14:44:13 2009 From: adamsonj at email.unc.edu (Joel J. Adamson ) Date: Mon, 04 May 2009 10:44:13 -0400 Subject: [Slackbuilds-users] Orphan packages In-Reply-To: <49FE9CD2.70702@arcor.de> References: <49FE9CD2.70702@arcor.de> Message-ID: <6636.1241448253@email.unc.edu> >>>>> "Michael" == Michael Wagner writes: Michael> gnubiff I will adopt gnubiff. Happy to help, Joel -- Joel J. Adamson -- http://www.unc.edu/~adamsonj University of North Carolina at Chapel Hill CB #3280, Coker Hall Chapel Hill, NC 27599-3280 From slacker6896 at gmail.com Mon May 4 15:31:48 2009 From: slacker6896 at gmail.com (seb seb) Date: Mon, 4 May 2009 17:31:48 +0200 Subject: [Slackbuilds-users] email address rejected Message-ID: Hi, I tried to post a new version of a SlackBuild that I maintain but when I click "Upload File", I have a message that said that my address has been rejected by mx.libertysurf.net. I have tried with another addresses, but none of them work. Could you correct this problem for my main address (phenixi [at] aliceadsl [dot] fr) and for the one used to send this message (slacker6896 [at] gmail [dot] com) Thanks ;-) -- SeB -------------- next part -------------- An HTML attachment was scrubbed... URL: From pprkut at liwjatan.at Mon May 4 20:49:41 2009 From: pprkut at liwjatan.at (Heinz Wiesinger) Date: Mon, 4 May 2009 22:49:41 +0200 Subject: [Slackbuilds-users] Nvidia driver 180.29 In-Reply-To: <200904260202.37096.pprkut@liwjatan.at> References: <20090425203734.GA3268@dark> <200904260202.37096.pprkut@liwjatan.at> Message-ID: <200905042249.43565.pprkut@liwjatan.at> On Sunday 26 April 2009 02:02:30 Heinz Wiesinger wrote: > On Saturday 25 April 2009 22:37:34 Grigorios Bouzakis wrote: > > Hi, > > i read the following article on lwn the other day > > http://lwn.net/Articles/329529/ , and today i noticed that the nvidia > > script in SBo is building this version. Maybe it would be wise to upgrade > > to some later version? I am using 180.44 at the moment. > > I have an update for 180.51 ready. If I don't experience any problems on my > system the next few days, I'm going to submit it soon. I had a few severe > crashes with 180.44, which is why it isn't on SBo. Unfortunately my issues remained :/. I have thought about this some time now and decided to go with 180.29, but noting the issue it has in the README might be a good idea. Grs, Heinz -------------- next part -------------- An HTML attachment was scrubbed... URL: From chaos.proton at gmail.com Tue May 5 13:18:55 2009 From: chaos.proton at gmail.com (Grissiom) Date: Tue, 5 May 2009 21:18:55 +0800 Subject: [Slackbuilds-users] invalid search result Message-ID: <200905052118.56888.chaos.proton@gmail.com> Hi list, When I search "adobe" in slackbuilds,org, I got a invalid link: http://slackbuilds.org/repository/12.2/office/acroread/ which listed as the first one of the search result. -------------- next part -------------- An HTML attachment was scrubbed... URL: From slacker6896 at gmail.com Tue May 5 18:46:45 2009 From: slacker6896 at gmail.com (Sebastien BALLET) Date: Tue, 5 May 2009 20:46:45 +0200 Subject: [Slackbuilds-users] invalid search result In-Reply-To: <200905052118.56888.chaos.proton@gmail.com> References: <200905052118.56888.chaos.proton@gmail.com> Message-ID: Hi, > When I search "adobe" in slackbuilds,org, I got a invalid link: > http://slackbuilds.org/repository/12.2/office/acroread/ acroread has been replaced by adobe-reader : http://slackbuilds.org/repository/12.2/office/adobe-reader/ -- SeB From timp at timp.com.au Tue May 5 21:20:06 2009 From: timp at timp.com.au (Timothy Pollard) Date: Wed, 6 May 2009 07:20:06 +1000 Subject: [Slackbuilds-users] invalid search result In-Reply-To: References: <200905052118.56888.chaos.proton@gmail.com> Message-ID: <20090506072006.24abf983@shammah.timp.com.au> On Tue, 5 May 2009 20:46:45 +0200 Sebastien BALLET wrote: > Hi, > > > When I search "adobe" in slackbuilds,org, I got a invalid link: > > http://slackbuilds.org/repository/12.2/office/acroread/ > > acroread has been replaced by adobe-reader : > http://slackbuilds.org/repository/12.2/office/adobe-reader/ > That, I suspect, is the problem. acroread is still showing up in the search results, http://slackbuilds.org/result/?search=adobe&sv=12.2, which shouldn't be happening. -- TimP [http://blog.timp.com.au] -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From xgizzmo at slackbuilds.org Tue May 5 23:20:53 2009 From: xgizzmo at slackbuilds.org (xgizzmo at slackbuilds.org) Date: Tue, 5 May 2009 19:20:53 -0400 Subject: [Slackbuilds-users] invalid search result In-Reply-To: <20090506072006.24abf983@shammah.timp.com.au> References: <200905052118.56888.chaos.proton@gmail.com> <20090506072006.24abf983@shammah.timp.com.au> Message-ID: <200905051920.54095.xgizzmo@slackbuilds.org> On Tuesday 05 May 2009 17:20:06 Timothy Pollard wrote: > On Tue, 5 May 2009 20:46:45 +0200 > Sebastien BALLET wrote: > > Hi, > > > > > When I search "adobe" in slackbuilds,org, I got a invalid link: > > > http://slackbuilds.org/repository/12.2/office/acroread/ > > > > acroread has been replaced by adobe-reader : > > http://slackbuilds.org/repository/12.2/office/adobe-reader/ > > > > That, I suspect, is the problem. acroread is still showing up in the search > results, http://slackbuilds.org/result/?search=adobe&sv=12.2, which shouldn't be > happening. > Thanks for the report, I removed the orphaned database entry. --dsomero From rworkman at slackbuilds.org Thu May 7 04:46:32 2009 From: rworkman at slackbuilds.org (Robby Workman) Date: Thu, 7 May 2009 04:46:32 +0000 Subject: [Slackbuilds-users] Updates - 20090507 Message-ID: <20090507044632.GA18561@slackbuilds.org> Thu May 7 04:44:29 UTC 2009 academic/galculator: Updated for version 1.3.4. Thanks to Frank Caraballo. --dsomero academic/gcompris: Added - gcompris is an educational software suite comprising of numerous activities for children aged 2 to 10. Thanks to Paul Liconti. --dsomero accessibility/xdotool: Added - xdotool lets you programatically (or manually) simulate keyboard input and mouse activity. Thanks to B. Watson. --dsomero audio/exaile: Added - exaile is a music manager and player for GTK+ written in Python. Thanks to Marco Cecchetti. --dsomero audio/id3: Added - id3 s console application for manipulating ID3 tags. Thanks to Cezary M. Kruk. --dsomero audio/streamripper: Updated for version 1.64.6. Thanks to Frank Caraballo. --dsomero desktop/dwm: Added - dwm is a dynamic window manager for X. Thanks to Tom Canich. --dsomero desktop/murrine: Updated for version 0.90.3. Thanks to Grigorios Bouzakis. --dsomero desktop/zenity: Added - Zenity is a tool that allows you to display Gtk+ dialog boxes from the command line and through shell scripts. Thanks to Larry Hajali. --rworkman development/argouml: Updated for version 0.28. Thanks to Robert Allen. --dsomero development/bzr: Updated for version 1.14. Thanks to Xavier Maillard. --rworkman development/bzrtools: Added - bzrtools is a collection of plugins providing useful extentions for GNU bazaar. Thanks to Xavier Maillard. --rworkman development/ipython: Updated for version 0.9.1. Thanks to Carlos Corbacho. --dsomero games/freeciv: Updated for version 2.1.9. Thanks to Iskar Enev. --dsomero games/icebreaker: Added - icebreaker is a Jezzball-like game for Linux, with a penguin theme. Thanks to B. Watson.. --dsomero games/jzintv: Added - jzintv is an emulator and development environment for the Mattel Intellivision game console. Thanks to B. Watson. --dsomero games/koules: Added - koules is a fast action arcade-style game for UNIX and OS/2. Thanks to B. Watson. --dsomero games/maelstrom: Added - maelstrom is a game similar to Asteroids. Thanks to B. Watson. --dsomero games/neverball: Updated for version 1.5.1. Thanks to Frank Caraballo. --dsomero games/uqm: Added - uqm (Ur-Quan Masters) is a port of the 3DO version of the PC game "Star Control II". Thanks to B. Watson. --dsomero games/uqm_3domusic: Added - uqm_3domusic is optional game content that provides high-quality in-game music. Thanks to B. Watson. --dsomero games/uqm_content: Added - uqm_content game content (graphics, sound, etc) need to play the uqm. Thanks to B. Watson. --dsomero games/uqm_voice: Added - uqm_voice is optional game content that provides in-game speech for uqm. Thanks to B. Watson. --dsomero games/z26: Added - z26 is an Atari 2600 emulator. Thanks to B. Watson. --dsomero graphics/digikam: Updated for version 0.9.5. Thanks to Frank Caraballo. --dsomero graphics/exiftags: Added - exiftags consists of three utilities for displaying and modifying Exif tags in digital camera JPEG files. Thanks to Cezary M. Kruk. --dsomero graphics/gimp-lqr-plugin: Added - gimp-lqr-plugin is a frontend to the Liquid Rescale Library. Thanks to Erik Hanson.. --dsomero graphics/kipi-plugins: Updated for version 0.1.7. Thanks to Frank Caraballo. --dsomero libraries/bsddb3: Added - bsddb3 is a python interface for Berkeley DB. Thanks to Larry Hajali. --dsomero libraries/chardet: Added - chardet provides character encoding auto-detection in Python. Thanks to Larry Hajali. --dsomero libraries/CherryPy: Added - CherryPy is a pythonic, object-oriented HTTP framework. Thanks to Larry Hajali. --dsomero libraries/exiv2: Updated for version 0.18.1. Thanks to Frank Caraballo. --dsomero libraries/gdk-pixbuf: Added - gdk-pixbuf is a library for manipulating images. Thanks to Cezary M. Kruk. --dsomero libraries/libkdcraw: Updated for version 0.1.8. Thanks to Frank Caraballo. --dsomero libraries/libkexiv2: Updated for version 0.1.9. Thanks to Frank Caraballo. --dsomero libraries/liblqr: Added - liblqr aims at resizing pictures non uniformly while preserving their features, i.e. avoiding distortion of the important parts. Thanks to Erik Hanson. --dsomero libraries/libmusicbrainz3: Added - this is the libmusicbrainz-3 library, which is incompatible with (but can be installed alongside) libmusicbrainz-2 from our repository. Thanks to Larry Hajali. --rworkman libraries/libtorrent-rasterbar: Updated for version 0.14.3, added the python bindings, and fixed zlib linking. Thanks to Erik Hanson. --rworkman libraries/libxklavier: Updated for version 3.9. Thanks to Heinz Wiesinger. --rworkman libraries/netcdf: Added - netcdf (network Common Data Form) is a set of interfaces for array-oriented data access. Thanks to Pierre Cazenave. --dsomero misc/gnome-doc-utils: Updated for version 0.16.0. Thanks to Frank Caraballo. --rworkman multimedia/gecko-mediaplayer: Updated for version 0.9.5. Thanks to Frank Caraballo. --dsomero multimedia/gnome-mplayer: Updated for version 0.9.5. Thanks to Frank Caraballo. --rworkman multimedia/grip: Added - grip is a gtk-based cd-player and cd-ripper. Thanks to B. Watson. --dsomero multimedia/gst-gnome-vfs: Added - this package contains the GStreamer plugin for gnome-vfs. Thanks to Marco Cecchetti. --rworkman multimedia/Miro: Added - Miro is a free Internet television application for the online Democracy Network. Thanks to Larry Hajali. --dsomero multimedia/remoot: Added - remoot is console application for remote control different audio players. Thanks to Cezary M. Kruk. --dsomero network/aMule: Updated for version 2.2.4. Thanks to Iskar Enev. --dsomero network/avahi: Updated for version 0.6.25. Thanks to David Somero. --rworkman network/dansguardian: Updated for version 2.10.0.3. Thanks to David Somero. --rworkman network/privoxy: Updated doinst.sh. Thanks to alkos333. --dsomero network/rhapsody: Added - rhapsody is a text console IRC client for Unix operating systems. Thanks to B. Watson. --dsomero network/squid: Updated for version 3.0.STABLE14. Thanks to David Somero. --rworkman office/catdoc: Added - catdoc reads MS Word file and prints readable ASCII text to stdout. Thanks to Cezary M. Kruk. --dsomero office/ding: Updated for version 1.6. Thanks to Martin Ivanov. --dsomero system/bleachbit: Added - bleachbit deletes unnecessary files to free valuable disk space. Thanks to Pierre Cazenave. --dsomero system/hardinfo: Updated for version 0.5.1. Thanks to Frank Caraballo. --dsomero system/iotop: Added - iotop is a Python program with a top-like UI for IO. Thanks to Audrius Kazukauskas. --dsomero system/iscan: Updated for version 2.18.0. Thanks to Frank Caraballo. --dsomero system/tmux: Updated for version 0.8. Thanks to Chess Griffin. --dsomero system/zeroinstall-injector: Updated for version 0.40. Thanks to Erik Hanson. --dsomero From acummingsus at gmail.com Thu May 7 05:14:39 2009 From: acummingsus at gmail.com (Alan C) Date: Wed, 6 May 2009 22:14:39 -0700 Subject: [Slackbuilds-users] rsync xfer Just me? Or is perm on 1 file set to disallow me receive a copy? Message-ID: send_files failed to open "12.2/academic/gcompris/gcompris.SlackBuild" (in slackbuilds): Permission denied (13) rsync error: some fil (perm disallow that 1 file to xfer a copy of it to me) or my rsync got wacked somehow Alan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From larryhaja at gmail.com Thu May 7 05:23:08 2009 From: larryhaja at gmail.com (Larry Hajali) Date: Wed, 6 May 2009 22:23:08 -0700 Subject: [Slackbuilds-users] rsync xfer Just me? Or is perm on 1 file set to disallow me receive a copy? In-Reply-To: References: Message-ID: <8ba30f850905062223r5f704cbbw696e3fb6152c19fb@mail.gmail.com> > > send_files failed to open "12.2/academic/gcompris/gcompris.SlackBuild" (in > slackbuilds): Permission denied (13) > rsync error: some fil > > (perm disallow that 1 file to xfer a copy of it to me) I get the same error. Larry -------------- next part -------------- An HTML attachment was scrubbed... URL: From erik at slackbuilds.org Thu May 7 06:10:01 2009 From: erik at slackbuilds.org (Erik Hanson) Date: Thu, 7 May 2009 01:10:01 -0500 Subject: [Slackbuilds-users] rsync xfer Just me? Or is perm on 1 file set to disallow me receive a copy? In-Reply-To: <8ba30f850905062223r5f704cbbw696e3fb6152c19fb@mail.gmail.com> References: <8ba30f850905062223r5f704cbbw696e3fb6152c19fb@mail.gmail.com> Message-ID: <20090507011001.70a0c54f@shaggy.scooby> On May 06, 2009, at 10:23 PM, Larry Hajali wrote: > > send_files failed to open "12.2/academic/gcompris/gcompris.SlackBuild" (in > > slackbuilds): Permission denied (13) > > rsync error: some fil > I get the same error. Should be fixed now. -- Erik Hanson http://slackbuilds.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From mjjzf at syntaktisk.dk Thu May 7 07:26:13 2009 From: mjjzf at syntaktisk.dk (Morten Juhl-Johansen =?ISO-8859-1?Q?Z=F6lde-Fej=E9r?=) Date: Thu, 7 May 2009 09:26:13 +0200 Subject: [Slackbuilds-users] Compilation problems with Abiword Message-ID: <20090507092613.2f36d105@espero.syntaktisk.dk> So, it seems I am actually getting what is the problem with creating an updated Slackbuild for Abiword. I first updated the Slackbuild to reflect v2.6.8, and it crashed along the way. It now seems that it requires an updated version of Pango. So I updated Pango and Cairo to the versions from Slackware-Current, and it builds without any problems. Now I have to see how much else in the system that is going to break with this update... Yours, Morten __ Morten Juhl-Johansen Z?lde-Fej?r http://syntaktisk.dk * mjjzf at syntaktisk.dk From me at alkos333.net Thu May 7 12:18:50 2009 From: me at alkos333.net (alkos333) Date: Thu, 7 May 2009 07:18:50 -0500 Subject: [Slackbuilds-users] Compilation problems with Abiword In-Reply-To: <20090507092613.2f36d105@espero.syntaktisk.dk> References: <20090507092613.2f36d105@espero.syntaktisk.dk> Message-ID: On Thu, May 7, 2009 at 2:26 AM, Morten Juhl-Johansen Z?lde-Fej?r wrote: > So, it seems I am actually getting what is the problem with creating an > updated Slackbuild for Abiword. I first updated the Slackbuild to > reflect v2.6.8, and it crashed along the way. It now seems that it > requires an updated version of Pango. > So I updated Pango and Cairo to the versions from Slackware-Current, > and it builds without any problems. Now I have to see how much else in > the system that is going to break with this update... > > Yours, > Morten > __ > Morten Juhl-Johansen Z?lde-Fej?r > http://syntaktisk.dk * mjjzf at syntaktisk.dk > _______________________________________________ > SlackBuilds-users mailing list > SlackBuilds-users at slackbuilds.org > http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users > Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/ > FAQ - http://slackbuilds.org/faq/ > > Thank you so much for looking into this. I promised Robby I was going to look into the compilation issues, but school work and finals kicked in and I never got around to it. Have you tried compiling 2.7.0, which has so many major improvements. The dev. team has done a really nice job. -- Alex Lysenka Computer Science Major Operations Management & Information Systems Major Northern Illinois University alysenka at niu.edu From adamsonj at email.unc.edu Thu May 7 13:34:06 2009 From: adamsonj at email.unc.edu (Joel J. Adamson ) Date: Thu, 07 May 2009 09:34:06 -0400 Subject: [Slackbuilds-users] rsync xfer Just me? Or is perm on 1 file set to disallow me receive a copy? In-Reply-To: <20090507011001.70a0c54f@shaggy.scooby> References: <8ba30f850905062223r5f704cbbw696e3fb6152c19fb@mail.gmail.com> <20090507011001.70a0c54f@shaggy.scooby> Message-ID: <3837.1241703246@email.unc.edu> >>>>> "Erik" == Erik Hanson writes: > On May 06, 2009, at 10:23 PM, Larry Hajali wrote: >> > send_files failed to open >> "12.2/academic/gcompris/gcompris.SlackBuild" (in > slackbuilds): >> Permission denied (13) > rsync error: some fil >> I get the same error. > Should be fixed now. I ran an update at 4:30 this morning and had no problems. Joel -- Joel J. Adamson -- http://www.unc.edu/~adamsonj University of North Carolina at Chapel Hill CB #3280, Coker Hall Chapel Hill, NC 27599-3280 From rworkman at slackbuilds.org Thu May 7 14:52:43 2009 From: rworkman at slackbuilds.org (Robby Workman) Date: Thu, 7 May 2009 09:52:43 -0500 Subject: [Slackbuilds-users] Compilation problems with Abiword In-Reply-To: <20090507092613.2f36d105@espero.syntaktisk.dk> References: <20090507092613.2f36d105@espero.syntaktisk.dk> Message-ID: <20090507095243.7b13cbf6@liberty.rlwhome.lan> On Thu, 7 May 2009 09:26:13 +0200 Morten Juhl-Johansen Z?lde-Fej?r wrote: > So, it seems I am actually getting what is the problem with creating > an updated Slackbuild for Abiword. I first updated the Slackbuild to > reflect v2.6.8, and it crashed along the way. It now seems that it > requires an updated version of Pango. > So I updated Pango and Cairo to the versions from Slackware-Current, > and it builds without any problems. Now I have to see how much else in > the system that is going to break with this update... Well, if it requires updating packages that are in Slackware, we can consider the abiword version we have now to be the last one for 12.2. -RW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From me at alkos333.net Thu May 7 14:54:28 2009 From: me at alkos333.net (alkos333) Date: Thu, 7 May 2009 09:54:28 -0500 Subject: [Slackbuilds-users] Compilation problems with Abiword In-Reply-To: <20090507095243.7b13cbf6@liberty.rlwhome.lan> References: <20090507092613.2f36d105@espero.syntaktisk.dk> <20090507095243.7b13cbf6@liberty.rlwhome.lan> Message-ID: On Thu, May 7, 2009 at 9:52 AM, Robby Workman wrote: > On Thu, 7 May 2009 09:26:13 +0200 > Morten Juhl-Johansen Z?lde-Fej?r wrote: > >> So, it seems I am actually getting what is the problem with creating >> an updated Slackbuild for Abiword. I first updated the Slackbuild to >> reflect v2.6.8, and it crashed along the way. It now seems that it >> requires an updated version of Pango. >> So I updated Pango and Cairo to the versions from Slackware-Current, >> and it builds without any problems. Now I have to see how much else in >> the system that is going to break with this update... > > > Well, if it requires updating packages that are in Slackware, we can > consider the abiword version we have now to be the last one for 12.2. > > -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/ > > > Yes, it does because they've ported from the rendering to cairo, etc. _current works but, 12.2 is insufficient, which is why there's no rush :) -- Alex Lysenka Computer Science Major Operations Management & Information Systems Major Northern Illinois University alysenka at niu.edu From me at alkos333.net Thu May 7 14:55:08 2009 From: me at alkos333.net (alkos333) Date: Thu, 7 May 2009 09:55:08 -0500 Subject: [Slackbuilds-users] Compilation problems with Abiword In-Reply-To: References: <20090507092613.2f36d105@espero.syntaktisk.dk> <20090507095243.7b13cbf6@liberty.rlwhome.lan> Message-ID: On Thu, May 7, 2009 at 9:54 AM, alkos333 wrote: > On Thu, May 7, 2009 at 9:52 AM, Robby Workman wrote: >> On Thu, 7 May 2009 09:26:13 +0200 >> Morten Juhl-Johansen Z?lde-Fej?r wrote: >> >>> So, it seems I am actually getting what is the problem with creating >>> an updated Slackbuild for Abiword. I first updated the Slackbuild to >>> reflect v2.6.8, and it crashed along the way. It now seems that it >>> requires an updated version of Pango. >>> So I updated Pango and Cairo to the versions from Slackware-Current, >>> and it builds without any problems. Now I have to see how much else in >>> the system that is going to break with this update... >> >> >> Well, if it requires updating packages that are in Slackware, we can >> consider the abiword version we have now to be the last one for 12.2. >> >> -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/ >> >> >> > > Yes, it does because they've ported from the rendering to cairo, etc. > _current works but, 12.2 is insufficient, which is why there's no rush > :) > > -- > Alex Lysenka > Computer Science Major > Operations Management & Information Systems Major > Northern Illinois University > alysenka at niu.edu > *they've ported their rendering to cairo -- Alex Lysenka Computer Science Major Operations Management & Information Systems Major Northern Illinois University alysenka at niu.edu From timp at timp.com.au Thu May 7 22:07:19 2009 From: timp at timp.com.au (Timothy Pollard) Date: Fri, 8 May 2009 08:07:19 +1000 Subject: [Slackbuilds-users] Esetroot download link 404 Message-ID: <20090508080719.16e8c5e5@shammah.timp.com.au> Hi, The Esetroot download link produces a 404 error. I believe it should be changed from http://www.jnrowe.ukfsn.org/data/Esetroot-20030422.tar.bz2 to http://www.jnrowe.ukfsn.org/_downloads/Esetroot-20030422.tar.bz2 -- TimP [http://blog.timp.com.au] -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From rworkman at slackbuilds.org Fri May 8 03:44:59 2009 From: rworkman at slackbuilds.org (Robby Workman) Date: Fri, 8 May 2009 03:44:59 +0000 Subject: [Slackbuilds-users] Updates - 20090508 Message-ID: <20090508034459.GA6437@slackbuilds.org> Fri May 8 03:42:12 UTC 2009 system/bleachbit: Included a patch from upstream to ignore the Slackware package manager directories if bleachbit is run as root. Thanks to Andrew Ziem for his quick response to this. --rworkman From xma at gnu.org Fri May 8 07:30:43 2009 From: xma at gnu.org (Xavier Maillard) Date: Fri, 8 May 2009 09:30:43 +0200 Subject: [Slackbuilds-users] Slackbuilds in python ? Message-ID: <20090508093043.39c70d64@homer.maillard.im> Hi, do you have any example of slackbuilds written in another scripting language than bash, say, for example, in Python ? I am planning to write one myself to see whether it could benefit of the Python strengh. Why ask ? Because I am writting a more complex slackbuild than I am used to (with multiple result packages) so I am writting many times the same code over and over. Maybe having a slackbuild python object with good methods could be valuable here. At the bare minimum, are functions (bash functions) accepted on SBo ? Cheers, Xavier Maillard From dragonwisard at gmail.com Fri May 8 13:37:06 2009 From: dragonwisard at gmail.com (Dragon Wisard) Date: Fri, 8 May 2009 09:37:06 -0400 Subject: [Slackbuilds-users] Slackbuilds in python ? In-Reply-To: <20090508093043.39c70d64@homer.maillard.im> References: <20090508093043.39c70d64@homer.maillard.im> Message-ID: <6c341e560905080637w158ea8e5x5dc708c085259d1e@mail.gmail.com> Hi Xavier, According to the Submissions page, SBo doesn't even like bash scripts. They want pure sh shell scripts. That said, Bourne Shell (sh) allows you to define functions in the format: function_name () { commands.... } Regards, Ben On Fri, May 8, 2009 at 3:30 AM, Xavier Maillard wrote: > Hi, > > do you have any example of slackbuilds written in another scripting > language than bash, say, for example, in Python ? > > I am planning to write one myself to see whether it could benefit of > the Python strengh. > > Why ask ? Because I am writting a more complex slackbuild than I am > used to (with multiple result packages) so I am writting many times the > same code over and over. Maybe having a slackbuild python object with > good methods could be valuable here. > > At the bare minimum, are functions (bash functions) accepted on SBo ? > > Cheers, > > Xavier Maillard > _______________________________________________ > 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/ > > -- http://www.dragonwisard.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From chaos.proton at gmail.com Fri May 8 14:40:32 2009 From: chaos.proton at gmail.com (Grissiom) Date: Fri, 8 May 2009 22:40:32 +0800 Subject: [Slackbuilds-users] Slackbuilds in python ? In-Reply-To: <20090508093043.39c70d64@homer.maillard.im> References: <20090508093043.39c70d64@homer.maillard.im> Message-ID: <200905082240.33698.chaos.proton@gmail.com> ? ??? 08 ?? 2009 15:30:43?Xavier Maillard ??? > Hi, > > do you have any example of slackbuilds written in another scripting > language than bash, say, for example, in Python ? > > I am planning to write one myself to see whether it could benefit of > the Python strengh. > > Why ask ? Because I am writting a more complex slackbuild than I am > used to (with multiple result packages) so I am writting many times the > same code over and over. Maybe having a slackbuild python object with > good methods could be valuable here. > > At the bare minimum, are functions (bash functions) accepted on SBo ? > > Cheers, > > Xavier Maillard Maybe this is a little OT but AFAIK Foresight( http://www.foresightlinux.org/ ) use python to do packaging. Thay say thier package system is powerful and flexible and ... Ok, anyway, but the more I see slackware the more I reallize that shell is enough for software packaging. Maybe you could post your problem here and let's have a disccusion about the solutions if you wish;) -- Cheers, Grissiom -------------- next part -------------- An HTML attachment was scrubbed... URL: From adamsonj at email.unc.edu Fri May 8 14:44:24 2009 From: adamsonj at email.unc.edu (Joel J. Adamson ) Date: Fri, 08 May 2009 10:44:24 -0400 Subject: [Slackbuilds-users] Slackbuilds in python ? In-Reply-To: <20090508093043.39c70d64@homer.maillard.im> References: <20090508093043.39c70d64@homer.maillard.im> Message-ID: <15366.1241793864@email.unc.edu> >>>>> "Xavier" == Xavier Maillard writes: > At the bare minimum, are functions (bash functions) accepted on > SBo ? template.SlackBuild actually includes a function. Not to split hairs (or un-split them), but sh on GNU/Linux is bash: lrwxrwxrwx 1 root root 4 2008-12-11 10:45 sh -> bash So you can use any bash-specific features with #!/bin/sh. These will only be run on Slackware right? Sh-compatibility is mainly a portability concern, and nobody's going to run a SlackBuild on FreeBSD or HP-UX are they? Joel -- Joel J. Adamson -- http://www.unc.edu/~adamsonj University of North Carolina at Chapel Hill CB #3280, Coker Hall Chapel Hill, NC 27599-3280 From rworkman at slackbuilds.org Fri May 8 14:56:34 2009 From: rworkman at slackbuilds.org (Robby Workman) Date: Fri, 8 May 2009 09:56:34 -0500 Subject: [Slackbuilds-users] Slackbuilds in python ? In-Reply-To: <20090508093043.39c70d64@homer.maillard.im> References: <20090508093043.39c70d64@homer.maillard.im> Message-ID: <20090508095634.0244c5f8@liberty.rlwhome.lan> On Fri, 8 May 2009 09:30:43 +0200 Xavier Maillard wrote: > do you have any example of slackbuilds written in another scripting > language than bash, say, for example, in Python ? I don't, and while I won't say it's a bad idea, I will say that we won't accept one here. > I am planning to write one myself to see whether it could benefit of > the Python strengh. Nothing wrong with that. > Why ask ? Because I am writting a more complex slackbuild than I am > used to (with multiple result packages) so I am writting many times > the same code over and over. Maybe having a slackbuild python object > with good methods could be valuable here. > > At the bare minimum, are functions (bash functions) accepted on SBo ? Putting some of the code duplication into sh functions is perfectly understandable -- for example: config_pkg() { ./configure \ --prefix=/usr \ ... remainder of options ... \ } I seem to remember at least one script in the Slackware tree that does this in a few places, but I can't recall which one right now. All that being said, keep in mind that we here at SlackBuilds.org want to have a 1:1 translation of source:package for a script, so if a script builds multiple packages at a time, it's not something that we're going to accept here. -RW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From dragonwisard at gmail.com Fri May 8 18:21:13 2009 From: dragonwisard at gmail.com (Dragon Wisard) Date: Fri, 8 May 2009 14:21:13 -0400 Subject: [Slackbuilds-users] Slackbuilds in python ? In-Reply-To: <15366.1241793864@email.unc.edu> References: <20090508093043.39c70d64@homer.maillard.im> <15366.1241793864@email.unc.edu> Message-ID: <6c341e560905081121i2952d998s30b7384e96b32792@mail.gmail.com> On Fri, May 8, 2009 at 10:44 AM, Joel J. Adamson wrote: > Sh-compatibility is mainly a > portability concern, and nobody's going to run a SlackBuild on FreeBSD > or HP-UX are they? Well actually... I've been looking at porting pkgtools to Solaris because I'm not a big fan of the default package management. But generally speaking, you are probably correct. But generally speaking, you are probably correct. Then again, using #!/bin/sh for bash-specific scripts has caused some issues for Debian and Ubuntu users who don't have sh symlinked to bash. Regards, Ben -- http://www.dragonwisard.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rworkman at slackbuilds.org Fri May 8 19:24:02 2009 From: rworkman at slackbuilds.org (Robby Workman) Date: Fri, 8 May 2009 14:24:02 -0500 Subject: [Slackbuilds-users] Slackbuilds in python ? In-Reply-To: <6c341e560905081121i2952d998s30b7384e96b32792@mail.gmail.com> References: <20090508093043.39c70d64@homer.maillard.im> <15366.1241793864@email.unc.edu> <6c341e560905081121i2952d998s30b7384e96b32792@mail.gmail.com> Message-ID: <20090508142402.50126ece@liberty.rlwhome.lan> On Fri, 8 May 2009 14:21:13 -0400 Dragon Wisard wrote: > On Fri, May 8, 2009 at 10:44 AM, Joel J. Adamson > wrote: > > > Sh-compatibility is mainly a > > portability concern, and nobody's going to run a SlackBuild on > > FreeBSD or HP-UX are they? > > > Then again, using #!/bin/sh for > bash-specific scripts has caused some issues for Debian and Ubuntu > users who don't have sh symlinked to bash. Indeed. As someone who has (on occasion, and just for grins and giggles), symlinked /bin/sh to /bin/ksh, I think it's important that /bin/sh stuff not contain bash-isms. -RW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From erik at slackbuilds.org Fri May 8 19:39:02 2009 From: erik at slackbuilds.org (Erik Hanson) Date: Fri, 8 May 2009 14:39:02 -0500 Subject: [Slackbuilds-users] Slackbuilds in python ? In-Reply-To: <15366.1241793864@email.unc.edu> References: <20090508093043.39c70d64@homer.maillard.im> <15366.1241793864@email.unc.edu> Message-ID: <20090508143902.1a04106f@shaggy.scooby> On May 08, 2009, at 10:44 AM, Joel J. Adamson wrote: > lrwxrwxrwx 1 root root 4 2008-12-11 10:45 sh -> bash > > So you can use any bash-specific features with #!/bin/sh. These will This isn't necessarily true, bash behaves differently ("historically") when invoked as "sh". There are details in bash(1) under Invocation. -- Erik Hanson http://slackbuilds.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From xma at gnu.org Fri May 8 20:43:59 2009 From: xma at gnu.org (Xavier MAILLARD) Date: Fri, 8 May 2009 22:43:59 +0200 Subject: [Slackbuilds-users] Slackbuilds in python ? In-Reply-To: <20090508095634.0244c5f8@liberty.rlwhome.lan> References: <20090508093043.39c70d64@homer.maillard.im> <20090508095634.0244c5f8@liberty.rlwhome.lan> Message-ID: <20090508224359.0197e657@homer.maillard.im> Le Fri, 8 May 2009 09:56:34 -0500, Robby Workman a ?crit : > On Fri, 8 May 2009 09:30:43 +0200 > Xavier Maillard wrote: > > > do you have any example of slackbuilds written in another scripting > > language than bash, say, for example, in Python ? > > > I don't, and while I won't say it's a bad idea, I will say that we > won't accept one here. That was not intented to be submitted on SBo anyway :D > > Why ask ? Because I am writting a more complex slackbuild than I am > > used to (with multiple result packages) so I am writting many times > > the same code over and over. Maybe having a slackbuild python object > > with good methods could be valuable here. > > > > At the bare minimum, are functions (bash functions) accepted on > > SBo ? > > > Putting some of the code duplication into sh functions is perfectly > understandable -- for example: This is exactly what I am doing ATM. > All that being said, keep in mind that we here at SlackBuilds.org want > to have a 1:1 translation of source:package for a script, so if a > script builds multiple packages at a time, it's not something that > we're going to accept here. Once again, the slackbuild I am writting is not meant to be submitted on SBo for these reasons: - not 1:1 - already in official slackware distribution Anyway, thank you all for your answers. I finally realized I did not really need Python since pure sh-ism is a good workaround. More about my slackbuild in a few days. Cheers, Xavier From adamsonj at email.unc.edu Fri May 8 20:41:35 2009 From: adamsonj at email.unc.edu (Joel J. Adamson ) Date: Fri, 08 May 2009 16:41:35 -0400 Subject: [Slackbuilds-users] Slackbuilds in python ? In-Reply-To: <20090508143902.1a04106f@shaggy.scooby> References: <20090508093043.39c70d64@homer.maillard.im> <15366.1241793864@email.unc.edu> <20090508143902.1a04106f@shaggy.scooby> Message-ID: <9276.1241815295@email.unc.edu> >>>>> "Erik" == Erik Hanson writes: > On May 08, 2009, at 10:44 AM, Joel J. Adamson wrote: >> lrwxrwxrwx 1 root root 4 2008-12-11 10:45 sh -> bash >> >> So you can use any bash-specific features with #!/bin/sh. These >> will > This isn't necessarily true, bash behaves differently > ("historically") when invoked as "sh". There are details in > bash(1) under Invocation. I discovered that myself this afternoon while writing a script :) Joel -- Joel J. Adamson -- http://www.unc.edu/~adamsonj University of North Carolina at Chapel Hill CB #3280, Coker Hall Chapel Hill, NC 27599-3280 From xma at gnu.org Fri May 8 20:45:29 2009 From: xma at gnu.org (Xavier MAILLARD) Date: Fri, 8 May 2009 22:45:29 +0200 Subject: [Slackbuilds-users] Slackbuilds in python ? In-Reply-To: <20090508143902.1a04106f@shaggy.scooby> References: <20090508093043.39c70d64@homer.maillard.im> <15366.1241793864@email.unc.edu> <20090508143902.1a04106f@shaggy.scooby> Message-ID: <20090508224529.12340db1@homer.maillard.im> Le Fri, 8 May 2009 14:39:02 -0500, Erik Hanson a ?crit : > On May 08, 2009, at 10:44 AM, Joel J. Adamson wrote: > > > lrwxrwxrwx 1 root root 4 2008-12-11 10:45 sh -> bash > > > > So you can use any bash-specific features with #!/bin/sh. These > > will > > This isn't necessarily true, bash behaves differently > ("historically") when invoked as "sh". There are details in bash(1) > under Invocation. > Thank you for the clarification, I never read this section before :D Xavier From adamsonj at email.unc.edu Sat May 9 01:28:14 2009 From: adamsonj at email.unc.edu (Joel J. Adamson ) Date: Fri, 08 May 2009 21:28:14 -0400 Subject: [Slackbuilds-users] Slackbuilds in python ? In-Reply-To: <9276.1241815295@email.unc.edu> References: <20090508093043.39c70d64@homer.maillard.im> <15366.1241793864@email.unc.edu> <20090508143902.1a04106f@shaggy.scooby> <9276.1241815295@email.unc.edu> Message-ID: <26929.1241832494@email.unc.edu> >>>>> "Joel" == Joel J Adamson <" > writes: >>>>> "Erik" == Erik Hanson writes: >> On May 08, 2009, at 10:44 AM, Joel J. Adamson wrote: >>> lrwxrwxrwx 1 root root 4 2008-12-11 10:45 sh -> bash >>> >>> So you can use any bash-specific features with #!/bin/sh. These >>> will >> This isn't necessarily true, bash behaves differently >> ("historically") when invoked as "sh". There are details in >> bash(1) under Invocation. > I discovered that myself this afternoon while writing a script :) That being said, Xavier's question was really about functions: since functions are part of the POSIX standard, can we really consider them "bash-isms?" Joel -- Joel J. Adamson -- http://www.unc.edu/~adamsonj University of North Carolina at Chapel Hill CB #3280, Coker Hall Chapel Hill, NC 27599-3280 From rworkman at slackbuilds.org Sat May 9 03:50:44 2009 From: rworkman at slackbuilds.org (Robby Workman) Date: Fri, 8 May 2009 22:50:44 -0500 Subject: [Slackbuilds-users] Slackbuilds in python ? In-Reply-To: <26929.1241832494@email.unc.edu> References: <20090508093043.39c70d64@homer.maillard.im> <15366.1241793864@email.unc.edu> <20090508143902.1a04106f@shaggy.scooby> <9276.1241815295@email.unc.edu> <26929.1241832494@email.unc.edu> Message-ID: <20090508225044.0e2e4637@liberty.rlwhome.lan> On Fri, 08 May 2009 21:28:14 -0400 "Joel J. Adamson " wrote: > >>>>> "Joel" == Joel J Adamson <" > writes: > > >>>>> "Erik" == Erik Hanson writes: > >> On May 08, 2009, at 10:44 AM, Joel J. Adamson wrote: > >>> lrwxrwxrwx 1 root root 4 2008-12-11 10:45 sh -> bash > >>> > >>> So you can use any bash-specific features with #!/bin/sh. > >>> These will > > >> This isn't necessarily true, bash behaves differently > >> ("historically") when invoked as "sh". There are details in > >> bash(1) under Invocation. > > > I discovered that myself this afternoon while writing a > > script :) > > That being said, Xavier's question was really about functions: since > functions are part of the POSIX standard, can we really consider them > "bash-isms?" Absolutely not. A function in general is fine. -RW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From nille.kungen at gmail.com Sat May 9 08:30:12 2009 From: nille.kungen at gmail.com (=?ISO-8859-1?Q?Niklas_=27Nille=27_=C5kerstr=F6m?=) Date: Sat, 09 May 2009 10:30:12 +0200 Subject: [Slackbuilds-users] LIBDIRSUFFIX Message-ID: <4A053F14.7030801@gmail.com> I seen that in slackware the builds often use LIBDIRSUFFIX now. So i wonder if we should add LIBDIRSUFFIX to template.SlackBuild since i think alot of people uses an 64bit version like slamd64 now. Is it okey to use LIBDIRSUFFIX in slackbuilds.org SlackBuilds? From thomas at beingboiled.info Sat May 9 13:44:16 2009 From: thomas at beingboiled.info (Thomas Morper) Date: Sat, 9 May 2009 15:44:16 +0200 Subject: [Slackbuilds-users] updating exiv2 breaks gwenview Message-ID: <200905091544.16686.thomas@beingboiled.info> Just a quick warning... Updating exiv2 and libkexiv2 to the current version will break gwenview. Neither will an existing binary work anymore nor will you be able to compile against the updated libraries! There's a more recent gwenview 1.4.3 which *might* work, but I haven't tried it because there's no tarball (svn-only) and no "configure" - you have to know how to use the autotools to build this. A fix for this problem would be highly appreciated. -- From slackware.wagnerm at arcor.de Sat May 9 15:08:28 2009 From: slackware.wagnerm at arcor.de (Michael Wagner) Date: Sat, 09 May 2009 17:08:28 +0200 Subject: [Slackbuilds-users] updating exiv2 breaks gwenview In-Reply-To: <200905091544.16686.thomas@beingboiled.info> References: <200905091544.16686.thomas@beingboiled.info> Message-ID: <4A059C6C.8040803@arcor.de> > Updating exiv2 and libkexiv2 to the current version will break gwenview. > Neither will an existing binary work anymore nor will you be able to compile > against the updated libraries! > > An update has already been submitted to the pending queue. Shouldn't it be necessary to mention an API/ABI/SONAME breakage while uploading packages including shared libraries? Greetings, Michael From xma at gnu.org Sat May 9 20:55:18 2009 From: xma at gnu.org (Xavier Maillard) Date: Sat, 9 May 2009 22:55:18 +0200 Subject: [Slackbuilds-users] Making a link in a slackbuild Message-ID: <20090509225518.716f4886@homer.maillard.im> Hi, it seems links made during a package construction is automatically removed during makepkg step. How am I supposed to have links then ? What is the recommended way ? Regards, Xavier From xma at gnu.org Sat May 9 20:56:22 2009 From: xma at gnu.org (Xavier MAILLARD) Date: Sat, 9 May 2009 22:56:22 +0200 Subject: [Slackbuilds-users] updating exiv2 breaks gwenview In-Reply-To: <4A059C6C.8040803@arcor.de> References: <200905091544.16686.thomas@beingboiled.info> <4A059C6C.8040803@arcor.de> Message-ID: <20090509225622.33c897ea@homer.maillard.im> Le Sat, 09 May 2009 17:08:28 +0200, Michael Wagner a ?crit : > > > Updating exiv2 and libkexiv2 to the current version will break > > gwenview. Neither will an existing binary work anymore nor will you > > be able to compile against the updated libraries! > > > > > > An update has already been submitted to the pending queue. > > Shouldn't it be necessary to mention an API/ABI/SONAME breakage while > uploading packages including shared libraries? +1 I think this should be part of the changelog message. Xavier From dominian at slackadelic.com Sat May 9 21:09:07 2009 From: dominian at slackadelic.com (Matt Hayes) Date: Sat, 09 May 2009 17:09:07 -0400 Subject: [Slackbuilds-users] Making a link in a slackbuild In-Reply-To: <20090509225518.716f4886@homer.maillard.im> References: <20090509225518.716f4886@homer.maillard.im> Message-ID: <4A05F0F3.6000300@slackadelic.com> Xavier Maillard wrote: > Hi, > > it seems links made during a package construction is automatically > removed during makepkg step. How am I supposed to have links then ? > What is the recommended way ? > > Regards, > > Xavier > _______________________________________________ > 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/ > They aren't removed per se, they are usually found in install/doinst.sh where they are executed after the package installation has finished. -Matt From me at alkos333.net Sat May 9 21:42:02 2009 From: me at alkos333.net (alkos333) Date: Sat, 9 May 2009 16:42:02 -0500 Subject: [Slackbuilds-users] Making a link in a slackbuild In-Reply-To: <20090509225518.716f4886@homer.maillard.im> References: <20090509225518.716f4886@homer.maillard.im> Message-ID: On Sat, May 9, 2009 at 3:55 PM, Xavier Maillard wrote: > Hi, > > it seems links made during a package construction is automatically > removed during makepkg step. How am I supposed to have links then ? > What is the recommended way ? > > Regards, > > Xavier > _______________________________________________ > 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/ > > Basically, makepkg finds all the links and adds commands needed to recreate the links to doinst.sh, which is run by installpkg/upgradepkg. -- Alex Lysenka Computer Science Major Operations Management & Information Systems Major Northern Illinois University alysenka at niu.edu From xgizzmo at slackbuilds.org Sat May 9 21:57:48 2009 From: xgizzmo at slackbuilds.org (xgizzmo at slackbuilds.org) Date: Sat, 9 May 2009 17:57:48 -0400 Subject: [Slackbuilds-users] Making a link in a slackbuild In-Reply-To: <20090509225518.716f4886@homer.maillard.im> References: <20090509225518.716f4886@homer.maillard.im> Message-ID: <200905091757.49025.xgizzmo@slackbuilds.org> On Saturday 09 May 2009 16:55:18 Xavier Maillard wrote: > Hi, > > it seems links made during a package construction is automatically > removed during makepkg step. How am I supposed to have links then ? > What is the recommended way ? > > Regards, > > Xavier > _______________________________________________ > 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/ > > They are removed and added to the doinst.sh script so they can be recreated on the target system. In other words the correct way is to make the symlink in the slackbuild. It will automaticly be added to the doinst.sh script. --dsomero From rworkman at slackbuilds.org Sun May 10 06:32:44 2009 From: rworkman at slackbuilds.org (Robby Workman) Date: Sun, 10 May 2009 01:32:44 -0500 Subject: [Slackbuilds-users] updating exiv2 breaks gwenview In-Reply-To: <4A059C6C.8040803@arcor.de> References: <200905091544.16686.thomas@beingboiled.info> <4A059C6C.8040803@arcor.de> Message-ID: <20090510013244.54b4a58b@liberty.rlwhome.lan> On Sat, 09 May 2009 17:08:28 +0200 Michael Wagner wrote: > > Updating exiv2 and libkexiv2 to the current version will break > > gwenview. Neither will an existing binary work anymore nor will you > > be able to compile against the updated libraries! > > > > An update has already been submitted to the pending queue. > > Shouldn't it be necessary to mention an API/ABI/SONAME breakage while > uploading packages including shared libraries? Unfortunately, this happens (even though we try to avoid it), and it's not always obvious to either the submitter or us when it does. As with the actual Slackware tree, the best we can hope to happen is to quickly catch it when it does and push an update. I'll try to look at the new gwenview asap. -RW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From rworkman at slackbuilds.org Sun May 10 06:33:42 2009 From: rworkman at slackbuilds.org (Robby Workman) Date: Sun, 10 May 2009 01:33:42 -0500 Subject: [Slackbuilds-users] LIBDIRSUFFIX In-Reply-To: <4A053F14.7030801@gmail.com> References: <4A053F14.7030801@gmail.com> Message-ID: <20090510013342.59f5c4ce@liberty.rlwhome.lan> On Sat, 09 May 2009 10:30:12 +0200 Niklas 'Nille' ?kerstr?m wrote: > I seen that in slackware the builds often use LIBDIRSUFFIX now. > So i wonder if we should add LIBDIRSUFFIX to template.SlackBuild > since i think alot of people uses an 64bit version like slamd64 now. > Is it okey to use LIBDIRSUFFIX in slackbuilds.org SlackBuilds? We'll discuss this and make an announcement on the list. -RW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From xma at gnu.org Sun May 10 12:40:10 2009 From: xma at gnu.org (Xavier Maillard) Date: Sun, 10 May 2009 14:40:10 +0200 Subject: [Slackbuilds-users] Making a link in a slackbuild In-Reply-To: <4A05F0F3.6000300@slackadelic.com> References: <20090509225518.716f4886@homer.maillard.im> <4A05F0F3.6000300@slackadelic.com> Message-ID: <871vqxrv11.wl%xma@gnu.org> Good catch everybody. I extracted my package and the links are part of the doinst.sh script file. Sorry to bother. Xavier From xma at gnu.org Sun May 10 12:42:50 2009 From: xma at gnu.org (Xavier Maillard) Date: Sun, 10 May 2009 14:42:50 +0200 Subject: [Slackbuilds-users] Making a link in a slackbuild In-Reply-To: <200905091757.49025.xgizzmo@slackbuilds.org> References: <20090509225518.716f4886@homer.maillard.im> <200905091757.49025.xgizzmo@slackbuilds.org> Message-ID: <87zldlqgc5.wl%xma@gnu.org> At Sat, 9 May 2009 17:57:48 -0400, xgizzmo at slackbuilds.org wrote: > They are removed and added to the doinst.sh script so they can be recreated > on the target system. In other words the correct way is to make the symlink > in the slackbuild. It will automaticly be added to the doinst.sh script. Good point. Though it is not obvious to me what (or when) a packager should fill a doinst.sh script. I think I have to read the "zen of slackware packaging" ;) Xavier From mjjzf at syntaktisk.dk Sun May 10 14:06:42 2009 From: mjjzf at syntaktisk.dk (Morten Juhl-Johansen =?ISO-8859-1?Q?Z=F6lde-Fej=E9r?=) Date: Sun, 10 May 2009 16:06:42 +0200 Subject: [Slackbuilds-users] Compilation problems with Abiword In-Reply-To: <20090507095243.7b13cbf6@liberty.rlwhome.lan> References: <20090507092613.2f36d105@espero.syntaktisk.dk> <20090507095243.7b13cbf6@liberty.rlwhome.lan> Message-ID: <20090510160642.512fa252@espero.syntaktisk.dk> On Thu, 7 May 2009 09:52:43 -0500 Robby Workman wrote: > Well, if it requires updating packages that are in Slackware, we can > consider the abiword version we have now to be the last one for 12.2. > > -RW Agreed. No problem in this. As Alex pointed out, 2.7.0 is where the action is right now... even if it is a development version. As I said, 2.6.8 built well on packages for Slackware-current, so as far as that goes it will be all set for after the next Slackware release next week (no, I have no idea, just dreaming). Yours, Morten __ Morten Juhl-Johansen Z?lde-Fej?r http://syntaktisk.dk * mjjzf at syntaktisk.dk From me at alkos333.net Sun May 10 14:11:38 2009 From: me at alkos333.net (alkos333) Date: Sun, 10 May 2009 09:11:38 -0500 Subject: [Slackbuilds-users] Compilation problems with Abiword In-Reply-To: <20090510160642.512fa252@espero.syntaktisk.dk> References: <20090507092613.2f36d105@espero.syntaktisk.dk> <20090507095243.7b13cbf6@liberty.rlwhome.lan> <20090510160642.512fa252@espero.syntaktisk.dk> Message-ID: On Sun, May 10, 2009 at 9:06 AM, Morten Juhl-Johansen Z?lde-Fej?r wrote: > after the next Slackware release next week (no, I have no idea, just > dreaming). That just begs the question - when is the next release coming outl? -- Ah.. that's right, when it's ready. :) -- Alex Lysenka Computer Science Major Operations Management & Information Systems Major Northern Illinois University alysenka at niu.edu From slacker6896 at gmail.com Sun May 10 17:27:28 2009 From: slacker6896 at gmail.com (Sebastien BALLET) Date: Sun, 10 May 2009 19:27:28 +0200 Subject: [Slackbuilds-users] mistaken submission Message-ID: Hi, After reading the thread "Slackbuilds in python ?" it seems that the submission that I made on 16/4 (i.e kernel-pae) is wrong. Indeed, this slackbuild builds multiple package at a time, which is something that slackbuilds.org do not want. To correct this mistake, I have made two slackbuilds (kernel-pae and kernel-pae-source). So, if you want them, I could submit them as soon as the old will be removed from the pending queue. Sorry for the inconvenience. -- SeB From rworkman at slackbuilds.org Sun May 10 19:44:58 2009 From: rworkman at slackbuilds.org (Robby Workman) Date: Sun, 10 May 2009 14:44:58 -0500 Subject: [Slackbuilds-users] mistaken submission In-Reply-To: References: Message-ID: <20090510144458.1fb6db33@liberty.rlwhome.lan> On Sun, 10 May 2009 19:27:28 +0200 Sebastien BALLET wrote: > After reading the thread "Slackbuilds in python ?" it seems that the > submission that I made on 16/4 (i.e kernel-pae) is wrong. Indeed, this > slackbuild builds multiple package at a time, which is something that > slackbuilds.org do not want. To correct this mistake, I have made two > slackbuilds (kernel-pae and kernel-pae-source). So, if you want them, > I could submit them as soon as the old will be removed from the > pending queue. Done. -RW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From rworkman at slackbuilds.org Sun May 10 20:24:55 2009 From: rworkman at slackbuilds.org (Robby Workman) Date: Sun, 10 May 2009 15:24:55 -0500 Subject: [Slackbuilds-users] LIBDIRSUFFIX In-Reply-To: <20090510013342.59f5c4ce@liberty.rlwhome.lan> References: <4A053F14.7030801@gmail.com> <20090510013342.59f5c4ce@liberty.rlwhome.lan> Message-ID: <20090510152455.5cd37e66@liberty.rlwhome.lan> On Sun, 10 May 2009 01:33:42 -0500 Robby Workman wrote: > On Sat, 09 May 2009 10:30:12 +0200 > Niklas 'Nille' ?kerstr?m wrote: > > > I seen that in slackware the builds often use LIBDIRSUFFIX now. > > So i wonder if we should add LIBDIRSUFFIX to template.SlackBuild > > since i think alot of people uses an 64bit version like slamd64 now. > > Is it okey to use LIBDIRSUFFIX in slackbuilds.org SlackBuilds? > > > We'll discuss this and make an announcement on the list. Have a look at the template.SlackBuild script again. :-) -RW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From xgizzmo at slackbuilds.org Sun May 10 23:09:04 2009 From: xgizzmo at slackbuilds.org (xgizzmo at slackbuilds.org) Date: Sun, 10 May 2009 19:09:04 -0400 Subject: [Slackbuilds-users] Updates - 20090510 Message-ID: <200905101909.05119.xgizzmo@slackbuilds.org> Sun May 10 22:39:13 UTC 2009 audio/mp3gain: Added - mp3gain is a command-line normalizer. Thanks to B. Watson. --chess development/gsoap: Added - gSOAP is a development toolkit that simplifies the overall use of XML in any type of application. Thanks to Heinz Wiesinger. --rworkman development/numpy: Updated for version 1.3.0. Thanks to Aleksandar Samardzic. --dsomero games/gnubg: Updated for version 20090501. Thanks to Erik Hanson. --chess graphics/gwenview: Included a patch to build against the new exiv2. Thanks to Michael Wagner. --rworkman libraries/qt4: Updated for version 4.5.1. Thanks to Heinz Wiesinger. --dsomero libraries/redland: Updated for version 1.0.9. Thanks to Heinz Wiesinger. --rworkman network/aria2: Updated for version 1.3.2. Thanks to Marco Cecchetti. --dsomero network/ndiswrapper: Included a patch to build on 2.6.29.x kernels. Thanks to Eric Hameleers for the heads-up on the patch. --rworkman office/osmo: Updated for version 0.2.6. Thanks to Frank Caraballo. --dsomero system/gammu: Updated for version 1.24.0. Thanks to Heinz Wiesinger. --dsomero system/rubygems: Updated for version 1.3.2. Thanks to Vincent Batts. --dsomero system/spambayes: Added fix needed for Python 2.6 (it doesn't change anything for 2.5); also tweaked build script a bit. Thanks to Audrius Kazukauskas. --dsomero From thomas at beingboiled.info Sun May 10 23:24:29 2009 From: thomas at beingboiled.info (Thomas Morper) Date: Mon, 11 May 2009 01:24:29 +0200 Subject: [Slackbuilds-users] Updates - 20090510 In-Reply-To: <200905101909.05119.xgizzmo@slackbuilds.org> References: <200905101909.05119.xgizzmo@slackbuilds.org> Message-ID: <200905110124.29635.thomas@beingboiled.info> Again, some minor permission problems have sneaked into this update for those who use rsync to keep up to date: rsync: opendir "12.2/audio/mp3gain" (in slackbuilds) failed: Permission denied (13) rsync: send_files failed to open "12.2/games/gnubg/gnubg.info" (in slackbuilds): Permission denied (13) Thanks in advance for fixing :-) -- From nille.kungen at gmail.com Sun May 10 23:46:31 2009 From: nille.kungen at gmail.com (=?UTF-8?B?TmlrbGFzICdOaWxsZScgw4VrZXJzdHLDtm0=?=) Date: Mon, 11 May 2009 01:46:31 +0200 Subject: [Slackbuilds-users] LIBDIRSUFFIX In-Reply-To: <20090510152455.5cd37e66@liberty.rlwhome.lan> References: <4A053F14.7030801@gmail.com> <20090510013342.59f5c4ce@liberty.rlwhome.lan> <20090510152455.5cd37e66@liberty.rlwhome.lan> Message-ID: <4A076757.4050701@gmail.com> Robby Workman skrev: > On Sun, 10 May 2009 01:33:42 -0500 > Robby Workman wrote: > > >> On Sat, 09 May 2009 10:30:12 +0200 >> Niklas 'Nille' ?kerstr?m wrote: >> >> >>> I seen that in slackware the builds often use LIBDIRSUFFIX now. >>> So i wonder if we should add LIBDIRSUFFIX to template.SlackBuild >>> since i think alot of people uses an 64bit version like slamd64 now. >>> Is it okey to use LIBDIRSUFFIX in slackbuilds.org SlackBuilds? >>> >> We'll discuss this and make an announcement on the list. >> > > > Have a look at the template.SlackBuild script again. :-) > > -RW > Thanks Robby it's like i wanted it. Will update my scripts when there's an new release if the project is dead then i will update them soon. From nishant at mnspace.net Mon May 11 02:05:23 2009 From: nishant at mnspace.net (Nishant Limbachia) Date: Sun, 10 May 2009 21:05:23 -0500 Subject: [Slackbuilds-users] clamav-unofficial-sigs Message-ID: <4A0787E3.5070404@mnspace.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I uploaded slackbuild for clamav-unofficial-sigs this morning but a newer version was released this afternoon :-). Can you please take down the script from pending and I'll upload newer version later. Thanks, - -- Nishant Limbachia nishant at mnspace.net GPG Key: 0x0FF9D6D5 GPG Fingerprint: CC77 2954 DBDD CA46 49D5 BC90 786E 5DA2 0FF9 D6D5 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkoHh+EACgkQeG5dog/51tURgACfdYWTgL420Q2vxgw7iXOF23qn BAAAnjKB+GS8mnPSBLg+Scx/FTnld33z =pTCr -----END PGP SIGNATURE----- From rworkman at slackbuilds.org Mon May 11 02:16:11 2009 From: rworkman at slackbuilds.org (Robby Workman) Date: Sun, 10 May 2009 21:16:11 -0500 Subject: [Slackbuilds-users] clamav-unofficial-sigs In-Reply-To: <4A0787E3.5070404@mnspace.net> References: <4A0787E3.5070404@mnspace.net> Message-ID: <20090510211611.2a7332fc@liberty.rlwhome.lan> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 10 May 2009 21:05:23 -0500 Nishant Limbachia wrote: > I uploaded slackbuild for clamav-unofficial-sigs this morning but a > newer version was released this afternoon :-). Can you please take > down the script from pending and I'll upload newer version later. Done. - -RW -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkoHimsACgkQvGy9tf6lsvvKGwCfY0QWhEra37HjZTqo5yxBS+Mk S9QAoKtFPH2Ianmi/BZ/TA/uk5jEamH4 =d1Jf -----END PGP SIGNATURE----- From wagnerm at arcor.de Mon May 11 04:49:57 2009 From: wagnerm at arcor.de (Michael Wagner) Date: Mon, 11 May 2009 06:49:57 +0200 Subject: [Slackbuilds-users] updating exiv2 breaks gwenview In-Reply-To: <20090510013244.54b4a58b@liberty.rlwhome.lan> References: <200905091544.16686.thomas@beingboiled.info> <4A059C6C.8040803@arcor.de> <20090510013244.54b4a58b@liberty.rlwhome.lan> Message-ID: <4A07AE75.6050102@arcor.de> > > Unfortunately, this happens (even though we try to avoid it), and it's > not always obvious to either the submitter or us when it does. As with > the actual Slackware tree, the best we can hope to happen is to quickly > catch it when it does and push an update. I'll try to look at the new > gwenview asap. > > -RW Maybe we can store the output of 'objdump -p libfoo.so.?.?.? | grep SONAME' in the *.info file? Michael From rworkman at slackbuilds.org Mon May 11 14:53:58 2009 From: rworkman at slackbuilds.org (Robby Workman) Date: Mon, 11 May 2009 09:53:58 -0500 Subject: [Slackbuilds-users] updating exiv2 breaks gwenview In-Reply-To: <4A07AE75.6050102@arcor.de> References: <200905091544.16686.thomas@beingboiled.info> <4A059C6C.8040803@arcor.de> <20090510013244.54b4a58b@liberty.rlwhome.lan> <4A07AE75.6050102@arcor.de> Message-ID: <20090511095358.6a928d80@liberty.rlwhome.lan> On Mon, 11 May 2009 06:49:57 +0200 Michael Wagner wrote: > > > > Unfortunately, this happens (even though we try to avoid it), and > > it's not always obvious to either the submitter or us when it > > does. As with the actual Slackware tree, the best we can hope to > > happen is to quickly catch it when it does and push an update. > > I'll try to look at the new gwenview asap. > > > > Maybe we can store the output of 'objdump -p libfoo.so.?.?.? | grep > SONAME' in the *.info file? Nah, I think we'll pass on that. While it might be useful in a few instances, I don't think those few occasions justify the addition. -RW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From xma at gnu.org Tue May 12 05:50:46 2009 From: xma at gnu.org (Xavier Maillard) Date: Tue, 12 May 2009 07:50:46 +0200 Subject: [Slackbuilds-users] can't compile nethack Message-ID: <87ljp2yimh.wl%xma@gnu.org> Hi, I tried to install nethack using SBo script but it failed. As far as I can see, SBo is compiling both terminal version and an X11 flavour of it. Problem is that it is not precised what one needs in order to successfully compile all flavours. What would be even better than compiling *all* versions would be to offer user a way to only compile the flavour he really wants (in my case, I would choose terminal only). What are the requirements so far with SBo script ? Xavier From geetha at angleritech.com Thu May 14 06:22:58 2009 From: geetha at angleritech.com (Geetha) Date: Thu, 14 May 2009 11:52:58 +0530 Subject: [Slackbuilds-users] package of list of gems Message-ID: <4A0BB8C2.2000609@angleritech.com> I need a package of list of ruby gems. basically we do install ruby gems , gem install rmagick -v=2.5.3 gem install rails -v=2.1.1 I would appreciate any one help.. -- Best Regards, ** *Geetha S *| System and Software Engineer email: geetha at angleritech.com * * ** * *Visit us at **Webinale**, Germany* (25th -- 27th May 2009)** *Click here for FREE TICKETS:** *http://www.angleritech.com/company/latest-technology-news-events.html * *ANGLER Technologies India - Your Offshore Development Partner -- An ISO 9001 Company* Contact us for your high quality Software Outsourcing , E-Business Products and Design Solutions /* */ web : www.angleritech.com tel : +91 422 2312707, 2313938 fax : +91 422 2313936 address :* *1144 Trichy Road, Coimbatore, 641045, India offices _ _ : India | USA | UK | Canada | Europe | UAE | South Africa | Singapore | Hong Kong * * *Disclaimer: *The information in the email, files and communication are strictly confidential and meant for the intended recipients. It may contain proprietary information. If you are not an intended recipient; any form of disclosure, copyright, distribution and any other means of use of information is unauthorised and subject to legal implications. We do not accept any liability for the transmission of incomplete, delayed communication and recipients must check this email and any attachments for the presence of viruses before downloading them. -------------- next part -------------- An HTML attachment was scrubbed... URL: From adamsonj at email.unc.edu Thu May 14 13:49:45 2009 From: adamsonj at email.unc.edu (Joel J. Adamson ) Date: Thu, 14 May 2009 09:49:45 -0400 Subject: [Slackbuilds-users] package of list of gems In-Reply-To: <4A0BB8C2.2000609@angleritech.com> References: <4A0BB8C2.2000609@angleritech.com> Message-ID: <17476.1242308985@email.unc.edu> >>>>> "geetha" == geetha writes: > I need a package of list of ruby gems. basically we do install > ruby gems , gem install rmagick -v=2.5.3 gem install rails > -v=2.1.1 I would appreciate any one help.. If you want a list of files that a package installs, look at the package file in /var/log/packages. For example: chondestes: /home/joel> cat /var/log/packages/gnubiff-2.2.8-i486-1_SBo PACKAGE NAME: gnubiff-2.2.8-i486-1_SBo COMPRESSED PACKAGE SIZE: 518 K UNCOMPRESSED PACKAGE SIZE: 1640 K PACKAGE LOCATION: gnubiff-2.2.8-i486-1_SBo.tgz PACKAGE DESCRIPTION: gnubiff: gnubiff (GTK+2 mail notification program) gnubiff: gnubiff: gnubiff is a mail notification program that checks for gnubiff: mail and displays headers when new mail has arrived. gnubiff: gnubiff: Homepage: http://gnubiff.sourceforge.net gnubiff: gnubiff: gnubiff: gnubiff: gnubiff: FILE LIST: ./ install/ install/doinst.sh install/slack-desc usr/ usr/bin/ usr/bin/gnubiff usr/doc/ usr/doc/gnubiff-2.2.8/ usr/doc/gnubiff-2.2.8/ABOUT-NLS usr/doc/gnubiff-2.2.8/AUTHORS usr/doc/gnubiff-2.2.8/COPYING usr/doc/gnubiff-2.2.8/ChangeLog usr/doc/gnubiff-2.2.8/INSTALL usr/doc/gnubiff-2.2.8/LICENSE usr/doc/gnubiff-2.2.8/NEWS usr/doc/gnubiff-2.2.8/README usr/doc/gnubiff-2.2.8/THANKS usr/doc/gnubiff-2.2.8/TODO usr/doc/gnubiff-2.2.8/gnubiff.SlackBuild usr/info/ usr/info/gnubiff.info.gz usr/man/ usr/man/man1/ usr/man/man1/gnubiff.1.gz usr/share/ usr/share/gnubiff/ usr/share/gnubiff/applet-gtk.glade usr/share/gnubiff/authentication.glade usr/share/gnubiff/certificate.glade usr/share/gnubiff/coin.wav usr/share/gnubiff/envelopes.png usr/share/gnubiff/gnubiff.png usr/share/gnubiff/mail.wav usr/share/gnubiff/popup.glade usr/share/gnubiff/preferences.glade usr/share/gnubiff/properties.glade usr/share/gnubiff/tux-awake.png usr/share/gnubiff/tux-big.png usr/share/gnubiff/tux-jump(64x64).png usr/share/gnubiff/tux-sleep(64x64).png usr/share/gnubiff/tux-sleep.png ... Joel -- Joel J. Adamson -- http://www.unc.edu/~adamsonj University of North Carolina at Chapel Hill CB #3280, Coker Hall Chapel Hill, NC 27599-3280 From vbatts at hashbangbash.com Thu May 14 14:23:19 2009 From: vbatts at hashbangbash.com (Vincent Batts) Date: Thu, 14 May 2009 09:23:19 -0500 Subject: [Slackbuilds-users] package of list of gems In-Reply-To: <4A0BB8C2.2000609@angleritech.com> References: <4A0BB8C2.2000609@angleritech.com> Message-ID: <2015330f0905140723m5cd63551h23b1cce72881cf14@mail.gmail.com> this mailing list is not entirely the place for this question, but you can install multiple gems at a time. check out `gem install --help` and gem does do dependency resolution, so you will not have to specify all packages in the chain, only the primary package needed, like in your question, "rails" will pull in a list of packages. vb 205.352.4112 http://hashbangbash.com/ On Thu, May 14, 2009 at 1:22 AM, Geetha wrote: > I need a package of list of ruby gems. > > basically we do install ruby gems , gem install rmagick -v=2.5.3 > gem install rails -v=2.1.1 > > I would appreciate any one help.. > > -- > > Best Regards, > > Geetha??S?| System and Software Engineer > email:?geetha at angleritech.com > > Visit us at Webinale, Germany (25th ? 27th May 2009) > > Click here for FREE TICKETS: > http://www.angleritech.com/company/latest-technology-news-events.html > > ANGLER Technologies India - Your Offshore Development Partner ? An ISO 9001 > Company > > Contact us for your high quality Software Outsourcing, E-Business Products > and Design Solutions > > > > web???????? :??? www.angleritech.com > tel????????? ?:??? +91 422 2312707, 2313938 > fax?????????? :??? +91 422 2313936 > address?? :?? ?1144 Trichy Road, Coimbatore, 641045, India > > offices??????:? ??India | USA | UK | Canada | Europe | UAE | South Africa | > Singapore | Hong Kong > > > > Disclaimer: The information in the email, files and communication are > strictly confidential and meant for the intended recipients. It may contain > proprietary information. If you are not an intended recipient; any form of > disclosure, copyright, distribution and any other means of use of > information is unauthorised and subject to legal implications. We do not > accept any liability for the transmission of incomplete, delayed > communication and recipients must check this email and any attachments for > the presence of viruses before downloading them. > > > > > > _______________________________________________ > 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 naitso at gmail.com Fri May 15 10:16:39 2009 From: naitso at gmail.com (Cristian Vedovato) Date: Fri, 15 May 2009 12:16:39 +0200 Subject: [Slackbuilds-users] openmotif 2.3.0 Message-ID: <6d54b66b0905150316h34436ac5i42de32e7bfe87f68@mail.gmail.com> Hi, i've noticed that openmotif 2.3.0 (package created with this slackbuild http://slackbuilds.org/repository/12.2/libraries/openmotif/), overwrites the original /usr/bin/tree found in the package tree-1.5.0-i486-1 Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From chaos.proton at gmail.com Mon May 18 14:28:17 2009 From: chaos.proton at gmail.com (Grissiom) Date: Mon, 18 May 2009 22:28:17 +0800 Subject: [Slackbuilds-users] acpitool won't build on current Message-ID: Hi all, Sorry that I know the build script is intent to 12.2 but I live in current and wish them be functional. But this time I failed: sh acpitool.SlackBuild acpitool-0.5/ acpitool-0.5/Makefile.in acpitool-0.5/ChangeLog acpitool-0.5/AUTHORS acpitool-0.5/man/ acpitool-0.5/man/Makefile.in acpitool-0.5/man/acpitool.1 acpitool-0.5/man/Makefile.am acpitool-0.5/acpitool.spec acpitool-0.5/configure acpitool-0.5/src/ acpitool-0.5/src/Makefile.in acpitool-0.5/src/toshiba.cpp acpitool-0.5/src/asus.h acpitool-0.5/src/cpu.h acpitool-0.5/src/ac_adapter.cpp acpitool-0.5/src/battery.cpp acpitool-0.5/src/battery.h acpitool-0.5/src/freq.h acpitool-0.5/src/thinkpad.cpp acpitool-0.5/src/Makefile.am acpitool-0.5/src/acpitool.h acpitool-0.5/src/ac_adapter.h acpitool-0.5/src/acpitool.cpp acpitool-0.5/src/asus.cpp acpitool-0.5/src/freq.cpp acpitool-0.5/src/thinkpad.h acpitool-0.5/src/cpu.cpp acpitool-0.5/src/main.cpp acpitool-0.5/src/toshiba.h acpitool-0.5/config.sub acpitool-0.5/depcomp acpitool-0.5/Makefile.am acpitool-0.5/config.h.in acpitool-0.5/install-sh acpitool-0.5/missing acpitool-0.5/NEWS acpitool-0.5/config.guess acpitool-0.5/configure.in acpitool-0.5/TODO acpitool-0.5/INSTALL acpitool-0.5/aclocal.m4 acpitool-0.5/COPYING acpitool-0.5/README /tmp/SBo/acpitool-0.5 checking for a BSD-compatible install... /bin/ginstall -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking build system type... i486-slackware-linux-gnu checking host system type... i486-slackware-linux-gnu checking for g++... g++ checking for C++ compiler default output file name... a.out checking whether the C++ compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking for style of include used by make... GNU checking dependency style of g++... gcc3 checking for gcc... gcc checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking dependency style of gcc... gcc3 checking for dirent.h that defines DIR... yes checking for library containing opendir... none required checking how to run the C preprocessor... gcc -E checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking for unistd.h... (cached) yes checking for an ANSI C-conforming const... yes checking whether closedir returns void... no checking for strdup... yes checking for memset... yes checking for strtol... yes checking for a BSD-compatible install... /bin/ginstall -c configure: creating ./config.status config.status: creating Makefile config.status: creating src/Makefile config.status: creating man/Makefile config.status: creating config.h config.status: executing depfiles commands +-----------------------------------------------------------------------------------+ | Run make && make install when the configure script has finished without problems. | +-----------------------------------------------------------------------------------+ make all-recursive make[1]: Entering directory `/tmp/SBo/acpitool-0.5' Making all in src /tmp/SBo/acpitool-0.5/src make[2]: Entering directory `/tmp/SBo/acpitool-0.5/src' if g++ -DHAVE_CONFIG_H -I. -I. -I.. -O2 -march=i486 -mtune=i686 -MT main.o -MD -MP -MF ".deps/main.Tpo" -c -o main.o main.cpp; \ then mv -f ".deps/main.Tpo" ".deps/main.Po"; else rm -f ".deps/main.Tpo"; exit 1; fi if g++ -DHAVE_CONFIG_H -I. -I. -I.. -O2 -march=i486 -mtune=i686 -MT acpitool.o -MD -MP -MF ".deps/acpitool.Tpo" -c -o acpitool.o acpitool.cpp; \ then mv -f ".deps/acpitool.Tpo" ".deps/acpitool.Po"; else rm -f ".deps/acpitool.Tpo"; exit 1; fi acpitool.cpp: In function 'int Has_ACPI(char*)': acpitool.cpp:60: warning: deprecated conversion from string constant to 'char*' acpitool.cpp:61: warning: deprecated conversion from string constant to 'char*' acpitool.cpp: In function 'int Get_Kernel_Version(char*, int)': acpitool.cpp:133: warning: deprecated conversion from string constant to 'char*' acpitool.cpp: In function 'int Set_Kernel_Version()': acpitool.cpp:181: warning: deprecated conversion from string constant to 'char*' acpitool.cpp: In function 'int Do_Thermal_Info(int, int)': acpitool.cpp:222: warning: deprecated conversion from string constant to 'char*' acpitool.cpp: In function 'int Do_Fan_Info(int)': acpitool.cpp:347: warning: deprecated conversion from string constant to 'char*' acpitool.cpp: In function 'int Show_WakeUp_Devices(int)': acpitool.cpp:403: warning: deprecated conversion from string constant to 'char*' acpitool.cpp: In function 'int Toggle_WakeUp_Device(int, int)': acpitool.cpp:450: warning: deprecated conversion from string constant to 'char*' acpitool.cpp: In function 'int Do_Suspend(int)': acpitool.cpp:516: warning: deprecated conversion from string constant to 'char*' acpitool.cpp:517: warning: deprecated conversion from string constant to 'char*' acpitool.cpp:523: warning: deprecated conversion from string constant to 'char*' acpitool.cpp:524: warning: deprecated conversion from string constant to 'char*' acpitool.cpp:527: warning: deprecated conversion from string constant to 'char*' acpitool.cpp:530: warning: deprecated conversion from string constant to 'char*' acpitool.cpp:531: warning: deprecated conversion from string constant to 'char*' if g++ -DHAVE_CONFIG_H -I. -I. -I.. -O2 -march=i486 -mtune=i686 -MT ac_adapter.o -MD -MP -MF ".deps/ac_adapter.Tpo" -c -o ac_adapter.o ac_adapter.cpp; \ then mv -f ".deps/ac_adapter.Tpo" ".deps/ac_adapter.Po"; else rm -f ".deps/ac_adapter.Tpo"; exit 1; fi ac_adapter.cpp: In function 'int Do_AC_Info(int)': ac_adapter.cpp:58: warning: deprecated conversion from string constant to 'char*' ac_adapter.cpp: In function 'int Do_AC_Info_Proc(int)': ac_adapter.cpp:95: warning: deprecated conversion from string constant to 'char*' ac_adapter.cpp: In function 'int Do_AC_Info_Sys()': ac_adapter.cpp:153: warning: deprecated conversion from string constant to 'char*' if g++ -DHAVE_CONFIG_H -I. -I. -I.. -O2 -march=i486 -mtune=i686 -MT toshiba.o -MD -MP -MF ".deps/toshiba.Tpo" -c -o toshiba.o toshiba.cpp; \ then mv -f ".deps/toshiba.Tpo" ".deps/toshiba.Po"; else rm -f ".deps/toshiba.Tpo"; exit 1; fi toshiba.cpp: In function 'int Has_Toshiba_ACPI()': toshiba.cpp:48: warning: deprecated conversion from string constant to 'char*' toshiba.cpp: In function 'int Do_Toshiba_Fan_Info()': toshiba.cpp:85: warning: deprecated conversion from string constant to 'char*' toshiba.cpp:107: error: 'strncmp' was not declared in this scope toshiba.cpp: In function 'int Do_LCD_Info()': toshiba.cpp:135: warning: deprecated conversion from string constant to 'char*' toshiba.cpp: In function 'int Force_Fan(int)': toshiba.cpp:169: warning: deprecated conversion from string constant to 'char*' toshiba.cpp: In function 'int Set_LCD_Level(int)': toshiba.cpp:203: warning: deprecated conversion from string constant to 'char*' toshiba.cpp: In function 'int Do_Video_Info()': toshiba.cpp:234: warning: deprecated conversion from string constant to 'char*' toshiba.cpp:255: error: 'strncmp' was not declared in this scope toshiba.cpp:264: error: 'strncmp' was not declared in this scope toshiba.cpp:275: error: 'strncmp' was not declared in this scope make[2]: *** [toshiba.o] Error 1 make[2]: Leaving directory `/tmp/SBo/acpitool-0.5/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/tmp/SBo/acpitool-0.5' make: *** [all] Error 2 is there anyway to survive? Thanks in advance. -- Cheers, Grissiom -------------- next part -------------- An HTML attachment was scrubbed... URL: From chaos.proton at gmail.com Mon May 18 14:50:43 2009 From: chaos.proton at gmail.com (Grissiom) Date: Mon, 18 May 2009 22:50:43 +0800 Subject: [Slackbuilds-users] acpitool won't build on current In-Reply-To: References: Message-ID: Hi all, Sorry that I know the build script is intent to 12.2 but I live in current and wish them be functional. But this time I failed: sh acpitool.SlackBuild ... checking for memset... yes checking for strtol... yes checking for a BSD-compatible install... /bin/ginstall -c configure: creating ./config.status config.status: creating Makefile config.status: creating src/Makefile config.status: creating man/Makefile config.status: creating config.h config.status: executing depfiles commands +-----------------------------------------------------------------------------------+ | Run make && make install when the configure script has finished without problems. | +-----------------------------------------------------------------------------------+ make all-recursive make[1]: Entering directory `/tmp/SBo/acpitool-0.5' Making all in src /tmp/SBo/acpitool-0.5/src make[2]: Entering directory `/tmp/SBo/acpitool-0.5/src' if g++ -DHAVE_CONFIG_H -I. -I. -I.. -O2 -march=i486 -mtune=i686 -MT main.o -MD -MP -MF ".deps/main.Tpo" -c -o main.o main.cpp; \ then mv -f ".deps/main.Tpo" ".deps/main.Po"; else rm -f ".deps/main.Tpo"; exit 1; fi if g++ -DHAVE_CONFIG_H -I. -I. -I.. -O2 -march=i486 -mtune=i686 -MT acpitool.o -MD -MP -MF ".deps/acpitool.Tpo" -c -o acpitool.o acpitool.cpp; \ then mv -f ".deps/acpitool.Tpo" ".deps/acpitool.Po"; else rm -f ".deps/acpitool.Tpo"; exit 1; fi acpitool.cpp: In function 'int Has_ACPI(char*)': acpitool.cpp:60: warning: deprecated conversion from string constant to 'char*' acpitool.cpp:61: warning: deprecated conversion from string constant to 'char*' acpitool.cpp: In function 'int Get_Kernel_Version(char*, int)': acpitool.cpp:133: warning: deprecated conversion from string constant to 'char*' acpitool.cpp: In function 'int Set_Kernel_Version()': acpitool.cpp:181: warning: deprecated conversion from string constant to 'char*' acpitool.cpp: In function 'int Do_Thermal_Info(int, int)': acpitool.cpp:222: warning: deprecated conversion from string constant to 'char*' acpitool.cpp: In function 'int Do_Fan_Info(int)': acpitool.cpp:347: warning: deprecated conversion from string constant to 'char*' acpitool.cpp: In function 'int Show_WakeUp_Devices(int)': acpitool.cpp:403: warning: deprecated conversion from string constant to 'char*' acpitool.cpp: In function 'int Toggle_WakeUp_Device(int, int)': acpitool.cpp:450: warning: deprecated conversion from string constant to 'char*' acpitool.cpp: In function 'int Do_Suspend(int)': acpitool.cpp:516: warning: deprecated conversion from string constant to 'char*' acpitool.cpp:517: warning: deprecated conversion from string constant to 'char*' acpitool.cpp:523: warning: deprecated conversion from string constant to 'char*' acpitool.cpp:524: warning: deprecated conversion from string constant to 'char*' acpitool.cpp:527: warning: deprecated conversion from string constant to 'char*' acpitool.cpp:530: warning: deprecated conversion from string constant to 'char*' acpitool.cpp:531: warning: deprecated conversion from string constant to 'char*' if g++ -DHAVE_CONFIG_H -I. -I. -I.. -O2 -march=i486 -mtune=i686 -MT ac_adapter.o -MD -MP -MF ".deps/ac_adapter.Tpo" -c -o ac_adapter.o ac_adapter.cpp; \ then mv -f ".deps/ac_adapter.Tpo" ".deps/ac_adapter.Po"; else rm -f ".deps/ac_adapter.Tpo"; exit 1; fi ac_adapter.cpp: In function 'int Do_AC_Info(int)': ac_adapter.cpp:58: warning: deprecated conversion from string constant to 'char*' ac_adapter.cpp: In function 'int Do_AC_Info_Proc(int)': ac_adapter.cpp:95: warning: deprecated conversion from string constant to 'char*' ac_adapter.cpp: In function 'int Do_AC_Info_Sys()': ac_adapter.cpp:153: warning: deprecated conversion from string constant to 'char*' if g++ -DHAVE_CONFIG_H -I. -I. -I.. -O2 -march=i486 -mtune=i686 -MT toshiba.o -MD -MP -MF ".deps/toshiba.Tpo" -c -o toshiba.o toshiba.cpp; \ then mv -f ".deps/toshiba.Tpo" ".deps/toshiba.Po"; else rm -f ".deps/toshiba.Tpo"; exit 1; fi toshiba.cpp: In function 'int Has_Toshiba_ACPI()': toshiba.cpp:48: warning: deprecated conversion from string constant to 'char*' toshiba.cpp: In function 'int Do_Toshiba_Fan_Info()': toshiba.cpp:85: warning: deprecated conversion from string constant to 'char*' toshiba.cpp:107: error: 'strncmp' was not declared in this scope toshiba.cpp: In function 'int Do_LCD_Info()': toshiba.cpp:135: warning: deprecated conversion from string constant to 'char*' toshiba.cpp: In function 'int Force_Fan(int)': toshiba.cpp:169: warning: deprecated conversion from string constant to 'char*' toshiba.cpp: In function 'int Set_LCD_Level(int)': toshiba.cpp:203: warning: deprecated conversion from string constant to 'char*' toshiba.cpp: In function 'int Do_Video_Info()': toshiba.cpp:234: warning: deprecated conversion from string constant to 'char*' toshiba.cpp:255: error: 'strncmp' was not declared in this scope toshiba.cpp:264: error: 'strncmp' was not declared in this scope toshiba.cpp:275: error: 'strncmp' was not declared in this scope make[2]: *** [toshiba.o] Error 1 make[2]: Leaving directory `/tmp/SBo/acpitool-0.5/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/tmp/SBo/acpitool-0.5' make: *** [all] Error 2 is there anyway to survive? Thanks in advance. -- Cheers, Grissiom -------------- next part -------------- An HTML attachment was scrubbed... URL: From chaos.proton at gmail.com Mon May 18 15:07:14 2009 From: chaos.proton at gmail.com (Grissiom) Date: Mon, 18 May 2009 23:07:14 +0800 Subject: [Slackbuilds-users] acpitool won't build on current Message-ID: Hi all, Sorry that I know the build script is intent to 12.2 but I live in current and wish them be functional. But this time I failed, the attachment is the error message. (For some reason if I copy the msg in mail it will be rejected...) Is there anyway to survive? Thanks in advance. -- Cheers, Grissiom -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: msg Type: application/octet-stream Size: 5089 bytes Desc: not available URL: From rworkman at slackbuilds.org Mon May 18 15:54:13 2009 From: rworkman at slackbuilds.org (Robby Workman) Date: Mon, 18 May 2009 10:54:13 -0500 Subject: [Slackbuilds-users] acpitool won't build on current In-Reply-To: References: Message-ID: <20090518105413.628e4c1f@liberty.rlwhome.lan> On Mon, 18 May 2009 22:50:43 +0800 Grissiom wrote: > Hi all, > > Sorry that I know the build script is intent to 12.2 but I live in > current and wish them be functional. But this time I failed: > ... > toshiba.cpp:255: error: 'strncmp' was not declared in this scope > toshiba.cpp:264: error: 'strncmp' was not declared in this scope > toshiba.cpp:275: error: 'strncmp' was not declared in this scope > make[2]: *** [toshiba.o] Error 1 > make[2]: Leaving directory `/tmp/SBo/acpitool-0.5/src' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/tmp/SBo/acpitool-0.5' > make: *** [all] Error 2 > > is there anyway to survive? Thanks in advance. Apply the attached patch to include string.h in toshiba.cpp and freq.cpp -RW -------------- next part -------------- A non-text attachment was scrubbed... Name: acpitool-0.5-add_string.h.patch Type: text/x-patch Size: 865 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From humanreadable at yahoo.com Mon May 18 17:12:53 2009 From: humanreadable at yahoo.com (Darrell Anderson) Date: Mon, 18 May 2009 10:12:53 -0700 (PDT) Subject: [Slackbuilds-users] Opera 9.64 and Flash Plugin Message-ID: <738500.38384.qm@web37503.mail.mud.yahoo.com> Greetings, Recently I decided to test Opera 9.64 (from slackbuilds.org). I could not get the Flash plugin (from slackbuilds.org) to function in Opera. The plugin functions fine in Firefox 3.10. I found a discussion about the problem at LQ: https://www.linuxquestions.org/questions/slackware-14/slackware-flashplayer-10-on-slackware-12.2-and-opera-9.63-692295/ The remedy that finally succeeded for me is in post No. 14: https://www.linuxquestions.org/questions/showthread.php?p=3523646#post3523646 I posted my gratitude and comments in post No. 16: https://www.linuxquestions.org/questions/showthread.php?p=3543971#post3543971 The point to all of this is the Opera and Flash build script commentations imply that Flash should "just work" with Opera. This was not the case for me and apparently some others too. As I mentioned in my LQ post, I found no package that creates these sym links. I don't know why the build scripts succeed for some people and fails for others. Perhaps a check in a doinst.sh will resolve the problem. Create the sym links if they are missing. I'm not a a member of this list. You can contact me by email or at the LQ thread. I hope this helps. Thanks again. Darrell Anderson http://humanreadable.nfshost.com/ From rworkman at slackbuilds.org Mon May 18 17:24:56 2009 From: rworkman at slackbuilds.org (Robby Workman) Date: Mon, 18 May 2009 12:24:56 -0500 Subject: [Slackbuilds-users] Opera 9.64 and Flash Plugin In-Reply-To: <738500.38384.qm@web37503.mail.mud.yahoo.com> References: <738500.38384.qm@web37503.mail.mud.yahoo.com> Message-ID: <20090518122456.76f4d7d1@liberty.rlwhome.lan> On Mon, 18 May 2009 10:12:53 -0700 (PDT) Darrell Anderson wrote: > > Greetings, > > Recently I decided to test Opera 9.64 (from slackbuilds.org). I could > not get the Flash plugin (from slackbuilds.org) to function in Opera. > The plugin functions fine in Firefox 3.10. I found a discussion about > the problem at LQ: > > https://www.linuxquestions.org/questions/slackware-14/slackware-flashplayer-10-on-slackware-12.2-and-opera-9.63-692295/ > > The remedy that finally succeeded for me is in post No. 14: > > https://www.linuxquestions.org/questions/showthread.php?p=3523646#post3523646 > > I posted my gratitude and comments in post No. 16: > > https://www.linuxquestions.org/questions/showthread.php?p=3543971#post3543971 > > The point to all of this is the Opera and Flash build script > commentations imply that Flash should "just work" with Opera. This > was not the case for me and apparently some others too. > > As I mentioned in my LQ post, I found no package that creates these > sym links. I don't know why the build scripts succeed for some people > and fails for others. > > Perhaps a check in a doinst.sh will resolve the problem. Create the > sym links if they are missing. > > I'm not a a member of this list. You can contact me by email or at > the LQ thread. (CC'd Darrell) It appears as if the seamonkey package is not installed perhaps. -RW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From rw at rlworkman.net Mon May 18 17:32:59 2009 From: rw at rlworkman.net (Robby Workman) Date: Mon, 18 May 2009 12:32:59 -0500 Subject: [Slackbuilds-users] Test Message Message-ID: <20090518123259.175e9245@liberty.rlwhome.lan> This is a test message - troubleshooting some mail issues on the server... -RW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From humanreadable at yahoo.com Mon May 18 19:21:42 2009 From: humanreadable at yahoo.com (Darrell Anderson) Date: Mon, 18 May 2009 12:21:42 -0700 (PDT) Subject: [Slackbuilds-users] Opera 9.64 and Flash Plugin Message-ID: <14407.19136.qm@web37504.mail.mud.yahoo.com> Hi, I'm willing to accept that Seamonkey could be the problem. I don't have the package installed. When I browse the package contents I do not find anything creating the missing links. Just confused, not arguing. :-) Nonetheless, might be a nice idea to have the Opera or Flash build script or doinst.sh create the links if missing? Or a note in the build script page addressing the need for the links? I realize there is a presumption of a full installation, but I wonder whether that is realistic. Again, just wondering, not arguing... Darrell Anderson http://humanreadable.nfshost.com/ > It appears as if the seamonkey package is not installed perhaps. From rworkman at slackbuilds.org Mon May 18 19:37:18 2009 From: rworkman at slackbuilds.org (Robby Workman) Date: Mon, 18 May 2009 14:37:18 -0500 Subject: [Slackbuilds-users] Opera 9.64 and Flash Plugin In-Reply-To: <14407.19136.qm@web37504.mail.mud.yahoo.com> References: <14407.19136.qm@web37504.mail.mud.yahoo.com> Message-ID: <20090518143718.796d7ca1@liberty.rlwhome.lan> On Mon, 18 May 2009 12:21:42 -0700 (PDT) Darrell Anderson wrote: > > Hi, > > I'm willing to accept that Seamonkey could be the problem. I don't > have the package installed. When I browse the package contents I do > not find anything creating the missing links. Just confused, not > arguing. :-) No need for symlinks: $ cat /etc/ld.so.conf /usr/local/lib /usr/i486-slackware-linux/lib /usr/lib/seamonkey > Nonetheless, might be a nice idea to have the Opera or Flash build > script or doinst.sh create the links if missing? Or a note in the > build script page addressing the need for the links? I realize there > is a presumption of a full installation, but I wonder whether that is > realistic. Again, just wondering, not arguing... As you said, there is the presumption of a full installation of Slackware, so we won't be creating the symlinks here. -RW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From humanreadable at yahoo.com Mon May 18 21:20:43 2009 From: humanreadable at yahoo.com (Darrell Anderson) Date: Mon, 18 May 2009 14:20:43 -0700 (PDT) Subject: [Slackbuilds-users] Opera 9.64 and Flash Plugin Message-ID: <295503.92050.qm@web37508.mail.mud.yahoo.com> Hi, I don't pretend to understand all that is involved with ld.so.conf, but I see the entry for seamonkey and presume that is where the connection is made (after running ldd?). Good enough. Okay, how about a short precautionary note in the build script page that Flash won't work as expected with Opera if Seamonkey is not installed? Just an idea --- that's all for now. Thanks. Darrell Anderson http://humanreadable.nfshost.com/ > No need for symlinks: > > $ cat /etc/ld.so.conf > /usr/local/lib > /usr/i486-slackware-linux/lib > /usr/lib/seamonkey From xma at gnu.org Mon May 18 21:43:53 2009 From: xma at gnu.org (Xavier Maillard) Date: Mon, 18 May 2009 23:43:53 +0200 Subject: [Slackbuilds-users] can't compile nethack In-Reply-To: <87ljp2yimh.wl%xma@gnu.org> References: <87ljp2yimh.wl%xma@gnu.org> Message-ID: <871vqmxf1i.wl%xma@gnu.org> At Tue, 12 May 2009 07:50:46 +0200, Xavier Maillard wrote: Hi, > > I tried to install nethack using SBo script but it failed. As far as > I can see, SBo is compiling both terminal version and an X11 flavour > of it. Problem is that it is not precised what one needs in order to > successfully compile all flavours. > > What would be even better than compiling *all* versions would be to > offer user a way to only compile the flavour he really wants (in my > case, I would choose terminal only). > > What are the requirements so far with SBo script ? I am still blocked with this slackbuild. Any idea ? best idea to come would be to have several nethack slackbuilds building a "flavour" of nethack (with X or without, etc..). That supposes the current slackbuild is able to offer a minimum of configuration from the user though (choose the right configuration file for example). Xavier From xma at gnu.org Mon May 18 22:17:46 2009 From: xma at gnu.org (Xavier Maillard) Date: Tue, 19 May 2009 00:17:46 +0200 Subject: [Slackbuilds-users] can't compile nethack References: <87ljp2yimh.wl%xma@gnu.org> Message-ID: <87tz3ivywl.wl%xma@gnu.org> At Tue, 12 May 2009 07:50:46 +0200, Xavier Maillard wrote: Hi, > > I tried to install nethack using SBo script but it failed. As far as > I can see, SBo is compiling both terminal version and an X11 flavour > of it. Problem is that it is not precised what one needs in order to > successfully compile all flavours. > > What would be even better than compiling *all* versions would be to > offer user a way to only compile the flavour he really wants (in my > case, I would choose terminal only). > > What are the requirements so far with SBo script ? I am still blocked with this slackbuild. Any idea ? best idea to come would be to have several nethack slackbuilds building a "flavour" of nethack (with X or without, etc..). That supposes the current slackbuild is able to offer a minimum of configuration from the user though (choose the right configuration file for example). Xavier _______________________________________________ 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 xma at gnu.org Mon May 18 22:22:58 2009 From: xma at gnu.org (Xavier Maillard) Date: Tue, 19 May 2009 00:22:58 +0200 Subject: [Slackbuilds-users] can't compile nethack References: <87ljp2yimh.wl%xma@gnu.org> Message-ID: <87r5ymvynx.wl%xma@gnu.org> At Tue, 12 May 2009 07:50:46 +0200, Xavier Maillard wrote: Hi, > > I tried to install nethack using SBo script but it failed. As far as > I can see, SBo is compiling both terminal version and an X11 flavour > of it. Problem is that it is not precised what one needs in order to > successfully compile all flavours. > > What would be even better than compiling *all* versions would be to > offer user a way to only compile the flavour he really wants (in my > case, I would choose terminal only). > > What are the requirements so far with SBo script ? I am still blocked with this slackbuild. Any idea ? best idea to come would be to have several nethack slackbuilds building a "flavour" of nethack (with X or without, etc..). That supposes the current slackbuild is able to offer a minimum of configuration from the user though (choose the right configuration file for example). Xavier From xma at gnu.org Mon May 18 22:16:31 2009 From: xma at gnu.org (Xavier MAILLARD) Date: Tue, 19 May 2009 00:16:31 +0200 Subject: [Slackbuilds-users] can't compile nethack In-Reply-To: <87r5ymvynx.wl%xma@gnu.org> References: <87ljp2yimh.wl%xma@gnu.org> <87r5ymvynx.wl%xma@gnu.org> Message-ID: <20090519001631.4487385e@homer.maillard.im> Sorry for the multiple copies. I received bounce messages and thought my mail never hitted the list :/ Apologies Xavier From rworkman at slackbuilds.org Tue May 19 03:29:56 2009 From: rworkman at slackbuilds.org (Robby Workman) Date: Mon, 18 May 2009 22:29:56 -0500 Subject: [Slackbuilds-users] Bounce messages re mail loop Message-ID: <20090518222956.7bc8257f@liberty.rlwhome.lan> It seems that a problem has come up within the last 24 hours or so in which valid mails are getting bounced, but not bounced. In other words, the sender is being informed of a bounce due to a mail loop on the server, but the mail is going through anyway. We have no idea exactly what's going on, because none of us have made any changes to the mail configuration, and of course, the configuration looks correct :-) rob0 is investigating and considering a call to Ghostbusters, so be patient. In the meantime, ignore any bounced messages - status updates will be posted here as we get them. Tue May 19 03:29:46 UTC 2009 -RW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From rob0 at slackbuilds.org Tue May 19 05:16:52 2009 From: rob0 at slackbuilds.org (Rob McGee) Date: Tue, 19 May 2009 00:16:52 -0500 Subject: [Slackbuilds-users] Bounce messages re mail loop In-Reply-To: <20090518222956.7bc8257f@liberty.rlwhome.lan> References: <20090518222956.7bc8257f@liberty.rlwhome.lan> Message-ID: <200905190016.52571.rob0@slackbuilds.org> On Mon May 18 2009 22:29:56 Robby Workman wrote: > It seems that a problem has come up within the last 24 hours or so in > which valid mails are getting bounced, but not bounced. In other > words, the sender is being informed of a bounce due to a mail loop on > the server, but the mail is going through anyway. > > We have no idea exactly what's going on, because none of us have made > any changes to the mail configuration, and of course, the > configuration looks correct :-) rob0 is investigating and > considering a call to Ghostbusters, so be patient. In the meantime, > ignore any bounced messages - status updates will be posted here as > we get them. Ghostbusters were not needed. It was / is correct on our end. Every bounce came through one or more hosts at mo-p05-ob.rzone.de[81.169.146.18x] (x=0-2). I am still not entirely sure what they did, but my guess is that they have done a virtual alias or user .forward of slackbuilds-users at slackbuilds.org going *to* slackbuilds-users at slackbuilds.org. Obviously NOT a good idea. This is coming with the same envelope sender on each. As of a few minutes ago, those hosts are blocked from sending mail to slackbuilds-users at slackbuilds.org. The rejection message will instruct the recipient to contact postmaster at slackbuilds.org to resolve the issue. There were 15 total bounces sent today, beginning at May 18 14:36 and ending May 19 03:37 (times are UTC.) If you got one, sorry. I think there's an exploitable issue here, so I will follow up to the postfix-users mailing list. It's not Mailman's fault, since the forwarding loop was detected and the bounces generated before the Mailman posting software was invoked. Any problems, questions or concerns, please let me know, here or offlist. Rob - /dev/rob0 From xgizzmo at slackbuilds.org Tue May 19 06:06:06 2009 From: xgizzmo at slackbuilds.org (xgizzmo at slackbuilds.org) Date: Tue, 19 May 2009 02:06:06 -0400 Subject: [Slackbuilds-users] Updates - 20090519 Message-ID: <200905190206.07083.xgizzmo@slackbuilds.org> First, The SlackBuilds.org admin team would like to welcome Chess Griffin and Heinz Wiesinger as our newest members. They have both been outstanding contributers. We look forward to working with them. Now the not so fun stuff, In trying to resolve some conflicts with Slackware's perl package, we realized that many of the perl modules were included in Slackwares perl package and have been removed for that reason. The only thing these modules clobbered were the man pages, the modules themselves were installed to a different location and did not overwrite the Slackware version. We recommend you remove any of these modules you may have installed. Tue May 19 04:22:02 UTC 2009 desktop/dwm: Removed patches/config.patch and merged miscellaneous script cleanups. Thanks to Tom Canich. --chess desktop/ffmpegthumbnailer: Updated for version 1.5.0. Thanks to Frank Caraballo. --pprkut desktop/gtk-smooth-engine: Added - gtk-smooth-engine is intended to be a small, fast, and configurable GTK2 theme. Thanks to Joel J. Adamson. --chess desktop/google-gadgets-for-linux: Added - Google Gadgets for Linux provides a platform for running desktop gadgets. Thanks to jkwood. --michiel desktop/wmclock: Added - wmclock is an applet which displays the date and time in a dockable tile in the same style as the clock from the NEXTSTEP operating system. Thanks to B. Watson. --rworkman desktop/wmdate: Added - wmDate is a date-display utility for WindowMaker. Thanks to Cezary M. Kruk. --rworkman desktop/wmdrawer: Added - wmdrawer is a dock application (dockapp) which provides a drawer (retractable button bar) to launch applications. Thanks to Cezary M. Kruk for the submission, and thanks to B. Watson for the valuable input on testing this. --rworkman desktop/wmmon: Added - WMMon monitors the your CPU, Disk I/O, Memory and Swap usage, and shows an average load for CPU and Disk I/O. Thanks to B. Watson. --rworkman desktop/xxkb: Added - xxkb is a keyboard layout switcher and indicator. Thanks to Cyril A. Sluchanko. --rworkman development/perl-extutils-cbuilder: Removed - as part of trying to resolve some conflicts with Slackware's perl package, we realized that this is already in there. --chess,dsomero,pprkut development/perl-extutils-parsexs: Removed - same as perl-extutils-cbuilder --chess,dsomero,pprkut development/perl-module-build: Removed - same as perl-extutils-cbuilder --chess,dsomero,pprkut development/qt-creator: Added - qt-creator is a new cross-platform integrated development environment. Thanks to Andre Barboza. --dsomero development/Scalar-List-Utils: Removed - same as perl-extutils-cbuilder --chess,dsomero,pprkut games/nevernoid: Added - nevernoid is a clone of the game "Arkanoid" with extra powerups. Thanks to B. Watson. --rworkman games/Scorched3D: Updated for version 42.1. Thanks to Heinz Wiesinger. --chess,rworkman libraries/Compress-Raw-Zlib: Removed - same as perl-extutils-cbuilder --chess,dsomero,pprkut libraries/Compress-Zlib: Removed - same as perl-extutils-cbuilder --chess,dsomero,pprkut libraries/IO-Compress-Base: Removed - same as perl-extutils-cbuilder --chess,dsomero,pprkut libraries/IO-Compress-Zlib: Removed - same as perl-extutils-cbuilder --chess,dsomero,pprkut libraries/IO-Zlib: Removed - same as perl-extutils-cbuilder --chess,dsomero,pprkut libraries/cracklib: Added - CrackLib is a library containing a C function which may be used in a "passwd"-like program. Thanks to Christopher Walker. --rworkman libraries/libdbi: Added - libdbi implements a database-independent abstraction layer in C similar to the DBI/DBD layer in Perl. Thanks to Michal Bialozor. --rworkman libraries/libdvi-drivers: Added - the libdbi-drivers project maintains drivers for the libdbi database abstraction layer. Thanks to Michal Bialozor. --rworkman libraries/libdockapp: Added - libDockApp is a library for developing Window Maker dockapps. Thanks to Cezary M. Kruk. --rworkman libraries/libvirt: Added - libvirt is a toolkit to interact with the virtualization capabilities of recent versions of Linux (and other OSes). Thanks to Michal Bialozor. --rworkman libraries/python-spidermonkey: Added - this is a Python/JavaScript bridge module making use of Mozilla's spidermonkey. Thanks to Larry Hajali. --rworkman misc/flashrom: Added - Flashrom is a utility for reading, writing, verifying and erasing flash ROM chips. Thanks to Niklas "Nille" ?kerstr?m. --pprkut multimedia/transcode: Updated for version 1.1.2. Thanks to Heinz Wiesinger. --rworkman network/arora: Added - Arora is a simple cross platform web browser. Thanks to David Somero. --pprkut network/js: Tweaked the README to add "js" in there somewhere for easier searching by sbopkg. Thanks to David Woodfall. --rworkman network/museek+: Updated for version 0.2 and renamed from "museek-plus" since our site backend can handle the "+" characters now. Thanks to Iskar Enev. --rworkman network/museek-plus: Removed (renamed to museek+). --rworkman network/qwit: Added - Qwit is a free cross-platform Qt4-based Twitter client Thanks to Larry Hajali --pprkut network/tucan: Added - tucan manager is designed for automatic management of downloads and uploads at hosting sites like rapidshare or megaupload. Thanks to Nai. --rworkman office/adobe-reader: Updated to version 9.1.1, which is a security fix. See http://www.adobe.com/support/security/bulletins/apsb09-06.html for more information. Thanks to Heinz Wiesinger. --rworkman system/acpitool: Updated with a patch to fix compile errors on -current. The patch isn't needed on 12.2, but it won't hurt anything either. Thanks to grissiom for the report. --rworkman system/atari++: Added - atari++ a Unix based emulator of the Atari eight bit computers. Thanks to B. Watson. --dsomero system/atari800: Added - atari800 an Atari 800, 800XL, 130XE and 5200 emulator. Thanks to B. Watson. --dsomero system/atari800_os++: Added - atari800_os++ an Open Source rewrite of the ROM operating system for the Atari XL/XE 8-bit computers. Thanks to B. Watson. --dsomero system/atari800_roms: Added - atari800_roms is the operating system and BASIC language ROM images from the Atari 800 and 800XL computers. Thanks to B. Watson. --dsomero system/atarisio: Added - atarisio is a disk emulator for use with Atari 8-bit computer and SIO2PC. Thanks to B. Watson. --dsomero system/hddtemp: Added - hddtemp is a small and daemonizable utility designed to read the S.M.A.R.T. information from the given hard disk and report the temperature of the disk. Thanks to Zordrak --pprkut system/smem: Added - smem is a tool that can give numerous reports on memory usage on Linux systems. Thanks to Dusan Stefanovic. --pprkut system/qemu: Updated to version 0.10.4. Thanks to Andrew Brouwers. --pprkut From rob0 at slackbuilds.org Tue May 19 07:07:29 2009 From: rob0 at slackbuilds.org (Rob McGee) Date: Tue, 19 May 2009 02:07:29 -0500 Subject: [Slackbuilds-users] Bounce messages re mail loop In-Reply-To: <200905190016.52571.rob0@slackbuilds.org> References: <20090518222956.7bc8257f@liberty.rlwhome.lan> <200905190016.52571.rob0@slackbuilds.org> Message-ID: <200905190207.29081.rob0@slackbuilds.org> On Tue May 19 2009 00:16:52 I wrote: stuff. I got a bounce myself. But this time it wasn't from us, it was from the perpetrator host. Sigh. Fortunately, it had enough information for me to identify and remove the subscriber. Look at your headers from list mail. You should see something like this ... Return-Path: That's what Postfix adds; that is the envelope sender. Our rogue subscriber had some sort of braindead filtering script which ignored the envelope sender, and reconstructed a NEW envelope based on the headers. That's why the messages were being reposted and bounced; this script sent them. Again, the subscriber is removed, so the problem is resolved until someone else does something equally silly. Rob - /dev/rob0 From xgizzmo at slackbuilds.org Wed May 20 02:54:06 2009 From: xgizzmo at slackbuilds.org (xgizzmo at slackbuilds.org) Date: Tue, 19 May 2009 22:54:06 -0400 Subject: [Slackbuilds-users] Updates - 20090520 Message-ID: <200905192254.06834.xgizzmo@slackbuilds.org> Wed May 20 01:18:14 UTC 2009 academic/R: Updated for version 2.9.0 and moved from development. Thanks to Joel J. Adamson. --dsomero audio/fluidsynth: Updated for version 1.0.9. Thanks to Heinz Wiesinger. --dsomero audio/ncmpc: Updated for version 0.14. Thanks to Andrew Brouwers and Slakmagik for the diff. --dsomero audio/Songbird: Updated for version 1.1.2_1042. Thanks to Michiel van Wessem. --dsomero desktop/QtCurve-Gtk2: Updated for version 0.62.8. Thanks to Michiel van Wessem. --dsomero desktop/QtCurve-KDE3: Updated for version 0.62.7. Thanks to Michiel van Wessem. --dsomero development/easygui: Updated for version 0.91. Thanks to LukenShiro. --dsomero development/geany: Updated for version 0.17. Thanks to Michiel van Wessem. --dsomero development/kdesvn: Updated for version 1.0.5. Thanks to Michiel van Wessem. --dsomero development/python-pmw: Updated SlackBuild. Thanks to LukenShiro. --dsomero development/R: Removed - moved to academic. development/re2c: Updated SlackBuild. Thanks to LukenShiro. --dsomero games/sms_sdl: Updated for version 0.9.4a_r7.1. Thanks to B. Watson. --dsomero games/wesnoth: Updated for version 1.6.1. Thanks to Michiel van Wessem. --dsomero libraries/fltk: Updated SlackBuild. Thanks to LukenShiro. --dsomero libraries/hdf5: Updated for version 1.8.3. Thanks to LukenShiro. --dsomero libraries/libkate: Updated for version 0.3.3. Thanks to Nishant Limbachia. --dsomero libraries/liblo: Updated for version 0.26. Thanks to Heinz Wiesinger. --dsomero libraries/libopenraw: Updated for version 0.0.7. Thanks to Michiel van Wessem. --dsomero libraries/libwww-perl: Updated for version 5.825. Thanks to LukenShiro. --dsomero libraries/perl-html-parser: Updated for version 3.60. Thanks to LukenShiro. --dsomero libraries/perl-net-dns: Updated for version 0.65. Thanks to LukenShiro. --dsomero libraries/reportlab: Updated for version 2.3. Thanks to LukenShiro. --dsomero libraries/SDL_gfx: Updated for version 2.0.19. Thanks to Michiel van Wessem. --dsomero multimedia/GoogleEarth: Updated for version 5.0.11733.9347. Thanks to Michiel van Wessem. --dsomero multimedia/smpeg: Updated for version r374. Thanks to Heinz Wiesinger. --dsomero network/efax-gtk: Updated SlackBuild. Thanks to LukenShiro. --dsomero network/gnubiff: Updated for version 2.2.11. Thanks to Joel Adamson. --dsomero network/linuxdcpp: Updated for version 1.0.3. Thanks to Niklas Nille ?kerstr?m. --dsomero network/phpmyadmin: Updated for version 3.1.4. Thanks to Nishant Limbachia. --dsomero network/shorewall-common: Updated for version 4.2.9. Thanks to Gregory Tourte. --dsomero network/shorewall-perl: Updated for version 4.2.9. Thanks to Gregory Tourte. --dsomero network/shorewall-shell: Updated for version 4.2.9. Thanks to Gregory Tourte. --dsomero network/shorewall6: Updated for version 4.2.9. Thanks to Gregory Tourte. --dsomero network/vnstat: Updated for version 1.7. Thanks to Michiel van Wessem. --dsomero office/freemind: Updated SlackBuild to include mimetype file. Thanks to Dhaby Xiloj. --dsomero office/gocr: Updated for version 0.47. Thanks to Nishant Limbachia. --dsomero office/homebank: Updated for version 4.0.3. Thanks to Erik Hanson. --dsomero office/htmldoc: Updated SlackBuild. Thanks to LukenShiro. --dsomero office/kmymoney2: Updated for version 0.9.3. Thanks to Michiel van Wessem. --dsomero office/openoffice.org: Updated for version 3.1.0. Thanks to Robby Workman. --chess office/openproj: Updated for version 1.4 totally rewritten SlackBuild that compiles from the source. Thanks to Chris Abela. --dsomero system/fsarchiver: Updated for version 0.5.4. Thanks to Nishant Limbachia. --dsomero system/ncdu: Updated for version 1.5. Thanks to Erik Hanson. --dsomero system/openct: Updated for version 0.6.16. Thanks to LukenShiro. --dsomero system/opensc: Updated for version 0.11.8. Thanks to LukenShiro. --dsomero system/pcsc-lite: Updated for version 1.5.3. Thanks to LukenShiro. --dsomero From adamsonj at email.unc.edu Thu May 21 14:55:02 2009 From: adamsonj at email.unc.edu (Joel J. Adamson ) Date: Thu, 21 May 2009 10:55:02 -0400 Subject: [Slackbuilds-users] Sage Message-ID: <4032.1242917702@email.unc.edu> Dear Slackers, I am in the middle of testing a SlackBuild for Sage (http://www.sagemath.org). Sage ties together a bunch of computer math systems, including numerical computation, computer algebra and other systems to make a unified, free software alternative to Mathematica and other proprietary math software. In order to make a unified build and not have _any_ dependencies, Sage installs a number of components in a local tree that are already available from SlackBuilds.org (e.g. scons, maxima). I do not anticipate any conflicts with existing packages, but is there any policy on a build like this? Thanks, Joel -- Joel J. Adamson -- http://www.unc.edu/~adamsonj University of North Carolina at Chapel Hill CB #3280, Coker Hall Chapel Hill, NC 27599-3280 From chaos.proton at gmail.com Thu May 21 16:14:30 2009 From: chaos.proton at gmail.com (Grissiom) Date: Fri, 22 May 2009 00:14:30 +0800 Subject: [Slackbuilds-users] mldonley.SlacBuild should be updated? Message-ID: <200905220014.31137.chaos.proton@gmail.com> Hi all, I see there are many updates in upstream of mldonkey, including "urgent security related bug-fix and effects all MLDonkey versions >= 2.8.4" (http://cvs.savannah.gnu.org/viewvc/mldonkey/mldonkey/distrib/ChangeLog?view=markup). But the SlackBuild for mldonley is still based on v2.9.4. I mailed the SlackBuild maintainer but get no reply yet. Maybe somebody else could fix it. -- Cheers, Grissiom -------------- next part -------------- An HTML attachment was scrubbed... URL: From josiahb at gmail.com Fri May 22 02:40:21 2009 From: josiahb at gmail.com (Josiah Boothby) Date: Thu, 21 May 2009 19:40:21 -0700 Subject: [Slackbuilds-users] Sage In-Reply-To: <4032.1242917702@email.unc.edu> References: <4032.1242917702@email.unc.edu> Message-ID: <6eb14ed10905211940v718fc9dcg982e4eec79350ffe@mail.gmail.com> > In order to make a unified build and not have _any_ dependencies, Sage > installs a number of components in a local tree that are already > available from SlackBuilds.org (e.g. scons, maxima). ?I do not > anticipate any conflicts with existing packages, but is there any policy > on a build like this? I can't answer about SBo policies, but I've had this sitting idly on a back burner of mine for a little while now. My brother is on the Sage dev team, so I asked him about this. His answer wasn't very direct, but could prove helpful (though I haven't had a chance to check it out). He told me that Sage has been packaged and is in the Ubuntu repositories, and the package maintainer went through a lot of work to do that; so my brother's advice was to see how the package is put together in Ubuntu, since that may remove (at least some of) the redundancies. Hope this is helps, Josiah From xgizzmo at slackbuilds.org Sat May 23 00:40:51 2009 From: xgizzmo at slackbuilds.org (xgizzmo at slackbuilds.org) Date: Fri, 22 May 2009 20:40:51 -0400 Subject: [Slackbuilds-users] Updates - 20090523 Message-ID: <200905222040.52036.xgizzmo@slackbuilds.org> Sat May 23 00:34:07 UTC 2009 office/openoffice.org: Incremented the BUILD variable to 4 since we started at 3 (sorry about that - my fault). Added support for x86_64 - thanks to necropresto for the enhancements. Added support for installing *all* extensions that might happen to be in the relevant directory - thanks to ivo at linvo.org for the patch and his patient explanation of exactly what was required. Fixed removal of the ttf fonts - thanks to Richard Hoyle for noticing. Let me know if there are any other issues. --rworkman From xgizzmo at slackbuilds.org Sun May 24 16:59:16 2009 From: xgizzmo at slackbuilds.org (xgizzmo at slackbuilds.org) Date: Sun, 24 May 2009 12:59:16 -0400 Subject: [Slackbuilds-users] Updates - 20090524 Message-ID: <200905241259.16684.xgizzmo@slackbuilds.org> Sun May 24 15:41:07 UTC 2009 academic/bibus: Added - bibus is a bibliographic and reference management software. Thanks to David Miller. --dsomero academic/rkward: Added - rkward strives to combine the power of the R-language with the (relative) ease of use of commercial statistical packages. Thanks to Germ??n M??rquez Mej??a. --dsomero academic/sympy: Added - sympy is a Python library for symbolic mathematics. Thanks to grissiom. --dsomero audio/audtty: Added - audtty is a simple application for controlling Audacious from the command line. Thanks to Manuel Mantilla. --dsomero audio/mac: Added - mac is a console frontend to Monkey's Audio. Thanks to Luis Henrique. --dsomero audio/mpc123: Added - mpc123 is a console Musepack audio player. Thanks to Luis Henrique. --dsomero audio/ncmpcpp: Added - ncmpcpp is almost exact clone of ncmpc (a curses based MPD client). Thanks to Juan Camilo Nore??a. --dsomero desktop/pclock: Added - pclock is Window Maker analog clock dockable application. Thanks to Cezary M. Kruk. --dsomero development/bouml: Added - bouml is a free UML 2 tool box. Thanks to David Negroni. --dsomero development/bouml_docs: Added - bouml_docs are the docs for bouml. Thanks to David Negroni. --dsomero development/pylint: Added - pylint is a python tool that checks if a module satisfies a coding standard. Thanks to grissiom. --dsomero development/shed: Added - shed is a hex editor written for unix/linux using ncurses. Thanks to David Woodfall. --dsomero games/supertuxkart-extra-karts: Added - supertuxkart-extra-karts adds extra karts for the game supertuxkart. Thanks to Larry Hajali. --dsomero games/supertuxkart-extra-tracks: Added - supertuxkart-extra-tracks adds extra tracks for the game supertuxkart. Thanks to Larry Hajali. --dsomero games/supertuxkart: Added - supertuxkart is a Free 3d kart racing game. Thanks to Larry Hajali. --dsomero libraries/cdk: Added - cdk tands for 'Curses Development Kit' and it currently contains 21 ready to use widgets. Thanks to Larry Hajali. --dsomero libraries/exiftool: Updated for version 7.67. Thanks to David Spencer. --chess libraries/libgadu: Added - libgadu is a library for Handling of Gadu-Gadu Instant Messaging. Thanks to M Slodkiewicz. --dsomero libraries/libiptc: Added - libiptc enables programs to communicate with netfilter bypassing iptables. Thanks to Pablo Oses. --dsomero libraries/libotf: Added - libotf is a library for handling OpenType fonts. Thanks to Larry Hajali. --dsomero libraries/logilab-astng: Added - logilab-astng is Python modules used by many python code checkers. Thanks to grissiom. --dsomero libraries/logilab-common: Added - logilab-common is Python modules used by Logilab's projects. Thanks to grissiom. --dsomero libraries/OpenSceneGraph: Added - OpenSceneGraph is an open source cross platform graphics toolkit. Thanks to Aleksandar Samardzic. --dsomero libraries/python-musicbrainz2: Added - python-musicbrainz2 is Python bindings for the MusicBrainz XML Web Service. Thanks to Larry Hajali. --dsomero libraries/sexy-python: Added - sexy-python is a set of Python bindings for libsexy. Thanks to Larry Hajali. --dsomero libraries/taglib-extras: Added - taglib-extras are unofficial TagLib file type plugins maintained by the Amarok project. Thanks to Heinz Wiesinger. --dsomero network/mod_python: Added - mod_python is a Python module for Apache. Thanks to Ben-Richard Ebbesvik. --dsomero network/wput: Added - wput is a utility for putting files using the FTP protocol from the command line. Thanks to Chris Abela. --dsomero office/cups-pdf: Updated for version 2.5.0. Thanks to Sebastien Ballet. --chess system/yeahconsole: Added - yeahconsole is a terminal emulator wrapper. Thanks to Pablo Santamaria. --dsomero From chaos.proton at gmail.com Mon May 25 05:38:21 2009 From: chaos.proton at gmail.com (Grissiom) Date: Mon, 25 May 2009 13:38:21 +0800 Subject: [Slackbuilds-users] mldonley.SlacBuild should be updated? In-Reply-To: <200905220014.31137.chaos.proton@gmail.com> References: <200905220014.31137.chaos.proton@gmail.com> Message-ID: On Fri, May 22, 2009 at 00:14, Grissiom wrote: > Hi all, > > > I see there are many updates in upstream of mldonkey, including "urgent > security related bug-fix and effects all MLDonkey versions >= 2.8.4" > ( > http://cvs.savannah.gnu.org/viewvc/mldonkey/mldonkey/distrib/ChangeLog?view=markup). > > But the SlackBuild for mldonley is still based on v2.9.4. I mailed the > SlackBuild maintainer but get no reply yet. Maybe somebody else could fix > it. > > Hello folks, Still get no reply from the maintainer, so nobody cares?... ;( I know you are busy these days ;) -- Cheers, Grissiom -------------- next part -------------- An HTML attachment was scrubbed... URL: From pwcazenave at gmail.com Tue May 26 09:02:47 2009 From: pwcazenave at gmail.com (Pierre Cazenave) Date: Tue, 26 May 2009 09:02:47 +0000 Subject: [Slackbuilds-users] Info on the SBo submissions page In-Reply-To: <4032.1242917702@email.unc.edu> References: <4032.1242917702@email.unc.edu> Message-ID: <4A1BB037.8040704@gmail.com> The info on the submissions page about what needs to be included in a successful slackbuild appears erroneous. At present, it's missing the LIBDIRSUFFIX variable, and is ambiguous with regards 64-bit support (including x86_64 compile flags, but saying 64-bit isn't supported). Also, since the slack-wiki DB has crashed, the link to how to write a good slack-desc file no longer works (well, it takes you to the wiki homepage, but no further). Thanks, Pierre From xgizzmo at slackbuilds.org Tue May 26 11:22:15 2009 From: xgizzmo at slackbuilds.org (xgizzmo at slackbuilds.org) Date: Tue, 26 May 2009 07:22:15 -0400 Subject: [Slackbuilds-users] Info on the SBo submissions page In-Reply-To: <4A1BB037.8040704@gmail.com> References: <4032.1242917702@email.unc.edu> <4A1BB037.8040704@gmail.com> Message-ID: <200905260722.15365.xgizzmo@slackbuilds.org> On Tuesday 26 May 2009 05:02:47 Pierre Cazenave wrote: > The info on the submissions page about what needs to be included in a > successful slackbuild appears erroneous. > > At present, it's missing the LIBDIRSUFFIX variable, and is ambiguous > with regards 64-bit support (including x86_64 compile flags, but saying > 64-bit isn't supported). > > Also, since the slack-wiki DB has crashed, the link to how to write a > good slack-desc file no longer works (well, it takes you to the wiki > homepage, but no further). > > Thanks, > > Pierre That page does need to be updated, but what is says with regard to 64bit is "64-bit derivatives of Slackware" Slackware64 is Slackware and will be supported. As far as how to write a good slack-desc file we can see about getting that hosted on the SlackBuilds.org server. --dsomero From pwcazenave at gmail.com Tue May 26 11:48:09 2009 From: pwcazenave at gmail.com (Pierre Cazenave) Date: Tue, 26 May 2009 11:48:09 +0000 Subject: [Slackbuilds-users] Info on the SBo submissions page In-Reply-To: <200905260722.15365.xgizzmo@slackbuilds.org> References: <4032.1242917702@email.unc.edu> <4A1BB037.8040704@gmail.com> <200905260722.15365.xgizzmo@slackbuilds.org> Message-ID: 2009/5/26 > On Tuesday 26 May 2009 05:02:47 Pierre Cazenave wrote: > > The info on the submissions page about what needs to be included in a > > successful slackbuild appears erroneous. > > > > At present, it's missing the LIBDIRSUFFIX variable, and is ambiguous > > with regards 64-bit support (including x86_64 compile flags, but saying > > 64-bit isn't supported). > > > > Also, since the slack-wiki DB has crashed, the link to how to write a > > good slack-desc file no longer works (well, it takes you to the wiki > > homepage, but no further). > > > > Thanks, > > > > Pierre > > That page does need to be updated, but what is says with regard to 64bit > is "64-bit derivatives of Slackware" Slackware64 is Slackware and will be > supported. As far as how to write a good slack-desc file we can see about > getting that hosted on the SlackBuilds.org server. > > --dsomero > > > _______________________________________________ > 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/ > Ah, that'll be me misreading the bit about 64-bit Slackware derivatives. Thanks, Pierre -------------- next part -------------- An HTML attachment was scrubbed... URL: From chaos.proton at gmail.com Tue May 26 14:11:49 2009 From: chaos.proton at gmail.com (Grissiom) Date: Tue, 26 May 2009 22:11:49 +0800 Subject: [Slackbuilds-users] development/docutils should be noarch Message-ID: Hi all, I think docutils should be noarch since it's written purely in python and nothing else. Here is the file list I build in slackware64: ============================================= PACKAGE NAME: docutils-0.5-i486-1_SBo COMPRESSED PACKAGE SIZE: 632K UNCOMPRESSED PACKAGE SIZE: 2630K PACKAGE LOCATION: /tmp/docutils-0.5-i486-1_SBo.tgz PACKAGE DESCRIPTION: docutils: docutils (Python Document Utilities module) docutils: docutils: Docutils is an open-source text processing system for processing docutils: plaintext documentation into useful formats, such as HTML or LaTeX. docutils: It includes reStructuredText, the easy to read, easy to use, docutils: what-you-see-is-what-you-get plaintext markup language. docutils: docutils: Homepage: http://docutils.sourceforge.net/ docutils: docutils: docutils: FILE LIST: ./ usr/ usr/doc/ usr/doc/docutils-0.5/ usr/doc/docutils-0.5/RELEASE-NOTES.txt usr/doc/docutils-0.5/README.txt usr/doc/docutils-0.5/COPYING.txt usr/doc/docutils-0.5/THANKS.txt usr/doc/docutils-0.5/BUGS.txt usr/doc/docutils-0.5/FAQ.txt usr/doc/docutils-0.5/HISTORY.txt usr/doc/docutils-0.5/PKG-INFO usr/doc/docutils-0.5/docutils.SlackBuild usr/bin/ usr/bin/rst2html.py usr/bin/rst2pseudoxml.py usr/bin/rst2xml.py usr/bin/rst2latex.py usr/bin/rstpep2html.py usr/bin/rst2s5.py usr/bin/rst2newlatex.py usr/lib64/ usr/lib64/python2.6/ usr/lib64/python2.6/site-packages/ usr/lib64/python2.6/site-packages/docutils/ usr/lib64/python2.6/site-packages/docutils/urischemes.pyc usr/lib64/python2.6/site-packages/docutils/statemachine.pyc usr/lib64/python2.6/site-packages/docutils/statemachine.py usr/lib64/python2.6/site-packages/docutils/frontend.pyc usr/lib64/python2.6/site-packages/docutils/languages/ usr/lib64/python2.6/site-packages/docutils/languages/de.py usr/lib64/python2.6/site-packages/docutils/languages/ja.py usr/lib64/python2.6/site-packages/docutils/languages/he.py usr/lib64/python2.6/site-packages/docutils/languages/ca.pyc usr/lib64/python2.6/site-packages/docutils/languages/fr.pyc usr/lib64/python2.6/site-packages/docutils/languages/zh_tw.py usr/lib64/python2.6/site-packages/docutils/languages/sv.py usr/lib64/python2.6/site-packages/docutils/languages/es.pyc usr/lib64/python2.6/site-packages/docutils/languages/pt_br.py usr/lib64/python2.6/site-packages/docutils/languages/ja.pyc usr/lib64/python2.6/site-packages/docutils/languages/ru.py usr/lib64/python2.6/site-packages/docutils/languages/cs.py usr/lib64/python2.6/site-packages/docutils/languages/zh_tw.pyc usr/lib64/python2.6/site-packages/docutils/languages/eo.py usr/lib64/python2.6/site-packages/docutils/languages/es.py usr/lib64/python2.6/site-packages/docutils/languages/ca.py usr/lib64/python2.6/site-packages/docutils/languages/en.pyc usr/lib64/python2.6/site-packages/docutils/languages/__init__.py usr/lib64/python2.6/site-packages/docutils/languages/fr.py usr/lib64/python2.6/site-packages/docutils/languages/sv.pyc usr/lib64/python2.6/site-packages/docutils/languages/fi.pyc usr/lib64/python2.6/site-packages/docutils/languages/zh_cn.py usr/lib64/python2.6/site-packages/docutils/languages/cs.pyc usr/lib64/python2.6/site-packages/docutils/languages/pt_br.pyc usr/lib64/python2.6/site-packages/docutils/languages/eo.pyc usr/lib64/python2.6/site-packages/docutils/languages/he.pyc usr/lib64/python2.6/site-packages/docutils/languages/sk.pyc usr/lib64/python2.6/site-packages/docutils/languages/af.py usr/lib64/python2.6/site-packages/docutils/languages/ru.pyc usr/lib64/python2.6/site-packages/docutils/languages/nl.py usr/lib64/python2.6/site-packages/docutils/languages/en.py usr/lib64/python2.6/site-packages/docutils/languages/it.py usr/lib64/python2.6/site-packages/docutils/languages/it.pyc usr/lib64/python2.6/site-packages/docutils/languages/nl.pyc usr/lib64/python2.6/site-packages/docutils/languages/fi.py usr/lib64/python2.6/site-packages/docutils/languages/af.pyc usr/lib64/python2.6/site-packages/docutils/languages/de.pyc usr/lib64/python2.6/site-packages/docutils/languages/zh_cn.pyc usr/lib64/python2.6/site-packages/docutils/languages/__init__.pyc usr/lib64/python2.6/site-packages/docutils/languages/sk.py usr/lib64/python2.6/site-packages/docutils/io.py usr/lib64/python2.6/site-packages/docutils/core.pyc usr/lib64/python2.6/site-packages/docutils/examples.pyc usr/lib64/python2.6/site-packages/docutils/nodes.pyc usr/lib64/python2.6/site-packages/docutils/parsers/ usr/lib64/python2.6/site-packages/docutils/parsers/__init__.py usr/lib64/python2.6/site-packages/docutils/parsers/rst/ usr/lib64/python2.6/site-packages/docutils/parsers/rst/tableparser.py usr/lib64/python2.6/site-packages/docutils/parsers/rst/roles.py usr/lib64/python2.6/site-packages/docutils/parsers/rst/languages/ usr/lib64/python2.6/site-packages/docutils/parsers/rst/languages/de.py usr/lib64/python2.6/site-packages/docutils/parsers/rst/languages/ja.py usr/lib64/python2.6/site-packages/docutils/parsers/rst/languages/he.py usr/lib64/python2.6/site-packages/docutils/parsers/rst/languages/ca.pyc usr/lib64/python2.6/site-packages/docutils/parsers/rst/languages/fr.pyc usr/lib64/python2.6/site-packages/docutils/parsers/rst/languages/zh_tw.py usr/lib64/python2.6/site-packages/docutils/parsers/rst/languages/sv.py usr/lib64/python2.6/site-packages/docutils/parsers/rst/languages/es.pyc usr/lib64/python2.6/site-packages/docutils/parsers/rst/languages/pt_br.py usr/lib64/python2.6/site-packages/docutils/parsers/rst/languages/ja.pyc usr/lib64/python2.6/site-packages/docutils/parsers/rst/languages/ru.py usr/lib64/python2.6/site-packages/docutils/parsers/rst/languages/cs.py usr/lib64/python2.6/site-packages/docutils/parsers/rst/languages/zh_tw.pyc usr/lib64/python2.6/site-packages/docutils/parsers/rst/languages/eo.py usr/lib64/python2.6/site-packages/docutils/parsers/rst/languages/es.py usr/lib64/python2.6/site-packages/docutils/parsers/rst/languages/ca.py usr/lib64/python2.6/site-packages/docutils/parsers/rst/languages/en.pyc usr/lib64/python2.6/site-packages/docutils/parsers/rst/languages/__init__.py usr/lib64/python2.6/site-packages/docutils/parsers/rst/languages/fr.py usr/lib64/python2.6/site-packages/docutils/parsers/rst/languages/sv.pyc usr/lib64/python2.6/site-packages/docutils/parsers/rst/languages/fi.pyc usr/lib64/python2.6/site-packages/docutils/parsers/rst/languages/zh_cn.py usr/lib64/python2.6/site-packages/docutils/parsers/rst/languages/cs.pyc usr/lib64/python2.6/site-packages/docutils/parsers/rst/languages/pt_br.pyc usr/lib64/python2.6/site-packages/docutils/parsers/rst/languages/eo.pyc usr/lib64/python2.6/site-packages/docutils/parsers/rst/languages/he.pyc usr/lib64/python2.6/site-packages/docutils/parsers/rst/languages/sk.pyc usr/lib64/python2.6/site-packages/docutils/parsers/rst/languages/af.py usr/lib64/python2.6/site-packages/docutils/parsers/rst/languages/ru.pyc usr/lib64/python2.6/site-packages/docutils/parsers/rst/languages/nl.py usr/lib64/python2.6/site-packages/docutils/parsers/rst/languages/en.py usr/lib64/python2.6/site-packages/docutils/parsers/rst/languages/it.py usr/lib64/python2.6/site-packages/docutils/parsers/rst/languages/it.pyc usr/lib64/python2.6/site-packages/docutils/parsers/rst/languages/nl.pyc usr/lib64/python2.6/site-packages/docutils/parsers/rst/languages/fi.py usr/lib64/python2.6/site-packages/docutils/parsers/rst/languages/af.pyc usr/lib64/python2.6/site-packages/docutils/parsers/rst/languages/de.pyc usr/lib64/python2.6/site-packages/docutils/parsers/rst/languages/zh_cn.pyc usr/lib64/python2.6/site-packages/docutils/parsers/rst/languages/__init__.pyc usr/lib64/python2.6/site-packages/docutils/parsers/rst/languages/sk.py usr/lib64/python2.6/site-packages/docutils/parsers/rst/states.pyc usr/lib64/python2.6/site-packages/docutils/parsers/rst/tableparser.pyc usr/lib64/python2.6/site-packages/docutils/parsers/rst/states.py usr/lib64/python2.6/site-packages/docutils/parsers/rst/__init__.py usr/lib64/python2.6/site-packages/docutils/parsers/rst/directives/ usr/lib64/python2.6/site-packages/docutils/parsers/rst/directives/html.py usr/lib64/python2.6/site-packages/docutils/parsers/rst/directives/misc.pyc usr/lib64/python2.6/site-packages/docutils/parsers/rst/directives/parts.pyc usr/lib64/python2.6/site-packages/docutils/parsers/rst/directives/tables.pyc usr/lib64/python2.6/site-packages/docutils/parsers/rst/directives/tables.py usr/lib64/python2.6/site-packages/docutils/parsers/rst/directives/parts.py usr/lib64/python2.6/site-packages/docutils/parsers/rst/directives/__init__.py usr/lib64/python2.6/site-packages/docutils/parsers/rst/directives/images.pyc usr/lib64/python2.6/site-packages/docutils/parsers/rst/directives/admonitions.pyc usr/lib64/python2.6/site-packages/docutils/parsers/rst/directives/body.pyc usr/lib64/python2.6/site-packages/docutils/parsers/rst/directives/html.pyc usr/lib64/python2.6/site-packages/docutils/parsers/rst/directives/misc.py usr/lib64/python2.6/site-packages/docutils/parsers/rst/directives/body.py usr/lib64/python2.6/site-packages/docutils/parsers/rst/directives/references.py usr/lib64/python2.6/site-packages/docutils/parsers/rst/directives/references.pyc usr/lib64/python2.6/site-packages/docutils/parsers/rst/directives/admonitions.py usr/lib64/python2.6/site-packages/docutils/parsers/rst/directives/images.py usr/lib64/python2.6/site-packages/docutils/parsers/rst/directives/__init__.pyc usr/lib64/python2.6/site-packages/docutils/parsers/rst/roles.pyc usr/lib64/python2.6/site-packages/docutils/parsers/rst/include/ usr/lib64/python2.6/site-packages/docutils/parsers/rst/include/isoamso.txt usr/lib64/python2.6/site-packages/docutils/parsers/rst/include/mmlalias.txt usr/lib64/python2.6/site-packages/docutils/parsers/rst/include/isomfrk.txt usr/lib64/python2.6/site-packages/docutils/parsers/rst/include/isocyr2.txt usr/lib64/python2.6/site-packages/docutils/parsers/rst/include/isocyr1.txt usr/lib64/python2.6/site-packages/docutils/parsers/rst/include/isotech.txt usr/lib64/python2.6/site-packages/docutils/parsers/rst/include/README.txt usr/lib64/python2.6/site-packages/docutils/parsers/rst/include/isomopf.txt usr/lib64/python2.6/site-packages/docutils/parsers/rst/include/xhtml1-special.txt usr/lib64/python2.6/site-packages/docutils/parsers/rst/include/isoamsb.txt usr/lib64/python2.6/site-packages/docutils/parsers/rst/include/isogrk4.txt usr/lib64/python2.6/site-packages/docutils/parsers/rst/include/isomfrk-wide.txt usr/lib64/python2.6/site-packages/docutils/parsers/rst/include/isogrk2.txt usr/lib64/python2.6/site-packages/docutils/parsers/rst/include/isomopf-wide.txt usr/lib64/python2.6/site-packages/docutils/parsers/rst/include/isogrk3.txt usr/lib64/python2.6/site-packages/docutils/parsers/rst/include/isoamsc.txt usr/lib64/python2.6/site-packages/docutils/parsers/rst/include/isogrk4-wide.txt usr/lib64/python2.6/site-packages/docutils/parsers/rst/include/mmlextra-wide.txt usr/lib64/python2.6/site-packages/docutils/parsers/rst/include/isogrk1.txt usr/lib64/python2.6/site-packages/docutils/parsers/rst/include/isoamsn.txt usr/lib64/python2.6/site-packages/docutils/parsers/rst/include/isoamsa.txt usr/lib64/python2.6/site-packages/docutils/parsers/rst/include/xhtml1-lat1.txt usr/lib64/python2.6/site-packages/docutils/parsers/rst/include/isomscr.txt usr/lib64/python2.6/site-packages/docutils/parsers/rst/include/isodia.txt usr/lib64/python2.6/site-packages/docutils/parsers/rst/include/isomscr-wide.txt usr/lib64/python2.6/site-packages/docutils/parsers/rst/include/isolat1.txt usr/lib64/python2.6/site-packages/docutils/parsers/rst/include/isoamsr.txt usr/lib64/python2.6/site-packages/docutils/parsers/rst/include/isobox.txt usr/lib64/python2.6/site-packages/docutils/parsers/rst/include/mmlextra.txt usr/lib64/python2.6/site-packages/docutils/parsers/rst/include/xhtml1-symbol.txt usr/lib64/python2.6/site-packages/docutils/parsers/rst/include/isopub.txt usr/lib64/python2.6/site-packages/docutils/parsers/rst/include/isonum.txt usr/lib64/python2.6/site-packages/docutils/parsers/rst/include/isolat2.txt usr/lib64/python2.6/site-packages/docutils/parsers/rst/include/s5defs.txt usr/lib64/python2.6/site-packages/docutils/parsers/rst/__init__.pyc usr/lib64/python2.6/site-packages/docutils/parsers/null.pyc usr/lib64/python2.6/site-packages/docutils/parsers/null.py usr/lib64/python2.6/site-packages/docutils/parsers/__init__.pyc usr/lib64/python2.6/site-packages/docutils/__init__.py usr/lib64/python2.6/site-packages/docutils/frontend.py usr/lib64/python2.6/site-packages/docutils/nodes.py usr/lib64/python2.6/site-packages/docutils/io.pyc usr/lib64/python2.6/site-packages/docutils/examples.py usr/lib64/python2.6/site-packages/docutils/writers/ usr/lib64/python2.6/site-packages/docutils/writers/pseudoxml.py usr/lib64/python2.6/site-packages/docutils/writers/docutils_xml.pyc usr/lib64/python2.6/site-packages/docutils/writers/__init__.py usr/lib64/python2.6/site-packages/docutils/writers/docutils_xml.py usr/lib64/python2.6/site-packages/docutils/writers/latex2e/ usr/lib64/python2.6/site-packages/docutils/writers/latex2e/__init__.py usr/lib64/python2.6/site-packages/docutils/writers/latex2e/latex2e.tex usr/lib64/python2.6/site-packages/docutils/writers/latex2e/__init__.pyc usr/lib64/python2.6/site-packages/docutils/writers/s5_html/ usr/lib64/python2.6/site-packages/docutils/writers/s5_html/__init__.py usr/lib64/python2.6/site-packages/docutils/writers/s5_html/themes/ usr/lib64/python2.6/site-packages/docutils/writers/s5_html/themes/README.txt usr/lib64/python2.6/site-packages/docutils/writers/s5_html/themes/medium-white/ usr/lib64/python2.6/site-packages/docutils/writers/s5_html/themes/medium-white/pretty.css usr/lib64/python2.6/site-packages/docutils/writers/s5_html/themes/medium-white/framing.css usr/lib64/python2.6/site-packages/docutils/writers/s5_html/themes/medium-black/ usr/lib64/python2.6/site-packages/docutils/writers/s5_html/themes/medium-black/__base__ usr/lib64/python2.6/site-packages/docutils/writers/s5_html/themes/medium-black/pretty.css usr/lib64/python2.6/site-packages/docutils/writers/s5_html/themes/small-white/ usr/lib64/python2.6/site-packages/docutils/writers/s5_html/themes/small-white/pretty.css usr/lib64/python2.6/site-packages/docutils/writers/s5_html/themes/small-white/framing.css usr/lib64/python2.6/site-packages/docutils/writers/s5_html/themes/small-black/ usr/lib64/python2.6/site-packages/docutils/writers/s5_html/themes/small-black/__base__ usr/lib64/python2.6/site-packages/docutils/writers/s5_html/themes/small-black/pretty.css usr/lib64/python2.6/site-packages/docutils/writers/s5_html/themes/default/ usr/lib64/python2.6/site-packages/docutils/writers/s5_html/themes/default/slides.css usr/lib64/python2.6/site-packages/docutils/writers/s5_html/themes/default/slides.js usr/lib64/python2.6/site-packages/docutils/writers/s5_html/themes/default/outline.css usr/lib64/python2.6/site-packages/docutils/writers/s5_html/themes/default/blank.gif usr/lib64/python2.6/site-packages/docutils/writers/s5_html/themes/default/opera.css usr/lib64/python2.6/site-packages/docutils/writers/s5_html/themes/default/pretty.css usr/lib64/python2.6/site-packages/docutils/writers/s5_html/themes/default/framing.css usr/lib64/python2.6/site-packages/docutils/writers/s5_html/themes/default/print.css usr/lib64/python2.6/site-packages/docutils/writers/s5_html/themes/default/s5-core.css usr/lib64/python2.6/site-packages/docutils/writers/s5_html/themes/default/iepngfix.htc usr/lib64/python2.6/site-packages/docutils/writers/s5_html/themes/big-white/ usr/lib64/python2.6/site-packages/docutils/writers/s5_html/themes/big-white/pretty.css usr/lib64/python2.6/site-packages/docutils/writers/s5_html/themes/big-white/framing.css usr/lib64/python2.6/site-packages/docutils/writers/s5_html/themes/big-black/ usr/lib64/python2.6/site-packages/docutils/writers/s5_html/themes/big-black/__base__ usr/lib64/python2.6/site-packages/docutils/writers/s5_html/themes/big-black/pretty.css usr/lib64/python2.6/site-packages/docutils/writers/s5_html/themes/big-black/framing.css usr/lib64/python2.6/site-packages/docutils/writers/s5_html/__init__.pyc usr/lib64/python2.6/site-packages/docutils/writers/newlatex2e/ usr/lib64/python2.6/site-packages/docutils/writers/newlatex2e/unicode_map.pyc usr/lib64/python2.6/site-packages/docutils/writers/newlatex2e/__init__.py usr/lib64/python2.6/site-packages/docutils/writers/newlatex2e/base.tex usr/lib64/python2.6/site-packages/docutils/writers/newlatex2e/unicode_map.py usr/lib64/python2.6/site-packages/docutils/writers/newlatex2e/__init__.pyc usr/lib64/python2.6/site-packages/docutils/writers/html4css1/ usr/lib64/python2.6/site-packages/docutils/writers/html4css1/__init__.py usr/lib64/python2.6/site-packages/docutils/writers/html4css1/template.txt usr/lib64/python2.6/site-packages/docutils/writers/html4css1/html4css1.css usr/lib64/python2.6/site-packages/docutils/writers/html4css1/__init__.pyc usr/lib64/python2.6/site-packages/docutils/writers/null.pyc usr/lib64/python2.6/site-packages/docutils/writers/pseudoxml.pyc usr/lib64/python2.6/site-packages/docutils/writers/null.py usr/lib64/python2.6/site-packages/docutils/writers/pep_html/ usr/lib64/python2.6/site-packages/docutils/writers/pep_html/pep.css usr/lib64/python2.6/site-packages/docutils/writers/pep_html/__init__.py usr/lib64/python2.6/site-packages/docutils/writers/pep_html/template.txt usr/lib64/python2.6/site-packages/docutils/writers/pep_html/__init__.pyc usr/lib64/python2.6/site-packages/docutils/writers/__init__.pyc usr/lib64/python2.6/site-packages/docutils/readers/ usr/lib64/python2.6/site-packages/docutils/readers/standalone.pyc usr/lib64/python2.6/site-packages/docutils/readers/pep.pyc usr/lib64/python2.6/site-packages/docutils/readers/pep.py usr/lib64/python2.6/site-packages/docutils/readers/__init__.py usr/lib64/python2.6/site-packages/docutils/readers/doctree.pyc usr/lib64/python2.6/site-packages/docutils/readers/standalone.py usr/lib64/python2.6/site-packages/docutils/readers/python/ usr/lib64/python2.6/site-packages/docutils/readers/python/moduleparser.py usr/lib64/python2.6/site-packages/docutils/readers/python/__init__.py usr/lib64/python2.6/site-packages/docutils/readers/python/pynodes.py usr/lib64/python2.6/site-packages/docutils/readers/python/pynodes.pyc usr/lib64/python2.6/site-packages/docutils/readers/python/moduleparser.pyc usr/lib64/python2.6/site-packages/docutils/readers/python/__init__.pyc usr/lib64/python2.6/site-packages/docutils/readers/doctree.py usr/lib64/python2.6/site-packages/docutils/readers/__init__.pyc usr/lib64/python2.6/site-packages/docutils/urischemes.py usr/lib64/python2.6/site-packages/docutils/utils.py usr/lib64/python2.6/site-packages/docutils/utils.pyc usr/lib64/python2.6/site-packages/docutils/core.py usr/lib64/python2.6/site-packages/docutils/transforms/ usr/lib64/python2.6/site-packages/docutils/transforms/writer_aux.pyc usr/lib64/python2.6/site-packages/docutils/transforms/writer_aux.py usr/lib64/python2.6/site-packages/docutils/transforms/misc.pyc usr/lib64/python2.6/site-packages/docutils/transforms/parts.pyc usr/lib64/python2.6/site-packages/docutils/transforms/frontmatter.py usr/lib64/python2.6/site-packages/docutils/transforms/universal.py usr/lib64/python2.6/site-packages/docutils/transforms/components.pyc usr/lib64/python2.6/site-packages/docutils/transforms/parts.py usr/lib64/python2.6/site-packages/docutils/transforms/__init__.py usr/lib64/python2.6/site-packages/docutils/transforms/frontmatter.pyc usr/lib64/python2.6/site-packages/docutils/transforms/components.py usr/lib64/python2.6/site-packages/docutils/transforms/misc.py usr/lib64/python2.6/site-packages/docutils/transforms/references.py usr/lib64/python2.6/site-packages/docutils/transforms/references.pyc usr/lib64/python2.6/site-packages/docutils/transforms/universal.pyc usr/lib64/python2.6/site-packages/docutils/transforms/peps.py usr/lib64/python2.6/site-packages/docutils/transforms/peps.pyc usr/lib64/python2.6/site-packages/docutils/transforms/__init__.pyc usr/lib64/python2.6/site-packages/docutils/__init__.pyc usr/lib64/python2.6/site-packages/roman.pyc usr/lib64/python2.6/site-packages/roman.py usr/lib64/python2.6/site-packages/docutils-0.5-py2.6.egg-info install/ install/slack-desc ============================================= Actually it will 'compiled' by python but not platform dependent. What's more, docutil-*-i486 works well on slackware64 ;) -- Cheers, Grissiom -------------- next part -------------- An HTML attachment was scrubbed... URL: From chess at chessgriffin.com Thu May 28 02:04:44 2009 From: chess at chessgriffin.com (Chess Griffin) Date: Wed, 27 May 2009 22:04:44 -0400 Subject: [Slackbuilds-users] Sbopkg and Slackware64 Update Message-ID: <20090528020443.GA29735@localhost> (Copy of a post made to LinuxQuestions.org forum): Question: Will sbopkg work on Slackware64? Why are some scripts failing that I build with sbopkg on Slackware64? Answer: Sbopkg is undergoing a /lot/ of work in its subversion repository in preparation for the next major release. Part of this work is to fully support Slackware64 insofar as the scripts at SlackBuilds.org will support Slackware64. This generally requires two things: (a) exporting ARCH in sbopkg.conf[1] and (b) a SlackBuild script that has been checked or updated for Slackware64 by possibly including the LIBDIRSUFFIX assignments, --libdir=/usr/lib${LIBDIRSUFFIX} passed to ./configure, and any other necessary changes. The SlackBuilds.org template (http://slackbuilds.org/template.SlackBuild) now provides the bits that are necessary for most scripts to work on Slackware64, although manual tweaking is often necessary. Some scripts may not need tweaking at all. Sbopkg simply provides an interface to build packages from the scripts at SlackBuilds.org. If one of the SlackBuild scripts does not build properly in sbopkg on Slackware64, then the cause is likely that the SlackBuild script itself has not yet been updated by its maintainer, in which case it will not work whether or not sbopkg is used. It is up to each script's maintainer to update his/her scripts at SlackBuilds.org. Ultimately, please just keep in mind that Slackware64 has not been released in its final form and the scripts at SlackBuilds.org have not yet been fully checked to work on Slackware64. Since we are in a period of transition, using sbopkg on Slackware64 is a 'YMMV' proposition. It is not officially supported. I am using sbopkg on Slackware64-current and it works fine for those SlackBuilds that have been updated after exporting ARCH in sbopkg.conf. Since I plan to stay on Slackware64, and since I eat my own dogfood, making sbopkg work flawlessly on Slackware64 is a high priority for me. :-) Sbopkg is not officially supported by SlackBuilds.org, so if you have any issues or questions with sbopkg itself, please do not report these things to any of the other SlackBuilds.org admins. Instead, please ask me via email, IRC (#sbopkg on freenode), or on the sbopkg ML (preferred). Check the sbopkg homepage for more information on that. Finally, if one of your favorite SlackBuild scripts at SlackBuilds.org has not been updated, consider asking the maintainer to update it. [1] For Slackware64 users, then, this would need to be added to sbopkg.conf: export ARCH=${ARCH:-x86_64} -- Chess Griffin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From chaos.proton at gmail.com Thu May 28 13:48:39 2009 From: chaos.proton at gmail.com (Grissiom) Date: Thu, 28 May 2009 21:48:39 +0800 Subject: [Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent Message-ID: Hi folks, While I was taking train this afternoon, a thought came up in my mind -- SlackBuilds for python modules and many programs that written in pure python (say, decorator, pysetuptools, logilab-common etc) should be arch dependent. Maybe most of them are installed via "distutils", if you see something like "python setup.py install --root=$PKG", it will be the case. I think setup.py just do what "./configure && make && make install" do -- detect the python installation structure, compile .py files to .pyc bytecodes. The bytecodes is platorm independent but the installation structure is not. So in slackware64, things will be installed into /usr/lib64/python2.6/site-packages/xxx but in slackware, things will be installed into /usr/lib/python2.6/site-packages/xxx. The conclusion is the files in the package in arch indenpendent but the direcory structure is arch dependent. After some hack, I found a solution for this: write the SlackBuilds like this: .... if [ "$ARCH" = "i486" ]; then SLKCFLAGS="-O2 -march=i486 -mtune=i686" LIBDIRSUFFIX="" elif [ "$ARCH" = "i686" ]; then SLKCFLAGS="-O2 -march=i686 -mtune=i686" LIBDIRSUFFIX="" elif [ "$ARCH" = "x86_64" ]; then SLKCFLAGS="-O2 -fPIC" LIBDIRSUFFIX="64" fi .... .... python setup.py install --prefix=/usr --install-lib=/usr/lib${LIBDIRSUFFIX}/python2.6/site-packages/ --root=$PKG .... Thus the package will install files to /usr/lib for 32bit slack and /usr/lib64 for slackware64.(note python in slackware12.2 is still 2.5.x you may need to adjust the install command for 12.2) Saying so much, I hope I have expressed my idea clearly and it will do some help. -- Cheers, Grissiom -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragonwisard at gmail.com Thu May 28 14:09:43 2009 From: dragonwisard at gmail.com (Dragon Wisard) Date: Thu, 28 May 2009 10:09:43 -0400 Subject: [Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent In-Reply-To: References: Message-ID: <6c341e560905280709l5c4a479ag950a7f38142c1a63@mail.gmail.com> Since they bytecode is itself, platform independent, wouldn't it make sense to just use one directory (eg. /usr/lib/python2.6/site-packages/xxx) and symlink the /usr/lib64/... to the that directory? Assuming you have both 32-bit and 64-bit builds of Python installed, there is no sense in having to install the same exact modules twice in two different locations. I would opt to install everything in /usr/lib/... since that will always be present, and then create a symlink from doit.sh if x86_64 is detected. Just my 2 cents. On Thu, May 28, 2009 at 9:48 AM, Grissiom wrote: > Hi folks, > > While I was taking train this afternoon, a thought came up in my mind -- > SlackBuilds for python modules and many programs that written in pure python > (say, decorator, pysetuptools, logilab-common etc) should be arch > dependent. Maybe most of them are installed via "distutils", if you see > something like "python setup.py install --root=$PKG", it will be the case. > > I think setup.py just do what "./configure && make && make install" do -- > detect the python installation structure, compile .py files to .pyc > bytecodes. The bytecodes is platorm independent but the installation > structure is not. So in slackware64, things will be installed into > /usr/lib64/python2.6/site-packages/xxx but in slackware, things will be > installed into /usr/lib/python2.6/site-packages/xxx. The conclusion is the > files in the package in arch indenpendent but the direcory structure is arch > dependent. > > After some hack, I found a solution for this: write the SlackBuilds like > this: > .... > if [ "$ARCH" = "i486" ]; then > SLKCFLAGS="-O2 -march=i486 -mtune=i686" > LIBDIRSUFFIX="" > elif [ "$ARCH" = "i686" ]; then > SLKCFLAGS="-O2 -march=i686 -mtune=i686" > LIBDIRSUFFIX="" > elif [ "$ARCH" = "x86_64" ]; then > SLKCFLAGS="-O2 -fPIC" > LIBDIRSUFFIX="64" > fi > .... > .... > python setup.py install --prefix=/usr > --install-lib=/usr/lib${LIBDIRSUFFIX}/python2.6/site-packages/ --root=$PKG > .... > > Thus the package will install files to /usr/lib for 32bit slack and > /usr/lib64 for slackware64.(note python in slackware12.2 is still 2.5.x you > may need to adjust the install command for 12.2) > > Saying so much, I hope I have expressed my idea clearly and it will do some > help. > > -- > Cheers, > Grissiom > > _______________________________________________ > 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/ > > > -- http://www.dragonwisard.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From chaos.proton at gmail.com Thu May 28 14:25:37 2009 From: chaos.proton at gmail.com (Grissiom) Date: Thu, 28 May 2009 22:25:37 +0800 Subject: [Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent In-Reply-To: <6c341e560905280709l5c4a479ag950a7f38142c1a63@mail.gmail.com> References: <6c341e560905280709l5c4a479ag950a7f38142c1a63@mail.gmail.com> Message-ID: On Thu, May 28, 2009 at 22:09, Dragon Wisard wrote: > Since they bytecode is itself, platform independent, wouldn't it make sense > to just use one directory (eg. /usr/lib/python2.6/site-packages/xxx) and > symlink the /usr/lib64/... to the that directory? Assuming you have both > 32-bit and 64-bit builds of Python installed, there is no sense in having to > install the same exact modules twice in two different locations. > > I would opt to install everything in /usr/lib/... since that will always be > present, and then create a symlink from doit.sh if x86_64 is detected. > > Just my 2 cents. > Yes, install them twice make no sense at all because in slackware32, python is installed in /usr/lib while in slackware64, python is installed in /usr/lib64. At least there is no official 32-bit python in 64-bit environment now.(maybe never?) Symlink is something like install "twice" except comsume less disk space. In my slackware64, the sys.path(where python looks for modules) is: ['', '/usr/lib64/python26.zip', '/usr/lib64/python2.6', '/usr/lib64/python2.6/plat-linux2', '/usr/lib64/python2.6/lib-tk', '/usr/lib64/python2.6/lib-old', '/usr/lib64/python2.6/lib-dynload', '/usr/lib64/python2.6/site-packages', '/usr/lib64/python2.6/site-packages/PIL', '/usr/lib64/python2.6/site-packages/gtk-2.0'] so, 64-bit python does not look for things in /usr/lib/pythonx.x/xx I think 32-bit python does not look for things in /usr/lib64 too. This is why the packages are "arch dependent" -- Cheers, Grissiom -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefanovic.dusan at gmail.com Thu May 28 15:12:49 2009 From: stefanovic.dusan at gmail.com (=?UTF-8?B?RHXFoWFuIFN0ZWZhbm92acSH?=) Date: Thu, 28 May 2009 17:12:49 +0200 Subject: [Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent In-Reply-To: References: Message-ID: On Thu, May 28, 2009 at 15:48, Grissiom wrote: > After some hack, I found a solution for this: write the SlackBuilds like > this: > .... > if [ "$ARCH" = "i486" ]; then > ? SLKCFLAGS="-O2 -march=i486 -mtune=i686" > ? LIBDIRSUFFIX="" > elif [ "$ARCH" = "i686" ]; then > ? SLKCFLAGS="-O2 -march=i686 -mtune=i686" > ? LIBDIRSUFFIX="" > elif [ "$ARCH" = "x86_64" ]; then > ? SLKCFLAGS="-O2 -fPIC" > ? LIBDIRSUFFIX="64" > fi > .... > .... > python setup.py install --prefix=/usr > --install-lib=/usr/lib${LIBDIRSUFFIX}/python2.6/site-packages/ --root=$PKG > .... > Maybe like this: ARCH=noarch LIBDIRSUFFIX=${LIBDIRSUFFIX:-32} there is no sense to use i486 or x86_64 as ARCH in noarch package just to set directory right. regards, ds From chaos.proton at gmail.com Thu May 28 15:28:27 2009 From: chaos.proton at gmail.com (Grissiom) Date: Thu, 28 May 2009 23:28:27 +0800 Subject: [Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent In-Reply-To: References: Message-ID: 2009/5/28 Du?an Stefanovi? > Maybe like this: > ARCH=noarch > LIBDIRSUFFIX=${LIBDIRSUFFIX:-32} > > there is no sense to use i486 or x86_64 as ARCH in noarch package just > to set directory right. > > regards, > ds > Hmm, so, what does "noarch" mean? IMHO, a noarch package is the one I can install it regardless whatever platform I'm running and after installing it, I can use it. If I installed a package that copy python modules into /usr/lib/pythonx.x/xxx I will have noway to take use of it under slackware64.(actually there is a way but it's dirty and painful) -- Cheers, Grissiom -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefanovic.dusan at gmail.com Thu May 28 15:45:04 2009 From: stefanovic.dusan at gmail.com (=?UTF-8?B?RHXFoWFuIFN0ZWZhbm92acSH?=) Date: Thu, 28 May 2009 17:45:04 +0200 Subject: [Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent In-Reply-To: References: Message-ID: > > > Hmm, so, what does "noarch" mean? IMHO, a noarch package is the one I can > install it regardless whatever platform I'm running and after installing it, > I can use it. If I installed a package that copy python modules into > /usr/lib/pythonx.x/xxx I will have noway to take use of it under > slackware64.(actually there is a way but it's dirty and painful) > noarch should mean (in my head at least it means) that the files inside the package are architecture independent. You can create noarch package that will install correctly in both x86_64 and i486. For example inside doinst.sh you can check distribution (either uname or /etc/slackware-version) and put files where they should go. I'm not saying that this is right way to do, but it is possibile. regards, ds From stefanovic.dusan at gmail.com Thu May 28 15:53:46 2009 From: stefanovic.dusan at gmail.com (=?UTF-8?B?RHXFoWFuIFN0ZWZhbm92acSH?=) Date: Thu, 28 May 2009 17:53:46 +0200 Subject: [Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent In-Reply-To: References: Message-ID: On the other hand, why do you expect that package that is build on one distribution work on another? Do you expect that i486 package that is build for slack 12.2 work on 12.1? Even vice versa is not true sometimes. I would never guess that program will work just by looking at ARCH. regards, ds From alien at slackbuilds.org Thu May 28 18:36:15 2009 From: alien at slackbuilds.org (Eric Hameleers) Date: Thu, 28 May 2009 20:36:15 +0200 Subject: [Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent In-Reply-To: References: Message-ID: <4A1ED99F.8030609@slackbuilds.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Grissiom wrote: > Hi folks, > > While I was taking train this afternoon, a thought came up in my mind -- > SlackBuilds for python modules and many programs that written in pure > python (say, decorator, pysetuptools, logilab-common etc) should be arch > dependent. Maybe most of them are installed via "distutils", if you see > something like "python setup.py install --root=$PKG", it will be the case. > > I think setup.py just do what "./configure && make && make install" do > -- detect the python installation structure, compile .py files to .pyc > bytecodes. The bytecodes is platorm independent but the installation > structure is not. So in slackware64, things will be installed into > /usr/lib64/python2.6/site-packages/xxx but in slackware, things will be > installed into /usr/lib/python2.6/site-packages/xxx. The conclusion is > the files in the package in arch indenpendent but the direcory structure > is arch dependent. > > After some hack, I found a solution for this: write the SlackBuilds like > this: > .... > if [ "$ARCH" = "i486" ]; then > SLKCFLAGS="-O2 -march=i486 -mtune=i686" > LIBDIRSUFFIX="" > elif [ "$ARCH" = "i686" ]; then > SLKCFLAGS="-O2 -march=i686 -mtune=i686" > LIBDIRSUFFIX="" > elif [ "$ARCH" = "x86_64" ]; then > SLKCFLAGS="-O2 -fPIC" > LIBDIRSUFFIX="64" > fi > .... > .... > python setup.py install --prefix=/usr > --install-lib=/usr/lib${LIBDIRSUFFIX}/python2.6/site-packages/ --root=$PKG > .... > > Thus the package will install files to /usr/lib for 32bit slack and > /usr/lib64 for slackware64.(note python in slackware12.2 is still 2.5.x > you may need to adjust the install command for 12.2) > > Saying so much, I hope I have expressed my idea clearly and it will do > some help. Hi Grissiom If you write a SlackBuild that installs purepython files which are architecture independent you will indeed still have a "lib vs lib64" difference in the final package depending on the architecture you create the package on. But since we are SlackBuilds.org and not LinuxPackages.net we do not have to worry about where the final package gets built and installed - the person who compiles it will know. So, the purepython package can be "noarch" as long as you determine the install-lib using Python itself: PYTHONLIB=$( python -c "from distutils.sysconfig import get_python_lib; print get_python_lib()" ) This will yield "/usr/lib/python2.5/site-packages" on Slackware 12.2 and "/usr/lib64/python2.6/site-packages" on slackware64-current. You see that the python version number no longer needs to be hardcoded. Use that variable as follows: python setup.py install \ --prefix=/usr \ --install-lib=$PYTHONLIB \ --root=$PKG You will not have to add the "if ARCH ... fi" block and the LIBDIRSUFFIX is not used at all. A single SlackBuild will work on all Slackware releases. Cheers, Eric - -- Eric Hameleers >') Email: alien at slackbuilds.org ( \ Jabber: alien at jabber.xs4all.nl ^^` -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkoe2UsACgkQXlaqr6dcvaD6KgCfcVhUh5MeDRP5js000OpvPzGM T28AnR5DilhrtY5PJxOMMID+oHGcco9R =Yz+5 -----END PGP SIGNATURE----- From chaos.proton at gmail.com Thu May 28 22:44:20 2009 From: chaos.proton at gmail.com (Grissiom) Date: Fri, 29 May 2009 06:44:20 +0800 Subject: [Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent In-Reply-To: References: Message-ID: 2009/5/28 Du?an Stefanovi? > noarch should mean (in my head at least it means) that the files > inside the package are architecture independent. > You can create noarch package that will install correctly in both > x86_64 and i486. For example inside doinst.sh you can check > distribution (either uname or /etc/slackware-version) and put files > where they should go. I'm not saying that this is right way to do, but > it is possibile. > Hmm, yes. But maybe this method is painful to uninstall and get what installed. But it's possible. -- Cheers, Grissiom -------------- next part -------------- An HTML attachment was scrubbed... URL: From chaos.proton at gmail.com Thu May 28 22:51:55 2009 From: chaos.proton at gmail.com (Grissiom) Date: Fri, 29 May 2009 06:51:55 +0800 Subject: [Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent In-Reply-To: References: Message-ID: 2009/5/28 Du?an Stefanovi? > On the other hand, why do you expect that package that is build on one > distribution work on another? > Do you expect that i486 package that is build for slack 12.2 work on 12.1? > Even vice versa is not true sometimes. I would never guess that > program will work just by looking at ARCH. > > regards, > ds > Hmm, I could not either ;) But I just want the packages live up to their names. -- Cheers, Grissiom -------------- next part -------------- An HTML attachment was scrubbed... URL: From chaos.proton at gmail.com Thu May 28 23:10:57 2009 From: chaos.proton at gmail.com (Grissiom) Date: Fri, 29 May 2009 07:10:57 +0800 Subject: [Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent In-Reply-To: <4A1ED99F.8030609@slackbuilds.org> References: <4A1ED99F.8030609@slackbuilds.org> Message-ID: On Fri, May 29, 2009 at 02:36, Eric Hameleers wrote: > > Hi Grissiom > > If you write a SlackBuild that installs purepython files which are > architecture independent you will indeed still have a "lib vs lib64" > difference in the final package depending on the architecture you > create the package on. > But since we are SlackBuilds.org and not LinuxPackages.net we do not > have to worry about where the final package gets built and installed - > the person who compiles it will know. > Hmm, Ok, so I know the role of SlackBuilds.org -- distribute the build script but not the packages and there is no guarantee that the packages build from the scripts are re-distributable? > > So, the purepython package can be "noarch" as long as you determine > the install-lib using Python itself: > > PYTHONLIB=$( python -c "from distutils.sysconfig import > get_python_lib; print get_python_lib()" ) > > This will yield "/usr/lib/python2.5/site-packages" on Slackware 12.2 > and "/usr/lib64/python2.6/site-packages" on slackware64-current. You > see that the python version number no longer needs to be hardcoded. > > Use that variable as follows: > > python setup.py install \ > --prefix=/usr \ > --install-lib=$PYTHONLIB \ > --root=$PKG > The setup.py will take care of this automaticially. Maybe there is no need to bother --install-lib if you do not want to re-distribute the package. You will not have to add the "if ARCH ... fi" block and the > LIBDIRSUFFIX is not used at all. A single SlackBuild will work on all > Slackware releases. Yes, SlackBuilds will always work. So the problem now is the package build from a SlackBuild is re-distributable or not or, do we want it to be re-distributable? -- Cheers, Grissiom -------------- next part -------------- An HTML attachment was scrubbed... URL: From dragonwisard at gmail.com Fri May 29 00:34:54 2009 From: dragonwisard at gmail.com (Dragon Wisard) Date: Thu, 28 May 2009 20:34:54 -0400 Subject: [Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent In-Reply-To: References: <4A1ED99F.8030609@slackbuilds.org> Message-ID: <6c341e560905281734m478f9636xd2b914cba2823612@mail.gmail.com> I think what Eric was saying is that the Slackbuild is architecture independent but the package generated by it is architecture dependent. That seems to be enough to satisfy him. Personally, I see no reason why the package should *need* to be architecture dependent. We're restricting it based on a directory structure convention. It would be relatively easy to just use symlinks to have the modules show up in both places if appropriate. I see no reason to have two separate packages when the contents are identical and the only difference is where they get installed. It's a waste of space and adds unnecessary complexity to administration. On Thu, May 28, 2009 at 7:10 PM, Grissiom wrote: > On Fri, May 29, 2009 at 02:36, Eric Hameleers wrote: >> >> Hi Grissiom >> >> If you write a SlackBuild that installs purepython files which are >> architecture independent you will indeed still have a "lib vs lib64" >> difference in the final package depending on the architecture you >> create the package on. >> But since we are SlackBuilds.org and not LinuxPackages.net we do not >> have to worry about where the final package gets built and installed - >> the person who compiles it will know. >> > > Hmm, Ok, so I know the role of SlackBuilds.org -- distribute the build > script but not the packages and there is no guarantee that the packages > build from the scripts are re-distributable? > > >> >> So, the purepython package can be "noarch" as long as you determine >> the install-lib using Python itself: >> >> PYTHONLIB=$( python -c "from distutils.sysconfig import >> get_python_lib; print get_python_lib()" ) >> >> This will yield "/usr/lib/python2.5/site-packages" on Slackware 12.2 >> and "/usr/lib64/python2.6/site-packages" on slackware64-current. You >> see that the python version number no longer needs to be hardcoded. >> >> Use that variable as follows: >> >> python setup.py install \ >> --prefix=/usr \ >> --install-lib=$PYTHONLIB \ >> --root=$PKG >> > > The setup.py will take care of this automaticially. Maybe there is no need > to bother --install-lib if you do not want to re-distribute the package. > > You will not have to add the "if ARCH ... fi" block and the >> LIBDIRSUFFIX is not used at all. A single SlackBuild will work on all >> Slackware releases. > > > Yes, SlackBuilds will always work. So the problem now is the package build > from a SlackBuild is re-distributable or not or, do we want it to be > re-distributable? > > -- > Cheers, > Grissiom > > _______________________________________________ > 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/ > > > -- http://www.dragonwisard.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rworkman at slackbuilds.org Fri May 29 01:03:31 2009 From: rworkman at slackbuilds.org (Robby Workman) Date: Thu, 28 May 2009 20:03:31 -0500 Subject: [Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent In-Reply-To: <6c341e560905281734m478f9636xd2b914cba2823612@mail.gmail.com> References: <4A1ED99F.8030609@slackbuilds.org> <6c341e560905281734m478f9636xd2b914cba2823612@mail.gmail.com> Message-ID: <20090528200331.2a9f821e@liberty.rlwhome.lan> On Thu, 28 May 2009 20:34:54 -0400 Dragon Wisard wrote: > I think what Eric was saying is that the Slackbuild is architecture > independent but the package generated by it is architecture > dependent. That seems to be enough to satisfy him. > > Personally, I see no reason why the package should *need* to be > architecture dependent. We're restricting it based on a directory > structure convention. It would be relatively easy to just use > symlinks to have the modules show up in both places if appropriate. I > see no reason to have two separate packages when the contents are > identical and the only difference is where they get installed. It's a > waste of space and adds unnecessary complexity to administration. Maybe, but I don't like the symlink idea at all. We can't just symlink the entire /usr/lib (or /usr/lib64) directory, so we'd have to symlink each additional file in there, and along the way, check for existing files/dirs on the filesystem with the same names so that we don't wipe them, and if they exist already, then what? Fail during installation? IMHO, if a package uses */lib64 then it's an ARCH=x86_64 package. -RW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From listreader at lupulin.net Fri May 29 01:06:00 2009 From: listreader at lupulin.net (paul wisehart) Date: Thu, 28 May 2009 21:06:00 -0400 Subject: [Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent In-Reply-To: References: <4A1ED99F.8030609@slackbuilds.org> Message-ID: <4A1F34F8.3070206@lupulin.net> Grissiom wrote: > On Fri, May 29, 2009 at 02:36, Eric Hameleers > wrote: > > Hi Grissiom > > If you write a SlackBuild that installs purepython files which are > architecture independent you will indeed still have a "lib vs lib64" > difference in the final package depending on the architecture you > create the package on. > But since we are SlackBuilds.org and not LinuxPackages.net we do not > have to worry about where the final package gets built and installed - > the person who compiles it will know. Are the *.pyc files arch independent? I don't know or care, but that's enough reason for me to want common slackbuilds, and discrete packages. -- paul w From listreader at lupulin.net Fri May 29 01:11:51 2009 From: listreader at lupulin.net (paul wisehart) Date: Thu, 28 May 2009 21:11:51 -0400 Subject: [Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent In-Reply-To: <4A1F34F8.3070206@lupulin.net> References: <4A1ED99F.8030609@slackbuilds.org> <4A1F34F8.3070206@lupulin.net> Message-ID: <4A1F3657.40106@lupulin.net> paul wisehart wrote: > Grissiom wrote: >> On Fri, May 29, 2009 at 02:36, Eric Hameleers > > wrote: >> >> Hi Grissiom >> >> If you write a SlackBuild that installs purepython files which are >> architecture independent you will indeed still have a "lib vs lib64" >> difference in the final package depending on the architecture you >> create the package on. >> But since we are SlackBuilds.org and not LinuxPackages.net we do not >> have to worry about where the final package gets built and >> installed - >> the person who compiles it will know. > > Are the *.pyc files arch independent? I don't know or care, but that's > enough reason for me to want common slackbuilds, and discrete packages. > I guess i do care :) http://www.network-theory.co.uk/docs/pytut/CompiledPythonfiles.html: "The contents of the ?spam.pyc? file are platform independent, so a Python module directory can be shared by machines of different architectures." But I still think they should be diff packages if they install into different directories, because "everything is a file", so the contents of the package *are* different. -- paul "maybe i should do the 1 min. google search *before* i post" wisehart From chaos.proton at gmail.com Fri May 29 01:15:55 2009 From: chaos.proton at gmail.com (Grissiom) Date: Fri, 29 May 2009 09:15:55 +0800 Subject: [Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent In-Reply-To: <20090528200331.2a9f821e@liberty.rlwhome.lan> References: <4A1ED99F.8030609@slackbuilds.org> <6c341e560905281734m478f9636xd2b914cba2823612@mail.gmail.com> <20090528200331.2a9f821e@liberty.rlwhome.lan> Message-ID: On Fri, May 29, 2009 at 09:03, Robby Workman wrote: > Maybe, but I don't like the symlink idea at all. We can't just symlink > the entire /usr/lib (or /usr/lib64) directory, so we'd have to symlink > each additional file in there, and along the way, check for existing > files/dirs on the filesystem with the same names so that we don't wipe > them, and if they exist already, then what? Fail during installation? > > IMHO, if a package uses */lib64 then it's an ARCH=x86_64 package. > +1 for this ;) -- Cheers, Grissiom -------------- next part -------------- An HTML attachment was scrubbed... URL: From xgizzmo at slackbuilds.org Fri May 29 02:40:19 2009 From: xgizzmo at slackbuilds.org (xgizzmo at slackbuilds.org) Date: Thu, 28 May 2009 22:40:19 -0400 Subject: [Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent In-Reply-To: References: <20090528200331.2a9f821e@liberty.rlwhome.lan> Message-ID: <200905282240.19607.xgizzmo@slackbuilds.org> On Thursday 28 May 2009 21:15:55 Grissiom wrote: > > > > IMHO, if a package uses */lib64 then it's an ARCH=x86_64 package. > > > This seems to be what Slackware does. I think the best thing to do here is just to make sure we use ARCH=${ARCH:-noarch} and not hard code it. That way if the package builder is building for x86_64 then they should be using ARCH=x86_64 ./some.SlackBuild and it will have an x86_64 tag on the final package. So far all of the python builds I have seen that use setup.py find the right python path on their own, so the SlackBuild does not have to be changed in any other way. --dsomero From dragonwisard at gmail.com Fri May 29 02:59:18 2009 From: dragonwisard at gmail.com (Dragon Wisard) Date: Thu, 28 May 2009 22:59:18 -0400 Subject: [Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent In-Reply-To: <200905282240.19607.xgizzmo@slackbuilds.org> References: <20090528200331.2a9f821e@liberty.rlwhome.lan> <200905282240.19607.xgizzmo@slackbuilds.org> Message-ID: <6c341e560905281959y3e2eaferc950893c4e4c2e01@mail.gmail.com> On Thu, May 28, 2009 at 10:40 PM, wrote: > On Thursday 28 May 2009 21:15:55 Grissiom wrote: > > > > > > IMHO, if a package uses */lib64 then it's an ARCH=x86_64 package. > > > > > > > This seems to be what Slackware does. I think the best thing to do > here is just to make sure we use ARCH=${ARCH:-noarch} and not hard > code it. That way if the package builder is building for x86_64 > then they should be using ARCH=x86_64 ./some.SlackBuild and it will > have an x86_64 tag on the final package. So far all of the python > builds I have seen that use setup.py find the right python path > on their own, so the SlackBuild does not have to be changed in > any other way. > I don't like the idea of defaulting to noarch if the package is incompatible with x86_64. If we're going to have separate packages, they should be clearly marked as such. Making one 'noarch' and one 'x86_64' is inconsistent. It's either 'noarch' or it isn't. > > --dsomero > > _______________________________________________ > 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/ > > -- http://www.dragonwisard.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From rworkman at slackbuilds.org Fri May 29 03:22:38 2009 From: rworkman at slackbuilds.org (Robby Workman) Date: Thu, 28 May 2009 22:22:38 -0500 Subject: [Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent In-Reply-To: <6c341e560905281959y3e2eaferc950893c4e4c2e01@mail.gmail.com> References: <20090528200331.2a9f821e@liberty.rlwhome.lan> <200905282240.19607.xgizzmo@slackbuilds.org> <6c341e560905281959y3e2eaferc950893c4e4c2e01@mail.gmail.com> Message-ID: <20090528222238.6dead7ec@liberty.rlwhome.lan> On Thu, 28 May 2009 22:59:18 -0400 Dragon Wisard wrote: > On Thu, May 28, 2009 at 10:40 PM, wrote: > > > On Thursday 28 May 2009 21:15:55 Grissiom wrote: > > > > > > > > IMHO, if a package uses */lib64 then it's an ARCH=x86_64 > > > > package. > > > > > > > > > > > This seems to be what Slackware does. I think the best thing to do > > here is just to make sure we use ARCH=${ARCH:-noarch} and not hard > > code it. That way if the package builder is building for x86_64 > > then they should be using ARCH=x86_64 ./some.SlackBuild and it will > > have an x86_64 tag on the final package. So far all of the python > > builds I have seen that use setup.py find the right python path > > on their own, so the SlackBuild does not have to be changed in > > any other way. > > > > I don't like the idea of defaulting to noarch if the package is > incompatible with x86_64. If we're going to have separate packages, > they should be clearly marked as such. Making one 'noarch' and one > 'x86_64' is inconsistent. It's either 'noarch' or it isn't. Yep, I agree - I was about to reply with the same, but instead, ++ here. :-) -RW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From xgizzmo at slackbuilds.org Fri May 29 03:45:40 2009 From: xgizzmo at slackbuilds.org (xgizzmo at slackbuilds.org) Date: Thu, 28 May 2009 23:45:40 -0400 Subject: [Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent In-Reply-To: <6c341e560905281959y3e2eaferc950893c4e4c2e01@mail.gmail.com> References: <200905282240.19607.xgizzmo@slackbuilds.org> <6c341e560905281959y3e2eaferc950893c4e4c2e01@mail.gmail.com> Message-ID: <200905282345.41455.xgizzmo@slackbuilds.org> On Thursday 28 May 2009 22:59:18 Dragon Wisard wrote: > I don't like the idea of defaulting to noarch if the package is incompatible > with x86_64. If we're going to have separate packages, they should be > clearly marked as such. Making one 'noarch' and one 'x86_64' is > inconsistent. It's either 'noarch' or it isn't. > Then for 32 bit if it in not noarch then what its it? its not i386 or i486 or i585 or i686. I don't see this as a problem that needs solving. It is really no different than a package for slackware 11 not working on slackware 12.2. The packages are Slackware version (64 bit being a different version) dependant not arch dependant. If the package builder prefers to call the package something else then they can. Most of the python builds are noarch there is no arch dependant code in them so they ARE noarch. The problem is caused by a different version of Slackware that uses a different python path. --dsomero From pc_warner at yahoo.com Fri May 29 03:47:47 2009 From: pc_warner at yahoo.com (Phillip Warner) Date: Thu, 28 May 2009 20:47:47 -0700 (PDT) Subject: [Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent Message-ID: <528239.82765.qm@web57707.mail.re3.yahoo.com> How about using ARCH=x86_32 for Slackware 12.2 and ARCH=x86_64 for Slackware64 unless the package has nothing to do with any lib/lib64 business, etc, which it could then have the pure ARCH=noarch? If setup.py always detects the right python dir as previously mentioned, then perhaps we only need the python detection scriptlet that Eric mentioned in rare cases. --phillip From pc_warner at yahoo.com Fri May 29 03:55:20 2009 From: pc_warner at yahoo.com (Phillip Warner) Date: Thu, 28 May 2009 20:55:20 -0700 (PDT) Subject: [Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent Message-ID: <863352.86677.qm@web57707.mail.re3.yahoo.com> As an alternative solution, maybe it would be a good idea for all of the SBo packages to have a default tag that includes the Slackware version (at least for the 64 bit). So, python_package-version-noarch-#_SBo64 for Slackware64 and python_package-version-noarch-#_SBo for Slackware 12.2 Could even have python_package-version-noarch-#_SBo13 but only the 64 bit distinction is really necessary. The modified tag for 64 bit would allow the noarch to be pure and hopefully satisfy all camps. --phillip --- On Thu, 5/28/09, xgizzmo at slackbuilds.org wrote: > From: xgizzmo at slackbuilds.org > Subject: Re: [Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent > To: slackbuilds-users at slackbuilds.org > Date: Thursday, May 28, 2009, 8:45 PM > On Thursday 28 May 2009 22:59:18 > Dragon Wisard wrote: > > I don't like the idea of defaulting to noarch if the > package is incompatible > > with x86_64. If we're going to have separate packages, > they should be > > clearly marked as such. Making one 'noarch' and one > 'x86_64' is > > inconsistent. It's either 'noarch' or it isn't. > > > > Then for 32 bit if it in not noarch then what its it? its > not i386 or i486 > or i585 or i686. I don't see this as a problem that needs > solving. It is > really no different than a package for slackware 11 not > working on slackware > 12.2. The packages are Slackware version (64 bit being a > different version) > dependant not arch dependant. If the package builder > prefers to call the > package something else then they can. Most of the python > builds are noarch > there is no arch dependant code in them so they ARE noarch. > The problem is > caused by a different version of Slackware that uses a > different python path. > > --dsomero??? > _______________________________________________ > 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 Fri May 29 03:57:06 2009 From: rworkman at slackbuilds.org (Robby Workman) Date: Thu, 28 May 2009 22:57:06 -0500 Subject: [Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent In-Reply-To: <200905282345.41455.xgizzmo@slackbuilds.org> References: <200905282240.19607.xgizzmo@slackbuilds.org> <6c341e560905281959y3e2eaferc950893c4e4c2e01@mail.gmail.com> <200905282345.41455.xgizzmo@slackbuilds.org> Message-ID: <20090528225706.77930d7f@liberty.rlwhome.lan> On Thu, 28 May 2009 23:45:40 -0400 xgizzmo at slackbuilds.org wrote: > On Thursday 28 May 2009 22:59:18 Dragon Wisard wrote: > > I don't like the idea of defaulting to noarch if the package is > > incompatible with x86_64. If we're going to have separate packages, > > they should be clearly marked as such. Making one 'noarch' and one > > 'x86_64' is inconsistent. It's either 'noarch' or it isn't. > > > > Then for 32 bit if it in not noarch then what its it? its not i386 or > i486 or i585 or i686. I don't see this as a problem that needs > solving. It is really no different than a package for slackware 11 > not working on slackware 12.2. The packages are Slackware version (64 > bit being a different version) dependant not arch dependant. If the > package builder prefers to call the package something else then they > can. Most of the python builds are noarch there is no arch dependant > code in them so they ARE noarch. The problem is caused by a different > version of Slackware that uses a different python path. And of course, that's a valid counterpoint. I guess we (the admins) will discuss this elsewhere and work out something :-) -RW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From chess at chessgriffin.com Fri May 29 04:08:52 2009 From: chess at chessgriffin.com (Chess Griffin) Date: Fri, 29 May 2009 00:08:52 -0400 Subject: [Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent In-Reply-To: <20090528225706.77930d7f@liberty.rlwhome.lan> References: <200905282240.19607.xgizzmo@slackbuilds.org> <6c341e560905281959y3e2eaferc950893c4e4c2e01@mail.gmail.com> <200905282345.41455.xgizzmo@slackbuilds.org> <20090528225706.77930d7f@liberty.rlwhome.lan> Message-ID: <20090529000852.614a0f6d@slack64.localdomain> On Thu, 28 May 2009 22:57:06 -0500 Robby Workman wrote: > On Thu, 28 May 2009 23:45:40 -0400 > xgizzmo at slackbuilds.org wrote: > > > On Thursday 28 May 2009 22:59:18 Dragon Wisard wrote: > > > I don't like the idea of defaulting to noarch if the package is > > > incompatible with x86_64. If we're going to have separate > > > packages, they should be clearly marked as such. Making one > > > 'noarch' and one 'x86_64' is inconsistent. It's either 'noarch' > > > or it isn't. > > > > > > > Then for 32 bit if it in not noarch then what its it? its not i386 > > or i486 or i585 or i686. I don't see this as a problem that needs > > solving. It is really no different than a package for slackware 11 > > not working on slackware 12.2. The packages are Slackware version > > (64 bit being a different version) dependant not arch dependant. If > > the package builder prefers to call the package something else then > > they can. Most of the python builds are noarch there is no arch > > dependant code in them so they ARE noarch. The problem is caused by > > a different version of Slackware that uses a different python path. > > > And of course, that's a valid counterpoint. I guess we (the admins) > will discuss this elsewhere and work out something :-) > > -RW I am probably missing the finer points of this discussion, but it seems to me that the current system works just fine. User A on a 32 bit system who has not set ARCH as an environmental variable and builds a package from a 'noarch' SlackBuild script, will end up with a package with 'noarch' in the name and libraries in /usr/lib. That can be re-distributed between other 32 bit systems. OTOH, User B on a 64 bit sysem who has set ARCH as 'x86_64', either in the environment or passing it to the SlackBuild script, will end up with a package with 'x86_64' in the name, with libraries in /usr/lib64 which can be redistributed between other 64 bit systems. The truly independent 'noarch' packages are those simple ones that simply build a single /usr/bin/ binary with make or that install icon sets or something. -- Chess Griffin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From dn2010 at gmail.com Fri May 29 05:13:09 2009 From: dn2010 at gmail.com (Daniil Bratashov) Date: Fri, 29 May 2009 09:13:09 +0400 Subject: [Slackbuilds-users] gwyddion slackbuild Message-ID: <20090529091309.734e3e00@darkstar.example.net> Please remove subj from pending, I'll resubmit the new version with libdir part fixed. WBR, Daniil Bratashov. From stefanovic.dusan at gmail.com Fri May 29 10:14:05 2009 From: stefanovic.dusan at gmail.com (=?UTF-8?B?RHXFoWFuIFN0ZWZhbm92acSH?=) Date: Fri, 29 May 2009 12:14:05 +0200 Subject: [Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent In-Reply-To: <20090529000852.614a0f6d@slack64.localdomain> References: <200905282240.19607.xgizzmo@slackbuilds.org> <6c341e560905281959y3e2eaferc950893c4e4c2e01@mail.gmail.com> <200905282345.41455.xgizzmo@slackbuilds.org> <20090528225706.77930d7f@liberty.rlwhome.lan> <20090529000852.614a0f6d@slack64.localdomain> Message-ID: I'm not trying to hijack this thread, but there is another question related to this discussion. What about i486 packages that are created for slackware64? slackware64 is multilib, so it is perfectly legal to do this. How should I name package that has 32bit binary inside, but is created for slack64? name-version-x86_64-build or name-version-i486-build or name-version-i486-build_s64? Long time ago slack packages had different name scheme than today (you can see it here: ftp://ftp.slackware.no/pub/linux/slackware/slackware-4.0/slakware/d1/ ). It was name.tgz, then after few releases it was changed to what we know today name-version-arch-build. Pat already has problem with this naming scheme, because it doesn't have slackware version (you can see that at any slack mirror, just look at patches directory). I know that it is for Pat to decide and not for as, but maybe it is time for change. pkgtools are already changed for next release, so maybe it is possible to add slackware version to naming scheme. regards, ds On Fri, May 29, 2009 at 06:08, Chess Griffin wrote: > On Thu, 28 May 2009 22:57:06 -0500 > Robby Workman wrote: > >> On Thu, 28 May 2009 23:45:40 -0400 >> xgizzmo at slackbuilds.org wrote: >> >> > On Thursday 28 May 2009 22:59:18 Dragon Wisard wrote: >> > > I don't like the idea of defaulting to noarch if the package is >> > > incompatible with x86_64. If we're going to have separate >> > > packages, they should be clearly marked as such. Making one >> > > 'noarch' and one 'x86_64' is inconsistent. It's either 'noarch' >> > > or it isn't. >> > > >> > >> > Then for 32 bit if it in not noarch then what its it? its not i386 >> > or i486 or i585 or i686. I don't see this as a problem that needs >> > solving. It is really no different than a package for slackware 11 >> > not working on slackware 12.2. The packages are Slackware version >> > (64 bit being a different version) dependant not arch dependant. If >> > the package builder prefers to call the package something else then >> > they can. Most of the python builds are noarch there is no arch >> > dependant code in them so they ARE noarch. The problem is caused by >> > a different version of Slackware that uses a different python path. >> >> >> And of course, that's a valid counterpoint. ?I guess we (the admins) >> will discuss this elsewhere and work out something :-) >> >> -RW > > I am probably missing the finer points of this discussion, but it seems > to me that the current system works just fine. ?User A on a 32 bit > system who has not set ARCH as an environmental variable and builds a > package from a 'noarch' SlackBuild script, will end up with a package > with 'noarch' in the name and libraries in /usr/lib. ?That can be > re-distributed between other 32 bit systems. ?OTOH, User B on a 64 bit > sysem who has set ARCH as 'x86_64', either in the environment or > passing it to the SlackBuild script, will end up with a package with > 'x86_64' in the name, with libraries in /usr/lib64 which can be > redistributed between other 64 bit systems. > > The truly independent 'noarch' packages are those simple ones that > simply build a single /usr/bin/ binary with make or that install icon > sets or something. > > -- > 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 chaos.proton at gmail.com Fri May 29 11:14:34 2009 From: chaos.proton at gmail.com (Grissiom) Date: Fri, 29 May 2009 19:14:34 +0800 Subject: [Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent In-Reply-To: <20090529000852.614a0f6d@slack64.localdomain> References: <200905282240.19607.xgizzmo@slackbuilds.org> <6c341e560905281959y3e2eaferc950893c4e4c2e01@mail.gmail.com> <200905282345.41455.xgizzmo@slackbuilds.org> <20090528225706.77930d7f@liberty.rlwhome.lan> <20090529000852.614a0f6d@slack64.localdomain> Message-ID: On Fri, May 29, 2009 at 12:08, Chess Griffin wrote: > I am probably missing the finer points of this discussion, but it seems > to me that the current system works just fine. User A on a 32 bit > system who has not set ARCH as an environmental variable and builds a > package from a 'noarch' SlackBuild script, will end up with a package > with 'noarch' in the name and libraries in /usr/lib. That can be > re-distributed between other 32 bit systems. OTOH, User B on a 64 bit > sysem who has set ARCH as 'x86_64', either in the environment or > passing it to the SlackBuild script, will end up with a package with > 'x86_64' in the name, with libraries in /usr/lib64 which can be > redistributed between other 64 bit systems. > Yes, but currently some packages build from SlackBuilds(mostly for python modules) will install thing into /usr/lib64 even have "noarch" tag. > The truly independent 'noarch' packages are those simple ones that > simply build a single /usr/bin/ binary with make or that install icon > sets or something. > Hmm, I think rworkman will agree with you. -- Cheers, Grissiom -------------- next part -------------- An HTML attachment was scrubbed... URL: From chaos.proton at gmail.com Fri May 29 11:26:15 2009 From: chaos.proton at gmail.com (Grissiom) Date: Fri, 29 May 2009 19:26:15 +0800 Subject: [Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent In-Reply-To: References: <200905282240.19607.xgizzmo@slackbuilds.org> <6c341e560905281959y3e2eaferc950893c4e4c2e01@mail.gmail.com> <200905282345.41455.xgizzmo@slackbuilds.org> <20090528225706.77930d7f@liberty.rlwhome.lan> <20090529000852.614a0f6d@slack64.localdomain> Message-ID: 2009/5/29 Du?an Stefanovi? > I'm not trying to hijack this thread, but there is another question > related to this discussion. What about i486 packages that are created > for slackware64? > slackware64 is multilib, so it is perfectly legal to do this. How > should I name package that has 32bit binary inside, but is created for > slack64? > > name-version-x86_64-build or name-version-i486-build or > name-version-i486-build_s64? > > Long time ago slack packages had different name scheme than today (you > can see it here: > ftp://ftp.slackware.no/pub/linux/slackware/slackware-4.0/slakware/d1/ > ). It was name.tgz, then after few releases it was changed to what we > know today name-version-arch-build. Pat already has problem with this > naming scheme, because it doesn't have slackware version (you can see > that at any slack mirror, just look at patches directory). I know that > it is for Pat to decide and not for as, but maybe it is time for > change. pkgtools are already changed for next release, so maybe it is > possible to add slackware version to naming scheme. > > regards, > ds > Yes, although the naming scheme is not the mission of this thread but I think it *may* provide a solution for this problem. Especially for the ones that think Slackware64 is just a other *version* of slackware but not the stoke slackware in x86_64 arch. But this will bring an other problem. What if the both the files *and* the directory structure are arch independent?(bash-completion as an example, although it not in slackware64 now) It's also non-sense to have two names with one package that exactly the same. -- Cheers, Grissiom -------------- next part -------------- An HTML attachment was scrubbed... URL: From stefanovic.dusan at gmail.com Fri May 29 11:37:03 2009 From: stefanovic.dusan at gmail.com (=?UTF-8?B?RHXFoWFuIFN0ZWZhbm92acSH?=) Date: Fri, 29 May 2009 13:37:03 +0200 Subject: [Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent In-Reply-To: References: <200905282240.19607.xgizzmo@slackbuilds.org> <6c341e560905281959y3e2eaferc950893c4e4c2e01@mail.gmail.com> <200905282345.41455.xgizzmo@slackbuilds.org> <20090528225706.77930d7f@liberty.rlwhome.lan> <20090529000852.614a0f6d@slack64.localdomain> Message-ID: > But this will bring an other problem. What if the both the files *and* the > directory structure are arch independent?(bash-completion as an example, > although it not in slackware64 now) It's also non-sense to have two names > with one package that exactly the same. > > -- > Cheers, > Grissiom > I could live with that... regards, ds From eha at sox.homeip.net Fri May 29 12:05:24 2009 From: eha at sox.homeip.net (Eric Hameleers) Date: Fri, 29 May 2009 14:05:24 +0200 (CEST) Subject: [Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent In-Reply-To: References: <200905282240.19607.xgizzmo@slackbuilds.org> <6c341e560905281959y3e2eaferc950893c4e4c2e01@mail.gmail.com> <200905282345.41455.xgizzmo@slackbuilds.org> <20090528225706.77930d7f@liberty.rlwhome.lan> <20090529000852.614a0f6d@slack64.localdomain> Message-ID: On Fri, 29 May 2009, [UTF-8] Du?an Stefanovi? wrote: > I'm not trying to hijack this thread, but there is another question > related to this discussion. What about i486 packages that are created > for slackware64? > slackware64 is multilib, so it is perfectly legal to do this. How > should I name package that has 32bit binary inside, but is created for > slack64? > > name-version-x86_64-build or name-version-i486-build or > name-version-i486-build_s64? It's really quite simple. If you build a 32bit compatibility package for slackware64, on slackware64, you are still building with an ARCH set to "x86_64" and with the "-m32" option added to the gcc invocation (assuming you are running a slackware with 32bit compatibility layer added on top). This will generate 32bit binaries, but the final package name will still have "x86_64" in the ARCH section. See ftp://anorien.warwick.ac.uk/slamd64/slackware64-current/source/a-compat32/bzip2-compat32/bzip2-compat32.SlackBuild for an example of how Fred Emmott created the 32bit compatibility packages for Slackware64. Also note that he added "-compat32" to the package _name_ so that the 32bit package can co-exist with the 64bit package. > Long time ago slack packages had different name scheme than today (you > can see it here: > ftp://ftp.slackware.no/pub/linux/slackware/slackware-4.0/slakware/d1/ > ). It was name.tgz, then after few releases it was changed to what we > know today name-version-arch-build. Pat already has problem with this > naming scheme, because it doesn't have slackware version (you can see > that at any slack mirror, just look at patches directory). I know that > it is for Pat to decide and not for as, but maybe it is time for > change. pkgtools are already changed for next release, so maybe it is > possible to add slackware version to naming scheme. Absolutely not going to happen! This is just not doing any good at all. There is a reason why the SlackBuilds at slackbuilds.org are categorized by Slackware release. If you want a SlackBuild for Slackware 12.2 you go looking in http://slackbuilds.org/slackbuilds/12.2/ - the SlackBuild itself should not concern itself with the Slackware version. I see this every so often, when people ask that we change our philosophy because some other party will benefit from it (notably 3rd party package repositories that are built from SBo scripts) but we have repeatedly made clear that we care about the quality of the scripts and that they should produce good packages. We are validating the scripts against one single Slackware release and that release branch is where the tarball is going to end up in our repository. If you want to change the name of your final package, or even the package extension (and thereby the compression scheme), you are perfectly free to edit the SlackBuild you've downloaded from our repository. Eric -- Eric Hameleers Email: alien at slackware.com Jabber: alien at jabber.xs4all.nl Gpg fingerprint: F2CE 1B92 EE1F 2C0C E97E 581E 5E56 AAAF A75C BDA0 From martin at priv.la5ska.net Fri May 29 12:42:05 2009 From: martin at priv.la5ska.net (Odd Martin Baanrud) Date: Fri, 29 May 2009 14:42:05 +0200 Subject: [Slackbuilds-users] Problems with building qemu and clamav Message-ID: <20090529124053.4A7E03580F@home.la5ska.net> Hello, I have problems with building the qemu and clamav packages. Here is the error I get while building qemu: "Error: esd check failed Make sure to have the esd libs and headers installed." And here are those from clamav: "configure: error: Cannot find libmilter make: *** No targets specified and no makefile found. Stop." How should I solve these problems? Are their some packages I need to build/install? Regards, Martin From stefanovic.dusan at gmail.com Fri May 29 13:42:08 2009 From: stefanovic.dusan at gmail.com (=?UTF-8?B?RHXFoWFuIFN0ZWZhbm92acSH?=) Date: Fri, 29 May 2009 15:42:08 +0200 Subject: [Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent In-Reply-To: References: <200905282240.19607.xgizzmo@slackbuilds.org> <6c341e560905281959y3e2eaferc950893c4e4c2e01@mail.gmail.com> <200905282345.41455.xgizzmo@slackbuilds.org> <20090528225706.77930d7f@liberty.rlwhome.lan> <20090529000852.614a0f6d@slack64.localdomain> Message-ID: On Fri, May 29, 2009 at 14:05, Eric Hameleers wrote: > It's really quite simple. If you build a 32bit compatibility package for > slackware64, on slackware64, you are still building with an ARCH set to > "x86_64" and with the "-m32" option added to the gcc invocation (assuming > you are running a slackware with 32bit compatibility layer added on top). > This will generate 32bit binaries, but the final package name will still > have "x86_64" in the ARCH section. > > See > ftp://anorien.warwick.ac.uk/slamd64/slackware64-current/source/a-compat32/bzip2-compat32/bzip2-compat32.SlackBuild > for an example of how Fred Emmott created the 32bit compatibility packages > for Slackware64. Also note that he added "-compat32" to the package _name_ > so that the 32bit package can co-exist with the 64bit package. > Well, I see advantage with "-compat32", but why call a 32bit binary x86_64? Similary, why call noarch package x86_64 just because directory structure is differnt? On the other hand, at ftp://anorien.warwick.ac.uk/slamd64/slackware64-current/slackware64/x-compat32/ there are packages like libXau-compat32-1.0.4-i486-1_slamd64.txz or libXres-compat32-1.0.3-i486-1_slamd64.txz Maybe I don't see the point, maybe 32bit binary that is build on slackware64 (with multilib added on top) is not true 32bit anymore, is this the case here? > Absolutely not going to happen! This is just not doing any good at all. > There is a reason why the ?SlackBuilds at slackbuilds.org are categorized by > Slackware release. If you want a SlackBuild for Slackware 12.2 you go > looking in http://slackbuilds.org/slackbuilds/12.2/ - the SlackBuild itself > should not concern itself with the Slackware version. > > I see this every so often, when people ask that we change our philosophy > because some other party will benefit from it (notably 3rd party package > repositories that are built from SBo scripts) I was actualy thinking about "first" party, slackware itself (and things that happen after release, patches directory). But, I'm not going to argue about that, pkgtools are good enough right now. > but we have repeatedly made > clear that we care about the quality of the scripts and that they should > produce good packages. We are validating the scripts against one single > Slackware release and that release branch is where the tarball is going to > end up in our repository. > If you want to change the name of your final package, or even the package > extension (and thereby the compression scheme), you are perfectly free to > edit the SlackBuild you've downloaded from our repository. > > Eric > Well, if this was addressed to me, just to be clear, I don't use/care about 3rd party package repositories, and my question/suggestion doesn't have anything related with them. > -- > Eric Hameleers > Email: alien at slackware.com > Jabber: alien at jabber.xs4all.nl > Gpg fingerprint: F2CE 1B92 EE1F 2C0C E97E ?581E 5E56 AAAF A75C BDA0 regrads, ds From banderols at gmail.com Fri May 29 15:52:46 2009 From: banderols at gmail.com (Murat D. Kadirov) Date: Fri, 29 May 2009 21:52:46 +0600 Subject: [Slackbuilds-users] Problems with building qemu and clamav In-Reply-To: <20090529124053.4A7E03580F@home.la5ska.net> References: <20090529124053.4A7E03580F@home.la5ska.net> Message-ID: <20090529155246.GA11794@darkstar> 14:42 Fri 29 May, Odd Martin Baanrud wrote: > Hello, > > I have problems with building the qemu and clamav packages. > Here is the error I get while building qemu: > "Error: esd check failed I think you need install esound from official packages. -- Murat D. Kadirov -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From audrius at neutrino.lt Sat May 30 10:39:50 2009 From: audrius at neutrino.lt (Audrius =?utf-8?Q?Ka=C5=BEukauskas?=) Date: Sat, 30 May 2009 13:39:50 +0300 Subject: [Slackbuilds-users] Problems with building qemu and clamav In-Reply-To: <20090529124053.4A7E03580F@home.la5ska.net> References: <20090529124053.4A7E03580F@home.la5ska.net> Message-ID: <20090530103950.GA2276@kiras.geris> On Fri, 2009-05-29 at 14:42:05 +0200, Odd Martin Baanrud wrote: > I have problems with building the qemu and clamav packages. > Here is the error I get while building qemu: > "Error: esd check failed > > Make sure to have the esd libs and headers installed." For that you need esound. > And here are those from clamav: > "configure: error: Cannot find libmilter > > make: *** No targets specified and no makefile found. Stop." And for this one you need sendmail. > How should I solve these problems? > Are their some packages I need to build/install? If you use slackpkg, here's a handy way to quickly look for package which has missing library: $ slackpkg search -- Audrius Ka?ukauskas -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From xgizzmo at slackbuilds.org Sun May 31 01:52:26 2009 From: xgizzmo at slackbuilds.org (xgizzmo at slackbuilds.org) Date: Sat, 30 May 2009 21:52:26 -0400 Subject: [Slackbuilds-users] Updates - 20090530 Message-ID: <200905302152.26392.xgizzmo@slackbuilds.org> Sat May 30 23:39:42 UTC 2009 development/help2man: Updated SlackBuild for x86_64. Thanks to Chess Griffin. --dsomero games/blobwars: Added - blobwars is a 2d arcade platform game. Thanks to Tim Dickson. --chess games/micropolis: Updated SlackBuild for x86_64. Thanks to Chess Griffin. --dsomero games/nexuiz: Updated for version 2.5.1. Thanks to Chess Griffin. --dsomero games/openarena: Updated SlackBuild for x86_64. Thanks to Chess Griffin. --dsomero games/openttd: Updated SlackBuild for x86_64. Thanks to Chess Griffin. --dsomero graphics/feh: Updated SlackBuild for x86_64. Thanks to Chess Griffin. --dsomero graphics/gpscorrelate: Updated for version 1.6.0. Thanks to David Spencer. --dsomero libraries/giblib: Updated SlackBuild for x86_64. Thanks to Chess Griffin. --dsomero libraries/imlib2: Updated SlackBuild for x86_64. Thanks to Chess Griffin. --dsomero libraries/libsigc++: Updated for version 2.2.3. Thanks to paul wisehart. --dsomero misc/gramps: Updated for version 3.1.1. Thanks to Bill Kirkpatrick. --dsomero multimedia/gpodder: Updated SlackBuild for x86_64. Thanks to Chess Griffin. --dsomero network/bip: Updated for version 0.8.0. Thanks to Chess Griffin. --dsomero network/dovecot: Updated for version 1.1.15. Thanks to Alan Hicks. --dsomero network/feedparser: Updated SlackBuild for x86_64. Thanks to Chess Griffin. --dsomero network/kvirc: Updated SlackBuild for x86_64. Thanks to Elvio Basello. --dsomero network/postfix: Updated for version 2.6.1. Thanks to Alan Hicks. --dsomero network/wireshark: Updated for version 1.0.8 this also fixes the security vulnerability: http://www.wireshark.org/security/wnpa-sec-2009-03.html. Thanks to Michiel van Wessem. --dsomero system/emelfm2: Updated for version 0.6.0. Thanks to Chess Griffin. --dsomero system/gparted: Updated for version 0.4.5. Thanks to Erik Hanson. --chess system/gpsd: Updated for version 2.39. Thanks to David Spencer. --dsomero system/graveman: Updated SlackBuild for x86_64. Thanks to Chess Griffin. --dsomero system/pcmanfm: Updated SlackBuild for x86_64. Thanks to Chess Griffin. --dsomero system/tmux: Updated SlackBuild for x86_64. Thanks to Chess Griffin. --dsomero From adis at linux.org.ba Sun May 31 19:48:53 2009 From: adis at linux.org.ba (Adis Nezirovic) Date: Sun, 31 May 2009 21:48:53 +0200 Subject: [Slackbuilds-users] PostgreSQL init script stop/restart options Message-ID: <20090531194853.GA3531@hiigarah.localhost.ba> Hello, Last week I've had interesing suggestion for PostgreSQL init script. The main issue is that pg_ctl, utility that starts Postgres, has three modes of operation: --- Three different shutdown methods can be selected with the -m option: - "Smart" mode waits for all the clients to disconnect. This is the default. - "Fast" mode does not wait for clients to disconnect. All active transactions are rolled back and clients are forcibly disconnected, then the server is shut down. - "Immediate" mode will abort all server processes without a clean shutdown. This will lead to a recovery run on restart. --- Current init script uses explicit '-m smart' option. And for users it looks like this: /etc/rc.d/rc.postgres {stop|restart} Sometimes, one needs to force server restart, (e.g PHP script gone bad, and it uses persistent connections) but "smart" option doesn't want to kill active connections.) Anyway, my first idea was to use something like this /etc/rc.d/rc.postgres {stop|restart} [smart|fast|immediate] (smart is the default and can be ommited) It's somewhat strange syntax for init script, but other options should be used only for extreme situations, especially immediate). Other proposal would be: /etc/rc.d/rc.postgres {restart|force-restart|unclean-restart} /etc/rc.d/rc.postgres {stop|force-stop|unclean-stop} What do you think, what's the proper way to treat "advanced" init script actions? Best regards, Adis -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From rworkman at slackbuilds.org Sun May 31 22:38:47 2009 From: rworkman at slackbuilds.org (Robby Workman) Date: Sun, 31 May 2009 17:38:47 -0500 Subject: [Slackbuilds-users] PostgreSQL init script stop/restart options In-Reply-To: <20090531194853.GA3531@hiigarah.localhost.ba> References: <20090531194853.GA3531@hiigarah.localhost.ba> Message-ID: <20090531173847.4e28c71f@liberty.rlwhome.lan> On Sun, 31 May 2009 21:48:53 +0200 Adis Nezirovic wrote: > Hello, > > Last week I've had interesing suggestion for PostgreSQL init script. > The main issue is that pg_ctl, utility that starts Postgres, has three > modes of operation: > > --- > Three different shutdown methods can be selected with the -m option: > - "Smart" mode waits for all the clients to disconnect. This is the > default. > - "Fast" mode does not wait for clients to disconnect. All active > transactions are rolled back and clients are forcibly disconnected, > then the server is shut down. > - "Immediate" mode will abort all server processes without a clean > shutdown. This will lead to a recovery run on restart. > --- > > Current init script uses explicit '-m smart' option. And for users it > looks like this: > /etc/rc.d/rc.postgres {stop|restart} > > > Sometimes, one needs to force server restart, (e.g PHP script gone > bad, and it uses persistent connections) but "smart" option doesn't > want to kill active connections.) > > Anyway, my first idea was to use something like this > > /etc/rc.d/rc.postgres {stop|restart} [smart|fast|immediate] > > (smart is the default and can be ommited) > It's somewhat strange syntax for init script, but other options should > be used only for extreme situations, especially immediate). > > > Other proposal would be: > > /etc/rc.d/rc.postgres {restart|force-restart|unclean-restart} > /etc/rc.d/rc.postgres {stop|force-stop|unclean-stop} > > > What do you think, what's the proper way to treat "advanced" init > script actions? I personally like the second block better. -RW -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From timp at timp.com.au Sun May 31 22:54:04 2009 From: timp at timp.com.au (Timothy Pollard) Date: Mon, 1 Jun 2009 08:54:04 +1000 Subject: [Slackbuilds-users] PostgreSQL init script stop/restart options In-Reply-To: <20090531194853.GA3531@hiigarah.localhost.ba> References: <20090531194853.GA3531@hiigarah.localhost.ba> Message-ID: <20090601085404.210ab1ae@shammah.timp.com.au> On Sun, 31 May 2009 21:48:53 +0200 Adis Nezirovic wrote: > Hello, > ... > > Anyway, my first idea was to use something like this > > /etc/rc.d/rc.postgres {stop|restart} [smart|fast|immediate] > > (smart is the default and can be ommited) > It's somewhat strange syntax for init script, but other options should > be used only for extreme situations, especially immediate). > > > Other proposal would be: > > /etc/rc.d/rc.postgres {restart|force-restart|unclean-restart} > /etc/rc.d/rc.postgres {stop|force-stop|unclean-stop} > > > What do you think, what's the proper way to treat "advanced" init script > actions? > > > Best regards, > Adis I tend to agree with Robby in that the second block is probably best. As well as preferring it personally, this seems more similar to how the official rc.httpd script works. /etc/rc.d/rc.httpd {start|stop|restart|graceful|graceful-stop} ("graceful-stop" is essentially just a special variant of stop) This seems to be the standard, if there are two different variants of the same command the default one is the one word command, and the other variants are two word commands separated by hyphens. -- TimP [http://blog.timp.com.au] -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: