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: Request for review - Charm 1.9.1
FTR: this package is already uploaded (after few more changes) pgpB2DeZbw0HL.pgp Description: PGP signature
Re: Python related changes for unstable/squeeze
Joss, although I'm more than happy that you fixed bug I reported
(#478178) and you implemented the "pyshared" feature, please wait with
implementation next time until both of you will agree to do something
(to avoid unnecessary work). Let me just cite a DD who told me once to
"hold on your horses, Piotr". Once we'll move to LEVEL 2 (see below),
you'll have to reimplement maintainer scripts again, and that will be
frustrating for sure.
Mathias, please reply to my stupid and ignorant questions. All I want is
to give our users best possible option so f.e. if you'd propose to keep
python2.5 in supported, I'd ask why the heck should we have so many
Python versions in Debian and is it possible to provide to all who
use python2.5 in their applications an alternative (but still smooth)
upgrade path.
So...
We're still at LEVEL 1 (common location for .py and .so files) as
Matthias didn't agree to to use /usr/lib/py{,3}shared. He said that he
see no advantages in using separate directory for .so files, but he also
didn't refuse to use one...
*If* we'll find a consensus here, we'll move to LEVEL 2. I'll shortly
describe what level 2 will be about below, but please don't reply to
this part of my mail until LEVEL 1 will be completed (there will be
punishment for a falstart, I'll ask Ana to propose one as womens are good
at tortures (/me read "Sword of Truth" recently ;)) [yeah, that's a
tricky way to lead flame war astray, so we can discuss in peace ;]
Again, think about your arguments now as it will be a hot ride.
LEVEL 2: common maintainer scripts ({post,pre}{inst,rm})
It will be a lot harder to find a consensus here. To avoid flames[1], I
propose to mail your opinions as list of points/ideas/{dis,}advantages
f.e. here are features that new maintainers scripts should have IMO
(we'll discuss which ones are valid and propose new ones):
* each script has to be short, few lines only if possible
* should not depend on any specific helper tool
+ same scripts in packages created by pysupport and in these created
by pycentral
+ this should help getting rid of helper dependency in future (or even
in level 2))
* python package (or new foobar package) should provide all
tools/modules needed by these scripts
+ package should depend on default helper (save thoughts about which
will be "default" for later)
* should use new dpkg feature - triggers
+ will speed up installation of new systems
+ most probably will ease dealing with various unexpected situations
(i.e. let dpkg do as much as possible and blame it later)
[1] If Mathias or Joss will not behave correctly, I'll ask Ana to kick
him in the ass and share pictures of him crying kicked by a girl ;-).
This will also have a very strong impact on my final decision so watch
your tounge^Wfingers!
If others will try to insult someone else *without* adding "please note
that I'm an asshole" I will call him an asshole (I will add that "I'm an
asshole who kicked you out of the list" so technically I will be able to
mail again) and will try to convince listmasters to block him for few
weeks - there will be no warnings, so if you want to call someone names,
make sure you'll write a lot of it - that will be your last chance to do
this.
PS Ana: do you hate me already or should I continue? ;-P
PPS Yes, I know that if everything will work out my way, decision
about my preferred tool will be irrelevant
--
-=[ Piotr Ożarowski ]=-
-=[ http://www.ozarowski.pl ]=-
pgp4H4H08RF03.pgp
Description: PGP signature
Re: Compiled bytecode files location
Josselin Mouette writes: > Le mercredi 18 février 2009 à 13:33 +1100, Ben Finney a écrit : > > I saw no response to Message-ID: <87skwceynw@benfinney.id.au> > > on this forum, but would love to be convinced this will be fixed. > > This is probably the last remaining issue keeping me with > > ‘python-central’ for my packages. > > As I already said, there is no compelling reason to stay in /var, Okay, I didn't see that when I looked back in the list archive. > and this can be changed without too much breakage - I just couldn’t > do that right before the lenny release. Sure, I was only hoping for discussion at that time, not immediate implementation of changes. > I just proposed /usr/lib/pymodules/pythonX.Y instead. Do you think > that location is suitable? I think ‘/usr/lib/foo/’ is better than ‘/var/lib/foo/’ for program libraries such as *.py and *.pyc, so to that extent it's a significant improvement. As for which directory names should be used under that hierarchy, I'm currently neutral on most proposed systems I've seen. I'm not educated enough on the issue of separation of these files to have an informed opinion yet. -- \ “Yesterday I saw a subliminal advertising executive for just a | `\ second.” —Steven Wright | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Compiled bytecode files location
On Fri, 2009-20-02 at 09:27 +1100, Ben Finney wrote: > I think ‘/usr/lib/foo/’ is better than ‘/var/lib/foo/’ for program > libraries such as *.py and *.pyc, so to that extent it's a significant > improvement. Why do you not follow FHS ? /usr/lib/fooarchitecture dependent /usr/share/foo architecture indepdendent So *.py ( and *.pyc, iirc ) should be under /usr/share. Yes: http://www.network-theory.co.uk/docs/pytut/CompiledPythonfiles.html The contents of the ‘spam.pyc’ file are platform independent, so a Python module directory can be shared by machines of different architectures. There is a semi-recent discussion about changing the format but I see no mention of breaking architecture independence. http://mail.python.org/pipermail/python-ideas/2008-April/thread.html#1549 -- --gh -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Compiled bytecode files location
Le jeudi 19 février 2009 à 18:06 -0500, Guy Hulbert a écrit : > So *.py ( and *.pyc, iirc ) should be under /usr/share. > > Yes: > http://www.network-theory.co.uk/docs/pytut/CompiledPythonfiles.html > The contents of the ‘spam.pyc’ file are platform independent, so > a Python module directory can be shared by machines of different > architectures. .py files are shipped in /usr/share, but the symlink farm has to live in /usr/lib because it also includes symlinks to binary .so files. -- .''`. Debian 5.0 "Lenny" has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and told `-me that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
