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.
The
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 t
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 < 1000
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. e.
> 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
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 buil
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 int
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 d
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
>
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 depende
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 (tests.unit.utils.te
11 matches
Mail list logo
