2018-02-24 8:54 GMT+01:00 Sven Joachim <svenj...@gmx.de>: > 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?
Yes, with the following comments/caveats (mostly reminders for myself, or somebody else if ends up doing this): - the "v5" suffix was for the GCC5 transition (changes due to C++11 ABI), the name should be "libcwidget4" or something. I wanted to change a couple of minor things and bump the soversion anyway, just never find the time to sort out all of the details, so let's see :) - I am the maintainer of both aptitude and cwidget, so no need to sweat over problems, I can upload them in lockstep Thanks for the detailed follow-up and taking care of these details :) -- Manuel A. Fernandez Montecelo <manuel.montez...@gmail.com>
