Giving an additional config file via --extra-cfg-file one could overwrite field "Depends" in the past. It doesn't do so anymore though.

I've checked the source but there is no test suite provided, otherwise I would've tried to provide a test to fix this behaviour for the future.

After running the 'debianize' command, building a source package gives me these lintian warnings:

W: flufl-i18n source: debhelper-but-no-misc-depends python-flufl.i18n
W: flufl-i18n source: out-of-date-standards-version 3.8.3 (current is 3.8.4)

Here are changes to the control file I had to make after the fact:

=== modified file 'debian/control'
--- debian/control 2010-06-10 21:00:27 +0000
+++ debian/control 2010-06-10 21:36:18 +0000
@@ -3,11 +3,11 @@
Section: python
Priority: optional
Build-Depends: python-setuptools (>= 0.6b3), debhelper (>= 7), python-support (>= 0.8.4)
-Standards-Version: 3.8.3
+Standards-Version: 3.8.4

Package: python-flufl.i18n
Architecture: all
-Depends: ${python:Depends}
+Depends: ${python:Depends}, ${misc:Depends}
XB-Python-Version: ${python:Versions}
Provides: ${python:Provides}
Description: A high level API for Python internationalization.

Hi,

I'm trying to compile scipy using stdeb under debian/lenny. Swig can't find the umfpack header files which are installed under /usr/include/suitesparse. So, I am trying to pass this path through in the CPATH environment variable using --setup-env-vars. I'm not sure that would work, but in any case I get an error message that was unexpected:

distutils.errors.DistutilsArgError: option --setup-env-vars not recognized.

The full session is copied below.

Thanks,
Tom

$ py2dsc --force-buildsystem=False --setup-env-vars scipy-0.7.2.tar.gz

Traceback (most recent call last):
File "/usr/bin/py2dsc", line 157, in
main()
File "/usr/bin/py2dsc", line 154, in main
sys.exit(runit())
File "/usr/bin/py2dsc", line 29, in runit
args = parser.getopt(object=optobj)
File "/usr/lib/python2.5/distutils/fancy_getopt.py", line 260, in getopt
raise DistutilsArgError, msg
distutils.errors.DistutilsArgError: option --setup-env-vars not recognized

else its hard to push to a ppa

The following is not-yet-tested:

HACK yukyuk:~/playground/stdeb/gw/stdeb$ git diff
diff --git a/stdeb/util.py b/stdeb/util.py
index 419961c..a38f22c 100644
--- a/stdeb/util.py
+++ b/stdeb/util.py
@@ -946,13 +946,13 @@ install-python%%:
if test "$" = "2.5" -o "$" = "2.4"; then
%(setup_env_vars)spython$* -c "import setuptools,sys;f='setup.py';sys.argv[0]=f;execfile(f,{'file':f,'name':'main'})" install
--no-compile --single-version-externally-managed \

•        --root $(CURDIR)/debian/${PACKAGE_NAME}; \
  

•        --root \"$(CURDIR)/debian/${PACKAGE_NAME}\"; \
     mv debian/${PACKAGE_NAME}/usr/lib/python$_/site-packages/_.egg-info \
           debian/${PACKAGE_NAME}/usr/lib/python$_/site-packages/${EGG_MODULE_NAME}.egg-info; \
   else \
     %(setup_env_vars)spython$_ -c "import setuptools,sys;f='setup.py';sys.argv[0]=f;execfile(f,{'**file**':f,'**name**':'**main**'})" install \
       --no-compile --single-version-externally-managed --install-layout=deb \
  

•        --root $(CURDIR)/debian/${PACKAGE_NAME}; \
  

•        --root \"$(CURDIR)/debian/${PACKAGE_NAME}\"; \
     mv debian/${PACKAGE_NAME}/usr/lib/python$_/dist-packages/_.egg-info \
           debian/${PACKAGE_NAME}/usr/lib/python$*/dist-packages/${EGG_MODULE_NAME}.egg-info; \
  fi
  

When building a .deb for pycryptopp, you have to pass the "--disable-embedded-cryptopp" option to "python ./setup.py build". How do I configure stdeb so that dpkg-buildpackage will do that?

