Bug#894049: transition: ncurses
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
Bug#894049: transition: ncurses
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.
Bug#894049: transition: ncurses
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
Bug#894049: transition: ncurses
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
Bug#894049: transition: ncurses
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
Bug#894049: transition: ncurses
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@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
Bug#894049: transition: ncurses
On 2018-03-25 21:51 +0200, Sven Joachim wrote: > Package: release.debian.org > Severity: normal > User: release.debian@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
Bug#894049: transition: ncurses
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
--- a/fpcsrc/packages/ncurses/src/ncurses.pp 2015-06-18 10:59:10.0 +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
Bug#894049: transition: ncurses
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
Bug#894049: transition: ncurses
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?
Bug#894049: transition: ncurses
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@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
Bug#894049: transition: ncurses
On 25/03/18 21:51, Sven Joachim wrote: > Package: release.debian.org > Severity: normal > User: release.debian@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
Bug#894049: transition: ncurses
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@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
Bug#894049: transition: ncurses
Package: release.debian.org Severity: normal User: release.debian@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 Description: PGP signature
