[Buildroot] AUH (auto-upgrade-helper) for the Buildroot

[Akhilesh Nema]

Hi Arnout,

Thank you for providing such a comprehensive response.

On Wed, Mar 20, 2024 at 10:21 AM Arnout Vandecappelle <arnout at mind.be>
wrote:

>
>
> On 19/03/2024 22:02, Akhilesh Nema wrote:
> > Hi Buildroot Experts,
> >
> > Around 80% of the commits on the Buildroot involve package upgrades.
> > (As of March 18, 2024)
> > Total number of commits on the br master         - 71554
> > Total number of commits on the package folder - 57305
> >
> > Yocto has an AUH tool to perform trivial upgrades.
>
>   I believe in Yocto, AUH is only used to help people preparing patches.
> The
> update is not actually performed automatically, right? The only thing that
> happens automatically is that there's a server that runs AUH (weekly IIRC)
> and
> sends the results (including patches) to the mailing list.
>
Yes, it seems that  the Yocto Server is running it bi-weekly, and patches
are submitted to the mailing-list/patchwork for review.
https://patchwork.yoctoproject.org/project/oe-core/list/?series=&submitter=&state=*&q=AUH&archive=both&delegate=

Update is not performed automatically.


>   For sure, in Buildroot, we don't want fully automatic package bumps. We
> definitely want all package bumps to be runtime tested by someone!
>
>   That said, something that helps prepare an update is certainly welcome.
>
>
> > It would be great if AUH (
> https://git.yoctoproject.org/auto-upgrade-helper
> > <https://git.yoctoproject.org/auto-upgrade-helper>) will be available
> for the
> > Buildroot. Is there a plan to support AUH or a similar tool on Buildroot?
>
>   The existing yocto tool is certainly not going to work as is, it relies
> on a
> bunch of OpenEmbedded specific features (like devtool).
>
>   The way this should work in Buildroot context is probably:
>
> - a util (in utils/ directory) that uses release-monitoring to find out
> the
> latest version of a package, and that updates the .mk and .hash files
> accordingly. It could perhaps also write a commit message.
>
> - a tool that completes the update flow for a (set of) packages by also
> running
> make legal-info on them, and running br-test-pkg and checkpackage. Ideally
> also
> the runtime tests for that package, though it may be difficult to find
> them.
> Note that this tool will still need to get a config fragment as input,
> because
> br-test-pkg requires it.
>
>   With that in place, we could install a cron job on a server somewhere to
> regularly perform this. But, as said before, the patches would still need
> to be
> runtime tested!
>
These are great ideas. I hope to see AUH port added to Buildroot soon.

Still there are some packages without a mapping on release-monitoring.org
(327, source - http://autobuild.buildroot.org/stats/master.html)
Some of the mappings are broken. (for example
https://release-monitoring.org/project/21837/.)
Buildroot may also apply an alternate (or supplement) method similar to the
one used by Yocto to check the availability of a new version.
https://github.com/openembedded/openembedded-core/blob/master/meta/lib/oe/recipeutils.py#L1012

>
>   Regards,
>   Arnout
>
>
> >
> > The usage of AUH can be found here -
> >
> https://docs.yoctoproject.org/dev-manual/upgrading-recipes.html#using-the-auto-upgrade-helper-auh
> <
> https://docs.yoctoproject.org/dev-manual/upgrading-recipes.html#using-the-auto-upgrade-helper-auh
> >
> >
> > Benefits of this tool are self explanatory.
> >
> > Thanks
> > Akhilesh
> >
> > _______________________________________________
> > buildroot mailing list
> > buildroot at buildroot.org
> > https://lists.buildroot.org/mailman/listinfo/buildroot


Thanks
Akhilesh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.buildroot.org/pipermail/buildroot/attachments/20240321/720f1354/attachment-0001.html>