On 2017-01-23 17:30, Wookey wrote: > On 2017-01-19 11:04 +0100, Cyril Brulebois wrote: > > Steve McIntyre <st...@einval.com> (2017-01-19): > > > On Thu, Jan 19, 2017 at 08:57:54AM +0100, Aurelien Jarno wrote: > > > > > > > >The workaround are to make sure the chroots are up-to-date (which should > > > >be the case now on the build daemons). An other alternative would be to > > > >avoid copying a library in mklibs if it is already present in the image. > > > >That might break if some very strict dependencies are used, though > > > >I guess the way the udebs are downloaded, they should always have the > > > >same or a newer version than in the chroot. > > > > > > Thanks for the explanation - it's appreciated! > > > > Yeah, thanks for the confirmation. > > OK. I tested today's image (2017-01-23 04:56) and the install went > through OK, so we are back in sync and this issue is gone for now. It should > probably be retitled to something about library sync/using host libs > and left open until it's fixed propoerly.
I have pushed a patch a few days ago that should fix the issue. Well I don't know if it should be considered as a fix or a hack, but at least it looks less a hack than the existing code... The longterm solution is clearly to fully get rid of mklibs. That should wait for after stretch though, as it requires new udebs from some packages and thus some coordination. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
signature.asc
Description: PGP signature
