On Mon, Mar 30, 2009 at 03:27:55PM +0200, Josselin Mouette wrote:
> I also tend to prefer solutions that look more robust, for example
> against existing PYTHONPATH variables. The rest is a matter of taste.
This is (now) the relevant part in /usr/bin/gnumed:
# packages which install the GNUmed
Le lundi 30 mars 2009 à 14:50 +0200, Karsten Hilbert a écrit :
> On Mon, Mar 30, 2009 at 02:18:31PM +0200, Josselin Mouette wrote:
>
> > > - modify sys.path inside gnumed.py appropriately
> > > (which I disapprove of as it means moving
> > >platform specific code from platform specific
> > >
On Mon, Mar 30, 2009 at 02:18:31PM +0200, Josselin Mouette wrote:
> > - modify sys.path inside gnumed.py appropriately
> > (which I disapprove of as it means moving
> > platform specific code from platform specific
> > layers into platform-agnostic Python code)
>
> This one is my fa
Le lundi 30 mars 2009 à 12:26 +0200, Karsten Hilbert a écrit :
> - use Gnumed.pth in site-packages/
> (which higher wizards around here discourage us to do)
Please don’t! This completely defeats the point of shipping packages in
a private directory.
> - link /usr/share/gnumed/Gnumed into si
Le lundi 30 mars 2009 à 12:18 +0200, Karsten Hilbert a écrit :
> For what it's worth the gnumed.py outermost Python script sayeth:
>
> #!/usr/bin/env python
>
> and, then, even that is ignored because the /usr/bin/gnumed
> shell script calls gnumed.py via "python -m".
Which means using the defau
On Mon, Mar 30, 2009 at 07:27:59AM +0200, RKI Andreas wrote:
>> While it is tempting to "slip in" not strictly needed improvements into
>> a bugfix it is usually - as is quite evident here - a road down which
>> dragons live.
>>
>> Don't.
>
> Well, I didn't in the first place (look at 0.3.12 packa
On Mon, Mar 30, 2009 at 10:54:31AM +0200, Josselin Mouette wrote:
> However the document you read makes it clear that it is better,
> for python applications, to put the (private) modules in a private
> location. Both installation schemes have been available for a long time,
> and this issue is or
Le dimanche 29 mars 2009 à 20:46 +0200, Karsten Hilbert a écrit :
> I believe Andreas was wondering about the pre-compiled pyc files being
> installed alongside the py files. If they are stored there they can
> only be precompiled by one particular Python version at a time. This made
> us wonder wh
On Mon, 30 Mar 2009, Emilio Pozuelo Monfort wrote:
I think pysupport does this for you. When the default interpreter changes, it
will regenerate all the .pyc files for the new one.
This lets me relax a bit more, but hmmm, I'm not fully convinced ...
And FWIW I've just noticed that your dh_py
Andreas Tille wrote:
> On Sat, 28 Mar 2009, Emilio Pozuelo Monfort wrote:
>
>> I got an
>> error that mx.DateTime can't be imported, so you probably need to
>> depend on
>> python-egenix-mxdatetime).
>
> Thanks to Emilio I was able to fix the gnumed-client package which was
> in fact
> lacking th
Andreas Tille wrote:
> On Sun, 29 Mar 2009, Emilio Pozuelo Monfort wrote:
>
>> In that case the .pyc files won't be loaded, but the .py ones, I guess
>> (please
>> somebody correct me if I'm wrong). Nothing to worry about as people
>> will usually
>> be using the default interpreter.
>
> I admit
On Sat, 28 Mar 2009, Emilio Pozuelo Monfort wrote:
I got an
error that mx.DateTime can't be imported, so you probably need to depend on
python-egenix-mxdatetime).
Thanks to Emilio I was able to fix the gnumed-client package which was in fact
lacking the python-egenix-mxdatetime build dependenc
On Sun, 29 Mar 2009, Emilio Pozuelo Monfort wrote:
In that case the .pyc files won't be loaded, but the .py ones, I guess (please
somebody correct me if I'm wrong). Nothing to worry about as people will usually
be using the default interpreter.
I admit I really prefered the former behaviour of
On Sun, 29 Mar 2009, Emilio Pozuelo Monfort wrote:
You're missing a 'export' before setting the variable (or call python in the
same line you set it).
Uhm - stupid me. That's a beginners fault ... :-(
In the first releases of gnumed-client package I used Gnumed.pth but
dropped this since I
On Sun, 29 Mar 2009, Karsten Hilbert wrote:
-
My suggestion would be:
- call gnumed.py with the python -m ... option if that works
- this would rid us of that hardcoded path - a great thing
- leave modules where they are and GNUmed finds them by default
- if the Debian package ma
On Sun, 29 Mar 2009, Karsten Hilbert wrote:
Well, you are trying to solve two things at once:
1) make the "python -m" calling convention work
2) move GNUmed modules to a private location
While, yes, this WAS recommended in that report I tried furiously
to argue against doing both at once becau
Karsten Hilbert wrote:
>> You're missing a 'export' before setting the variable (or call python in
>> the
>> same line you set it).
>
> Ah, thanks. Emilio, you are clearly a better expert on
> packaging Python code under Debian than me :-)
That was shell ;)
>>> I really wonder how this new pyth
> >> That is, you're now shipping some modules in a private location
> >
> > This is what I understood as recommendation in #516037.
>
> Yes, that's recommended, but it's not a requirement.
>
> Anyway, you almost got it!
>
> >> (usr/share is
> >> not in PYTHONPATH), so they are not found when y
Hiya,
Andreas Tille wrote:
> On Sat, 28 Mar 2009, Emilio Pozuelo Monfort wrote:
>
>> That is, you're now shipping some modules in a private location
>
> This is what I understood as recommendation in #516037.
Yes, that's recommended, but it's not a requirement.
Anyway, you almost got it!
>> (
For what it's worth here is my concluding suggestion in that bug thread:
-
My suggestion would be:
- call gnumed.py with the python -m ... option if that works
- this would rid us of that hardcoded path - a great thing
- leave modules where they are and GNUmed finds them by default
> > That is, you're now shipping some modules in a private location
>
> This is what I understood as recommendation in #516037.
Well, you are trying to solve two things at once:
1) make the "python -m" calling convention work
2) move GNUmed modules to a private location
While, yes, this WAS rec
On Sat, 28 Mar 2009, Emilio Pozuelo Monfort wrote:
That is, you're now shipping some modules in a private location
This is what I understood as recommendation in #516037.
(usr/share is
not in PYTHONPATH), so they are not found when you try to import them.
You could ship Gnumed in /usr/share
Hi Andreas,
Andreas Tille wrote:
> Hi,
>
> I tried to implement the Python policy [1] using python-support to
> the new GNUmed packages but failed. If I try the basic essence
> of the /usr/bin/gnumed script I get:
>
> $ python -m Gnumed.wxpython.gnumed
> Traceback (most recent call last):
> F
Hi,
I tried to implement the Python policy [1] using python-support to
the new GNUmed packages but failed. If I try the basic essence
of the /usr/bin/gnumed script I get:
$ python -m Gnumed.wxpython.gnumed
Traceback (most recent call last):
File "/usr/lib/python2.5/runpy.py", line 85, in run_
@lists.debian.org, since I am not
>> subscribed to that list]
>>
>> I have been trying to ensure that my SELinux related packages which
>> have a python component are compliant with the new Python
>> policy[1]. The wiki page for the policy[2] seems to be mostly a
>> dh_p
Le jeu 27 juillet 2006 23:20, Manoj Srivastava a écrit :
> On Thu, 27 Jul 2006 14:15:47 -0500, Joe Wreschnig
<[EMAIL PROTECTED]> said:
> > Your confusion is due to an incorrect distinction. .py and .so
> > files are both modules; .so files are "extension modules" and .py
> > files are "pure Pytho
been trying to ensure that my SELinux related packages
> which have a python component are compliant with the new Python
> policy[1]. The wiki page for the policy[2] seems to be mostly a dh_python
> usage manual, and defers to dh_python to set up the variable
> substitutions correctl
compliant with the new Python
policy[1]. The wiki page for the policy[2] seems to be mostly a dh_python
usage manual, and defers to dh_python to set up the variable
substitutions correctly, so I have been trying to write up my own
manual based on the policy and reverse engineering dh_python
Package: pyro
Version: 3.5-1
Severity: important
Tags: patch
Hi Cédric,
The pyro package currently does not follow the new Python policy
(http://wiki.debian.org/DebianPython/NewPolicy), but strangely no bug
has been filed against it so far.
The attached patch fixes this, as well as the
Hello Debian Python!
I maintain python-goopy and harvestman packages, which (may) need to
be updated to conform to the new Python policy. Unfortunately, I won't
be back at my Sid machine till August, and I can't do anything about
it before that!
In any case, I thing goopy will take no
"Python Transition Mass bug" <[EMAIL PROTECTED]> writes:
> Hi, your package has been detected as generating a python
> module/extension that may need an upgrade to the new Python Policy[1].
>
> A wiki page [2] explains what has to be done to upgrade your packages
&
On Tue, 13 Jun 2006, Raphael Hertzog wrote:
> Hi,
>
> I've prepared this:
> http://wiki.debian.org/DebianPython/NewPolicy
>
> Feel free to enhance.
>
> I also converted python-pam as an example (std debhelper package):
> http://people.debian.org/~hertzog/python/examples/
>
> I'll gladly put oth
On Tue, 13 Jun 2006, Raphael Hertzog wrote:
> Now it's time to ask all maintainers to update their packages. Someone
> should prepare several list of source packages:
> - python extensions
> - python modules only
> - python apps
>
> Then we need to fill bugs, and usertag them "policy-ext", "policy
Coin,
Raphael Hertzog <[EMAIL PROTECTED]> writes:
> Now it's time to ask all maintainers to update their packages. Someone
> should prepare several list of source packages:
> - python extensions
> - python modules only
> - python apps
Fact is python-support is not yet ready for extensions, and
On Tue, 2006-06-13 at 01:14 +0200, Matthias Klose wrote:
> Joe Wreschnig writes:
> > I have updated the Python policy document based on the discussions on
> > the list. An updated DebianDoc (and HTML and text files) can be found at
> > http://people.debian.org/~piman/python-policy/.
> >
> > It:
>
Hi,
I've prepared this:
http://wiki.debian.org/DebianPython/NewPolicy
Feel free to enhance.
I also converted python-pam as an example (std debhelper package):
http://people.debian.org/~hertzog/python/examples/
I'll gladly put other examples packages at the same place. Just send them
to me.
Now
Joe Wreschnig writes:
> I have updated the Python policy document based on the discussions on
> the list. An updated DebianDoc (and HTML and text files) can be found at
> http://people.debian.org/~piman/python-policy/.
>
> It:
> 0) Removes a lot of cruft/debate from the document itself
> 1) Expl
Coin,
Matthias Klose <[EMAIL PROTECTED]> writes:
>> How about adding example for building compiled extensions? Otherwise
>> there will be used many ways to produce binaries for all supported
>> python versions.
>
> - Packaging examples
>- CDBS (not yet available)
A packaging example can be
Hi
On Mon, 12 Jun 2006 13:18:53 +0200
Raphael Hertzog <[EMAIL PROTECTED]> wrote:
> In the mean time, I can tell you that you will have to Build-Depends on
> "python (>= 2.3.5-6), python-all-dev" and that you should use `pyversions
> -r debian/control` to find out the list of python versions that
Hi
no need to CC me...
On Mon, 12 Jun 2006 12:34:18 +0200
Matthias Klose <[EMAIL PROTECTED]> wrote:
> - Packaging examples
>- CDBS (not yet available)
>- python-central
> (http://python-modules.alioth.debian.org/python-central_howto.txt)
>- python-support (http://wiki.debian.org/De
Hi,
On Mon, 12 Jun 2006, Michal Čihař wrote:
> On Mon, 12 Jun 2006 02:29:51 -0500
> Joe Wreschnig <[EMAIL PROTECTED]> wrote:
>
> > I have updated the Python policy document based on the discussions on
> > the list. An updated DebianDoc (and HTML and text files) can be found at
> > http://people.d
> How about adding example for building compiled extensions? Otherwise
> there will be used many ways to produce binaries for all supported
> python versions.
- Packaging examples
- CDBS (not yet available)
- python-central
(http://python-modules.alioth.debian.org/python-central_howto.txt)
Hi
On Mon, 12 Jun 2006 02:29:51 -0500
Joe Wreschnig <[EMAIL PROTECTED]> wrote:
> I have updated the Python policy document based on the discussions on
> the list. An updated DebianDoc (and HTML and text files) can be found at
> http://people.debian.org/~piman/python-policy/.
How about adding exa
Piotr Ozarowski writes:
> What about an Egg support? I think it's worth mentioning in policy
>
> I'm talking about:
> * --single-version-externally-managed parameter passed to
> `setup.py install` or DEB_PYTHON_INSTALL_ARGS_ALL (CDBS)
> * Egg's dirname's issue (python's/module's version in dirna
Joe Wreschnig ([EMAIL PROTECTED]):
> I have updated the Python policy document based on the discussions on
> the list. An updated DebianDoc (and HTML and text files) can be found at
> http://people.debian.org/~piman/python-policy/.
great work!
[...]
> It does not:
> 1) Cover CDBS, since I don't
I have updated the Python policy document based on the discussions on
the list. An updated DebianDoc (and HTML and text files) can be found at
http://people.debian.org/~piman/python-policy/.
It:
0) Removes a lot of cruft/debate from the document itself
1) Explains X*-Python-Version
2) Explains
Le samedi 03 juin 2006 à 01:21 +0200, Matthias Klose a écrit :
> Steve Langasek writes:
> > Indeed, the intent was that this strict upper bound would apply to
> > extensions, not to modules. Not sure if that intent got lost somewhere
> > along the way.
>
> IIRC We did conclude that we need the Pr
Le vendredi 02 juin 2006 à 16:58 -0500, Joe Wreschnig a écrit :
> What happened to "Python 2.4 first, new infrastructure later"?
Matthias disagreed with that proposal, and it was decided to push the
changes as fast as possible so that he accepts to upload python2.4
after.
--
.''`. Joss
Le vendredi 02 juin 2006 à 12:52 +0200, Raphael Hertzog a écrit :
> For applications:
> * if they use /usr/bin/python, they should simply depend on python-foo
> modules that they use.
> * if they use /usr/bin/python2.X, they should depend on python2.X-foo
> modules that they use.
And on python
On Fri, 02 Jun 2006, Joe Wreschnig wrote:
[Steve Langasek]
> > Yes, this was also discussed in the BoF, with the same conclusion: because
> > providing python2.x-foo can only be done safely if the package depends on
> > the python2.x versions of all other modules it requires, making transitions
> >
Steve Langasek writes:
> On Fri, Jun 02, 2006 at 11:50:53AM -0500, Joe Wreschnig wrote:
> > On Fri, 2006-06-02 at 12:52 +0200, Raphael Hertzog wrote:
> > > * the dependencies (hopefully created automatically by dh_python) will
> > > indicate the right interval automatically:
> > > right now for
On Fri, 2006-06-02 at 14:43 -0700, Steve Langasek wrote:
> On Fri, Jun 02, 2006 at 11:50:53AM -0500, Joe Wreschnig wrote:
> > On Fri, 2006-06-02 at 12:52 +0200, Raphael Hertzog wrote:
> > > * the dependencies (hopefully created automatically by dh_python) will
> > > indicate the right interval au
On Fri, Jun 02, 2006 at 11:50:53AM -0500, Joe Wreschnig wrote:
> On Fri, 2006-06-02 at 12:52 +0200, Raphael Hertzog wrote:
> > * the dependencies (hopefully created automatically by dh_python) will
> > indicate the right interval automatically:
> > right now for example it would be "python (>=2
Joe Wreschnig writes:
> On Fri, 2006-06-02 at 12:52 +0200, Raphael Hertzog wrote:
> > * the dependencies (hopefully created automatically by dh_python) will
> > indicate the right interval automatically:
> > right now for example it would be "python (>=2.3), python (<< 2.5)"
> > for a package
On Fri, 2006-06-02 at 12:52 +0200, Raphael Hertzog wrote:
> * the dependencies (hopefully created automatically by dh_python) will
> indicate the right interval automatically:
> right now for example it would be "python (>=2.3), python (<< 2.5)"
> for a package saying "XC-Python-Version: all"
Hello everybody,
there has (again) been some grumblings about the python transition (hi
Thomas!). The python Bof at the debconf has been successfull at deciding a
new python policy. However this policy is not implemented yet. That's what
causing this delay...
The new policy is more or les
On Tue, 2005-07-05 at 02:49, Matthias Klose wrote:
> Florent Rougon writes:
> > Sergio Talens-Oliag <[EMAIL PROTECTED]> wrote:
> >
> > > OK, then I'll take a look and see if I can write a script to support
> > > it, it
> > > seems quite simple but maybe I'm missing something...
> >
> > Befor
Matthias Klose <[EMAIL PROTECTED]> wrote:
> look at the archives. python-central is a step forward, but it doesn't
> do anything to solve the forward conflicts for python applications and
> modules outside of sys.path.
OK, thanks for the explanation.
--
Florent
--
To UNSUBSCRIBE, email to [E
Florent Rougon writes:
> Sergio Talens-Oliag <[EMAIL PROTECTED]> wrote:
>
> > OK, then I'll take a look and see if I can write a script to support it,
> > it
> > seems quite simple but maybe I'm missing something...
>
> Before you write another script, I think it would be useful to know why
Sergio Talens-Oliag <[EMAIL PROTECTED]> wrote:
> OK, then I'll take a look and see if I can write a script to support it, it
> seems quite simple but maybe I'm missing something...
Before you write another script, I think it would be useful to know why
python-central was not adopted. I have a
El Tue, Jul 05, 2005 at 12:14:00AM -0700, Donovan Baarda va escriure:
> > My proposal for those cases is simple: why don't we remove
> > /usr/lib/site-python/ from the python path and link the contents of that
> > directory on /usr/lib/pythonX.Y/site-python/ on the postinstall of pure
> > pytho
Sergio Talens-Oliag wrote:
Hello all,
I was reading the last messages to the list and I've noticed that all python
packages I have are pure python and I that I could install them for all
python versions (at least for python >=2.3), but if I install the code on
/usr/lib/site-python/ the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sergio Talens-Oliag schrieb:
> Hello all,
>
> I was reading the last messages to the list and I've noticed that all python
> packages I have are pure python and I that I could install them for all
> python versions (at least for python >=2.3),
Hello all,
I was reading the last messages to the list and I've noticed that all python
packages I have are pure python and I that I could install them for all
python versions (at least for python >=2.3), but if I install the code on
/usr/lib/site-python/ the code will only work with the
I'm the maintainer of the libming packages.
Libming has Python bindings, so i made a package python2-ming.
The Python policy has changed now, and Python 2.1 is now the default
python, so i recompiled my package.
Could someone with python experience (i havn't used python much; i don't
like the ind
> "AT" == Anthony Towns writes:
AT> Bug#119218: gnats2w 0.15.2 gnats2w 0.15.2 all
This one is orphaned upstream and is going to be removed from the
distribution. I'm waiting a bit if anyone wants it and if not then I'll
ask for its removal. I assume it has already been removed from woo
On Sun, 2001-11-25 at 10:29, Anthony Towns wrote:
> Hello,
>
> The following packages still depend: on python-base. These dependencies
> need to be fixed.
>
> Bug#118951: geas 0.0.6-2 geas 0.0.6-2 i386
> Bug#119218: gnats2w 0.15.2 gnats2w 0.15.2 all
> Bug#119230: junior-programm
> Bug#118664: omniorb 1:3.0.4-2.1 omniorb 1:3.0.4-2.1 i386
I have an NMU ready to go for omniorb that fixes this and other bugs; just
waiting for word from the maintainer (who is usually quite good with writing
back).
Ben.
--
Ben Burton
[EMAIL PROTECTED] | [EMAIL PROTECTED]
http://b
On Sun, Nov 25, 2001 at 07:29:16PM +1000, Anthony Towns wrote:
> The following packages still depend: on python-base. These dependencies
> need to be fixed.
> Bug#118695: pyching 1.0.4-3 pyching 1.0.4-3 i386
> Bug#118185: reportbug 1.36 reportbug 1.36 all
> routeplan
Hello,
The following packages still depend: on python-base. These dependencies
need to be fixed.
Bug#118951: geas 0.0.6-2 geas 0.0.6-2 i386
Bug#119218: gnats2w 0.15.2 gnats2w 0.15.2 all
Bug#119230: junior-programming 1.1 junior-programming 1.1 all
Bug#119206: luci
On 29-Oct-2001 Tom Cato Amundsen wrote:
> Has anyone started modifying lintian? If I remember correctly,
> packages that generate lintian errors will be rejected...
>
anyone is me, the maint. (-: Although any pythoners among you willing to get
dirty with perl are welcome to send patches.
> At
> "python" is a real package, no virtual one. I.e. at any given time,
> there is only one package "python" on a system (neither python1.5 nor
> python2.1 will provide "python").
Duh, okay. :)
Thanks - Ben.
* Ben Burton <[EMAIL PROTECTED]> [011029 15:46]:
>
> > > Also, someone else reported that lintian complains against
> > > Depends: python (>= 2.1), python (<< 2.2)
> >
> > This is a lintian bug. It's not bothering to notice that one's a less-than
> > and the other's a greater-than.
>
> Btw, isn't
> > Also, someone else reported that lintian complains against
> > Depends: python (>= 2.1), python (<< 2.2)
>
> This is a lintian bug. It's not bothering to notice that one's a less-than
> and the other's a greater-than.
Btw, isn't this Depends line problematic anyway? I could have python 1.5
a
On Mon, Oct 29, 2001 at 12:40:33PM +0100, Tom Cato Amundsen wrote:
> Has anyone started modifying lintian? If I remember correctly,
> packages that generate lintian errors will be rejected...
Lintian is advisory only.
> Also, someone else reported that lintian complains against
> Depends: python
Has anyone started modifying lintian? If I remember correctly,
packages that generate lintian errors will be rejected...
At the moment, lines like
Depends: python1.5
cause an error, E: python-script-but-no-python-dep
Also, someone else reported that lintian complains against
Depends: python (>= 2
76 matches
Mail list logo
