[ANN] U-Boot v2020.07-rc3 released

Alexey Brodkin Alexey.Brodkin at synopsys.com
Tue May 26 15:15:36 CEST 2020

Hi Tom, Wolfgang,

> > In message <CALeDE9MGoubGU7KgEHZaHtHAcv2E4wasHgewNQMsL3_KFJzEzQ at mail.gmail.com> you wrote:
> > > >
> > > > I'm going to continue with the every-other-week RC schedule and release on
> > > > July 6th.  I'm currently planning to branch -next on June 8th but PRs
> > > > can be posted sooner and I'll get them queued up.  Thanks all!
> > >
> > > Is there a tar file?
> >
> > There is no need for (static) tarballs, as you can always download
> > one dynamically from the gitlab interface.
> >
> > Go to https://gitlab.denx.de/u-boot/u-boot , then clock on the
> > "Download" symbol, which looks something like this:
> >
> >         ||
> >         \/
> >       |____|
> >
> > It's labeled "Download source code", and you can select for example
> > "tar.bz2" download format.
> The problem is that unless this is unlike the github interface the
> tarballs are deleted / recreated at times and so the checksums change.
> In OpenEmbedded land this is worked around by using the githash for a
> specific tag and fetching that way.  I don't know if Fedora/etc support
> a similar mechanism.

That might be quite unfortunate if we stop producing "static" tarballs with
known checksums as in build-systems like Buildroot tarballs are still preferable
or at least simpler way of dealing with new versions.

Or at least if creation of "static tarballs" won't be supported looking forward
it might be good to make people aware of that somehow :)

Also cannot we use "Releases" feature of GitLab?
See https://gitlab.denx.de/help/user/project/releases/index.
Not sure if in case of "releases" tarballs could be still regenerated at some
point but even in that case we may "attach" "manually" created "assets" which will
have a known checksums and those are for sure as static as it can be.


More information about the U-Boot-Board-Maintainers mailing list