On Tue, 2016-07-26 at 20:43 -0700, Stephano Cetola wrote: > On 07/20, Richard Purdie wrote: > > On Thu, 2016-07-14 at 14:20 -0700, Stephano Cetola wrote: > > > Give each rootfs its own RPM channel to use. This puts the RPM > > > metadata > > > in a private subdirectory of $WORKDIR, rather than living in > > > DEPLOY_DIR > > > where other tasks may race with it. > > > > > > This allows us to reduce the time that the rpm.lock is held to > > > only > > > the > > > time needed to hardlink the RPMs, allowing the majority of the > > > rootfs > > > operation to run in parallel. > > > > > > [ YOCTO #9255 ] > > > > > > Signed-Off-By: Steven Walter <stevenrwal...@gmail.com> > > > Signed-off-by: Stephano Cetola <stephano.cet...@linux.intel.com> > > > --- > > > meta/classes/rootfs_rpm.bbclass | 5 ----- > > > meta/lib/oe/package_manager.py | 17 ++++++++++++++--- > > > 2 files changed, 14 insertions(+), 8 deletions(-) > > > > Sadly, much as I'd love to merge this, testing shows we have some > > issues. > > > > Firstly, it means we no longer generate indexes in tmp/deploy/rpm > > and > > this breaks -c testimage since some of the tests connect and look > > for > > packages there, e.g. > > https://autobuilder.yoctoproject.org/main/builders > > /nightly-qa-logrotate/builds/851 but many others would have also > > failed. > > > > After digging into this I think that I can change the tests so that > they > point at the correct location: > > e.g. > tmp/work/qemux86-oe-linux/core-image-sato/1.0 > -r0/rpms/qemux86/repodata > > based on the target triplet, image, PV (I'm guessing here), and arch > variables. I realized when digging into this that using "rpms" in the > path (which was a result of this patch) is wrong. It should be "rpm". > > Let me know if this sounds right or if I'm dreaming.
Its not the right fix. The tests can be run against a pre-existing image which wasn't "built" by the same build directory. tmp/deploy/xxx is therefore the correct location for the packages/index, we just need to ensure something has built the indexes there. Cheers, Richard -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core