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
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
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,
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 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
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
> 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
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.
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
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
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
11 matches
Mail list logo
