On Thu, Sep 06, 2018 at 03:55:04PM +0200, Aurelien Jarno wrote: > On 2018-09-06 12:13, Paul Gevers wrote: > > Hi > > > > On 06-09-18 11:53, Samuel Thibault wrote: > > > Samuel Thibault, le jeu. 06 sept. 2018 11:44:45 +0200, a ecrit: > > >> Paul Gevers, le jeu. 06 sept. 2018 11:22:46 +0200, a ecrit: > > >>> On 06-09-18 11:19, Samuel Thibault wrote: > > >>>> It'd be useful for the abi-compliance-checker test to actually output > > >>>> error messages, > > >>>> > > >>>> https://ci.debian.net/data/autopkgtest/testing/amd64/k/kf5-kdepim-apps-libs/944759/log.gz > > >>>> > > >>>> it not very talkative :) > > >>> > > >>> I agree, but I found that there are more logs in the artifacts. > > >> > > >> Ah, right. They seem to only point at c++ headers, so it'd rather be a > > >> g++ issue? > > > > > > All the passed artifacts I can find have libc++-dev 6.0.1-1, not > > > libc++-8-dev 1:8~svn340819-1. > > > > Does this mean that libc++-8-dev is breaking the ABI of the Qt/KDE > > packages? Luckily libc++-8-dev will not migrate to testing due to > > https://bugs.debian.org/714686 Does it need a "Breaks" then? > > Actually due to a bug in the migration process this package migrated to > testing on 2018-08-26 despite the RC bug. It has been removed from > testing during last night. > > > Does anybody know why libc++-8-dev is installed when glibc or > > abi-compliance-checker come from unstable? It seems that package is > > providing something that in testing is provided by libc++-dev (Or > > somewhere else in the dependency chain this goes "wrong" and leads to > > this outcome). > > I have been able to install libc++-dev along glibc 2.27-6, so I wonder > if it is not just a matter of regenerating the testing chroot following > the libc++-8-dev removal from testing. the containers on ci.debian.net are recreated from scratch once a day, so this should solve itsef, I guess?
Attachment:
signature.asc
Description: PGP signature