if your version has a non-alphanumeric character such as "+" in it (as many debian packages do, eg 1.4.4+svn20091011), running the egg_info command screws with it and changes the "+" into a "-", causing the build to fail.

The offending code in setuptools/command/egg_info.py:
self.distribution.metadata.version = self.egg_version

We can get around this in stdeb/command/sdist_dsc.py:

+        oldver = self.distribution.metadata.version
         self.run_command('egg_info')
+        self.distribution.metadata.version = oldver

but this is kind of ugly. I haven't noticed any bad effects, though - the .deb still ends up with the correct (unaltered) version.

I have installed stdeb 0.6.0 from sources on a debian Lenny system. When running the provided test.sh, I get an "Unknown option: buildsystem" error after "dh clean", followed by an abort. The full output of test.sh is given below.

Thanks for your efforts on stdeb. I hope to use it to build numpy and friends for a few of the different architectures I need.

Thanks,
Tom

$ ./test.sh
--2010-06-26 12:00:44-- http://astraw.com/misc_files/simplepack-8.0.1+r23437.tar.gz
Resolving astraw.com... 69.163.194.242
Connecting to astraw.com|69.163.194.242|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 518 [application/x-tar]
Saving to: `simplepack-8.0.1+r23437.tar.gz'

100%[======================================>] 518 --.-K/s in 0s

2010-06-26 12:00:45 (18.8 MB/s) - `simplepack-8.0.1+r23437.tar.gz' saved [518/518]

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
running the following command in directory: deb_dist/tmp_py2dsc/simplepack-8.0.1+r23437
/usr/bin/python setup.py --command-packages stdeb.command sdist_dsc --dist-dir=/home/tomduck/install/archive/stdeb-0.6.0/deb_dist --use-premade-distfile=/home/tomduck/install/archive/stdeb-0.6.0/simplepack-8.0.1+r23437.tar.gz
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
running sdist_dsc
CALLING dpkg-source -b simplepack-8.0.1+r23437 simplepack_8.0.1+r23437.orig.tar.gz (in dir /home/tomduck/install/archive/stdeb-0.6.0/deb_dist)
dpkg-source: info: using source format `1.0'
dpkg-source: info: building simplepack using existing simplepack_8.0.1+r23437.orig.tar.gz
dpkg-source: info: building simplepack in simplepack_8.0.1+r23437-1.diff.gz
dpkg-source: info: building simplepack in simplepack_8.0.1+r23437-1.dsc
dpkg-source: warning: extracting unsigned source package (simplepack_8.0.1+r23437-1.dsc)
dpkg-source: extracting simplepack in simplepack-8.0.1+r23437
dpkg-source: info: unpacking simplepack_8.0.1+r23437.orig.tar.gz
dpkg-source: info: applying simplepack_8.0.1+r23437-1.diff.gz
dpkg-buildpackage: set CFLAGS to default value: -g -O2
dpkg-buildpackage: set CPPFLAGS to default value:
dpkg-buildpackage: set LDFLAGS to default value:
dpkg-buildpackage: set FFLAGS to default value: -g -O2
dpkg-buildpackage: set CXXFLAGS to default value: -g -O2
dpkg-buildpackage: source package simplepack
dpkg-buildpackage: source version 8.0.1+r23437-1
dpkg-buildpackage: source changed by unknown unknown@unknown
dpkg-buildpackage: host architecture i386
fakeroot debian/rules clean
dh clean
Unknown option: buildsystem
dh: unknown option; aborting
make: *** [clean] Error 1
dpkg-buildpackage: failure: fakeroot debian/rules clean gave error exit status 2

It should be possible to add a debian/watch file automatically, with a default path being the Cheeseshop (a.k.a. PyPI) path to an uploaded package. E.g. for flufl.enum:

version=3
http://pypi.python.org/packages/source/f/flufl.enum/flufl.enum-(.*).tar.gz

Of course, there should be a command line switch to either disable adding debian/watch, or setting it to your preferred (non-cheesy) alternative.

From http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=568699 :

py2dsc doesn't create debian/copyright. It should be feasible to create
draft copyright file using information from egg-info.

this breaks http://pypi.python.org/pypi/hgdistver and ships my complete hg history and tox test results

also it explains the very surprisingly very large tarball

XS-Python-Version still seems to be set to 'current', although the bug this tries to fix has been resolved already in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=548392

With the recent transition to Python2.6 in Debian this probably already broke some packages.
Thanks for noticing.

I think it would be straightforward to write an automatic install command for Debian/Ubuntu which would

1. grab the upstream Python source distribution, (e.g. from PyPI)
2. convert it to a debian source package,
3. then compile it to a .deb and
4. then install it using "dpkg -i".

Parts 2 and 3 are already done and parts 1 and 4 don't seem particularly difficult.

The python-support is not in Ubuntu main (only universe). Therefore I think it would be best if we did not require it.

Building a package that makes use of setuptools entry_points console_scripts results in the wrong Python version being used by default.

I think what is happening is that sub setup_py in Debian/Debhelper/Buildsystem/python_distutils.pm calls setup.py for several versions of Python, but the order in which they're called is not such that the default Python is always last. setuptools then modifies the shebang line, and whichever Python gets run last overwrites the file in /usr/bin/my_script. One possible fix would be to modify python_distutils.pm to call the default Python version last.

One possible fix would be to tell setuptools not to create a version-specific shebang line.

Lots of warning like these show up when running under Ubuntu 10.10:

dh_install -i
Unknown option: buildsystem
dh_install: warning: ignored unknown options in DH_OPTIONS
dh_installdocs -i
Unknown option: buildsystem
dh_installdocs: warning: ignored unknown options in DH_OPTIONS
dh_installchangelogs -i
Unknown option: buildsystem
dh_installchangelogs: warning: ignored unknown options in DH_OPTIONS
dh_installexamples -i
Unknown option: buildsystem
dh_installexamples: warning: ignored unknown options in DH_OPTIONS
dh_installman -i
Unknown option: buildsystem
dh_installman: warning: ignored unknown options in DH_OPTIONS
dh_installcatalogs -i
Unknown option: buildsystem
dh_installcatalogs: warning: ignored unknown options in DH_OPTIONS
dh_installcron -i

Please comment. Thanks

Sometimes packages need to perform some kind of post-install step. The distutils way of doing this seems to be by registering an install_data command (see this example). We could generate a debian/.postinst script that calls this command.

For now, the workaroud is to do it manually:

Do "python setup.py debianize" to create a debian directory with stdeb. (You need stdeb in your --command-packages to do this step.) Then create a file in debian/<python-packagename>.postinst which will be run when the package is installed. (Unfortunately, this would not be carried in the plain distutils source, but only in the debian/ directory. Which is why I filed this ticket.)

I'm getting pycryptopp integrated into Debian. It would be ideal if I could specify that the test vector data files in pycryptopp are "data_files" in the setup.py, and then the resulting .deb would write them into filenames e.g. "/usr/share/pycryptopp/testvectors/SHA256LongMsg.txt", and then a call like "pkg_resources.resource_string('pycryptopp', 'testvectors/SHA256LongMsg.txt')" would import them.

Dave Peterson had an idea of how to accomplish this in a general way that could be applied to other projects than just pycryptopp. I'll now ask him to explain his idea here. :-)

Built on a recent Ubuntu, stdeb is adding a false dependency on Python 2.7 to a build I am running, even when I override it via XS-Python-Version:

Depends: python2.7 | python2.6, python (>= 2.7.1-0ubuntu2), python (<< 2.8)

How do I tell stdeb not to include the system version of Python as a dependency?

Putting an explicit "1.0" in debian/source/format would avoid some warnings I get when creating the source package.

dpkg-source: info: use the '3.0 (quilt)' format to have separate and documented changes to upstream files, see dpkg-source(1)

As shown on our buildbot:

http://allmydata.org/buildbot-pycryptopp/builders/allmydata.com-hardy-i386%20syslib/builds/3/steps/stdeb/logs/stdio

It is using python2.5 for most of it, but then the 'dpkg-buildpackage' step executes debian/rules and then it tries to use python2.4 and fails. I'm going to uninstall python2.4 from this buildslave, probably...

i think its much more readable that when listing 4 or more entries

Hi,

line 612 in the 0.5.0 release of stdeb/util.py

"for longopt, shortopt, description in stdeb_cfg_options:"

causes wrong descriptions in the generated debian/control because "description" shadows the previously given description-parameter.

In my case i always get the standard text of the udev-rules field as description in the final debian package.

•        for longopt, shortopt, description in stdeb_cfg_options:
  

•        for longopt, shortopt, desc in stdeb_cfg_options:
  

solved this for me.

Not all python packages should go into section Python. See e.g. "anki" which goes do "misc". Please consider supporting another config option "Section" to manually set a section.

I ran into a problem with stdeb and X-Python-Version. In the stdep.cfg file I specified:
XS-Python-Version: >= 2.6

The resulting debian/control file contains X-Python-Version (without the S). I read that this is the recommended key according to the Debian Python policy. But when running python bdist_deb with Python 2.7 the resulting Debian package will depend on Python 2.7 which is not what I wanted to achieve.

This happens on an Ubuntu 12.04 machine with the Debian package python-stdeb 0.6.0+20100620-2build1. This version has the following changeset 363fa49 included.
When installing stdeb via pip the problem does not appear. After checking the sources stdep from pip is a bit older version and does not contain the above mentioned changeset. Without that change the key XS-Python-Version is preserved and with that the resulting Debian package has the correct dependency.

While it's certainly workable to have to add --command-packages=stdeb.command or hack your ~/.pydistutls.cfg file, I think it does a bit of a disservice to users. Let's make it really easy for them to run stdeb commands by adding an entry point to the setup.py to automatically get stdeb commands once the package is installed.

As described in Python bug 1054967, message 94524, stdeb cannot be linked by the official Python documentation because it depends on setuptools. Therefore, it would be nice to make a plain distutils version.

The --extra-cfg-file option docs say that stdeb.cfg lives in .egg-info, but that has been changed and now it lives next to setup.py (as it should).

Hi,

This is probably related to a similar issue I reported earlier today, using stdeb 0.6.0 under debian/lenny. The --stdeb-patch-file option is reported as unrecognized. The full session is reported below.

Cheers,
Tom

$ py2dsc --force-buildsystem=False --stdeb-patch-file=scipy-0.7.2.diff scipy-0.7.2.tar.gz

Traceback (most recent call last):
File "/usr/bin/py2dsc", line 157, in
main()
File "/usr/bin/py2dsc", line 154, in main
sys.exit(runit())
File "/usr/bin/py2dsc", line 29, in runit
args = parser.getopt(object=optobj)
File "/usr/lib/python2.5/distutils/fancy_getopt.py", line 260, in getopt
raise DistutilsArgError, msg
distutils.errors.DistutilsArgError: option --stdeb-patch-file not recognized

would be a tremendous help

See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=615858, which also includes a patch.

I might be wrong, but it seems that option 'Distribution' worked some time ago. I could set it to Karmic and get the correct changelog header. It now seems Suite is taking on this role.

If the former ever work, and it's not already mentioned in the changelogs maybe it should go there.

As reported by lukshintim on the distutils mailing list, when changing the XS-Python-Version option in stdeb.cfg, the Build-Depends in debian/control should reflect that. Currently they are fixed to python-all-dev.

We need to handle backward compatibility issues.

1. We currently have depend in generated binary packages on python-central because if a package was previously generated with stdeb < 0.4 and then upgraded to stdeb 0.4, it will be broken unless the .preinst script installed with 0.4 is run. This script depends on python-central. Ideally, we wouldn't package the .preinst script or include python-central in the depends. Perhaps we add an option "--pycentral-backwards-compatibility=False" that turns this off?

2. The fix to #10 causes stdeb to limit the available Python to just one. Now that Debian bug 548392 is fixed, we should initially optionally allow the workaround to be disabled. In the future this option will be the default. Perhaps a "--workaround-548392" option argument? It would initially default to True, and later default to False. If the default True was used (as opposed to giving True on the command line), it could emit a warning that it would be changed in the future.

Perhaps a "--no-backwards-compatibility" flag that adjusts both these options?

dpkg-buildpackage fails on .dsc produced from gnome-wallchanger (bzr revno 22)

How can I add post install hooks?

I have my package building using:
python setup.py --command-packages=stdeb.command bdist_deb

What I want to do is run my post install script to add a launcher. I tried editing the postinst file generated by the debhelper in my
deb_dist/program/ directory and tried running:
dpkg-buildpackage -rfakeroot -uc -us

But when I open the .deb file with the archive manager and look at the postinst file it doesn't have the code I added.

Is there a way to add post install hooks/script to the stdeb.cfg file?

Hi,

I want to build a debian package for upload to Ubuntu PPA. The upstream source is Ephem which is an astronomy package comprising Python and C.

Using stdeb, I can build a source (and binary) debian package of the Python 2 version (http://pypi.python.org/pypi/pyephem) - the source package is then uploaded to the PPA as the PPA does the build. However I want a Python 3 version and when I run the terminal command

python3 setup.py --command-packages=stdeb.command sdist_dsc

I get

usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
   or: setup.py --help [cmd1 cmd2 ...]
   or: setup.py --help-commands
   or: setup.py cmd --help

error: invalid command 'sdist_dsc'

So...can I use Python 3 and stdeb to make a DEB source/binary package (with C extensions)?

Thanks in advance,

Bernard.

In my project I have a bin/ directory which symlinks to a python script elsewhere. If I run py2dsc, it fails with:

dpkg-source: error: new version is plain file
dpkg-source: error: old version is symlink to ../dtella.py

because for some reason, the symlink is not preserved at this stage. the symlink exists in all the other copies of the project in deb_dist, including the generated tar.gz (which seems to be the preceding step to this)

Stdeb already has machinery to allow discovery of the original Debian/Ubuntu package for a given python package distribution. This should be carefully checked to allow graceful upgrades from a Debian/Ubuntu distributed version.

Note some Debian sources (e.g. for numpy) generate multiple debian packages. The stdeb generated version should probably conflict/replace/provide all of these.

I guess if you don't want it to stop then you should use the "--ignore-install-requires" option?

diff --git a/stdeb/util.py b/stdeb/util.py
index adfea5b..3ef0698 100644
--- a/stdeb/util.py
+++ b/stdeb/util.py
@@ -22,6 +22,7 @@ __all__ = ['DebianInfo','build_dsc','expand_tarball','expand_zip',

 import exceptions
 class CalledProcessError(exceptions.Exception): pass
+class CantSatisfyRequirement(exceptions.Exception): pass

 def check_call(*popenargs, **kwargs):
     retcode = subprocess.call(*popenargs, **kwargs)
@@ -132,7 +133,12 @@ def get_date_822():
     result = cmd.stdout.read().strip()
     return result

-def get_deb_depends_from_setuptools_requires(requirements):
+def get_deb_depends_from_setuptools_requires(requirements, exception_on_failure=True):
+    """
+    If exception_on_failure then raise an exception if there is a setuptools
+    requirement that you can't figure out how to satisfy.  Else, just log a
+    warning.
+    """
     depends = [] # This will be the return value from this function.

     requirements = list(pkg_resources.parse_requirements(requirements))
@@ -212,9 +218,14 @@ def get_deb_depends_from_setuptools_requires(requirements):
                          "\"%s\" -- ignoring."
                          % (', '.join(debs), req.project_name, req))
         if not gooddebs:
-            log.warn("I found no Debian package which provides the required "
-                     "Python package \"%s\" with version requirements "
-                     "\"%s\"."% (req.project_name, req.specs))
+            if exception_on_failure:
+                raise CantSatisfyRequirement("I found no Debian package which "
+                    "provides the required Python package \"%s\" with version "
+                    "requirements \"%s\"." % (req.project_name, req.specs), req)
+            else:
+                log.warn("I found no Debian package which provides the required "
+                         "Python package \"%s\" with version requirements "
+                         "\"%s\"."% (req.project_name, req.specs))
         elif len(gooddebs) == 1:
             log.info("I found a Debian package which provides the require "
                      "Python package.  Python package: \"%s\", "

The master branch currently uses debhelper 7 to automatically build Python packages. Versions before 7.3.5 have this bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520834

stdeb should depend on debhelper >= 7.3.5 to avoid this bug.

I use paver
http://www.blueskyonmars.com/projects/paver/

I installed stdeb and I get this exception:

Captured Task Output:
---------------------

---> paver.tasks.help
Traceback (most recent call last):
  File "/usr/local/lib/python2.6/dist-packages/Paver-1.0.1-py2.6.egg/paver/tasks.py", line 164, in _run_task
    return do_task()
  File "/usr/local/lib/python2.6/dist-packages/Paver-1.0.1-py2.6.egg/paver/tasks.py", line 161, in do_task
    return func(**kw)
  File "/usr/local/lib/python2.6/dist-packages/Paver-1.0.1-py2.6.egg/paver/tasks.py", line 546, in help
    print(fmt % (task.shortname, task.description))
  File "/usr/local/lib/python2.6/dist-packages/Paver-1.0.1-py2.6.egg/paver/setuputils.py", line 150, in description
    return self.command_class.description
AttributeError: class sdist_dsc has no attribute 'description'

Currently, the master makes very broken diff.gz files. For my package, which is called bluepy, I get a duplicate source folder in deb_dist, i.e.: deb_dist/bluepy-0.2.0-dev/bluepy-0.2.0-dev/ This is also reflected in the bluepy_0.2.0-dev-1.diff.gz which is almost the same size as bluepy_0.2.0-dev.orig.tar.gz since it introduces a complete copy of the original sources.

Some projects (e.g. Babel) use the PyPI download_url to point to a download webpage rather than a download tarball. We should automatically detect these and do the right thing. For example, easy_install does this.

Running this following setup.py:

https://github.com/gliptak/webilder/blob/master/setup.py
https://github.com/gliptak/webilder/blob/master/stdeb.cfg

creates a deb file, which does not contain several files (like man pages, mime) installed using setup.py:

71,79d66
< /usr/share/mime
< /usr/share/mime/packages
< /usr/share/mime/packages/webilder.xml
< /usr/share/man
< /usr/share/man/man1
< /usr/share/man/man1/webilder_desktop.1.gz
< /usr/share/man/man1/webilder_applet.1.gz
< /usr/share/man/man1/webilder_downloader.1.gz
< /usr/share/man/man1/wbz_handler.1.gz
81,83d67
< /usr/lib/mime
< /usr/lib/mime/packages
< /usr/lib/mime/packages/webilder

Could you suggest modifications to the setup allowing those above files to be included in the deb package? Thanks

Currently stdeb fails on packages that use extras_require:

get_deb_depends_from_setuptools_requires passes the content directly to pkg_resources.parse_requirements which doesn't expect that which causes the cryptic error.

pkg_resources.parse_requirements input is normally preprocessed by pkg_resources.split_sections that splits extras requires from those of the main package.

In my setup.py:

py_modules = ['src/prog'],
data_files=['', ['src/data.yml']],

The setup.py script that I wrote works fine with

python setup.py sdist

(the tar.gz that is being generated has both my module and data file in
the same directory) but it throws errors when I run:

python setup.py --command-packages=stdeb.command bdist_deb

specifically it says:

warning: install_data: setup script did not provide a directory for '' -- installing right in
'/home/<mydirectory>/debian/python-<myapplicationname>/usr'
error: can't copy '': doesn't exist or not a regular file

so I believe stdeb is simply unable to understand that the empty string
means "put the data file together with the module", the way the regular
distutils can.

Am I right or did I misunderstand anything?

Because I can't pass options to setup.py, per http://github.com/astraw/stdeb/issues/#issue/5 , I instead arranged to use the Setup-Env-Vars part of stdeb.cfg to set an env var. This works in 10bb2fb but not in current HEAD (99c3aec). In HEAD when I execute os.environ.get() in my setup.py the variable is absent, but in 10bb... it is present.

http://allmydata.org/trac/pycryptopp/browser