Re: please test the numpy package
hence no reason to allow for a transition to testing. Moreover, I promise that pymvpa will not attempt such thing ;-) What about Sphinx 0.4.3? Does it mean we will not try to unblock it? Sphinx 0.4.3 is the classic example: It causes more trouble than it fixed. For example try building pymvpa's docs with it -- it completely fails since sphinx 0.4.3 is not able to find any figures. It works with lenny's version and 0.5 though... Ok, what is the result of this thread? People need the new numpy and then scipy in Debian, I start getting emails about it. There are the following options: 1) do nothing until Lenny releases and then upload to unstable 2) upload to unstable and remove the sphinx docs 3) upload to experimental 3a) keep the sphinx docs (sphinx is in experimental) 3b) remove the sphinx docs I'd prefer 2). But Bernd discouraged me to do that, unless I am sure the new upload won't break anything. But it's a new upstream release, I think we can be almost sure it will break something -- but imho nothing that couldn't be fixed easily. Ondrej -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: please test the numpy package
On Thu, Feb 5, 2009 at 17:21, Ondrej Certik ond...@certik.cz wrote: 3) upload to experimental 3a) keep the sphinx docs (sphinx is in experimental) I'd recommends this. 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 debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Request for review - Charm 1.9.1
[Christopher Lunsford, 2009-02-05]
- dget http://mentors.debian.net/debian/pool/main/c/charm/charm_1.9.1-1.dsc
* PAPT is in Maintainer field, join PAPT and inject the package into our repo
* python-feedparser is missing in Recommends (Depends?)
* add ${misc:Depends} to Depends
* no need to build depend on python-all, python is enough
* add teams' Vcs-Svn and Vcs-Browser fields
in debian/rules:
* why python$*, $* will always be empty
* you can remove everything from build rule
* binary-arch doesn't need to depend on build and install
* dh_shlibdeps can be removed
* remove *.pyc files in clean rule
* install ljcharm.py into private directory (it's a Python application,
not module); install charm script into the same directory and symlink
it to /usr/bin/charm
--
http://people.debian.org/~piotr/sponsor
pgpnZnUnVKJBE.pgp
Description: PGP signature
Re: Request for review - Charm 1.9.1
On Thu, 05 Feb 2009, Christopher Lunsford wrote: Dear Debian-Python, I am looking for some peer reviews on my package charm, and possibly a mentor. Package name: charm Version : 1.9.1-1 Upstream Author : Lydia Leong evil...@livejournal.com URL : http://ljcharm.sourceforge.net/ License : GPLv2 Section : web It builds these binary packages: charm - LiveJournal and Atom blogging client for the terminal Hi there, IANDD but i'd like to comment a a couple of small things: - On debian/copyright seems like you're missing one year (2009), also you can use © instead of (C). - On debian/control, perhaps you may want to use the same short desc that was used on the ITP (A LiveJournal and Atom API client). Also there's no need to start the paragraph of the long desc with the package's name. Regards, Mauro -- JID: lavaram...@jabber.org | http://lusers.com.ar/ work: ma...@gcoop.com.ar | http://gcoop.com.ar/ 2B82 A38D 1BA5 847A A74D 6C34 6AB7 9ED6 C8FD F9C1 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: please test the numpy package
On Thu, Feb 5, 2009 at 9:05 AM, Sandro Tosi mo...@debian.org wrote: On Thu, Feb 5, 2009 at 17:21, Ondrej Certik ond...@certik.cz wrote: 3) upload to experimental 3a) keep the sphinx docs (sphinx is in experimental) I'd recommends this. Ok. But we are wasting people's time. I just got another email from a Ubuntu user that he will rather consider compiling it for Ubuntu's PPA himself, because he cannot use debian experimental. Of course. So he needs to invest his time in the package, I need to invest my time in the package and the result is that it will not even be in unstable anyway. :( Ondrej -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: please test the numpy package
Ondrej Certik ond...@certik.cz (05/02/2009): Ok. But we are wasting people's time. I just got another email from a Ubuntu user that he will rather consider compiling it for Ubuntu's PPA himself, because he cannot use debian experimental. Of course. So he needs to invest his time in the package, I need to invest my time in the package and the result is that it will not even be in unstable anyway. :( (Following at home, so I might be missing something obvious.) What's the difference between unstable and experimental from that Ubuntu user point of view? If the use of a PPA is what I think it is, he has to fetch the source, be it from unstable or from experimental, throw it into the *builder of his choice, and upload that to the so-called PPA. How much time does he need to dget *builder dput? That's not what I call “invest time in the package”. And not breaking unstable at this point of the release cycle is something that matters, especially for late hotfixes that might be needed (and there still are such needs). Mraw, KiBi. signature.asc Description: Digital signature
Re: please test the numpy package
On Thu, Feb 5, 2009 at 8:41 PM, Cyril Brulebois k...@debian.org wrote: Ondrej Certik ond...@certik.cz (05/02/2009): Ok. But we are wasting people's time. I just got another email from a Ubuntu user that he will rather consider compiling it for Ubuntu's PPA himself, because he cannot use debian experimental. Of course. So he needs to invest his time in the package, I need to invest my time in the package and the result is that it will not even be in unstable anyway. :( (Following at home, so I might be missing something obvious.) What's the difference between unstable and experimental from that Ubuntu user point of view? If the use of a PPA is what I think it is, he has to fetch the source, be it from unstable or from experimental, throw it into the *builder of his choice, and upload that to the so-called PPA. How much time does he need to dget *builder dput? That's not what I call invest time in the package. Ok, you are probably right. So I'll prepare an upload to experimental and other people can just dget and pbuilder it. And not breaking unstable at this point of the release cycle is something that matters, especially for late hotfixes that might be needed (and there still are such needs). Yes. I am unhappy that unstable gets frozen for such a long time, but I understand that with the current setup (e.g. unstable, testing, ..), there is probably no other way. Ondrej -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Frozen unstable (was: please test the numpy package)
Ondrej Certik ond...@certik.cz writes: I am unhappy that unstable gets frozen for such a long time, but I understand that with the current setup (e.g. unstable, testing, ..), there is probably no other way. I'm unhappy about it too, but I don't understand it. Where can I find an explanation for the necessity of freezing ‘unstable’ when preparing to release ‘testing’? -- \ “A child of five could understand this. Fetch me a child of | `\ five.” —Groucho Marx | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Frozen unstable (was: please test the numpy package)
On Fri, Feb 06, 2009 at 05:17:11PM +1100, Ben Finney wrote: Ondrej Certik ond...@certik.cz writes: I am unhappy that unstable gets frozen for such a long time, but I understand that with the current setup (e.g. unstable, testing, ..), there is probably no other way. I'm unhappy about it too, but I don't understand it. Where can I find an explanation for the necessity of freezing ‘unstable’ when preparing to release ‘testing’? I'd be also very interested about this information -- which seems to be common sense -- but I cannot see the necessity as well. Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Frozen unstable (was: please test the numpy package)
Ben Finney ben+deb...@benfinney.id.au (06/02/2009): I'm unhappy about it too, but I don't understand it. Where can I find an explanation for the necessity of freezing ‘unstable’ when preparing to release ‘testing’? For more than verbose explanations, see -devel@ a few weeks ago, starting at 200812160703.00258.russ...@coker.com.au. Mraw, KiBi. signature.asc Description: Digital signature
Re: Frozen unstable (was: please test the numpy package)
On Fri, Feb 06, 2009 at 07:24:47AM +0100, Michael Hanke wrote: On Fri, Feb 06, 2009 at 05:17:11PM +1100, Ben Finney wrote: Ondrej Certik ond...@certik.cz writes: I am unhappy that unstable gets frozen for such a long time, but I understand that with the current setup (e.g. unstable, testing, ..), there is probably no other way. I'm unhappy about it too, but I don't understand it. Where can I find an explanation for the necessity of freezing ‘unstable’ when preparing to release ‘testing’? I'd be also very interested about this information -- which seems to be common sense -- but I cannot see the necessity as well. It's not necessary to freeze unstable when preparing to release testing; this is a significant reason why testing exists as a separate suite. So in fact, unstable is *not* frozen. It is recommended to treat unstable as frozen for libraries, because uploads of such central packages to unstable makes it more onerous to get fixes to other packages depending on those libraries into testing via the normal route; but I'm of the opinion that the pendulum has swung too far the other direction for lenny, with maintainers uploading leaf packages to experimental instead of to unstable for freeze reasons, when the probability of an upload to unstable causing more work for the lenny release is infinitesimal. (I understand that the current discussion is about a case of a package with a lot of reverse-dependencies; so I don't disagree with the conclusion to avoid an upload to unstable for now.) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Frozen unstable (was: please test the numpy package)
On Fri, Feb 06, 2009 at 07:50:36AM +0100, Steve Langasek wrote: On Fri, Feb 06, 2009 at 07:24:47AM +0100, Michael Hanke wrote: On Fri, Feb 06, 2009 at 05:17:11PM +1100, Ben Finney wrote: Ondrej Certik ond...@certik.cz writes: I am unhappy that unstable gets frozen for such a long time, but I understand that with the current setup (e.g. unstable, testing, ..), there is probably no other way. I'm unhappy about it too, but I don't understand it. Where can I find an explanation for the necessity of freezing ‘unstable’ when preparing to release ‘testing’? I'd be also very interested about this information -- which seems to be common sense -- but I cannot see the necessity as well. It's not necessary to freeze unstable when preparing to release testing; this is a significant reason why testing exists as a separate suite. So in fact, unstable is *not* frozen. It is recommended to treat unstable as frozen for libraries, because uploads of such central packages to unstable makes it more onerous to get fixes to other packages depending on those libraries into testing via the normal route; but I'm of the opinion that the pendulum has swung too far the other direction for lenny, with maintainers uploading leaf packages to experimental instead of to unstable for freeze reasons, when the probability of an upload to unstable causing more work for the lenny release is infinitesimal. Thanks a lot for your clarifications. (I understand that the current discussion is about a case of a package with a lot of reverse-dependencies; so I don't disagree with the conclusion to avoid an upload to unstable for now.) Wrt to lenny, we are talking about two reverse dependent packages. Michael -- GPG key: 1024D/3144BE0F Michael Hanke http://apsy.gse.uni-magdeburg.de/hanke ICQ: 48230050 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
