Plz fix ncurses for ARM64 and ARM.
2014-04-05 23:35 GMT+04:00 Alexey Vokhmin <[email protected]>: > > Apparently another abf issue, > as it is not the first time it says "metadata already queued for > regeneration" > but looks like only regenerates it after someone from abf interfering, i.e. > after like 8+ hours. > > See: https://abf.io/platforms/cooker/repositories/main/edit > > Current status | Last status of regeneration metadata | Last log of > regeneration metadata | Last regeneration of metadata > No actions| Completed succesfully | > regeneration.log<http://file-store.rosalinux.ru/api/v1/file_stores/841163649795853f2f5e0b7ae2524d2ba78b8815.log?show=true> > | 2014-04-05 > 19:23:37 UTC > > Logs: > http://file-store.rosalinux.ru/api/v1/file_stores/841163649795853f2f5e0b7ae2524d2ba78b8815.log?show=true > > Regeneration works. Please, be patient. > > > Let's go discuss "Do not remove packages required by others in publish and > implement garbage-collector for orphan rpms" in > https://abf.io/abf/abf-ideas/issues/128 > > > Thanks, > Alexey > > > > On Sat, Apr 5, 2014 at 10:38 PM, Александр Бурмашев < > [email protected]> wrote: > >> The problem will never happen anymore if libs + all packages, requiring >> them, are built before publishing the updated library into the repository. >> >> >> >> >> 2014-04-05 22:23 GMT+04:00 Paulo César Pereira de Andrade < >> [email protected]>: >> >> 2014-04-05 15:15 GMT-03:00 Bernhard Rosenkränzer <[email protected]>: >>> > 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. >>> >>> Anything that can fail will fail, so this problem will repeat again >>> and again >>> if nothing is changed, but most times it does not break the chroot... >>> >>> > 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). >>> >>> I believe my suggestion idea is better described at >>> https://abf.io/abf/abf-ideas/issues/128#comment4931 >>> and the garbage collector (continuing 4931) at >>> https://abf.io/abf/abf-ideas/issues/128#comment4932 >>> >>> >> 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). >>> >>> Well, mdawkins did copy rpms from openmandriva2014.0 to cooker, but >>> now metadata regeneration does not happen. Apparently another abf issue, >>> as it is not the first time it says "metadata already queued for >>> regeneration" >>> but looks like only regenerates it after someone from abf interfering, >>> i.e. >>> after like 8+ hours. >>> >>> > ttyl >>> > bero >>> >>> Thanks, >>> Paulo >>> >>> >> > > > -- > _________________________________ > Best wishes, > Your Vokhmin Alexey. > e-mail: [email protected] > skype: avokhmin > > > >
