From trond.danielsen at gmail.com Mon Jun 2 05:45:38 2008 From: trond.danielsen at gmail.com (Trond Danielsen) Date: Mon, 2 Jun 2008 07:45:38 +0200 Subject: Enthought revisited Message-ID: <409676c70806012245x243346c8oa8478839c67d292c@mail.gmail.com> Hi everyone, in an previous thread on this mailing list several people expressed their interest in packaging the Enthought collection for Fedora. I wonder if this interest still exist, and if anyone with more experience than me in these matters would be willing to step up and lead the work required to get this done before Fedora 10? I most certainly am willing to contribute in packaging and testing, but do not fill qualified to take on the entire stack alone. Best Regards, -- Trond Danielsen From jspaleta at gmail.com Mon Jun 2 06:00:30 2008 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 1 Jun 2008 22:00:30 -0800 Subject: Enthought revisited In-Reply-To: <409676c70806012245x243346c8oa8478839c67d292c@mail.gmail.com> References: <409676c70806012245x243346c8oa8478839c67d292c@mail.gmail.com> Message-ID: <604aa7910806012300w59a9c41awfc3b856804f6b1fe@mail.gmail.com> On Sun, Jun 1, 2008 at 9:45 PM, Trond Danielsen wrote: > Hi everyone, > > in an previous thread on this mailing list several people expressed > their interest in packaging the Enthought collection for Fedora. I > wonder if this interest still exist, and if anyone with more > experience than me in these matters would be willing to step up and > lead the work required to get this done before Fedora 10? > > I most certainly am willing to contribute in packaging and testing, > but do not fill qualified to take on the entire stack alone. I think it is prudent to see if there is enthought upstream developer interest in helping with the task of integrating their full framework. I don't think it would be wise to attempt to pull the full stack in without coordinating with upstream. -jef From dmalcolm at redhat.com Fri Jun 13 15:39:54 2008 From: dmalcolm at redhat.com (David Malcolm) Date: Fri, 13 Jun 2008 11:39:54 -0400 Subject: Autogenerating rpm requirements from egg requirements Message-ID: <1213371594.7122.10.camel@radiator.bos.redhat.com> I ran into a problem with TurboGears packaging in EPEL5 where requirements in the requires.txt file in the egginfo subdirs were getting bumped upstream but without corresponding bumps in the rpm packaging, leading to yum failing to do all the upgrading I needed (filed as bug 451228 and 451231 so far). Has anyone tackled this problem? I had a go at trying to autogenerate the RPM metadata, I've attached my work-in-progress so far to bug 451228: https://bugzilla.redhat.com/attachment.cgi?id=309225 Thoughts? Worth finishing and turning into something in a common location for rpmbuild? Dave From gael.varoquaux at normalesup.org Sun Jun 15 01:16:20 2008 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Sun, 15 Jun 2008 03:16:20 +0200 Subject: Enthought revisited In-Reply-To: <604aa7910806012300w59a9c41awfc3b856804f6b1fe@mail.gmail.com> References: <409676c70806012245x243346c8oa8478839c67d292c@mail.gmail.com> <604aa7910806012300w59a9c41awfc3b856804f6b1fe@mail.gmail.com> Message-ID: <20080615011620.GD5196@phare.normalesup.org> On Sun, Jun 01, 2008 at 10:00:30PM -0800, Jeff Spaleta wrote: > On Sun, Jun 1, 2008 at 9:45 PM, Trond Danielsen > wrote: > > Hi everyone, > > in an previous thread on this mailing list several people expressed > > their interest in packaging the Enthought collection for Fedora. I > > wonder if this interest still exist, and if anyone with more > > experience than me in these matters would be willing to step up and > > lead the work required to get this done before Fedora 10? > > I most certainly am willing to contribute in packaging and testing, > > but do not fill qualified to take on the entire stack alone. > I think it is prudent to see if there is enthought upstream developer > interest in helping with the task of integrating their full framework. > I don't think it would be wise to attempt to pull the full stack in > without coordinating with upstream. Sorry, I have been travelling for holidays, and then relocating to the states. I guess it is me you are talking about, though other people are also willing to help, they are just not following this mailing list. Feel free to ask for any help or advice. We are willing to make some effort to make things easier for you to package. Cheers, Ga?l From a.badger at gmail.com Mon Jun 16 18:05:45 2008 From: a.badger at gmail.com (Toshio Kuratomi) Date: Mon, 16 Jun 2008 14:05:45 -0400 Subject: Autogenerating rpm requirements from egg requirements In-Reply-To: <1213371594.7122.10.camel@radiator.bos.redhat.com> References: <1213371594.7122.10.camel@radiator.bos.redhat.com> Message-ID: <4856AB79.6020207@gmail.com> David Malcolm wrote: > I ran into a problem with TurboGears packaging in EPEL5 where > requirements in the requires.txt file in the egginfo subdirs were > getting bumped upstream but without corresponding bumps in the rpm > packaging, leading to yum failing to do all the upgrading I needed > (filed as bug 451228 and 451231 so far). > > Has anyone tackled this problem? > > I had a go at trying to autogenerate the RPM metadata, I've attached my > work-in-progress so far to bug 451228: > https://bugzilla.redhat.com/attachment.cgi?id=309225 > > Thoughts? Worth finishing and turning into something in a common > location for rpmbuild? > Definitely worthwhile! This should be brought up on fedora-devel or the rpm development lists so that we can get something merged into our rpm scripts. I think it might be cleaner to generate rpm virtual provides for these. Something like perl's virtual package provides or possibly ruby's since ruby has both "normal" modules and "gem" modules: python-sqlalchemy Provides: pythonegg(SQLAlchemy) = %{version} Provides: python(sqlalchemy) = %{version} python-TurboGears Provides: python(turbogears) = %{version} Provides: pythonegg(TurboGears) = %{version} Requires: pythonegg(SQLAlchemy) >- 0.3.11 We'd want to run these virtual provides by the packaging committee (I'll take it there). And try to get scripts that create them to rpm devel. -Toshio -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: OpenPGP digital signature URL: From stickster at gmail.com Tue Jun 17 13:07:49 2008 From: stickster at gmail.com (Paul W. Frields) Date: Tue, 17 Jun 2008 09:07:49 -0400 Subject: Code swarm of Python development Message-ID: <1213708069.3329.31.camel@victoria> I know this is probably old news, but I saw this on Python-tutor and wanted to pass it on... http://www.vimeo.com/1093745 Maybe it's just the blinkenlights, but I think this is a really cool visualization. -- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ivazqueznet at gmail.com Tue Jun 17 16:53:12 2008 From: ivazqueznet at gmail.com (Ignacio Vazquez-Abrams) Date: Tue, 17 Jun 2008 12:53:12 -0400 Subject: Code swarm of Python development In-Reply-To: <1213708069.3329.31.camel@victoria> References: <1213708069.3329.31.camel@victoria> Message-ID: <1213721593.10118.120.camel@ignacio.lan> On Tue, 2008-06-17 at 09:07 -0400, Paul W. Frields wrote: > I know this is probably old news, but I saw this on Python-tutor and > wanted to pass it on... "18 days ago", so not *that* old. > http://www.vimeo.com/1093745 > > Maybe it's just the blinkenlights, but I think this is a really cool > visualization. An excellent watch, even just to get a feel for the size of the project. -- Ignacio Vazquez-Abrams PLEASE don't CC me; I'm already subscribed -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: