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

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

[Tom Rini]

Hey all,

It's release day and I've tagged v2020.07-rc3.  We're moving along
nicely and should continue with prioritizing stabilization and obviously
correct updates / migrations at this time.

Once again, for a changelog, 
git log --merges v2020.07-rc2..v2020.07-rc3
and as always, I ask for more details in the PRs people send me so I can
put them in the merge commit.

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!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200525/b58d6576/attachment.sig>

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

[Peter Robinson]

> It's release day and I've tagged v2020.07-rc3.  We're moving along
> nicely and should continue with prioritizing stabilization and obviously
> correct updates / migrations at this time.
>
> Once again, for a changelog,
> git log --merges v2020.07-rc2..v2020.07-rc3
> and as always, I ask for more details in the PRs people send me so I can
> put them in the merge commit.
>
> 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?

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

[Wolfgang Denk]

Dear Peter,

In message <CALeDE9MGoubGU7KgEHZaHtHAcv2E4wasHgewNQMsL3_KFJzEzQ@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.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Of course life is  bizarre.  The  more  bizarre  it  gets,  the  more
interesting  it  is.  The only way to approach it is to make yourself
some popcorn and enjoy the show.                      - David Gerrold

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

[Tom Rini]

On Tue, May 26, 2020 at 01:13:56PM +0200, Wolfgang Denk wrote:
> Dear Peter,
> 
> In message <CALeDE9MGoubGU7KgEHZaHtHAcv2E4wasHgewNQMsL3_KFJzEzQ@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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200526/0df4b986/attachment.sig>

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

[Alexey Brodkin]

Hi Tom, Wolfgang,

> > In message <CALeDE9MGoubGU7KgEHZaHtHAcv2E4wasHgewNQMsL3_KFJzEzQ@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.

-Alexey

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

[Tom Rini]

On Tue, May 26, 2020 at 01:15:36PM +0000, Alexey Brodkin wrote:
> Hi Tom, Wolfgang,
> 
> > > In message <CALeDE9MGoubGU7KgEHZaHtHAcv2E4wasHgewNQMsL3_KFJzEzQ@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.

I might be missing something but while I do see things about how to have
(and show "verified") signed commits, I don't see that we can do that on
tags.  I can script the release process but I think we would move from
the release tag being signed to the commit being signed.  Which isn't
awful I suppose, but is a change.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200526/65017418/attachment.sig>

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

[Tom Rini]

On Tue, May 26, 2020 at 11:13:30AM +0100, Peter Robinson wrote:
> > It's release day and I've tagged v2020.07-rc3.  We're moving along
> > nicely and should continue with prioritizing stabilization and obviously
> > correct updates / migrations at this time.
> >
> > Once again, for a changelog,
> > git log --merges v2020.07-rc2..v2020.07-rc3
> > and as always, I ask for more details in the PRs people send me so I can
> > put them in the merge commit.
> >
> > 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?

OK, so the hiccup has been fixed and the tar file and signature is up
now and my release script will fail rather than continue when there's a
problem like this in the future.  Thanks for pointing this out!

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200602/5e7f7acc/attachment.sig>