Re: Developer workflow and DVCS (was: Leaving DPMT?)
On Sun, Mar 1, 2009 at 4:14 PM, Tristan Seligmann mithra...@mithrandi.net wrote: * David Cournapeau courn...@gmail.com [2009-02-28 20:22:46 +0900]: I have never used stacked branches, but are you sure you can only branch the repository data related to a subset of the working tree only ? My understanding is that bzr stacked branches are useful to avoid downloading the whole history, but that you still need to get the whole project. I think it would be very difficult to support the usual features of DVCS without it ? If you don't want the project history, then you can use lightweight checkouts, which are essentially equivalent to SVN checkouts (you get a local working copy, but no local branch or repository). Ah, so you basically only get the local working copy, but *no* bzr repository, right? Well, with git, you can get this over the web interface, so we may write a simple (Python:) script to download this for you from the commandline. Maybe someone did this already. Ondrej -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Developer workflow and DVCS (was: Leaving DPMT?)
On Mon, Mar 2, 2009 at 11:27 AM, Tristan Seligmann mithra...@mithrandi.net wrote: * Ondrej Certik ond...@certik.cz [2009-03-02 11:07:25 -0500]: If you don't want the project history, then you can use lightweight checkouts, which are essentially equivalent to SVN checkouts (you get a local working copy, but no local branch or repository). Ah, so you basically only get the local working copy, but *no* bzr repository, right? Well, with git, you can get this over the web interface, so we may write a simple (Python:) script to download this for you from the commandline. Maybe someone did this already. Does fetching the tarball(?) from the git web interface give you something that you can commit changes with? You can still commit / No, I think you can't. update / etc. in a bzr lightweight checkout, like you can with an SVN working copy. Ah, I didn't know this. So that's indeed better. Even though as I have shown in the thread about numpy update, the history is not big, the main problem is with the tarball (e.g. including it in the repo, vs. downloading it separately). Ondrej -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Piotrek's new preferred helper tool - (unfair) decision
On Mon, Mar 2, 2009 at 4:17 PM, Piotr Ożarowski pi...@debian.org wrote: [Piotr Ożarowski, 2009-02-18] [...] it's time however to decide which one will be my winner - I'll decide that in next weeks (maybe months, but it will happen sooner than later Since nobody is interested in having the tools binary compatible[1] (and, to be honest, I cared about opinion of two guys only: Matthias voted no by not agreeing to use /usr/lib/pyshared and Joss expressed his disapproval on #debian-python) - I choose python-support to be my preferred tool (no, not the winner, I only wanted to provoke you both to make a consensus and thus not let me decide about anything). I'm not saying one of them is better than the other (although I was more a pycentral guy, Ana knows something about it[2]) - I'm saying I have more influence on how the tool looks like (f.e. via reporting bugs) and changes are more predictable in pysupport. You can now prove me how wrong decision I made but... I don't care ;-P I propose to file bugs against python-support instead (Joss will talk you to death if it's not really a bug ;-) I fully agree. Let's just concentrate all our effort on one system, so I am glad you finally made a decision. I'll convert all my packages to python-support soon. Ondrej -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bzr lightweight checkout, bzr shallow branches, and git
Hi Adeodato, On Mon, Mar 2, 2009 at 11:37 AM, Adeodato Simó d...@net.com.org.es wrote: * Ondrej Certik [Mon, 02 Mar 2009 11:07:25 -0500]: I have never used stacked branches, but are you sure you can only branch the repository data related to a subset of the working tree only ? My understanding is that bzr stacked branches are useful to avoid downloading the whole history, but that you still need to get the whole project. I think it would be very difficult to support the usual features of DVCS without it ? If you don't want the project history, then you can use lightweight checkouts, which are essentially equivalent to SVN checkouts (you get a local working copy, but no local branch or repository). Ah, so you basically only get the local working copy, but *no* bzr repository, right? Well, with git, you can get this over the web interface, so we may write a simple (Python:) script to download this for you from the commandline. Maybe someone did this already. No, that interpretation is not correct. I'm going to explain the three involved concepts, in hopes that it will be useful for this discussion, or for future instances of this discussion. I'll (concisely) explain Bazaar's lightweight checkouts, Bazaar's stacked branches, and what Git has to offer in this area. Thanks a lot for taking time to write this, now it's clear to me that git is inferior in this particular point to bazaar, I agree with you. You made very good points, thanks for that. On Mon, Mar 2, 2009 at 3:44 PM, Steve Langasek vor...@debian.org wrote: My rebuttal is that if git is technical superior to bazaar because bazaar has a mechanism to create repositories with only partial history, then No, I think Adeodato addressed this in his follow up email: I'm not claiming that Git's design is overall inferior than Bazaar's. In fact, I quite much like it. I'm just saying that Bazaar can provide full-fledged branches that don't physically contain all history data, and Git cannot, and in my view that's a disadvantage and an inferiority *in that particular point*. bazaar is technically superior to git because git has rebasing as a first-class feature. Just to make sure -- you meant it as a joke, right? Sometimes I am a little unsure over emails. :) On Mon, Mar 2, 2009 at 4:20 PM, Cyril Brulebois k...@debian.org wrote: Steve Langasek vor...@debian.org (02/03/2009): My rebuttal is that if git is technical superior to bazaar because bazaar has a mechanism to create repositories with only partial history, then bazaar is technically superior to git because git has rebasing as a first-class feature. Oh my HEAD, it hurts. I didn't get this reply at all, besides HEAD being the git's top commit. I think my humor senses are sleeping today, sorry guys, I hope to improve tomorrow. :) Anyway, good discussion, please keep going, I find it very useful. Ondrej -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Leaving DPMT?
On Fri, Feb 27, 2009 at 7:33 AM, Stephan Peijnik deb...@sp.or.at wrote: First of all, I do not consider myself to be a 'major' contributor to the DPMT either. On Fri, 2009-02-27 at 15:07 +0100, Sandro Tosi wrote: No, what I said was: - I see no need to move to git as a team - I can't afford to download all the git repos for packages I want to modify once I can to some agree with Sandro here. I'm not a big fan of svn, but for the DPMT repository svn looks like the right choice to me. The big benefit of using svn is that each and every directory in a svn repository can be checked out forming a stand-alone local copy. And this exactly is not possible with other recently more-popular VCS such as Mercurial and git. Well, it would be possible to create a separate repository for each and every package, but as Piotr already put it, it would make certain tasks harder to achieve. Just think of the X-Svn-* to Svn-* field change recently. With separate repositories for each package one would first have to look up every repository URL, check out all of them, then apply the change to all of them and push all of them back. With svn it is as simple as checking out one directory (ie. packages/), apply the change and then do a single commit, which will push back all changes. Now the svn way seems a lot less complex to me, and that's why I would prefer staying with svn. However, if someone can point out that a 'better' vcs that has this 'every-directory-can-be-a-repository' behaviour, please do so and I would be happy to give that a try. Oh, last but not least, there's the old saying 'never change a running system', which one should really keep in mind when discussing such changes. We discussed that in the pust, just find the discussion on this list before. I apologize for opening it again. Ondrej -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Leaving DPMT?
On Fri, Feb 27, 2009 at 4:48 PM, Ben Finney ben+deb...@benfinney.id.au wrote: Sandro Tosi mo...@debian.org writes: On Sat, Feb 28, 2009 at 01:11, Ben Finney ben+deb...@benfinney.id.au wrote: I see this discussion focussing exclusively on Subversion versus Git; I wish with this message to point out that not all DVCSen are necessarily like Git. WTF?! As Ondrej said just some hours ago: You seem quite fed-up Sandro. :) I didn't mean it to start the svn-git discussion again when I mentioned you. Just to check if you already fixed your internet connection or not yet. :) I didn't see that message when I wrote mine. On Fri, Feb 27, 2009 at 16:41, Ondrej Certik ond...@certik.cz wrote: We discussed that in the pust, just find the discussion on this list before. I apologize for opening it again. I don't know what thread that is. Use the right thread to discuss this. Certainly, if someone can point me to the right thread. http://www.google.com/search?hl=enq=debian+python+git+svnbtnG=Google+Searchaq=foq= it's the 4th link: http://www.mail-archive.com/debian-python@lists.debian.org/msg04997.html Ondrej -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Leaving DPMT?
On Thu, Feb 26, 2009 at 12:14 PM, Piotr Ożarowski pi...@debian.org wrote:
Hi,
[Cyril Brulebois, 2009-02-26]
That's why I'm planning to move python-{networkx,pygraphviz} out of
DPMT's svn and move them to collab-maint's set of git repositories.
Now, question: should I keep DPMT in Uploaders, or drop it?
please remove it, one exception will lead to other requests and I just
love grep -r :-P
There's no need to leave DPMT, though, maybe you'll come back later
(f.e. if we move to some other VCS)
Currently I think Sandro is the last major contributor for DPMT who
wants to stay in svn.
Cyril, I'll be watching how you maintain the
python-{networkx,pygraphviz} in git and probably move my packages too
if I like it!
Ondrej
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
new numpy tests fail
Hi, so the new numpy is in Debian, finally... But one test fails: In [1]: import numpy In [2]: numpy.test() Running unit tests for numpy /var/lib/python-support/python2.5/nose/plugins/manager.py:386: UserWarning: Module nose was already imported from /var/lib/python-support/python2.5/nose/__init__.py, but /var/lib/python-support/python2.5 is being added to sys.path import pkg_resources NumPy version 1.2.1 NumPy is installed in /usr/lib/python2.5/site-packages/numpy Python version 2.5.4 (r254:67916, Feb 17 2009, 20:16:45) [GCC 4.3.3] nose version 0.10.4 ..FK.. == FAIL: test_umath.TestComplexFunctions.test_against_cmath -- Traceback (most recent call last): File /var/lib/python-support/python2.5/nose/case.py, line 182, in runTest self.test(*self.arg) File /usr/lib/python2.5/site-packages/numpy/core/tests/test_umath.py, line 268, in test_against_cmath assert abs(a - b) atol, %s %s: %s; cmath: %s%(fname,p,a,b) AssertionError: arcsinh -2j: (-1.31695789692-1.57079632679j); cmath: (1.31695789692-1.57079632679j) -- Ran 1726 tests in 9.747s FAILED (KNOWNFAIL=1, failures=1) Out[2]: nose.result.TextTestResult run=1726 errors=0 failures=1 If anyone (David:) has time to look into it, it'd be great. Ondrej -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
numpy 1.2.1 uploaded to unstable
Hi, I finally found time to upload the numpy 1.2.1 to Debian unstable (currently it's in incoming: http://incoming.debian.org/). The package is lintian clean, but there is one test that failed for me in chroot. I'll wait until it gets to mirrors and then try it on my laptop and report a bug (I uploaded from a ubuntu machine, but of course I compiled it in pbuilder with sid and tested in chroot). Ondrej -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Python related changes for unstable/squeeze
On Tue, Feb 17, 2009 at 6:44 AM, Josselin Mouette j...@debian.org wrote: Le mardi 17 février 2009 à 15:03 +0100, Bernd Zeimetz a écrit : - Can you guys please finally sit down and agree on one solution for handling python modules? I still think that having two (slightly different) ways of doing this task is not the way to go. I really do not see technical reason for this situation. I have no preference at all and I'm actually using both things in my packages, but I really do not think it is way to go. And it would be great if we can have single tool, which gets more testing and will have less bugs than current concurrent solutions. Ack. Please guys, get together, discuss it in a *sane* way (why do I fear that's not possible...) and merge both tools or drop both of them and do something else useful - together. You really can't say I'm not trying to discuss. But it takes at least two persons to discuss, and Matthias has been ignoring all technical discussions about Python packaging for years. This is not a technical problem. The technical divergences can be solved if consensus is reached about them or if a decision body (TC or GR) forces them. This is purely a person problem: Matthias is clearly not willing to maintain python-central correctly nor to make it evolve according to the needs of developers. These are two very good reasons to keep maintaining an alternative. Unfortunately from both of you I only met Matthias in person (in Prague at the Ubuntu Developer Summit), but what I understood is that there are some technical reasons why python-central is better. But those should be resolved by discussing it on the list, coming to a consensus and then fixing it by merging the packages or starting from scratch. Josselin, it's true that if you were discussing with me in the same tone as you are with Matthias, it will not make me very happy (as many people have pointed out), but I appreciate that you discuss and reply to criticisms and that's the most important. So Matthias, please, try to come to this list and get this resolved once and for all. Failing to discuss and pushing things your way is bad. Ondrej -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Python related changes for unstable/squeeze
On Tue, Feb 17, 2009 at 10:34 AM, Josselin Mouette j...@debian.org wrote: Le mardi 17 février 2009 à 10:09 -0800, Ondrej Certik a écrit : Unfortunately from both of you I only met Matthias in person (in Prague at the Ubuntu Developer Summit), but what I understood is that there are some technical reasons why python-central is better. I'd be happy to hear these reasons; I'm always eager to improve python-support when there is room to. Currently I know one reason why you could consider python-central better: this is because it installs files at the same place the upstream packages do. This avoids breaking some (bad) packages' expectations. I have two remarks about this: * The python-support README has documented for long how to work around this problem if you encounter it (remember it concerns a handful of packages). * If python-support was the only tool to write files to /usr/lib/pythonX.Y/site-packages, there would be no problem with using this directory. However there are packages using python-central and packages shipping files directly there, so it is simply not possible without losing the advantages of python-support (like, not introducing 50 RC bugs every time something is changed). Besides, I could show you several reasons why python-support is superior, and at least one why python-central is broken. I forgot already what those reasons were, Matthias told me in Prague and they seemed reasonable to me. In fact, we were having a similar flame discussion about python-central and python-support just before the summit on this list and the result of which was (to me, as a bystander) that python-support is clearly superior, so I asked Matthias about it, and he provided some good arguments for python-central. But these arguments should be put on the list and things should get discussed and fixed. Anyway, I think now it's Matthias' turn to come forward and also do a few steps to get this discussed and eventually fixed. Ondrej -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Python related changes for unstable/squeeze
Hi Matthias, thanks for all the work you do. I have one question: - 3.0/3.1: I do not plan to upload 3.0 to unstable or experimental, but will prepare 3.1 packages for experimental and upload those to unstable with the final release or a late release candidate. The 3.1 release is planned for April 2009. It would really help if Debian had python3.0, becuase it would help me, as upstream, to port my software. Currently I have to compile python3.0 from the ubuntu source package. If ubuntu can have it, why not Debian? Ondrej -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Python related changes for unstable/squeeze
On Mon, Feb 16, 2009 at 2:15 PM, Matthias Klose d...@debian.org wrote: Ondrej Certik schrieb: Hi Matthias, thanks for all the work you do. I have one question: - 3.0/3.1: I do not plan to upload 3.0 to unstable or experimental, but will prepare 3.1 packages for experimental and upload those to unstable with the final release or a late release candidate. The 3.1 release is planned for April 2009. It would really help if Debian had python3.0, becuase it would help me, as upstream, to port my software. Currently I have to compile python3.0 from the ubuntu source package. If ubuntu can have it, why not Debian? I will provide packages on people.debian.org, which should help for the upstream work. python-3.0 is very short lived and I do want to avoid an unnecessary transition. Ok, that makes sense. Thanks! Ondrej -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Python related changes for unstable/squeeze
Various --- There are other things which may be worth a look. - Can you guys please finally sit down and agree on one solution for handling python modules? I still think that having two (slightly different) ways of doing this task is not the way to go. I really do not see technical reason for this situation. I have no preference at all and I'm actually using both things in my packages, but I really do not think it is way to go. And it would be great if we can have single tool, which gets more testing and will have less bugs than current concurrent solutions. I strongly support this. I also use both in my packages and I would prefer if there was just one way. I don't mind which. Ondrej -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ok to upload cython 0.10.3-1?
On Mon, Feb 9, 2009 at 5:14 AM, Bernd Zeimetz be...@bzed.de wrote: Hi! Ondrej Certik wrote: is it ok if I upload 0.10.3-1? E.g. will it break the sage build (or anything else)? Lenny will be released in 5 days - is it really a problem to wait for that? No, not at all. Let's wait then. Ondrej -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Presentation and some questions/remarks about numpy/scipy packages
Hi David! On Sun, Feb 8, 2009 at 9:10 PM, David Cournapeau courn...@gmail.com wrote: Hi, I am a developer of numpy and scipy, and I would be interested in helping numpy/scipy debian packages to be better on both Debian and Ubuntu. As a user of both Debian and Ubuntu, and one of the main developer working on build issues for numpy/scipy, I think I can be useful :) I am really glad you are interested in the packaging. Welcome! :) Do you know how to build it from our svn? If not, feel free to ask. Since python-sphinx 0.5 is in unstable now, do you think we should build with the docs as they are in the debian packaging svn? I simply used numpy svn and copied the doc directory into the tarball, see the debian/rules. I looked at the recent debian packaging (current trunk), and I noticed two things which I think are mistakes, or at least seem strange: - build-depends has a depdency on libfftw3-dev. Numpy does not use FFTW at all, and never had to my knowledge, at least from numpy 0.9.8 (almost 3 years ago). I think it could probably be just removed, unless someone objects. - build-conflicts against atlas. I guess this is to avoid explicitely linking against ATLAS - this can be avoided easily without the build-conflicts which is a bit of a pain: ATLAS=None python setup.py build should build numpy (and scipy) without ATLAS, even if atlas is detected. Thanks for the tip --- I think there was some reason for this conflict, but I can't remember now. Let's wait a bit what other think here. Ondrej -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Presentation and some questions/remarks about numpy/scipy packages
On Sun, Feb 8, 2009 at 10:00 PM, David Cournapeau courn...@gmail.com wrote: On Mon, Feb 9, 2009 at 2:36 PM, Ondrej Certik ond...@certik.cz wrote: Hi David! On Sun, Feb 8, 2009 at 9:10 PM, David Cournapeau courn...@gmail.com wrote: Hi, I am a developer of numpy and scipy, and I would be interested in helping numpy/scipy debian packages to be better on both Debian and Ubuntu. As a user of both Debian and Ubuntu, and one of the main developer working on build issues for numpy/scipy, I think I can be useful :) I am really glad you are interested in the packaging. Welcome! :) Do you know how to build it from our svn? If not, feel free to ask. Well, I know how to build a debian package from source and how to fix some issues, but I am not familiar with a lot of tools around. Is there a simple guideline about this ? Our page is here: http://wiki.debian.org/Teams/PythonModulesTeam and in particular I wrote this howto: http://wiki.debian.org/PAPT_Howto E.g. the section Building the package. Btw, feel free to update the PythonModulesTeam page above with instructions how to build the package, that would be really useful. Since python-sphinx 0.5 is in unstable now, do you think we should build with the docs as they are in the debian packaging svn? I simply used numpy svn and copied the doc directory into the tarball, see the debian/rules. Doc is a pain to deal with with distutils, generally. I don't know what's the doc status in 1.2 (the documentation infrastructure is one of the big change since 1.2 for the upcoming 1.3). I think we can ignore doc changes for 1.2*, and focus on 1.3, since we would need to change anyway for 1.3. Ok, so should I leave the current tarball, as you can see, I am using svn -r6221: get-orig-source: wget http://qa.debian.org/watch/sf.php/numpy/numpy-1.2.1.tar.gz; \ tar xzf numpy-1.2.1.tar.gz; \ cd numpy-1.2.1; \ svn export -r6221 http://svn.scipy.org/svn/numpy/trunk/doc; \ cd ..; \ tar czf python-numpy_1.2.1.ds.orig.tar.gz numpy-1.2.1; \ rm -rf numpy-1.2.1 numpy-1.2.1.tar.gz Thanks for the tip --- I think there was some reason for this conflict, but I can't remember now. Let's wait a bit what other think here. According to the debian/changelog file and the related bug on debian bug tracker, this was to avoid depending on ATLAS at link stage. This can be done by the command above - which is not really documented. Generally, the numpy build system is a bit arcane and 'magic'. In the short term, I hope to clarify most of oddities for easier packaging (not just Debian, BTW). Thanks, that's excellent. 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
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 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
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
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
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: 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: Python 3.0 ?
On Tue, Jan 6, 2009 at 1:39 PM, Christoph Haas em...@christoph-haas.de wrote: On Samstag, 27. Dezember 2008, Ondrej Certik wrote: On Sat, Dec 27, 2008 at 11:08 PM, Piotr Ożarowski pi...@debian.org wrote: [andmalc, 2008-12-27 23:00] I'd appreciate a package, if only to play with and not for production. $ dget -x https://launchpad.net/ubuntu/jaunty/+source/python3.0/3.0-0ubuntu1/+fi les/python3.0_3.0-0ubuntu1.dsc $ cd python* $ debuild This reminds me we should finish debexpo: http://debexpo.workaround.org/trac/ and install it, so that each of us doesn't have to recompile python3.0 again on our machines. Thanks for not giving up the project. I know you and I are currently the only believers. :) Unfortunately the GSoC student who wrote it went pretty much MIA right after the end of the GSoC phase. He promised to finish it but I don't see any serious activity. So anyone with a little spare time to help testing and reporting bugs is welcome. People familiar with Python/MVC frameworks like Django, Turbogears or even Pylons (which it's using) are welcome. Perhaps we are lucky and get some support here. mentors.debian.net badly needs the software, too. My moldy old code is falling apart. :( Let's get this done, I think that this functionality is absolutely necessary for Debian, so the sonner we do it, the better. I just sent an email to debexpo-devel about that. Thanks, Ondrej
Re: Python 3.0 ?
On Sat, Dec 27, 2008 at 11:08 PM, Piotr Ożarowski pi...@debian.org wrote: [andmalc, 2008-12-27 23:00] I'd appreciate a package, if only to play with and not for production. $ dget -x https://launchpad.net/ubuntu/jaunty/+source/python3.0/3.0-0ubuntu1/+files/python3.0_3.0-0ubuntu1.dsc $ cd python* $ debuild This reminds me we should finish debexpo: http://debexpo.workaround.org/trac/ and install it, so that each of us doesn't have to recompile python3.0 again on our machines. Ondrej
Re: numpy 1.2.1, switching to git?
On Fri, Dec 26, 2008 at 12:54 AM, Piotr Ożarowski pi...@debian.org wrote: [Piotr Ożarowski, 2008-12-23 13:37] unfortunately I use Git only outside Debian, so I don't know about issues git-buildpackage might have. I know it doesn't have mergeWithUpstream but it's written in Python, so we can implement this. The problem is (FWIK) that it's better to use Git with upstream sources (with tools like pristine-tar)... anyway, I vote for Git, but I'm open to alternative suggestions. update: I vote for status quo (svn, svn-buildpackage, mergeWithUpstream) for now - at least until all top contributors will have decent internet connection or we'll work out some kind of remote upstream branches schema so that one could choose what to download (and a script to download all repositories (packages) within the team) Agree. We talked with Sandro on IRC, the problem is in a bad internet connection --- it takes ~40min to download 10MB -- then of course every MB matters. For me it takes just couple seconds, so it doesn't really matter if I am downloading tarball+debian dir separately, or together in a git repo. I just assumed that everyone has a decent internet connection these days, and I was wrong. :) Ondrej
Re: numpy 1.2.1, switching to git?
On Wed, Dec 24, 2008 at 10:35 PM, Sandro Tosi mo...@debian.org wrote: On Wed, Dec 24, 2008 at 00:48, Ondrej Certik ond...@certik.cz wrote: thanks for the points, I reacted to some. so please accept my reply :) Absolutely. :) have you ever tried git-svn to work over your packages actually in the team? Yes, git-svn rocks and I use it regularly, but branching+merging sucks with git-svn, plus you cannot really use it with git-buildpackage, upstream branch and pristine-tar. Also if you reclone it, you have to follow the howto here in order to dcommit back to svn: http://subtlegradient.com/articles/2008/04/22/cloning-a-git-svn-clone Really? for a bunch of file under debian/ you need all of this? or are you talking about upstream code? I think we need to separate the 2 arguments, because the *are* separated: we are packagers, we have to keep track of our team's things; your involvement in upstream development is commendable, but this is something other that debian packaging, so it has to be. Yes, I do use it just with the debian dir, to see what other people have done with the package. However, sometimes the orig.tar.gz cannot be obtained with svn-uscan --- let's say if you are repackaging upstream, or simply if you are packaging a different version than svn-uscan downloads. well, either you're creating a new revision of an already existing package (so apt-get source --tar-only would do) or you should stick to the lastest released tarball, ain't you? There should be strong reason I want to be able to also easily build let's say the new numpy version (1.2.1) together with the one in the Debian archive, e.g. 1.1.1. Because the 1.2.1 requires a bit more work, I cannot yet upload it to Debian. So now we have 2 orig.tarballs already. You are right, that in this case I can get both just with apt-get source or svn-uscan. to not package the latest version but one between the latest and the one in the archive, that could he handled as expection: they are not the regular way to do, so we cannot take them as examples. In fact, svn-uscan downloads the one specified in debian/changelog, so I can get any orig.tarball I need, as long as upstream webpages have it. The problem is that I need an internet connection and upstream needs to have working webpages. With git+upstream branch, I can just clone the repo and go off the internet and I am safe, because I have everything needed to build any version. So it boils down to a question of size, e.g. harddisk and net connection speed/price. One example being the abinit package, where svn-uscan is offering me the highest released version number, however the production version (that should be packaged) is not the highest version available. this seems to be a very corner case Ok. I don't see too difficult: 1 command (whatever you prefer) comparing with the many of vi file + dch + build + lintian loops you do to prepare a package. everything will be in one git repo, Given my slow line, I cannot afford the pain to download every packages source code + debianization; now, to have a full checkout of dpmt/papt repositories, I need to launch the commands during the night. Additionally, doing repositories wide updates will become more painful, so I have to refrain from work on every package but just on mine. That's a good argument and I don't know the answer to it. But are you sure it would be that much bigger? Ondrej, you're a science man :) are you just kidding here? :D Of course it's bigger. A lot bigger. Given you have the whole repository I just asked a question and as a science man, I was curious about the answer. You say Of course it's bigger. A lot bigger.. So that made me think, hmm, let's just try it and see. So I took the last 4 upstream releases of numpy, and imported the orig.tarballs one by one into one git repository, together with the binary-delta (e.g. pristine-tar). version, git size, orig.tar.gz size 1.0.1 1.5M 1.2M 1.1.0 2.2M 1.7M 1.1.1 2.3M 1.6M 1.2.1 2.6M 1.4M So as you can see, the whole repository with all 4 versions is less than twice as big as any orig.tar.gz. I do not consider this a lot bigger. locally, you have the HEAD + all other modifications done in the past, for both the upstream code and the debianization. It's like No, only upstream orig.tar.gz is imported, so we do not care about upstream revisions -- that's not our problem. downloading all the uploaded version of the package in the archive compared with only the latest one. As you can see from my example with numpy above, this doesn't seem to be the case. The amount of downloaded data is *less* than two orig.tar.gz in the numpy case above. Let's take the example of DPMT: the dimension on the svn repo on alioth is 186M while the full checkout I have here is 47M. And that's only for debian/ dir (well, almost, but still). Well, but you need to count the orig.tar.gz that you need to download as well in order to build any
Re: numpy 1.2.1, switching to git?
Btw, Emilio did a list of the most active DPMT users, here it is. Some people like pox and piotr are actually the same. And the same list for PAPT: emi...@saturno:~/deb/python-apps$ svn log | egrep ^r[0-9]+ | cut -f2 -d'|' | sed 's/-guest//' | sort | uniq -c | sort -n -r 401 nijel 288 piotr 235 gothicx 159 pochu 76 nslater 69 kumanna 68 rainct 66 gilir 63 certik 52 vdanjean 52 bzed 46 dottedmag 41 stani 39 varun 37 kitterma 36 morph 35 odd_bloke 29 pcc 29 gudjon 28 appaji 25 thomasbl 24 arnau 20 sc 20 andyp 18 jalet 15 gerardo 14 eike 14 ana 13 dfiloni 11 tklauser 10 ryanakca 10 nxvl 10 akumar 8 sez 8 baby 6 catlee 4 osrevolution 4 cody-somerville 2 mithrandi 2 cjsmo 1 nenolod 1 ffm -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: numpy 1.2.1, switching to git?
On Tue, Dec 23, 2008 at 2:14 PM, Bernd Zeimetz be...@bzed.de wrote: Matthias Klose wrote: I only trust my own comparsion without any date and version numbers. And honestly I don't care about a checkin of the usual 2-5 files taking half a second longer. What annoys me most with git is the steep learning curve and the non-intuitive UI, therefore I do prefer bzr over hg over svn over others. In my opinion git is much more intuitive than any other tool - but you have to climb a bit on the learning curve before you realize it. If you already know hg, the curve is not steep at all (as I said, it took me a day or two to feel like at home). I suspect if you already know bzr well, the curve will not be steep as well. Ondrej -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: numpy 1.2.1, switching to git?
Hi Sandro, thanks for the points, I reacted to some. On Tue, Dec 23, 2008 at 5:02 PM, Sandro Tosi mo...@debian.org wrote: P.S. bzed, POX, isn't it time to move our packaging to git? I'm none of them, but I'll speak anyway :) Buxy almost did my point, I'd like to express me a bit. To do a change into something different we need a reason: what's the reason for moving from svn to git? is it because it's cool? (I hope not ;) ) is it because it has some features missing in svn? maybe, but which ones? something else? Yes, distributed version control system has many features that are missing in svn (=that I am missing in svn), mainly that I can easily fiddle with different approaches and branches locally, that I can easily upload my own branch somewhere for someone else to try. With svn, I need to append a patch to our BTS/mailinglist. It's DVCS, ok, but how many time did you have to diff or log a package offline? How many time did you have to leave uncommitted changes Actually, all the time. Maybe it's only how I work, but I often look at the history to learn what are the latest changes to see where the package is heading to, what is the style of maintaining, etc. Or simply to remind myself what I did on this package in the past. locally while waiting to connect to network for svn up svn co? it Also all the time, the latest example being my very first email in this thread. would be the same for git or svn: you need network to upload a package, and you need network to update/commit/whatever action on the repo. Having a centralized place, to concentrate our work it's a plus, not a minus for us (IMO): why would you distribute it? That's a good point and an argument why we should use one VCS as a team. Moreover, I do not want upstream code in the VCS we use for debianization (I did this error for personal managed pacakges and I do not want to do it again). Let upsteam tracks his own source code like he prefers, we do not need re-tracking it in git/svn/XXX, what we want to do is to keep track of our work, what's in debian/ dir *only*. As I understand, the upstream code in the repo is useful only so that one doesn't have to fiddle with orig.tar.gz. If, for packaging reason, you need to touch the upstream code, then checkout the upstream code in whatever place you prefer, using the same VCS upstream uses, and submit them patches, check differences or what-so-ever, but that has nothing to do with packaging that tool. I agree with this. So that I can just commit such patches in a branch and also so that we don't have to mess with the orig.tar.gz, svn-uscan and other things apt-get source --tar-only src_pkg Ah thanks, I forgot about this. uscan --verbose --repack --rename --destdir=/where/you/keep/tarballs Right, that's almost what my svn-uscan alias does: $ alias svn-uscan alias svn-uscan='uscan --verbose --force-download --rename --destdir=../tarballs' However, sometimes the orig.tar.gz cannot be obtained with svn-uscan --- let's say if you are repackaging upstream, or simply if you are packaging a different version than svn-uscan downloads. One example being the abinit package, where svn-uscan is offering me the highest released version number, however the production version (that should be packaged) is not the highest version available. I don't see too difficult: 1 command (whatever you prefer) comparing with the many of vi file + dch + build + lintian loops you do to prepare a package. everything will be in one git repo, Given my slow line, I cannot afford the pain to download every packages source code + debianization; now, to have a full checkout of dpmt/papt repositories, I need to launch the commands during the night. Additionally, doing repositories wide updates will become more painful, so I have to refrain from work on every package but just on mine. That's a good argument and I don't know the answer to it. But are you sure it would be that much bigger? If you want to test a package, you still need to download the orig.tar.gz plus the debian dir (in svn). (the best thing is to just try this and see) What users are you talking about? those that wants to rebuild a package are experienced used, so they can apt-get source pkg and then debcheckout it or whatever order/way they prefer. A normal used is client of the .deb package installed via apt-get/aptitude/synaptic/dpkg/ I am talking about the user (client in your terminology:), who reports a bug and even suggests a fix, but he doesn't have time to learn how to fiddle with svn-buildpackage+orig.tar.gz. Especially if the fix needs to change some patches in debian/patches. See the howto in the Holger's wiki: http://wiki.debian.org/HolgerLevsen#head-a629792087aba6594e680a74e93b55a9318ba995 it's too dificult I myself don't remember it and I still need to copy the commands from the wiki each time I am fixing some patch in debian/patches. Actually --- when looking at it now, it seems
Re: numpy 1.2.1, switching to git?
On Sat, Dec 20, 2008 at 7:49 PM, Steve Langasek vor...@debian.org wrote: On Sat, Dec 20, 2008 at 06:43:19PM +0100, Bernd Zeimetz wrote: Monty Taylor wrote: /me whinges that switching to bzr for packaging in general would be a much nicer thing overall, since then ubuntu downstream is pretty well bzr... unfortunatelt I don't know why they use bzr Because bzr was developed in conjunction with Ubuntu? :) (This might mean Ubuntu is somewhat biased in favor of bzr; OTOH, it also means that bzr developers are responsive to the needs of Ubuntu developers.) as it is really ugly to use Ugly how? (that's just my subjective opinion, please don't start a flame war now) It's a rather strongly worded opinion; if you want to avoid flame wars, you might find it helpful to bring specific criticisms to the table instead of just declaring a solution ugly. :) Well, it's just slow once you get used to git and how fast it is, it really sucks to wait for basic operations like bzr di. See e.g. my comparison here: http://www.selenic.com/pipermail/mercurial/2008-August/021009.html But as Bernd said, let's not start a flamewar about this. But I think it's useful to see what all the debian-python developers think. As I told Matthias offlist, we should only switch to git if most of developers are fine with that. Yeah, but since we are talking about that --- Steve, do you really think that bzr has any future? I know that Ubuntu is using it a lot, and couple other projects (mostly hosted on Launchpad), but that's about it. Git, on the other hand, is used a lot in Debian, and in a lot of other projects. Also you have many places on the internet to store your repository (github, gitorious, git.debian.org, ...). As to mercurial Tristan, I don't know if you actually ever used hg-buildpackage, but it is written in Haskell (!) and see my blog post here: http://ondrejcertik.blogspot.com/2007/10/mercurial-vs-git-for-managing-debian.html it's not really well polished (well, of course, because not a lot of people are using it, compared to git-buildpackage). Anyway, besides stating which vcs one likes, this is mostly a debate over a beer in Prague, but well, why not, I just had several of them. Ondrej -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Would like to add a new package and looking for support.
On Wed, Dec 17, 2008 at 1:40 PM, Nima Talebi n...@autonomy.net.au wrote: Hi Everybody. I've taken the latest dmidecode (http://www.nongnu.org/dmidecode/) and recompiled it as a python module, which I'd now like to introduce into the unstable debian release. The web page for this project is at http://projects.autonomy.net.au/dmidecode, and I'm almost done with the debian package itself, I wanted to know if there is anyone here who is interested enough to look at my package and tell me if I've done the right thing. It should be in the code repository detailed on the site soon. I couldn't find the debian package on the above links -- could you please point me to the .dsc file? I'll have a look. Ondrej -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
numpy 1.2.1, switching to git?
Hi,
I just uploaded some fixes to numpy 1.1.1, currently in incoming. The
attached patch fixes the packaging so that it compiles with the new
numpy 1.2.1. However, I had to comment out all the documentation
building, as it has changed upstream (and the current Debian packaging
breaks the build).
So if anyone (Kumar?) have time to work on this, it'd be awesome. For
others, if you just need the package, apply the patch and it will
build.
Ondrej
P.S. bzed, POX, isn't it time to move our packaging to git? So that I
can just commit such patches in a branch and also so that we don't
have to mess with the orig.tar.gz, svn-uscan and other things -- i.e.
everything will be in one git repo, so users can just download, hit
one command and they have a working package (as opposed to the current
scheme, were they need to download svn, then setup some tarball
directories, then setup svn-uscan, then execute it and only then they
can actually build the package, so it's very annoying for casual users
to setup the environment to contribute to the packaging)
Index: debian/changelog
===
--- debian/changelog (revision 7087)
+++ debian/changelog (working copy)
@@ -1,3 +1,9 @@
+python-numpy (1:1.2.1-1) unstable; urgency=low
+
+ * New upstream release
+
+ -- Ondrej Certik [EMAIL PROTECTED] Mon, 08 Dec 2008 17:32:37 +0100
+
python-numpy (1:1.1.1-2) unstable; urgency=low
[ Ondrej Certik ]
Index: debian/rules
===
--- debian/rules (revision 7087)
+++ debian/rules (working copy)
@@ -32,8 +32,8 @@
install -d $(CURDIR)/debian/python-numpy/usr/share/doc/python-numpy
cp -r $(DEB_DESTDIR)/usr/lib/python$(cdbs_python_current_version)/site-packages/numpy/doc/* \
$(CURDIR)/debian/python-numpy/usr/share/doc/python-numpy/
- cp $(DEB_DESTDIR)/usr/lib/python$(cdbs_python_current_version)/site-packages/numpy/doc/README.txt \
- $(CURDIR)/debian/python-numpy/usr/share/doc/python-numpy/README.doc.txt
+# cp $(DEB_DESTDIR)/usr/lib/python$(cdbs_python_current_version)/site-packages/numpy/doc/README.txt \
+# $(CURDIR)/debian/python-numpy/usr/share/doc/python-numpy/README.doc.txt
: # Adding links to manpages
mkdir -p debian/python-numpy/usr/share/man/man1
@@ -69,12 +69,12 @@
dh_link usr/share/pyshared/numpy/core/include/numpy usr/include/python$${i}_d/numpy; \
done
-binary-install/python-numpy-doc::
- cp -r $(CURDIR)/numpy/doc/html/* $(CURDIR)/debian/$(cdbs_curpkg)/usr/share/doc/$(cdbs_curpkg)
- mkdir $(CURDIR)/debian/$(cdbs_curpkg)/usr/share/doc/$(cdbs_curpkg)/f2py
- rst2html numpy/f2py/docs/usersguide/index.txt $(CURDIR)/debian/$(cdbs_curpkg)/usr/share/doc/$(cdbs_curpkg)/f2py/index.html
- cp -r $(CURDIR)/numpy/f2py/docs/* $(CURDIR)/debian/$(cdbs_curpkg)/usr/share/doc/$(cdbs_curpkg)/f2py
- chmod -x $(CURDIR)/debian/$(cdbs_curpkg)/usr/share/doc/$(cdbs_curpkg)/f2py/usersguide/setup_example.py
+#binary-install/python-numpy-doc::
+ #cp -r $(CURDIR)/numpy/doc/html/* $(CURDIR)/debian/$(cdbs_curpkg)/usr/share/doc/$(cdbs_curpkg)
+ #mkdir $(CURDIR)/debian/$(cdbs_curpkg)/usr/share/doc/$(cdbs_curpkg)/f2py
+ #rst2html numpy/f2py/docs/usersguide/index.txt $(CURDIR)/debian/$(cdbs_curpkg)/usr/share/doc/$(cdbs_curpkg)/f2py/index.html
+ #cp -r $(CURDIR)/numpy/f2py/docs/* $(CURDIR)/debian/$(cdbs_curpkg)/usr/share/doc/$(cdbs_curpkg)/f2py
+ #chmod -x $(CURDIR)/debian/$(cdbs_curpkg)/usr/share/doc/$(cdbs_curpkg)/f2py/usersguide/setup_example.py
build/python-numpy-dbg::
set -e; \
Re: python-matplotlib_0.98.1-1+lenny3_i386.deb
On Sat, Nov 8, 2008 at 11:28 AM, Tom Kuiper [EMAIL PROTECTED] wrote: Dear Dato, On Monday I installed this package and the two associated packages (as they were then, anyway) from http://ftp.de.debian.org/debian/pool/main/m/matplotlib/ On Thursday I tried to save a figure to EPS format and got the errors below. Is there something else that needs to be updated? It seems to work for me. Could you please post here the full script that reproduces the error? Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python-matplotlib_0.98.1-1+lenny3_i386.deb
On Sat, Nov 8, 2008 at 7:17 PM, Kumar Appaiah [EMAIL PROTECTED] wrote:
Dear Tom,
On Sat, Nov 08, 2008 at 09:04:38AM -0800, Tom Kuiper wrote:
What package does the TTF to EPS/PS conversion?
Reading through your backtrace, I guess the function which fails is
convert_ttf_to_ps. This function is defined in the matplotlib source
file src/_ttconv.cpp, and the relevant portion which seems to fail is
this:
try {
insert_ttfont( filename, output, (font_type_enum)fonttype,
glyph_ids );
} catch (TTException e) {
PyErr_SetString(PyExc_RuntimeError, e.getMessage());
which is fairly strange, since you should be having the fonts already.
Could you please tell me if you are doing anything special in your .py
file which causes some error in loading the EPS fonts? (not that I
would still be able to help, but anyway...)
I am attaching the file that Tom sent me in private and forgot to
attach to the list. It supposedly fails for him, but it works for me.
Ondrej
#!/usr/bin/python2.4
from pylab import *
def S(R):
ratio = 0.3078*R
return 1./(ratio - 1)
def Tb(S,nLdv):
if abs(S) 0.1:
result = 1
else:
result = 0.32*S*(1-exp(-0.85*nLdv/S))
if result 1e20: return 1e20
#print S, result
return result
vTb = vectorize(Tb)
subplot(2,1,1)
R = linspace(1.0,5,100)
plot(R,S(R),label='extended source')
plot(R,S((290.1/239.75)**2*R),label='point source')
ylim(-20,5)
xlabel(r'$290/239$')
ylabel(r'$\mathcal{S}$')
grid()
legend(loc='lower right')
subplot(2,1,2)
#S = linspace(-.8,.4,100)
S = logspace(-3,1.3)
#print Tb(S,1)
# plot(S, vTb(S,1) )
loglog(S,vTb(-S,1.),label=r'$\frac{nL}{\Delta v} = 1$')
loglog(S,vTb(-S,10.),label=r'$\frac{nL}{\Delta v} = 10$')
loglog(S,vTb(-S,100.),label=r'$\frac{nL}{\Delta v} = 100$')
ylim(0,1e9)
#xlim(-.8,.4)
xlim(0.001,20)
grid()
xlabel(r'$-\mathcal{S}$')
ylabel(r'$T_B$')
legend(loc='upper left')
savefig('S_vs_R.eps',papertype='letter')
show()
Re: Let's switch to viewsvn for Vcs-Browser?
On Mon, Nov 3, 2008 at 11:19 PM, Sandro Tosi [EMAIL PROTECTED] wrote:
Hi all,
On Sat, Nov 1, 2008 at 18:07, Sandro Tosi [EMAIL PROTECTED] wrote:
Hi all,
following up what once POX suggested on irc, I'd like to switch from
wsvn to viewsvn (compare the difference yourself at [1] and [2]) for
Vcs-Browser field.
I already checked-out the whole packages/ dir from both svn repos (so
that the changes thru all the repo can be done in a single commit
instead of polluting with commit for each package) and I got the
script I used to uniform Vcs-* fields I can modify to do this
conversion (so basically I'm volunteering :) ).
If no-one will complain, let's say, in a couple of days, I'll run the script.
Done! Now DPMT and PAPT packages that already have Vcs-Browser field,
now have it using viewsvn. I did the changes with a script, so I hope
I didn't create too much artifacts in the changelog (but they are so
trivial, easily removable when the maint will approach to upload the
package).
I've not done yet: I'd like to add Vcs-{Svn,Browser} fields to those
packages currently lacking 'em, but that's a job for another day ;)
Thanks for the work you did!
Ondrej
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
status of python2.6
Hi, is there anyone packaging python2.6? Any plans for it? I did some really stupid and naive packaging here: http://github.com/certik/python2.6/tree/master in case anyone wanted some package immediatelly. But a proper packaging should be done -- I don't know if there is anything special to watch for, so that python-support and python-central works, etc. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: status of python2.6
On Fri, Oct 3, 2008 at 11:54 AM, Piotr Ożarowski [EMAIL PROTECTED] wrote: [Ondrej Certik, 2008-10-03 11:41] is there anyone packaging python2.6? Any plans for it? I'm sure Matthias will upload python2.6 to unstable short after releasing Lenny. For now Lenny has the highest priority. (i.e. if you want python2.6 in Debian - fix some RC bugs :) Well, I need to fix some RC bugs anyways in order to finally become a DD. :) But first I need to finish the administration with my Ph.D. studies. When will Lenny be released? When the number of RC bugs goes to 0? Ondrej
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: request to join debian python teams
On Sat, Aug 23, 2008 at 8:59 PM, Serafeim Zanikolas [EMAIL PROTECTED] wrote: On Fri, Aug 22, 2008 at 12:09:07AM +0200, Piotr Ożarowski wrote: Hi Serafeim, [Serafeim Zanikolas, 2008-08-20] I'd like to join the python modules and apps teams to help with general QA. I've added you to both teams, welcome :-) Thank you Piotr! I've committed my first (minor) fixes for ipython in svn r5584. Anyone, please let me know if I've missed anything in terms of team process (I've added a changelog entry with distribution set to UNRELEASED). Thanks for your fix! The patch looks good to me. Ondrej
Re: should numpy be built with atlas?
On Tue, Jul 8, 2008 at 1:58 PM, Tiziano Zito [EMAIL PROTECTED] wrote: On 7/8/08, Matthias Klose [EMAIL PROTECTED] wrote: thanks for the update. Looking at the blas package, I see that the cblas library is included in libblas3. So it looks like the numpy check is wrong, testing for a package name, and not for a feature. This seems to explain why it did work in etch, and this should be fixed in python-numpy. Hi Ondrej, Hi Matthias. Removing the two lines in numpy/core/setup.py indeed seems to do the trick. Feel free to test the attached patch, generated against the python-numpy source package in sid. On my system it generates a numpy package with a _dotblas.so file correctly linked to lapack libs. If ATLAS is then installed, the ATLAS libraries are used instead. Ondrej: if the patch works, would you report it upstream? Yes, but first I'll upload a new package, because depending on the atlas packages is not good. It works on my system. Your script (attached) gives me: $ ./test_atlas.py Using ATLAS: 0.53141283989 $ wajig remove atlas3-base libatlas3gf-base $ ./test_atlas.py Using ATLAS: 1.64572000504 So it seems to work, even though the difference is not so big. I am now going to test the package on i386 and then upload if all is ok. We can then talk with upstream what is the best way to fix this in the long term. Ondrej #! /usr/bin/env python import numpy import time try: import numpy.core._dotblas print 'Using ATLAS:' except ImportError: print 'No ATLAS:' t = time.time() x = numpy.random.random((1000,1000)) y = numpy.random.random((1000,1000)) z = numpy.dot(x, y) print time.time()-t
Debian: numpy not building _dotblas.so
Hi, we have this problem in Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489726 The problem is that numpy should not depend on atlas unconditionally, yet it should allow it for users that have it. I am not an expert in blas/lapack/atlas and it's Debian packaging much (I know some people say that atlas packaging in Debian is not very good, actually pretty bad), so I am just forwarding the question here. The problem is with this patch: http://projects.scipy.org/scipy/numpy/changeset/3854 and the question that we have is: doko I'd like to know, if the code was changed to only work with atlas, or if was never working. if it's the latter, then we should use atlas Matthias, Tiziano, feel free to clarify this more. See the above Debian bug for more information and background. Thanks, Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: scipy packaging
On Mon, Jul 7, 2008 at 6:34 PM, Pietro Battiston [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, a package I maintain, gvb, has just entered sid, and I noticed that unfortunately I erroneously set Priority: optional (it is wrong because it depends on python-scipy which has Priority: extra). I was already fixing this, but first I was curious on why scipy had extra. I noticed it Conflicts: with the following packages: python-scipy-core, python2.3-scipy, python2.3-scipy-core, python2.4-scipy, python2.4-scipy-core actually, those seem to me all obsolete or only used in kfreebsd architecture... in other words, it seems to me better to set Priority: extra in those and Priority: optional in main python-scipy package. Please forgive me if I'm missing something, those are my first steps as Debian maintainer... Thanks for asking these questions. Even though I try to keep python-scipy in shape, I don't know the answers. To me personally it doesn't really matter, if it's extra, or optional. But if you need something fixed in python-scipy and you get a consensus on that, I'll fix it, or help you fix it. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: numpy 1.1: import numpy fails in Debian
On Mon, Jun 9, 2008 at 6:20 PM, Ondrej Certik [EMAIL PROTECTED] wrote: Hi, I tried to package numpy 1.1 and upload it to Debian, all worked fine, I installed the package and: In [1]: import numpy --- ImportError Traceback (most recent call last) /home/ondra/debian/packages/numpy/ipython console in module() /usr/lib/python2.5/site-packages/numpy/__init__.py in module() 105 import random 106 import ctypeslib -- 107 import ma global ma = undefined 108 109 # Make these accessible from numpy name-space ImportError: No module named ma So I tried to investigate where the problem is, but I didn't figure it out. I am sending the build log. If anyone knows what's wrong, it'd be very helpful. The only thing I figured out so far is that the ma package gets installed into: debian/tmp/usr/lib/python2.5/site-packages/numpy/ma but it is not copied into the directory: debian/python-numpy/usr/share/pyshared/numpy/ from which the package is made. So it's maybe a bug in some Debian package, rather than in numpy itself. But maybe some numpy developers know what is so different on the ma package (which as I understand was added in 1.1). Andrew Straw fixed the problem, so the new numpy package is in incoming: http://incoming.debian.org/ and should be on Debian mirrors tomorrow. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: debhelper 7 and python-central
On Mon, May 19, 2008 at 12:49 PM, Josselin Mouette [EMAIL PROTECTED] wrote: Le dimanche 18 mai 2008 à 11:35 -0700, Monty Taylor a écrit : 1. What are the real differences between these two? Technically speaking, they use very different approaches. Python-central links modules at their original places while python-support puts them in /var/lib to follow the FHS. The latter approach is less fragile overall, but for a handful of (IMHO broken) packages it requires a few changes (like a different path installation, or moving files to a different directory). 2. Why, as a packager, would I choose one over the other? As the python-support maintainer, I could recommend it because it has more features, like namespace packages (allowing to split modules coming from the same directory in non-interdependent packages), Python-Depends (allowing to express Provides: in a way that doesn't break when the list of supported python versions changes), or triggers support (leading to faster upgrades). As the maintainer of several python-related packages, I have noticed recurrent breakage on user systems caused by bugs in python-central, and I avoid it for this precise reason. 3. Is there a valid reason to have both of them be acceptable if they both do the same job? Probably not, but I'm not in the right position to judge. I am glad this discussion is taking place. I'd like to add this to our FAQ, is anyone against it? Matthias Klose, as the maintainer of python-central, do you have any comments to this? I.e. if the above statements are accurate, it seems to me that python-support is now better than python-central -- do you have any plans to fix this, or what is the motivation of python-central? I know you suggested me to follow the changelog of it to know what is happening, but I am also interested in your future plans with it and especially what you don't like on python-support. So that we can find some common ground and either have two packages if there are two good approaches to the same thing that people just cannot agree on one, or just one package if the reason for two packages are just communication problems that we will fix/explain in this thread. Ondrej
Debian has switched to python2.5
Hi, for those like myself who didn't even notice, Debian has switched to python2.5 by the release team NMUing Python. So currently, some packages needs to be fixed, for example on my system, these packages now want to be removed: gimp-python hpijs hpijs-ppds hplip hplip-gui libapache2-mod-python openoffice.org openoffice.org-writer pida python-ctypes python-opengl python-subversion python-uno trac The problem is probably mainly with python-ctypes and maybe a few others. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian has switched to python2.5
On Mon, Apr 14, 2008 at 12:49 PM, Piotr Ożarowski [EMAIL PROTECTED] wrote: python2.5 is default since less than 24h, binNMUs were requested, please give our build daemons some time. In the mean time you can take a look at [1] and try to fix some old DPMT bugs :-) [1] http://qa.debian.org/[EMAIL PROTECTED] Yeah, I am fixing this recent RC bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=475990 :) Ondrej
Re: Request: mother
On Tue, Mar 25, 2008 at 11:01 PM, Piotr Ożarowski [EMAIL PROTECTED] wrote: Hi Antonio, [Antonio De Luci, 2008-03-24] I would like to be added to Team DMTP. I intend to keep the mother's package on DPMT. You're a new team member, welcome! BTW: you will need to list some good advantages over SQLAlchemy to get it sponsored by me (python-sqlalchemy maintainer :-) Haha, I was just going to ask the same question. :) Ondrej
Re: free profiler in python
On Tue, Feb 12, 2008 at 1:59 AM, Floris Bruynooghe [EMAIL PROTECTED] wrote: Hello Ondrej On Sat, Feb 09, 2008 at 12:01:52AM +0100, Ondrej Certik wrote: the python-profile is in non-free, so what free tool do you use for profiling your python programs? There is cProfile in python2.5, which seems to be free, but for showing the result I need pstat, which is again non-free. Is there a DFSG free way to profile python programs? A few year ago I wrote http://savannah.nongnu.org/projects/pyprof/ which set out to do what you want. Unfortunately I've failed to follow up on that since then. If there's enough interest it might be interesting to dust it off, get it up to date with python 2.5 and try to get a package in Debian. Excellent, that's exactly what I am looking for. I'll keep it in mind, if I start working on something like that, I'll start from your work and package it for Debian. Also I like that you chose a very permissive license (MIT). Thanks for your work. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Debian Python developers, make your packaging concerns known (was: Current distutils-sig discussion on package management)
On Wed, Mar 19, 2008 at 11:08 PM, Ben Finney [EMAIL PROTECTED] wrote: Ben Finney [EMAIL PROTECTED] writes: The Python distutils-sig group is currently discussing the topic of package management, how setuptools interacts with package managers, and what changes are desirable as a result. URL:http://mid.gmane.org/[EMAIL PROTECTED] [...] I urge anyone who's had problems getting Python setuptools and Debian package management working together, to join this discussion so that your issues can be considered in whatever changes ensue. To reiterate: This discussion is happening *now*. If ever you have looked at Python packaging (e.g. distutils or setuptools) and said no, *no*, NO!, then this is the time to get involved so that changes can be made for the better. I have no knowledge of *what* the problems are; I only know that there are people in this group who persistently complain about how Python's current packaging practices are broken with respect to Debian packaging. URL:http://mid.gmane.org/[EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] From: Guido van Rossum [EMAIL PROTECTED] Date: Wed, 19 Mar 2008 14:23:26 -0700 I'm back at Google and *really* busy for another week or so, so I'll have to postpone the rest of this discussion for a while. If other people want to chime in please do so; if this is just a dialog between Phillip and me I might incorrectly assume that nobody besides Phillip really cares. Please, if you have suggestions for what Python packaging could do better, and improve Debian packaging of Python packages, *now* is the time to join that discussion over at the distutils-sig. Thanks for letting us know. I also don't know what the particular problems are, my only experience was with the initial packaging of python-enthought-traits + mayavi2 where I was unable to force setuptools not to download stuff from the net, so I simply asked upstream to provide me a simple script to do the whole compilation+installation of all python files+modules. Then the packaging was dead easy. And Varun and Kmap then fixed it with the help of upstream, so now even the build script is not necessary anymore. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: to DDs: sponsors needed in DPMT and PAPT
On Thu, Feb 28, 2008 at 9:26 PM, Piotr Ożarowski [EMAIL PROTECTED] wrote: Hi, We need more sponsors in Debian Python Modules Team and Python Modules Packaging Team. If you have few free hours, please take a look at our TODO pages [1,2] and put your name in DD column if you're willing to work on a package with our non-DD member (and remove row once package is uploaded). Most of packages there are NEW (packages previously accepted are easier to check, so they're processed fast). Thanks in advance [1] http://wiki.debian.org/Teams/PythonModulesTeam/TODO [2] http://wiki.debian.org/Teams/PythonAppsPackagingTeam/TODO Yes, unfrotunately, I cannot really help much here yet as a non DD. :) Ondrej
Re: RFS: matplotlib 0.90.1-3
On Sat, Feb 23, 2008 at 5:08 PM, Ondrej Certik [EMAIL PROTECTED] wrote: On Sat, Feb 23, 2008 at 4:31 PM, Eike Nicklas [EMAIL PROTECTED] wrote: Hi Ondrej et al., Yes, I read that bug. There are more problems with matplotlib - it is not lintian clean, it still uses Numerics and numarray besides numpy (I don't know if this is a feature or a bug), I think upstream deprecated Numerics and numarray and the latest version only uses numpy. Changelog excerpts: 2007-06-01 Deprecate Numeric and numarray for use as numerix. 2007-06-02 Released 0.90.1 at revision 3352 2007-06-07 Disable build of numarray and Numeric extensions for internal MPL use and the numerix layer. 2007-07-19 replaced the Python code in numerix/ by a minimal wrapper around numpy that explicitly mentions all symbols that need to be addressed for further numpification [...] and only numpy is mentioned in the current README. Anyway, as a matplotlib user, I am happy that you want to fix the current issues, but sadly I currently don't have the time to help with that. It shouldn't be a big problem and I'll do it, as I also use and need it. We are actually only waiting for an approval from the matplotlib maintainers. Anyway, this seems it will take quite some time before it gets resolved, so I compiled the fixed packages for i386 and amd64 and put them here to my repository: http://debian.certik.cz/ Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RFS: matplotlib 0.90.1-3
Hi, currently, matplotlib doesn't install with numpy in sid, when numpy switched to gfortran and it conflicts with matplotlib. It seems just a recompile of matplotlib fixes the problem. I imported matplotlib to DPMT svn: svn://svn.debian.org/svn/python-modules/packages/matplotlib/ and committed the necessary change. Unfortunatley, the maintainer and uploaders of matplotlib didn't yet reply to my email and bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=467099 and a simple NMU will not fix the problem, as numpy conflicts with python-matplotlib ( 0.90.1-3). So what should I do to get this fixed soon? Should I upload (I can do that as a DM) a new revision of numpy not conflicting with python-matplotlib? Or can you upload the new matplotlib as I prepared in the svn? The best solution is the one I offered to the maintainers of matplotlib in the bug above - to maintain matplotlib in DPMT. But unless they approve it, I don't think we can do that. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: matplotlib 0.90.1-3
On Sat, Feb 23, 2008 at 4:31 PM, Eike Nicklas [EMAIL PROTECTED] wrote: Hi Ondrej et al., Yes, I read that bug. There are more problems with matplotlib - it is not lintian clean, it still uses Numerics and numarray besides numpy (I don't know if this is a feature or a bug), I think upstream deprecated Numerics and numarray and the latest version only uses numpy. Changelog excerpts: 2007-06-01 Deprecate Numeric and numarray for use as numerix. 2007-06-02 Released 0.90.1 at revision 3352 2007-06-07 Disable build of numarray and Numeric extensions for internal MPL use and the numerix layer. 2007-07-19 replaced the Python code in numerix/ by a minimal wrapper around numpy that explicitly mentions all symbols that need to be addressed for further numpification [...] and only numpy is mentioned in the current README. Anyway, as a matplotlib user, I am happy that you want to fix the current issues, but sadly I currently don't have the time to help with that. It shouldn't be a big problem and I'll do it, as I also use and need it. We are actually only waiting for an approval from the matplotlib maintainers. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
free profiler in python
Hi, the python-profile is in non-free, so what free tool do you use for profiling your python programs? There is cProfile in python2.5, which seems to be free, but for showing the result I need pstat, which is again non-free. Is there a DFSG free way to profile python programs? If not, it seems to me that only pstat is missing. Maybe I'll get fedup with this enough to write some freepstat replacement, in which case I'll let you know to sponsor the package. :) Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
how to get python-numpy to testing
Hi, python-numpy seems ok to go to testing, but: http://bjorn.haxx.se/debian/testing.pl?package=python-numpy a) Updating python-numpy makes 1 depending packages uninstallable on i386: python-scipy, this should however fall into: 1. Sometimes packages have seemingly recursive dependencies (adding X makes Y uninstallable, Y is waiting for X). This means the new version of X will break the old version of Y, but there's also a new version of Y that needs the new version of X. As soon as all other dependencies are solved, the two packages can be hinted to go in together. as python-scipy needs newer python-numpy etc. So all should be ok here. b) Updating python-numpy makes 5 non-depending packages uninstallable on i386: model-builder, ninix-aya, python-gastables, python-nifti, pyxplot Looking for example at: $ wajig show model-builder [...] Depends: python, python-central (= 0.5.8), python-numpy-ext, python-scipy, python-wxtools, python-wxversion, python-matplotlib, python-setuptools I don't see why newer python-numpy makes it uninstallable. Any ideas how to fix b), so that python-numpy can go to testing? Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: question about NumPy C include files location
On Dec 20, 2007 9:17 PM, Andrew Straw [EMAIL PROTECTED] wrote: Ondrej Certik wrote: Hi, the files like arrayobject.h, arrayscalars.h etc. used to be in: /usr/lib/python2.4/site-packages/numpy/core/include/numpy/ and this imho is the same on other distributions, like Gentoo. However, now, the fresh python-numpy in Debian has them in: /usr/share/python-support/python-numpy/numpy/core/include/numpy/ I am not sure this is correct? Those files are needed, when you want to write extension modules in C, that use python-numpy. Ondrej You probably know this already, but where ever they go, please make sure that numpy.get_include() knows where to find them. Thanks for the info. BTW, we decided with Kumar to wait until python-numpy gets into testing. Or should we fix this now? This is imho a policy violation, so it's an RC bug. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
question about NumPy C include files location
Hi, the files like arrayobject.h, arrayscalars.h etc. used to be in: /usr/lib/python2.4/site-packages/numpy/core/include/numpy/ and this imho is the same on other distributions, like Gentoo. However, now, the fresh python-numpy in Debian has them in: /usr/share/python-support/python-numpy/numpy/core/include/numpy/ I am not sure this is correct? Those files are needed, when you want to write extension modules in C, that use python-numpy. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: question about NumPy C include files location
On Dec 19, 2007 10:00 AM, Ondrej Certik [EMAIL PROTECTED] wrote: Hi, the files like arrayobject.h, arrayscalars.h etc. used to be in: /usr/lib/python2.4/site-packages/numpy/core/include/numpy/ and this imho is the same on other distributions, like Gentoo. However, now, the fresh python-numpy in Debian has them in: /usr/share/python-support/python-numpy/numpy/core/include/numpy/ I am not sure this is correct? Also the new package has them in: /var/lib/python-support/python2.4/numpy/core/include/numpy/ (symlinks) Where is the canonical place where to put those files, if any? Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why still 2.4? How can I help you?
On Dec 18, 2007 11:09 PM, Piotr Ożarowski [EMAIL PROTECTED] wrote: But Lenny and Sid are both still at Python level 2.4... If not now, then when? don't worry, Lenny will not have python2.4 as a default Python version (or it will be released with python2.4 over my dead body ;) Good. :) +1 Ondrej
Re: python-numpy has problems on buildbots
So the problem still persists on amd64 as reported by Jose. Apparently the problem still persists on amd64: $ apt-cache show python-numpy Package: python-numpy Priority: optional Section: python Installed-Size: 6092 Maintainer: Debian Python Modules Team [EMAIL PROTECTED] Architecture: amd64 Version: 1:1.0.4-2 Provides: python-f2py, python-numpy-dev, python-numpy-ext, python2.4-numpy, python2.5-numpy Depends: atlas3-base | lapack3 | liblapack.so.3, atlas3-base | libatlas.so.3, libc6 (= 2.7-1), libg2c0 (= 1:3.4.4-5), libgcc1 (= 1:4.2.1), python ( 2.6), python (= 2.4), python-central (= 0.5.8) The atlas3-base | libatlas.so.3 dependency forces users to install atlas. Is not such a big deal, as users will want to install atlas anyway... On i386 it is: Depends: atlas3-base | lapack3 | liblapack.so.3, atlas3-base | refblas3 | libblas.so.3, libc6 (= 2.7-1), libg2c0 (= 1:3.4.4-5), libgcc1 (= 1:4.2.1), python ( 2.6), python (= 2.4), python-central (= 0.5.8) so it's the refblas3, that is missing on amd64, right? Exactly. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Fwd: python-numpy has problems on buildbots
On Dec 5, 2007 1:03 PM, José Fonseca [EMAIL PROTECTED] wrote: Hi, On 12/5/07, Ondrej Certik [EMAIL PROTECTED] wrote: Hi, we with Kumar made a progress and had python-numpy uploaded (thanks Fabio). It builds nicely in pbuilder, but fails to build on buildbots. See: http://buildd.debian.org/pkg.cgi?pkg=python-numpy Fabio uploaded it on amd64, so that one is fine. Crucial are the following lines from debian/control: Build-Depends: cdbs (= 0.4.43), python-all-dev, python-all-dbg, python-central (= 0.5.6), refblas3-dev [!arm !m68k], lapack3-dev [!arm !m68k], debhelper (= 5.0.38), g77, patchutils, python-docutils, fftw3-dev Build-Conflicts: lapack-dev [!arm !m68k], blas-dev [!arm !m68k], atlas2-base, atlas2-base-dev, atlas3-base, atlas3-base-dev As you can see, arm and m68k are exceptions and indeed python-numpy builds on them just fine (see the link above). (It's still building on m68k, but last revision built there fine). It doesn't build on other architectures. If we look for example why it failed on the most important architecture i386: [...] So as you can see, the problem is that buildbots install atlas3-base for some reason and because we build-conflict with it, we fail. Three questions: 1. Why is there the build-conflict in the first place? This is the question to original maintainers (Marco, Alexandre, Jose, Matthias) I added the build-conflict because without it, dpkg-shlibdeps would make them depend exclusively on blas and lapack, instead of depending on the virtual package (because all other packages provide blas and lapack) So instead of getting the desired: Depends: atlas3-base | lapack3 | liblapack.so.3, atlas3-base | refblas3 | libblas.so.3, ... dpkg-shlibdeps would produce: Depends: atlas2-base Or Depends: atlas3-base I tried that - i.e. installed atlas3-base on my system, commented out build-conflicts, built python-numpy and got these dependencies: Depends: atlas3-base | lapack3 | liblapack.so.3, atlas3-base | refblas3 | libblas.so.3, ... which is imho correct, right? We are going to upload now. Ondrej
Re: python-numpy has problems on buildbots
I tried that - i.e. installed atlas3-base on my system, commented out build-conflicts, built python-numpy and got these dependencies: Depends: atlas3-base | lapack3 | liblapack.so.3, atlas3-base | refblas3 | libblas.so.3, ... which is imho correct, right? We are going to upload now. So it indeed seems to work: http://buildd.debian.org/pkg.cgi?pkg=python-numpy numpy built on i386, alpha, amd64, mips, mipsel, powerpc and probably on all the others. The i386 is in incoming, so tomorrow expect working python-numpy on your system. And if it isn't working, file a bug. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python-numpy has problems on buildbots
On Dec 5, 2007 8:10 PM, Lucas Nussbaum [EMAIL PROTECTED] wrote: On 05/12/07 at 13:37 +0100, Bernd Zeimetz wrote: 1. Why is there the build-conflict in the first place? This is the question to original maintainers (Marco, Alexandre, Jose, Matthias) I added the build-conflict because without it, dpkg-shlibdeps would make them depend exclusively on blas and lapack, instead of depending on the virtual package (because all other packages provide blas and lapack) The packages should not be installed on the buildds anyway, so I think ti shoudl work without build-conflicts. There's no garantee about which packages are *not* installed on the buildds, since packages are not uninstalled after builds. Build-conflicts is the good way to solve that. So would do you suggest? Just to wait until python-numpy gets build on buildbots? Or do you suggest to take some action (which)? :) Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python-numpy has problems on buildbots
There's no garantee about which packages are *not* installed on the buildds, since packages are not uninstalled after builds. Build-conflicts is the good way to solve that. if you look into a random log you'll see that the build chroot is cleaned up after a build. There're only packages left if something really goes wrong. His statement is nevertheless correct, there is *no* guarantee that packages will be built in pristine environments, and if this causes a problem for your package then your package is missing either a build-dependency or a build-conflict (or is buggy in some other way). The package seems to have a correct build-conflict, so it refuses to built, if it knows it would fail anyway. But I didn't understood - are the buildbots going to ever remove the build-conflicting package? or not? How was it that numpy was ever built on buildbots? One option of course is to help with the atlas transition. But does that mean that python-numpy will be broken until this gets resolved? This is not acceptable for me. So we need to find some solution, that allows us to build python-numpy, python-scipy et. al. on buildbots now. I'll try things that Jose and Bernd suggested and we'll see. There must be a way to build and fix it now, instead of tomorrow. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
python-numpy has problems on buildbots
Hi, we with Kumar made a progress and had python-numpy uploaded (thanks Fabio). It builds nicely in pbuilder, but fails to build on buildbots. See: http://buildd.debian.org/pkg.cgi?pkg=python-numpy Fabio uploaded it on amd64, so that one is fine. Crucial are the following lines from debian/control: Build-Depends: cdbs (= 0.4.43), python-all-dev, python-all-dbg, python-central (= 0.5.6), refblas3-dev [!arm !m68k], lapack3-dev [!arm !m68k], debhelper (= 5.0.38), g77, patchutils, python-docutils, fftw3-dev Build-Conflicts: lapack-dev [!arm !m68k], blas-dev [!arm !m68k], atlas2-base, atlas2-base-dev, atlas3-base, atlas3-base-dev As you can see, arm and m68k are exceptions and indeed python-numpy builds on them just fine (see the link above). (It's still building on m68k, but last revision built there fine). It doesn't build on other architectures. If we look for example why it failed on the most important architecture i386: [...] Setting up xfonts-utils (1:1.0.1-2) ... Setting up xterm (229-1) ... Setting up xutils (1:7.3+7) ... Checking correctness of source dependencies... After installing, the following source dependencies are still unsatisfied: atlas3-base(still installed) atlas3-base-dev(still installed) Source-dependencies not satisfied; skipping python-numpy /usr/bin/sudo dpkg --root=/home/buildd/build/chroot-unstable --purge libx11-data fontconfig-config libio-compress-base-perl gettext file libxaw7 ttf-dejavu python-all-dbg libfftw3-dev python2.5-minimal libxxf86dga1 libio-stringy-perl debconf-utils x11-common libfontenc1 libcompress-raw-zlib-perl libxi6 gcc-3.4 python2.4-dev libfribidi0 libfontconfig1 libidn11 patchutils libobject-realize-later-perl x11-utils gcc-3.4-base x11-xserver-utils libx11-6 libkrb53 libnewt0.52 atlas3-headers libxdamage1 libxt6 blt x11-session-utils xutils libssh2-1 python-all libice6 intltool-debian lapack3-dev libxrender1 libttf2 xfonts-utils ttf-dejavu-extra libxtst6 libxft2 libxext6 libxtrap6 atlas3-base libsqlite3-0 python2.5-dev libfile-remove-perl libxinerama1 tcl8.4 libncursesw5 libxmu6 python-docutils xfonts-encodings defoma libtimedate-perl libdigest-sha1-perl ttf-dejavu-core python2.5 libdrm2 liburi-perl curl libxpm4 autotools-dev refblas3 libmailtools-perl libxmuu1 python2.4-dbg cpp-3.4 p ython2.5-dbg libpopt0 libmail-sendmail-perl libfreetype6 libssl0.9.8 x11-xfs-utils libmime-types-perl libgl1-mesa-glx libcompress-zlib-perl libcurl3 tk8.4 libxv1 html2text xbitmaps debhelper libxrandr2 libkeyutils1 libuser-identity-perl xutils-dev libdmx1 python python-roman atlas3-base-dev libmagic1 libexpat1 libio-compress-zlib-perl libxau6 libdigest-hmac-perl g77-3.4 libfftw3-3 mime-support whiptail libxdmcp6 libxfixes3 libgpmg1 libg2c0 po-debconf g77 refblas3-dev libxfont1 python-all-dev python-dbg libxxf86vm1 python-dev lapack3 libft-perl python-minimal python2.4 cdbs ucf xterm libg2c0-dev libfs6 gettext-base libxxf86misc1 libsm6 python-central python2.4-minimal libmail-box-perl (Reading database ... 15444 files and directories currently installed.) Removing python-all-dbg ... Removing libfftw3-dev ... Removing debconf-utils ... [...] So as you can see, the problem is that buildbots install atlas3-base for some reason and because we build-conflict with it, we fail. Three questions: 1. Why is there the build-conflict in the first place? This is the question to original maintainers (Marco, Alexandre, Jose, Matthias) 2. Why are there the exceptions to m68k and arm? 3. If the build-conflict is needed, how can we fix the package so that it builds on buildbots? CCing to Lucas, because he has some experience with these kinds of problems. Thanks, Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: permission denied when creating a directory for a new project
On Nov 13, 2007 6:35 AM, Bernd Zeimetz [EMAIL PROTECTED] wrote: Ondrej Certik wrote: I get the impression that you want to package some math software... just forgot the name :) Let me know if you need help. libmesh. The packages are here: ah ok, I though about http://www.sagemath.org/ Well, I am actually at the SAGE conference in Bristol right now. But SAGE is really huge and I don't think the time has come to package it in Debian yet. SAGE is packaging a lot of external packages together with SAGE patches to make them compile and play nicely. Two days ago we did a quick check which packages in SAGE are in Debian and which are not: http://wiki.sagemath.org/days6/sprint/debian And there are 24 packages, that are not yet in Debian. And that's not the biggest problem - the biggest problem is that SAGE needs some packages to be patched, like Maxima. So the first step would be to get those patches to the respective Debian packages, the maintainer of which doesn't need to accept them etc. So it's a very slow process and too much for 1 or two people to do. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
permission denied when creating a directory for a new project
Hi, I want to package cython in the PAPT team and I am getting: $ svn mkdir svn+ssh://[EMAIL PROTECTED]/svn/python-apps/packages/cython/ Committed revision 211. Warning: 'post-commit' hook failed with error output: Use of uninitialized value in concatenation (.) or string at /srv/home/groups/pkg-perl/scripts/qa/DebianQA/Config.pm line 21. Error opening cache: Permission denied am I doing something wrong? Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: permission denied when creating a directory for a new project
On Nov 12, 2007 10:47 PM, Ondrej Certik [EMAIL PROTECTED] wrote: Hi, I want to package cython in the PAPT team and I am getting: $ svn mkdir svn+ssh://[EMAIL PROTECTED]/svn/python-apps/packages/cython/ Committed revision 211. Warning: 'post-commit' hook failed with error output: Use of uninitialized value in concatenation (.) or string at /srv/home/groups/pkg-perl/scripts/qa/DebianQA/Config.pm line 21. Error opening cache: Permission denied am I doing something wrong? And this is what I get when committing to the mayavi2 package: $ svn ci -m applying Prabhu's changes Sendingdebian/control Sendingdebian/copyright Sendingdebian/rules Transmitting file data ... Committed revision 212. Warning: 'post-commit' hook failed with error output: Use of uninitialized value in concatenation (.) or string at /srv/home/groups/pkg-perl/scripts/qa/DebianQA/Config.pm line 21. Filesystem has no item: File not found: revision 212, path '/packages/cython/trunk' at /srv/home/groups/pkg-perl/scripts/qa/DebianQA/Svn.pm line 96 So I think something is wrong with the PAPT svn repository. Note that committing to the DPMT repositories works just fine. Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: permission denied when creating a directory for a new project
I get the impression that you want to package some math software... just forgot the name :) Let me know if you need help. libmesh. The packages are here: http://debian.certik.cz/ but they still need some work, before they could be uploaded to unstable. not you, but Tincho - adding him to the loop :) But the directory was created just fine. Awesome. :) btw, svn-inject can take care of creating the directory, too. Yeah, I know, but I just prefer to do it by hand. Thanks for a reply, Ondrej -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Python Egg Guidelines across distros
On 9/10/07, Josselin Mouette [EMAIL PROTECTED] wrote: Le vendredi 07 septembre 2007 à 22:53 +0200, Stefano Canepa a écrit : do you mean using setuptools upstream is bad for the resulting debian package? Could you explain why? Setuptools was designed by developers, for developers, and not much for users. More specifically, it was designed for developers working on a certain operating system which doesn't have a decent packaging infrastructure. [] I am forwarding a relevant opinion from a mayavi2, traits mailinglist (I am doing the packaging of mayavi2 and traits for Debian). Ondrej -- Forwarded message -- From: Gael Varoquaux [EMAIL PROTECTED] Date: Sep 10, 2007 1:23 PM Subject: Re: [Enthought-dev] why setuptools and eggs are bad To: [EMAIL PROTECTED] On Mon, Sep 10, 2007 at 12:26:18PM +0200, Ondrej Certik wrote: this debate on debian-python mailinglist could be interesting for you (see also all related messages): http://people.debian.org/~terpstra/message/20070910.084442.11816b2b.en.html Interesting. These guys have been stumbling on the same issues than us for packaging. To sum up, the problem is that setup tools is not designed to interact with the outside world. It does not provide an api for listing dependencies, does all kind of magic during the install, and insists for doing everything itself, and not exposing the info it has to the external world. This is bad because the way it is doing things may not fit with a certain platform's need and existing packaging system. Actually setuptools is designed with Windows in mind. Now my work around for packaging ETS has been the coarse-grained source tarballs: I have a script that inspects the dependencies of an egg, downloads them (this script was an absolute pain to write, and is fragile, as setuptools does not expose a proper API for all these things, and there is a lot of guess work to do). It can be enhanced to build a partial dependency tree (why the hell is it something that we should do, setuptools must be doing this, I want this info exposed !). Once the packages downloaded, the dependency tree built, tarballs can be created with the relevant info, and I can group the packages, in the case of the ETS. This script should be enhanced to gather the info to make a real .deb, and expose the relevant info (package description, version, ...) to another packaging system. I also totally strip the Python source from anything relevant to setuptools, this way I am sure there is not setuptools introduced magic in them. Setuptools is only a build requirement. Incidentally, this is somewhat similar to Andrew Straw's stdeb, expect it focuses on downloading and grouping packages. If you want to forward this mail to the relevant mailing list (debian-python, setuptools) go for it. I am happy discussing my conclusions and providing my hackish script to who ever wants it. I wont go myself on these lists because I don't like complaining without providing a solution, and I don't have time to look at the problem more in details. There is a problem, though, and setuptools guys should be aware of it and try to address it quickly, elsewhere they will have the community of packagers more and more angry at them. One of the conclusions of the debian-python thread Ondrej points to is that upstream maintainers should be discouraged to use setuptools. Gaël ___ Enthought-dev mailing list [EMAIL PROTECTED] https://mail.enthought.com/mailman/listinfo/enthought-dev
PMPT membership
Hi, I'm the current maintainer (and also an upstream author) of the sympy debian package, that is waiting in the NEW queue (thanks to Piotr Ożarowski for sponsoring it). I would like to join the the Python Molules Packaging Team to maintain this and help with other packages if possible. For example I would like to do the python bindings for the petsc library. My alioth userid is certik-guest. Thanks Ondrej Certik
