On Fri, 2019-06-28 at 17:57 +0100, [email protected] wrote: > On Fri, 2019-06-28 at 16:52 +0000, Luca Boccassi wrote: > > 2019-06-27T13:18:54.5592415Z [WARN] [15902] Reading package > > lists... > > 2019-06-27T13:18:54.5592628Z [WARN] [15903] Building dependency > > tree... > > 2019-06-27T13:18:54.5593124Z [WARN] [15904] Some packages could not > > be installed. This may mean that you have > > 2019-06-27T13:18:54.5593526Z [WARN] [15905] requested an impossible > > situation or if you are using the unstable > > 2019-06-27T13:18:54.5593893Z [WARN] [15906] distribution that some > > required packages have not yet been created > > 2019-06-27T13:18:54.5599962Z [WARN] [15907] or been moved out of > > Incoming. > > 2019-06-27T13:18:54.5600415Z [WARN] [15908] The following > > information may help to resolve the situation: > > 2019-06-27T13:18:54.5600834Z [WARN] [15909] The following packages > > have unmet dependencies: > > 2019-06-27T13:18:54.5601383Z [WARN] [15910] target-sdk-provides- > > dummy : Conflicts: bash > > 2019-06-27T13:18:54.5601724Z [WARN] > > [15911] Conflicts: coreutils > > 2019-06-27T13:18:54.5602246Z [WARN] > > [15912] Conflicts: coreutils-dev > > 2019-06-27T13:18:54.5602590Z [WARN] > > [15913] Conflicts: perl > > 2019-06-27T13:18:54.5603147Z [WARN] > > [15914] Conflicts: perl-module-strict > > 2019-06-27T13:18:54.5603989Z [WARN] > > [15915] Conflicts: perl-module-vars > > 2019-06-27T13:18:54.5605346Z [WARN] > > [15916] Conflicts: perl-module- > > warnings > > 2019-06-27T13:18:54.5606090Z [WARN] [15917] E: Unable to correct > > problems, you have held broken packages. > > > > Same config worked fine in sumo. > > > > Any suggestion on how to fix it? Is it possible to enter the > > working > > directory to run apt manually, so that I can dig further into the > > dependency issue? > > Sadly such "enter a shell" functionality has never been implemented > so > that isn't possible. > > The message is basically saying that there are conflicted providers > of > some things the SDK is trying to remove (like bash, perl). Its likely > the dummy recipe isn't providing something which it needs to which > would then stop the other provider being pulled in. > > How to isolate what that is, I'm less sure about, there isn't an easy > way. I've just done it from package inspection in the past. > > Cheers, > > Richard
Thanks - I'll try to get the packages out of the build directory and recreate the apt state in a chroot. Is there a test build of the SDK with a packages_deb configuration? The distro conf we use that triggers this failure is not that esoteric - pretty much standard stuff. -- Kind regards, Luca Boccassi -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
