Re: Python 2 support for Bullseye

2020-10-16 Thread Moritz Muehlenhoff
On Fri, Oct 16, 2020 at 09:36:09PM +0300, Dmitry Shachnev wrote:
> Hi Moritz!
> 
> On Fri, Oct 16, 2020 at 08:04:56PM +0200, Moritz Mühlenhoff wrote:
> > There will be few core packages build-depending on Python 2 (for tests
> > or building) which won't be ready for Python 3 for Bullseye (Chromium,
> > qtwebkit and IIRC also Pypy), but those only need Python 2 (and a very
> > small set of support packages like setuptools/jinja) to build and
> > run their tests.
> 
> Small correction: s/qtwebkit/qtwebengine/.

Ack, that one, they keep changing names to often :-)

> There are also patches from the FreeBSD maintainer [2], but they are huge
> (2200 lines in total) and the author reports that they cause some JS errors,
> so I would better not apply them and wait for an official port.

Definitely.

> Qt WebEngine in Debian is not supported from security point of view anyway,
> so I think it should be fine to let it use Python 2 in Bullseye.

Yeah, given that it's only at build time for sources we control it's entirely
fine.

Cheers,
Moritz



Re: Python 2 support for Bullseye

2020-10-16 Thread Dmitry Shachnev
Hi Moritz!

On Fri, Oct 16, 2020 at 08:04:56PM +0200, Moritz Mühlenhoff wrote:
> There will be few core packages build-depending on Python 2 (for tests
> or building) which won't be ready for Python 3 for Bullseye (Chromium,
> qtwebkit and IIRC also Pypy), but those only need Python 2 (and a very
> small set of support packages like setuptools/jinja) to build and
> run their tests.

Small correction: s/qtwebkit/qtwebengine/.

QtWebEngine bundles Chromium whose upstream is actively working on
Python 3 port [1]. Most probably it won't be ready in time for Bullseye,
but for Bookworm it should be ready (or rather, Qt WebEngine 6 will
use Python 3, and we will remove Qt WebEngine 5).

There are also patches from the FreeBSD maintainer [2], but they are huge
(2200 lines in total) and the author reports that they cause some JS errors,
so I would better not apply them and wait for an official port.

Qt WebEngine in Debian is not supported from security point of view anyway,
so I think it should be fine to let it use Python 2 in Bullseye.

[1]: https://bugs.chromium.org/p/chromium/issues/detail?id=1112471
[2]: https://mail.kde.org/pipermail/distributions/2020-September/000860.html

--
Dmitry Shachnev


signature.asc
Description: PGP signature


Re: Python 2 support for Bullseye

2020-10-16 Thread Moritz Muehlenhoff
On Fri, Oct 16, 2020 at 08:21:09PM +0200, Matthias Klose wrote:
> > As such, I'd propose to include Python 2 (plus the small set of
> > support packages) in Bullseye
> 
> ok. I think you should explicitly name all these packages.

Yeah. I think the final list is still TBD (e.g. depends on whether Chromium
still gets a Py3 port in time for the freeze).

> > but exempt it from support (and then
> > remove it for good after the Bullseye release):
> 
> not ok. That would mean removing pypy3 from the archive as well. If you don't
> want to support Python2, then why do you care about it's removal for 
> bullseye+1?

Ok. I assumed the need for Py2 in pypy3 was a temporary thing? If it's needed
for longer (is there an estimate of sorts?), I'm also fine with keeping
it longer.

> > - Mark src:python (plus related support packages) as unsupported in
> >   debian-security-support and with a README.Debian in the source
> >   package (and given how prominent Python is, also in the release notes)
> 
> That should list the binary packages, there's no src:python package.

I acually meant src:python2.7, debian-security-support only operates
on source packages (and then flags all installed binary packages).

Cheers,
Moritz



Joining DPT

2020-10-16 Thread Birger Schacht

Hi DPT,

I would like to join the Debian Python Team. I maintain the errbot 
package, which is in my own namespace on salsa at the moment and which I 
would like to move to the DPT namespace. Errbot is a chatbot for 
multiple chat networks, written in Python.
In addition to that I started working as a Python Dev and there are some 
Python libraries that I would like to package for Debian, to make my 
life easier.


My Salsa login is 'birger'.

I have read the DPT-Policy on [0] and I accept it.
(I will have to change the branch layout of the errbot repo to adhere to 
the DPT-Policy, but there is a new release waiting to be packaged, so I 
can do that when preparing the next upload.)


cheers,
Birger

[0] 
https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst


OpenPGP_0xCB06EA7B78DBE151.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature


Re: Python 2 support for Bullseye

