Re: [gentoo-dev] Unmasking dev-python/setuptools 0.6_alpha5?
On Fri, Nov 11, 2005 at 10:01:33PM -0600, Edward Muller wrote: > Anyone know how safe/unsafe dev-python/setuptools-0.6_alpha5 is? I am > building > an ebuild for Turbogears and a current version of setuptools is required. Just in case you haven't seen it, you should take a look at http://eggs.gentooexperimental.org/ I have also tried making an ebuild for Turbogears and it is a really tough job without a nice way to handle eggs, so you should probably grab eggs.eclass and use that. -- Anders -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS/O d--@ s:+ a-- C++ UL+++$ P++ L+++ E- W+ N(+) o K? w O-- M- V PS+ PE@ Y+ PGP+ t 5 X R+ tv+ b++ DI+++ D+ G e- h !r y? --END GEEK CODE BLOCK-- PGPKey: http://random.sks.keyserver.penguin.de:11371/pks/lookup?op=get&search=0xD4DEFED0 -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Timezone /etc/conf.d/clock
On Thu, Feb 15, 2007 at 08:01:11AM -0500, Caleb Cushing wrote: > which most probably aren't since that was changed in the handbook > (wonders why it was). It might have something to do with the fact that FHS specifies that /usr does not have to be on the root partition and thus using a symlink in /etc to somewhere in /usr is bad because most of the stuff in /etc is needed during boot, before other partitions are mounted. Moving away from using a symlink for localtime is therefore a step in the right direction for FHS compliance. -- Anders -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS/O d--@ s:+ a-- C++ UL+++$ P++ L+++ E- W+ N(+) o K? w O-- M- V PS+ PE@ Y+ PGP+ t 5 X R+ tv+ b++ DI+++ D+ G e- h !r y? --END GEEK CODE BLOCK-- PGPKey: http://random.sks.keyserver.penguin.de:11371/pks/lookup?op=get&search=0xD4DEFED0 -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Ebuild versioning problems
Hi, I am working on an ebuild for open-iscsi (linux-iscsi-5.0.0.0.3rc6-363) and would like to know what the best way of dealing with that totally insane versionnumber is. Right now I have the ebuild named linux-iscsi-5.0.0.0.3_rc6363.ebuild and then set $MY_PV and $MY_P manually. Is there a better way? -- Anders -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS/O d--@ s:+ a-- C++ UL+++$ P++ L+++ E- W+ N(+) o K? w O-- M- V PS+ PE@ Y+ PGP+ t 5 X R+ tv+ b++ DI+++ D+ G e- h !r y? --END GEEK CODE BLOCK-- PGPKey: http://random.sks.keyserver.penguin.de:11371/pks/lookup?op=get&search=0xD4DEFED0 -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Ebuild versioning problems
On Tue, Jul 12, 2005 at 08:51:42AM -0400, Mike Frysinger wrote: > > I am working on an ebuild for open-iscsi (linux-iscsi-5.0.0.0.3rc6-363) > > and would like to know what the best way of dealing with that totally > > insane versionnumber is. > > Right now I have the ebuild named linux-iscsi-5.0.0.0.3_rc6363.ebuild > > and then set $MY_PV and $MY_P manually. > > Is there a better way? > none that i'm aware of :/ Okay, it will have to do then. > imho, projects who use those sort of versioning schemas should probably > rethink wtf the version # means to them I absolutely agree, but I am not associated with them in any way and therefore am not in a possition to convince them to reconsider their versioning policy (unfortunately). -- Anders -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS/O d--@ s:+ a-- C++ UL+++$ P++ L+++ E- W+ N(+) o K? w O-- M- V PS+ PE@ Y+ PGP+ t 5 X R+ tv+ b++ DI+++ D+ G e- h !r y? --END GEEK CODE BLOCK-- PGPKey: http://random.sks.keyserver.penguin.de:11371/pks/lookup?op=get&search=0xD4DEFED0 -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Ebuild versioning problems
On Wed, Jul 13, 2005 at 11:47:14AM -0400, Chris Gianelloni wrote: > > I absolutely agree, but I am not associated with them in any way and > > therefore am not in a possition to convince them to reconsider their > > versioning policy (unfortunately). > Why not just ask them? I've found that some people will change, some > won't, but they definitely won't change if you don't at least ask. I've now tried to ask on their -devel list, but have met nothing but silence. Guess they don't want to discuss their versioning scheme :-/ -- Anders -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS/O d--@ s:+ a-- C++ UL+++$ P++ L+++ E- W+ N(+) o K? w O-- M- V PS+ PE@ Y+ PGP+ t 5 X R+ tv+ b++ DI+++ D+ G e- h !r y? --END GEEK CODE BLOCK-- PGPKey: http://random.sks.keyserver.penguin.de:11371/pks/lookup?op=get&search=0xD4DEFED0 -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Python setuptools/eggs
Hi, I wanted to try out the new and fabled TurboGears and found that it uses the new python software distribution tool setuptools and is distributed as python eggs. I can easily install it with setuptools/easy_setup, but I wanted to make an ebuild for TurboGears, which is not just so with setuptools and eggs. I started making ebuilds for the dependencies, but it seems that setuptools has a nasty habit of downloading dependencies for a package if it hasn't been installed by setuptools. So when eg. the new SQLObject 0.7rc1 (which also uses setuptools) depends upon FormEncode (not to mention depends upon setuptools) it does not care that I have already emerged setuptools or FormEncode, it just downloads the egg for it and installs it. It seems that alot of python projects are starting to use setuptools/easy_install/eggs, and granted, it is quite neat, but there needs to figured out a way to handle installing these things through Portage, or alot of new versions are going to be a pain to have installed. How should Portage handle this? I was thinking that maybe hacking up a Gentoo specific version of setuptools that would make it work together with Portage or something like that, but it seems a bit un-gentoo-like. A different approach could be to grab the .egg files and manually install them in the ebuilds, which wouldn't be a problem for pure-python packages, but would suck for packages with c-extensions included, since some might end bound to a specific subset of archs. Instead of me just blindly fumbling in the blind for a way to get ebuilds for TurboGears and it's assorted dependencies, I thought it would be better to get some official guidelines. Some useful URLs: http://peak.telecommunity.com/DevCenter/setuptools http://peak.telecommunity.com/DevCenter/EasyInstall http://peak.telecommunity.com/DevCenter/PythonEggs -- Anders -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS/O d--@ s:+ a-- C++ UL+++$ P++ L+++ E- W+ N(+) o K? w O-- M- V PS+ PE@ Y+ PGP+ t 5 X R+ tv+ b++ DI+++ D+ G e- h !r y? --END GEEK CODE BLOCK-- PGPKey: http://random.sks.keyserver.penguin.de:11371/pks/lookup?op=get&search=0xD4DEFED0 -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Python setuptools/eggs
On Sat, Oct 08, 2005 at 03:45:18PM -0700, Rob Cakebread wrote: > >How should Portage handle this? > I've been working on an eclass for these but its not ready. > I was hoping it'd be as easy as the Ruby gems eclass, because > they are similar, but eggs don't play nicely in a sandbox yet. But aren't eggs a bit against the Gentoo philosophy? I mean there are some eggs that contain precompiled C-extensions. Shouldn't it still be source builds that just somehow work with setuptools? > You're probably best off using the straight source for TurboGears > and its dependencies if you want to install via ebuild for now. The problem is that even straight source does not play nicely in ebuilds. Take SQLObject 0.7rc1, when you use the distutils eclass, it will still download setuptools as an egg and use that to do all dependency checks and resolutions. For SQLObject you can just delete the ez_setup dir after unpacking it, then it will use ordinary distutils with no dependency resolution, but with some packages such as FormEncode, you HAVE to use setuptools, or do everything manually in the ebuild. > Mail me off-list or join #gentoo-python if you're interested > in working on the easy_install eclass, please. Should we move this off-list? -- Anders -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS/O d--@ s:+ a-- C++ UL+++$ P++ L+++ E- W+ N(+) o K? w O-- M- V PS+ PE@ Y+ PGP+ t 5 X R+ tv+ b++ DI+++ D+ G e- h !r y? --END GEEK CODE BLOCK-- PGPKey: http://random.sks.keyserver.penguin.de:11371/pks/lookup?op=get&search=0xD4DEFED0 -- gentoo-dev@gentoo.org mailing list
