Re: Request to join the Debian Python Team

[Stefano Rivera]

Hi Gregory (2024.11.17_22:59:49_+)
> I would like to join the Debian Python Team to take care of "ansible-lint" 
> package.

Added, welcome to the team.

And thanks for the work on MiniDebConf Toulouse, it was excellent!

Stefano

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

LICENSES folder in /usr/share/doc/ ?

[c . buhtz]

Hello,

I was not sure which list is appropriate for this question. Because of 
that I try it here because I am quit familiar with this community.


To my understanding of the policy the license file of package should be 
installed into


/usr/share/doc//LICENSE

How to handle it if a project does have multiple license files?

According to the REUSE standard (itself related to SPDX standard) an 
upstream repository should have a folder named LICENSES containing the 
licenses. See [1] as an example.


Would it be OK, just installing that folder in Debian GNU/Linux the same 
way?


/usr/share/doc//LICENSES/*.txt

Regards,
Christian


[1] -- 

Re: LICENSES folder in /usr/share/doc/ ?

[c . buhtz]

Hello Stefano,

thank you for your reply.

Am 18.11.2024 13:55 schrieb Stefano Rivera:
To my understanding of the policy the license file of package should 
be

installed into

/usr/share/doc//LICENSE


It's spelled: /usr/share/doc//copyright


To my understand the "copyright" file is something Debian specific.
This does not exist in my upstream project but is "generated" by my 
Debian Package Maintainer.
There are several packages (e.g. "backintime-common" and 
"backintime-qt") containing LICENSE

file and copyright file in that folder side by side.

Just assume that my DPM does handle the copyright file by himself in an 
appropriate way.


But what about LICNESE file and a LICENSES folder for multiple licenses 
files?



This scheme looks less expressive than Debian's machine-readable 
format.


SPDX is designed to be human- and machine readable. There is also a 
linter "reuse lint".
I am also aware of Debian internal approaches to generate Debian policy 
conform copyright

and license information based on SPDX meta data.

Regards,
Christian

Re: LICENSES folder in /usr/share/doc/ ?

[Soren Stoutner]

On Monday, November 18, 2024 8:57:49 AM MST c.bu...@posteo.jp wrote:
> Regarding the lintian tag am I assuming correct that Debian GNU/Linux
> does not care about a LICENSE file or LICENSES folder?
> So there is no real problem to have a LICENSES folder?
> The "copyright" file will exist (downstream) no matter if there is a
> LICENSE file, a LICENSES folder or any of this.

The debian/copyright file must contain all the copyright information AND all 
the license information.  All the licenses from all the LICENSES files must be 
copied into debian/copyright (the full text of common licenses can be 
referenced against usr/share/common-licenses).  Upstream LICENSES files should 
not be shipped in Debian.

-- 
Soren Stoutner
so...@debian.org

signature.asc
Description: This is a digitally signed message part.

Re: LICENSES folder in /usr/share/doc/ ?

[c . buhtz]

Hello Andrey,
Thank you for the reply.

Am 18.11.2024 15:26 schrieb Andrey Rakhmatullin:

On Mon, Nov 18, 2024 at 01:41:34PM +, c.bu...@posteo.jp wrote:

To my understand the "copyright" file is something Debian specific.
This does not exist in my upstream project but is "generated" by my 
Debian

Package Maintainer.


Correct. Which is what you were asking about.


IMHO not. But that seems to be because of our different perspectives.


And lintian has an extra-license-file tag for such packages.


https://udd.debian.org/lintian-tag/extra-license-file

Ah... Now, we come closer.

But what about LICNESE file and a LICENSES folder for multiple 
licenses

files?


What about them that wasn't answered in the email you quoted and in the
Policy?


To my understand that wasn't answered.

Regarding the lintian tag am I assuming correct that Debian GNU/Linux 
does not care about a LICENSE file or LICENSES folder?

So there is no real problem to have a LICENSES folder?
The "copyright" file will exist (downstream) no matter if there is a 
LICENSE file, a LICENSES folder or any of this.


