On 18.02.25 19:41, M. Zhou wrote:
On Tue, 2025-02-18 at 09:50 -0800, Diane Trout wrote:
Do you have any ideas of what could be done to help get a version of
llvmlite that works with numba into Debian?
No idea. I'm keeping an eye on upstream release but the only option
I can see to make it wor
On 09.01.25 10:34, James Allwright wrote:
Hi package maintainers,
I have noticed that pkg-config in not returning the library I need to
link to for python.
pkg-config --libs python3
is returning nothing, when I expect
-lpython3
I think the problem is in file
/usr/lib/x86_64-linux-gnu/pkgconf
On 08.01.25 21:36, Scott Talbert wrote:
On Wed, 8 Jan 2025, Soren Stoutner wrote:
Python3-hid was marked `Multi-Arch: same` by a previous maintainer.
Recently,
tracker.debian.org warned that there is an issue because the WHEEL
file is
different in each package.
https://tracker.debian.org/pk
python3-defaults in unstable now adds Python 3.13 as a supported Python
3.13 version. You might see some additional build failures, until the
binNMUs for this addition are done [1]. This might take some days for
some architectures. We will most likely also see some more issues once
the lower
On 13.11.24 11:04, PICCA Frederic-Emmanuel wrote:
do we know how long we will have to fix all the FTBFS and autopkgtest before
the freeze ?
no. the freeze date is not yet announced.
I am a bit worrying for the scientific stack , will we have enough time to work
with our upstream in order to
On 02.11.24 18:35, Sebastian Ramacher wrote:
Dear toolchain, debian-installer, and image maintainers,
We, as the release team, are aware that we are late with the
announcement of the freeze timeline for trixie. After some internal
discussions on how we want to handle the freeze for trixie based
On 31.10.24 21:53, Julian Gilbey wrote:
Hi Adrian,
On Thu, Oct 31, 2024 at 07:08:20PM +0100, John Paul Adrian Glaubitz wrote:
Hi Julian,
[...]
Thanks a lot. I would have never guessed that.
Meanwhile, I found the following alternative approach in the README.rst [1]:
dh_auto_test -- -
On 18.10.24 18:48, Scott Kitterman wrote:
On October 18, 2024 2:07:35 PM UTC, Simon McVittie wrote:
On Fri, 18 Oct 2024 at 15:31:26 +0200, Guillem Jover wrote:
I guess whether "upstream name or python-$modulename" would seem fine,
depends on what "upstream name" is. I guess if the latter is
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-CC: debian-python@lists.debian.org
Please setup a tracker to add python3.13 as a supported python3 version.
This is non-blocking, as packages can migrate on their own once bui
On 07.10.24 19:28, 陈 晟祺 wrote:
Hi,
Python 3.13 is released with experimental free-threaded (or no-gil) mode [1].
Upstream calls it python3.13t. I wonder whether Debian plans to package it?
I have searched though d-python lists & some BTS bugs but got no similar
question. Please point out if I a
On 06.10.24 21:12, Stefano Rivera wrote:
Hi Carsten (2024.10.06_19:09:26_+)
is there a repo existing where a current WIP of the Python 3.13 is built as
.deb packages?
Or could this be prepared?
Debian unstable.
But nothing is built against it, yet. That will happen when the release
team i
On 06.10.24 17:51, Louis-Philippe Véronneau wrote:
Hello,
The `uses-deprecated-python-stdlib` lintian tag finally seems to be
ready. \0/
I'm hereby proposing to do a mass bug filing for all the packages that
are currently using libraries that will be deprecated in Python 3.13. As
of now, 20
On 04.09.24 17:25, Stefano Rivera wrote:
In October last year, we added python3-setuptools as a dependency of dh-python,
to ease the transition from distutils.
I think it's time to unwind this.
I did a test-rebuild of everything that depends on dh-python without depending
on setuptools:
cat de
On 22.08.24 21:37, Alexandre Detiste wrote:
Hi,
Would it be possible to remove 2to3 from Python3.12 without waiting for 3.13 ?
I see in the meantime a new usage was brought back.
I'll check if this "slimit" package can be easily switched to python3-fissix;
which is a 2to3 fork that is already
On 03.08.24 07:25, Louis-Philippe Véronneau wrote:
On 2024-08-02 20:40, Blair Noctis wrote:
to scale it out in an external source package
which is effectively going against Python upstream, allowing the thing
to live
on, and people to say "it's still alive in Debian!"
Also, even python3.11 is
On 29.06.24 20:29, Scott Kitterman wrote:
On Saturday, June 29, 2024 1:36:41 PM EDT Soren Stoutner wrote:
Scott,
On Saturday, June 29, 2024 8:58:09 AM MST Scott Kitterman wrote:
I would say no. Distutils is going to be with us for quite some time,
even
though it's no longer part of the standa
On 24.06.24 10:42, Matthias Klose wrote:
On 22.06.24 00:06, Emmanuel Arias wrote:
Hi team,
As the Louis-Philippe and Andreas response to my last mail [0]
I would like to propose a (regular?) IRC meeting to try to organize
the work inside the team. I would like to propose an IRC meeting
on 5
On 22.06.24 00:06, Emmanuel Arias wrote:
Hi team,
As the Louis-Philippe and Andreas response to my last mail [0]
I would like to propose a (regular?) IRC meeting to try to organize
the work inside the team. I would like to propose an IRC meeting
on 5 July, perhaps a good time could be around 12P
On 11.12.23 19:55, Julian Gilbey wrote:
On Mon, Dec 11, 2023 at 04:34:17PM +0100, Matthias Klose wrote:
On 11.12.23 16:19, Julian Gilbey wrote:
On Mon, Dec 11, 2023 at 08:09:31AM +0100, Matthias Klose wrote:
[...]
You could package a non-conflicting cython-legacy, however that would
require
On 11.12.23 08:12, Matthias Klose wrote:
On 10.12.23 14:06, Rebecca N. Palmer wrote:
Is this an acceptable amount of breakage or should we continue to
wait? Bear in mind that if we wait too long, we may be forced into it
by some transition further up the stack (e.g. a future Python or
numpy
On 11.12.23 16:19, Julian Gilbey wrote:
On Mon, Dec 11, 2023 at 08:09:31AM +0100, Matthias Klose wrote:
[...]
You could package a non-conflicting cython-legacy, however that would
require more changes, also how to build it.
Hi Matthias,
Unfortunately, at least some of cython3-legacy doesn&#
On 11.12.23 08:09, Matthias Klose wrote:
On 10.12.23 21:32, Andrey Rakhmatullin wrote:
On Sun, Dec 10, 2023 at 09:30:03PM +0100, Andrey Rakhmatullin wrote:
I find that there's also a significant issue with relying on
cython3-legacy: it conflicts with cython3, meaning that it will be
impos
On 10.12.23 14:06, Rebecca N. Palmer wrote:
I'd like to move forward with the pandas 1.5 -> 2.1 transition
reasonably soon.
Given that pandas 2.x is *not* required for Python 3.12 (but is required
for Cython 3.0), should we wait for the Python 3.12 transition to be
done first?
These are bro
On 10.12.23 21:32, Andrey Rakhmatullin wrote:
On Sun, Dec 10, 2023 at 09:30:03PM +0100, Andrey Rakhmatullin wrote:
I find that there's also a significant issue with relying on
cython3-legacy: it conflicts with cython3, meaning that it will be
impossible to simultaneously install packages dependi
as a supported version. If you see
builds failing because of a missing 3.12 extension, please just wait a
few days until all the binNMUs are done.
For the progress, see (ignoring the 'unknown' status)
https://release.debian.org/transitions/html/python3.12-add.html
Matthias
On 07.11.23
On 07.11.23 14:06, Thomas Goirand wrote:
When 3.12 because an available version, it would help a lot to have
someone like Lucas Nusbaumm to rebuild all reverse dependencies of
Python. Is that something planned?
No. A test rebuild with a stack of 12 dependency levels doesn't make
much sense.
Python 3.12 was released a month ago, and it's time to prepare for the
update in unstable, first adding 3.12 as a supported version.
There s a tracker for adding 3.12 as a supported version [1], also there
are the first bug reports filed for issues related to 3.12 [2].
As usual, it's diffic
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-CC: debian-python@lists.debian.org
Please setup a tracker to add python3.12 as a supported python3 version. This is
non-blocking, as packages can migrate on their own once buil
while we have not an 100% agreement to go ahead, I think we should aim for 3.11.
The following steps would be:
- accept the current python3-defaults into
testing (adding 3.11 as supported)
- ask for a transition slot to upload (see #1026825)
python3-defaults with 3.11 as the default
- s
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-CC: debian-python@lists.debian.org
Please setup a transition window for python 3.11 as the default python3 version.
A tracker is setup at
https://release.debian.org/transitio
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-CC: debian-python@lists.debian.org
Please setup a transition window for python 3.10 as the default python3 version.
A tracker is setup at
https://release.debian.org/transit
On 9/14/21 8:36 AM, Matthias Klose wrote:
> On 9/13/21 4:02 PM, Scott Talbert wrote:
>> On Fri, 3 Sep 2021, Matthias Klose wrote:
>>
>>>> Python 3.8 upstream now has a common ABI for normal and debug extension
>>>> builds,
>>>> so it is technical
On 9/13/21 4:02 PM, Scott Talbert wrote:
> On Fri, 3 Sep 2021, Matthias Klose wrote:
>
>>> Python 3.8 upstream now has a common ABI for normal and debug extension
>>> builds,
>>> so it is technically possible to load a debug extension in the normal
>>>
On 7/6/20 8:33 PM, Matthias Klose wrote:
> Python 3.8 upstream now has a common ABI for normal and debug extension
> builds,
> so it is technically possible to load a debug extension in the normal
> interpreter, or to load a normal extension in the debug interpreter. In
>
As Stefano wrote, we had some discussion around Python packaging in Linux
distros. While the linux-sig is/was very dormant the last years, we'd like to
coordinate on this list, so if you're interested in cross distro issues, please
subscribe to
https://mail.python.org/mailman3/lists/linux-sig.pyt
On 5/16/21 1:52 PM, Luke Kenneth Casson Leighton wrote:
>> * One 3.x version at a time. Doesn't line up with cpython's support terms.
> numpy and sci-py, the two "best known" debian python software
> packages, have known about this for a long, long, time. they
> quietly solved it by adding explic
On 3/3/21 6:56 PM, Andrey Rahmatullin wrote:
> On Wed, Mar 03, 2021 at 05:39:04PM +, Stefano Rivera wrote:
>> You need python3.8-venv.
> Which doesn't exist, at least in the current repos.
you rebuild it from python3-stdlib-extensions. but yes, the binaries don't exist
in the archive.
I am appending the following two sections to the python policy chapter 2,
documenting what currently is in testing. There are different opinions, no
perfect solutions, and if we disagree, we should delegate the final decision
whether to include or to not include the binary packages
python{,-dev}-i
On 2/12/21 2:08 PM, Julien Palard wrote:
> Hi,
>
> As far as I understand, the divergence between "Python upstream" and
> Debian is:
>
> - It looks like Debian target users consuming software, users just
> install a package and it works, no venv needed obviously, it always just
> work, it's fa
On 1/20/21 8:39 PM, Stephen Kitt wrote:
> Hi,
>
> I’ve come across a situation which doesn’t seem to be addressed by existing
> policies: the python-ptrace source package only ships
> architecture-independent content, but it works on a small number of
> architectures (currently, 32/64-bit x86, 32-
On 11/9/20 10:19 AM, Matthias Klose wrote:
> On 10/23/20 1:07 PM, Matthias Klose wrote:
>> On 10/18/20 12:13 PM, Matthias Klose wrote:
>>> Python 3.9 as a supported Python3 version is now in unstable, and all
>>> binNMUs
>>> are done (thanks to Graham for th
On 11/11/20 3:27 AM, Michael Hudson-Doyle wrote:
> On Mon, 9 Nov 2020 at 22:20, Matthias Klose wrote:
>
>> On 10/23/20 1:07 PM, Matthias Klose wrote:
>>> On 10/18/20 12:13 PM, Matthias Klose wrote:
>>>> Python 3.9 as a supported Python3 version is now in unst
On 10/23/20 1:07 PM, Matthias Klose wrote:
> On 10/18/20 12:13 PM, Matthias Klose wrote:
>> Python 3.9 as a supported Python3 version is now in unstable, and all binNMUs
>> are done (thanks to Graham for the work). Bug reports should be all filed
>> for
>> all
On 11/5/20 1:03 PM, terce...@debian.org wrote:
> On Thu, Nov 05, 2020 at 09:28:56AM +0100, Thomas Goirand wrote:
>> On 11/4/20 9:27 PM, Novy, Ondrej wrote:
>>> Hi,
>>>
>>> Antonio Terceiro píše v St 04. 11. 2020 v 14:01 -0300:
Could you ellaborate? Maybe we should have a discussion in the Pyth
On 10/23/20 1:07 PM, Matthias Klose wrote:
> On 10/18/20 12:13 PM, Matthias Klose wrote:
>> Python 3.9 as a supported Python3 version is now in unstable, and all binNMUs
>> are done (thanks to Graham for the work). Bug reports should be all filed
>> for
>> all
On 10/18/20 12:13 PM, Matthias Klose wrote:
> Python 3.9 as a supported Python3 version is now in unstable, and all binNMUs
> are done (thanks to Graham for the work). Bug reports should be all filed
> for
> all known problems [1], and the current state of the 3.9 addition can b
Python 3.9 as a supported Python3 version is now in unstable, and all binNMUs
are done (thanks to Graham for the work). Bug reports should be all filed for
all known problems [1], and the current state of the 3.9 addition can be seen at
[2] (a few of the "bad" are false packages with b-d n python
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 li
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 (wher
On 7/6/20 9:04 PM, Matthias Klose wrote:
> Starting with Python 3.8, Python upstream changed to a time based yearly
> release
> schedule, targeting the first release of a major Python version (3.x) for
> October of each year. For the transition to 3.8:
>
> - we add 3.8 as sup
On 9/17/20 3:04 PM, Nicolas Dandrimont wrote:
> Hi Matthias, others,
>
> On Thu, Jul 9, 2020, at 15:26, 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 pa
block 967209 by 967157
thanks
sorry, that's due to uninstallability of libglade2-dev.
On 8/4/20 2:49 PM, Dirk Eddelbuettel wrote:
>
> Hi doko and Python folks,
>
> On 4 August 2020 at 09:29, Matthias Klose wrote:
> | Package: src:rgtk2
> | Version: 2.20.36-2
> | Sever
On 7/13/20 6:23 PM, Fabrice BAUZAC-STEHLY wrote:
> Hi,
>
> Another solution would be to simply use the update-alternatives system
> to manage /usr/bin/python. python3 would have a higher priority than
> python2. Users would still have the possibility to switch
> /usr/bin/python to python2 explic
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 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 exp
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
Starting with Python 3.8, Python upstream changed to a time based yearly release
schedule, targeting the first release of a major Python version (3.x) for
October of each year. For the transition to 3.8:
- we add 3.8 as supported in November
- made 3.8 the default in March
- dropped 3.7 in Apr
Python 3.8 upstream now has a common ABI for normal and debug extension builds,
so it is technically possible to load a debug extension in the normal
interpreter, or to load a normal extension in the debug interpreter. In Debian,
debug extensions are shipped with a different name, and only loaded
On 4/30/20 5:28 AM, Scott Kitterman wrote:
> I think Python policy changes should be discussed. I accidentally committed
> a
> change to git [1] (I didn't realize I still had access, I thought it would be
> a merge request) to allow Python 3 only wheels for packages that require
> wheels, but
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
>
On 2/3/20 8:22 PM, Simon McVittie wrote:
> On Sun, 02 Feb 2020 at 09:35:04 +0100, Matthias Klose wrote:
>> I think this is now in shape to be started.
>
> Please can this wait until the remaining bits of the libffi7 transition
> and the restructuring of the libgcc_s packaging
On 2/2/20 5:53 PM, Rene Engelhard wrote:
> On Sun, Feb 02, 2020 at 09:35:04AM +0100, Matthias Klose wrote:
>>> On 17-01-2020 23:28, Matthias Klose wrote:
>>>> Please add a transition tracker to switch the python3 default to 3.8.
>>>> It's not
>&g
Control: tags -1 - moreinfo
On 1/18/20 9:30 PM, Paul Gevers wrote:
> Control: tags -1 moreinfo
>
> Hi Matthias,
>
> On 17-01-2020 23:28, Matthias Klose wrote:
>> Please add a transition tracker to switch the python3 default to 3.8. It's
>> not
>> yet
On 24.01.20 20:00, Scott Kitterman wrote:
> I started looking into updating pip to the current release
thanks for doing that.
> packaging
the recent version is in the archive but ftbfs. it's a dh-python issue.
Matthias
On 22.01.20 02:18, Nicholas D Steeves wrote:
> I don't think this is an assumption. Debian adheres to PEP 394, which
> until recently said that /usr/bin/python is supposed to be Python 2, for
> backwards compatibility. When I discovered this I felt increased trust
> in Debian and its developers f
On 09.12.19 11:46, Andreas Tille wrote:
> Hi,
>
> I have upgraded python-datrie in Git[1] to latest upstream version
> (0.8). It shows the same issue - so I admit I have no better clue than
> reporting the issue upstream which I'd rather leave to the official
> Uploader of the package.
>
> BTW,
On 02.12.19 20:28, Paul Gevers wrote:
> Hi all,
>
> On 01-12-2019 22:45, Sandro Tosi wrote:
>> Paul, this is the thread i was talking about.
>>
>> you were copied in the original email:
>> https://lists.debian.org/debian-python/2019/10/msg00098.html
>>
>> if there is something the RT wants to disc
On 26.11.19 11:02, Ole Streicher wrote:
> Hi,
>
> I am currently updating the "casacore" package to the latest upstream
> version. Doing this, I discovered that it is not marked as part of the
> Python 3.8 transition, and was also not binNMUed for this, although it
> has the package libcasa-python
On 12.11.19 23:39, Matthias Klose wrote:
> On 07.11.19 15:08, Matthias Klose wrote:
>> This weekend, I am planning to upload python3-defaults, adding python3.8 as a
>> supported Python3 version. This may introduce some churn in unstable until
>> the
>> basic bi
On 07.11.19 15:08, Matthias Klose wrote:
> This weekend, I am planning to upload python3-defaults, adding python3.8 as a
> supported Python3 version. This may introduce some churn in unstable until
> the
> basic binNMUs are available as well.
>
> Details for the addition
On 11.11.19 11:43, Yves-Alexis Perez wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Mon, 2019-11-11 at 10:33 +0100, Ondřej Nový wrote:
We are going to raise the severity of the py2removal bugs to "serious"
in several steps. In the
first phase we are going to raise severity of the py
This weekend, I am planning to upload python3-defaults, adding python3.8 as a
supported Python3 version. This may introduce some churn in unstable until the
basic binNMUs are available as well.
Details for the addition can be found at [1], known issues and patches are filed
[2]. There was no
On 06.11.19 22:04, Nicholas D Steeves wrote:
Brian May writes:
Stéphane Blondon writes:
Perhaps there is a doubt how to read it?
- do not (remove python-foo-doc or rename it to python3-foo-doc)
- (do not remove python-foo-doc) or (rename it to python3-foo-doc)
Would it be better if we remo
On 03.11.19 15:09, Neil Williams wrote:
On Sun, 3 Nov 2019 15:00:17 +0100
Matthias Klose wrote:
[discussing this outside the bug report on the ML]
On 03.11.19 14:39, Neil Williams wrote:
Actually, that's a good catch. I was mixing up the defaults package
with the general advice on py
[discussing this outside the bug report on the ML]
On 03.11.19 14:39, Neil Williams wrote:
Actually, that's a good catch. I was mixing up the defaults package
with the general advice on python3 migration to not remove
python-foo-doc just to rename it to python3-foo-doc.
where did you read that
On 03.11.19 02:20, Paul Wise wrote:
On Sat, Nov 2, 2019 at 6:04 PM Matthias Klose wrote:
At this point I'd ignore any Python2 related package, and concentrate on Python3
stuff only.
Yes, I was referring only to python3-* module packages.
Byte compilation is an optimization, speeding
On 02.11.19 04:22, Paul Wise wrote:
Hi all,
I run adequate on my system, which means I notice when Python module
packages don't bytecompile when they are installed. So far I've just
been ignoring the warnings that adequate prints.
https://salsa.debian.org/debian/adequate
In addition I noticed:
On 02.11.19 09:05, Hugo Lefeuvre wrote:
Hi Matthias,
I see that you just raised the severity of this bug to serious, and
Bleachbit is now to be removed on 16.11.
I don't think this is the way to go. Upstream is actively working on this.
We have recently managed the GTK3 migration, meaning that
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=py2keep;users=debian-python@lists.debian.org
doesn't show show too many packages yet, which is good. Not sure if we should
tag the dependencies of these packages with a different tag, e.g. py2keep-dep
for python-setuptools.
Im unsure if I unde
On 26.10.19 22:09, Rebecca N. Palmer wrote:
What should be done with modules where Python 3.8 compatibility requires moving
to a new upstream release that doesn't support Python 2, but the Python 2
package still has dependencies (so can't be removed yet under existing rules)?
- Split them into
For Python2 packages, dh-python 4.20191017 now rewrites any python shebang to
/usr/bin/python2 and generates dependencies on python2 instead of python.
The py2removal bugs have a section
"""
- If the package has still many users (popcon >= 300), or is needed to
build another package which can
Paul Gevers from the release team pointed out that the Python2 removal is
causing some uninstall-ability issues in testing because some packages
apparently are removed too early, but never the less are migrating to testing.
He suggested to make the removal plan more concrete and having a timelin
On 11.10.19 18:27, Christian Kastner wrote:
Hi,
python-cachetools provides modules for Python2 and Python3.
The Python2 module as two reverse dependencies, both with low installed
popcon:
python-cachetools: 302
mopidy-podcast: 109
mopidy-internetarchive: 95
This wo
On 12.09.19 17:01, Ian Jackson wrote:
Drew Parsons writes ("should Debian add itself to https://python3statement.org
?"):
https://python3statement.org/ is a site documenting the projects which
are supporting the policy of dropping Python2 to keep Python3 only.
That statement is a *pledge* to
On 10.09.19 20:31, Richard B. Kreckel wrote:
On 10.09.19 11:29, Matthias Klose wrote:
Please read the instructions, they mention to check dependencies, build
dependencies, and test dependencies ...
I have read https://wiki.debian.org/Python/2Removal and the linked
pages. Are there any other
On 05.09.19 19:50, Diane Trout wrote:
Hi,
The py2removal bug says to discuss the py2keep tag first.
src:cloudpickle is a dependency of src:spyder and src:skimage.
python-skimage has a popcon inst score of 469
spyder has a popcon inst score of 1385
spyder3 has a popcon inst score of 1069
The r
user debian-python@lists.debian.org
usertags 938836 - py2keep
thanks
> popcon is 15747.
I think that's too easy. There is a python3-xapian module which can be used by
the rdeps. The py2keep tag isn't meant for "I don't care to investigate" issues.
$ apt-cache rdepends python-xapian
python-x
On 01.09.19 21:48, Martin Kelly wrote:
Hi,
I maintain python-gmpy and python-gmpy2, which need to transition to Python 3.
However, they have several packages that have Suggests or Recommends (not a hard
dependency) pointing to python-gmpy/python-gmpy2. These other packages appear to
be Python
don't feel confident simply uploading someone's else package.
Best would probably be if Matthias Klose, one of the current Uploaders,
agrees to that and uploads the current package thus passing over
maintainership.
Matthias?
did you see my comment in #936270?
Please file Python2 removal bugs with the appropriate attributes.
It's
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertags: py2removal
- It's NOT "Usertag". Usertag is only recognized by the bug server.
- It's NOT "py2-removal". It's "py2removal".
See htt
On 24.08.19 07:03, Scott Kitterman wrote:
> On Thursday, August 15, 2019 8:08:41 AM EDT Thomas Goirand wrote:
>> Hi there!
>>
>> According to the daily graph I built here:
>> http://py2graph.infomaniak.ch/py2.7.deps.svg
>>
>> we can work on Python 2 removal for the below packages. Note that I have
On 25.08.19 00:08, Thomas Goirand wrote:
> On 8/24/19 10:38 AM, Neil Williams wrote:
>> How is that graph turned into a list of packages? It's too large to
>> scan manually.
>
> Well, I did it manually... and this is only a short list, as a
> suggestion for a todo list, so nothing exhaustive... I
On 13.08.19 15:30, peter green wrote:
> IMO python-monotonic should be reinstated until it's reverse dependencies are
> sorted out.
I agree with that.
On 16.07.19 17:31, Julien Puydt wrote:
> Le 16/07/2019 à 17:21, Andrey Rahmatullin a écrit :
>> Python 2 is included in buster and so will be supported for several
>> years.
>>
>
> The starting point of the thread was :
> 1. Ok, buster has Python 2 so even if upstream drops it, we will still
> sup
On 16.07.19 16:52, Paul Tagliamonte wrote:
> I lost some of this thread - should we request a transition
> from the release team? I was looking for the list of blockers
> to dropping Python 2 and couldn't find anything except this
> thread (where we're still figuring out what to do, of course)
#93
On 13.07.19 23:18, Emmanuel Arias wrote:
> Hello everybody,
>
> Next week will start the DebCamp and then DebConf. I would like to know
> to any debian python team member :-)
>
> Exist any plan for debian packaging during the DebCamp/DebConf?
>
> Unfortunately, I will arrive to Curitiba on 18th
On 07.07.19 16:55, Drew Parsons wrote:
> On 2019-07-07 22:46, Mo Zhou wrote:
>> Hi science team,
>>
>> By the way, when do we start dropping python2 support?
>> The upstreams of the whole python scientific computing
>> stack had already started dropping it.
>
> Good question. I think it is on the
On 24.01.19 00:16, Ben Finney wrote:
> Howdy all,
>
> What is a ‘py3versions’ (or alternative) command that can be run in
> AutoPkgTest, to query the Python versions that are installed on this
> machine *with* their standard library?
>
> The ‘pythonX.Y-minimal’ packages can be installed *without*
On 14.12.18 12:48, Simon McVittie wrote:
> Control: forwarded -1
> https://salsa.debian.org/ci-team/autopkgtest/merge_requests/42
> Control: tags -1 + patch
>
> On Fri, 14 Dec 2018 at 11:31:02 +, Simon McVittie wrote:
>> tl;dr: autopkgtest-virt-qemu doesn't work with python3.7.
>
> This seem
On 05.11.18 10:32, Matthias Klose wrote:
> On 05.11.18 09:17, Michael Hudson-Doyle wrote:
>> On Mon, 5 Nov 2018 at 21:09, Thomas Goirand wrote:
>>
>>> Hi there!
>>>
>>> During Debconf, we decided we would not decide yet, and see in November
>>>
1 - 100 of 524 matches
Mail list logo