2020-10-16 Thread Matthias Klose
On 10/16/20 8:04 PM, Moritz Mühlenhoff wrote:
> There will be few core packages build-depending on Python 2 (for tests
> or building) which won't be ready for Python 3 for Bullseye (Chromium,
> qtwebkit and IIRC also Pypy), but those only need Python 2 (and a very
> small set of support packages like setuptools/jinja) to build and
> run their tests.
> 
> Apart from those there's only a handful of packages still in testing
> which have a run time dependency on Python 2 packages (and most are
> actively being worked on (e.g. Xen)).
> 
> All packages (and their test suites) shipped in Debian are trusted
> anyway (and consequently don't need any kind of updates during the
> bullseye cycle), so a lack of updates/upstream EOL doesn't matter.
> 
> As such, I'd propose to include Python 2 (plus the small set of
> support packages) in Bullseye

ok. I think you should explicitly name all these packages.

> but exempt it from support (and then
> remove it for good after the Bullseye release):

not ok. That would mean removing pypy3 from the archive as well.  If you don't
want to support Python2, then why do you care about it's removal for bullseye+1?

> - Mark src:python (plus related support packages) as unsupported in
>   debian-security-support and with a README.Debian in the source
>   package (and given how prominent Python is, also in the release notes)

That should list the binary packages, there's no src:python package.

> - Bump the severity of the few remaining packages in testing to RC
>   state (and force them out testing if auto removals were blocked
>   for some reason)

See above, I think it's unfriendly to push out pypy3.

Matthias



Python 2 support for Bullseye

2020-10-16 Thread Moritz Mühlenhoff
There will be few core packages build-depending on Python 2 (for tests
or building) which won't be ready for Python 3 for Bullseye (Chromium,
qtwebkit and IIRC also Pypy), but those only need Python 2 (and a very
small set of support packages like setuptools/jinja) to build and
run their tests.

Apart from those there's only a handful of packages still in testing
which have a run time dependency on Python 2 packages (and most are
actively being worked on (e.g. Xen)).

All packages (and their test suites) shipped in Debian are trusted
anyway (and consequently don't need any kind of updates during the
bullseye cycle), so a lack of updates/upstream EOL doesn't matter.

As such, I'd propose to include Python 2 (plus the small set of
support packages) in Bullseye but exempt it from support (and then
remove it for good after the Bullseye release):
- Mark src:python (plus related support packages) as unsupported in
  debian-security-support and with a README.Debian in the source
  package (and given how prominent Python is, also in the release notes)
- Bump the severity of the few remaining packages in testing to RC
  state (and force them out testing if auto removals were blocked
  for some reason)

Thoughts?

Cheers,
Moritz



Transfer cherrytree from DPT to Debian group

2020-10-16 Thread Andrius Merkys
Hello,

Recently cherrytree [1] has been rewritten from Python to C++, thus it
no longer belongs in DPT. Could someone with adequate permissions
transfer it from DPT to generic Debian group on salsa.d.o?
Alternatively, one could grant me permission to manage cherrytree so as
I could transfer it myself.

[1] https://salsa.debian.org/python-team/packages/cherrytree

Thanks,
Andrius



Re: Bug#972213: boost1.71: Please indicate some way which python versions you support

2020-10-16 Thread Alastair McKinstry



On 16/10/2020 09:19, Drew Parsons wrote:

On 2020-10-16 14:43, Giovanni Mascellani wrote:

Hi,

Il 16/10/20 02:53, Drew Parsons ha scritto:


Would it make sense to use the Built-Using [1] header?

...

[1]
https://www.debian.org/doc/debian-policy/ch-relationships.html#additional-source-packages-used-to-build-the-binary-built-using 



The precise web page you are linking hints that this use of Built-Using
would be improper:

"This field should be used only when there are license or DFSG
requirements to retain the referenced source packages. It should not be
added solely as a way to locate packages that need to be rebuilt against
newer versions of their build dependencies".


Ah yes, I had a feeling there were more reasons to not prefer this 
method!




That said, I forgot to mention that the Python versions Boost is
compiled against is also tracked in the package names provided by
libboost-python1.71.0, which are currently libboost-python1.71.0-py38
and libboost-python1.71-py39.

Is this better? More in general, there can be dozens of ways to
advertise which Python versions are used to build Boost.Python, but it
is not clear to me how this information should be consumed.



That sounds like a useful approach.

The ecflow build could access the provided versions via
  dpkg -s libboost-python${BOOST_VERSION} | grep Provides


That works.

Code can be added that the package fails to rebuild if it can't get the 
necessary provides.


Thanks

Alastair

--
Alastair McKinstry, , , 
https://diaspora.sceal.ie/u/amckinstry
Misentropy: doubting that the Universe is becoming more disordered.



Re: Bug#972213: boost1.71: Please indicate some way which python versions you support

