Debian Bug report logs - #894049
transition: ncurses

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Sven Joachim <svenjoac@gmx.de>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: transition: ncurses

Date: Sun, 25 Mar 2018 21:51:37 +0200

[Message part 1 (text/plain, inline)]

Package: release.debian.org
Severity: normal
User: release.debian.org@packages.debian.org
Usertags: transition

I would like to start a transition for ncurses, changing the soname of
the libraries from 5 to 6.  This affects a large number of packages
(about 600 of them), but should be doable almost exclusively via
binNMUs, with two exceptions:

- libcdk5 needs a sourceful upload and a rename of the library package,
  neither this package nor its three reverse dependencies should be
  rebuilt before that.  Please see https://bugs.debian.org/892280 and
  https://release.debian.org/transitions/html/auto-libcdk5.html.

- cwidget also needs a sourceful upload and either a package rename or a
  shlibs bump + versioned Breaks against aptitude, please see
  https://bugs.debian.org/891161 for details.  Fortunately both cwidget
  and aptitude currently FTBFS with libncursesw6, so there is no danger
  of incompatible combinations after binNMUs.

The packages libtinfo5, libncurses5 and libncursesw5 are still built, so
only packages depending on the multilib packages and the udeb become
uninstallable and need to be rebuilt right away: grub, readline and
screen.

Apart from cwidget/aptitude, I have not noticed any ncurses related
FTBFS bugs, and the API is unchanged.  However, there will certainly be
quite a few unrelated FTBFS problems, such as the recent switch to
openjdk-9 and the python3.6/python3-distutils breakage.

Suggested ben file (please check if it is correct):

title = "ncurses";
is_affected = .depends ~ /\b(lib32ncurses6|lib32ncursesw6|lib32tinfo6|lib64ncurses6|lib64ncursesw6|lib64tinfo6|libncurses6|libncursesw6|libtinfo6|libtinfo6\-udeb|lib32ncurses5|lib32ncursesw5|lib32tinfo5|lib64ncurses5|lib64tinfo5|libncurses5|libncursesw5|libtinfo5|libtinfo5\-udeb)\b/;
is_good = .depends ~ /\b(lib32ncurses6|lib32ncursesw6|lib32tinfo6|lib64ncurses6|lib64ncursesw6|lib64tinfo6|libncurses6|libncursesw6|libtinfo6|libtinfo6\-udeb)\b/;
is_bad = .depends ~ /\b(lib32ncurses5|lib32ncursesw5|lib32tinfo5|lib64ncurses5|lib64tinfo5|libncurses5|libncursesw5|libtinfo5|libtinfo5\-udeb)\b/ & ! .package ~ /\b(libncursesw5|libncurses5)\b/; 

Thanks for your consideration,
Sven

[signature.asc (application/pgp-signature, inline)]

Message #10 received at 894049@bugs.debian.org (full text, mbox, reply):

From: Emilio Pozuelo Monfort <pochu@debian.org>

To: Sven Joachim <svenjoac@gmx.de>, 894049@bugs.debian.org

Subject: Re: Bug#894049: transition: ncurses

Date: Wed, 25 Apr 2018 15:51:05 +0200

Control: tags -1 confirmed
Control: forwarded -1 https://release.debian.org/transitions/html/libncurses6.html

On 25/03/18 21:51, Sven Joachim wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian.org@packages.debian.org
> Usertags: transition
> 
> I would like to start a transition for ncurses, changing the soname of
> the libraries from 5 to 6.  This affects a large number of packages
> (about 600 of them), but should be doable almost exclusively via
> binNMUs, with two exceptions:
> 
> - libcdk5 needs a sourceful upload and a rename of the library package,
>   neither this package nor its three reverse dependencies should be
>   rebuilt before that.  Please see https://bugs.debian.org/892280 and
>   https://release.debian.org/transitions/html/auto-libcdk5.html.
> 
> - cwidget also needs a sourceful upload and either a package rename or a
>   shlibs bump + versioned Breaks against aptitude, please see
>   https://bugs.debian.org/891161 for details.  Fortunately both cwidget
>   and aptitude currently FTBFS with libncursesw6, so there is no danger
>   of incompatible combinations after binNMUs.
> 
> The packages libtinfo5, libncurses5 and libncursesw5 are still built, so
> only packages depending on the multilib packages and the udeb become
> uninstallable and need to be rebuilt right away: grub, readline and
> screen.
> 
> Apart from cwidget/aptitude, I have not noticed any ncurses related
> FTBFS bugs, and the API is unchanged.  However, there will certainly be
> quite a few unrelated FTBFS problems, such as the recent switch to
> openjdk-9 and the python3.6/python3-distutils breakage.

Please go ahead.

Thanks,
Emilio

Message #19 received at 894049@bugs.debian.org (full text, mbox, reply):

