On 2018-02-23 22:12 +0100, Sven Joachim wrote:
> So I have good and bad news. The good one is that this error was easy
> to fix by casting the 0 to size_t, so that both parameters passed to
> std::max have the same type. See the attached patch.
>
> The bad news is that after rebuilding libcwidget3v5 against libncursesw6
> aptitude no longer starts:
>
> ,----
> | $ aptitude
> | aptitude: symbol lookup error: aptitude: undefined symbol:
> _ZN7cwidget7widgets6widget14dispatch_mouseEsiiim
> | $ objdump -T /usr/lib/i386-linux-gnu/libcwidget.so.3.0.0 | grep
> widget14dispatch_mouse
> | 000dde10 g DF .text 00000002 Base
> _ZN7cwidget7widgets6widget14dispatch_mouseEsiiij
> `----
>
> This is because mmask_t is of a different type in libncursesw6. Looks
> like I may have to go back to the drawing board in ncurses and re-enable
> the "--with-mmask-t='long'" configure option there. Oh well. :-(
Grepping for mmask_t on codesearch.debian.net revealed 48 packages which
might be using this datatype. I will examine them more closely next
week, but from a first look it seems that cwidget might very well be the
only affected library. If this turns out to be true, I would prefer to
deal with the incompatibility in cwidget/aptitude rather than deviate
from upstream's default in ncurses.
So here is a possible plan:
- Do *not* fix this bug in unstable now, to exclude the possibility of
the above symbol lookup error after a cwidget rebuild when the ncurses
transition starts.
- After ncurses has been accepted in experimental, upload cwidget there
too. Rename the library package again, say to libcwidget3v6, and
build-depend on libncurses-dev (>= 6.0+20180210) to ensure that it gets
linked against libncursesw6 rather than libncursesw5.
- When the ncurses transition starts in unstable, both aptitude and
cwidget still FTBFS. Upload the new cwidget package to unstable, get
aptitude binNMU'ed, and everyone is happy.
Does this sound reasonable?
Cheers,
Sven
