On Fri, 2023-10-27 at 12:30 -0400, Tom Rini wrote: > On Thu, Oct 26, 2023 at 03:22:26PM +0100, Richard Purdie wrote: > > > I'm happy to say that meta-openembedded source mirroring is now working > > via the Yocto Project's infrastructure and available through the > > project's source mirrors. > > > > An example successful run with master is here: > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/156/builds/19 > > > > Nanbield should also work. > > > > kirkstone is here and is now error free but does show a lot of > > warnings: > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/156/builds/27 > > > > dunfell is also error free but also shows warnings: > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/156/builds/31 > > > > I did have to disable two recipes as one uses mercurial (the other has > > it as a dependency) and the mercurial checkout format changed between > > versions. The mirrors from later releases don't work with the version > > of mercurial-native from dunfell meta-oe. Disabling it was the > > easiest/safest path forward. > > > > Currently these are all scheduled to run automatically. If we can fix > > the warnings, that can stay. If there isn't a desire to fix the > > warnings in stable branches, we'd probably disable the scheduler for > > them since we have a policy of no warnings on the autobuilder. > > Maybe it's because I'm missing a different step, but I've always had to > setup source mirrors for SCM archives to be in a subdirectory, not just > for mercurial style problems but for hash changes. For example I have: > $ ls -d ~/work/OE/downloads/*/git2_sourceware.org.git.glibc.git.tar.gz > /home/trini/work/OE/downloads/dunfell/git2_sourceware.org.git.glibc.git.tar.gz > /home/trini/work/OE/downloads/honister/git2_sourceware.org.git.glibc.git.tar.gz > ... > > And then have in my PREMIRRORS: > git://.*/.* ${SOURCE_MIRROR_URL}/${LAYERSERIES_COMPAT:core} \n \ > gitsm://.*/.* ${SOURCE_MIRROR_URL}/${LAYERSERIES_COMPAT:core} \n \ > > So that I get the right thing. Might this be closer to the path forward > to solve the above issue? Or is mine because I'm not generating the > archives correctly to start with (and so the mercurial issue really is > special) ?
The idea is that information is not removed from the archives so that a newer archive should always have everything the older one had plus more. In that sense, DL_DIR should be shareable between newer and older releases and the mirror tarballs should to. They don't have to be identical, newer ones may contain new revisions, as long as the older ones are still there. For YP, we only have one source mirror for all releases. With mercurial, they changed the on disk format newer tooling creates so it doesn't work with the mercurial-native from dunfell. If you ASSUME_PROVIDED it, or update the recipe it would work. Since it is a single recipe on an fairly old release (now) I'm not worrying too much about it. The mirrors do have the data and people would make it work if they needed to. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#105780): https://lists.openembedded.org/g/openembedded-devel/message/105780 Mute This Topic: https://lists.openembedded.org/mt/102200675/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-devel/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
