python packaging questions
Hi Debian Python experts,
I am currently trying to create Debian packages for a small python
application I am writing. I thinks, this application is not yet ready
for an official inclusion in Debian, but still, I have some questions
about 'proper' packaging just out of interest:
* For specifying supported Python versions, the policy recommends using
XS/B-Python, whereas the python-support documentation recommends
debian/pyversions. Which method should be used or does it not matter?
What when using python-central?
* 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 python2.5-gtk2. Does that mean that all those
packages will be installed or are those only virtual packages to ease
future transitions?
* In debian/control: The python-support docs recommend using
'Depends: ${python:Depends}' and then specifying the dependencies on
other python modules in 'Python-Depends'. Should this method also be
used with python-central or should then all the dependencies be
specified in 'Depends'?
Thanks for your help,
Eike
--
Eike Nicklas
www.ephys.de
pgpP7CYj76SM4.pgp
Description: PGP signature
Re: python packaging questions
Thanks a lot to all of you, that clarified things for me!
On Wed, 16 Jan 2008 14:10:11 +0100 Josselin Mouette wrote:
> 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 python2.5-gtk2. Does that mean that all those
> > packages will be installed or are those only virtual packages to ease
> > future transitions?
>
> These are virtual packages, and they are brought in by the
> Python-Depends field. (Altough if python2.3-gtk2 appears, there must be
> an issue somewhere.)
>
> > * In debian/control: The python-support docs recommend using
> > 'Depends: ${python:Depends}' and then specifying the dependencies on
> > other python modules in 'Python-Depends'. Should this method also be
> > used with python-central or should then all the dependencies be
> > specified in 'Depends'?
>
> If your package is an application and not a module, you don’t really
> need Python-Depends. I should clarify the docs about that. (In fact you
> need them only if you use Provides: ${python:Provides}.)
>
pgpRqQzPpSjMf.pgp
Description: PGP signature
RFS: pondus
Hi Debian Python Team, I am currently writing a small application in Python that (as a long term happy Debian user) I would like to include in Debian. I created a package (hopefully conforming to the Python Policy) and uploaded it to mentors.debian.net It would be great if you had a look at the package, provided some feedback on the packaging and eventually sponsored the package once it is packaged properly. Thanks a lot for your help, Eike Here's the package information: * Package name: pondus Version : 0.1.0-1 Upstream Author : Eike Nicklas <[EMAIL PROTECTED]> * URL : http://www.ephys.de/software/pondus/ * License : GPL Section : x11 It builds these binary packages: pondus - personal weight manager for GTK+2 The package appears to be lintian clean and builds fine in pbuilder. The upload would fix these bugs: 463873 The package can be found on mentors.debian.net: - URL: http://mentors.debian.net/debian/pool/main/p/pondus - Source repository: deb-src http://mentors.debian.net/debian unstable main contrib non-free - dget http://mentors.debian.net/debian/pool/main/p/pondus/pondus_0.1.0-1.dsc pgpBC8RtzFpqZ.pgp Description: PGP signature
Re: RFS: pondus
Hi Piotr and list, On Mon, 4 Feb 2008 22:47:45 +0100 Piotr Ożarowski wrote: > [Eike Nicklas, 2008-02-04T17:51] > > It would be great if you had a look at the package, provided some > > feedback on the packaging and eventually sponsored the package once it > > is packaged properly. > > * you've missed python-gobject (src/pondus/gui/dialog_add.py, line 23), > but since python-gtk2 depends on it, I guess it's OK. Thanks for the hint, I will add the dependency on the next upload (or I can reupload, if you prefer that). > * how about installing NEWS file as upstream changelog? > (`dh_installchangelogs NEWS`) This is done by upstream setup.py, the NEWS file is already in the package. > > I can upload it now (without above changes), but please consider joining > PAPT [1] first. I just sent a request for joining the team and will upload the debian directory to the SVN repository as soon as I am in the team and time permits. Thanks for your feedback and help, Eike pgp9K9L1K8NAU.pgp Description: PGP signature
Re: RFS: matplotlib 0.90.1-3
Hi, On Sat, 23 Feb 2008 13:07:24 +0100 Ondrej Certik wrote: > > currently, matplotlib doesn't install with numpy in sid, when numpy > switched to gfortran and it conflicts with matplotlib. > That might also (partly) fix a bug I reassigned to matplotlib: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=466818 It was initially reported against pondus, which does not explicitely use python-numpy, but only python-matplotlib (which it correctly depends on) Eike pgppYeU57Siv3.pgp Description: PGP signature
Re: RFS: matplotlib 0.90.1-3
Hi Ondrej et al., > > Yes, I read that bug. There are more problems with matplotlib - it is > not lintian clean, > it still uses Numerics and numarray besides numpy (I don't know if > this is a feature or a bug), > I think upstream deprecated Numerics and numarray and the latest version only uses numpy. Changelog excerpts: 2007-06-01 Deprecate Numeric and numarray for use as numerix. 2007-06-02 Released 0.90.1 at revision 3352 2007-06-07 Disable build of numarray and Numeric extensions for internal MPL use and the numerix layer. 2007-07-19 replaced the Python code in numerix/ by a minimal wrapper around numpy that explicitly mentions all symbols that need to be addressed for further numpification [...] and only numpy is mentioned in the current README. Anyway, as a matplotlib user, I am happy that you want to fix the current issues, but sadly I currently don't have the time to help with that. Eike pgpoLmGwQJO0k.pgp Description: PGP signature
dependency questions
Hi all, I have a program that depends on python >= 2.4 and elementtree (which is included in python >= 2.5). What is the best way to express this dependency in debian/control (I am using python-support)? a) Depends: python (>=2.4), python (>=2.5) | python-elementtree b) Depends: python (>=2.5) (since python2.5 is the default version in lenny and sid anyway) c) Depends: python (>=2.4), python-elementtree (does python2.5 provide python-elementtree?) Thanks a lot for your help Eike pgpCUtRoCPJ8p.pgp Description: PGP signature
Re: dependency questions
On Mon, 25 Aug 2008 00:08:20 -0400 Scott Kitterman wrote: > On Sunday 24 August 2008 18:03, Eike Nicklas wrote: > > I have a program that depends on python >= 2.4 and elementtree (which > > is included in python >= 2.5). > > > > What is the best way to express this dependency in debian/control > > (I am using python-support)? > > > > a) Depends: python (>=2.4), python (>=2.5) | python-elementtree > > > > b) Depends: python (>=2.5) > > (since python2.5 is the default version in lenny and sid anyway) > > > > c) Depends: python (>=2.4), python-elementtree > > (does python2.5 provide python-elementtree?) > > > Option a works. I've used it. The package should work for all supported > Python versions, so that's what I'd go with. > Thanks a lot for the quick answer, will use option a. Eike pgpg0P1Ajx9kV.pgp Description: PGP signature
Re: Debian lenny update : nxutils.so: undefined symbol: __gxx_personality_v0
On Wed, 8 Oct 2008 12:08:46 +0200 Piotr Ożarowski wrote: > [oc-spam66, 2008-10-08 11:55] > >I went back to the former python-matplotlib package (0.98.1-1) and could > >import pylab again. So I think there is a problem with python-matplotlib > >0.98.1-1+lenny1.1 > > could you please try unstable one? (0.98.3-3) > 0.98.3-3 works fine here (as did 0.98.1-1, but with 0.98.1-1+lenny1.1 I had the same problems as O.C.) eike pgpbFuU2eCwDn.pgp Description: PGP signature
Re: numpy 1.2.1, switching to git?
I'd prefer: hg, git, bzr, svn, * but looks like the trend goes to git, which is a good option IMHO. Merry Christmas, Eike pgpHKNQOnhCVA.pgp Description: PGP signature
Re: Skip Python 2.6 and use 2.7 as default in Squeeze?
On Mon, 19 Apr 2010 19:46:48 -0500 Kumar Appaiah wrote: > But it would be nice to see Python 2.7 in Debian soon. :-) > It's available in experimental (not the latest beta, though). But indeed it would be great to have the 2.6->2.7 transition started a little earlier than the 2.5->2.6 one :-) pgpFtHfNGFfti.pgp Description: PGP signature
private modules and dh_python2
Hi all, I just tried to package an application using a private module. In this case, the name of the script starting the application and the module have the same name. So if the module is in /usr/share/foo/foo, then the script can not be /usr/share/foo/foo as well and installing the script to /usr/share/foo/scripts/foo results in an import error. How should this be best handled? 1) Patch the upstream script to add /usr/share/foo to pythonpath if 'import foo' fails? 2) In this specific case (which might actually not be that uncommon), dh_python2 could rename the script foo to foo.py such that it can be installed to /usr/share/foo/foo.py (currently, the behavior of dh_python2 is to install the script to /usr/share/foo/foo/foo in this case of a naming clash). 3) Module and script having the same name is bad practice and the module should be renamed to foo-lib anyway. Thanks for any comments, Eike pgpSirwkYFb4o.pgp Description: PGP signature
Re: private modules and dh_python2
Hi Barry, thanks for the quick answer. On Fri, 10 Jun 2011 15:34:19 -0400 Barry Warsaw wrote: > On Jun 10, 2011, at 09:01 PM, Eike Nicklas wrote: > > >I just tried to package an application using a private module. In > >this case, the name of the script starting the application and the > >module have the same name. > > Is the script private too? Wouldn't that be better installed > in /usr/bin/foo? Then 'import foo' fails if '/usr/share/foo/foo' is not explicitly added to pythonpath (that was the idea of having the module private in the first place ;-) ) As I understand http://wiki.debian.org/Python/Packaging#Example_2:_Python_application the idea is to install both script and module to /usr/share/foo where the script can 'locally' import the module and link /usr/bin/foo to the script. Eike pgpgJQzhrfGDt.pgp Description: PGP signature
Re: private modules and dh_python2
On Fri, 10 Jun 2011 21:52:11 +0200 Piotr Ożarowski wrote: > > install foo to /usr/share/foo/ under a different name, see > http://lists.debian.org/debian-python/2009/03/msg00091.html > Renaming is a great and simple idea, I'll do that. Thanks to all of you for the quick help, Eike pgpG23izpXYku.pgp Description: PGP signature
RFS: etm
Hi all, I just created a package for etm: Package name: etm Version : 883 Upstream Author : Daniel Graham URL : http://www.duke.edu/~dgraham/ETM/ License : GPL Programming Lang: Python Description : event and task manager using simple text files It is injected to the svn repository http://svn.debian.org/viewsvn/python-apps/packages/etm/trunk/ The package builds fine in pbuilder and works here. Lintian only complains about missing manpages. Furthermore, the package currently does not provide a .desktop file. Any comments are welcome, thanks a lot in advance, Eike pgpJ9DsPJPn3T.pgp Description: PGP signature
