Re: [Python-modules-commits] r6316 - in packages/python-feedvalidator/trunk/debian (watch)
On Sat, Aug 23, 2008 at 9:19 PM, <[EMAIL PROTECTED]> wrote: > Added: packages/python-feedvalidator/trunk/debian/watch > === [...] > +version=3 > +http://code.google.com/p/feedparser/downloads/list > http://feedparser.googlecode.com/files/feedparser-(\d.*)\.zip Piotr, I think you mixed up feedvalidator and feedparser here. They are two different packages. Unfortunately feedvalidator download list[1] is empty, so the watch file would be useless anyway. [1]http://code.google.com/p/feedvalidator/downloads/list -- --- Carlos Galisteo PGP_key::http://k-rolus.net/~cgalisteo/cgalisteo.gpg Key_Fingerprint::F888 6FBA 9145 B5A2 C187 66D6 5B8C 027A 69AD BE65 --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dependency questions
Le lundi 25 août 2008 à 00:03 +0200, Eike Nicklas a écrit : > c) Depends: python (>=2.4), python-elementtree > (does python2.5 provide python-elementtree?) It does not, which is a bug, since this option should be the correct one. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: r6347 - in packages/python-recaptcha/trunk/debian (control)
Le lundi 25 août 2008 à 21:13 +0200, Vincent Bernat a écrit :
> OoO Pendant le journal télévisé du lundi 25 août 2008, vers 20:42, je
> disais:
>
> > import sys,new,os; p = os.path.join(sys._getframe(1).f_locals['sitedir'],
> > *('recaptcha',)); ie = os.path.exists(os.path.join(p,'__init__.py')); m =
> > not ie and sys.modules.setdefault('recaptcha',new.module('recaptcha')); mp
> > = (m or []) and m.__dict__.setdefault('__path__',[]); (p not in mp) and
> > mp.append(p)
> > /var/lib/python-support/python2.5/import sys,new,os; p =
> > os.path.join(sys._getframe(1).f_locals['sitedir'], *('recaptcha',)); ie =
> > os.path.exists(os.path.join(p,'__init__.py')); m = not ie and
> > sys.modules.setdefault('recaptcha',new.module('recaptcha')); mp = (m or [])
> > and m.__dict__.setdefault('__path__',[]); (p not in mp) and mp.append(p)
This one should be nominated for the OMGWTF python package of the day.
> > This snippet can be found in recaptcha_client-1.0.2-py2.5-nspkg.pth that
> > is generated at compile time. I don't know why this is
> > generated. Moreover, this file seems a bit useless. What is the cleanest
> > way to get rid of it and all the egg stuff?
>
> I am not sure what was the precise action that fixed this thing, but my
> last commit was able to get rid of the problem. If someone has some
> explanations, I will welcome them.
>
> BTW, while searching a bit about this problem, I have found this bug:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=475440
>
> Is it a bug in python-support?
This looks like just another design flaw in setuptools.
Please, think of the kittens. Don’t use setuptools.
--
.''`.
: :' : We are debian.org. Lower your prices, surrender your code.
`. `' We will add your hardware and software distinctiveness to
`-our own. Resistance is futile.
signature.asc
Description: Ceci est une partie de message numériquement signée
Django 1.0 - Possibility of a freeze exception?
Hello, the Django project will release their version 1.0 in the beginning of next week. I know that usually no new upstream versions are allowed into Lenny at this point. I wonder though if Django could be an exception. 1. Django has a significant Debian user-base (638 pop contest installations when I last checked). 2. It is unlikely that version 0.96 will receive ongoing security support from upstream for long after 1.0. 3. Due to changes in the admin and form applications, Django 1.0 will be backwards incompatible with 0.96 and the old stable version's use in Debian might be questionable. 4. All packages that use Django are under our control (currently only in experimental). Let me know what you think and how to best approach the release managers with this. Most importantly, you can help this effort by testing the python-django_1.0~beta1-1 package that is currently in experimental. I am already using it in my own work. Also let me know if any of you are planning on going to the Django release party in Mountain View next week. All my best, David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Django 1.0 - Possibility of a freeze exception?
On Wed, Aug 27, 2008 at 3:34 PM, David Spreen <[EMAIL PROTECTED]> wrote: > Hello, > > the Django project will release their version 1.0 in the beginning of > next week. I know that usually no new upstream versions are allowed into > Lenny at this point. I wonder though if Django could be an exception. > > 1. Django has a significant Debian user-base (638 pop contest > installations when I last checked). > > 2. It is unlikely that version 0.96 will receive ongoing security > support from upstream for long after 1.0. > > 3. Due to changes in the admin and form applications, Django 1.0 will be > backwards incompatible with 0.96 and the old stable version's use in > Debian might be questionable. > > 4. All packages that use Django are under our control (currently only in > experimental). > > Let me know what you think and how to best approach the release managers > with this. > > Most importantly, you can help this effort by testing the > python-django_1.0~beta1-1 package that is currently in experimental. I > am already using it in my own work. I use Django from experimental regularly and it works just fine. I am +1. But I cannot help, too busy. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Django 1.0 - Possibility of a freeze exception?
On Wed, Aug 27, 2008 at 04:05:18PM +0200, Ondrej Certik wrote: > On Wed, Aug 27, 2008 at 3:34 PM, David Spreen <[EMAIL PROTECTED]> wrote: > > Hello, > > > > the Django project will release their version 1.0 in the beginning of > > next week. I know that usually no new upstream versions are allowed into > > Lenny at this point. I wonder though if Django could be an exception. > > > > 1. Django has a significant Debian user-base (638 pop contest > > installations when I last checked). > > > > 2. It is unlikely that version 0.96 will receive ongoing security > > support from upstream for long after 1.0. > > > > 3. Due to changes in the admin and form applications, Django 1.0 will be > > backwards incompatible with 0.96 and the old stable version's use in > > Debian might be questionable. > > > > 4. All packages that use Django are under our control (currently only in > > experimental). > > > > Let me know what you think and how to best approach the release managers > > with this. > > > > Most importantly, you can help this effort by testing the > > python-django_1.0~beta1-1 package that is currently in experimental. I > > am already using it in my own work. > > I use Django from experimental regularly and it works just fine. > > I am +1. But I cannot help, too busy. I don't have any ability to vote officially, but I am strongly in support of this, and would do anything possible to help make it happen. (I have some Python packaging experience, and have been building my own SVN Django using the experimental packaging for several months.) Regards, -- Christopher Schmidt MetaCarta -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dependency questions
On Wed, 27 Aug 2008 at 13:07:19 +0200, Josselin Mouette wrote: > Le lundi 25 août 2008 à 00:03 +0200, Eike Nicklas a écrit : > > c) Depends: python (>=2.4), python-elementtree > > (does python2.5 provide python-elementtree?) > > It does not, which is a bug, since this option should be the correct > one. I don't think that's actually correct, because Python 2.5's version of ElementTree is xml.etree.ElementTree, but the standalone version is ElementTree.ElementTree or something. So, packages that do the usual try:/except ImportError: dance (1) should depend on python (>= 2.5) | python-elementtree, but packages that unconditionally import ElementTree (2) should depend on python-elementtree only, and packages that unconditionally import xml.etree (3) should depend on python (>= 2.5). In practice, the maintainers of packages in category (2) should probably patch them to do the try/except stuff, though. python (>= 2.5) should not provide python-elementtree, because python-elementtree makes ElementTree available for all Python versions, but python (>= 2.5) only makes xml.etree.ElementTree available, and only for Pythons >= 2.5. smcv -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dependency questions
Le mercredi 27 août 2008 à 14:57 +0100, Simon McVittie a écrit : > On Wed, 27 Aug 2008 at 13:07:19 +0200, Josselin Mouette wrote: > > It does not, which is a bug, since this option should be the correct > > one. > > I don't think that's actually correct, because Python 2.5's version of > ElementTree is xml.etree.ElementTree, but the standalone version is > ElementTree.ElementTree or something. Ah, right, I forgot elementtree is special. The provides is missing for ctypes and wsgiref, for which the module name remains the same. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: r6347 - in packages/python-recaptcha/trunk/debian (control)
OoO Peu avant le début de l'après-midi du mercredi 27 août 2008, vers
13:12, Josselin Mouette <[EMAIL PROTECTED]> disait :
>> > import sys,new,os; p = os.path.join(sys._getframe(1).f_locals['sitedir'],
>> > *('recaptcha',)); ie = os.path.exists(os.path.join(p,'__init__.py')); m =
>> > not ie and sys.modules.setdefault('recaptcha',new.module('recaptcha')); mp
>> > = (m or []) and m.__dict__.setdefault('__path__',[]); (p not in mp) and
>> > mp.append(p)
>> > /var/lib/python-support/python2.5/import sys,new,os; p =
>> > os.path.join(sys._getframe(1).f_locals['sitedir'], *('recaptcha',)); ie =
>> > os.path.exists(os.path.join(p,'__init__.py')); m = not ie and
>> > sys.modules.setdefault('recaptcha',new.module('recaptcha')); mp = (m or
>> > []) and m.__dict__.setdefault('__path__',[]); (p not in mp) and
>> > mp.append(p)
> This one should be nominated for the OMGWTF python package of the day.
It is generated by setuptools in fact. And a missing new line render it
unusable.
>> > This snippet can be found in recaptcha_client-1.0.2-py2.5-nspkg.pth that
>> > is generated at compile time. I don't know why this is
>> > generated. Moreover, this file seems a bit useless. What is the cleanest
>> > way to get rid of it and all the egg stuff?
>>
>> I am not sure what was the precise action that fixed this thing, but my
>> last commit was able to get rid of the problem. If someone has some
>> explanations, I will welcome them.
>>
>> BTW, while searching a bit about this problem, I have found this bug:
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=475440
>>
>> Is it a bug in python-support?
> This looks like just another design flaw in setuptools.
> Please, think of the kittens. Don’t use setuptools.
Well, people use setuptoolsand it does not work with
python-support. What should we do? Move the egg by hand in a more
correct location? Or maybe python-support could put it by itself in a
correct location?
--
BOFH excuse #368:
Failure to adjust for daylight savings time.
pgpqZXXyiw0Nc.pgp
Description: PGP signature
Re: Django 1.0 - Possibility of a freeze exception?
Hi David, I'm sorry, but I don't use django, but... On Wed, Aug 27, 2008 at 15:34, David Spreen <[EMAIL PROTECTED]> wrote: > Let me know what you think and how to best approach the release managers > with this. ...I think that you have to simply explain to release team the situation, in the more polite way possible (they are really stressed these days) strongly motivating your request for 1.0 for Lenny. Try to do it asap, just to avoid rushing to have a package ready, ask RT and have a "no" as reply. Cheers, -- Sandro Tosi (aka morph, Morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: r6347 - in packages/python-recaptcha/trunk/debian (control)
Le mercredi 27 août 2008 à 19:21 +0200, Vincent Bernat a écrit :
> OoO Peu avant le début de l'après-midi du mercredi 27 août 2008, vers
> 13:12, Josselin Mouette <[EMAIL PROTECTED]> disait :
>
> >> > import sys,new,os; p =
> >> > os.path.join(sys._getframe(1).f_locals['sitedir'], *('recaptcha',)); ie
> >> > = os.path.exists(os.path.join(p,'__init__.py')); m = not ie and
> >> > sys.modules.setdefault('recaptcha',new.module('recaptcha')); mp = (m or
> >> > []) and m.__dict__.setdefault('__path__',[]); (p not in mp) and
> >> > mp.append(p)
> >> > /var/lib/python-support/python2.5/import sys,new,os; p =
> >> > os.path.join(sys._getframe(1).f_locals['sitedir'], *('recaptcha',)); ie
> >> > = os.path.exists(os.path.join(p,'__init__.py')); m = not ie and
> >> > sys.modules.setdefault('recaptcha',new.module('recaptcha')); mp = (m or
> >> > []) and m.__dict__.setdefault('__path__',[]); (p not in mp) and
> >> > mp.append(p)
>
> > This one should be nominated for the OMGWTF python package of the day.
>
> It is generated by setuptools in fact. And a missing new line render it
> unusable.
Could you please test the python-support package at
http://malsain.org/~joss/debian/ to see whether it handles this case
correctly?
BTW, it is a VERY bad idea to do something like this: this way, all
python scripts will execute this code at startup, which can have a
performance impact or, even worse, render python unusable on the system.
> >> BTW, while searching a bit about this problem, I have found this bug:
> >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=475440
> >>
> >> Is it a bug in python-support?
>
> > This looks like just another design flaw in setuptools.
>
> > Please, think of the kittens. Don’t use setuptools.
>
> Well, people use setuptoolsand it does not work with
> python-support. What should we do? Move the egg by hand in a more
> correct location? Or maybe python-support could put it by itself in a
> correct location?
The egg IS already installed in a correct location: there is a symlink
in /var/lib/python-support/python2.x which is in sys.path. From my
understanding of http://bugs.python.org/setuptools/issue17, the problem
is in easy_install, but most contributors to this bug did not even check
that the symlink was here.
Cheers,
--
.''`.
: :' : We are debian.org. Lower your prices, surrender your code.
`. `' We will add your hardware and software distinctiveness to
`-our own. Resistance is futile.
signature.asc
Description: Ceci est une partie de message numériquement signée
Re: Django 1.0 - Possibility of a freeze exception?
Hi, On Wed, Aug 27, 2008 at 3:34 PM, David Spreen <[EMAIL PROTECTED]> wrote: > the Django project will release their version 1.0 in the beginning of > next week. Hope so! > 2. It is unlikely that version 0.96 will receive ongoing security > support from upstream for long after 1.0. I think it's the strongest argument for the Release Team, having a package that is really likely to have no support upstream (it's been stated that the 0.96 will be abandoned shortly if my memory serves well (?)) is not nice. And Django does not affect any other packages in lenny that I'm aware of. So, lots of emphasys could be put on this point! > 3. Due to changes in the admin and form applications, Django 1.0 will be > backwards incompatible with 0.96 and the old stable version's use in > Debian might be questionable. That's the second super point, nobody will want 0.96 to work over it when it's incompatible in so many ways with 1.0 (to not say in almost any reasonable use case, just look at the BackwardsIncompatibleChanges wiki page from Django). > Let me know what you think and how to best approach the release managers > with this. As said: I'd really like to see that happen. The maintenance and the "nobody will use it in 0.96" are to very good points for the release team, just be polite with them (and promise some beers if needed, hehe ;) > Most importantly, you can help this effort by testing the > python-django_1.0~beta1-1 package that is currently in experimental. I > am already using it in my own work. Do you plan to add a python-django-doc now that beta2 included the docs-refactor stuff? (a "make html" inside the docs/ directory will make you happy!) > Also let me know if any of you are planning on going to the Django > release party in Mountain View next week. Not me, too far (for those dates at least). Have a nice party :) Hope you convince RT. Regards, Marc -- http://www.marcfargas.com - will be finished someday. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Django 1.0 - Possibility of a freeze exception?
Le mercredi 27 août 2008 à 23:33 +0200, Marc Fargas a écrit : > > 3. Due to changes in the admin and form applications, Django 1.0 will be > > backwards incompatible with 0.96 and the old stable version's use in > > Debian might be questionable. > > That's the second super point, nobody will want 0.96 to work over it > when it's incompatible in so many ways with 1.0 (to not say in almost > any reasonable use case, just look at the BackwardsIncompatibleChanges > wiki page from Django). Another important thing to consider is that most Django applications in the wild already require at least 0.97 even though it wasn’t released. Shipping 0.96 would therefore be mostly useless. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Django 1.0 - Possibility of a freeze exception?
On Wed, Aug 27, 2008 at 11:38 PM, Josselin Mouette <[EMAIL PROTECTED]> wrote: > Le mercredi 27 août 2008 à 23:33 +0200, Marc Fargas a écrit : >> > 3. Due to changes in the admin and form applications, Django 1.0 will be >> > backwards incompatible with 0.96 and the old stable version's use in >> > Debian might be questionable. >> >> That's the second super point, nobody will want 0.96 to work over it >> when it's incompatible in so many ways with 1.0 (to not say in almost >> any reasonable use case, just look at the BackwardsIncompatibleChanges >> wiki page from Django). > > Another important thing to consider is that most Django applications in > the wild already require at least 0.97 even though it wasn't released. > Shipping 0.96 would therefore be mostly useless. This is I think the most strongest point. I need the package from experimental anyway, the one in unstable is useless for most of applications. Ondrej
Re: Django 1.0 - Possibility of a freeze exception?
Hello, Marc Fargas wrote: > Hi, > > On Wed, Aug 27, 2008 at 3:34 PM, David Spreen <[EMAIL PROTECTED]> wrote: > >> the Django project will release their version 1.0 in the beginning of >> next week. >> > > Hope so! > > > I think it's the strongest argument for the Release Team, having a > package that is really likely to have no support upstream (it's been > stated that the 0.96 will be abandoned shortly if my memory serves > well (?)) is not nice. And Django does not affect any other packages > in lenny that I'm aware of. So, lots of emphasys could be put on this > point! > > Actually, I just confirmed with the devel mailinglist that in the past they provide security support for the last two stable releases. It is therefore not such a strong argument. > That's the second super point, nobody will want 0.96 to work over it > when it's incompatible in so many ways with 1.0 (to not say in almost > any reasonable use case, just look at the BackwardsIncompatibleChanges > wiki page from Django). > Agreed. > Do you plan to add a python-django-doc now that beta2 included the > docs-refactor stuff? (a "make html" inside the docs/ directory will > make you happy!) > Already done on my hard disk. Will upload to svn once I get off work. best, David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
