Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #16895 > unrolled thread

dpkg-buildpackage vs sbuild with python packaging

Back to article view | Back to linux.debian.maint.python

Contents

  dpkg-buildpackage vs sbuild with python packaging PICCA Frederic-Emmanuel <frederic-emmanuel.picca@synchrotron-soleil.fr> - 2025-06-11 16:00 +0200
    Re: dpkg-buildpackage vs sbuild with python packaging Santiago Vila <sanvila@debian.org> - 2025-06-11 16:50 +0200
      Re: dpkg-buildpackage vs sbuild with python packaging PICCA Frederic-Emmanuel <frederic-emmanuel.picca@synchrotron-soleil.fr> - 2025-06-11 17:10 +0200
        Re: dpkg-buildpackage vs sbuild with python packaging Santiago Vila <sanvila@debian.org> - 2025-06-11 17:30 +0200
      Re: dpkg-buildpackage vs sbuild with python packaging Santiago Vila <sanvila@debian.org> - 2025-06-11 17:30 +0200
        Re: dpkg-buildpackage vs sbuild with python packaging Santiago Vila <sanvila@debian.org> - 2025-06-11 17:30 +0200
        Re: dpkg-buildpackage vs sbuild with python packaging Santiago Vila <sanvila@debian.org> - 2025-06-11 17:40 +0200
          Re: dpkg-buildpackage vs sbuild with python packaging PICCA Frederic-Emmanuel <frederic-emmanuel.picca@synchrotron-soleil.fr> - 2025-06-11 18:00 +0200
            Re: dpkg-buildpackage vs sbuild with python packaging Stefano Rivera <stefanor@debian.org> - 2025-06-11 18:30 +0200
        Re: dpkg-buildpackage vs sbuild with python packaging PICCA Frederic-Emmanuel <frederic-emmanuel.picca@synchrotron-soleil.fr> - 2025-06-11 17:50 +0200
        Re: dpkg-buildpackage vs sbuild with python packaging Peter Pentchev <roam@ringlet.net> - 2025-06-11 17:50 +0200
          Re: dpkg-buildpackage vs sbuild with python packaging Peter Pentchev <roam@ringlet.net> - 2025-06-11 18:00 +0200
          Re: dpkg-buildpackage vs sbuild with python packaging PICCA Frederic-Emmanuel <frederic-emmanuel.picca@synchrotron-soleil.fr> - 2025-06-11 18:10 +0200
      Re: dpkg-buildpackage vs sbuild with python packaging PICCA Frederic-Emmanuel <frederic-emmanuel.picca@synchrotron-soleil.fr> - 2025-06-11 17:30 +0200
        Re: dpkg-buildpackage vs sbuild with python packaging Stefano Rivera <stefanor@debian.org> - 2025-06-11 17:50 +0200
          Re: dpkg-buildpackage vs sbuild with python packaging PICCA Frederic-Emmanuel <frederic-emmanuel.picca@synchrotron-soleil.fr> - 2025-06-11 18:00 +0200
            Re: dpkg-buildpackage vs sbuild with python packaging thomas@goirand.fr - 2025-06-11 18:40 +0200
              Re: dpkg-buildpackage vs sbuild with python packaging Stefano Rivera <stefanor@debian.org> - 2025-06-11 18:40 +0200
                Re: dpkg-buildpackage vs sbuild with python packaging stefanor@debian.org - 2025-06-11 19:30 +0200
                  Re: dpkg-buildpackage vs sbuild with python packaging stefanor@debian.org - 2025-06-12 11:30 +0200
                    Re: dpkg-buildpackage vs sbuild with python packaging PICCA Frederic-Emmanuel <frederic-emmanuel.picca@synchrotron-soleil.fr> - 2025-06-12 11:50 +0200
                  Re: dpkg-buildpackage vs sbuild with python packaging PICCA Frederic-Emmanuel <frederic-emmanuel.picca@synchrotron-soleil.fr> - 2025-06-12 11:40 +0200
                Re: dpkg-buildpackage vs sbuild with python packaging PICCA Frederic-Emmanuel <frederic-emmanuel.picca@synchrotron-soleil.fr> - 2025-06-11 19:40 +0200
                Re: dpkg-buildpackage vs sbuild with python packaging thomas@goirand.fr - 2025-06-11 20:50 +0200
          Re: dpkg-buildpackage vs sbuild with python packaging Peter Pentchev <roam@ringlet.net> - 2025-06-11 18:00 +0200