From: Emilio Pozuelo Monfort <pochu@debian.org>

To: Sven Joachim <svenjoac@gmx.de>, 894049@bugs.debian.org

Subject: Re: Bug#894049: transition: ncurses

Date: Mon, 30 Apr 2018 19:00:39 +0200

On 25/03/18 21:51, Sven Joachim wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian.org@packages.debian.org
> Usertags: transition
> 
> I would like to start a transition for ncurses, changing the soname of
> the libraries from 5 to 6.

You dropped lib32tinfo-dev but lib32readline-dev depends on it. Can you advise
on what to do there?

Cheers,
Emilio

Message #24 received at 894049@bugs.debian.org (full text, mbox, reply):

From: Sven Joachim <svenjoac@gmx.de>

To: Emilio Pozuelo Monfort <pochu@debian.org>

Cc: 894049@bugs.debian.org

Subject: Re: Bug#894049: transition: ncurses

Date: Mon, 30 Apr 2018 20:01:30 +0200

On 2018-04-30 19:00 +0200, Emilio Pozuelo Monfort wrote:

> On 25/03/18 21:51, Sven Joachim wrote:
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian.org@packages.debian.org
>> Usertags: transition
>> 
>> I would like to start a transition for ncurses, changing the soname of
>> the libraries from 5 to 6.
>
> You dropped lib32tinfo-dev but lib32readline-dev depends on it.

Yes, but lib32ncurses-dev Provides/Replaces/Conflicts lib32tinfo-dev.

> Can you advise on what to do there?

Decrufting the binary packages no longer built from src:ncurses should
help, I think.

Thanks for managing the ncurses transition!

Cheers,
       Sven

Message #29 received at 894049@bugs.debian.org (full text, mbox, reply):

From: peter green <plugwash@p10link.net>

To: 894049@bugs.debian.org

Subject: re: transition: ncurses

Date: Sun, 6 May 2018 01:05:31 +0100

I suspect fpc will also need a sourceful upload for the new ncurses. I would recommend not binnmuing it until the maintainers have had chance to take a look.

Is there a full list of differences between the version 5 and 6 ABIs anywhere? chtype has already been mentioned, are there any others?

Message #34 received at 894049@bugs.debian.org (full text, mbox, reply):

From: Emilio Pozuelo Monfort <pochu@debian.org>

To: peter green <plugwash@p10link.net>, 894049@bugs.debian.org, Sven Joachim <svenjoac@gmx.de>

Subject: Re: Bug#894049: transition: ncurses

Date: Sun, 6 May 2018 08:32:43 +0200

On 06/05/18 02:05, peter green wrote:
> I suspect fpc will also need a sourceful upload for the new ncurses. I would
> recommend not binnmuing it until the maintainers have had chance to take a look.

It's not on https://release.debian.org/transitions/html/libncurses6.html so I
wasn't planning on binNMUing it.

> Is there a full list of differences between the version 5 and 6 ABIs anywhere?
> chtype has already been mentioned, are there any others?

Cc'ing Sven for that.

Emilio

Message #39 received at 894049@bugs.debian.org (full text, mbox, reply):

From: Sven Joachim <svenjoac@gmx.de>

To: peter green <plugwash@p10link.net>

Cc: Emilio Pozuelo Monfort <pochu@debian.org>, 894049@bugs.debian.org

Subject: Re: Bug#894049: transition: ncurses

Date: Sun, 06 May 2018 09:11:48 +0200

[Message part 1 (text/plain, inline)]

On 2018-05-06 08:32 +0200, Emilio Pozuelo Monfort wrote:

> On 06/05/18 02:05, peter green wrote:
>> I suspect fpc will also need a sourceful upload for the new ncurses. I would
>> recommend not binnmuing it until the maintainers have had chance to take a look.
>
> It's not on https://release.debian.org/transitions/html/libncurses6.html so I
> wasn't planning on binNMUing it.
>
>> Is there a full list of differences between the version 5 and 6 ABIs anywhere?
>> chtype has already been mentioned, are there any others?
>
> Cc'ing Sven for that.

The chtype and mmask_t types have both changed from unsigned long to
unsigned int in the new ncurses ABI, and NCURSES_MOUSE_VERSION has been
bumped from 1 to 2.  AFAIK these are the only incompatible changes.

The fpc package should probably apply the attached patch and
build-depend on libncurses-dev (>= 6.1+20180210) to ensure that it gets
built against the new ABI.

That being said, ncurses.pp is based on ncurses 5.6 which is over eleven
years old.  Somebody ought to update it upstream for ncurses 6.0 or
newer, I guess.

Cheers,
       Sven

[ncurses.pp.diff (text/x-diff, inline)]

