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
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
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 "telnetli
I could work on legacycrypt.
On Fri, Aug 2, 2024 at 4:19 AM Louis-Philippe Véronneau
wrote:
> 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
Le ven. 2 août 2024 à 11:19, Louis-Philippe Véronneau
a écrit :
> > Should it be a native package or one with real upstream on PyPi ?
So it seems there's a global need for those zombie-libraries.
> eamanu said he would make a list of upstream projects we could package,
> but if you have some time
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/li
Le ven. 2 août 2024 à 12:25, Blair Noctis 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
On 02/08/2024 18:55, Alexandre Detiste wrote:
> Le ven. 2 août 2024 à 12:25, Blair Noctis 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 f
Hello,
do you know if it exist a tool which automatically produce autopkgtest test
snipset from a conda meta.yaml file ?
since plenty of upstream are writing these kind of scripts, it would be great
to execute these test via autopkgtests when possible.
I have a student which is writting a to
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 t
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.
>
>
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"
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 al
On Fri, Aug 02, 2024 at 01:29:14PM +0200, PICCA Frederic-Emmanuel wrote:
> Hello,
>
>
> do you know if it exist a tool which automatically produce autopkgtest test
> snipset from a conda meta.yaml file ?
>
> since plenty of upstream are writing these kind of scripts, it would be
> great to ex
> Do you think there is value in those that we don't have in
> autopkgtest-pkg-pybuild? in my experience conda test commands are just
> ad-hoc commands to run e.g. pytest, but my experience with them is narrow.
I do not have lot's of experience for now, but at least the test suite is most
of the
Hi,
On Thu, Aug 01, 2024 at 09:14:01AM +0200, Alexandre Detiste wrote:
> Le lun. 22 juil. 2024, 12:59, Drew Parsons a écrit :
>
> > On 2024-07-22 11:40, Alexandre Detiste
>
> > I'm struggling with basemap... I don't understand how
> > > this multi-package with it's 3 setup.py works.
> > > It's
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
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/lin
Hi Team,
As it was proposed during the Python BoF at DebConf24, it would be nice
to try a "one day sprint" each 2 weeks. It would help us work on fixing bug
reports
and IMO it will be great for newcomers as well.
This would also remove the timezone issues we've been having for the irc/live
meet
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
20 matches
Mail list logo