Correct?

Regards,
Christian

Re: f2py problem with Multi-Python (and Ninja)

[Andrey Rakhmatullin]

On Mon, Nov 18, 2024 at 04:07:32PM +0100, Ole Streicher wrote:
> >>Build log is f.e.
> >>https://salsa.debian.org/debian-astro-team/pybdsf/-/jobs/6612895
> > The problem is most likely caused by "find_package(F2PY)", which does
> > not take different Python versions into account [1].
> 
> This is indeed the case. But shouldn't that be adjusted for Debian (or
> even upstream)? Setting f2py different from the Python minor version
> seems a bug to me.

If the upstream of f2py doesn't provide f2pyX.Y binaries, the only way to
adjust this seems to be switching FindF2PY.cmake to run it via `pythonX.Y
-m`.

> At the end, everybody tyrying to run a project that uses
> "find_package(F2PY)" for a non-default Python version on Debian will
> stumble upon it, which is a bit contrary to the idea of having CMake
> figuring the required configuration.

Sure, if the FindF2PY.cmake upstream wants this use case to be supported
by it.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: f2py problem with Multi-Python (and Ninja)

[Timo Röhling]

Hi Ole,

* Ole Streicher  [2024-11-18 13:40]:

Build log is f.e.
https://salsa.debian.org/debian-astro-team/pybdsf/-/jobs/6612895
The problem is most likely caused by "find_package(F2PY)", which 
does not take different Python versions into account [1].


Debian ships with f2pyX.Y scripts for each supported Python version.
Alternatively, the example code in the NumPy documentation [2] 
invokes f2py via "${Python_EXECUTABLE} -m numpy.f2py", which should 
also work with skbuild.



Cheers
Timo

[1] 
https://salsa.debian.org/python-team/packages/scikit-build/-/blob/debian/master/skbuild/resources/cmake/FindF2PY.cmake?ref_type=heads#L69

[2] https://numpy.org/doc/1.26/f2py/buildtools/cmake.html


--
⢀⣴⠾⠻⢶⣦⠀   ╭╮
⣾⠁⢠⠒⠀⣿⡁   │ Timo Röhling   │
⢿⡄⠘⠷⠚⠋⠀   │ 9B03 EBB9 8300 DF97 C2B1  23BF CC8C 6BDD 1403 F4CA │
⠈⠳⣄   ╰╯


signature.asc
Description: PGP signature

Re: LICENSES folder in /usr/share/doc/ ?

[Andrey Rakhmatullin]

On Mon, Nov 18, 2024 at 01:41:34PM +, c.bu...@posteo.jp wrote:
> > > To my understanding of the policy the license file of package should
> > > be
> > > installed into
> > > 
> > > /usr/share/doc//LICENSE
> > 
> > It's spelled: /usr/share/doc//copyright
> 
> To my understand the "copyright" file is something Debian specific.
> This does not exist in my upstream project but is "generated" by my Debian
> Package Maintainer.

Correct. Which is what you were asking about.

> There are several packages (e.g. "backintime-common" and "backintime-qt")
> containing LICENSE
> file and copyright file in that folder side by side.

And lintian has an extra-license-file tag for such packages.

> Just assume that my DPM does handle the copyright file by himself in an
> appropriate way.
> 
> But what about LICNESE file and a LICENSES folder for multiple licenses
> files?

What about them that wasn't answered in the email you quoted and in the
Policy?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: LICENSES folder in /usr/share/doc/ ?

[Paul Boddie]

On Monday, 18 November 2024 16:57:49 CET c.bu...@posteo.jp wrote:
> 
> To my understand that wasn't answered.

Yes, the collection of licences is something distinct from the copyright 
information. In REUSE, the copyright information is maintained in a manifest 
that should be compatible with the DEP-5 format.

> Regarding the lintian tag am I assuming correct that Debian GNU/Linux
> does not care about a LICENSE file or LICENSES folder?
> So there is no real problem to have a LICENSES folder?