--- a/fpcsrc/packages/ncurses/src/ncurses.pp	2015-06-18 10:59:10.000000000 +0200
+++ b/fpcsrc/packages/ncurses/src/ncurses.pp	2018-05-06 08:46:48.731837657 +0200
@@ -69,13 +69,13 @@ const
    NCURSES_VERSION_MINOR = 6;
    NCURSES_VERSION_PATCH = 20061217;
    NCURSES_VERSION = '5.6';
-   NCURSES_MOUSE_VERSION = 1;
+   NCURSES_MOUSE_VERSION = 2;
 
 type
    pchtype = ^chtype;
-   chtype  = culong;
+   chtype  = cuint;
    pmmask_t = ^mmask_t;
-   mmask_t  = culong;
+   mmask_t  = cuint;
 
 { colors  }
 var

Message #44 received at 894049@bugs.debian.org (full text, mbox, reply):

From: Sven Joachim <svenjoac@gmx.de>

To: 894049@bugs.debian.org

Subject: Re: Bug#894049: transition: ncurses

Date: Thu, 10 May 2018 15:56:07 +0200

On 2018-03-25 21:51 +0200, Sven Joachim wrote:

> Package: release.debian.org
> Severity: normal
> User: release.debian.org@packages.debian.org
> Usertags: transition
>
> I would like to start a transition for ncurses, changing the soname of
> the libraries from 5 to 6.

The results thus far look quite good, although a few bugs still need to
ironed out, e.g. #898131.

> Suggested ben file (please check if it is correct):
>
> title = "ncurses";
> is_affected = .depends ~
> /\b(lib32ncurses6|lib32ncursesw6|lib32tinfo6|lib64ncurses6|lib64ncursesw6|lib64tinfo6|libncurses6|libncursesw6|libtinfo6|libtinfo6\-udeb|lib32ncurses5|lib32ncursesw5|lib32tinfo5|lib64ncurses5|lib64tinfo5|libncurses5|libncursesw5|libtinfo5|libtinfo5\-udeb)\b/;
> is_good = .depends ~
> /\b(lib32ncurses6|lib32ncursesw6|lib32tinfo6|lib64ncurses6|lib64ncursesw6|lib64tinfo6|libncurses6|libncursesw6|libtinfo6|libtinfo6\-udeb)\b/;
> is_bad = .depends ~
> /\b(lib32ncurses5|lib32ncursesw5|lib32tinfo5|lib64ncurses5|lib64tinfo5|libncurses5|libncursesw5|libtinfo5|libtinfo5\-udeb)\b/
> & ! .package ~ /\b(libncursesw5|libncurses5)\b/;

This has turned out to be rather suboptimal, because the regexes match
on libncurses5-dev etc, and so some packages are listed as partial or
bad in the tracker[1] which should be good or unaffected.  The ones
below seem to be better, filtering out the -dev packages while still
catching hardcoded dependencies such as #804579.

title = "libncurses6";
is_affected = .depends ~ /\b(lib32ncurses6|lib32ncursesw6|lib32tinfo6|lib64ncurses6|lib64ncursesw6|lib64tinfo6|libncurses6|libncursesw6|libtinfo6|libtinfo6\-udeb|lib32ncurses5|lib32ncursesw5|lib32tinfo5|lib64ncurses5|lib64tinfo5|libncurses5|libncursesw5|libtinfo5|libtinfo5\-udeb)([^-]|$)/;
is_good = .depends ~ /\b(lib32ncurses6|lib32ncursesw6|lib32tinfo6|lib64ncurses6|lib64ncursesw6|lib64tinfo6|libncurses6|libncursesw6|libtinfo6|libtinfo6\-udeb)\b/;
is_bad = .depends ~ /\b(lib32ncurses5|lib32ncursesw5|lib32tinfo5|lib64ncurses5|lib64tinfo5|libncurses5|libncursesw5|libtinfo5|libtinfo5\-udeb)\b/ & ! .package ~ /\b(libncursesw5|libncurses5)([^-]|$)/; 

Another small problem is that bash is missing on the tracker since it
uses Pre-Depends rather than Depends.  Should I try to fiddle more with
the ben syntax, or file a separate binNMU request for bash?  The latter
would definitely be easier for me.

Cheers,
       Sven


1. https://release.debian.org/transitions/html/libncurses6.html

Message #49 received at 894049@bugs.debian.org (full text, mbox, reply):

From: Emilio Pozuelo Monfort <pochu@debian.org>

To: Sven Joachim <svenjoac@gmx.de>, 894049@bugs.debian.org

Subject: Re: Bug#894049: transition: ncurses

Date: Sat, 12 May 2018 09:46:44 +0200

