[Slackbuilds-users] gwyddion slackbuild

Please remove subj from pending, I'll resubmit the new version with libdir part fixed. WBR, Daniil Bratashov. ___ SlackBuilds-users mailing list SlackBuilds-users@slackbuilds.org http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users Archives -

Re: [Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent

On Thu, 28 May 2009 22:57:06 -0500 Robby Workman wrote: > On Thu, 28 May 2009 23:45:40 -0400 > xgiz...@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

Re: [Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent

On Thu, 28 May 2009 23:45:40 -0400 xgiz...@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

Re: [Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent

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 1

Re: [Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent

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 nee

Re: [Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent

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

Re: [Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent

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 Slackwa

Re: [Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent

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

Re: [Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent

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

Re: [Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent

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 filesyst

Re: [Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent

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" differen

Re: [Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent

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 packag

Re: [Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent

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

Re: [Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent

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

Re: [Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent

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 packag

Re: [Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent

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 j

Re: [Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent

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

Re: [Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent

-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

Re: [Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent

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 __

Re: [Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent

> > > 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 >

Re: [Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent

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 instal

Re: [Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent

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

Re: [Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent

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-b

Re: [Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent

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

[Slackbuilds-users] [FYI]SlackBuild for python modules should be architecture dependent

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