The removal of packages still depending on Python2 looks good [1], however we
have a bunch of packages that still require Python2, and where maintainers
explicitly asked to keep those in the distro [2]. Among those are pypy and
pypy3 which need Python2 for bootstrapping. I'm going to keep the Pyt
On Thursday, July 9, 2020 7:21:45 AM EDT Matthias Klose wrote:
> The removal of packages still depending on Python2 looks good [1], however
> we have a bunch of packages that still require Python2, and where
> maintainers explicitly asked to keep those in the distro [2]. Among those
> are pypy and
On 7/9/20 1:45 PM, Scott Kitterman wrote:
> On Thursday, July 9, 2020 7:21:45 AM EDT Matthias Klose wrote:
>> The removal of packages still depending on Python2 looks good [1], however
>> we have a bunch of packages that still require Python2, and where
>> maintainers explicitly asked to keep those
As written in [1], bullseye will not see unversioned python packages and the
unversioned python command being built from the python-defaults package.
It seems to be a little bit more controversial what should happen to the python
command in the long term. Some people argue that python should neve
On 2020-07-09 15:26:47 +0200 (+0200), Matthias Klose wrote:
> As written in [1], bullseye will not see unversioned python
> packages and the unversioned python command being built from the
> python-defaults package.
>
> It seems to be a little bit more controversial what should happen
> to the pyt
On Thu, Jul 09, 2020 at 04:55:33PM +, Jeremy Stanley wrote:
> I don't follow your logic there. Why is it hard to explain? Python
> was a programming language, and its last interpreter (2.7) is no
> longer developed or supported. Python3 (formerly Python3000) is also
> a programming language, si
python-numpy* is no longer buildable in testing due to the removal of the
"cython" binary package.
The maintainer has requested removal of python-numpy from unstable but the
ftpmasters have not yet
actioned it, presumably because there are still reverse-dependencies in
unstable. A rc bug is
pre
Hi,
čt 9. 7. 2020 v 15:27 odesílatel Matthias Klose napsal:
> Describing here a solution which is implemented for Ubuntu focal (20.04
> LTS). A
> new source package what-is-python (-perl-dont-hurt-me) ships binary
> packages
> python-is-python2, python-dev-is-python2, python-is-python3 and
> py
Hi,
čt 9. 7. 2020 v 21:25 odesílatel peter green napsal:
> python-numpy* is no longer buildable in testing due to the removal of the
> "cython" binary package.
> The maintainer has requested removal of python-numpy from unstable but the
> ftpmasters have not yet
> actioned it, presumably because
Hi
On 09-07-2020 21:16, peter green wrote:
> All of the reverse dependencies of python-numpy have already been
> removed from testing. So IMO
> it makes sense to remove python-numpy from testing at this point, do
> other people agree?
I think it makes sense, so I added a removal hint.
Paul
si
Hello,
I was in the DPMT back when it was on Alioth and I would like to join
it again to backport python-flasgger and help with other packages as
the need arises.
My Salsa login is "federico".
I have read the policy and I accept it:
https://salsa.debian.org/python-team/tools/python-modules/blob/m
Hi Scott, devel, and Python team,
Nicholas D Steeves writes:
> Control: block -1 by 962574
>
> Tomlkit seems to be required for self-tests.
>
Thank you for taking care of tomlkit so quickly! I wish I had more time
and energy to make faster progress with DepHell. Today I discovered it
appears
Hello,
this email is to inform the maintainers of the reverse dependencies of
mercurial of the plan to upload to unstable the python3 version next
Thursday. We want to be extra-safe with the switch, hence this email.
In To: to this email the maintainers mailing list + key other MLs and
addresses,
Hello,
i would like to propose a project to make sure our teams (DPMT/PAPT)
repos are using pristine-tar properly.
The checks i have in mind for now, are:
* pristine-tar branch must exist, if not -> it's a bug
* pristine-tar + upstream branch must produce the same tarball as
downloaded from the a
Hello,
i would like to propose a project to make sure our teams (DPMT/PAPT)
repos are being used correctly; it has a broader set of requirements
than the pristine-tar one (and so it's more complex), thus a separate
message.
The checks i have in mind for now, are:
* packages in DPMT/PAPT need to h
15 matches
Mail list logo