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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 [email protected] [email protected] [email protected]
PGP key: https://www.ringlet.net/roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEELuenpRf8EkzxFcNUZR7vsCUn3xMFAmhJo4IACgkQZR7vsCUn 3xOZtQ//XaTK6PduOy9ZDNv2tXpV8XGMfoUl1Ap4pN5kOjD7ab50qmuBZPmgYrrY yttlxr9T4fnMgpgCvJitM/GQliOE0xbLssqyCQvCEtbkppfzsQRHOldFZKsRDfmr UbfswmnhquGWyg4j/FGDh6SScNZlvji3RelB5Up7hMDjvE9K5RvoOQ0YQA0NdC8L RQ8YgNyhOc1vDJRjuh8Tqk8Gmoa6Xy6eSF8HobeWpsrWpsYqyjAQe7npjoh4S1Az I1wWD56FZuWwNJFepf2e5zpggssfkXyoXq4JRBMx+g2Tqihb+BCdckT06p/Xn7M/ dXEQdQv5gOV+WFt57lJmKIZzcG0Vznn1XXNRTWTbx8484vVYdKyRUI7MP3J+cdFJ XVYRF+tYybJQ6hRplAfsNsjQDJZ/lI/f0MMkxSwdEfGYqK/uDAhrsvAdO1ISKL+O aFW9Jk3UVfJw04kD/PQDs9IKTfCoSxdeFntszydnkT4TFzfvxpT+olwP0AovI/3G Px6caHOfwRCT3Ny0UPW1xxLWhVZgO8cm0ZV9UBiNpfHng26RHi7gUhlcRCsqA0t2 REHT+rTUW06Op+craZbWAjzQM64O00MmkDUOrh0PQzP8IH3zXR5Os9FS0KzpdVe1 q3TvWko3vcym28eacXMPa/br1ljoWITx+0oUgLx94S4W5dKWvWU=
=VhXp

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

Our packaging tools are dealing with this ?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, Jun 11, 2025 at 03:35:54PM +0000, Stefano Rivera wrote:

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.

Yeah, that's something I thought I would mention, but I thought I'd try it first
and then I forgot :) It is entirely possible that basing the Debian packaging on
the sdist tarball would "just work".

G'luck,
Peter

--
Peter Pentchev [email protected] [email protected] [email protected]
PGP key: https://www.ringlet.net/roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEELuenpRf8EkzxFcNUZR7vsCUn3xMFAmhJptUACgkQZR7vsCUn 3xNhlBAAoRDFhZFsH7wQ4Fo4lzUhKox1NchS5ZxNVLTqRdQab0hO0YAYryN6rJmH tS9A05n2epr3ioKreb5luQmaeZFtUoarllrGzk5dF6IJooFfHpADpuaTtBopEfRt fWWrepHGaqf+wZA83lFvjoBWB7HhPAYUCaxGpt0QZzCWAouUeY3u1gCDxtE+Zsr7 2rH1TBnQLIvh2XWhI81p6aFynVpfe+iqqDKXyuGdktzhPj62Kii5/bpRQwh39ct2 XslOFxGUCdBcnjpHDUjzvPMo7z5mcmXCmax3dQQ3ilSh8KzAMAr+Voz4dPpKjaIV RhPeNSVciELduLBuF3WyheA+fS9KyiM4SWmU8iFCll7vxVOS1YHdAvi6DRrxxb3b bIkqGSsm9eRwlnGZo7UjlMWvLkBdyHnZD9FI8NzwQgLX24nF/WfRSitxrrf2MUBI aJdsW2XY2tk5UnVAG61g68DMUcnfZvhJJYdhdygsUJyiKJAcun9ELvAAVQsgc7gA OuItT0JkgUEj6N6PSbfJ5jyEwqfIxKvxUsTwM6H82Kka4DIBb3K0i32XYEH4SuvC 7wkqxPbJ3giSYRnd/bK0DkY7oi/d+aujSqGNRkGMqQRr4MkLBiPKb4usDXwFd/PQ l4BUNjEM06ANfujSMQPLqLQlhp91zK1cmFCuLc59Qk1uMU/1BZU=
=ham0

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 [email protected] [email protected] [email protected]
PGP key: https://www.ringlet.net/roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEELuenpRf8EkzxFcNUZR7vsCUn3xMFAmhJpfcACgkQZR7vsCUn 3xPKjBAAl6IG9bm01Fv2zE1HjWZsnLyLSCo/tASidVx5VwoUdO9syeIwfXPBBuJ6 6jSwIY4Xhihax5juZ8U5dfxoAObN7vZPxJI1NJAdfXM3TK3VxuKncADxbFM60/of xl6Mh7LL4eEJ0v581aWD0vfpgESkXL0ZGmQqtuqR+PrsVV7iPQAteTqNPmIMaNI2 wdxpOZPjSgzLH9bflms/jyqhoDE3rejoEhjbU2ndXtd0Uf9aa1Nc2S6CPqbyqZG3 NbZujOdSq16wEgoVI9/wE6B0tw2Rw05OrZQvYCRZZQRSb1LD1nBduPpeyRtzQ4PE eoFY4LghepkM3TwWwZDlHPyCAR6saVPtkUmHjYxetHWFMmytfm9kI41jgNm5yyNx Xop8H+snmAHwcSNRNh4GIWN/MpALvU6bO5AND1HVcF6MWRB3fr5INJRxOWibKCBb PRU0LinR7MJAprDYdAT+lhtHNRkS8kjeQ62OjxKs20ksNCX1xR6JtUCw9IhZOhoe bnNbVxvQd+9hbNqZmzDOmeEcpzEAoOeAcrG+VIcm1BZjanU5cpwskDKWK4uBLPij 2jfHdbngzEOYxx+t3N4xFo7EFSha/DvS8vHbAVcOOqxtdfWWxF7kNz7Z/PEtv1Kc JyzjHGtEO+Eab79Gczs84hE8rmR7gFtm/n5Lit+TZIJ6dIJSlK8=
=7RbS

