On Sun, Oct 13, 2019 at 11:41:38PM -0400, Nicholas D Steeves wrote:
> Hi Thomas and Python Team,
>
> Thomas Goirand writes:
>
> > For example, today I looked into removing Python 2 from python-cogent.
> > Running sixer on all files lead to a huge log of problems to solve by
> > hand. There's no
Hi,
po 14. 10. 2019 v 4:52 odesílatel Thomas Goirand napsal:
> But in both cases, it's going to take a very long time. Do we really
> want to get stuck on these packages for like forever, or would it feel
> ok to raise the severity to serious, so that the package gets
> auto-removed and then we
On 9/16/19 10:03 PM, Hans-Christoph Steiner wrote:
>>> I know the Ruby team also decided to use debian/salsa-ci.yml instead of
>>> debian/gitlab-ci.yml [2]. I guess we should also do the same.
> This is still an open question:
> https://salsa.debian.org/salsa-ci-team/pipeline/issues/86
>
> Debian
>> But in both cases, it's going to take a very long time. Do we really
>> want to get stuck on these packages for like forever, or would it feel
>> ok to raise the severity to serious, so that the package gets
>> auto-removed and then we can work on removing Python 2 from its
>> dependencies?
>
>
> It's becoming increasingly clear to me that, at some point, we will need
> to just ignore the breakage.
no, please dont. it's way too early to even think about that.
--
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google
Hello,
and if at the end the upstream could take care of the Debian packaging, by
adding a
.salsa-ci.yml in the upstream directory, in order to have a feedback with nice
badges ?
Cheers
On Mon, Oct 14, 2019 at 09:54:18AM -0400, Sandro Tosi wrote:
> i think it's a bit premature to raise severity to RC (we should also
> check with the release team): these bugs have been opened since just 2
> months and a half, and the development cycle for bullseye started not
> longer before. there
Package: ftp.debian.org
Severity: normal
User: debian-python@lists.debian.org
Usertags: py2removal
http://www.alittletooquiet.net/software/sclapp/ is dead.
The current upstream code was uploaded to Debian in 2008.
Reverse deps checked with dak rm -Rnb python-sclapp
--
WBR, wRAR
signature.asc
> As of now, calibre is not of sufficient quality to be part of a Debian release
> and until it drops all Python2 requirements, it must be considered RC buggy.
Is your quality argument based on the Calibre author's shenanigans?
https://www.reddit.com/r/linux/comments/9wodtq/calibre_wont_migrate_to
Oh, and by the way, I just saw this:
https://github.com/kovidgoyal/calibre/blob/master/README.python3
Perhaps a working Py3 port is not so far off after all.
On Mon, 14 Oct 2019 20:18:10 +0200
Gregor Riepl wrote:
> > As of now, calibre is not of sufficient quality to be part of a
> > Debian release and until it drops all Python2 requirements, it must
> > be considered RC buggy.
>
> Is your quality argument based on the Calibre author's shenanigans?
On Mon, 14 Oct 2019 20:22:40 +0200
Gregor Riepl wrote:
> Oh, and by the way, I just saw this:
> https://github.com/kovidgoyal/calibre/blob/master/README.python3
>
> Perhaps a working Py3 port is not so far off after all.
>
Then it can be introduced as a new upload when it is ready.
It's not r
Hi everyone,
I'd like to migrate my current membership of the debian-python DPMT
and PAPT teams on salsa to use my shiny, new DD account \o/. My salsa
account is nickm.
Thank you for your help, guidance, mentorship and sponsored uploads so far!
Cheers,
Nick
Hi All,
Just be careful with the bugs severity on complicated packages. I totally
get the python only packages that produce a single binary, go for it for
those.
However consider the net-snmp python module. It's python 2 only and
upstream isn't changing it. In fact I am pretty sure they don't su
On 10/14/19 11:05 PM, Craig Small wrote:
> Hi All,
> Just be careful with the bugs severity on complicated packages. I
> totally get the python only packages that produce a single binary, go
> for it for those.
>
> However consider the net-snmp python module. It's python 2 only and
> upstream is
On 10/14/19 3:54 PM, Sandro Tosi wrote:
>>> But in both cases, it's going to take a very long time. Do we really
>>> want to get stuck on these packages for like forever, or would it feel
>>> ok to raise the severity to serious, so that the package gets
>>> auto-removed and then we can work on remo
On Tue, 15 Oct. 2019, 1:04 pm Thomas Goirand, wrote:
>
> Either we don't have enough details about net-snmp, or you're trying to
> push for not-valid-yet-another-exception.
>
It's more if a source package makes multiple binary packages, one of those
being a python 2 package, and there are other
On Tue, 15 Oct. 2019, 1:04 pm Thomas Goirand, wrote:
> Please re-read the excellent contribution from Neil Williams
> in this thread, and explain again why we have a special case... :)
I just did re-read it; especially about it's RC bugs not a total removal RM
so these packages will sit in unsta
18 matches
Mail list logo
