Re: Python 2 removal in sid/bullseye: Progress and next steps

[Norbert Preining]

Hi Mo,

On Tue, 12 Nov 2019, Mo Zhou wrote:
> How many users still use these unmaintained scripts? Could you please
> provide us a reference/estimated popcon so we can better understand the
> situation of texlive in terms of py2rm.

Popcon does not help, since these scripts are part of a huge collection,
and on the TL side we do not do any tracking at all (we could, since the
TeX Live Manager tlmgr could be asked to track what is installed), we
have not even the slightest ideas about what is actually in use. But for
examples latex-make is still Py2, and is generally in use.

I checked all the scripts I could find, see below, so the situation is
not bad at all, at least in plane numbers.

Best

Norbert

(relatives to texmf-dist/scripts/)

changes/pyMergeChanges.py
already py3, needs shebang
de-macro/de-macro
py2 only
dviasm/dviasm.py
py2
ebong/ebong.py
only py2
latex-make/
unclear
latex-make/figdepth.py
latex-make/gensubfig.py
latex-make/latexfilter.py
latex-make/svg2dev.py
latex-make/svgdepth.py
latex-papersize/latex-papersize.py
py2
lilyglyphs/
py2 only
lilyglyphs/lily-glyph-commands.py
lilyglyphs/lily-image-commands.py
lilyglyphs/lily-rebuild-pdfs.py
lilyglyphs/lilyglyphs_common.py
pdfbook2/pdfbook2
py2
pgfplots/pgfplots.py
unclear
pygmentex/pygmentex.py
unclear, probably only Py2
pythontex/
there are py3 versions, but defaults seems to be py2
pythontex/depythontex.py
pythontex/depythontex2.py
pythontex/depythontex3.py
pythontex/pythontex.py
pythontex/pythontex2.py
pythontex/pythontex3.py
pythontex/pythontex_engines.py
pythontex/pythontex_2to3.py
pythontex/pythontex_install.py
pythontex/pythontex_utils.py
sympytexpackage/sympytex.py
unclear
texliveonfly/texliveonfly.py
should work with py3, but needs new shebang
webquiz/*
already py3

--
PREINING Norbert   http://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Re: Python 2 removal in sid/bullseye: Progress and next steps

[Mo Zhou]

On Tue, Nov 12, 2019 at 10:07:26AM +0900, Norbert Preining wrote:
> Yes, we have a lot of python scripts, and some have been written more
> than 10 years ago, and there is no maintainer anymore.
> ...
> And *we* at the TeX side prefer not to simply throw out old stuff, see
> above.

How many users still use these unmaintained scripts? Could you please
provide us a reference/estimated popcon so we can better understand the
situation of texlive in terms of py2rm.

Re: Python 2 removal in sid/bullseye: Progress and next steps

[Norbert Preining]

Hi Matthias,

On Mon, 11 Nov 2019, Matthias Klose wrote:
> sure, and when everybody is doing that, we end up with Python2 in bullseye+2
> as well. Python3 is around for 10+ years now...

Well, the whole py2/py3 mess shouldn't have happened at all, but this is
not any of our faults, but purely Python devs.

> As an example for texlive-base, we filed https://bugs.debian.org/938655 two

Yes, we have a lot of python scripts, and some have been written more
than 10 years ago, and there is no maintainer anymore.

TeX world is different, people expect that their stuff from 20 years ago
still works the same way - and it does, besides when some #%$'%#$$#
decides to deprecate a whole programming language.
All those short-sighted devs should learn from DEK.

I am working on this, but tracking down devs from the early 2000 years
and ask them to update their scripts to Py3 is bothersome.

And *we* at the TeX side prefer not to simply throw out old stuff, see
above.

Best

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Re: Python 2 removal in sid/bullseye: Progress and next steps

[Norbert Preining]

Hi Ondrey, hi all,

thanks to you (and all the others) for answers.

> It's team work, I "only" sent that email :). It looks like others already

Yes, in this sense with "you" I meant the Python Team and everyone
working on it.

> time line=now. 1.5 year is really short period for doing so much work in
> Debian. Imho we are already too late to make it, but let's try it. :)

Thanks, that is what I wanted to know. It wasn't clear.

> as other sad, RoQA. But maintainer can always stop this. Py2keep tag, fix

py2keep tag added to those packages I think need it, at least for the
time being.

Best

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Re: Automated removal of RC buggy packages

[Sam Hartman]

> "Matthias" == Matthias Klose  writes:

Matthias> why do you even consider such uploads suitable for
Matthias> unstable?  That's something which should go to
Matthias> experimental.  And I would like to see some automatic
Matthias> demotion from unstable to experimental for packages with
Matthias> RC issues which are not fixed for some time.

we are not in agreement.
The package had entirely adequate code quality that users should not
need to install additional sources to enjoy the functionality.

Also, in some cases, I had the version in unstable but a newer version
in experimental.

Re: Automated removal of RC buggy packages

[Matthias Klose]

On 12.11.19 00:00, Sam Hartman wrote:

"Moritz" == Moritz Mühlenhoff  writes:


 Moritz> Scott Kitterman  schrieb:
 >> One maintainer doesn't get to block the removal of an entire
 >> stack like Qt4.  I think there's a reasonable point of discussion
 >> about when RoQA is appropriate, but there comes a time when stuff
 >> just has to go.  That doesn't make it a free for all, but for
 >> old, unsupported libs we should have a bias towards action.

 Moritz> We should even work towards automating this further; if a
 Moritz> package is RC-buggy for longer than say a year (with some
 Moritz> select exceptions) it should just get auto-removed from the
 Moritz> archive.


if you do this, please standardize a way for a maintainer to flag that
they don't want a version package in testing.
I had a package that was "RC buggy" for a couple of years because I
didn't have confidence in the stability of the over the wire protocol.
Similarly I've had RC buggy packages because I wasn't confident in my
ability to provide support across a stable release.


why do you even consider such uploads suitable for unstable?  That's something 
which should go to experimental.  And I would like to see some automatic 
demotion from unstable to experimental for packages with RC issues which are not 
fixed for some time.


Matthias

Re: Automated removal of RC buggy packages

[Moritz Mühlenhoff]

On Mon, Nov 11, 2019 at 06:00:18PM -0500, Sam Hartman wrote:
> Moritz> We should even work towards automating this further; if a
> Moritz> package is RC-buggy for longer than say a year (with some
> Moritz> select exceptions) it should just get auto-removed from the
> Moritz> archive.
> 
> if you do this, please standardize a way for a maintainer to flag that
> they don't want a version package in testing.

Agreed, for that use case it always felt a bit of a kludge to apply the default
RC bugs severities, as it also clutters the list of actionable
bugs for people to work on (as a maintainer-imposed "serious" isn't actionable
compared to an actually fixable serious bug)

Possible options might be a dedicated RC bug severity like "block-testing" or
maybe a maintainer-accessible way to upload britney block hints for their own
packages hints via dcut or so.

Cheers,
Moritz

Automated removal of RC buggy packages

[Sam Hartman]

> "Moritz" == Moritz Mühlenhoff  writes:

Moritz> Scott Kitterman  schrieb:
>> One maintainer doesn't get to block the removal of an entire
>> stack like Qt4.  I think there's a reasonable point of discussion
>> about when RoQA is appropriate, but there comes a time when stuff
>> just has to go.  That doesn't make it a free for all, but for
>> old, unsupported libs we should have a bias towards action.

Moritz> We should even work towards automating this further; if a
Moritz> package is RC-buggy for longer than say a year (with some
Moritz> select exceptions) it should just get auto-removed from the
Moritz> archive.


if you do this, please standardize a way for a maintainer to flag that
they don't want a version package in testing.
I had a package that was "RC buggy" for a couple of years because I
didn't have confidence in the stability of the over the wire protocol.
Similarly I've had RC buggy packages because I wasn't confident in my
ability to provide support across a stable release.

Yes, this could have been done with a block at the release team.
But I liked that I retained control as a maintainer and that when I was
ready I could just close that bug without asking anyone.
I know the RT is responsive, but those sort of little things like
letting people solve their own problems when it's possible do matter for
keeping Debian fun.

--Sam

Re: Python 2 removal in sid/bullseye: Progress and next steps

[Moritz Mühlenhoff]

Scott Kitterman  schrieb:
> One maintainer doesn't get to block the removal of an entire stack like Qt4.
> I think there's a reasonable point of discussion about when RoQA is
> appropriate, but there comes a time when stuff just has to go.
> That doesn't make it a free for all, but for old, unsupported libs
> we should have a bias towards action.

We should even work towards automating this further; if a package is
RC-buggy for longer than say a year (with some select exceptions)
it should just get auto-removed from the archive.

These "transitions" of phasing out obsolete software (qt4, openssl 1.0,
etc.) are currently too manual and too time-consuming.

Cheers,
Moritz

Re: Python 2 removal in sid/bullseye: Progress and next steps

[Ondřej Surý]

Sorry for top post, I am just on my phone. Just my two cents - the RoQA is a 
pretty standard thing when you deal with bigger transitions and there’s a lot 
of unmaintained packages.

Been there couple of times, and it was nowhere near py2 removal magnitude. So, 
I just want to send huge thanks towards the Python team and you have my support 
to make things as easier for you as you can. I think you drafted excellent and 
considerate plan.

O.
--
Ondřej Surý 

> On 11 Nov 2019, at 22:15, Ondrej Novy  wrote:
> 
> 
> Hi,
> 
> po 11. 11. 2019 v 16:27 odesílatel Norbert Preining  
> napsal:
>> thanks for your work on the Python2 removal.
> 
> It's team work, I "only" sent that email :). It looks like others already 
> replied, but
> 
>> Could you please give a time line of how you are planning to proceed?
> 
> time line=now. 1.5 year is really short period for doing so much work in 
> Debian. Imho we are already too late to make it, but let's try it. :)
> 
>> I think requesting the removal of packages that you are **not**
>> maintaining is - to be polite - a bit unconventional (at least).
>> This remains at the discretion of the maintainer as far as I remember.
> 
> as other sad, RoQA. But maintainer can always stop this. Py2keep tag, fix 
> package, even anyone else can NMU it. Removing is last and least preferred 
> option. This is happening mostly for unmaintained/dead upstream packages, low 
> popcons, MIA maintainers, QA packages, etc.
> 
>> > All dependency fields in debian/control and debian/tests/control must
>> > also be updated to stop using the unversioned python 
>> 
>> Are all you "must" statements "policy decisions"? Or your personal wish
>> list items?
> 
> Python policy update is underway.
> 
> Thank you.
> 
> -- 
> Best regards
>  Ondřej Nový
> 

Re: Python 2 removal in sid/bullseye: Progress and next steps

[Ondrej Novy]

Hi,

po 11. 11. 2019 v 16:27 odesílatel Norbert Preining 
napsal:

> thanks for your work on the Python2 removal.
>

It's team work, I "only" sent that email :). It looks like others already
replied, but

Could you please give a time line of how you are planning to proceed?
>

time line=now. 1.5 year is really short period for doing so much work in
Debian. Imho we are already too late to make it, but let's try it. :)

I think requesting the removal of packages that you are **not**
> maintaining is - to be polite - a bit unconventional (at least).
> This remains at the discretion of the maintainer as far as I remember.
>

as other sad, RoQA. But maintainer can always stop this. Py2keep tag, fix
package, even anyone else can NMU it. Removing is last and least preferred
option. This is happening mostly for unmaintained/dead upstream packages,
low popcons, MIA maintainers, QA packages, etc.

> All dependency fields in debian/control and debian/tests/control must
> > also be updated to stop using the unversioned python
>
> Are all you "must" statements "policy decisions"? Or your personal wish
> list items?
>

Python policy update is underway.

Thank you.

-- 
Best regards
 Ondřej Nový

Bug#944563: ITP: libb-cow-perl -- additional B helpers to check COW status

[gregor herrmann]

Package: wnpp
Owner: gregor herrmann 
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, debian-p...@lists.debian.org

* Package name: libb-cow-perl
  Version : 0.001
  Upstream Author : Nicolas R. 
* URL : https://metacpan.org/release/B-COW
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : additional B helpers to check COW status

B::COW provides some naive additional B helpers to check the COW status of
one SvPV.

A COWed SvPV is sharing its string (the PV) with other SvPVs. It's a (kind
of) Read Only C string, that would be Copied On Write (COW).

More than one SV can share the same PV, but when one PV need to alter it, it
would perform a copy of it, decrease the COWREFCNT counter.

One SV can then drop the COW flag when it's the only one holding a pointer to
the PV.

The COWREFCNT is stored at the end of the PV, after the "\0".

That value is limited to 255, after that a new PV would be created,

The package will be maintained under the umbrella of the Debian Perl Group.

--
Generated with the help of dpt-gen-itp(1) from pkg-perl-tools.


signature.asc
Description: Digital Signature

Re: please avoid writing useless/annoying stuff in debian/gbp.conf

[Russ Allbery]

"Theodore Y. Ts'o"  writes:

> Yes, and that's why I use debian/master instead of debian/buster or
> debian/bullseye.  :-)

> When I do create debian/buster (once it became the stable branch), the
> first thing I did after I branched off debian/buster from debian/master
> was to edit debian/gbp.conf was to have:

> debian-branch=debian/buster

> I only do this when I need to do the first stable backport of a
> serious/security bug, such that I have to create the debian/buster
> branch in the first place.  So it hasn't been all that annoying for me.

+1 this is my approach too.

-- 
Russ Allbery (r...@debian.org)  

Re: Python 2 removal in sid/bullseye: Progress and next steps

[Scott Kitterman]

On November 11, 2019 3:10:32 PM UTC, Norbert Preining  
wrote:
>Hi Ondřej,
>
>(please Cc, I am not subscribed to debian-devel)
>
>thanks for your work on the Python2 removal.
>
>On Mon, 11 Nov 2019, Ondřej Nový wrote:
...
>
>Furthermore,
>
>> We will also then file bug reports against ftp.debian.org to remove
>> such packages from unstable.  We are going to do this semi-
>
>I think requesting the removal of packages that you are **not**
>maintaining is - to be polite - a bit unconventional (at least).
>This remains at the discretion of the maintainer as far as I remember.
...
Um. No.

We have RoQA rm requests for a reason.  You can see it in action in the recent 
past on Qt4 related packages.

One maintainer doesn't get to block the removal of an entire stack like Qt4.  I 
think there's a reasonable point of discussion about when RoQA is appropriate, 
but there comes a time when stuff just has to go. That doesn't make it a free 
for all, but for old, unsupported libs we should have a bias towards action.

For Qt4, I think we're well past it.  For python2 it's coming up fast.  We 
started with roughly 3,000 python2 packages.  We've done the easy half.

I know the next release is far in the future, but given the size and complexity 
of the removal effort, I think we're already at risk of not getting it done.  
I'm not the maintainer of the interpreter packages not the Debian 
infrastructure packages (I used to be, but lacked time to continue working on 
it), so my opinion is only that of a DD with multiple affected packages, but I 
don't think my views on this are at all extreme.

Scott K

Re: please avoid writing useless/annoying stuff in debian/gbp.conf (was: source only upload with git-buildpackage)

[Theodore Y. Ts'o]

On Mon, Nov 11, 2019 at 08:58:42AM +0100, Thomas Goirand wrote:
> >> Please, *never* do that. It's generally a very bad idea to write
> >> anything to debian/gbp.conf. It's as if you were adding your text editor
> >> preferences in the package. Instead, please prefer writing in ~/.gbp.conf.
> > 
> > I keep most of my git-buildpackage settings which are specific to my
> > developer environment in ~/.gbp.conf.  However, there are some gbp
> > settings which are specific to the repository set up, and those I
> > think, IMHO, *are* appropriate for debian/gbp.conf.  For example:
> > 
> > [DEFAULT]
> > pristine-tar = True
> > upstream-tag='v%(version)s'
> > debian-branch=debian/master
> 
> The first 2, yes. The last one, it's my opinion that it's useless, and
> that you only need it because "ignore-branch = True" isn't the default
> in git-buildpackage. It's ok as long as you always keep the same
> packagig branch, but if, like in my team, we need a new branch name
> every 6 months, and for 400+ repositories, then keeping the branch name
> declared in debian/gbp.conf becomes super annoying (as it forces one to
> change the "debian-branch" each time).

Yes, and that's why I use debian/master instead of debian/buster or
debian/bullseye.  :-)

When I do create debian/buster (once it became the stable branch), the
first thing I did after I branched off debian/buster from
debian/master was to edit debian/gbp.conf was to have:

debian-branch=debian/buster

I only do this when I need to do the first stable backport of a
serious/security bug, such that I have to create the debian/buster
branch in the first place.  So it hasn't been all that annoying for
me.

Cheers,

- Ted

Bug#944543: ITP: erlang-unicode-util-compat -- unicode_util compatibility library for Erlang <= 20

[Philipp Huebner]

Package: wnpp
Severity: wishlist
Owner: Philipp Huebner 

* Package name: erlang-unicode-util-compat
  Version : 0.5.0
  Upstream Author : Benoit Chesneau
* URL : https://github.com/benoitc/unicode_util_compat
* License : Apache-2.0
  Programming Lang: Erlang
  Description : unicode_util compatibility library for Erlang <= 20

 This library allows the usage of unicode_util and string from Erlang R21 in
 older Erlang >= R18.
 It is primarily needed to provide backports of ejabberd for Buster.

Bug#944540: ITP: erlang-idna -- pure Erlang IDNA implementation that follows RFC 5891

[Philipp Huebner]

Package: wnpp
Severity: wishlist
Owner: Philipp Huebner 

* Package name: erlang-idna
  Version : 6.0.0
  Upstream Author : Benoit Chesneau
* URL : https://github.com/benoitc/erlang-idna
* License : MIT
  Programming Lang: Erlang
  Description : pure Erlang IDNA implementation that follows RFC 5891

 This library adds support for IDNA 2008 and IDNA 2003 to Erlang.
 IDNA is short for "Internationalized Domain Names in Applications" and is
 standardized in RFC 5891.

Re: Python 2 removal in sid/bullseye: Progress and next steps

[Matthias Klose]

On 11.11.19 16:10, Norbert Preining wrote:

Hi Ondřej,

(please Cc, I am not subscribed to debian-devel)

thanks for your work on the Python2 removal.

On Mon, 11 Nov 2019, Ondřej Nový wrote:

We are going to raise the severity of the py2removal bugs to "serious"
in several steps.  In the

...

Could you please give a time line of how you are planning to proceed?
The next Debian release is still about 1.5 years away (extrapolating
from the last N releases), so I don't see any extreme urgency to purge
Debian from Py2 packages *now* at a time when it is even still
supported?


sure, and when everybody is doing that, we end up with Python2 in bullseye+2 as 
well. Python3 is around for 10+ years now...



Do you have any timeline? Plans beside "...we are going to raise
...remove..."?

I would strongly suggest to wait till january at least to start this process,
upstream authors might wait till the last moment ...

Furthermore,


We will also then file bug reports against ftp.debian.org to remove
such packages from unstable.  We are going to do this semi-


I think requesting the removal of packages that you are **not**
maintaining is - to be polite - a bit unconventional (at least).
This remains at the discretion of the maintainer as far as I remember.


As an example for texlive-base, we filed https://bugs.debian.org/938655 two 
months ago which didn't see a reply yet.  This issue gives you three options, so 
no we are not requesting the removal.



All dependency fields in debian/control and debian/tests/control must
also be updated to stop using the unversioned python


Are all you "must" statements "policy decisions"? Or your personal wish
list items?


yes, that is covered in #943666, and will be uploaded soonish.

Please don't get me wrong, things like the Python2 removal are going to be 
painful, we have to start it.


Matthias

Bug#944539: ITP: ignition-cmake2 -- CMake modules to be used by the Ignition projects (v2)

[Jose Luis Rivero]

Package: wnpp
Severity: wishlist
Owner: Jose Luis Rivero 

* Package name: ignition-cmake2
  Version : 2.1.1
  Upstream Author : Open Source Robotics Foundation
* URL : https://ignitionrobotics.org/libraries/cmake
* License : Apache2
  Programming Lang: CMake
  Description : CMake modules to be used by the Ignition projects (v2)

 CMake modules to be used by the Ignition projects (v2)

 This package is required to build ignition projects, as well as to link
 other third party projects against them. It provides modules that are used to
 find dependencies of ignition projects and generate cmake targets for
 consumers of ignition projects to link against.

 Series 2.x of the package, designed to be co-installable with version1.
 Not API compatible.

Re: Python 2 removal in sid/bullseye: Progress and next steps

[Mattia Rizzolo]

Hi, I'm going to answer, even if I'm not Ondrej :)

On Tue, Nov 12, 2019 at 12:10:32AM +0900, Norbert Preining wrote:
> On Mon, 11 Nov 2019, Ondřej Nový wrote:
> > We are going to raise the severity of the py2removal bugs to "serious"
> > in several steps.  In the
> ...
> 
> Could you please give a time line of how you are planning to proceed?
> The next Debian release is still about 1.5 years away (extrapolating
> from the last N releases), so I don't see any extreme urgency to purge
> Debian from Py2 packages *now* at a time when it is even still
> supported?
> 
> Do you have any timeline? Plans beside "...we are going to raise
> ...remove..."?
> 
> I would strongly suggest to wait till january at least to start this process,
> upstream authors might wait till the last moment ...

I don't know about which particular timeline they were thinking about,
but I honestly hope they start already.
Sure, we are already at nearly half of the process, but now start the
much more complex cases.  Starting from leaf packages right now only
makes sense, it will take weeks to just start crawling the tree anyway.

> > We will also then file bug reports against ftp.debian.org to remove
> > such packages from unstable.  We are going to do this semi-
> 
> I think requesting the removal of packages that you are **not**
> maintaining is - to be polite - a bit unconventional (at least).
> This remains at the discretion of the maintainer as far as I remember.

That's not true.  RoQA have been used for years, and from what I could
see of the flow of RM bugs related to python2, quite a bit were already
done like that.
It might be unpolite at times, sure, but that's not really an excuse.

Anyway, if you properly maintain your packages, and you maintain
non-leaf packages you need not worry; if you maintain leaf packages, at
least share in the py2removal bugs your plans.  That ought to stop
people from removing your packages, even if it won't stop them to raise
the severity to RC when the time comes.

> > All dependency fields in debian/control and debian/tests/control must
> > also be updated to stop using the unversioned python 
> 
> Are all you "must" statements "policy decisions"? Or your personal wish
> list items?

They are "policy decisions" as in, "python policy" (even the package is
not yet updated).  Dependencies are already being automatically changed
by dh-python.  If there is one thing sure for bullseye, the
/usr/bin/python symlink won't be shipped.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: Python 2 removal in sid/bullseye: Progress and next steps

[Norbert Preining]

Hi Ondřej,

(please Cc, I am not subscribed to debian-devel)

thanks for your work on the Python2 removal.

On Mon, 11 Nov 2019, Ondřej Nový wrote:
> We are going to raise the severity of the py2removal bugs to "serious"
> in several steps.  In the
...

Could you please give a time line of how you are planning to proceed?
The next Debian release is still about 1.5 years away (extrapolating
from the last N releases), so I don't see any extreme urgency to purge
Debian from Py2 packages *now* at a time when it is even still
supported?

Do you have any timeline? Plans beside "...we are going to raise
...remove..."?

I would strongly suggest to wait till january at least to start this process,
upstream authors might wait till the last moment ...

Furthermore,

> We will also then file bug reports against ftp.debian.org to remove
> such packages from unstable.  We are going to do this semi-

I think requesting the removal of packages that you are **not**
maintaining is - to be polite - a bit unconventional (at least).
This remains at the discretion of the maintainer as far as I remember.

> All dependency fields in debian/control and debian/tests/control must
> also be updated to stop using the unversioned python 

Are all you "must" statements "policy decisions"? Or your personal wish
list items?

Thanks

Norbert

(again, please CC, I am not subscribed to debian-devel)

--
PREINING Norbert   http://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#944532: ITP: erlang-p1-acme -- ACME client library for Erlang

[Philipp Huebner]

Package: wnpp
Severity: wishlist
Owner: Philipp Huebner 

* Package name: erlang-p1-acme
  Version : 1.0.2
  Upstream Author : ProcessOne
* URL : https://github.com/processone/p1_acme
* License : Apache-2.0
  Programming Lang: Erlang
  Description : ACME client library for Erlang

 This Erlang library provides an ACME client implementing RFC 8555.
 It was written for ejabberd which still uses it. It was split off into its
 own project to follow Erlang/OTP guidelines.

Re: please avoid writing useless/annoying stuff in debian/gbp.conf (was: source only upload with git-buildpackage)

[Jeremy Bicha]

On Mon, Nov 11, 2019 at 2:59 AM Thomas Goirand  wrote:
> On 11/11/19 1:02 AM, Theodore Y. Ts'o wrote:
> > On Sun, Nov 10, 2019 at 11:20:45PM +0100, Thomas Goirand wrote:
> >>
> >> Please, *never* do that. It's generally a very bad idea to write
> >> anything to debian/gbp.conf. It's as if you were adding your text editor
> >> preferences in the package. Instead, please prefer writing in ~/.gbp.conf.
> >
> > I keep most of my git-buildpackage settings which are specific to my
> > developer environment in ~/.gbp.conf.  However, there are some gbp
> > settings which are specific to the repository set up, and those I
> > think, IMHO, *are* appropriate for debian/gbp.conf.  For example:
> >
> > [DEFAULT]
> > pristine-tar = True
> > upstream-tag='v%(version)s'
> > debian-branch=debian/master
>
> The first 2, yes. The last one, it's my opinion that it's useless, and
> that you only need it because "ignore-branch = True" isn't the default
> in git-buildpackage. It's ok as long as you always keep the same
> packagig branch, but if, like in my team, we need a new branch name
> every 6 months, and for 400+ repositories, then keeping the branch name
> declared in debian/gbp.conf becomes super annoying (as it forces one to
> change the "debian-branch" each time).

Could you please add debian/gbp.conf back to your packages? As I
understand it, I think your preferred settings would look something
like this:

[DEFAULT]
ignore-branch = True
pristine-tar = False

[buildpackage]
sign-tags = True

[dch]
multimaint-merge = True

[import-orig]
upstream-tag = %(version)s

[pq]
patch-numbers = False



It is absolutely not possible to set the correct
pristine-tar=True/False in ~/.gbp.conf to work with your packages
(which avoid pristine-tar) and the vast majority of gbp packages in
Debian which do use pristine-tar. Those settings are specific to the
workflow for that repo, and everyone using that repo needs to use
those same settings to avoid issues.

On the other hand, there are some developer-level preferences like
export-dir and "pbuilder = True". Those should not be in the repo's
debian/gbp.conf but they should be in ~/.gbp.conf .

Thanks,
Jeremy Bicha

Re: Python 2 removal in sid/bullseye: Progress and next steps

[Matthias Klose]

On 11.11.19 10:33, Ondřej Nový wrote:

Hi,

We are aiming to remove Python 2 for the bullseye release, or at least
remove as many Python 2 related packages as possible.  Python 2 is
discontinued upstream, but crucially, more and more providers of Python
modules don't support Python 2 in either the current or future upstream
version.

Some FAQs and guidelines can be found at
https://wiki.debian.org/Python/2Removal.

With about 3300 py2removal bugs filed and 1500 closed, we are now
almost done with half of the removals.


please find attach the dd-list of all open py2removal issues.


py2-dd-list.xz
Description: application/xz