Hi, On 2014-04-05 18:02, Paulo César Pereira de Andrade wrote:
I cannot work on cooker for 24 hours now, I pinged in irc when detected the problem but nobody commented :-(
That can happen at times -- for example, I was out in nowhere with Chwido for the day (seems he likes the same remote places I do).
The issue is that ncurses was updated, and it changed major of libncursesw. It did properly follow Mandriva libname specs changing the major of the package, e.g. changed libncursesw5 to libncursesw6, *but* when publishing, "abf" just removed all packages generated by the previous ncurses, that included libncursesw5.
That's the right thing to do, it's just wrong to have a binary package that doesn't have a corresponding source package in the tree. It does mean, however, that we have to be extra careful -- build the compat package providing the old soname BEFORE building the new package with the updated soname.
Maybe abf's publishing tests should be extended to catch this? Right now it warns if a package can't be installed because it conflicts with itself or the likes. A check for removing a .so.X that is still needed by something else would be great (and an urpmq --whatrequires call shouldn't be too expensive).
Anyway, to fix the cooker issue, I hereby request some kind of abf access, maybe a way to upload files, e.g. rebuild bash locally with the newer libncursesw (but I would do it only for i586 and x86_64) and upload it, at least this way I would not be blocked from working for at least 24 hours.
Certainly not opposed to giving you more access (but I don't have the privileges to do so myself) -- but you could have fixed this even without more access, simply locate an older ncurses and re-publish it. That would have killed libncursesw6, but nothing uses that yet. Would have been good enough to get things running again so a compat package could be built (and then ncurses 6 could be published again).
ttyl bero
