at a time). If
> you get rid of it, they are back to the crappy situation we were at a
> year ago.
The private extensions situation has never been more crappy, and having
"current" in a control field is not going to make it suck less.
--
.''`. Josselin Mouette
sn't contain any modules named gmLog
or GmCLI. So this is an expected result :)
--
.''`. Josselin Mouette/\./\
: :' : [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
`- Debian GNU/Linux -- The power of freedom
signature.asc
Description: Ceci est une partie de message numériquement signée
s. Now there's just
another good reason not to do so.
--
.''`. Josselin Mouette/\./\
: :' : [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
`- Debian GNU/Linux -- The power of freedom
signature.asc
Description: Ceci est une partie de message numériquement signée
Le jeudi 10 août 2006 à 07:09 +0200, Andreas Tille a écrit :
> On Wed, 9 Aug 2006, Josselin Mouette wrote:
>
> > As Gnumed doesn't ship a .pth file, the .path doesn't need to be
> > updated.
>
> Well, I did so in 0.1 packages but was unsure whether this might
changes its functionality in some
> way.
You are 100% right. I will change the script to add the python
dependency even when there is a dependency on python-support.
--
.''`. Josselin Mouette/\./\
: :' : [EMAIL PROTECTED]
`. `'
has
> been added during my NMU as it was a wishlist that I found useful (so -X
> isn't widely used).
Yes, we can check for the few packages using it.
--
.''`. Josselin Mouette/\./\
: :' : [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
`- Debian GNU/Linux -- The power of freedom
signature.asc
Description: Ceci est une partie de message numériquement signée
; > beats me to it).
>
> You're right. However there's no point in changing that now, until we have
> a proper plan to get rid of dh_python completely and replacing it with
> another common infrastructure to generate the ${python:*} substitutions.
> I tried to propose o
al, sorry. As long as these fields don't
even have clear semantics, implementing them is, at best, useless.
> without offering any alternative
> suitable for mass-detection of binNMU candidates.
What if I provide you with a script that does the same without the
fields?
--
.''
change their packages
to add (among other things) fields with unclear definition and
questionable usefulness. With the net result of having several
maintainers stepping back from maintaining python packages because they
find it too complicated.
--
.''`. Josselin Mouette
release schedule.
--
.''`. Josselin Mouette/\./\
: :' : [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
`- Debian GNU/Linux -- The power of freedom
intained, but it has also
discouraged some maintainers who thought they needed more time to
understand the "new policy".
--
.''`. Josselin Mouette/\./\
: :' : [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
`- Debian GNU/Linux -- The power of freedom
by removing
the /usr/lib/python2.X/site-packages/bzrlib/plugins/bzrtools
directories.
--
.''`. Josselin Mouette/\./\
: :' : [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
`- Debian GNU/Linux -- The power of freedom
> So my proposal is to make XS-P-V mandatory when there is an upper bound.
Beware of one thing: having both XS-P-V and pyversions is the worst case
we can have, as the maintainer has to ensure they contain the same
information.
--
.''`. Josselin Mouette/\./\
: :&
ng to see if a new version would be available soon, but I need
> another solution for now.
Sorry, this python-support update went completely out of my mind. I've
just uploaded it.
--
.''`. Josselin Mouette/\./\
: :' : [EMAIL PROTECTED]
`. `'
on't think this is an issue, as python-support
> will bytecompile for all supported versions, but what about testing
> installation under an unsupported version (like 2.5 is now)?
I guess it would work by adding it to /usr/share/python/debian_defaults.
Cheers,
--
.'
upport which has this
requirement. I think this is rather a bug in python. The preinst calls
the hooks, while the pyversions.py script is held in python-minimal, and
there is no Pre-Depends: on python-minimal.
--
.''`. Josselin Mouette/\./\
: :' : [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
`- Debian GNU/Linux -- The power of freedom
ed out later that the fields had unclear specifications and could
only be used by python-central itself.
There is at least a lesson to retain: the BoF itself was a bad idea from
the beginning. I hope people won't make again the mistake to define
policies in a meeting.
--
.''
ce. You will not put my name on another so-called consensus.
--
.''`. Josselin Mouette/\./\
: :' : [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
`- Debian GNU/Linux -- The power of freedom
signature.asc
Description: Ceci est
eature :)
If you want to just ship some .py files manually, the simplest way is
probably to install them to /usr/share/python-support/$package instead
of /usr/lib/python2.X/site-packages.
Cheers,
--
Josselin Mouette/\./\
"Do you have any more insane proposals for me?"
sig
t; As such, maybe it's worth supporting.
As /usr/lib/python is not part of the default python path, I doubt
upstream packages would install anything in this directory. All python
installation helpers (distutils, automake, setuptools)
use /usr/lib/python2.X instead.
--
Josselin Mouette
Le jeudi 30 novembre 2006 à 15:35 +0100, Raphael Hertzog a écrit :
> Matthias's goal has always been to get rid of python2.3 completely.
Please, don't change the past.
--
Josselin Mouette/\./\
"Do you have any more insane proposals for me?"
Le mercredi 03 janvier 2007 à 09:58 +0100, Vincent Danjean a écrit :
> Hi,
>
> I'm the maintainer of mercurial. At least one of the users has a
> problem with loading python modules.
> Can someone look at bug #382252 ?
>
> In short,
> echo 'import sys; print sys.path; from mercurial impor
By the way I also noticed there is a direct symbolic link
in /var/lib/python-support to your templates directory, while support
for such links in /usr/share/python-support was added (on your
request :) in 0.4.3.
Last but not least, you should use python instead of python2.4, now that
2.4 is the de
Le mercredi 31 janvier 2007 à 14:15 -0600, Carlo Segre a écrit :
> Hello All;
>
> Section B.2 of the Python Policy shows a code snippet that indicates you
> need to use dh_python after dh_pycentral. According to the dh_python man
> page it is deprecated so this should be changed.
>
> In additi
When discussing the "new" python policy at debconf, one of the
interesting points that were raised is the need to set explicit
dependencies for all virtual python2.X-foo packages you need.
Let's consider the pygtk example: python-gtk2 depends on python-gobject,
and provides python2.4-gtk2. If you
Le samedi 17 février 2007 à 17:51 +0100, Loïc Minier a écrit :
> On Sat, Feb 17, 2007, Josselin Mouette wrote:
> > As the first python2.5 rebuild tests showed, this is likely to hit us
> > hard during the 2.4 -> 2.5 transition, and it is going to rain RC bugs.
>
> Which
Le mercredi 21 février 2007 à 11:12 -0800, Steve Langasek a écrit :
> OTOH, I also don't see why it's important to avoid
> removal of zope2.7 on upgrade, it /is/ an obsolete package from the etch
> perspective.
This can be the case only if there is a smooth and automated transition
from zope2.7 to
Le mercredi 14 mars 2007 à 09:48 +0100, Raphael Hertzog a écrit :
> > I have some idea about doing each of those, but no real clues about
> > packaging for both Python's Cheeseshop and a Debian package
> > simultaneously. Where should I start learning about the issues and
> > recommendations?
>
>
Le lundi 19 mars 2007 à 23:44 +0100, Raphael Hertzog a écrit :
> === modified file 'debian/rules'
> --- debian/rules2007-03-19 06:44:04 +
> +++ debian/rules2007-03-19 22:37:56 +
> @@ -46,7 +46,6 @@
> install: build ${PYVERS:%=install-python%}
> dh_testdir
>
Hi,
I think it's time to update the python policy with the progress that has
been made in how we build python packages. The proposed diff is
attached. In summary it includes:
* the deprecation of the "current" keyword;
* making Provides: meaningful in the case of inter-module
d
Le mercredi 21 mars 2007 à 20:22 +0100, Josselin Mouette a écrit :
> I think it's time to update the python policy with the progress that has
> been made in how we build python packages. The proposed diff is
> attached. In summary it includes:
> * the deprecation of the
Le mercredi 21 mars 2007 à 14:44 -0700, Steve Langasek a écrit :
> On Wed, Mar 21, 2007 at 08:22:32PM +0100, Josselin Mouette wrote:
>
> > I think it's time to update the python policy with the progress that has
> > been made in how we build python packages. The proposed d
Le mercredi 21 mars 2007 à 14:51 -0700, Steve Langasek a écrit :
> On Wed, Mar 21, 2007 at 10:47:37PM +0100, Josselin Mouette wrote:
> > If this is a public extension, this goes completely against the spirit
> > of the policy and should not be allowed. It just means more package
Le mercredi 21 mars 2007 à 15:51 -0700, Steve Langasek a écrit :
> > If we don't, I don't see the purpose of the policy alltogether.
>
> Allowing transitions between default versions of python without package
> renames, bypassing NEW, allowing binNMUable transitions, and generally
> simplifying
Le jeudi 22 mars 2007 à 00:06 +0100, Thomas Jollans a écrit :
> There is also the option of only having one in the distribution, which should
> be PySyck for having more features. This would mean chucking the official
> binding out of debian, which I am not entirely comfortable with either.
If i
Le jeudi 22 mars 2007 à 16:12 +1100, Ben Finney a écrit :
> Pierre Habouzit <[EMAIL PROTECTED]> writes:
>
> > Why would you prevent the user to bytecompile your package for every
> > python version he choose to install ? I see the point to avoid archive
> > bloat in not building every binary exte
Le mercredi 21 mars 2007 à 19:13 -0700, Steve Langasek a écrit :
> You implemented a tool that *ignored* some of the use cases that went into
> the initial policy, among them the case for 'current'.
This is wrong. Python-support doesn't rely on anything else than what
the maintainer chooses to bui
Le jeudi 22 mars 2007 à 14:50 +0100, Pierre Habouzit a écrit :
> exactly, putting current is just yet-another-place where the
> maintainers declares that he will only prepare the package for "current"
> python. And you're right, python-(all-?)-dev is a already here to give a
> hint to the dh_tool
Le jeudi 22 mars 2007 à 19:56 +0100, Pierre Habouzit a écrit :
> > Just nitpicking: the dh_ tool doesn't need to know that, as it can guess
> > it from what was previously built. This is a hint for the release
> > managers (to know which packages need a binNMU), and could be the base
> > for a scri
Le vendredi 23 mars 2007 à 13:40 +0100, Piotr Ożarowski a écrit :
> XB-Python-Type: "multiple" (compile for all installed [and supported by
> the package] Python versions) or "single" (only for one Python version)
>
> That looks good to me
And how do you ensure that this matches what's actu
While the discussion is still ongoing about the "current" keyword, it
seems that everyone agrees with the other changes which are only loosely
related. Can we proceed with these, until we agree on how "current"
should be replaced?
--
.''`.
: :' : We are debian.org. Lower your prices, surren
Le dimanche 06 mai 2007 à 10:25 +0200, Pierre Habouzit a écrit :
> > also trac wants *.egg files in /usr/share/trac/plugins,
> > that seems to be very far off the debian python policy.
>
> Well, hell no ! I don't think it's against the policy at all:
> /usr/share/trac/plugins is a private module
Le mardi 08 mai 2007 à 05:57 -0400, Kevin Coyner a écrit :
> Is this not an issue with any other python package? Still thinking
> of reassigning this bug ...
It looks like an issue in distutils indeed. The file is opened in ASCII
mode, which doesn't allow for writing Unicode text inside.
You shou
Le samedi 12 mai 2007 à 18:06 -0300, Gustavo Noronha Silva a écrit :
> Hello!
>
> python-support 0.6.4 includes code to automatically rename egg-info
> directories in order to remove the python version number from their
> name. This is a most welcome adition, IMO, since now we have shared code
> h
Le lundi 25 juin 2007 à 20:17 +0200, Carlos Galisteo a écrit :
> Upstream source is released under the CNRI Python License [2] but AFAIK,
> the DFSG compliant 'Python License' is the PSF [3] one.
>
> As you can read in the PSF license full text, there's a controversy about
> the CNRI (1.6.1) co
think you need listen to anything the setuptools developers say,
as they have close to zero understanding of the packaging issues they
create for us.
--
.''`. Josselin Mouette/\./\
: :' : [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
`- Debian GNU/Linux -- The power of freedom
signature.asc
Description: Ceci est une partie de message numériquement signée
ebian, the maintainer will have to patch it to remove or
downgrade the egg dependency. If it is not, users will just be screwed.
--
.''`. Josselin Mouette/\./\
: :' : [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
`- Debia
g issues they
> > create for us.
> >
> Heh, I know how you feel but I try to resist giving in to it since we're
> going to be living in a world with setuptools for the foreseeable future
> and we'll all have to learn to communicate and compromise in pursuit of
>
aluable one for the distributor.
--
.''`. Josselin Mouette/\./\
: :' : [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
`- Debian GNU/Linux -- The power of freedom
signature.asc
Description: Ceci est une partie de message numériquement signée
to add it with sys.path.append("/the/path") at the
beginning of the binary.
If, as the location suggests, they are public, you should look at the
setup.py file to see if there's something unusual that would install the
modules in this unusual location.
--
.''`.
; Hmm. I am hoping that "modify the programs" is not a necessary part of
> this.
If upstream hasn't thought of it, it is. You only need to add one line
in the program, before the module is imported.
Cheers,
--
.''`. Josselin Mouette/\./\
: :' :
see how any Python program can be written to
> allow for that without modification every time the "/foo/bar" changes.
Distutils may be extended to do such a thing, but most of the software
I've seen doing it is using automake or changing the files with custom
hackery.
--
.'&#x
ibavg
miro
python-visual
pythonmagick #445395
A status of all opened bugs can be found here:
http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=python2.5;[EMAIL PROTECTED]
Thanks for reading.
--
.''`. Josselin Mouette/\./\
: :' :
o excuse.
A 0-day NMU policy is indeed a bit too much for such packages; it would
be nice to have them fixed, but it should be done in agreement with the
maintainer.
--
.''`. Josselin Mouette/\./\
: :' : [EMAIL PROTECTED]
`. `'
in a day. If, by the
time that is required to come to switch python 2.5, the toolchain still
isn't fixed, that will say much about the state of the mips port.
--
.''`. Josselin Mouette/\./\
: :' : [EMAIL PROTECTED]
`. `'
Le vendredi 05 octobre 2007 à 20:04 +0200, Josselin Mouette a écrit :
> The following packages should also work with python2.5 after a round of
> binNMUs, as some dependencies were relaxed in python-support 0.7.4:
> dia
> exaile
> k3d
You can add:
mo
Le samedi 06 octobre 2007 à 09:07 +0200, Josselin Mouette a écrit :
> Le vendredi 05 octobre 2007 à 20:04 +0200, Josselin Mouette a écrit :
> > The following packages should also work with python2.5 after a round of
> > binNMUs, as some dependencies were relaxed in pytho
Le samedi 06 octobre 2007 à 12:21 +0200, Bernd Zeimetz a écrit :
> > Sorry , but there is a very good reason to do so: If the default python
> > version changes running applications with mod-wsgi will badly fail.
> > Therefore it depends in a relaxed way (python <<2.5, but >=2.4) on the
> > actual
Le samedi 06 octobre 2007 à 13:26 +0200, Bernd Zeimetz a écrit :
> I indeed didn't know about rtupdate - it seems to be missing on
> http://www.debian.org/doc/packaging-manuals/python-policy/
As some changes that were accepted 7 months ago have still not been
integrated into the policy, I wouldn't
ble goal, but not when done at the expense of proper
support of operating systems which have one.
--
.''`. Josselin Mouette/\./\
: :' : [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
`- Debian GNU/Linux -- The power of freedom
Still, it would be nice to build extensions for all python versions, but
the fact they are private makes this process more complicated.
--
.''`. Josselin Mouette/\./\
: :' : [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
`- Deb
Le jeudi 11 octobre 2007 à 14:44 -0400, Aaron M. Ucko a écrit :
> Josselin Mouette <[EMAIL PROTECTED]> writes:
>
> > Still, it would be nice to build extensions for all python versions, but
> > the fact they are private makes this process more complicated.
>
> ... p
Le vendredi 12 octobre 2007 à 22:40 -0700, Steve Langasek a écrit :
> Is there code available that can be used to reproduce this list from
> Packages/Sources? I would very much prefer to be able to generate an
> authoritative list of per-arch binaries that need to be binNMUed, so that
> the progre
Le samedi 13 octobre 2007 à 18:29 +0200, Bernd Zeimetz a écrit :
> > Given the number of packages that don't follow the policy or declare
> > wrong values in XS-Python-Version, for most packages it was possible to
> > decide only by looking at debian/rules by hand.
>
> Policy does not require to s
Hi,
Le lundi 15 octobre 2007 à 16:49 +0200, Sandro Tosi a écrit :
> Hi Dirk,
>
> > GPU programming from Python:
> > http://www.cs.lth.se/home/Calle_Lejdfors/pygpu/
> >
> > Looks promising, but I still don't really speak Python. Anybody with more
> > skills and some free time interested i
Hi,
Le lundi 05 novembre 2007 à 15:40 +0100, Piotr Ożarowski a écrit :
> Hi Fabrizio
>
> > I am looking for sponsorship for my new python module: python-avc,
> >ITP http://bugs.debian.org/448646,
> >mentors http://mentors.debian.net/debian/pool/main/p/python-avc.
>
> * remove "Provides:
Le mardi 06 novembre 2007 à 00:22 +0100, Bernd Zeimetz a écrit :
> Please get the _official_ Python Policy fixed and such requirements
> included if you like to have them.
The official Python policy is currently unmaintained.
--
.''`.
: :' : We are debian.org. Lower your prices, surrender
Le lundi 05 novembre 2007 à 23:57 +0100, Piotr Ożarowski a écrit :
> > > * remove "Provides: ${python:Provides}" - architecture independent
>
> > > packages don't need it
> >
> > Of course they do. What if a package Depends: py
Le mardi 06 novembre 2007 à 01:25 +0100, Bernd Zeimetz a écrit :
> Josselin Mouette wrote:
> >>> Of course they do. What if a package Depends: python2.5, python2.5-avc?
> >> Depends: python2.5, python-avc (>=new_policy_version)
> >
> > Sorry, but that d
Le mardi 06 novembre 2007 à 05:20 +0100, Bernd Zeimetz a écrit :
> Matthias Klose wrote:
> > proposed policy changes should
> > be filed as bug reports against python-defaults.
What is the point of having this list if it cannot even be used for
discussing policy changes?
You still haven't added t
Le mercredi 19 décembre 2007 à 10:03 +0100, Ondrej Certik a écrit :
> 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 th
Le vendredi 04 janvier 2008 à 00:11 +0100, Piotr Ożarowski a écrit :
> * Provides: ${python:Provides} is not really needed (sorry Joss)
You don’t need to be sorry, I’m the first one to say we should remove
them in many cases ;) They introduce the need for Python-Depends, which
is frankly not the m
Le lundi 07 janvier 2008 à 07:56 +0100, Vincent Bernat a écrit :
> Well, if you can change the order for postinst, you will get wrong order
> in prerm.
debhelper (5.0.44) unstable; urgency=low
* prerm and postrm scripts are now generated in a reverse order than
preinst and postinst scripts.
Le mercredi 16 janvier 2008 à 00:31 +0100, Eike Nicklas a écrit :
> * Which value should the XS-Python-Version field have to ensure easy
> transitions of future Python versions? I tried using 'all', but then
> my (binary) package depended for example on python2.3-gtk2,
> python2.4-gtk2 and py
Hi,
Le samedi 23 février 2008 à 22:45 -0600, Steve M. Robbins a écrit :
> One idea is to use a user-config.jam file containing
>
> using python : 2.4 : /usr ;
> using python : 2.5 : /usr ;
>
> Then run jam twice
>
> bjam variant= ...
> bjam variant= ... python python=2.5
Le mardi 26 février 2008 à 22:04 -0600, Steve M. Robbins a écrit :
> The idea is to create a single -dev package that contains the
> following in /usr/lib:
>
> libboost_python-py24-gcc42-1_34_1.so
> libboost_python-py24-gcc42-1_34_1.a
>
> libboost_python-py25-gcc42-1_34_1.
On mer, 2008-04-02 at 12:04 -0500, Steve M. Robbins wrote:
> The sequence shown in the build log indicates that no python-dev
> package is installed at all. This is due to another change made to
> support multiple python runtimes. The libboost-python-dev package
> used to depend on python-dev. N
On ven, 2008-04-04 at 10:48 -0500, Steve M. Robbins wrote:
> I was hoping is that if python is subsequently installed, that python
> itself would run the rtupdate scripts. This doesn't seem to be the
> case. Should it be? If not, how should I handle the situation where
> libboost-dbg is installe
On ven, 2008-04-04 at 19:08 -0500, Steve M. Robbins wrote:
> When Python is subsequently installed, the rtupdate scripts of all
> previously-installed packages should be run.
>
> Sound reasonable? Shall I file a bug to this effect? On python?
I think it is definitely reasonable, and you can fil
On lun, 2008-04-14 at 00:52 +0100, Serafeim Zanikolas wrote:
> I'm packaging a set of pure python modules (ITP #473039), which are part of a
> single module and share a few common files. So in /usr/share/python-support/
> we have:
>
> python-nodebox-web/nodebox_web/web/ (files required by all
On lun, 2008-04-14 at 22:57 +0200, Adeodato Simó wrote:
> Finally, and quite importantly, there is what to do with modules that
> have been added to the standard library in 2.5 (ctypes, celementtree,
> wgsiref). These use either pycentral or pysupport, and since they mark
> themselves as for python
On mar, 2008-04-15 at 12:46 +0200, Piotr Ożarowski wrote:
> [Josselin Mouette, 2008-04-15 12:32]
> > The solution is really simple, just add them to python’s Provides: list.
>
> python2.5 package already does that
But python does not:
Provides: python-email, python-xmlbase
>
severity 476229 critical
retitle 476229 rtupdate scripts not run during transition to python2.5
reassign 476229 python 2.5.2-0.1
thanks
Le jeudi 17 avril 2008 à 16:50 +0200, Loïc Minier a écrit :
> Thanks (please tell the bug); someone please try to find out why the
> rtupdate script isn't called
Le mardi 13 mai 2008 à 16:35 +0100, Sam Morris a écrit :
> Python-knowledgeable people: I seem to have uncovered a bug specific to
> python 2.5. Could you please take a look at #481071 and advise how to go
> about tracking it down?
>
> The bug can be reproduced with python 2.5 but only on Debian s
Le mercredi 14 mai 2008 à 00:32 +0200, Josselin Mouette a écrit :
> Le mardi 13 mai 2008 à 16:35 +0100, Sam Morris a écrit :
> > The bug can be reproduced with python 2.5 but only on Debian systems--on
> > an Ubuntu 8.04 system the code does not throw an error. Please try th
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 latt
Le lundi 19 mai 2008 à 14:39 +0200, Michal Čihař a écrit :
> What surprised me is different handling of XB-Python-Version field. I
> have XS-Python-Version: current and python-central makes
> XB-Python-Version: current from this, what I feel is correct (package
> is pure Python, no dependency on Py
Le mardi 20 mai 2008 à 00:45 +0200, Pierre Habouzit a écrit :
> This is _wrong_ to put XB-PV: 2.4, 2.5 for an arch:all package, this
> should be XB-PV: all or something similar.
Indeed, dh_pysupport puts wrong values in XB-Python-Version, so this is
a bug. A very minor one, since this informatio
Le lundi 19 mai 2008 à 19:22 +0100, Floris Bruynooghe a écrit :
> > The latter approach is less fragile overall,
>
> How is that? As far as I can see both python-central and
> python-support maintain directories for each python version and
> symlink the .py files to a shared location. Just on th
Le mercredi 21 mai 2008 à 08:59 +1000, Ben Finney a écrit :
> I don't see that it leads to storing the compiled programs to live
> under /var/, rather than /usr/ which to my mind is more appropriate
> for compiled versions of programs installed by the package manager,
> which don't change except th
Le samedi 31 mai 2008 à 22:00 +0200, Manuel Prinz a écrit :
> I have a Python application with private extension modules, so the package is
> Arch: any. Because there is no way (at least I'm not aware of that) to split
> the package because the modules are private, I can't seperate the large part
Le lundi 25 août 2008 à 00:03 +0200, Eike Nicklas a écrit :
> c) Depends: python (>=2.4), python-elementtree
> (does python2.5 provide python-elementtree?)
It does not, which is a bug, since this option should be the correct
one.
--
.''`.
: :' : We are debian.org. Lower your prices, surren
Le lundi 25 août 2008 à 21:13 +0200, Vincent Bernat a écrit :
> OoO Pendant le journal télévisé du lundi 25 août 2008, vers 20:42, je
> disais:
>
> > import sys,new,os; p = os.path.join(sys._getframe(1).f_locals['sitedir'],
> > *('recaptcha',)); ie = os.path.exists(os.path.join(p,'__init__.py'
Le mercredi 27 août 2008 à 14:57 +0100, Simon McVittie a écrit :
> On Wed, 27 Aug 2008 at 13:07:19 +0200, Josselin Mouette wrote:
> > It does not, which is a bug, since this option should be the correct
> > one.
>
> I don't think that's actually correct,
Le mercredi 27 août 2008 à 19:21 +0200, Vincent Bernat a écrit :
> OoO Peu avant le début de l'après-midi du mercredi 27 août 2008, vers
> 13:12, Josselin Mouette <[EMAIL PROTECTED]> disait :
>
> >> > import sys,new,os; p =
> >> > os.
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
Le vendredi 29 août 2008 à 19:51 +0200, Vincent Bernat a écrit :
> > Could you please test the python-support package at
> > http://malsain.org/~joss/debian/ to see whether it handles this case
> > correctly?
>
> Yes, this works correctly with this version.
OK, uploaded to unstable.
> The init
Le lundi 29 septembre 2008 à 15:12 +0200, Nicolas Chauvat a écrit :
> Here is where we stand today:
> http://mail.python.org/pipermail/distutils-sig/2008-September/010126.html
This looks like a step in the right direction if we want to generate
inter-module dependencies.
Most things defined in th
Le mercredi 24 décembre 2008 à 00:48 +0100, Ondrej Certik a écrit :
> Imho if we are going to only version the debian dir, then I also don't
> see such a strong argument for git (or other distributed vcs). Since
> it will still need to fiddle with upstream tarball and also with
> debian/patches + q
Le lundi 02 février 2009 à 22:35 -0500, Yaroslav Halchenko a écrit :
> why in a hackish site.py those /usr/local paths are added?
Because we want to follow the FHS, which is all but hackish - but
Python, in many ways, doesn’t make it easy.
The real question is more: why aren’t these paths correc
1 - 100 of 353 matches
Mail list logo
