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 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
Re: Frozen unstable
Steve Langasek writes: > It's not necessary to freeze unstable when preparing to release > testing; this is a significant reason why testing exists as a > separate suite. That's exactly what I thought; I'm glad to see a member of the release team reassert it. > So in fact, unstable is *not* frozen. It is recommended to treat > unstable as frozen for libraries [… 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. Okay. It does, as has been said, seem to be common wisdom currently to treat ‘unstable’ as effectively verboten until the release of ‘lenny’; thank you for at least explaining the likely origin of that extreme. Cyril Brulebois writes: > For more than verbose explanations, see -devel@ a few weeks ago, > starting at <200812160703.00258.russ...@coker.com.au>. Thanks, but I was looking not for long discussions but for concise statements of the official position. I'm grateful to have received it so promptly. -- \ “What you have become is the price you paid to get what you | `\ used to want.” —Mignon McLaughlin | _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 07:24:47AM +0100, Michael Hanke wrote: > On Fri, Feb 06, 2009 at 05:17:11PM +1100, Ben Finney wrote: > > Ondrej Certik 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)
Ben Finney (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 05:17:11PM +1100, Ben Finney wrote: > Ondrej Certik 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
Frozen unstable (was: please test the numpy package)
Ondrej Certik 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: please test the numpy package
On Thu, Feb 5, 2009 at 8:41 PM, Cyril Brulebois wrote: > Ondrej Certik (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
Re: please test the numpy package
Ondrej Certik (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 9:05 AM, Sandro Tosi wrote: > On Thu, Feb 5, 2009 at 17:21, Ondrej Certik 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: 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
> 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: 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: please test the numpy package
On Thu, Feb 5, 2009 at 17:21, Ondrej Certik 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: 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
Request for review - Charm 1.9.1
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 URL : http://ljcharm.sourceforge.net/ License : GPLv2 Section : web It builds these binary packages: charm - LiveJournal and Atom blogging client for the terminal The package appears to be lintian clean. The upload would fix these bugs: 502231 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/c/charm - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/c/charm/charm_1.9.1-1.dsc I would appreciate it very much if someone reviewed this package for me. Kind regards Christopher Lunsford -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Bug#504080: [RFR] Courier-Pythonfilter
On Wednesday 28 January 2009 23:16, Piotr Ożarowski wrote:
> [please CC me or debian-pyt...@l.d.o as I didn't subscribe this bug]
>
> * 1.6 is mentioned in bug #504080, is .dsc available somewhere?
> * it's "Architecture: all" package, not "any", or did I miss
> something? * please merge patches 01-31 into one file
> * s/Debian packaging is (C)/Debian packaging is ©
> * add "${misc:Depends}" to Depends
> * configure and configure-stamp rules are not needed (probably also
> build-stamp)
> * consider using "include /usr/share/dpatch/dpatch.make" in
> debian/rules (it will provide "patch" and "unpatch" rules)
> * dh_installexamples, dh_strip and dh_shlibdeps are not needed
> * shouldn't you generate siteid using something like uuidgen in
> postinst? README mentions it...
> * Please bump python-support's required build version to >= 0.6
> * I don't know much about packaging stuff for Courier, but how about
> providing python-courier package with courier module (and probably
> python-pythonfilter package with filters or maybe moving filters
> into private directory)
Piotr, I will make 1.6 available on mentors.debian.net within the week
and I will definitely take a deeper look at all the above suggestions
you've made.
Thanks,
Frederik Dannemare
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
