Control: clone -1 -2
Control: reassign -2 libncurses-dev 6.2+20200912-1
Control: retitle -2 dpkg and zsh FTBFS: KEY_EVENT undeclared
Control: severity -1 normal
Control: tags -2 - ftbfs
On 2020-09-18 19:29 +0200, Guillem Jover wrote:
> On Fri, 2020-09-18 at 18:26:34 +0200, Sven Joachim wrote:
>> Am 18.09.2020 um 13:43 schrieb Helmut Grohne:
>> > Source: dpkg
>> > Version: 1.20.5
>> > Severity: serious
>> > Tags: ftbfs
>> >
>> > dpkg FTBFS as of today:
>> >
>> > | In file included from ../../dselect/curkeys.cc:30:
>> > | ./curkeys.h:168:5: error: ‘KEY_EVENT’ was not declared in this scope;
>> > did you mean ‘KEY_OPEN’?
>> > | 168 | { KEY_EVENT, "Event" },
>> > | | ^~~~~~~~~
>> > | | KEY_OPEN
>
>> > I suppose this is connected to a ncurses upload.
>
>> Quoting the ncurses NEWS file:
>>
>> ,----
>> | 20200817
>> | + prevent KEY_EVENT from appearing in curses.h unless the configure
>> | option --enable-wgetch-events is used (report by Werner Fink).
>> `----
>
> Right, thanks for the confirmation, that's along the lines of what I
> had gathered from checking the header. Even though the problem here
> is that the macro is there, but just behind a conditional, I suppose
> that's still expected?
No, that was not expected and an oversight which has been corrected in
the 20200918 ncurses patchlevel. At least one other package (zsh) is
affected.
>> See the thread at
>> https://lists.gnu.org/archive/html/bug-ncurses/2020-08/threads.html#00017
>> for a discussion that motivated this change.
>
> I'll check this later, but no matter what, I think it is still worth
> fixing the dpkg build system to handle this kind of case more robustly.
> I've prepared the attached patch which seems to work with gcc and clang,
> and I'll try to upload either later today or tomorrow.
I agree that dpkg's parsing of curses.h needs improvement, but no need
to hurry with an upload, I will upgrade ncurses to the 20200918
patchlevel this weekend.
Cheers,
Sven