CgpPbiBKdW4gMTEsIDIwMjUgMTc6NTcsIFBJQ0NBIEZyZWRlcmljLUVtbWFudWVsIDxmcmVkZXJp Yy1lbW1hbnVlbC5waWNjYUBzeW5jaHJvdHJvbi1zb2xlaWwuZnI+IHdyb3RlOgoKPgoKPiA+IFRo aXMgaXMgYSBzaXRhdGlvbiB3aGVyZSB1cHN0cmVhbSB0YXJiYWxscyBhcmUgcHJlZmVyYWJsZSB0 byBnaXQuIAoKPgoKPiBZZXMgYnV0IGZvciBub3cgdGhlIHBhY2thZ2UgaXMgb25seSBkaXN0cmli dXRlZCB2aWEgZ2l0Li4uIAoKPgoKPiBFdmVuIHdvcnNlLCBpdCBpcyB1c2UgdmlhIGEgY2hlY2tv dXQgYW5kIHRoYXQncyBhbGwuIAoKPgoKPiA+IElmIHlvdSB1c2UgYW4gc2Rpc3QsIHRoZSBlZ2ct aW5mbyAvIGRpc3QtaW5mbyBpbiB0aGUgc2Rpc3Qgd2lsbCBjb250YWluIAoKPiA+IGEgZmlsZSBs aXN0IHRoYXQgc2V0dXB0b29scy1zY20gY2FuIHVzZS4gCgo+Cgo+IE1heWJlIEkgY2FuIGdlbmVy YXRlIHRoaXMgc2Rpc3QgdmlhIHVzY2FuLiBJdCB3b3VsZCBzb2x2ZSBteSBwcm9ibGVtLiAKCj4K Cj4gRnJlZAoKCkRvbid0IGRvIHRoYXQuIEp1c3QgYWRkIGEgTUFOSUZFU1QuaW4gYW5kIHdyaXRl IGluIGl0OgoKCnJlY3VzaXZlLWluY2x1ZGUgPGZvbGRlci1uYW1lPiAqCgoKKFNvbWV0aGluZyBs aWtlIHRoYXQuLi4pCgoKYW5kIHNldHVwdG9vbHMgd2lsbCBsaWtlbHkgcGFja2FnZSBhbGwgZGF0 YSBmaWxlcy4gSSBkaWQgdGhhdCBpbiBNQU5ZIE9wZW5TdGFjayBwYWNrYWdlcy4gSSBjYW4gZmlu ZCBvbmUgZXhhbXBsZSBpZiB5b3UgbmVlZCBvbmUuCgoKQXMgZm9yIHRoZSB2ZXJzaW9uLCBzZXR1 cHRvb2xzLXNjbSB1bmRlcnN0YW5kIGFuIGVudiB2YXIgdGhhdCB5b3UgbWF5IHNldCB3aXRoIHNv bWV0aGluZyBsaWtlOgoKCmV4cG9ydCBTRVRVUFRPT0xTX1NDTV9QUkVURU5EX1ZFUlNJT049JChz aGVsbCBkcGtnLXBhcnNlY2hhbmdlbG9nIC1zb21ldGhpbmcpCgoKKEFnYWluLCB0b3Agb2YgbXkg aGVhZCwgbG9vayBpdCB1cCBvbiBvdGhlciBwYWNrYWdlcyB0byBnZXQgaXQgcmlnaHQsIGFuZCB5 b3UgY2FuIGFzayBtZSBhZ2FpbiBpZiB5b3UgY2FudCBmaW5kIGl0IHlvdXJzZWxmLi4uKQoKClRo ZW4gYm90aCB5b3VyIGlzc3VlcyB3aWxsIGJlIGZpeGVkLgoKCkhvcGluZyB0aGlzIGhlbHBzLAoK Q2hlZXJzLAoKClRob21hcyBHb2lyYW5kICh6aWdvKQoKCg== PGh0bWw+PGJvZHk+PGJyPjxkaXYgZGlyPSJsdHIiPk9uIEp1biAxMSwgMjAyNSAxNzo1NywgUElD Q0EgRnJlZGVyaWMtRW1tYW51ZWwgJmx0O2ZyZWRlcmljLWVtbWFudWVsLnBpY2NhQHN5bmNocm90 cm9uLXNvbGVpbC5mciZndDsgd3JvdGU6PC9kaXY+CjxkaXYgZGlyPSJsdHIiPiZndDs8L2Rpdj4K PGRpdiBkaXI9Imx0ciI+Jmd0OyAmZ3Q7IFRoaXMgaXMgYSBzaXRhdGlvbiB3aGVyZSB1cHN0cmVh bSB0YXJiYWxscyBhcmUgcHJlZmVyYWJsZSB0byBnaXQuIDwvZGl2Pgo8ZGl2IGRpcj0ibHRyIj4m Z3Q7PC9kaXY+CjxkaXYgZGlyPSJsdHIiPiZndDsgWWVzIGJ1dCBmb3Igbm93IHRoZSBwYWNrYWdl IGlzIG9ubHkgZGlzdHJpYnV0ZWQgdmlhIGdpdC4uLiA8L2Rpdj4KPGRpdiBkaXI9Imx0ciI+Jmd0 OzwvZGl2Pgo8ZGl2IGRpcj0ibHRyIj4mZ3Q7IEV2ZW4gd29yc2UsIGl0IGlzIHVzZSB2aWEgYSBj aGVja291dCBhbmQgdGhhdCYjMzk7cyBhbGwuIDwvZGl2Pgo8ZGl2IGRpcj0ibHRyIj4mZ3Q7PC9k aXY+CjxkaXYgZGlyPSJsdHIiPiZndDsgJmd0OyBJZiB5b3UgdXNlIGFuIHNkaXN0LCB0aGUgZWdn LWluZm8gLyBkaXN0LWluZm8gaW4gdGhlIHNkaXN0IHdpbGwgY29udGFpbiA8L2Rpdj4KPGRpdiBk aXI9Imx0ciI+Jmd0OyAmZ3Q7IGEgZmlsZSBsaXN0IHRoYXQgc2V0dXB0b29scy1zY20gY2FuIHVz ZS4gPC9kaXY+CjxkaXYgZGlyPSJsdHIiPiZndDs8L2Rpdj4KPGRpdiBkaXI9Imx0ciI+Jmd0OyBN YXliZSBJIGNhbiBnZW5lcmF0ZSB0aGlzIHNkaXN0IHZpYSB1c2Nhbi4gSXQgd291bGQgc29sdmUg bXkgcHJvYmxlbS4gPC9kaXY+CjxkaXYgZGlyPSJsdHIiPiZndDs8L2Rpdj4KPGRpdiBkaXI9Imx0 ciI+Jmd0OyBGcmVkPC9kaXY+Cjxicj48ZGl2IGRpcj0ibHRyIj5Eb24mIzM5O3QgZG8gdGhhdC4g SnVzdCBhZGQgYSBNQU5JRkVTVC5pbiBhbmQgd3JpdGUgaW4gaXQ6PC9kaXY+Cjxicj48ZGl2IGRp cj0ibHRyIj5yZWN1c2l2ZS1pbmNsdWRlICZsdDtmb2xkZXItbmFtZSZndDsgKjwvZGl2Pgo8YnI+ PGRpdiBkaXI9Imx0ciI+KFNvbWV0aGluZyBsaWtlIHRoYXQuLi4pPC9kaXY+Cjxicj48ZGl2IGRp cj0ibHRyIj5hbmQgc2V0dXB0b29scyB3aWxsIGxpa2VseSBwYWNrYWdlIGFsbCBkYXRhIGZpbGVz LiBJIGRpZCB0aGF0IGluIE1BTlkgT3BlblN0YWNrIHBhY2thZ2VzLiBJIGNhbiBmaW5kIG9uZSBl eGFtcGxlIGlmIHlvdSBuZWVkIG9uZS48L2Rpdj4KPGJyPjxkaXYgZGlyPSJsdHIiPkFzIGZvciB0 aGUgdmVyc2lvbiwgc2V0dXB0b29scy1zY20gdW5kZXJzdGFuZCBhbiBlbnYgdmFyIHRoYXQgeW91 IG1heSBzZXQgd2l0aCBzb21ldGhpbmcgbGlrZTo8L2Rpdj4KPGJyPjxkaXYgZGlyPSJsdHIiPmV4 cG9ydCBTRVRVUFRPT0xTX1NDTV9QUkVURU5EX1ZFUlNJT049JChzaGVsbCBkcGtnLXBhcnNlY2hh bmdlbG9nIC1zb21ldGhpbmcpPC9kaXY+Cjxicj48ZGl2IGRpcj0ibHRyIj4oQWdhaW4sIHRvcCBv ZiBteSBoZWFkLCBsb29rIGl0IHVwIG9uIG90aGVyIHBhY2thZ2VzIHRvIGdldCBpdCByaWdodCwg YW5kIHlvdSBjYW4gYXNrIG1lIGFnYWluIGlmIHlvdSBjYW50IGZpbmQgaXQgeW91cnNlbGYuLi4p PC9kaXY+Cjxicj48ZGl2IGRpcj0ibHRyIj5UaGVuIGJvdGggeW91ciBpc3N1ZXMgd2lsbCBiZSBm aXhlZC48L2Rpdj4KPGJyPjxkaXYgZGlyPSJsdHIiPkhvcGluZyB0aGlzIGhlbHBzLDwvZGl2Pgo8 ZGl2IGRpcj0ibHRyIj5DaGVlcnMsPC9kaXY+Cjxicj48ZGl2IGRpcj0ibHRyIj5UaG9tYXMgR29p cmFuZCAoemlnbyk8L2Rpdj4KPGJyPjwvYm9keT48L2h0bWw+

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 ?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

