re: samba: FTBFS glibc/stropts/python issue.

2020-03-30 Thread peter green
The samba FTBFS is blocking the python 3.8 transition in raspbian bullseye, so I decided to take a look. error: Unable to determine origin of type `struct cli_credentials' I don't think this is the error that is causing the build failure. The same error can be seen in succesful build logs.

py2removal: proposal to increase apps popcon limit

2020-03-30 Thread Sandro Tosi
Hello, as part of the py2removal process, we're not raising the bug priority to serious if it's associated with an application and popcon is bigger than 300 There are currently: * 38 apps that are leaf packages and popcon > 300; ** 13 out of 38 have popcon < 600 ** 20 out of 38 have popcon <

Re: Bug#954582: samba: FTBFS glibc/stropts/python issue.

2020-03-30 Thread Andrew Bartlett
On Tue, 2020-03-31 at 02:09 +0100, peter green wrote: > The samba FTBFS is blocking the python 3.8 transition in raspbian > bullseye, so I decided to take a look. Thanks for digging into this. I've updated the Samba bug below, and I think this is a Python bug and needs to be fixed in Python.

Re: samba: FTBFS glibc/stropts/python issue.

2020-03-30 Thread peter green
If my understanding is correct I see two possible ways forward. 1. Rebuild python3.8 against the new glibc. 2. Remove the stropts include from samba, it doesn't seem to actually be used for anything (at least I can't find any other references to HAVE_STROPTS_H in the code). I am currently

Taking over DPMT (Was: python-boto: autopkgtest failure with Python 3.8 as default)

2020-03-30 Thread Andreas Tille
Hi Emmanuel, thanks a lot for your patch. Please note that you crafted it against GIt which is lagging behind the latest NMU. I intended to apply it anyway - but it does not solve == ERROR: test_constructor

Re: Python3 modules not built for all supported Python versions

2020-03-30 Thread Simon McVittie
On Mon, 30 Mar 2020 at 15:30:01 +0200, Johannes Schauer wrote: > does this mean that build-depending on python3-dev is wrong in general and > should instead be replaced by build-depending on python3-all-dev? It is only wrong for packages that build Python 3 extensions (binary modules) that are

Re: Python3 modules not built for all supported Python versions

2020-03-30 Thread Emilio Pozuelo Monfort
On 30/03/2020 16:08, Simon McVittie wrote: > On Mon, 30 Mar 2020 at 15:30:01 +0200, Johannes Schauer wrote: >> does this mean that build-depending on python3-dev is wrong in general and >> should instead be replaced by build-depending on python3-all-dev? > > It is only wrong for packages that

Re: Python3 modules not built for all supported Python versions

2020-03-30 Thread Piotr O┼╝arowski
> I don't know if I'm missing an argument to dh_python3 so that it knows the > python version, or even if there's a better workaround. But perhaps pybuild better workaround is to force cmake to install into versioned dist-packages (that's what I do in distutils) as I didn't find a reliable way to

Python3 modules not built for all supported Python versions

2020-03-30 Thread Emilio Pozuelo Monfort
Hi, We've just finished the transition to python3.8 as the default python3 interpreter, which was a bit difficult due to some autopkgtest regressions in a few rdeps, and to the fact that many modules only build their extensions for the default python version, which means they have a strict

Re: Python3 modules not built for all supported Python versions

2020-03-30 Thread Matthias Klose
On 3/30/20 1:24 PM, Emilio Pozuelo Monfort wrote: > Hi, > > We've just finished the transition to python3.8 as the default python3 > interpreter, which was a bit difficult due to some autopkgtest regressions in > a > few rdeps, and to the fact that many modules only build their extensions for >

Re: Python3 modules not built for all supported Python versions

2020-03-30 Thread Johannes Schauer
Hi, Quoting Emilio Pozuelo Monfort (2020-03-30 13:24:01) > We've just finished the transition to python3.8 as the default python3 > interpreter, which was a bit difficult due to some autopkgtest regressions in > a few rdeps, and to the fact that many modules only build their extensions > for the