On 20.05.25 15:04, Andreas Tille wrote:
@Matthias: I noticed that all but one of your packages (knxd) are not
featuring Vcs fields (and knxd is not on Salsa but on Github). If it is
your personal policy to not use Salsa that's fine and I would remove
your ID from the Bug of the Day query.
/llvm-toolchain-15_1%3A15.0.7-15build1_1%3A15.0.7-15ubuntu1.diff.gz
Matthias
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
__init__.py" are not copied in
from the source tree,
and without them Python refuses to recognize the copy.
Ugh.
Do we have any other namespaced packages in the archive? How do *they* handle
this?
--
-- regards
--
-- Matthias Urlichs
OpenPGP_signature.asc
Description: OpenPGP digital signature
top of my TODO
list …) if anybody wants to take a closer look.
--
-- regards,
--
-- Matthias Urlichs
OpenPGP_signature.asc
Description: OpenPGP digital signature
levels of this addition are done.
Matthias
[1] https://release.debian.org/transitions/html/python3.13-add.html
for the Python 3.12 transition. Please note
that we don't enable any of the experimental features in Python 3.12 (no
GIL, JIT compilation), so assuming there are currently no other RC
issues in your packages, there should plenty of time to fix any 3.13
related issues.
Matthias
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
nd of
documentation is not helping very much. So maybe the people already
knowing all the quirks could come up with a way to rewrite the docs?
We even could have that as the first topic for a Python BoF, before
starting any other topic ...
Matthias
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
the default before the
transition freeze.
Matthias
is ready to start the python3.13-add transition.
plus we should not do that before the 3.13 upstream release. I'm
targeting 1-2 weeks after the 3.13 release for the addition of 3.13 as a
supported Python version.
Matthias
might want to check with the 3.13 bugs
already filed by Stefano for overlaps, but that should not be a
showstopper. It's important that maintainers are aware of these reports,
and that we can raise severities when we are progressing with the 3.13
transitions.
Matthias
e the package's build system away from setuptools/distutils.
dd-list attached.
please
- user-tag
- add tags sid trixie
- add a phrase to the bug reports, that the severity
might be increased before the trixie release.
Matthias
that is already used to keep python3-nose
artificially alive.
I'd like to avoid addressing a single module. 3.13 has a whole bunch of
modules that are removed in the standard library.
What's the status of filing bug reports for all these removed modules?
Matthias
ode?
we do that for python3-zombie-imp already.
Matthias
t out of python3-
stdlib-extensions, then it might come up pretty soon. Is anyone planning on
working on this (I confess I thought someone already had).
it will be removed once we stop having 3.11 as a supported Python version.
Matthias
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
w, Stefano will be there as well, and hopefully not
only involved with the video team ;p
Matthias
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
there a way to see the binNMUs which are still stuck in unstable, and
don't migrate?
Matthias
identified most of them, and fixed these. At least we were now able to
do all the binNMUs.
You could package a non-conflicting cython-legacy, however that would
require more changes, also how to build it.
Matthias
and I am looking forward to helping out with the
firehose package.
Best,
Matthias
--
I welcome VSRE emails. See http://vsre.info/
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
challenge over time with 1000+ packages.
I'm planning to ask Lucas for a normal test rebuild of unstable, once we
have a reasonable amount of packages built with 3.12 in unstable. Bugs
for these will be filed, but we probably have to usertag these our self.
Matthias
ren't blocked by the
addition of 3.12. Then planning for the defaults change in January.
While this timeline is not that much needed for 3.12, it will be a good
exercise for 3.13, so that we get 3.13 as the default into the trixie
release.
Matthias
[1] https://bugs.debia
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
Sorry,
forgot this:
I have read and acknowledged the Debian Python Teams' policy.
My salsa login is werdahias.
Regards,
---
Matthias Geiger (werdahias)
14. März 2023, 00:23 von matthias.geiger1...@tutanota.de:
> Hi all,
>
> could I please get access to the python salsa team ? I
. The packaging for the four new
libraries is essentially done locally.
Regards,
---
Matthias Geiger (werdahias)
-BEGIN PGP PUBLIC KEY BLOCK-
mQINBGJGNsQBEADCVylaCtYtBQW4NmDrZOIizSrVlv5ZJ5WJ128MAblWk3fRFPya
Cs/klkTT58ehBSr61sXVP+NpkF7MWOBu2CNg66U40a/Eb+v4poxNaIjXKvQtf51S
y5yGwmTc7IJg8Huo
ckages would be affected.
Matthias
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
w and upload it if you got
the time.
Cheers
Matthias
21. Nov. 2022, 20:04 von c.schoen...@t-online.de:
> Hello Matthias,
>
> Am 21.11.22 um 16:39 schrieb matthias.geiger1...@tutanota.de:
>
>> Dear Maintainers,
>>
>> I'd like to join the team and get access to m
hat I read the packaging policy. My salsa username is werdahias.
I'm not a DD yet, so I'd need sponsorship for this package.
Regards,
Matthias Geiger (werdahias)
-BEGIN PGP SIGNATURE-
iQIzBAEBCgAdFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmN7m58ACgkQGL0Qazts
VHWcXBAAk4c3S7Lj04xbXeaqYQmWB
Package: wnpp
Severity: wishlist
Owner: Matthias Geiger
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-python@lists.debian.org
* Package name : python3-fints
Version : 3.1.0
Upstream Author : Raphael Michel
* URL : https://pypi.org/project/fints/
* License
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
no longer part of Debian.
Regards Matthias
Am 05.01.22 um 05:15 schrieb Paul Wise:
> On Tue, 2021-12-28 at 18:37 +0100, Matthias wrote:
>
>> but it would be great, if RadioTray will get back into the official
>> Debian repository.
>
> Please note the extra steps required when
it would be great, if RadioTray will get back into the official
Debian repository.
I have already written a mail to the old Debian maintainer Elías
Alejandro Año Mendoza, but did not get an answer.
Is here someone, who is willing to sponsor RadioTray?
Regards,
Matthias
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
>
ists/linux-sig.python.org/
Thanks, Matthias
mples.
The modules are not built in any different way from all the modules shipped in
Debian.
Matthias
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.
}-is-python3 built from the what-is-python source to the CTTE.
Matthias
+Removal of the unversioned packages
+---
+
+Starting with the Debian 11 release (bullseye), the binary packages
+``python``, ``python-minimal``, ``python-dev``, ``python-dbg`` and
+``python-doc
on of "Python upstream" supporting
users using Python on Debian on upstream communication channels like #python on
Freenode. Yes, I have heard the complaints, but usually things are not
forwarded to Debian. Stefano and myself have recently joined #python, so let's
see if that can help.
Matthias
ch are really supported?
There's no python packaging specific approach. So yes, either make it
architecture dependent, or maybe add code to the entry points (__init__.py) to
raise an ImportError on unsupported architectures?
Matthias
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
laces.
> Anyway, my point is that we should collective aim to be consistent
> across the Python packages. The fact that some packages have made their
> "not *3" binaries be the python3 versions, and others not, due to
> arbitrary individual maintainer decisions, is a mess.
it's a difficult decision to make. But if people want, then we could ship
pytest-is-python2 and pytest-is-python3 packages as well, as long as we don't
build-depend on those.
Matthias
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
with b-d n python3-all-dev, but not
building for 3.9, bug reports also filed).
The major outstanding issue is the pandas stack, all other problems are found in
leaf packages (leaf in the sense of that no other package for the 3.9 addition
is blocked).
Please help fixing the remaining issues!
Matthias
y packages, there's no src:python package.
> - Bump the severity of the few remaining packages in testing to RC
> state (and force them out testing if auto removals were blocked
> for some reason)
See above, I think it's unfriendly to push out pypy3.
Matthias
that at all. It usually is only
an issue when adding a new python version, and this happens once in a year. The
transition tracker [1] provides a guidance how to build stuff in which order,
based on dependencies, but doesn't take care about build-dependencies,
autopkgtest dependencies, and dependency cycles. And binNMUing 600 packages
takes time ...
Matthias
[1] https://release.debian.org/transitions/html/python3.9.html
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 17.09.20 15:26, Matthias Klose wrote:
> If there is too much disagreement about the
> python-is-python3 package, then I plan to run it via the CTTE, and ask for an
> advice how to move on.
FWIW and IMHO that's a reasonable compromise.
--
-- Matthias Urlichs
signature.a
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
olicy. Note that such a package including the
Provides should only be uploaded once all dependencies on the unversioned python
packages are gone.
Matthias
[1] https://lists.debian.org/debian-python/2020/07/msg00039.html
[2] https://launchpad.net/ubuntu/+source/what-is-python
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
r. That should give plenty of time to address any
unversioned python usage before the release freeze.
Matthias
[1]
http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=py2removal;users=debian-python@lists.debian.org
[2]
http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=py2keep;users=debian-python@lists.debian.org
do the defaults change to
3.9, or if we drop 3.9 again, or ship with two supported Python3 versions.
Please note this will be a re-occuring situation with Python 3.11 and
bullseye+1, so we should find out how to handle this on a regular basis,
assuming that Debian release schedules won't change much.
Matthias
eaningful debug sessions. I'm not preferring
this solution.
I'm currently tending to implement the second scenario, but if people think that
having the -dbg packages available is still useful, then also opt for the third
option.
Matthias
reason that you cannot use it?
> Hopefully this won't be controversial. There's really no way to avoid it.
well, better don't assume that.
Matthias
still could keep 3.7 as a supported python3 version for some time,
if people want to work on those issues. But people probably won't have the time
to work on that when we introduce 3.9.
Matthias
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
providing
a python command, incompatible with everybody else. New users will not
understand that Debian doesn't have a python command when there's no Python2
anymore.
What we will do is to get rid off the unversioned python for all the packaging
in the archive, so that users can do what they want.
Matthias
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,
think that's the correct choice. For
now these seem to be single packages, so please could you name those, and we can
look at those with a priority? That's at least a path that is forward looking,
or feel free to propose another approach better than your current proposal for
not getting the attention of maintainers.
Matthias
PS: There's a RC issue for creduce now, not caused by the package itself, should
I downgrade it?
ore doesn't match, only building for the default Python3.
Matthias
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
me new test failures.
Matthias
[1] https://wiki.debian.org/Python/Python3.8.
[2]
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=python3.8;users=debian-python@lists.debian.org
o two negated bullet points may be clearer to
those whose first language doesn't possess a negative list operator.
please could one of you open an issue with a patch to track the change?
Thanks, Matthias
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
hts?
I'd say, there are currently more pressing issues than that, like the Python2
removal, or the introduction of Python 3.8. 3.8 also offers a central directory
for bc files, so that's maybe another thing to look at, but not a priority now
from my point of view.
Matthias
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
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
op spyder? I didn't look at
skimage, but maybe look there first if it needs to be Python2.
Matthias
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
1 - 100 of 565 matches
Mail list logo
