Same underlying issue as: https://bugzilla.yoctoproject.org/show_bug.cgi?id=14676 A recent attempt to add a layer (meta-dart) has the same issue, as GitHub by default sets the branch name as "main" and the layerindex code does not know how to handle this. http://layers.openembedded.org/layerindex/branch/master/layer/meta-dart/
Created attachment 4916 [details] Screen capture of the crash/log provided by r3flow
This also happened for meta-synwall. Not only will the initial update of the layer fail (it cannot create the layer-branch), but it will also fail to create the Maintainer information, apparently. So even after manually creating a <layer>-master layer-branch with "actual branch" set to "main"... an admin also must add the maintainer information manually. This is very annoying.
Also affected meta-dts-distro
This patch addresses adding an optional branch, but it would not help with a layer with default branch (not "master") being added? Pretty sure the UI also needs a change... https://lore.kernel.org/yocto/20211022040302.32088-1-changqing.li@windriver.com/
Potentially related, there are layers which don't have an active master branch but just have the release branches: https://github.com/STMicroelectronics/meta-st-stm32mp
I'll take the opportunity to point out that meta-qt6 doesn't use YP branch names but uses release numbers: 6.2, 6.3, 6.4, 6.5, 6.5.1 ... sigh. https://code.qt.io/cgit/yocto/meta-qt6.git/ There is a Yocto version support compatibility matrix. Anyway, I don't expect Tim to deal with the qt6 approach but Samuli (who I've CCed) might want to comment or better still add some branches and have meta-qt6 indexed so people can more easily find the layer. Finally, Tim and I talked about this issue briefly on a Yocto call this week and he mentioned that he'll be working on the layer index code over the next 6 months on a part time ( paid! ) basis and was considering adding a feature to the layer index to allow aliasing. I'm not convinced that such a feature is the best approach since I see it as something that should be in the git repo. Thoughts anyone?
meta-loongarch just hit this too.
Bulk move of 64 bugs to 4.3 M3 after a quick review. If a bug is actually fixed, please add a commit link and resolve it. -- Randy for YP bug team.
What's the current status of the layerindex regarding the non YP branches? Was the aliasing feature pursued further. In the meanwhile, would it be possible to get the layerindex to use 'dev' branch from meta-qt6 layer instead of the default 'master', similar to what's done for the layers with 'main' branch? As Randy mentioned, the layer is following Qt versioning in the branching instead of YP branch names, and our CI infra is relying on these.
Moved to M4.
Bulk move to 5.0 M1. -- Randy
Bulk move of 52 5.0-M1 bugs to M2.
This is somewhat implemented by exposing the "Actual branch" field (the actual_branch variable from LayerBranch model), which can allow the proper actual_branch to be set during layer submission. In the case of "main" or "development" (as suggested by hints with newer git), we could probably help by checking if "master" exists and if not try another well known choice and then throw an error. We can use git to query the "default" branch, which may also be helpful, but might create unpredictable/undesired behavior. What will help for a layer like meta-qt6 where every LayerBranch needs to be mapped to a different upstream git branch is a UI table view showing all the LayerBranches for a given LayerItem and the actual_branch to "stable" branch mapping. We could also probably add a "Updates enabled" check box next to each branch to allow admin/staff users to rapidly change all of a layer's updates at the same time. Perhaps a "Manage Layer Branches" button would take the user to this view. Layer maintainers would be able to set the actual_branch fields. And perhaps an "Add Layer Branch" button could be at the bottom to allow missing branches to be added...
I'm honesetly considering closing this bug, because the "Actual Branch" field does what is needed. Anything else will likely be the layer index trying to be psychic. We have many places where layers are doing things that the layer index can not understand. And if we do not get more people giving feedback and help, it will not happen.
Moving to 5.1 because it will not likely happen in 5.0M4 either.
Bulk move to 5.2-M3.
Bulk move to 5.2-M3 and this time I'll actually specify M3!
As Tim said, the "Actual Branch" field does what is needed. Anything else will likely be the layer index trying to be psychic. Re-open if you disagree and have an example that will be useful.