On 10/05/18 15:56, Sven Joachim wrote:
> On 2018-03-25 21:51 +0200, Sven Joachim wrote:
> 
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian.org@packages.debian.org
>> Usertags: transition
>>
>> I would like to start a transition for ncurses, changing the soname of
>> the libraries from 5 to 6.
> 
> The results thus far look quite good, although a few bugs still need to
> ironed out, e.g. #898131.
> 
>> Suggested ben file (please check if it is correct):
>>
>> title = "ncurses";
>> is_affected = .depends ~
>> /\b(lib32ncurses6|lib32ncursesw6|lib32tinfo6|lib64ncurses6|lib64ncursesw6|lib64tinfo6|libncurses6|libncursesw6|libtinfo6|libtinfo6\-udeb|lib32ncurses5|lib32ncursesw5|lib32tinfo5|lib64ncurses5|lib64tinfo5|libncurses5|libncursesw5|libtinfo5|libtinfo5\-udeb)\b/;
>> is_good = .depends ~
>> /\b(lib32ncurses6|lib32ncursesw6|lib32tinfo6|lib64ncurses6|lib64ncursesw6|lib64tinfo6|libncurses6|libncursesw6|libtinfo6|libtinfo6\-udeb)\b/;
>> is_bad = .depends ~
>> /\b(lib32ncurses5|lib32ncursesw5|lib32tinfo5|lib64ncurses5|lib64tinfo5|libncurses5|libncursesw5|libtinfo5|libtinfo5\-udeb)\b/
>> & ! .package ~ /\b(libncursesw5|libncurses5)\b/;
> 
> This has turned out to be rather suboptimal, because the regexes match
> on libncurses5-dev etc, and so some packages are listed as partial or
> bad in the tracker[1] which should be good or unaffected.  The ones
> below seem to be better, filtering out the -dev packages while still
> catching hardcoded dependencies such as #804579.
> 
> title = "libncurses6";
> is_affected = .depends ~ /\b(lib32ncurses6|lib32ncursesw6|lib32tinfo6|lib64ncurses6|lib64ncursesw6|lib64tinfo6|libncurses6|libncursesw6|libtinfo6|libtinfo6\-udeb|lib32ncurses5|lib32ncursesw5|lib32tinfo5|lib64ncurses5|lib64tinfo5|libncurses5|libncursesw5|libtinfo5|libtinfo5\-udeb)([^-]|$)/;
> is_good = .depends ~ /\b(lib32ncurses6|lib32ncursesw6|lib32tinfo6|lib64ncurses6|lib64ncursesw6|lib64tinfo6|libncurses6|libncursesw6|libtinfo6|libtinfo6\-udeb)\b/;
> is_bad = .depends ~ /\b(lib32ncurses5|lib32ncursesw5|lib32tinfo5|lib64ncurses5|lib64tinfo5|libncurses5|libncursesw5|libtinfo5|libtinfo5\-udeb)\b/ & ! .package ~ /\b(libncursesw5|libncurses5)([^-]|$)/; 

What do you want to achieve with this?

  & ! .package ~ /\b(libncursesw5|libncurses5)([^-]|$)/; 

I don't think that's doing what you want.

Cheers,
Emilio

Message #54 received at 894049@bugs.debian.org (full text, mbox, reply):

From: Sven Joachim <svenjoac@gmx.de>

To: Emilio Pozuelo Monfort <pochu@debian.org>

Cc: 894049@bugs.debian.org

Subject: Re: Bug#894049: transition: ncurses

Date: Sat, 12 May 2018 10:59:36 +0200

On 2018-05-12 09:46 +0200, Emilio Pozuelo Monfort wrote:

> On 10/05/18 15:56, Sven Joachim wrote:
>> On 2018-03-25 21:51 +0200, Sven Joachim wrote:
>> 
>> This has turned out to be rather suboptimal, because the regexes match
>> on libncurses5-dev etc, and so some packages are listed as partial or
>> bad in the tracker[1] which should be good or unaffected.  The ones
>> below seem to be better, filtering out the -dev packages while still
>> catching hardcoded dependencies such as #804579.
>> 
>> title = "libncurses6";
>> is_affected = .depends ~
>> /\b(lib32ncurses6|lib32ncursesw6|lib32tinfo6|lib64ncurses6|lib64ncursesw6|lib64tinfo6|libncurses6|libncursesw6|libtinfo6|libtinfo6\-udeb|lib32ncurses5|lib32ncursesw5|lib32tinfo5|lib64ncurses5|lib64tinfo5|libncurses5|libncursesw5|libtinfo5|libtinfo5\-udeb)([^-]|$)/;
>> is_good = .depends ~
>> /\b(lib32ncurses6|lib32ncursesw6|lib32tinfo6|lib64ncurses6|lib64ncursesw6|lib64tinfo6|libncurses6|libncursesw6|libtinfo6|libtinfo6\-udeb)\b/;
>> is_bad = .depends ~
>> /\b(lib32ncurses5|lib32ncursesw5|lib32tinfo5|lib64ncurses5|lib64tinfo5|libncurses5|libncursesw5|libtinfo5|libtinfo5\-udeb)\b/
>> & ! .package ~ /\b(libncursesw5|libncurses5)([^-]|$)/;
>
> What do you want to achieve with this?

