Re: [yocto] Missing layer in the layer index

["Paul Barker" <paul@betafive.co.uk>]

On Thu, 5 Dec 2019, at 10:07, Paul Eggleton wrote:
> On Thursday, 5 December 2019 9:48:48 PM NZDT Paul Barker wrote:
> > On Thu, 5 Dec 2019, at 01:37, Paul Eggleton wrote:
> > > On Wednesday, 4 December 2019 11:10:49 PM NZDT Nicolas Dechesne wrote:
> > > > > I'd like to make sure meta-sancloud (https://github.com/SanCloudLtd/meta-> > sancloud) is listed in the layer index. I can't see it listed for either
> > > > > of the branches we support (thud & rocko). However, when I try to add the
> > > > > layer I get the error message "Layer with this Layer name already exists."
> > > > >
> > > > > Perhaps this was already added with an old URL. Is there any way to get
> > > > > this fixed up?
> > > > 
> > > > yes, this is the reason. It exists with the following URL:
> > > > https://bitbucket.sancloud.co.uk/scm/yb/meta-sancloud.git
> > > > 
> > > > The maintainer for that layer is not listed.. was it you?
> > > 
> > > Oddly there are no maintainer records and no layer branch records either, 
> > > hence why the layer doesn't show up properly. I'm unsure how it would have got 
> > > into that state or how long it's been there, but since it's pretty much 
> > > useless I have gone ahead and deleted it - Paul, could you please file your 
> > > submission again?
> > 
> > Thanks for that, it may have got broken in the layer index when we moved the repo from our private Bitbucket instance over to GitHub. I've resubmitted now.
> 
> Actually looking at the new repo I think I know what might have 
> happened. The layer index does not currently handle layers that don't 
> have a master branch perfectly; it could be that the original repo went 
> away and that caused it to remove all the layerbranches, and since 
> maintainers are per layerbranch they also got removed. (If a master 
> layerbranch is there it is protected from deletion even if upstream 
> master goes away, you just get a warning during parsing.)
> 
> I can understand why people don't want to have a master branch if they 
> aren't using it; that most layers have it was an assumption I made in 
> the earlier design. It's fixable but will take a bit of work to ensure 
> the correct behaviour. (This assumption is also reflected in the 
> submission process - by default a master layerbranch is created, but 
> for layers without a master branch as the approver you then have to go 
> in and switch the master branch to whatever the "main" branch is - I 
> just did that for this layer.)

Ah ok. I have a pet hate of layers with a master branch that doesn't actually work with master of oe-core and other layers. I'd rather see a repository with no master branch!

In this case we're building with meta-ti & meta-arago which only support every other release. I know they also have a master branch but it's always been broken when I've tried to use it in the past. I may see if I can give it another try.

-- 
Paul Barker