Page 1 of 2  [1] 2  Next page →

#16895 — dpkg-buildpackage vs sbuild with python packaging

Hello I am working on this package

salsa:science-team/xrdutils

This is a pure python package, which use setuptools.

Now if I build the package within sbuild I get this file list.

(I will just take the grafit package)

   dh_auto_build -O--buildsystem=pybuild
I: pybuild plugin_pyproject:129: Building wheel for python3.13 with "build" module
I: pybuild base:311: python3.13 -m build --skip-dependency-check --no-isolation --wheel --outdir /build/reproducible-path/xrdutils-0.0.3/.pybuild/cpython3_3.13_xrdutils  
* Building wheel...
/usr/lib/python3/dist-packages/setuptools/config/_apply_pyprojecttoml.py:82: SetuptoolsDeprecationWarning: `project.license` as a TOML table is deprecated
!!

        ********************************************************************************
        Please use a simple string containing a SPDX expression for `project.license`. You can also use `project.license-files`. (Both options available on setuptools>=77.0.0).

        By 2026-Feb-18, you need to update your project and remove deprecated calls
        or your builds will no longer be supported.

        See https://packaging.python.org/en/latest/guides/writing-pyproject-toml/#license for details.
        ********************************************************************************

!!
  corresp(dist, value, root_dir)


creating build/lib/grafit
copying src/grafit/widgets.py -> build/lib/grafit
copying src/grafit/tools.py -> build/lib/grafit
copying src/grafit/plotitems.py -> build/lib/grafit
copying src/grafit/plot.py -> build/lib/grafit
copying src/grafit/parameters.py -> build/lib/grafit
copying src/grafit/models.py -> build/lib/grafit
copying src/grafit/masking.py -> build/lib/grafit
copying src/grafit/io.py -> build/lib/grafit
copying src/grafit/grafit_gui.py -> build/lib/grafit
copying src/grafit/fit2D.py -> build/lib/grafit
copying src/grafit/fit1D.py -> build/lib/grafit
copying src/grafit/events.py -> build/lib/grafit
copying src/grafit/datatypes.py -> build/lib/grafit
copying src/grafit/calculation.py -> build/lib/grafit
copying src/grafit/builder.py -> build/lib/grafit
copying src/grafit/__init__.py -> build/lib/grafit

adding 'grafit/__init__.py'
adding 'grafit/builder.py'
adding 'grafit/calculation.py'
adding 'grafit/datatypes.py'
adding 'grafit/events.py'
adding 'grafit/fit1D.py'
adding 'grafit/fit2D.py'
adding 'grafit/grafit_gui.py'
adding 'grafit/io.py'
adding 'grafit/masking.py'
adding 'grafit/models.py'
adding 'grafit/parameters.py'
adding 'grafit/plot.py'
adding 'grafit/plotitems.py'
adding 'grafit/tools.py'
adding 'grafit/widgets.py'


And with a simple dpkg-buildpackage on unstable distribution.

I: pybuild plugin_pyproject:129: Building wheel for python3.13 with "build" module
I: pybuild base:311: python3.13 -m build --skip-dependency-check --no-isolation --wheel --outdir /home/experiences/instrumentation/picca/debian/science-team/xrdutils/.pybuild/cpython3_3.13_xrdutils  
* Building wheel...
/usr/lib/python3/dist-packages/setuptools/config/_apply_pyprojecttoml.py:82: SetuptoolsDeprecationWarning: `project.license` as a TOML table is deprecated
!!

        ********************************************************************************
        Please use a simple string containing a SPDX expression for `project.license`. You can also use `project.license-files`. (Both options available on setuptools>=77.0.0).

        By 2026-Feb-18, you need to update your project and remove deprecated calls
        or your builds will no longer be supported.

        See https://packaging.python.org/en/latest/guides/writing-pyproject-toml/#license for details.
        ********************************************************************************

!!
  corresp(dist, value, root_dir)

