Request to add "meta-google/recipes-google/console/" to auto bump

Brandon Kim brandonkim at
Thu Jul 14 02:26:48 AEST 2022

Thanks for the insight, agreed on not using AUTOREV (which we don't
do, and thus why we had to manually bump a year's worth of change
here: and I
guess it gets fuzzy on what the definition of a  "well-maintained open
source projects" is.

I'll see if I can figure out what the process of adding to Yocto / OE
meta-layer is.


On Wed, Jul 13, 2022 at 4:56 AM Patrick Williams <patrick at> wrote:
> On Tue, Jul 12, 2022 at 11:42:58AM -0700, Brandon Kim wrote:
> > Hello,
> >
> > Following the instructions in
> >
> > we'd like to request "
> > <>"
> > to be added to the autobump list if possible (or let us know if the
> > instruction is outdated - or if there is concern for adding a meta-google
> > recipe to the autobump list). It points to a public github repo under
> > google:
> This instruction is correct still.  You should never use AUTOREV in a
> recipe.  It makes it so that builds are not reproducible and at a
> minimum breaks the release process.  When we make a release we'd have
> to make an additional commit to pin all the AUTOREVs, which we don't
> currently do.  If you look through the entire tree, including all the
> Yocto meta-layers, you shouldn't see any examples of using this in a
> formal meta-layer(*).
> I don't think we should add glome to the autobump list.  This list
> currently only contains recipes under the openbmc org.  Honestly, glome
> shouldn't even exist in meta-google[1].  There has been some discussion
> about what does "well-maintained open source projects" mean, but lately
> we've been interpreting this guideline to mean "nothing outside the
> openbmc org".  The expectation is that if you really are pointing at a
> "well-maintained open source project" you should have no trouble getting
> it put into meta-openembedded instead.  This saves us the trouble of
> having any debate about what is / is not "well-maintained".
> My recommendation would be to move glome to a Yocto/OE meta-layer and
> deal with them for updates because that is what we've been suggesting
> for anything not in the openbmc org lately.
> (*) I do see one in one of _our_ meta-layers and this needs to get
>     fixed... one of the problems of opening up machine metas to almost
>     any company who asks with little review oversight.
> 1.
> --
> Patrick Williams

More information about the openbmc mailing list