Re: please test the numpy package
On Fri, Feb 6, 2009 at 05:57, Ondrej Certik ond...@certik.cz wrote: 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. Is it easier then add an experimental source to /etc/apt/sources.list and apt-get -t experimental install python-numpy? What is the problem of using experimental? moreover, even because this is an experimental package itself, where by-hand operation are done downloading the tarball, and you request tests before uploading. Experimental is there to be used, and if users have a bad feeling using it, the same is to be there when using unstable too (like the names say). So, my suggestions is: upload to experimental and let your peers (blog posts, ml msgs, morse code ;) ) know where to find it and how to install 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. As smarter people than me already explained, unstalbe is not frozen, but if you upload there lower level packages not targetted to Lenny, the higher level pkgs, that depend on those lowers, will start depends on them (via shlibdeps and so) and neither the highers will be able to transit to testing from unstable but needs t-p-u (that results in a lt less users testing the package for errors). 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
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: 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
Re: please test the numpy package
On Mon, Jan 26, 2009 at 08:15:47AM +0100, Adeodato Simó wrote: * Michael Hanke [Mon, 26 Jan 2009 06:37:13 +0100]: I'd be curious to know which/how many packages in lenny actually build-depend on sphinx. Does anyone know a way to quickly determine that -- it might provide some facts about the situation we are speculating about. % zcat /org/ftp.debian.org/ftp/dists/lenny/*/source/Sources.gz | grep-dctrl -FBuild-Depends python-sphinx -ns package pymvpa python-django Thanks a lot! This is exactly what I suspected. None of those packages has RC-bugs, hence no reason to allow for a transition to testing. Moreover, I promise that pymvpa will not attempt such thing ;-) On sid there are a few more: jinja2 matplotlib mpmath pymvpa python-django python-django-treebeard python-pysqlite2 python-tempita python-webob rpy2 webtest Even for those there is no RC bug (although none of them will be part of lenny anyway). Given these facts, I'd very much appreciate an upload of latest sphinx to unstable -- making complicated experiments with numpy's (and other docs) obsolete. Thanks in advance. 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: please test the numpy package
[Michael Hanke, 2009-01-26] On Mon, Jan 26, 2009 at 08:15:47AM +0100, Adeodato Simó wrote: * Michael Hanke [Mon, 26 Jan 2009 06:37:13 +0100]: I'd be curious to know which/how many packages in lenny actually build-depend on sphinx. Does anyone know a way to quickly determine that -- it might provide some facts about the situation we are speculating about. % zcat /org/ftp.debian.org/ftp/dists/lenny/*/source/Sources.gz | grep-dctrl -FBuild-Depends python-sphinx -ns package pymvpa python-django Thanks a lot! This is exactly what I suspected. None of those packages has RC-bugs, Are you sure? It doesn't have reported RC bugs, yes ;-P 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? -- -=[ Piotr Ożarowski ]=- -=[ http://www.ozarowski.pl ]=- pgpDmhMHGRDKF.pgp Description: PGP signature
Re: please test the numpy package
On Mon, Jan 26, 2009 at 10:47:02AM +0100, Piotr Ożarowski wrote: [Michael Hanke, 2009-01-26] On Mon, Jan 26, 2009 at 08:15:47AM +0100, Adeodato Simó wrote: * Michael Hanke [Mon, 26 Jan 2009 06:37:13 +0100]: I'd be curious to know which/how many packages in lenny actually build-depend on sphinx. Does anyone know a way to quickly determine that -- it might provide some facts about the situation we are speculating about. % zcat /org/ftp.debian.org/ftp/dists/lenny/*/source/Sources.gz | grep-dctrl -FBuild-Depends python-sphinx -ns package pymvpa python-django Thanks a lot! This is exactly what I suspected. None of those packages has RC-bugs, Are you sure? It doesn't have reported RC bugs, yes ;-P ;-) This is of course always implied. 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... http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=502397#15 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
Sphinx (was: Re: please test the numpy package)
[Michael Hanke, 2009-01-26] On Mon, Jan 26, 2009 at 10:47:02AM +0100, Piotr Ożarowski wrote: 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... http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=502397#15 yeah, I forgot to fix it in -1 (I thought it's already fixed in our repo so worked on other issues only), that's one of the reasons I didn't ask to unblock it -- -=[ Piotr Ożarowski ]=- -=[ http://www.ozarowski.pl ]=- pgpd3mD53uKTp.pgp Description: PGP signature
please test the numpy package
Hi, I finally packaged the newest uptream and committed all fixes into our svn repo for numpy. Kumar (or others), do you think you could please test the package? There is a problem with documentation, that it depends on sphinx-0.5, which is currently only in experimental. And also upstream doesn't have it in the tarball. I originally fixed that by adding a new target into debian/rules, that downloaded the upstream tgz, unpacked, eported the doc/ directory from upstream svn and then packaged it again. But since it still doesn't build in pure sid, I rather fixed the build with the current upstream tarball. If all is ok, I will then upload. 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, 2009-01-25] There is a problem with documentation, that it depends on sphinx-0.5, which is currently only in experimental. And also upstream doesn't have it in the tarball. I originally fixed that by adding a new target into debian/rules, that downloaded the upstream tgz, unpacked, eported the doc/ directory from upstream svn and then packaged it again. But since it still doesn't build in pure sid, I rather fixed the build with the current upstream tarball. python-numpy has many reverse dependencies[1] - how about uploading it to experimental for now? This way you'll have Sphinx 0.5.x available. If you really want to upload it to unstable, build the docs using Sphinx from experimental and include them in the upstream source tarball for now (add .ds to upstream version, get-orig-source rule and a README.Debian-source file in the new tarball explaining that you've added the docs and how to regenerate it[2]) [1] see `apt-cache rdepends python-numpy` [2] `./debian/rules get-orig-source`, python-sphinx from experimental installed -- 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 Sun, Jan 25, 2009 at 12:53:05AM -0800, Ondrej Certik wrote: Hi, I finally packaged the newest uptream and committed all fixes into our svn repo for numpy. Kumar (or others), do you think you could please test the package? There is a problem with documentation, that it depends on sphinx-0.5, which is currently only in experimental. And also upstream doesn't have it in the tarball. I originally fixed that by adding a new target into debian/rules, that downloaded the upstream tgz, unpacked, eported the doc/ directory from upstream svn and then packaged it again. But since it still doesn't build in pure sid, I rather fixed the build with the current upstream tarball. Thanks Ondrej, and sorry for not helping out with this earlier. I built the package and tested it, and it seems fine; I ran some of my matplotlib+SciPy examples, and they seemed to run all right. numpy.test() also seemed OK. I guess this can be uploaded to experimental with the new Sphinx documentation, as Piotr says. Thanks again. Kumar -- Kumar Appaiah signature.asc Description: Digital signature
Re: please test the numpy package
Ondrej Certik schrieb: Hi, I finally packaged the newest uptream and committed all fixes into our svn repo for numpy. Kumar (or others), do you think you could please test the package? numpy becomes big. see https://launchpad.net/bugs/309215. In the past the parts depending on external numeric libraries were splitted out into a separate package, but the package structure now makes it difficult to keep this split. Please consider splitting out a python-multiarray (seems to be straightforward, maybe keep it in its own name space) or a python-numpy-core/-base package (unsure where to make the split). There is a problem with documentation, that it depends on sphinx-0.5, which is currently only in experimental. And also upstream doesn't have it in the tarball. I originally fixed that by adding a new target into debian/rules, that downloaded the upstream tgz, unpacked, eported the doc/ directory from upstream svn and then packaged it again. But since it still doesn't build in pure sid, I rather fixed the build with the current upstream tarball. As long as you can fulfill the dependencies with build dependencies all should be ok. However python itself now uses sphinx from the sphinx trunk. very nice :-/ -- 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
Hi, Ondrej Certik wrote: I really want it in unstable. It's because the new scipy won't build without this upload etc. and many people are just waiting for it. It's a legitimate question though, but so far I understood that this is what unstable is for. Otherwise people will have to move from unstable to experimental to get the latest packages. Is this what we want? I prefer it in unstable, but I am open to other opinions. I didn't look at the package, but if I remember right a lot of packages depend on numpy, so I would wait with an upload until Lenny is released definitely, except you're absolutely sure that the new version won't break other packages in unstable and won't mess up the migration path fro unstable to testing for them in case there's something to fix. People who want to or need to use the package in the meantime can use experimental, that's what experimental is for. Cheers, Bernd -- Bernd Zeimetz Debian GNU/Linux Developer GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79 -- 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 wrote: I really want it in unstable. It's because the new scipy won't build without this upload etc. and many people are just waiting for it. It's a legitimate question though, but so far I understood that this is what unstable is for. Otherwise people will have to move from unstable to experimental to get the latest packages. Is this what we want? I prefer it in unstable, but I am open to other opinions. We have packaged GNOME 2.24 in experimental and that has worked fine. I don't think there's a problem with that while Lenny is not released. Cheers, Emilio signature.asc Description: OpenPGP digital signature
Re: unstable semi-frozen (was: please test the numpy package)
[Ondrej Certik, 2009-01-25] I really want it in unstable. I want unstable not to be affected by testing freeze as well, but that's all what I will say in this topic before Lenny's release. For now, if we want to give maintainers, whose packages are depending on our packages, a possibility to test them in unstable, we have to use experimental. Example: Sphinx 0.5 - if I would upload it to unstable, all maintainers that are now complaining that their new packages cannot be build in unstable, would not even notice that Lenny's version is not sufficient to build it (and some of them would probably try to unblock the package for Lenny). That said, I think Lenny should be released with Sphinx 0.5, I just doubt I would be able to convince release managers to unblock it, I even resigned to try to unblock 0.4.3 (there's another problem I would like to be discussed after Lenny here) -- -=[ Piotr Ożarowski ]=- -=[ http://www.ozarowski.pl ]=- pgpDWuDrQdsoB.pgp Description: PGP signature
Re: please test the numpy package
[Michael Hanke, 2009-01-25] To me the question is: Why is sphinx 0.5 in experimental not unstable? This issue does not only affect numpy, as sphinx 0.4.3 has some problems which prevent successful building of docs (e.g. image/figure handling bug) -- and at least this one is solved in 0.5. if you will help me convince release managers to unblock it, I will upload 0.5 to unstable (if Mikhail will not protest). -- -=[ Piotr Ożarowski ]=- -=[ http://www.ozarowski.pl ]=- pgpJ8JereMtfS.pgp Description: PGP signature
Re: please test the numpy package
On Sun, Jan 25, 2009 at 1:47 PM, Piotr Ożarowski pi...@debian.org wrote: [Michael Hanke, 2009-01-25] To me the question is: Why is sphinx 0.5 in experimental not unstable? This issue does not only affect numpy, as sphinx 0.4.3 has some problems which prevent successful building of docs (e.g. image/figure handling bug) -- and at least this one is solved in 0.5. if you will help me convince release managers to unblock it, I will upload 0.5 to unstable (if Mikhail will not protest). So release managers are blocking any uploads of sphinx to unstable? 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, 2009-01-25] On Sun, Jan 25, 2009 at 1:47 PM, Piotr Ożarowski pi...@debian.org wrote: if you will help me convince release managers to unblock it, I will upload 0.5 to unstable (if Mikhail will not protest). So release managers are blocking any uploads of sphinx to unstable? no - *I'm* blocking it. I know it provides new features that testing version doesn't provide and I don't want other maintainers to use them for packages that they intend for testing (but to test them more carefully, they're using unstable, not testing-proposed-updates) -- -=[ Piotr Ożarowski ]=- -=[ http://www.ozarowski.pl ]=- pgpYyGZXMJOzi.pgp Description: PGP signature
Re: unstable semi-frozen (was: please test the numpy package)
On Sun, Jan 25, 2009 at 1:42 PM, Piotr Ożarowski pi...@debian.org wrote: [Ondrej Certik, 2009-01-25] I really want it in unstable. I want unstable not to be affected by testing freeze as well, but that's all what I will say in this topic before Lenny's release. For now, if we want to give maintainers, whose packages are depending on our packages, a possibility to test them in unstable, we have to use experimental. Example: Sphinx 0.5 - if I would upload it to unstable, all maintainers that are now complaining that their new packages cannot be build in unstable, would not even notice that Lenny's version is not sufficient to build it (and some of them would probably try to unblock the package for Lenny). That said, I think Lenny should be released with Sphinx 0.5, I just doubt I would be able to convince release managers to unblock it, I even resigned to try to unblock 0.4.3 (there's another problem I would like to be discussed after Lenny here) I switched from stable to testing and then unstable (many years ago) exactly because I wanted (=needed) new packages and didn't want to compile from source. Basically now the situation is that I will have to start using experimental for most packages I use daily, e.g. sphinx, numpy, scipy and many others... Imho that's not the way. I also need python3.0, which is still not in unstable, so I also compiled it from source. I understand that Debian contains a lot of different people with different needs. But I want some distribution that keeps updating and that's it, or a freeze a month (maybe two) at maximum, not half a year or more. :( Well, but the best I can do about it is to either create my own repository with programs I need, or just upload to experimental, which is better, because it is at least part of Debian in some way. But when people come to experimental, they'll see: Experimental package Warning: This package is from the experimental distribution. That means it is likely unstable or buggy, and it may even cause data loss. Please be sure to consult the changelog and other possible documentation before using it. Obviously this is not true for the packages that we are talking about (sphinx, numpy, scipy). 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 Sun, Jan 25, 2009 at 10:47:06PM +0100, Piotr Ożarowski wrote: [Michael Hanke, 2009-01-25] To me the question is: Why is sphinx 0.5 in experimental not unstable? This issue does not only affect numpy, as sphinx 0.4.3 has some problems which prevent successful building of docs (e.g. image/figure handling bug) -- and at least this one is solved in 0.5. if you will help me convince release managers to unblock it, I will upload 0.5 to unstable (if Mikhail will not protest). I cannot think of any argument in favor of sphinx transitioning from unstable/experimental to testing. At the same time, I have a hard time seeing the need for a full blown unstabletesting transition for a package that aims to become part of lenny (i.e. preventing a direct upload to testing-proposed-updates). I'd be curious to know which/how many packages in lenny actually build-depend on sphinx. Does anyone know a way to quickly determine that -- it might provide some facts about the situation we are speculating about. 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: please test the numpy package
* Michael Hanke [Mon, 26 Jan 2009 06:37:13 +0100]: I'd be curious to know which/how many packages in lenny actually build-depend on sphinx. Does anyone know a way to quickly determine that -- it might provide some facts about the situation we are speculating about. % zcat /org/ftp.debian.org/ftp/dists/lenny/*/source/Sources.gz | grep-dctrl -FBuild-Depends python-sphinx -ns package pymvpa python-django On sid there are a few more: jinja2 matplotlib mpmath pymvpa python-django python-django-treebeard python-pysqlite2 python-tempita python-webob rpy2 webtest -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. -- Brian W. Kernighan -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