creating build/lib/grafit
copying src/grafit/__init__.py -> build/lib/grafit
copying src/grafit/plotitems.py -> build/lib/grafit
copying src/grafit/builder.py -> build/lib/grafit
copying src/grafit/masking.py -> build/lib/grafit
copying src/grafit/plot.py -> build/lib/grafit
copying src/grafit/models.py -> build/lib/grafit
copying src/grafit/fit2D.py -> build/lib/grafit
copying src/grafit/fit1D.py -> build/lib/grafit
copying src/grafit/events.py -> build/lib/grafit
copying src/grafit/datatypes.py -> build/lib/grafit
copying src/grafit/calculation.py -> build/lib/grafit
copying src/grafit/tools.py -> build/lib/grafit
copying src/grafit/parameters.py -> build/lib/grafit
copying src/grafit/io.py -> build/lib/grafit
copying src/grafit/grafit_gui.py -> build/lib/grafit
copying src/grafit/widgets.py -> build/lib/grafit

creating build/lib/grafit/images
copying src/grafit/images/Eraser.png -> build/lib/grafit/images
copying src/grafit/images/Run.png -> build/lib/grafit/images
copying src/grafit/images/circle_sponge.png -> build/lib/grafit/images
copying src/grafit/images/cubic.png -> build/lib/grafit/images
copying src/grafit/images/door.png -> build/lib/grafit/images
copying src/grafit/images/exp.png -> build/lib/grafit/images
copying src/grafit/images/export_fit.png -> build/lib/grafit/images
copying src/grafit/images/gauss.png -> build/lib/grafit/images
copying src/grafit/images/gauss2D.jpg -> build/lib/grafit/images
copying src/grafit/images/linear.png -> build/lib/grafit/images
copying src/grafit/images/lorentz.png -> build/lib/grafit/images
copying src/grafit/images/mask_circle_grey.png -> build/lib/grafit/images
copying src/grafit/images/mask_polygon_grey.png -> build/lib/grafit/images
copying src/grafit/images/mask_rectangle_grey.png -> build/lib/grafit/images
copying src/grafit/images/planar.jpg -> build/lib/grafit/images
copying src/grafit/images/power.png -> build/lib/grafit/images
copying src/grafit/images/quadratic.png -> build/lib/grafit/images
copying src/grafit/images/sigma.jpg -> build/lib/grafit/images
copying src/grafit/images/sinus.png -> build/lib/grafit/images
copying src/grafit/images/square_sponge.png -> build/lib/grafit/images
copying src/grafit/images/step.png -> build/lib/grafit/images
copying src/grafit/images/voigt.png -> build/lib/grafit/images
copying src/grafit/images/weight.png -> build/lib/grafit/images
copying src/grafit/images/y_full_range.png -> build/lib/grafit/images

adding 'grafit/__init__.py'
adding 'grafit/builder.py'
adding 'grafit/calculation.py'
adding 'grafit/datatypes.py'
adding 'grafit/events.py'
adding 'grafit/fit1D.py'
adding 'grafit/fit2D.py'
adding 'grafit/grafit_gui.py'
adding 'grafit/io.py'
adding 'grafit/masking.py'
adding 'grafit/models.py'
adding 'grafit/parameters.py'
adding 'grafit/plot.py'
adding 'grafit/plotitems.py'
adding 'grafit/tools.py'
adding 'grafit/widgets.py'
adding 'grafit/images/Eraser.png'
adding 'grafit/images/Run.png'
adding 'grafit/images/circle_sponge.png'
adding 'grafit/images/cubic.png'
adding 'grafit/images/door.png'
adding 'grafit/images/exp.png'
adding 'grafit/images/export_fit.png'
adding 'grafit/images/gauss.png'
adding 'grafit/images/gauss2D.jpg'
adding 'grafit/images/linear.png'
adding 'grafit/images/lorentz.png'
adding 'grafit/images/mask_circle_grey.png'
adding 'grafit/images/mask_polygon_grey.png'
adding 'grafit/images/mask_rectangle_grey.png'
adding 'grafit/images/planar.jpg'
adding 'grafit/images/power.png'
adding 'grafit/images/quadratic.png'
adding 'grafit/images/sigma.jpg'
adding 'grafit/images/sinus.png'
adding 'grafit/images/square_sponge.png'
adding 'grafit/images/step.png'
adding 'grafit/images/voigt.png'
adding 'grafit/images/weight.png'
adding 'grafit/images/y_full_range.png'



