You can do conditional dependencies on those packages.

Like python3.13 | python3-xxxx

Then it will be installable on both.

In data venerd� 2 agosto 2024 10:21:55 CEST, Alexandre Detiste ha scritto:

Hi,

I will need some "zombie-telnetlib" (so exactly the same API as
existing telnetlib)
because I maintain proprietary .deb (not "Debian packages") that need
to be installable without rebuild on Buster, Bookworm & Trixie.

I understand that "telnetlib3" / "exscript" are 'better/newer' API but
that does not fit the need.

Debian could also benefit from this zombie-telnetlib.

Should it be a native package or one with real upstream on PyPi ?

Greetings

Le ven. 2 ao�t 2024 � 09:13, Louis-Philippe V�ronneau

<pollo@debian.org> a �crit :

telnetlib:
* telnetlib3: a Telnet Client and Server library for python [2]
* exscript: automating network connections over protocols such as Telnet
or SSH [3]

Is anyone in the DPT interested in packaging and maintaining these libraries? They will likely be very useful for the 3.13 transition.>
From the stats I have, I currently count:
* 37 packages using telnetlib

--
Salvo Tomaselli

"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
-- Galileo Galilei

https://ltworf.codeberg.page/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello,

In the 2nd Python BoF today, it was pointed out we should probably make sure the alternatives listed in PEP-594 for libraries removed in 3.13 are packaged in Debian.

I had a look, and these are the ones that should be packaged (all the other ones are already in the archive). There are no RFP open for them either:

crypt:
* legacycrypt: standalone version of crypt [1]

telnetlib:
* telnetlib3: a Telnet Client and Server library for python [2]
* exscript: automating network connections over protocols such as Telnet or SSH [3]

Is anyone in the DPT interested in packaging and maintaining these libraries? They will likely be very useful for the 3.13 transition.

From the stats I have, I currently count:

* 37 packages using telnetlib
* 300 packages using crypt

[1]: https://pypi.org/project/legacycrypt/
[2]: https://github.com/jquast/telnetlib3/
[3]: https://github.com/knipknap/exscript/

--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau
⢿⡄⠘⠷⠚⠋ pollo@debian.org / veronneau.org
⠈⠳⣄

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-08-02 17:21, Alexandre Detiste wrote:

Hi,

I will need some "zombie-telnetlib" (so exactly the same API as
existing telnetlib)
because I maintain proprietary .deb (not "Debian packages") that need
to be installable without rebuild on Buster, Bookworm & Trixie.

I understand that "telnetlib3" / "exscript" are 'better/newer' API but
that does not fit the need.

Debian could also benefit from this zombie-telnetlib.

Should it be a native package or one with real upstream on PyPi ?

That was another item we discussed during the 2nd BoF. There are already
some projects like these [1][2] and we were considering packaging them
to ease the 3.13 transition.

eamanu said he would make a list of upstream projects we could package,
but if you have some time, getting a list of projects would be great.

