On Fri, Oct 27, 2023 at 05:53:24PM +0100, Richard Purdie wrote:
> 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.

Right. So, I think I got astray somewhere then, sorry. I would have
sworn the case I had run in to was that my archive mirror of say
linux-yocto (so, something that can be painful to refresh from scratch)
didn't have commits / branches that it should, and so went and split up
the source archives per-codename. I did a manual inspection of the glibc
archive above and it looks like it should have everything for honister
and dunfell (and anything else). So I likely really hit the problem of
commit changed and archive just didn't have it, period. So not something
that required codename based splitting. Sorry for the noise.

> 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.

Thanks for explaining more.

-- 
Tom
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#105781): 
https://lists.openembedded.org/g/openembedded-devel/message/105781
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]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to