the data files are installed with dpkg-buildpackage but not within sbuild.

So my question is : is it normal.

thanks for your help.

Frederic

[toc] | [next] | [standalone]

#16896

El 11/6/25 a las 15:39, PICCA Frederic-Emmanuel escribió:
> Now if I build the package within sbuild I get this file list.
> [...] 
> And with a simple dpkg-buildpackage on unstable distribution.
> [...]

When using dpkg-buildpackage, try at least using a chroot containing
only build-essential packages and the build-dependencies.

If you have more packages installed than that, there is no guarantee
that the end result will be the same.

Thanks.

[toc] | [prev] | [next] | [standalone]

#16897

> When using dpkg-buildpackage, try at least using a chroot containing
> only build-essential packages and the build-dependencies.

both are using the python -m build method...

so the setuptools build system has different behaviour depending on other installed  packages ?

Fred

[toc] | [prev] | [next] | [standalone]

#16898

El 11/6/25 a las 16:52, PICCA Frederic-Emmanuel escribió:
>> When using dpkg-buildpackage, try at least using a chroot containing
>> only build-essential packages and the build-dependencies.
> 
> both are using the python -m build method...
> 
> so the setuptools build system has different behaviour depending on other installed  packages ?

That's what it seems, yes.

If you want to be sure, you could in theory start from a minimal chroot,
then try adding the packages that you have in your unstable system,
one by one, until the end result becomes different.

In fact, you have discovered a potential Build-Conflicts, but the number
of potential build-conflicts is so big that many people would
not consider worthy to know which one it is (unless you are curious).

In practice, we just take for granted that the build should
be done in a minimal chroot.

Thanks.

[toc] | [prev] | [next] | [standalone]

#16899

El 11/6/25 a las 17:10, PICCA Frederic-Emmanuel escribió:
> It seems that this is due to setuptools-scm which provide the list of the data during the dpkg-buildpackage.

That's it. You can now add setuptools-scm to build-conflicts if it makes you happy.
It might help some people (for example, you in another parallel universe who
still don't know this), but there is no policy requirement to add build-conflicts.

Thanks.

[toc] | [prev] | [next] | [standalone]

#16900

> there is no policy requirement to add build-conflicts.

Or maybe it is but most people believe they are not really useful
if we all use minimal chroots.

[toc] | [prev] | [next] | [standalone]

#16902

El 11/6/25 a las 17:27, PICCA Frederic-Emmanuel escribió:
> setuptools-scm is also use in order to generate the version number.
> 
> Our packaging tools are dealing with this ?

The version number is in the very first line of debian/changelog.

[toc] | [prev] | [next] | [standalone]

#16909

> The version number is in the very first line of debian/changelog.

Yes I can use this and extract the version number by myself. 

reading this, 

https://salsa.debian.org/python-team/packages/setuptools-scm/-/blob/master/debian/README.Debian?ref_type=heads


There is no information about the data file list...

and it seems that the default of setuptools (install all data files)

is overrided by the scm logic, no .git directory means no data file to install...


Fred

[toc] | [prev] | [next] | [standalone]

#16911

Hi PICCA (2025.06.11_15:37:48_+0000)
>There is no information about the data file list...

It is SOURCES.txt, see for example #1052854.

I don't think setuptools-scm is even parsing it (I can't see any code 
doing so), it must be setuptools parsing it, itself.

Stefano

-- 
Stefano Rivera
   http://tumbleweed.org.za/
   +1 415 683 3272

[toc] | [prev] | [next] | [standalone]

#16903

setuptools-scm is also use in order to generate the version number.

Our packaging tools are dealing with this ?

[toc] | [prev] | [next] | [standalone]

#16905

[Multipart message — attachments visible in raw view] — view raw

On Wed, Jun 11, 2025 at 05:25:41PM +0200, Santiago Vila wrote:
> El 11/6/25 a las 17:10, PICCA Frederic-Emmanuel escribió:
> > It seems that this is due to setuptools-scm which provide the list of the data during the dpkg-buildpackage.
> 
> That's it. You can now add setuptools-scm to build-conflicts if it makes you happy.
> It might help some people (for example, you in another parallel universe who
> still don't know this), but there is no policy requirement to add build-conflicts.

So declaring a conflict on setuptools-scm may be a bit tricky, since it is
also listed in the upstream's pyproject.toml file, although, of course,
it may be patched out. If anything, a conflict should be declared against
the "git" package :)

