Re: python-enchant is not importable in python 2.6 on armhf. Any idea which package is at fault?
On Mon, Dec 26, 2011, peter green wrote:
According to the launchpad meta-bug the python2.7 fix was already
uploaded to
unstable. This would fit with my test succeeding with python2.7 and
failing with
python2.6
Python2.6 (ubuntu) in the launchpad meta-bug is marked as won't fix
because python2.6 is to be removed are there any plans to fix
python2.6 in
debian or do they plan to remove it like ubuntu do?
(python2.6 will eventually be removed from Debian but depending on how
long it will stay, its maintainer might opt to use the patch in this
package)
It would be best if we would patch python programs and modules to stop
using find_library.
Should a bug be opened against python-enchant? and if so what should the
package use instead of find_library?
You would file a bug against the python-enchant package or the
pyenchant source package. The code using find_library is in
enchant/_enchant.py, _e_path_possibilities() yields some pathnames
where the library should be loaded from:
def _e_path_possibilities():
Generator yielding possible locations of the enchant library.
yield os.environ.get(PYENCHANT_LIBRARY_PATH)
yield find_library(enchant)
yield find_library(libenchant)
yield find_library(libenchant-1)
if sys.platform == 'darwin':
# enchant lib installed by macports
yield /opt/local/lib/libenchant.dylib
as you can see, this doesn't encode the SONAME anywhere, so that if the
ABI / SONAME change and the old and new ones are present, a random one
will be chosen. Ideally, the code would gain awareness of the
ABIs / SONAMEs that pyenchant actually works with and do something
like:
for soname in ('libenchant.so.1', 'libenchant.so.0'):
try:
e = cdll.LoadLibrary(soname)
except OSError:
pass
if e:
break
this could be used by default for all unixish systems, but I guess
upstream would still want PYENCHANT_LIBRARY_PATH to be preferred in
some way.
(The above snippet would be used somewhere near line 119 # Not found
yet, search various standard system locations. in enchant/_enchant.py
and would try libenchant.so.1 and fall back to libenchant.so.0).
Cheers,
--
Loïc Minier
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111227181843.ga28...@bee.dooz.org
Re: RFC: Proposed updates to the Python Policy to reflect current practices
On Fri, Dec 11, 2009, Emilio Pozuelo Monfort wrote: Require the python- prefix for public modules This would mean we'd need to split e.g. python-gtk2 into five. Do we really want that? The should wording allowed one to not do it in special cases. I'm not saying we shouldn't change it, but we should make sure we're aware of all the consequences of the change... Good point; I guess we want to require the python- prefix (at least when a dependency is involved), and a recommendation to use python-foo when shipping module foo (unless shipping multiple modules, or when the module name doens't allow so (underscores for instance). -- Loïc Minier -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: Proposed updates to the Python Policy to reflect current practices
On Tue, Dec 08, 2009, Jakub Wilk wrote:
+ versions explicitely.
You could fix that typo if you are at it.
Thanks; I've spell checked the whole document and came up with the
attached patch, Spell check fixes.
--
Loïc Minier
From ee2c89e0b24b2deff74ad35d59a8ca4a9f936ecf Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Lo=C3=AFc=20Minier?= l...@dooz.org
Date: Fri, 11 Dec 2009 12:00:18 +0100
Subject: [PATCH 29/29] Spell check fixes
---
debian/python-policy.sgml | 52 ++--
1 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/debian/python-policy.sgml b/debian/python-policy.sgml
index 67e3d76..513200e 100644
--- a/debian/python-policy.sgml
+++ b/debian/python-policy.sgml
@@ -62,7 +62,7 @@
tt/usr/share/common-licences/GPL/tt in the Debian GNU/Linux
distribution or on the World Wide Web at
url id=http://www.gnu.org/copyleft/gpl.html;
- name=The GNU Public Licence.
+ name=The GNU Public License.
/p
p
You can also obtain it by writing to the
@@ -96,7 +96,7 @@
are needed by other packages, or as long as it seems
reasonable to provide them. (Note: For the scope of this
document, Python versions are synonymous to feature
- releases, i.e. Python 2.5 and 2.5.1 are subminor versions of
+ releases, i.e. Python 2.5 and 2.5.1 are sub-minor versions of
the same Python version 2.5, but Python 2.4 and 2.5 are
indeed different versions.)
/p
@@ -115,7 +115,7 @@
byte-compiled, old-versions which is the list of runtimes which
might still be on the system but for which should not be built
anymore, and unsupported-versions which is the list of runtimes
- which should not be supported at all, that is modules shouldn't be
+ which should not be supported at all, that is modules should not be
built or byte-compiled for these.
/p
p
@@ -186,11 +186,11 @@
p
Python scripts depending on the default Python version (see ref
id=base) or not depending on a specific Python version should
- use filepython/file (unversioned) as the interpreter name.
+ use filepython/file (without a version) as the interpreter name.
/p
p
Python scripts that only work with a specific Python version must
- explicitly use the versioned interpreter name
+ explicitly use the version-ed interpreter name
(filepythonvarX/var.varY/var/file).
/p
/sect1
@@ -285,7 +285,7 @@
There are three supported hook types which come in the form of
scripts which are invoked from the maintainer scripts of the
Python runtime packages when specific installations,
- uninstallations, or upgrades occur.
+ removals, or upgrades occur.
/p
penumlist
item
@@ -345,7 +345,7 @@
Python transitions. Python modules are internally very
dependent on a specific Python version. However, we want to
automate recompiling modules when possible, either during the
- upgrade itself (re-bytecompiling pyc and pyo files) or shortly
+ upgrade itself (re-byte-compiling pyc and pyo files) or shortly
thereafter with automated rebuilds (to handle C
extensions). These policies encourage automated dependency
generation and loose version bounds whenever possible.
@@ -378,8 +378,8 @@
modules are installed in a public directory as listed
in ref id=paths. They are accessible to any
program. Private modules are installed in a private directory such
- as file/usr/share/varpackagename/var/file
- or file/usr/lib/varpackagename/var/file. They are
+ as file/usr/share/varpackage-name/var/file
+ or file/usr/lib/varpackage-name/var/file. They are
generally only accessible to a specific program or suite of
programs included in the same package.
/p
@@ -446,7 +446,7 @@ XB-Python-Version: ${python:Versions}
yourself.) The format of the field ttXB-Python-Version/tt is
the same as the ttXS-Python-Version/tt field for packages not
containing extensions. Packages with extensions must list the
- versions explicitely.
+ versions explicitly.
/p
p
If your package is used by another module or application
@@ -489,11 +489,11 @@ XB-Python-Version: ${python:Versions}
/p
/sect
- sect id=bytecompilation
-headingModules Bytecompilation/heading
+ sect id=byte_compilation
+headingModules Byte-Compilation/heading
p
If a binary package provides any binary-independent modules
- (filefoo.py/file files), the corresponding bytecompiled
+ (filefoo.py/file files), the corresponding byte-compiled
modules (filefoo.pyc/file files) and optimized modules
(filefoo.pyo/file files) must not ship in the
package. Instead, they should be generated in the package's
@@ -534,7 +534,7 @@ XB-Python-Version: ${python:Versions}
begin with tt#!/usr/bin/python/tt or tt#!/usr/bin/env
python/tt (the former is preferred). They must also
specify a dependency on packagepython/package, with a
- versioned dependency
Recursive dependencies on pythonX.Y-foo practices
On Thu, Dec 10, 2009, Josselin Mouette wrote:
Rationale: let’s consider a package foo that uses python2.4 directly
(with a python2.4 shebang), and depends on python2.4-foo, provided by
python-foo, which in turn depends on python-bar. If python-bar is
rebuilt with XS-P-V: = 2.5, it will stop providing python2.4-bar, but
python-foo will not change, and will still provide python2.4-foo. Then
foo will simply stop working.
This is why the usage of pythonX.Y-foo dependencies should not be
recommended. Packages providing public modules should all be in one of
these cases:
* No Provides: ${python:Provides} at all.
* The package has no dependency on other Python modules.
* The package depends on all pythonX.Y-bar, for X.Y in
${python:Versions} and bar in all dependencies in other modules.
Since the last solution is very suboptimal (it requires simultaneous
uploads and testing migration for all entangled packages), it should be
avoided – and anyway we should discourage use of a specific pythonX.Y
version.
I agree that in general we want to avoid using a specific pythonX.Y
version in packages. I also agree that there is a problem with the
current situation which doesn't ensure that pythonX.Y-foo really works
when bar changes.
It would be ok to not have Provides: in python-foo when there is no
reverse dependency requiring a non-default python version. It makes it
harder to have a package depend on a non-default version of python-foo,
but this has to be balanced with requiring pythonX.Y-foo -
pythonX.Y-bar for all versions.
An entirely different approach is simply enforcing that at in
transitions or at the QA level:
* either ensure that we do rebuilds in the proper order when the
list of suppored version changes (rebuild python-foo before
python-bar)
* or simply have a debcheck-alike script which verifies that there is
no case of a pythonX.Y-foo dep where pythonX.Y-bar is missing
Another approach I can think of is to put the burden on the package
requiring a specific python version:
* either manage the recursive pythonX.Y-foo and pythonX.Y-bar deps
manually in the package
* or require installation of python-foo when this package gets built as
to allow computing its recursive dependencies
I don't quite like the latter, as it pulls more stuff than needed at
build time and is a bit fragile, but it does shift the problem on a
much smaller subset of packages, and doesn't prevent the rest of the
python packages to move on.
Another related issue is that of packages linking to libpython to embed
an interpreter. Most of them link to the library corresponding to the
default python version of the moment. Therefore all their dependencies
should be pythonX.Y-foo and not python-foo like what is (incorrectly)
done currently.
I aboslutely agree that these should depend on pythonX.Y for libpython
itself; it might make sense to expand their python-baz (= x) deps to
python2.x-baz, python2.y-baz, python-baz (= x), but it's not clear how
to express that the package will use this or that version of python at
run time.
For extensions, it might make sense to require all versions of all
depended upon packages.
But I'm very worried that any such change will tighten deps a lot,
while we might be able to simply catch these with more QA / cleaner
transitions.
One similar issue in Debian I have in mind is when we have two versions
of a library, and a complex set of dependencies load them together in
memory; we want to avoid this, but it's not easy to enforce via deps.
--
Loïc Minier
--
To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: Proposed updates to the Python Policy to reflect current practices
On Fri, Dec 11, 2009, Emilio Pozuelo Monfort wrote: This would mean we'd need to split e.g. python-gtk2 into five. Do we really want that? The should wording allowed one to not do it in special cases. I'm not saying we shouldn't change it, but we should make sure we're aware of all the consequences of the change... How about the new attached patch, Require the python- prefix for public modules? -- Loïc Minier From 95d0258fb8513078ccb3eb496a7867c16de4f747 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Lo=C3=AFc=20Minier?= l...@dooz.org Date: Fri, 11 Dec 2009 11:00:24 +0100 Subject: [PATCH 28/30] Require the python- prefix for public modules Require the python- prefix for packages shipping public modules used by other packages, and recommend using python-foo for public modules in general but allow for package shipping multiple modules; thanks Luca Falavigna and Emilio Pozuelo Monfort. --- debian/python-policy.sgml | 23 +++ 1 files changed, 15 insertions(+), 8 deletions(-) diff --git a/debian/python-policy.sgml b/debian/python-policy.sgml index e8d7e3a..bdbc541 100644 --- a/debian/python-policy.sgml +++ b/debian/python-policy.sgml @@ -387,14 +387,21 @@ sect id=package_names headingModule Package Names/heading p - Public modules should have a binary package named - packagepython-varfoo/var/package, - where varfoo/var is the name of the module. Such a - package should support the current Debian Python version, - and more if possible (there are several tools to help - implement this, see ref id=packaging_tools). For - example, if Python 2.3, 2.4, and 2.5 are supported, the - Python command + Public modules used by other packages must have their binary + package name prefixed with varpython-/var. It is recommended + to use this prefix for all packages with public modules as they be + used by other packages in the future. + + The binary package for module foo should preferably be named + packagepython-varfoo/var/package, if the module name + allows, but this is not required if the binary package ships + multiple modules. In the latter case the maintainer choses the + name of the module which represents the package the most. + + Such a package should support the current Debian Python version, + and more if possible (there are several tools to help implement + this, see ref id=packaging_tools). For example, if Python 2.3, + 2.4, and 2.5 are supported, the Python command example import foo /example -- 1.6.5
Re: RFC: Proposed updates to the Python Policy to reflect current practices
On Fri, Dec 11, 2009, Emilio Pozuelo Monfort wrote:
Looks fine to me, but 3.1 needs to be updated too since it currently says
that a
package that needs `foo' must depend on `python-foo', which may not be correct
anymore with this patch.
Ack
--
Loïc Minier
From ef9d6552930015aec0a9cb5a0b3d6bb5d2870f96 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Lo=C3=AFc=20Minier?= l...@dooz.org
Date: Fri, 11 Dec 2009 11:00:24 +0100
Subject: [PATCH 28/30] Require the python- prefix for public modules
Require the python- prefix for packages shipping public modules used by
other packages, and recommend using python-foo for public modules in
general but allow for package shipping multiple modules; thanks Luca
Falavigna and Emilio Pozuelo Monfort.
---
debian/python-policy.sgml | 27 ++-
1 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/debian/python-policy.sgml b/debian/python-policy.sgml
index c49957d..d9cf0dd 100644
--- a/debian/python-policy.sgml
+++ b/debian/python-policy.sgml
@@ -387,14 +387,21 @@
sect id=package_names
headingModule Package Names/heading
p
- Public modules should have a binary package named
- packagepython-varfoo/var/package,
- where varfoo/var is the name of the module. Such a
- package should support the current Debian Python version,
- and more if possible (there are several tools to help
- implement this, see ref id=packaging_tools). For
- example, if Python 2.3, 2.4, and 2.5 are supported, the
- Python command
+ Public modules used by other packages must have their binary
+ package name prefixed with varpython-/var. It is recommended
+ to use this prefix for all packages with public modules as they be
+ used by other packages in the future.
+
+ The binary package for module foo should preferably be named
+ packagepython-varfoo/var/package, if the module name
+ allows, but this is not required if the binary package ships
+ multiple modules. In the latter case the maintainer choses the
+ name of the module which represents the package the most.
+
+ Such a package should support the current Debian Python version,
+ and more if possible (there are several tools to help implement
+ this, see ref id=packaging_tools). For example, if Python 2.3,
+ 2.4, and 2.5 are supported, the Python command
example
import foo
/example
@@ -536,7 +543,9 @@ XB-Python-Version: ${python:Versions}
/p
p
If the program needs the python module ttfoo/tt,
- it must depend on packagepython-foo/package.
+ it must depend on the real package providing this module, usually
+ packagepython-foo/package but this name might vary when the
+ package ships multiple modules.
/p
sect1 id=current_version_progs
--
1.6.5
Re: RFC: Proposed updates to the Python Policy to reflect current practices
On Fri, Dec 11, 2009, Steve Langasek wrote: I think this is a policy regression, actually. The fact that /usr/bin/python2.x is a binary, and /usr/bin/python is a symlink pointing to a binary, is not irrelevant - we certainly don't want someone to get the idea that it's ok to replace either of these with a script... So I would revert the first chunk, and for the second chunk change it to: @@ -153,7 +154,8 @@ /p p At any time, the packagepython/package package must ensure - that the binary file/usr/bin/python/file is provided. + that file/usr/bin/python/file is provided as a symlink to the + current filepythonvarX/var.varY/var/file executable. The packagepython/package package must also depend on the appropriate packagepythonvarX/var.varY/var/package to Thanks, I merged something close; patch attached -- Loïc Minier From b4764801ece55036695e6d380ee5732986a0bf56 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Lo=C3=AFc=20Minier?= l...@dooz.org Date: Fri, 11 Dec 2009 10:13:52 +0100 Subject: [PATCH 26/30] Clarify which files are provided Clarify that pythonX.Y provides a /usr/bin/pythonX.Y interpreter binary and that python provides a /usr/bin/python symlink to the current pythonX.Y executable. --- debian/python-policy.sgml |8 +--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/debian/python-policy.sgml b/debian/python-policy.sgml index 804effc..7ba6a14 100644 --- a/debian/python-policy.sgml +++ b/debian/python-policy.sgml @@ -135,8 +135,9 @@ For every Python version provided in the distribution, the package packagepythonvarX/var.varY/var/package shall provide a complete distribution for emdeployment/em of Python scripts - and applications. The package must ensure that the binary - file/usr/bin/pythonvarX/var.varY/var/file is provided. + and applications. The package must ensure that the + file/usr/bin/pythonvarX/var.varY/var/file interpreter + executable is provided. /p p Installation of packagepythonvarX/var.varY/var/package @@ -153,7 +154,8 @@ /p p At any time, the packagepython/package package must ensure - that the binary file/usr/bin/python/file is provided. + that file/usr/bin/python/file is provided as a symlink to the + current filepythonvarX/var.varY/var/file executable. The packagepython/package package must also depend on the appropriate packagepythonvarX/var.varY/var/package to -- 1.6.5
Re: RFC: Proposed updates to the Python Policy to reflect current practices
On Fri, Dec 11, 2009, Dmitrijs Ledkovs wrote: 2009/12/9 Loïc Minier l...@dooz.org: On Wed, Dec 09, 2009, Dmitrijs Ledkovs wrote: Where is this git repository hosted? Or where can I get the current version of the policy as seen on the debian.org website? Concerning the Python Policy, it's currently not handled in any VCS, so I created a private git repo from the uploads of the python-defaults package (which I found in the morgue) and committed the proposed changes on top of that. I can provide a copy of the repo to you, but it's not in any way an official repo for the python-defaults package or the policy. -- Loďc Minier Yes please! I'm struggling to read the patches like that I'd rather read git annotate =) which would be proposed final but with info where the words came from (patches or old stuff) Pushed as git.debian.org:~lool/public_git/python-defaults.git if you want to use ssh with an alioth account, or git://git.debian.org/~lool/python-defaults.git otherwise -- Loïc Minier -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RFC: Proposed updates to the Python Policy to reflect current practices
On Wed, Dec 09, 2009, Dmitrijs Ledkovs wrote: Where is this git repository hosted? Or where can I get the current version of the policy as seen on the debian.org website? Concerning the Python Policy, it's currently not handled in any VCS, so I created a private git repo from the uploads of the python-defaults package (which I found in the morgue) and committed the proposed changes on top of that. I can provide a copy of the repo to you, but it's not in any way an official repo for the python-defaults package or the policy. -- Loïc Minier -- 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 Wed, Dec 24, 2008, Josselin Mouette wrote: Precisely. TTBOMK no other VCS is as smooth to operate as subversion *for Debian packages*. Only svn-buildpackage can handle correctly the versioning of the debian/ directory alone. bzr bd works fine in this mode; did you try it out? -- Loïc Minier -- 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, Scott Kitterman wrote: I'll argue we want something different. We want VCS that will maximize participation. That means both keeping top contributors happpy and keeping it accessible to newcomers. I don't think hg, bzr, or git obviously qualify as accesible. My vote, fwiw, is to stay with svn until we have a documented, accessible workflow with tool support. Fair point. -- Loïc Minier -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: python-nautilus update (Re: [Python-apps-team] Bug#475233: Needs porting to new nautilus extension api)
Hi, On Fri, Apr 11, 2008, Stani wrote: Andreas reported that nautilus is upgrading its API to 2.0 It's changing it's extension ABI to 2.0; extensions were shipped in /usr/lib/nautilus/extensions-1.0 and will now be in /extensions-2.0. I don't know whether the API actually changes, but I'd suspect that it changes in places where GnomeVFS was exposed and stays similar otherwise. Do you have any idea when it will be available? Will existing python nautilus scripts work? Ross just committed a nautilus-python update in SVN; it looks like it's ready, but he prepared it for unstable (probably waiting for nautilus 2.22 to move to unstable). @Ross: I'm not sure nautilus is going it right now; in fact, I'm not sure there's consensus to ship nautilus 2.22 in lenny right now. Perhaps you could branch your new nautilus-python to pkg-gnome/packages/experimental, revert the changes in /unstable and upload the 0.5 tree in experimental for now? Thanks! -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: On team maintainership of DPMT (PAPT) packages
On Sun, Mar 09, 2008, Emilio Pozuelo Monfort wrote: For example, in the pkg-gnome team, it's even discouraged to put the team as the Maintainer, but everybody's welcome to touch any package, no matter who's listed as the Maintainer. The rationale here is that packages with an assigned maintainer: are usually better maintained than team maintained ones; this might be because the team is underpowered, but then having individual Maintainers: didn't prevent any pkg-gnome-wide changes to happen... -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Running unittest on build?
On Fri, Jan 11, 2008, Vincent Bernat wrote: Should we run unittest when building a python package? The main drawback is that we need to add more build-dependencies. I think it's a good idea; if you think the build-deps for the test suite are too large to be in Build-Depends, perhaps you can simply rely on them being installed on your machine and run the testsuite but ignore failures: run_testsuite || true but generally packages have the bdeps for the testsuite they run. Also, make sure you honor nocheck in DEB_BUILD_OPTS. Cheers, -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#429524: ITP: louie -- Python signal dispatching mechanism
Package: wnpp Severity: wishlist Owner: Loic Minier [EMAIL PROTECTED] * Package name: louie Version : 1.1 Upstream Author : Patrick K. O'Brien and contributors [EMAIL PROTECTED] * URL : http://pylouie.org/ * License : BSD Programming Lang: Python Description : Python signal dispatching mechanism Louie provides Python programmers with a straightforward way to dispatch signals between objects in a wide variety of contexts. It is based on PyDispatcher, which in turn was based on a highly-rated recipe in the Python Cookbook. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22-rc4-686 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- Loïc Minier
Re: RSVG Bindings
On Sat, Apr 21, 2007, Zani Zani wrote: Tnx man, i searched everywhere after the rsvg.so but have not searched for it on Debian unstable (foolish of me), the script found the .so but now it reports an error: AttributeError: 'gtk.gdk.ScreenX11' object has no attribute 'get_rgba_colormap' get_rgba_colormap was added in pygtk 2.9.0. You might want to request the exact requirements of your script to his provider. -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RSVG Bindings
On Sat, Apr 21, 2007, Zani Zani wrote: No its not, i had already tried that, remember that i am using etch and gnome 2.14.3, still no luck. Well, the module was written starting with gnome-python-desktop 2.15.1 and we shipped etch with 2.14.0, so you can't have it for etch unless you use a backport or build it yourself. -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RSVG Bindings
On Sat, Apr 21, 2007, Zani Zani wrote: Hey all, i have been trying for some time now to get the python bindings for librsvg and it just can't be found, i have a script that is pretty complex and that have not been written by me and used to work great on RedHat, they have a package call gnome-extras-something that had the rsvg.so, but debian just don't seen to have this file anywherei searched for it everywhere i have even extracted the file from the RH RPM and the script successfully found it but it didn't run and reported an error of FLOATING POINT (no further explanation) and i am pretty sure that this error comes from the module not the script...so i don't even know if this is the proper place to post this message but i would be really glad if someone could shed some light on this, would be pretty awful if we had to switch back to RH just because if this, i really like debian ;) It's in python-gnome2-desktop. -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposed update to the python policy
On Wed, Mar 21, 2007, 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 diff is attached. In summary it includes: * the deprecation of the current keyword; * making Provides: meaningful in the case of inter-module dependencies, as discussed at Debconf; * fixes to the erroneous python-support section. Looks good; this obviously implies that python-central will need to match the new dependency functionalities. -- Loïc Minier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python-support 0.6
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 transition? The default python version? I thought the rebuilds will be donc/scheduled before the default version is switched. Let's take the example of an application that uses python-gtk2 and requires python2.5 to work - a case that will probably happen before 2.5 is the default. As long as 2.5 is not the default, it will have to depend on python-gtk2 (= someversion), python2.5, python2.5-gtk2. This will fail to bring a python2.5-gobject implementation. Sure, I do see the problem in this case, but I think it's not very common. The problem didn't turn up very often with python2.4 for example. -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python2.5 fails to import pygtk and gtk modules
Hi, On Tue, Jan 02, 2007, Tshepang Lekhonkhobe wrote: I tried to do some development using Etch's python2.5, but it fails to import pygtk and gtk modules and this is a regression IIRC. v2.4 works fine. pyversions --supported only returns python2.4, so the source package does not build the 2.5 flavor. Either patch pygtk's debian/rules or patch pyversions and rebuild pygtk. Cheers, -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python2.5 fails to import pygtk and gtk modules
On Tue, Jan 02, 2007, Pierre Habouzit wrote: or do that the clean way: edit /usr/share/python/debian_defaults This is slightly better indeed. My personal taste wouldn't allow me to edit a file under /usr, but I suppose a diversion would achieve a similar job. It would be nice to override this with /etc/python/debian_config. Not sure what has to be done though to force the byte compilation and links creation for the pure modules, and that won't compile binary extention either anyway (but maybe pygtk already forces it I don't know I shall say, I've not checked). The python postinst has it: for hook in /usr/share/python/runtime.d/*.rtupdate; do [ -x $hook ] || continue if ! $hook rtupdate python$oldv python2.4; then hb=$(basename $hook .rtupdate) echo 2 error running python rtupdate hook $hb errors=yes fi done (There are also pre- and post-rtupdate hooks, but these are mostly useful when the default runtime changes.) -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: python2.5 fails to import pygtk and gtk modules
On Tue, Jan 02, 2007, Alexandre Fayolle wrote: I have to admit that I am a bit disapointed by this, to say the least. Why are we shipping python2.5 in etch if we don't ship the python extension modules people expect to find (PIL, mx.DateTime, Numeric...) I suppose this could be solved by python-defaults upload to experimental to list python2.5 as supported as well? I agree python2.5 is not very useful in itself as is. -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Help needed with python-gpod
On Sat, Sep 30, 2006, Pierre Habouzit wrote: with the autotools, to chose the python version you build for, you just need: PYTHON=pythonX.Y ./configure . I usually use PYTHON=$(which pythonX.Y) instead because some upstreams use [EMAIL PROTECTED]@ in their shebangs which will break if not an absolute pathname. -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RFS: urwid (updated package)
On Thu, Aug 24, 2006, Ian Ward wrote: http://mentors.debian.net/debian/pool/main/u/urwid/urwid_0.9.6-1.dsc Uploaded. Would be nice to have an upstream ChangeLog. -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Python Transition, Mass Bug fill and NMUs...
On Wed, Aug 02, 2006, Pierre Habouzit wrote: that could have been more clear, but I do have such tools to follow the transition, I use[1]. The two rounds of mass bug have been package that build public modules and extensions, and then all the other ones (+ some missed one at the first stage). Ok, some things I consider bugs with the current state of the transition and I would have expected in a Status of the Python transition page: - way of expressing dependencies on a particular version of python modules (#379455) - support of rtupdate scripts - support of pure python2.3 modules (raised on debian-python@ last week) - reports of upgrade testing this seems to be quite well documented on the DebianPython/NewPolicy pages, buxy added some full examples, and I added some more things about cdbs recenlty. The page was also updated for private modules before the second mass bug fill. An example of what I would have expected to find on the page I describe is: what to do when your package ships both private extensions and private modules; solution a) could be to configure the package with a --libexecdir or similar containing the name of the python runtime and build it multiple times, solution b) could be to only build for one version of python. -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: More dh_python questions
Hi, (Could you please stop cross-posting to debian-devel? The discussion belongs to debian-python@ and the list is low traffic.) On Sun, Jul 30, 2006, Manoj Srivastava wrote: I have only one version in XS-Python-Version (say, 2.4) I think the patch in #378604 enhance this situation with XS-Python-Version: 2.4, but I had trouble too with XS-Python-Version: 2.3, see thread on debian-python@, Generation of python dependencies for public extensions versus python2.3. Also, the behavior seems completely clean for XS-Python-Version: current, have a look at flumotion which has private modules which are compiled in place (in /usr/lib/flumotion) for the current version of python on install, and are recompiled on upgrades. Bye, -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Generation of python dependencies for public extensions versus python2.3
On Tue, Jul 25, 2006, Joe Wreschnig wrote: The scripts in /usr/lib/python2.3/site-packages/GMenuSimpleEditor call plain python. That's probably causing the dependency. After I've sed 1d the files, the Depends of python-gmenu still has: Depends: libc6 (= 2.3.6-6), libglib2.0-0 (= 2.10.0), libgnome-menu2 (= 2.14.0), python-central (= 0.5), python (= 2.3), python ( 2.4) Python-Version: 2.3 So, it won't be possible to use the package with python2.3 after the switch. To recap: - the gnome-menus source has XS-Python-Version: current - the python-gmenu binary ends up with Python-Version: 2.3 - python-gmenu ships a private module, GMenuSimpleEditor, with no python shebang, which will be byte-compiled by pycentral - python-gmenu ships a public extension, /usr/lib/python2.3/site-packages/gmenu.so Wouldn't it be best to permit python2.3 instead of python in this case? Perhaps it's because the package is named python-XXX, which means it should always ship its public extension for the current version of Python? I tried renaming the binary package to something else, not using python in the name, the result was still the same: Depends: libc6 (= 2.3.6-6), libglib2.0-0 (= 2.10.0), libgnome-menu2 (= 2.14.0), python-central (= 0.5), python (= 2.3), python ( 2.4) Python-Version: 2.3 I even tried using XS-Python-Version: 2.3, and it resulted in the same binary headers. Is it possible at all to achieve a python2.3 package?? I think the only solution I have is to build for all versions now. -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Generation of python dependencies for public extensions versus python2.3
Hi, While trying to install the packages from experimental where python is python2.4, I was surprized by the non-upgradability of the python-gmenus package (from gnome-menus): it is built with XS-Python-Version set to current, and ends up with: Depends: libc6 (= 2.3.6-6), libglib2.0-0 (= 2.10.0), libgnome-menu2 (= 2.14.0), python-central (= 0.5), python (= 2.3), python ( 2.4) Python-Version: 2.3 Since current was 2.3 when it was built, it ships files below /usr/lib/python2.3, so why doesn't it end with a python2.3 dependency instead of pure python dependencies? And why does it conflict with a python 2.4? The extension would certainly still work when used from python2.3 after the switch, and this seems to make upgrades harder. Bye, -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Move to python 2.4 / Changing the packaging style for python packages
Matthias, On Tue, Jun 13, 2006, Matthias Klose wrote: We will prepare the transition in experimental by an upload of the python, python-dev packages I tried testing my rtupdates scripts by installing python version 2.4.3-5 from experimental, but they didn't seem to run, and I couldn't find anywhere in the maintainer scripts of the python package a place where they would be run. Is this feature already included in the python packages? In experimental? Or do I need to depend on something? I checked the python package from http://people.debian.org/~doko/pythontst/, and its maintainer scripts didn't seem to have the feature either. Bye, -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379455: Python Policy suggests dependencies that prevent the replacement of real packages by virtual ones
Package: python-defaults Severity: important Tags: patch Hi, As explained on debian-python@ in the attached message... Here's a patch. Bye, -- Loïc Minier [EMAIL PROTECTED] ---BeginMessage--- Hi, Python Policy 3.2 states: 3.2 Programs Using a Particular Python Version A program which requires a specific version of Python must begin with #!/usr/bin/pythonX.Y (or #!/usr/bin/env pythonX.Y). It must also specify a dependency on pythonX.Y and on any pythonX.Y-foo package providing necessary modules. It should not depend on any python-foo package, unless it requires a specific version of the package (since virtual packages cannot be versioned). If this is the case, it should depend on both the virtual package and the main package (e.g. Depends: python2.4-foo, python-foo (= 1.0)). Consider gnome-osd which depended on python2.4-pyorbit-omg before pyorbit was transitioned. Now pyorbit only ships python-pyorbit-omg which Provides python2.4-pyorbit-omg, but users with gnome-osd installed -- and hence python2.4-pyorbit-omg as a real package installed -- won't get python-pyorbit-omg. Shouldn't such packages Depend on python-pyorbit-omg, python2.4-pyorbit-omg, even if they don't need a particular version of python-pyorbit-omg (contrarily to what 3.2 §2 requests)? Bye, -- Loïc Minier [EMAIL PROTECTED] ---End Message--- diff -urN python-defaults-2.4.3-5/debian/changelog python-defaults-2.4.3-6/debian/changelog --- python-defaults-2.4.3-5/debian/changelog2006-06-16 18:15:25.0 +0200 +++ python-defaults-2.4.3-6/debian/changelog2006-07-23 19:59:50.0 +0200 @@ -1,3 +1,11 @@ +python-defaults (2.4.3-6) unstable; urgency=low + + * Recommend depending on pythonX.X-foo, python-foo instead of recommending +to only depend on pythonX.X-foo when a particular version is needed to +permit upgrades from real packages to virtual ones. (Closes: XX) + + -- Loic Minier [EMAIL PROTECTED] Sun, 23 Jul 2006 19:58:17 +0200 + python-defaults (2.4.3-5) experimental; urgency=low * Tighten dependencies between packages built from this source. diff -urN python-defaults-2.4.3-5/debian/python-policy.sgml python-defaults-2.4.3-6/debian/python-policy.sgml --- python-defaults-2.4.3-5/debian/python-policy.sgml 2006-06-13 01:28:48.0 +0200 +++ python-defaults-2.4.3-6/debian/python-policy.sgml 2006-07-23 19:58:03.0 +0200 @@ -451,13 +451,11 @@ must also specify a dependency on packagepythonvarX/var.varY/var/package and on any packagepythonvarX/var.varY/var-foo/package - package providing necessary modules. It should not depend on - any packagepython-foo/package package, unless it - requires a specific version of the package (since virtual - packages cannot be versioned). If this is the case, it - should depend on both the virtual package and the main - package (e.g. ttDepends: python2.4-foo, python-foo (= - 1.0)/tt). + package providing necessary modules. It should also depend on + the corresponding packagepython-foo/package packages, to + ease upgrades from real to virtual packages; this is also the + only way to depend on a particular version of the package + (since virtual packages cannot be versioned). /p p The notes on installation directories and bytecompilation
Python transition and pkg-config files
Hi, (I just subscribed to debian-python and a quick googling didn't bring any prior reference to this problem.) % pkg-config --variable pyexecdir pygtk-2.0 /usr/lib/python2.4/site-packages % pkg-config --variable pyexecdir gst-python-0.10 /usr/lib/python2.4/site-packages Oops. On my system, these packages are affacted: /usr/lib/pkgconfig/pygtk-2.0.pc /usr/lib/pkgconfig/gst-python-0.10.pc /usr/lib/pkgconfig/gst-python-0.8.pc /usr/lib/pkgconfig/pygda-1.2.pc Any suggestion on how to deal with this? Use of alternatives to manage symlinks of pygtk-2.0-pythonVER.pc? Perhaps we should introduce a /usr/lib/python/site-packages dir which always points to /usr/lib/pythonCURRENT/site-packages and make .pc files reference that? Or should pyexecdir be dropped from .pc files? Bye, -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Python transition and pkg-config files
On Tue, Jul 11, 2006, Loïc Minier wrote: It's also possible to influence the PKG_CONFIG_PATH, eg. PKG_CONFIG_PATH=/usr/lib/pkg-config/python2.3:$PKG_CONFIG_PATH in debian/rules. I tried this, and it wasn't too hard except it needed a rtupdate script to update the symlinks after a default python runtime change, and the symlinks need to be created / removed in postinst / prerm. However, I just discovered it does only fix some use cases. From gst0.10-python's configure.ac: PKG_CHECK_MODULES(PYGTK, pygtk-2.0 = $PYGTK_REQ) = (ok, that will now work) PYGTK_DEFSDIR=`$PKG_CONFIG --variable=defsdir pygtk-2.0` = (/usr/share/pygtk/2.0/defs: I can only ship that one time) PYGTK_H2DEF=`$PKG_CONFIG --variable=codegendir pygtk-2.0`/h2def.py PYGTK_CODEGEN=$PYTHON `$PKG_CONFIG --variable=codegendir pygtk-2.0`/codegen.py = (/usr/share/pygtk/2.0/codegen/h2def.py and codegen.py: same problem) So, am I supposed to install every file below a directory versionned with the python runtime and handle symlink creation, deletion, and updates in maintainer scripts? (These dirs are not ./configure-able.) -- Loïc Minier [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#330681: O: python-gnome
Package: wnpp Severity: normal Hi, After some checks with the pkg-gnome maintainers, and following the discussions in debian-gtk-gnome and debian-release concerning the status of GNOME 1, I'm orphaning a couple of GNOME 1 packages. Bye, -- Loïc Minier [EMAIL PROTECTED]