CgpPbiBKdW4gMTEsIDIwMjUgMTg6NTEsIFN0ZWZhbm8gUml2ZXJhIDxzdGVmYW5vckBkZWJpYW4u b3JnPiB3cm90ZToKCj4KCj4gSGkgdGhvbWFzICgyMDI1LjA2LjExXzE2OjMwOjE1XyswMDAwKSAK Cj4gPkFzIGZvciB0aGUgdmVyc2lvbiwgc2V0dXB0b29scy1zY20gdW5kZXJzdGFuZCBhbiBlbnYg dmFyIHRoYXQgeW91IG1heSBzZXQgd2l0aCBzb21ldGhpbmcgbGlrZTogCgo+ID5leHBvcnQgU0VU VVBUT09MU19TQ01fUFJFVEVORF9WRVJTSU9OPSQoc2hlbGwgZHBrZy1wYXJzZWNoYW5nZWxvZyAt c29tZXRoaW5nKSAKCj4KCj4gWW91IGRvbid0IG5lZWQgdG8gZG8gdGhhdCwgcHlidWlsZCBkb2Vz IGl0IGZvciB5b3UuIAoKPgoKPiBTdGVmYW5vIAoKClllYWgsIElGIHVzaW5nIHB5YnVpbGQuLi4g OikKCgooV2hpY2ggSSBhbSB0aGVzZSBkYXlzLCB0aG91Z2ggaXQgaXMgbm90IG1hbmRhdG9yeSkK CgpUaG9tYXMKCgo= PGh0bWw+PGJvZHk+PGJyPjxkaXYgZGlyPSJsdHIiPk9uIEp1biAxMSwgMjAyNSAxODo1MSwgU3Rl ZmFubyBSaXZlcmEgJmx0O3N0ZWZhbm9yQGRlYmlhbi5vcmcmZ3Q7IHdyb3RlOjwvZGl2Pgo8ZGl2 IGRpcj0ibHRyIj4mZ3Q7PC9kaXY+CjxkaXYgZGlyPSJsdHIiPiZndDsgSGkgdGhvbWFzICgyMDI1 LjA2LjExXzE2OjMwOjE1XyswMDAwKSA8L2Rpdj4KPGRpdiBkaXI9Imx0ciI+Jmd0OyAmZ3Q7QXMg Zm9yIHRoZSB2ZXJzaW9uLCBzZXR1cHRvb2xzLXNjbSB1bmRlcnN0YW5kIGFuIGVudiB2YXIgdGhh dCB5b3UgbWF5IHNldCB3aXRoIHNvbWV0aGluZyBsaWtlOiA8L2Rpdj4KPGRpdiBkaXI9Imx0ciI+ Jmd0OyAmZ3Q7ZXhwb3J0IFNFVFVQVE9PTFNfU0NNX1BSRVRFTkRfVkVSU0lPTj0kKHNoZWxsIGRw a2ctcGFyc2VjaGFuZ2Vsb2cgLXNvbWV0aGluZykgPC9kaXY+CjxkaXYgZGlyPSJsdHIiPiZndDs8 L2Rpdj4KPGRpdiBkaXI9Imx0ciI+Jmd0OyBZb3UgZG9uJiMzOTt0IG5lZWQgdG8gZG8gdGhhdCwg cHlidWlsZCBkb2VzIGl0IGZvciB5b3UuIDwvZGl2Pgo8ZGl2IGRpcj0ibHRyIj4mZ3Q7PC9kaXY+ CjxkaXYgZGlyPSJsdHIiPiZndDsgU3RlZmFubyA8L2Rpdj4KPGJyPjxkaXYgZGlyPSJsdHIiPlll YWgsIElGIHVzaW5nIHB5YnVpbGQuLi4gOik8L2Rpdj4KPGJyPjxkaXYgZGlyPSJsdHIiPihXaGlj aCBJIGFtIHRoZXNlIGRheXMsIHRob3VnaCBpdCBpcyBub3QgbWFuZGF0b3J5KTwvZGl2Pgo8YnI+ PGRpdiBkaXI9Imx0ciI+VGhvbWFzPC9kaXY+Cjxicj48L2JvZHk+PC9odG1sPg==

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

thanks you all,

I added a MANIFEST.in file and create an entry point for the application script


I end up with this error

adding 'xrdutils-0.0.4.dist-info/licenses/LICENSE'
adding 'xrdutils-0.0.4.dist-info/METADATA'
adding 'xrdutils-0.0.4.dist-info/WHEEL'
adding 'xrdutils-0.0.4.dist-info/entry_points.txt'
adding 'xrdutils-0.0.4.dist-info/top_level.txt'
adding 'xrdutils-0.0.4.dist-info/RECORD'
removing build/bdist.linux-x86_64/wheel
Successfully built xrdutils-0.0.4-py3-none-any.whl
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 :))

cheers

Fred

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I found the culprite :)..

a malformed entry_point.

"toto.test" instead of "toto.test:main"

Is there a linter for the pyprojects file ?

Thanks for your help.

Fred

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)