However, it seems the upstream build actually depends on setuptools-scm now,
they (you? :)) don't use any other way to tell the build system about
the data files - the *.png images, the *.rst documentation, etc..
This... may be a problem if the package is not built out of a Git checkout
with Git itself present... and Debian packages are usually expected to be
built out of a plain extracted source archive, no `.git/`, no anything.

I'd suggest making some changes upstream, like listing the data files yourself:
  https://setuptools.pypa.io/en/latest/userguide/datafiles.html

(or, of course, switching away from setuptools, but any build system you choose
 may still need to be configured to include the data files along with your
 Python module sources, although some of them do this by default for most files)

G'luck,
Peter

-- 
Peter Pentchev  roam@ringlet.net roam@debian.org peter@morpheusly.com
PGP key:        https://www.ringlet.net/roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13

[toc] | [prev] | [next] | [standalone]

#16907

[Multipart message — attachments visible in raw view] — view raw

On Wed, Jun 11, 2025 at 05:44:07PM +0200, PICCA Frederic-Emmanuel wrote:
> > However, it seems the upstream build actually depends on setuptools-scm now,
> > they (you? :)) don't use any other way to tell the build system about
> > the data files - the *.png images, the *.rst documentation, etc..
> > This... may be a problem if the package is not built out of a Git checkout
> > with Git itself present... and Debian packages are usually expected to be
> > built out of a plain extracted source archive, no `.git/`, no anything.
> 
> I am just contributing to the project, specifficaly I try to add a proper pyproject.toml file.
> 
> > I'd suggest making some changes upstream, like listing the data files yourself:
> >  https://setuptools.pypa.io/en/latest/userguide/datafiles.html
> > 
> > (or, of course, switching away from setuptools, but any build system you choose
> > may still need to be configured to include the data files along with your
> > Python module sources, although some of them do this by default for most files)
> 
> setuptools is not the right tool in order to build Python projects ?

It's not that it is not the right tool, but it has accumulated a lot of
history over the years, there are a lot of things that it has to do to
maintain compatibility with older projects that were written for older
setuptools versions. Occassionally they do make incompatible changes, and there is
much wailing and gnashing of teeth, but IMHO that's not really a bad thing :)

Some newer build systems, like hatchling or flit, are more streamlined
(that's another way to say "opinionated") - they do not let you do
everything you can do with setuptools and setuptools plugins, but they
handle the most common cases with a minimal amount of configuration.

Sorry, I may have phrased my original sentence a bit too strongly -
I am NOT saying that you should migrate away from setuptools, but
I personally have found hatchling much easier to configure for simple projects.

G'luck,
Peter

-- 
Peter Pentchev  roam@ringlet.net roam@debian.org peter@morpheusly.com
PGP key:        https://www.ringlet.net/roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13

[toc] | [prev] | [next] | [standalone]

#16910

> However, it seems the upstream build actually depends on setuptools-scm now,
> they (you? :)) don't use any other way to tell the build system about
> the data files - the *.png images, the *.rst documentation, etc..
> This... may be a problem if the package is not built out of a Git checkout
> with Git itself present... and Debian packages are usually expected to be
> built out of a plain extracted source archive, no `.git/`, no anything.

I am just contributing to the project, specifficaly I try to add a proper pyproject.toml file.

> I'd suggest making some changes upstream, like listing the data files yourself:
>  https://setuptools.pypa.io/en/latest/userguide/datafiles.html
> 
> (or, of course, switching away from setuptools, but any build system you choose
> may still need to be configured to include the data files along with your
> Python module sources, although some of them do this by default for most files)

setuptools is not the right tool in order to build Python projects ?

Fred

[toc] | [prev] | [next] | [standalone]

#16901

It seems that this is due to setuptools-scm which provide the list of the data during the dpkg-buildpackage.


taken from the doc of setuptools-scm ---
Additionally setuptools-scm provides setuptools with a list of files that are managed by the SCM (i.e. it automatically adds all the SCM-managed files to the sdist). Unwanted files must be excluded via MANIFEST.in or configuring Git archive.
---

And indded via sbuild there is no .git directory so setuptools-scm do not provide the list.