2020-10-16 Thread Matthias Klose
On 10/15/20 10:03 PM, Alastair McKinstry wrote:
> On 15/10/2020 08:13, Giovanni Mascellani wrote:
> 
>> Hi,
>>
>> Il 14/10/20 15:52, Alastair McKinstry ha scritto:
>>> I maintain the package "ecflow" which uses libboost-python-dev. Now
>>> with the transition to python3.9, ecflow will support (where
>>> possible) multiple python versions. Currently it supports python3.8
>>> but not python3.9 ; this may be fixed in a binNMU or next version,
>>> but I cannot tell whether my failure to build python3.9 support for
>>> ecflow is due to missing py3.9 support in boost, or a bug in my
>>> packaging.
>> BTW, a binNMU was just requested to add Python 3.9 support.
>>
>>> Can some mechanism be added to enable tracability ?
>> In general, Boost supports all the Python versions currently supported
>> by the Python team, except that someone has to file a binNMU for them to
>> appear once a new Python version is packaged. To check which Python
>> versions are supported by a specific package version, it is enough to
>> check the content of the libboost-python1.71.0 package (replace 1.71.0
>> with future versions where applicable):
>>
>> $ dpkg -L libboost-python1.71.0 | grep libboost_python
>> /usr/lib/x86_64-linux-gnu/libboost_python38.so.1.71.0
>> /usr/lib/x86_64-linux-gnu/libboost_python39.so.1.71.0
>>
>> (until yesterday you did not have the python39 variant)
>>
>> Does this answer your question?
>>
>> Giovanni.
> 
> Not really. This is probably better discussed on debian-python.
> 
> The point was that there is a lack of a good mechanism to see which packages
> provide py39 support, etc.
> 
> In principle my package ecflow just needs a rebuild after the boost is 
> rebuilt,
> but tracking if this actually works, or add a particular dependency to enable
> automatic rebuild/tracking.

I don't think that packages should care about that at all.  It usually is only
an issue when adding a new python version, and this happens once in a year.  The
transition tracker [1] provides a guidance how to build stuff in which order,
based on dependencies, but doesn't take care about build-dependencies,
autopkgtest dependencies, and dependency cycles.  And binNMUing 600 packages
takes time ...

Matthias

[1] https://release.debian.org/transitions/html/python3.9.html



Re: Bug#972213: boost1.71: Please indicate some way which python versions you support

2020-10-16 Thread Drew Parsons

On 2020-10-16 14:43, Giovanni Mascellani wrote:

Hi,

Il 16/10/20 02:53, Drew Parsons ha scritto:


Would it make sense to use the Built-Using [1] header?

...

[1]
https://www.debian.org/doc/debian-policy/ch-relationships.html#additional-source-packages-used-to-build-the-binary-built-using


The precise web page you are linking hints that this use of Built-Using
would be improper:

"This field should be used only when there are license or DFSG
requirements to retain the referenced source packages. It should not be
added solely as a way to locate packages that need to be rebuilt 
against

newer versions of their build dependencies".


Ah yes, I had a feeling there were more reasons to not prefer this 
method!




That said, I forgot to mention that the Python versions Boost is
compiled against is also tracked in the package names provided by
libboost-python1.71.0, which are currently libboost-python1.71.0-py38
and libboost-python1.71-py39.

Is this better? More in general, there can be dozens of ways to
advertise which Python versions are used to build Boost.Python, but it
is not clear to me how this information should be consumed.



That sounds like a useful approach.

The ecflow build could access the provided versions via
  dpkg -s libboost-python${BOOST_VERSION} | grep Provides



Re: Bug#972213: boost1.71: Please indicate some way which python versions you support

2020-10-16 Thread Giovanni Mascellani
Hi,

Il 16/10/20 02:53, Drew Parsons ha scritto:
> Source: boost1.71
> Followup-For: Bug #972213
> X-Debbugs-Cc: debian-python@lists.debian.org
> 
> Would it make sense to use the Built-Using [1] header?
> e.g.
>   Built-Using: python3.8 python3.9
> 
> dh_python3 knows if the module includes extensions
> (*_python*.so.) and could inject the pythons into Built-Using.
>
> [...]
> 
> [1]
> https://www.debian.org/doc/debian-policy/ch-relationships.html#additional-source-packages-used-to-build-the-binary-built-using

The precise web page you are linking hints that this use of Built-Using
would be improper:

"This field should be used only when there are license or DFSG
requirements to retain the referenced source packages. It should not be
added solely as a way to locate packages that need to be rebuilt against
newer versions of their build dependencies".

That said, I forgot to mention that the Python versions Boost is
compiled against is also tracked in the package names provided by
libboost-python1.71.0, which are currently libboost-python1.71.0-py38
and libboost-python1.71-py39.

Is this better? More in general, there can be dozens of ways to
advertise which Python versions are used to build Boost.Python, but it
is not clear to me how this information should be consumed.

Giovanni.
-- 
Giovanni Mascellani