I imagine that there will be a desire to prevent duplicate files being 
installed, since there is /usr/share/common-licenses which is meant to hold 
standard licence texts. Of course, custom licences would not feature among the 
common-licenses and this is where REUSE's own licences collection for each 
package could be useful, but some custom licences might preclude software from 
being available in Debian in the first place.

> The "copyright" file will exist (downstream) no matter if there is a
> LICENSE file, a LICENSES folder or any of this.

Indeed.

Paul

Re: LICENSES folder in /usr/share/doc/ ?

[Stefano Rivera]

Hi c.buhtz (2024.11.18_12:31:01_+)
> I was not sure which list is appropriate for this question. Because of that
> I try it here because I am quit familiar with this community.
> 
> To my understanding of the policy the license file of package should be
> installed into
> 
> /usr/share/doc//LICENSE

It's spelled: /usr/share/doc//copyright

> How to handle it if a project does have multiple license files?

We combine them all into a single file. See:
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

> According to the REUSE standard (itself related to SPDX standard) an
> upstream repository should have a folder named LICENSES containing the
> licenses. See [1] as an example.
> 
> Would it be OK, just installing that folder in Debian GNU/Linux the same
> way?
> 
> /usr/share/doc//LICENSES/*.txt

I'm afraid not, that wouldn't comply with policy, §12.5 is fairly
specific.

https://www.debian.org/doc/debian-policy/ch-docs.html#s-copyrightfile
https://www.debian.org/doc/debian-policy/ch-source.html#copyright-debian-copyright

Not that policy can't be changed, but there'd need to be a good reason.
This scheme looks less expressive than Debian's machine-readable format.

Stefano

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

Re: LICENSES folder in /usr/share/doc/ ?

[Andrey Rakhmatullin]

On Mon, Nov 18, 2024 at 03:57:49PM +, c.bu...@posteo.jp wrote:
> > > To my understand the "copyright" file is something Debian specific.
> > > This does not exist in my upstream project but is "generated" by my
> > > Debian
> > > Package Maintainer.
> > 
> > Correct. Which is what you were asking about.
> 
> IMHO not. But that seems to be because of our different perspectives.

If you weren't actually asking about the requirements of the Policy then
you shouldn't have mentioned it...

> > And lintian has an extra-license-file tag for such packages.
> 
> https://udd.debian.org/lintian-tag/extra-license-file
> 
> Ah... Now, we come closer.
> 
> > > But what about LICNESE file and a LICENSES folder for multiple
> > > licenses
> > > files?
> > 
> > What about them that wasn't answered in the email you quoted and in the
> > Policy?
> 
> To my understand that wasn't answered.

I asked what exactly wasn't answered...

> Regarding the lintian tag am I assuming correct that Debian GNU/Linux does
> not care about a LICENSE file or LICENSES folder?

"Debian GNU/Linux" doesn't care if those files exist in the package.

> So there is no real problem to have a LICENSES folder?

Yes, there is no real problem to ship the licenses twice. It's just not
helpful.

> The "copyright" file will exist (downstream) no matter if there is a LICENSE
> file, a LICENSES folder or any of this.

Of course, that's what the Policy mandates.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: f2py problem with Multi-Python (and Ninja)

[Ole Streicher]

Hi Timo,

Timo Röhling  writes:
> * Ole Streicher  [2024-11-18 13:40]:
>>Build log is f.e.
>>https://salsa.debian.org/debian-astro-team/pybdsf/-/jobs/6612895
> The problem is most likely caused by "find_package(F2PY)", which does
> not take different Python versions into account [1].

This is indeed the case. But shouldn't that be adjusted for Debian (or
even upstream)? Setting f2py different from the Python minor version
seems a bug to me.

At the end, everybody tyrying to run a project that uses
"find_package(F2PY)" for a non-default Python version on Debian will
stumble upon it, which is a bit contrary to the idea of having CMake
figuring the required configuration.