Do we know how to deal with this at the pacakging level. the upstream is using the code  from the git repository, so it is not affected by this issue...

Fred

[toc] | [prev] | [next] | [standalone]

#16904

Hi PICCA (2025.06.11_15:10:53_+0000)
>And indded via sbuild there is no .git directory so setuptools-scm do not provide the list.
>
>Do we know how to deal with this at the pacakging level. the upstream is using the code  from the git repository, so it is not affected by this issue...

This is a sitation where upstream tarballs are preferable to git.

If you use an sdist, the egg-info / dist-info in the sdist will contain 
a file list that setuptools-scm can use.

Stefano

-- 
Stefano Rivera
   http://tumbleweed.org.za/
   +1 415 683 3272

[toc] | [prev] | [next] | [standalone]

#16906

> This is a sitation where upstream tarballs are preferable to git.

Yes but for now the package is only distributed via git...

Even worse, it is use via a checkout and that's all.

> If you use an sdist, the egg-info / dist-info in the sdist will contain
> a file list that setuptools-scm can use.

Maybe I can generate this sdist via uscan. It would solve my problem.

Fred

[toc] | [prev] | [next] | [standalone]

#16912

[Multipart message — attachments visible in raw view] — view raw

On Jun 11, 2025 17:57, PICCA Frederic-Emmanuel <frederic-emmanuel.picca@synchrotron-soleil.fr> wrote:

>

> > This is a sitation where upstream tarballs are preferable to git. 

>

> Yes but for now the package is only distributed via git... 

>

> Even worse, it is use via a checkout and that's all. 

>

> > If you use an sdist, the egg-info / dist-info in the sdist will contain 

> > a file list that setuptools-scm can use. 

>

> Maybe I can generate this sdist via uscan. It would solve my problem. 

>

> Fred


Don't do that. Just add a MANIFEST.in and write in it:


recusive-include <folder-name> *


(Something like that...)


and setuptools will likely package all data files. I did that in MANY OpenStack packages. I can find one example if you need one.


As for the version, setuptools-scm understand an env var that you may set with something like:


export SETUPTOOLS_SCM_PRETEND_VERSION=$(shell dpkg-parsechangelog -something)


(Again, top of my head, look it up on other packages to get it right, and you can ask me again if you cant find it yourself...)


Then both your issues will be fixed.


Hoping this helps,

Cheers,


Thomas Goirand (zigo)

[toc] | [prev] | [next] | [standalone]

#16913

Hi thomas (2025.06.11_16:30:15_+0000)
>As for the version, setuptools-scm understand an env var that you may set with something like:
>export SETUPTOOLS_SCM_PRETEND_VERSION=$(shell dpkg-parsechangelog -something)

You don't need to do that, pybuild does it for you.

Stefano

-- 
Stefano Rivera
   http://tumbleweed.org.za/
   +1 415 683 3272

[toc] | [prev] | [next] | [standalone]

#16914

Hi PICCA (2025.06.11_17:14:36_+0000)

>> Hi thomas (2025.06.11_16:30:15_+0000)
>>>As for the version, setuptools-scm understand an env var that you may set with
>>>something like:
>>>export SETUPTOOLS_SCM_PRETEND_VERSION=$(shell dpkg-parsechangelog -something)
>
>the same kind of things is availalbe also for hatchling-vcs ?

python3-hatch-vcs is actually just a thin wrapper around setuptools-vcs, 
so yes.

And again, you don't need to export this, pybuild does it for you.

Stefano

-- 
Stefano Rivera
   http://tumbleweed.org.za/
   +1 415 683 3272

[toc] | [prev] | [next] | [standalone]

#16918

Hi PICCA (2025.06.12_09:12:58_+0000)

>I: pybuild plugin_pyproject:144: Unpacking wheel built for python3.13 with "installer" module
>E: pybuild pybuild:389: build: plugin pyproject failed with:
>dh_auto_build: error: pybuild --build -i python{version} -p 3.13 returned exit code 13
>make: *** [debian/rules:11: binary] Error 25
>dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
>
>
>The error message is  quite usefull :))

Indeed.

If you want help looking at it, I suggest pushing to git.

Stefano

-- 
Stefano Rivera
   http://tumbleweed.org.za/
   +1 415 683 3272

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.maint.python

csiph-web