If we end up packaging these libraries, I think it should be clear that
they won't be available for Forky (Debian 14). The last thing we want is
to maintain some deprecated zombie-libraries forever in Debian :(

Cheers,

[1]: https://github.com/simonrob/pyasyncore
[2]: https://github.com/tiran/legacycrypt

--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau
⢿⡄⠘⠷⠚⠋ pollo@debian.org / veronneau.org
⠈⠳⣄

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Copy: debian-python@lists.debian.org

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------7v0YXwbb6OOpLBcjulN6vF0U
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 02/08/2024 16:21, Alexandre Detiste wrote:

Hi,

I will need some "zombie-telnetlib" (so exactly the same API as
existing telnetlib)
because I maintain proprietary .deb (not "Debian packages") that need
to be installable without rebuild on Buster, Bookworm & Trixie.

It's just /usr/lib/python3.12/telnetlib.py. You can probably copy it to your "proprietary" .deb and continue using it.

I understand that "telnetlib3" / "exscript" are 'better/newer' API but
that does not fit the need.

Hopefully the need can be fulfilled by a clever rewrite and/or an external library.

Debian could also benefit from this zombie-telnetlib.

How?

On the other hand, it would allow packages to continue relying on a thing expunged from upstream, a maintenance burden for both Debian and upstream.

--
Sdrager,
Blair Noctis

--------------7v0YXwbb6OOpLBcjulN6vF0U--

-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQScTWEJ927Sl0a/hB7sV97Kb1Pv6QUCZqy0GAAKCRDsV97Kb1Pv 6VH2AP49cLF6Zlnd0h1RLwcZrh8ahygG4KVmr9TH6TKz5LLESQD+NUSbJm0zVF/J PKkUenF1OU0BC11a1zhrM6Na/9jcaAE=
=9uzT
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 02 Aug 2024 at 19:40:59 +0800, Blair Noctis wrote:

Even today, 2 Aug 2024, is 2 months from the effective date. Please
file bugreports/issues to ask the packages you care about to migrate.

I agree with this part of what you said.

But, not this part:

Also, even python3.11 is still there. Sure someone needing something expunged from 3.13 would be fine staying with 3.12?

In unstable, yes, at least temporarily; but not forever (and 3.11 has
already disappeared from testing).

Also, many Debian developers think of our stable releases as being our
primary deliverable, with testing/unstable only being a tool that we
use to make the next stable release. In stable, we generally only have
one version of Python (for example Debian 12 has Python 3.11 and no
other version), because the Python maintainers and other core teams do not
have the resources to security-support more than one branch for 3 years.

smcv

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Copy: debian-python@lists.debian.org

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------cssiQsVsMNqBgaan1GdPqGc0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

On 02/08/2024 18:55, Alexandre Detiste wrote:

Le ven. 2 août 2024 à 12:25, Blair Noctis <n@sail.ng> a écrit :

Debian could also benefit from this zombie-telnetlib.

How?

On the other hand, it would allow packages to continue relying on a thing
expunged from upstream, a maintenance burden for both Debian and upstream.

If we for example need to patch 10 dead-upstream projects to re-add telnetlib.py
& the corresponding stanza in d/copyright it might be less work
to scale it out in an external source package.

All of this depends on how many packages will need this telnetlib.

codesearch gives pages and pages of stuff with a lot of false positives

https://codesearch.debian.net/search?q=telnetlib&literal=1&perpkg=1&page=5

Searching in regex mode with `import.*telnetlib path:*.py` should give more accurate results. But nevertheless:

Yeah, if they have not migrated. This PEP was first proposed in 2019, amended in
2022, and 3.13 is slanted to be released in October, 2024. Package authors should have had plenty of time to have this information propagated to them and migrate. Even today, 2 Aug 2024, is 2 months from the effective date. Please file bugreports/issues to ask the packages you care about to migrate.

If we for example need to patch 10 dead-upstream projects

which means the maintainer is now responsible for keeping it up to date. Including following Python upgrades and PEPs. But not by

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 still there. Sure someone needing something expunged from 3.13 would be fine staying with 3.12?

--
Sdrager,
Blair Noctis

--------------cssiQsVsMNqBgaan1GdPqGc0--

-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQScTWEJ927Sl0a/hB7sV97Kb1Pv6QUCZqzFywAKCRDsV97Kb1Pv 6eDbAP9Qu6woUywFjyP5tGMRZJcsvIvFtM0trOmO9jGF/RHZogEA1C30HH3pBRaQ fv3NtitVA5fgCUfa5gj9XsR2K/LIHw8=
=5MHI
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Package authors should have had plenty of time to have this information propagated to them and migrate.

In general, stuff that works doesn't receive many updates. And thinght might be abandoned upstream but still work fine and be used as dependencies for other things.


--
Salvo Tomaselli

"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
-- Galileo Galilei

https://ltworf.codeberg.page/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Copy: debian-python@lists.debian.org

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------rJnUdh2kKgZ25b26BAssyrku
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 02/08/2024 20:14, Salvo Tomaselli wrote:

Package authors should have had plenty of time to have this information
propagated to them and migrate.

In general, stuff that works doesn't receive many updates.

Yes, in fact I quite like the concept of "feature-complete passive maintenance".
However, it doesn't conflict with updating with upstream/language.

And thinght might be
abandoned upstream but still work fine and be used as dependencies for other things.

Covered in another email:

If we for example need to patch 10 dead-upstream projects

which means the maintainer is now responsible for keeping it up to date. Including following Python upgrades and PEPs.

--
Sdrager,
Blair Noctis

--------------rJnUdh2kKgZ25b26BAssyrku--

-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQScTWEJ927Sl0a/hB7sV97Kb1Pv6QUCZqzQngAKCRDsV97Kb1Pv 6ZBRAP49usUMKyfT+wfFiA2wBYnkUgpK0hNLC8OgmY2VMKMZzQEAjIycw3nUsgQT rCHIap4Z6XFHIzpM1CZUZ52CaJrX3wk=
=wNFa
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Copy: debian-python@lists.debian.org

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------hIPVkj5OZX2CXupSA0hvXr0M
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On 02/08/2024 20:07, Simon McVittie wrote:

On Fri, 02 Aug 2024 at 19:40:59 +0800, Blair Noctis wrote:

Even today, 2 Aug 2024, is 2 months from the effective date. Please
file bugreports/issues to ask the packages you care about to migrate.

I agree with this part of what you said.

But, not this part:

Also, even python3.11 is still there. Sure someone needing something expunged
from 3.13 would be fine staying with 3.12?

In unstable, yes, at least temporarily; but not forever (and 3.11 has
already disappeared from testing).

Also, many Debian developers think of our stable releases as being our primary deliverable, with testing/unstable only being a tool that we
use to make the next stable release. In stable, we generally only have
one version of Python (for example Debian 12 has Python 3.11 and no
other version), because the Python maintainers and other core teams do not have the resources to security-support more than one branch for 3 years.

Sorry, I daily drive unstable and overlooked that part. My apologies.

Though as you said, current stable bookworm/12 has 3.11, which definitely has those modules; next stable trixie/13 might have 3.13, but it would be frozen in 2025, by then we should have worked this out.

--
Sdrager,
Blair Noctis

--------------hIPVkj5OZX2CXupSA0hvXr0M--

-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQScTWEJ927Sl0a/hB7sV97Kb1Pv6QUCZqzPPgAKCRDsV97Kb1Pv 6TmtAP9yEqnD7DCqcKNLD6cwBchJqqo8+GPSE0qlFxv030JXrwEA9yZF7rmNeBJF UPy9NTvJm71NkRftGnQjPmiGb7b38Ak=
=kSTJ
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, Aug 02, 2024 at 02:11:41PM +0200, Salvo Tomaselli wrote:

If we end up packaging these libraries, I think it should be clear that they won't be available for Forky (Debian 14). The last thing we want is
to maintain some deprecated zombie-libraries forever in Debian :(

The alternative to using asynccore might be major rewrites.

At this poinrt I think python is a joke.

Which is a popular opinion.
Still, asyncore was deprecated in 2016.

--
WBR, wRAR

-----BEGIN PGP SIGNATURE-----

iQJhBAABCgBLFiEEolIP6gqGcKZh3YxVM2L3AxpJkuEFAmas0oQtFIAAAAAAFQAP cGthLWFkZHJlc3NAZ251cGcub3Jnd3JhckBkZWJpYW4ub3JnAAoJEDNi9wMaSZLh yowP/jupJjPqs2xgmT8cF1rFe15I48REuqfo1Sjb9p8YPgD610gC7B74bGhiyLpP RB/S1biWn3nfIR/5OoWMc4h9p7jQOoVteYHg1a5qNeqp7kwkilwf2XO8NmJVk+jB /d5xoeHKdkEUZ8f+spcml6hsqzCYSMCqg2WYzGKlyvfgDMOdOUMfd/phB3TvRUr2 VgskfaAuwyJbDPsb8XVjpRap9JqxcAYOctp6Ponyhzyv3mKUjOGnT5pdzaBIv2xn g5OAHFfu9lDNGY1fFDn4ZxjfKwBwykx/FwoDz5sUf4PO7oXvGXM3WbJnREkNboDf tosuRqsmrmZCqpfcZoXZ1Earo+kuufuVdKVAURAt7dt16VYCbko9QZ0bA3nF1Iph iSa4r/xKDr7rU2KgWMTSbDGrUh6OV7MRdYtRKejVkMGuE+wmk6X2IKSWLZoXcJA4 awe4L581beYgBpgJkub+IqVEgBBa9OM7kDQzN1eECwKvpNntKuRKuHRCLOVHJET8 FZ8qRI/eUAZcbGCVEiiouV7E0KQ5GgQ4J7nPjd+29siboPuBmArqCCqTqFAiAxZg I4ZXWpsz/0RTX5t2qVeiex7KTiBvOEdYffFSH32h4uxZVzH2cPRlg2PA9e2ywUiW exRhQoYO4OJ4pbyhycPGudl2cTspEhF5UwqMx9a8+17E2xnY
=36Rc
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Which is a popular opinion.
Still, asyncore was deprecated in 2016.

Eh, software is 8 years old so it needs a full rewrite now?


--
Salvo Tomaselli

"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
-- Galileo Galilei

https://ltworf.codeberg.page/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-08-02 23:06, Salvo Tomaselli wrote:

Which is a popular opinion.
Still, asyncore was deprecated in 2016.

Eh, software is 8 years old so it needs a full rewrite now?

Please try to keep comments that are not productive to the current
efforts to some other channels?

That kind of email certainly doesn't motivate me to make things in
Debian better :(

--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau
⢿⡄⠘⠷⠚⠋ pollo@debian.org / veronneau.org
⠈⠳⣄

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-08-02 20:40, Blair Noctis wrote:

https://codesearch.debian.net/search?q=telnetlib&literal=1&perpkg=1&page=5

Searching in regex mode with `import.*telnetlib path:*.py` should give more accurate results. But nevertheless:

I did this work already in Lintian:

https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Check/Languages/Python/StdlibDeprecation.pm?ref_type=heads

The current code for "uses-deprecated-python-stdlib" in Sid is flawed
(see #1077324) but that will be fixed in the next Lintian release.

When that happens, I'm planning on making a MBF.

--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau
⢿⡄⠘⠷⠚⠋ pollo@debian.org / veronneau.org
⠈⠳⣄

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 still there. Sure someone needing something expunged from 3.13 would be fine staying with 3.12?

The idea of having these libraries around for Trixie (and to remove them
after the release) is to ease the 3.13 transition.

From my preliminary analysis, there are more than 600 packages that use
one of the stdlib that'll be removed in 3.13.

That is a lot of work and I doubt we'll have a successful transition
without this temporary measure.

--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau
⢿⡄⠘⠷⠚⠋ pollo@debian.org / veronneau.org
⠈⠳⣄

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 still there. Sure someone needing something
expunged
from 3.13 would be fine staying with 3.12?

The idea of having these libraries around for Trixie (and to remove them after the release) is to ease the 3.13 transition.

From my preliminary analysis, there are more than 600 packages that use
one of the stdlib that'll be removed in 3.13.

There's also the option to remove packages from testing and/or unstable.
I assume, we'll see a lot of packages still using old modules getting
removed from testing, once 3.13 becomes the default. It's also an option
to remove those completely, if they are not maintained.

That is a lot of work and I doubt we'll have a successful transition
without this temporary measure.

can we agree on a naming for the packaging, e.g.
python3-zombie-<module>, so that we make it clear, that people are using obsolete code?

we do that for python3-zombie-imp already.

Matthias

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Louis-Philippe Véronneau, on 2024-08-03:

On 2024-08-02 20:40, Blair Noctis wrote:

https://codesearch.debian.net/search?q=telnetlib&literal=1&perpkg=1&page=5

Searching in regex mode with `import.*telnetlib path:*.py` should give more accurate results. But nevertheless:

I did this work already in Lintian:

https://salsa.debian.org/lintian/lintian/-/blob/master/lib/Lintian/Check/Languages/Python/StdlibDeprecation.pm?ref_type=heads

The current code for "uses-deprecated-python-stdlib" in Sid is flawed (see #1077324) but that will be fixed in the next Lintian release.

Cool! Thanks for the fix! :)

When that happens, I'm planning on making a MBF.

Have a nice day, :)
--
.''`. Étienne Mollier <emollier@debian.org>
: :' : pgp: 8f91 b227 c7d6 f2b1 948c 8236 793c f67e 8f0d 11da
`. `' sent from /dev/tty1, please excuse my verbosity
`-

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEj5GyJ8fW8rGUjII2eTz2fo8NEdoFAmat6NQACgkQeTz2fo8N EdrfVQ//SSy/EdJ54QaPsF+tUIViKYFH9YA3h/kKlHtfmgWitrx0MI6R4fkiF+3E rSdhnp19qD2Yi7QnIM5opSOCvmvdyUEcN78YuSWAky7hGKUz2sCAzNKGQArDwQ09 uQCzwBgPO6lURNwnCEqjMcdbbpkrujQfe3Qqj65i89az2hk60Y+6vC0MFG1P7hHy 2Tsumf0RitJuAEfkb+MV5ntYoGQH/CjGd2EPaQR8aVReY1IGLIhwT9/aHykQiwRQ wS4OWrx+ZIHUFDkLwosc9HF9VumF92NixpTc+CwWg5IJNy04bdniXUuP7zdebUwI PpbPOTJb6dVGAIgLMudNathzsQtEYsI1fWzdbmGg7SONYJh8sisJX8XOrEKWnLl1 z/Lm43QzGsWeV5LodniImV6IcL9XmNgI0WCnQS2f4xhvkjt177dgW328IcBNw8xI iD48HBOi1/ibClcwJ38wmgEdhS5BPtFQom6rZabJ6gs4gTtUWBz7ie3cHplqP+IS DsfceqvpNEst+hOr1Dkz6U1NVPiTIzuOYutnkyfMPvluDCIe7JKCLur23b/C1RoB Jij9KbmFQSsQ0q4Yc3KJW1PX9jkFtCIUNAH6vm5GUtCSGPQTm+ayvtJrukvqQwqU mIgzB7KnN8Kx8fMqXECHNezgo0KjUiWeEjfpEsZgbulflMsdvSM=
=4wI+
-----END PGP SIGN

[snip]

eamanu said he would make a list of upstream projects we could package, but if you have some time, getting a list of projects would be great.

I add a section here [0]. I'm going add the modules there, please feel
edit it.


[0] https://wiki.debian.org/Python/Dead%20Batteries#preview


Cheers,
Emmanuel
[snip]



-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEE3lnVbvHK7ir4q61+p3sXeEcY/EFAmat9mgACgkQ+p3sXeEc Y/GpNg/+M9X7jmdPRRli4LRwUVQVEIkTXOuB+Y1HEFqBJTwUlNG4sXX4bQzSlDDJ FS4eFqW2QpQD4H4b/1xHresJs7ruRtzUYM0JCrLX2T4qqq7KWxol+eZQRP18+xHc KnuhWkWIbWE8c/H8tKJBFrYtoHmooRbfjfON9jPwLZxrX4GNcQMSjmHuEkZfQbKp hqlwBkaol5RM8erxGK0bq6d50YylZhO5LClX80OGHq+o8M6rpSDLuFSG4gDCYhkI xYWOgfNET5lO6qyXpXtc+AqefeLU1fbtrbvePdLv9U2yMGBRHAhEn8xzWvtuHVBN OWh3mrxOQr/rtJ7wA4imAD2wV8PxxYJqdkqEV5jroM/F1/uvcLLProOhbAUcIHGQ 5fw7pkE4OwERow40T2vSFzGCcAXkKeMGLAWj/0mUJUhud8Gp/UQ2q2gDSduM5fGa 9aFadSAiyCfGhAa5I7M24utuDY7et80WpVVaZmHmolQ2/voskXI4Vast026z2fAk gG5hNXV3t/VqWWLtKSwQT5Zn2jnxSbxTYx/flLEA+xqBytS1PuVcNT4n/6mC0W75 FMymrH7Kvt4fFVkCQMIRYa1SkZp2g+v8BbS7ZpjM3JDHiQJklYWQRuLh1D0R6WJs CrJE1v3Jn+4Gub2uh2QRxNUs84pxW5y8Rh0uCA0INNAebmlRgKc=
=k6LQ
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Copy: pollo@debian.org (Louis-Philippe =?ISO-8859-1?Q?V=E9ronneau?=)

In data sabato 3 agosto 2024 03:08:13 CEST, Louis-Philippe V�ronneau ha scritto:

On 2024-08-02 23:06, Salvo Tomaselli wrote:

Which is a popular opinion.
Still, asyncore was deprecated in 2016.

Eh, software is 8 years old so it needs a full rewrite now?

Please try to keep comments that are not productive to the current
efforts to some other channels?

That kind of email certainly doesn't motivate me to make things in
Debian better :(

I think I wasn't clear enough.

I don't think there's any sort of problem with us having a python3- droppedmodule in debian forever (until nothing depends on it), if the dropped module has no security implications.

I don't think dropping software that works completely fine helps anyone, just because python upstream decided they didn't like some module any longer.

Best

--
Salvo Tomaselli

"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
-- Galileo Galilei

https://ltworf.codeberg.page/
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEQnSLnnbYmXmeH74Us6fPDIAYhs8FAmauNSwACgkQs6fPDIAY hs+vCA//XO98iWqKw4xQkFwEFYDJ+3z1BekAymqYDPlspTGCyuaVd3CXIzgadZrW Twpy5Z6sXzyVDkkb0AWkd4ZllyxAjIGnqjZDPO2nXHgm/QFTMDZ6ft6YLAfdT0UP Fpegc5VL8Pr+WywZE1xPvMhKNljNSfWrDrtMrNvb8YzGuNbj9OUhoxvpboqHSrhf hUHkPrt2CL4NCpzgWRSMqyxORMYdINxk5+GroabqlU6XbYYGayuGW/t3EMKXUYsM 2LOnGbMm9e5rtHRjI1iBxvAne8XHrHshwfVcOgSdi0WA2ogLx3tDetG4hU6Eh9oe MD2yAKJn04Ba8h8Jr8W2US++oh6K2k98+pKDXV5PXyEG8l/GyDqzP1QaoRQnhJ2f reuFKnE+4tzQEtazPWehPcKZGWqMCdNklL+eUlyO1nWTRCoYdMkYlgTn+VO5pBhO UujLk2TQMYpSmOt1pDMV27z2Uluk55OSbvawNsdZCEoGe7CSB5UV43je/DRs9UeX N246RRV9vREJgD21vSbjzyvtBTD0FRoDi3/UwQDtjG65vrd5eTPMl9MQ+UUOhYkX 7lBU3wBOqg1j+C4PLf6nyf6j16MBAkHdaMz5IMX1jbah4sWJf4Cs129WgMx9IO7K lFdgh6T52k99HBZgYvCWzhCiJ

This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------QKA4MEblaSwLL8MB3pFvm7YE
Content-Type: multipart/mixed; boundary="------------iqIC7qdBoT7V0rnQdrrqFPaj"

--------------iqIC7qdBoT7V0rnQdrrqFPaj
Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64

T24gMjAyNC0wOC0wMyA0IGggMDIgYS5tLiwgTWF0dGhpYXMgS2xvc2Ugd3JvdGU6DQo+IE9u IDAzLjA4LjI0IDA3OjI1LCBMb3Vpcy1QaGlsaXBwZSBWw6lyb25uZWF1IHdyb3RlOg0KPj4g T24gMjAyNC0wOC0wMiAyMDo0MCwgQmxhaXIgTm9jdGlzIHdyb3RlOg0KPj4+PiB0byBzY2Fs ZSBpdCBvdXQgaW4gYW4gZXh0ZXJuYWwgc291cmNlIHBhY2thZ2UNCj4+PiB3aGljaCBpcyBl ZmZlY3RpdmVseSBnb2luZyBhZ2FpbnN0IFB5dGhvbiB1cHN0cmVhbSwgYWxsb3dpbmcgdGhl IA0KPj4+IHRoaW5nIHRvIGxpdmUNCj4+PiBvbiwgYW5kIHBlb3BsZSB0byBzYXkgIml0J3Mg c3RpbGwgYWxpdmUgaW4gRGViaWFuISINCj4+Pg0KPj4+IEFsc28sIGV2ZW4gcHl0aG9uMy4x MSBpcyBzdGlsbCB0aGVyZS4gU3VyZSBzb21lb25lIG5lZWRpbmcgc29tZXRoaW5nIA0KPj4+ IGV4cHVuZ2VkDQo+Pj4gZnJvbSAzLjEzIHdvdWxkIGJlIGZpbmUgc3RheWluZyB3aXRoIDMu MTI/DQo+Pg0KPj4gVGhlIGlkZWEgb2YgaGF2aW5nIHRoZXNlIGxpYnJhcmllcyBhcm91bmQg Zm9yIFRyaXhpZSAoYW5kIHRvIHJlbW92ZSANCj4+IHRoZW0gYWZ0ZXIgdGhlIHJlbGVhc2Up IGlzIHRvIGVhc2UgdGhlIDMuMTMgdHJhbnNpdGlvbi4NCj4+DQo+PiDCoEZyb20gbXkgcHJl bGltaW5hcnkgYW5hbHlzaXMsIHRoZXJlIGFyZSBtb3JlIHRoYW4gNjAwIHBhY2thZ2VzIHRo YXQgDQo+PiB1c2Ugb25lIG9mIHRoZSBzdGRsaWIgdGhhdCdsbCBiZSByZW1vdmVkIGluIDMu MTMuDQo+IA0KPiBUaGVyZSdzIGFsc28gdGhlIG9wdGlvbiB0byByZW1vdmUgcGFja2FnZXMg ZnJvbSB0ZXN0aW5nIGFuZC9vciB1bnN0YWJsZS4gDQo+IEkgYXNzdW1lLCB3ZSdsbCBzZWUg YSBsb3Qgb2YgcGFja2FnZXMgc3RpbGwgdXNpbmcgb2xkIG1vZHVsZXMgZ2V0dGluZyANCj4g cmVtb3ZlZCBmcm9tIHRlc3RpbmcsIG9uY2UgMy4xMyBiZWNvbWVzIHRoZSBkZWZhdWx0LiBJ dCdzIGFsc28gYW4gb3B0aW9uIA0KPiB0byByZW1vdmUgdGhvc2UgY29tcGxldGVseSwgaWYg dGhleSBhcmUgbm90IG1haW50YWluZWQuDQo+IA0KPj4gVGhhdCBpcyBhIGxvdCBvZiB3b3Jr IGFuZCBJIGRvdWJ0IHdlJ2xsIGhhdmUgYSBzdWNjZXNzZnVsIHRyYW5zaXRpb24gDQo+PiB3 aXRob3V0IHRoaXMgdGVtcG9yYXJ5IG1lYXN1cmUuDQo+IA0KPiBjYW4gd2UgYWdyZWUgb24g YSBuYW1pbmcgZm9yIHRoZSBwYWNrYWdpbmcsIGUuZy4gcHl0aG9uMy16b21iaWUtIA0KPiA8 bW9kdWxlPiwgc28gdGhhdCB3ZSBtYWtlIGl0IGNsZWFyLCB0aGF0IHBlb3BsZSBhcmUgdXNp bmcgb2Jzb2xldGUgY29kZT8NCj4gDQo+IHdlIGRvIHRoYXQgZm9yIHB5dGhvbjMtem9tYmll LWltcCBhbHJlYWR5Lg0KDQpJIGxpa2UgdGhpcyBhIGxvdCBhbmQgSSBzdXBwb3J0IHRoaXMg bmFtaW5nIHNjaGVtZS4NCg0KLS0gDQogICDiooDio7TioL7ioLviorbio6bioIANCiAgIOKj vuKggeKioOKgkuKggOKjv+KhgSAgTG91aXMtUGhpbGlwcGUgVsOpcm9ubmVhdQ0KICAg4qK/ 4qGE4qCY4qC34qCa4qCLICAgcG9sbG9AZGViaWFuLm9yZyAvIHZlcm9ubmVhdS5vcmcNCiAg IOKgiOKgs+KjhA0KDQo=
--------------iqIC7qdBoT7V0rnQdrrqFPaj
Content-Type: application/pgp-keys; name="OpenPGP_0xE1E5457C8BAD4113.asc" Content-Disposition: attachment; filename="OpenPGP_0xE1E5457C8BAD4113.asc" Content-Description: OpenPGP public key
Content-Transfer-Encoding: quoted-printable

-----BEGIN PGP PUBLIC KEY BLOCK-----

xjMEYEPdjBYJKwYBBAHaRw8BAQdA5yh8SOHhcvKeX/A4rv0/JTCL8Kgnnwy4/okK h1Htbs3NOExvdWlzLVBoaWxpcHBlIFbDqXJvbm5lYXUgPGxvdWlzLXBoaWxpcHBl QHZlcm9ubmVhdS5vcmc+wpkEExYKAEECGwMFCQHhM4AFCwkIBwMFFQoJCAsFFgID AQACHgECF4AWIQT2TWHTIfPLSJFWdT3h5UV8i61BEwUCYEPeHgIZAQAKCRDh5UV8 i61BE0xKAP4oRsMaA2T/Zjge126dwHbnxBsjI/Q3ky8QkGlOffUKJAEA9dWm0hE4 0URSXM8Ndtf+GeHxvNeryVMCtVDUfjHMBA/CmQQTFgoAQQIbAwULCQgHAwUVCgkI CwUWAgMBAAIeAQIXgAIZARYhBPZNYdMh88tIkVZ1PeHlRXyLrUETBQJiEWgLBQkD rr3/AAoJEOHlRXyLrUETOK0BAM9I6BMMiqhsORsRcDVcM4VTm8G67YHapBW5zdl/ llfxAPwLAsi32TCPWjuwD3UdKig+6syvKFsiIfjiNBweNIQED8KZBBMWCgBBAhsD BQsJCAcDBRUKCQgLBRYCAwEAAh4BAheAAhkBFiEE9k1h0yHzy0iRVnU94eVFfIut QRMFAmPExgwFCQWDEYAACgkQ4eVFfIutQRNr2AD+L1MzuP25AZMyDYNUNmxbTOEg TP6PV/QrLnwhklD4pIcBAL3Zi/VynLJIvCxRUcvzCalWVJ3F/GAL0PqwTOuRda0N wpkEExYKAEECGwMFCwkIBwMFFQoJCAsFFgIDAQACHgECF4ACGQEWIQT2TWHTIfPL SJFWdT3h5UV8i61BEwUCZb/fiAUJDuIDfAAKCRDh5UV8i61BE004AQCHEbsPWc/N IGpUErFr4mBtStwhYRZr+FmfoW9IylhVbAD/fOeZfkf/IciaFQPb0eorhWqA2KMo Xay7G1vVTM7DiQfNLExvdWlzLVBoaWxpcHBlIFbDqXJvbm5lYXUgPHBvbGxvQGRl Ymlhbi5vcmc+wpYEExYKAD4WIQT2TWHTIfPLSJFWdT3h5UV8i61BEwUCYEPd6wIb AwUJAeEzgAULCQgHAwUVCgkICwUWAgMBAAIeAQIXgAAKCRDh5UV8i61BE3izAQCQ AM5ypBaNwptKQFupJR7+o5w3jC0v+vbQGyUEQzRAIQEAxkE63ACWQHABSqGHodlJ UaJJtcRty3PhQ6WRjiiQWgXClgQTFgoAPgIbAwULCQgHAwUVCgkICwUWAgMBAAIe AQIXgBYhBPZNYdMh88tIkVZ1PeHlRXyLrUETBQJiEWgLBQkDrr3/AAoJEOHlRXyL rUETCLcA/jnHuZdEAUSbGsdQuTF3t+yZOXCDFdnjh9IuIXenNsKmAP99Vp9KreW7 +4tcvtibAnirb9DCLGENy1NVxvJPYaW/AcKWBBMWCgA+AhsDBQsJCAcDBRUKCQgL BRYCAwEAAh4BAheAFiEE9k1h0yHzy0iRVnU94eVFfIutQRMFAmPExgwFCQWDEYAA CgkQ4eVFfIutQRO9JAEAkEhUgwuGUbdWhKnakB4DHcl/27WAb/Ig10C98nKKRSYA /j5y02CKj5Ydd3iMi/Y+Vt15W2N4mMw0bc0XHOrJx+sKwpYEExYKAD4CGwMFCwkI BwMFFQoJCAsFFgIDAQACHgECF4AWIQT2TWHTIfPLSJFWdT3h5UV8i61BEwUCZb/f iAUJDuIDfAAKCRDh5UV8i61BEzdaAP0cGJp8CpkywzefhdaJjfK5/uAQLRg5Bk6y CWnyR8B4wQEAxA4C39PJPsosgOVBMdfkzCPhGVynYBnujOyEcksX1w/OMwRgQ+DR FgkrBgEEAdpHDwEBB0BJt6Q0DfEmfFSEx6cry21+bw5N6meJcckQ3RKbX/OaJ8LA NQQYFgoAJhYhBPZNYdMh88tIkVZ1PeHlRXyLrUETBQJgQ+DRAhsCBQkB4TOAAIEJ EOHlRXyLrUETdiAEGRYKAB0WIQTKp0AHB6gWsCAvw830JXpQshz6hQUCYEPg0QAK CRD0JXpQshz6hazDAQChFPOW6RzpKzg9oKGiCa51PMx17MXUVDNPkcfQLgRVrAD/ Ul9rKwr6x4v/N0RApQcPdwx2Dw28y05d9wyDgSIVFgTVJAEA8qJQKpIwuqXtC1aI H/GYMVRiW01rf40uNFhGw0p970kA/1kRpdjqg77ejDCnFs2mEGmFKQf72URqDQN3 cESjA4oMwsA1BBgWCgAmAhsCFiEE9k1h0yHzy0iRVnU94eVFfIutQRMFAmISe8MF CQOvznIAgXYgBBkWCgAdFiEEyqdABweoFrAgL8PN9CV6ULIc+oUFAmBD4NEACgkQ 9CV6ULIc+oWswwEAoRTzlukc6Ss4PaChogmudTzMdezF1FQzT5HH0C4EVawA/1Jf aysK+seL/zdEQKUHD3cMdg8NvMtOXfcMg4EiFRYECRDh5UV8i61BE9joAQCf1i+t POWIC+fI95/eRdcK/If3vd0+f/nf2y5eKt4GewD+Kq3CI57jvnz7bx+CxdpVSnIV wSGKuy7T8iHNKelVdQ3CwDUEGBYKACYCGwIWIQT2TWHTIfPLSJFWdT3h5UV8i61B EwUCY8TGFgUJBYMORQCBdiAEGRYKAB0WIQTKp0AHB6gWsCAvw830JXpQshz6hQUC YEPg0QAKCRD0JXpQshz6hazDAQChFPOW6RzpKzg9oKGiCa51PMx17MXUVDNPkcfQ LgRVrAD/Ul9rKwr6x4v/N0RApQcPdwx2Dw28y05d9wyDgSIVFgQJEOHlRXyLrUET /dEA/AgqUnNa1JZr9Tle8LWPq8QYkBUCxqnoVOR+f+blHlXFAQDToU8ZL2N22j2U yHMNz8p2L2MNeMCs3mj8HjMAm98LBsLANQQYFgoAJgIbAhYhBPZNYdMh88tIkVZ1 PeHlRXyLrUETBQJlv9+vBQkO4gBeAIF2IAQZFgoAHRYhBMqnQAcHqBawIC/DzfQl elCyHPqFBQJgQ+DRAAoJEPQlelCyHPqFrMMBAKEU85bpHOkrOD2goaIJrnU8zHXs xdRUM0+Rx9AuBFWsAP9SX2srCvrHi/83REClBw93DHYPDbzLTl33DIOBIhUWBAkQ 4eVFfIutQRNGFwD5AVYQfZSNgQ8OfCX2UVgYFeku22XO0ufqng2gzJHXiTMBAKMJ UmRsYhd7KfPx5LEv+B2bIhl+cVZUJDuzLnEFWFYPzjgEYEPg5RIKKwYBBAGXVQEF AQEHQIES2w30v+hi13deaiPcx7KPVMCUIA25nu6by9Wfa5BuAwEIB8J+BBgWCgAm FiEE9k1h0yHzy0iRVnU94eVFfIutQRMFAmBD4OUCGwwFCQHhM4AACgkQ4eVFfIut QRMNhgD9HkVqB+Vy+F9EAzjHilHnSPft2xfLdhTrqzh6O0jEhqsA/2dd/AMSsZNA H8FYQKq3Th+Hikj+jXXs+P9HYlULp1UHwn4EGBYKACYCGwwWIQT2TWHTIfPLSJFW dT3h5UV8i61BEwUCYhJ72AUJA6/OcwAKCRDh5UV8i61BE2CVAP9+JHidrPFWE7Ww NskxdVY1YzHxGihO20Zt65AagSMVgAD9FlBCTPfQKpvC5jBax89pLAg07QsLq1wJ 5U5v1zV5JQTCfgQYFgoAJgIbDBYhBPZNYdMh88tIkVZ1PeHlRXyLrUETBQJjxMYf BQkFgw46AAoJEOHlRXyLrUETqTUBAI8cz/gDORn8lcDQ/tzvXYiyZBeelktw++Si mxhIlUmMAQC9ZISRQeqa52/EUErTMrg3e3hgZ7SiYNXaRCuj4vTrBMJ+BBgWCgAm AhsMFiEE9k1h0yHzy0iRVnU94eVFfIutQRMFAmW/37AFCQ7iAEoACgkQ4eVFfIut QRMGGgEA4b20EKpkwxf33aHc34mOOSFmHJG/awrymlZ3z+gzmPUBAP3nmhFpjqtj aTmKQXrFYwWQi3vIyr9VjzHyy2DnwyAHzjMEYhFqKxYJKwYBBAHaRw8BAQdAZIVA ArBgjmmj0WOB9pSYnoI6fIRa3bhpJbeKsTMoCfPCeAQoFgoAIBYhBPZNYdMh88tI kVZ1PeHlRXyLrUETBQJi6C3mAh0DAAoJEOHlRXyLrUETlWQA/RNjQxvcQamu4GY2 Ka0JGOBM1IFJGWOYOZdOOoyNFrzfAQDytAG+Eo8e3pDyQw2uIAfzK9YbQsqGaz8r Cge7ZLgkA8LANQQYFgoAJhYhBPZNYdMh88tIkVZ1PeHlRXyLrUETBQJiEWorAhsC BQkB4TOAAIEJEOHlRXyLrUETdiAEGRYKAB0WIQSQXfPjkatdPeFHEpNmts1qvsDb lgUCYhFqKwAKCRBmts1qvsDbljr/AQCn3i6trKCXohwwHaFdLKUMaFSQ5nthc4Jg Qsa9CsUX0AD/c2h8CPfjY4q5gvBqLyBr3me8MVyf7/I2BZ2WnVYSEQapPgEA1ypU 5j7Fiw+kpzL1vpBdUmx1Kumj6gC125xGov4U06wA/j7ezWTtSqiUIiCfpoj9SyJT 6omSjD7fLjXcPCiqh1cGzjgEYhFxEhIKKwYBBAGXVQEFAQEHQGUjAsbDR5A4iNrZ 6fRV9V5ft/fyp63vY3e3sbWtCxgBAwEIB8J4BCgWCgAgFiEE9k1h0yHzy0iRVnU9 4eVFfIutQRMFAmLoLhcCHQMACgkQ4eVFfIutQRNw9wD7B/YAwKzq2Ov3dvy3n6cp o/skeQxwxFqRL0Phk55wPXsBAOi4Bxsdw0Tfyn5FtXqF8ZZ2hXkD16oICzhY/JM2 JA4Awn0EGBYKACYWIQT2TWHTIfPLSJFWdT3h5UV8i61BEwUCYhFxEgIbDAUJAeEz gAAKCRDh5UV8i61BE4p2APd4nRcoabtOeBFUWxc/8m1QJaRqpHbevfi2Ldwq9ESJ AQDQETDGHeO5Vf9fwtX1rHpkbmQwnfgcx/6O28om5FGuDg==
=78EK
-----END PGP PUBLIC KEY BLOCK-----

--------------iqIC7qdBoT7V0rnQdrrqFPaj--

--------------QKA4MEblaSwLL8MB3pFvm7YE--

-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQTKp0AHB6gWsCAvw830JXpQshz6hQUCZri9fwAKCRD0JXpQshz6 ha+cAQCinwrrvPyWYBlm6Cpqhq+02EGcZ8WvEy044+yGj1dKgwEA7gJxx91mcSaM my5hYmsdrIxHFVL66hPaXSOvnFxPegY=
=zqDE
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)