Best

Ole

Re: Python 3.13 addition as a supported Python version started

[Thomas Goirand]

On 11/13/24 15:44, Stefano Rivera wrote:

Hi buhtz (2024.11.13_12:06:33_+)

This was discussed at the Python BoF at DebConf in ROK earlier this
year.


OK, nice to know that there was a discussion before. Did I missed the
announcement of the results of this discussion in this mailing list?


The BoF was mentioned on the list, but I think we forgot to feed the
conclusions back. Here is the recording:
https://debconf24.debconf.org/talks/31-python-bof/

Link to the notes at the bottom (etherpad).

Stefano


FYI, it's been at least 2 release that we discuss upgrading the Python 
interpreter version during the Debconf BoF before the freeze.


Over the years, we come to the conclusion that we have no choice but to 
upgrade and stay current. Delaying the Python interpreter upgrade would 
be a bad choice.


So next time, just expect that:
1/ We'll be discussing this at debconf
2/ Unless a very strong *new* reason pops in, we'll choose to upgrade to 
the latest interpreter version


Note that I used to be on the conservative side before, but Mathias and 
others managed to convince me I was wrong, and we should stay current 
ASAP, and as much as possible.


Cheers,

Thomas Goirand (zigo)

f2py problem with Multi-Python (and Ninja)

[Ole Streicher]

Hi,

I have a package (pybdsf) that currently fails to compile when both
Python 3.12 and 3.13 are installed (current situation). From the log:

8<-
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/pybdsf-1.11.1/.pybuild/cpython3_3.13  
8<-

which seems reasonable, and results in the Ninja command:

8<-
/usr/bin/cmake /build/pybdsf-1.11.1 -G Ninja --no-warn-unused-cli \
 
-DCMAKE_INSTALL_PREFIX:PATH=/build/pybdsf-1.11.1/_skbuild/linux-x86_64-3.13/cmake-install
 \
 -DPYTHON_VERSION_STRING:STRING=3.13.0 -DSKBUILD:INTERNAL=TRUE \
 
-DCMAKE_MODULE_PATH:PATH=/usr/lib/python3/dist-packages/skbuild/resources/cmake 
\
 -DPYTHON_EXECUTABLE:PATH=/usr/bin/python3.13 \
 -DPYTHON_INCLUDE_DIR:PATH=/usr/include/python3.13 \
 -DPYTHON_LIBRARY:PATH=/usr/lib/x86_64-linux-gnu/libpython3.13.so \
 -DPython_EXECUTABLE:PATH=/usr/bin/python3.13 \
 -DPython_ROOT_DIR:PATH=/usr -DPython_FIND_REGISTRY:STRING=NEVER \
 -DPython_INCLUDE_DIR:PATH=/usr/include/python3.13 \
 
-DPython_NumPy_INCLUDE_DIRS:PATH=/usr/lib/python3/dist-packages/numpy/core/include
 \
 -DPython3_EXECUTABLE:PATH=/usr/bin/python3.13 \
 -DPython3_ROOT_DIR:PATH=/usr -DPython3_FIND_REGISTRY:STRING=NEVER \
 -DPython3_INCLUDE_DIR:PATH=/usr/include/python3.13 \
 
-DPython3_NumPy_INCLUDE_DIRS:PATH=/usr/lib/python3/dist-packages/numpy/core/include
 \
 -DCMAKE_BUILD_TYPE:STRING=Release
8<-

which also looks reasonable. However, there is a module to be compiled
using f2py, which then fails, because it takes the default f2py instead
of the one that is specific for Python 3.13. This currently results in a
module compiled for Python 3.12, and so the build for 3.13 fails.

I am now unsure where the bug is:

* in Python's "build" module?
* in the "meson" Python module?
* in pybuild?
* numpy?
* upstream?
* Or must I set (or install) something to make it running?

Build log is f.e.
https://salsa.debian.org/debian-astro-team/pybdsf/-/jobs/6612895

Best regards

Ole