Filter out packages which depend on libncurses5-dev or
libncursesw5-dev, since changing their dependencies is out of the scope
for this transition.  For instance, cwidget is listed as "partial" in
the tracker, and I think this is because libcwidget-dev depends on
libncursesw5-dev.

The trailing '$' is there to match cases like logol where there is a
hardcoded dependency on libncursesw5.

>   & ! .package ~ /\b(libncursesw5|libncurses5)([^-]|$)/; 
>
> I don't think that's doing what you want.

Indeed not, thanks for checking.  The line below is what I meant.

is_bad = .depends ~ /\b(lib32ncurses5|lib32ncursesw5|lib32tinfo5|lib64ncurses5|lib64tinfo5|libncurses5|libncursesw5|libtinfo5|libtinfo5\-udeb)([^-]|$)/ & ! .package ~ /\b(libncursesw5|libncurses5)\b/;

Pardon my ignorance, but this is only the second time in my life where I
worked^Wstruggled with ben files.  And "ben monitor" only gives a list
of affected packages, I can't really check what is "good" or "bad" wrt
the state of the archive. :-(

Cheers,
       Sven

Message #59 received at 894049@bugs.debian.org (full text, mbox, reply):

From: Emilio Pozuelo Monfort <pochu@debian.org>

To: Sven Joachim <svenjoac@gmx.de>, 894049@bugs.debian.org

Subject: Re: Bug#894049: transition: ncurses

Date: Sat, 12 May 2018 20:29:40 +0200

On 12/05/18 10:59, Sven Joachim wrote:
> On 2018-05-12 09:46 +0200, Emilio Pozuelo Monfort wrote:
> 
>> On 10/05/18 15:56, Sven Joachim wrote:
>>> On 2018-03-25 21:51 +0200, Sven Joachim wrote:
>>>
>>> This has turned out to be rather suboptimal, because the regexes match
>>> on libncurses5-dev etc, and so some packages are listed as partial or
>>> bad in the tracker[1] which should be good or unaffected.  The ones
>>> below seem to be better, filtering out the -dev packages while still
>>> catching hardcoded dependencies such as #804579.
>>>
>>> title = "libncurses6";
>>> is_affected = .depends ~
>>> /\b(lib32ncurses6|lib32ncursesw6|lib32tinfo6|lib64ncurses6|lib64ncursesw6|lib64tinfo6|libncurses6|libncursesw6|libtinfo6|libtinfo6\-udeb|lib32ncurses5|lib32ncursesw5|lib32tinfo5|lib64ncurses5|lib64tinfo5|libncurses5|libncursesw5|libtinfo5|libtinfo5\-udeb)([^-]|$)/;
>>> is_good = .depends ~
>>> /\b(lib32ncurses6|lib32ncursesw6|lib32tinfo6|lib64ncurses6|lib64ncursesw6|lib64tinfo6|libncurses6|libncursesw6|libtinfo6|libtinfo6\-udeb)\b/;
>>> is_bad = .depends ~
>>> /\b(lib32ncurses5|lib32ncursesw5|lib32tinfo5|lib64ncurses5|lib64tinfo5|libncurses5|libncursesw5|libtinfo5|libtinfo5\-udeb)\b/
>>> & ! .package ~ /\b(libncursesw5|libncurses5)([^-]|$)/;
>>
>> What do you want to achieve with this?
>
> Filter out packages which depend on libncurses5-dev or
> libncursesw5-dev, since changing their dependencies is out of the scope
> for this transition.  For instance, cwidget is listed as "partial" in
> the tracker, and I think this is because libcwidget-dev depends on
> libncursesw5-dev.
> 
> The trailing '$' is there to match cases like logol where there is a
> hardcoded dependency on libncursesw5.

Sorry, I meant with the .package line that I quoted after the question. I should
have made it clearer. The above change makes sense and I committed it to the
transition tracker.

>>   & ! .package ~ /\b(libncursesw5|libncurses5)([^-]|$)/; 
>>
>> I don't think that's doing what you want.
> 
> Indeed not, thanks for checking.  The line below is what I meant.
> 
> is_bad = .depends ~ /\b(lib32ncurses5|lib32ncursesw5|lib32tinfo5|lib64ncurses5|lib64tinfo5|libncurses5|libncursesw5|libtinfo5|libtinfo5\-udeb)([^-]|$)/ & ! .package ~ /\b(libncursesw5|libncurses5)\b/;
> 
> Pardon my ignorance, but this is only the second time in my life where I
> worked^Wstruggled with ben files.  And "ben monitor" only gives a list
> of affected packages, I can't really check what is "good" or "bad" wrt
> the state of the archive. :-(

Maybe my question wasn't clear. Your " ! .package" part of the match is
basically a no-op (unless I'm misremembering the ben syntax). Basically that
full is_bad is doing something like "give me all packages that depend on one of
these, but exclude src:libncursesw5 and src:libncurses5 from the is_bad set.
Since there are no such source packages, that part is basically doing nothing.

Since I don't know what you want to achieve with that, I can't suggest something
that may work. :-)

BTW it's alright, one doesn't have to get a perfect regex on the first attempt,
we all make mistakes.

Cheers,
Emilio

Message #64 received at 894049@bugs.debian.org (full text, mbox, reply):

From: Sven Joachim <svenjoac@gmx.de>

To: Emilio Pozuelo Monfort <pochu@debian.org>

Cc: 894049@bugs.debian.org

Subject: Re: Bug#894049: transition: ncurses

Date: Sat, 12 May 2018 21:07:50 +0200

On 2018-05-12 20:29 +0200, Emilio Pozuelo Monfort wrote:

> On 12/05/18 10:59, Sven Joachim wrote:
>> On 2018-05-12 09:46 +0200, Emilio Pozuelo Monfort wrote:
>> 
>>> On 10/05/18 15:56, Sven Joachim wrote:
>>>> On 2018-03-25 21:51 +0200, Sven Joachim wrote:
>>>>
>>>> This has turned out to be rather suboptimal, because the regexes match
>>>> on libncurses5-dev etc, and so some packages are listed as partial or
>>>> bad in the tracker[1] which should be good or unaffected.  The ones
>>>> below seem to be better, filtering out the -dev packages while still
>>>> catching hardcoded dependencies such as #804579.
>>>>
>>>> title = "libncurses6";
>>>> is_affected = .depends ~
>>>> /\b(lib32ncurses6|lib32ncursesw6|lib32tinfo6|lib64ncurses6|lib64ncursesw6|lib64tinfo6|libncurses6|libncursesw6|libtinfo6|libtinfo6\-udeb|lib32ncurses5|lib32ncursesw5|lib32tinfo5|lib64ncurses5|lib64tinfo5|libncurses5|libncursesw5|libtinfo5|libtinfo5\-udeb)([^-]|$)/;
>>>> is_good = .depends ~
>>>> /\b(lib32ncurses6|lib32ncursesw6|lib32tinfo6|lib64ncurses6|lib64ncursesw6|lib64tinfo6|libncurses6|libncursesw6|libtinfo6|libtinfo6\-udeb)\b/;
>>>> is_bad = .depends ~
>>>> /\b(lib32ncurses5|lib32ncursesw5|lib32tinfo5|lib64ncurses5|lib64tinfo5|libncurses5|libncursesw5|libtinfo5|libtinfo5\-udeb)\b/
>>>> & ! .package ~ /\b(libncursesw5|libncurses5)([^-]|$)/;
>>>
>>> What do you want to achieve with this?
>>
>> Filter out packages which depend on libncurses5-dev or
>> libncursesw5-dev, since changing their dependencies is out of the scope
>> for this transition.  For instance, cwidget is listed as "partial" in
>> the tracker, and I think this is because libcwidget-dev depends on
>> libncursesw5-dev.
>> 
>> The trailing '$' is there to match cases like logol where there is a
>> hardcoded dependency on libncursesw5.
>
> Sorry, I meant with the .package line that I quoted after the question. I should
> have made it clearer. The above change makes sense and I committed it to the
> transition tracker.

I have seen that, but the is_bad regex is still very much suboptimal
because with it dependencies on libncursesw?5-dev are considered "bad".

>>>   & ! .package ~ /\b(libncursesw5|libncurses5)([^-]|$)/; 
>>>
>>> I don't think that's doing what you want.
>> 
>> Indeed not, thanks for checking.  The line below is what I meant.
>> 
>> is_bad = .depends ~
>> /\b(lib32ncurses5|lib32ncursesw5|lib32tinfo5|lib64ncurses5|lib64tinfo5|libncurses5|libncursesw5|libtinfo5|libtinfo5\-udeb)([^-]|$)/
>> & ! .package ~ /\b(libncursesw5|libncurses5)\b/;

That "is_bad" regex was better, I think.

>> Pardon my ignorance, but this is only the second time in my life where I
>> worked^Wstruggled with ben files.  And "ben monitor" only gives a list
>> of affected packages, I can't really check what is "good" or "bad" wrt
>> the state of the archive. :-(
>
> Maybe my question wasn't clear. Your " ! .package" part of the match is
> basically a no-op (unless I'm misremembering the ben syntax). Basically that
> full is_bad is doing something like "give me all packages that depend on one of
> these, but exclude src:libncursesw5 and src:libncurses5 from the is_bad set.
> Since there are no such source packages, that part is basically doing nothing.

According to the ben reference manual it matches _binary_ packages:

,----
| * `is_bad`: matches binary packages that are considered to be broken
|   (not fixed) for this transition.
`----

> Since I don't know what you want to achieve with that, I can't suggest something
> that may work. :-)

My goal with that "! .package" part was to prevent the ncurses source
package from being listed as "partial" which would have happened
otherwise, because the binary packages libncursesw5 and libncurses5
still depend on libtinfo5.  And this has apparently even worked.

Cheers,
       Sven

Message #69 received at 894049@bugs.debian.org (full text, mbox, reply):

From: Emilio Pozuelo Monfort <pochu@debian.org>

To: Sven Joachim <svenjoac@gmx.de>

Cc: 894049@bugs.debian.org

Subject: Re: Bug#894049: transition: ncurses

Date: Sat, 12 May 2018 21:15:29 +0200

On 12/05/18 21:07, Sven Joachim wrote:
> My goal with that "! .package" part was to prevent the ncurses source
> package from being listed as "partial" which would have happened
> otherwise, because the binary packages libncursesw5 and libncurses5
> still depend on libtinfo5.  And this has apparently even worked.

Ah, you are right. I was thinking of .source, which might have been easier here
with & ! .source ~ /^ncurses$/. I don't use .source or .package much as I don't
mind partial results (usually fixed by a decruft, though not in this case), so I
had forgotten that we had both .source and .package, and assumed that .package
matched sources (which obviously makes little sense). So thanks for instructing
me about that!

Cheers,
Emilio

PS: I will continue with the binNMUs soon, once the libicu ones are done.

Message #74 received at 894049@bugs.debian.org (full text, mbox, reply):

From: Sven Joachim <svenjoac@gmx.de>

To: Emilio Pozuelo Monfort <pochu@debian.org>

Cc: 894049@bugs.debian.org

Subject: Re: Bug#894049: transition: ncurses

Date: Sat, 12 May 2018 21:43:25 +0200

On 2018-05-12 21:15 +0200, Emilio Pozuelo Monfort wrote:

> On 12/05/18 21:07, Sven Joachim wrote:
>> My goal with that "! .package" part was to prevent the ncurses source
>> package from being listed as "partial" which would have happened
>> otherwise, because the binary packages libncursesw5 and libncurses5
>> still depend on libtinfo5.  And this has apparently even worked.
>
> Ah, you are right. I was thinking of .source, which might have been easier here
> with & ! .source ~ /^ncurses$/. I don't use .source or .package much as I don't
> mind partial results (usually fixed by a decruft, though not in this case), so I
> had forgotten that we had both .source and .package, and assumed that .package
> matched sources (which obviously makes little sense). So thanks for instructing
> me about that!

Can you please update the transition tracker, replacing the is_bad regex
with my last suggestion, i.e. the following?

is_bad = .depends ~ /\b(lib32ncurses5|lib32ncursesw5|lib32tinfo5|lib64ncurses5|lib64tinfo5|libncurses5|libncursesw5|libtinfo5|libtinfo5\-udeb)([^-]|$)/ & ! .package ~ /\b(libncursesw5|libncurses5)\b/; 

> PS: I will continue with the binNMUs soon, once the libicu ones are done.

Thanks!  In related news, I have requested a binNMU for bash (#898500),
since it was missing on the transition tracker.  I didn't want to fight
with ben to add pre-depends matches to the regexes.

Cheers,
       Sven

Message #79 received at 894049-quiet@bugs.debian.org (full text, mbox, reply):

From: Paul Gevers <elbrus@debian.org>

To: 894049-quiet@bugs.debian.org

Subject: Re: Bug#894049: transition: ncurses

Date: Thu, 12 Sep 2019 11:18:37 +0200

[Message part 1 (text/plain, inline)]

Control: block -1 by 898045
Control: tags -1 pending

Let's move this report a bit out of the way, but not close it as it
isn't really finished.

Paul

[signature.asc (application/pgp-signature, attachment)]

Message #88 received at 894049-done@bugs.debian.org (full text, mbox, reply):

From: Paul Gevers <elbrus@debian.org>

To: 894049-done@bugs.debian.org, Sven Joachim <svenjoac@gmx.de>

Subject: Re: Bug#894049: transition: ncurses

Date: Sun, 31 May 2020 20:29:18 +0200

[Message part 1 (text/plain, inline)]

Hi,

On 12-09-2019 11:18, Paul Gevers wrote:
> Let's move this report a bit out of the way, but not close it as it
> isn't really finished.

I think it's all done now. The last pieces of *this* transition are gone.

Paul

[signature.asc (application/pgp-signature, attachment)]

Message #93 received at 894049@bugs.debian.org (full text, mbox, reply):

From: R hertoric <rhetoricbomb@gmail.com>

To: 894049@bugs.debian.org

Cc: Paul Gevers <elbrus@debian.org>

Subject: Re: Bug#894049: marked as done (transition: ncurses)

Date: Tue, 2 Jun 2020 00:09:23 -0500

[Message part 1 (text/plain, inline)]

What stretch-pu ftp Masters to download the

On Sun, May 31, 2020, 1:45 PM Debian Bug Tracking System <
owner@bugs.debian.org> wrote:

> Your message dated Sun, 31 May 2020 20:29:18 +0200
> with message-id <7f60b78d-6907-a4f4-ce15-85a5ba234018@debian.org>
> and subject line Re: Bug#894049: transition: ncurses
> has caused the Debian Bug report #894049,
> regarding transition: ncurses
> to be marked as done.
>
> This means that you claim that the problem has been dealt with.
> If this is not the case it is now your responsibility to reopen the
> Bug report if necessary, and/or fix the problem forthwith.
>
> (NB: If you are a system administrator and have no idea what this
> message is talking about, this may indicate a serious mail system
> misconfiguration somewhere. Please contact owner@bugs.debian.org
> immediately.)
>
>
> --
> 894049: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=894049
> Debian Bug Tracking System
> Contact owner@bugs.debian.org with problems
>
>
>
> ---------- Forwarded message ----------
> From: Sven Joachim <svenjoac@gmx.de>
> To: Debian Bug Tracking System <submit@bugs.debian.org>
> Cc:
> Bcc:
> Date: Sun, 25 Mar 2018 21:51:37 +0200
> Subject: transition: ncurses
> Package: release.debian.org
> Severity: normal
> User: release.debian.org@packages.debian.org
> Usertags: transition
>
> I would like to start a transition for ncurses, changing the soname of
> the libraries from 5 to 6.  This affects a large number of packages
> (about 600 of them), but should be doable almost exclusively via
> binNMUs, with two exceptions:
>
> - libcdk5 needs a sourceful upload and a rename of the library package,
>   neither this package nor its three reverse dependencies should be
>   rebuilt before that.  Please see https://bugs.debian.org/892280 and
>   https://release.debian.org/transitions/html/auto-libcdk5.html.
>
> - cwidget also needs a sourceful upload and either a package rename or a
>   shlibs bump + versioned Breaks against aptitude, please see
>   https://bugs.debian.org/891161 for details.  Fortunately both cwidget
>   and aptitude currently FTBFS with libncursesw6, so there is no danger
>   of incompatible combinations after binNMUs.
>
> The packages libtinfo5, libncurses5 and libncursesw5 are still built, so
> only packages depending on the multilib packages and the udeb become
> uninstallable and need to be rebuilt right away: grub, readline and
> screen.
>
> Apart from cwidget/aptitude, I have not noticed any ncurses related
> FTBFS bugs, and the API is unchanged.  However, there will certainly be
> quite a few unrelated FTBFS problems, such as the recent switch to
> openjdk-9 and the python3.6/python3-distutils breakage.
>
> Suggested ben file (please check if it is correct):
>
> title = "ncurses";
> is_affected = .depends ~
> /\b(lib32ncurses6|lib32ncursesw6|lib32tinfo6|lib64ncurses6|lib64ncursesw6|lib64tinfo6|libncurses6|libncursesw6|libtinfo6|libtinfo6\-udeb|lib32ncurses5|lib32ncursesw5|lib32tinfo5|lib64ncurses5|lib64tinfo5|libncurses5|libncursesw5|libtinfo5|libtinfo5\-udeb)\b/;
> is_good = .depends ~
> /\b(lib32ncurses6|lib32ncursesw6|lib32tinfo6|lib64ncurses6|lib64ncursesw6|lib64tinfo6|libncurses6|libncursesw6|libtinfo6|libtinfo6\-udeb)\b/;
> is_bad = .depends ~
> /\b(lib32ncurses5|lib32ncursesw5|lib32tinfo5|lib64ncurses5|lib64tinfo5|libncurses5|libncursesw5|libtinfo5|libtinfo5\-udeb)\b/
> & ! .package ~ /\b(libncursesw5|libncurses5)\b/;
>
> Thanks for your consideration,
> Sven
>
>
>
> ---------- Forwarded message ----------
> From: Paul Gevers <elbrus@debian.org>
> To: 894049-done@bugs.debian.org, Sven Joachim <svenjoac@gmx.de>
> Cc:
> Bcc:
> Date: Sun, 31 May 2020 20:29:18 +0200
> Subject: Re: Bug#894049: transition: ncurses
> Hi,
>
> On 12-09-2019 11:18, Paul Gevers wrote:
> > Let's move this report a bit out of the way, but not close it as it
> > isn't really finished.
>
> I think it's all done now. The last pieces of *this* transition are gone.
>
> Paul
>
>

[Message part 2 (text/html, inline)]

Send a report that this bug log contains spam.