From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] Verifying linux 5.4.x hashes
Date: Fri, 28 May 2021 22:49:50 +0200 [thread overview]
Message-ID: <20210528204950.GJ2788252@scaer> (raw)
In-Reply-To: <20210528202931.futcxwo2lokvoact@falbala.internal.home.lespocky.de>
Alexander, All,
On 2021-05-28 22:29 +0200, Alexander Dahl spake thusly:
> On Fri, May 28, 2021 at 09:55:06PM +0200, Yann E. MORIN wrote:
> > - the hashes for custom version are not checked at all, becasue we
> > can't have all the hashes of all the kernel versions
> Maybe not for non official version, but why not for all mainline
> kernel versions?
> % git tag | grep -v rc | wc -l
> 3025
> This would be 3k lines of text currently, big compared to other
> buildroot hashes files, but not that huge in general. If one could
> split it up for major releases, I would consider it maintainable,
> that's just few hundred lines per kernel version max.
The problem is not really about the number of hashes. The problem is
about kernel relases that are made after we have done a relase.
For example, let's assume that we add all known hashes right now (and
update until we release. When we release Buildroot 2021.05, it is
frozen: it's not going to change, that's all about being a release.
A day after we release 2021.05 with all say) then-known 5.4.x versions
and thus up to and including 5.4.123, the kernel team (GKH) releases
5.4.124.
Then Buildroot 2021.05 no longer has a hash for all kernel releases.
That is the actual problem: kernel releases are going to be made after
we tag and release our own versions.
So, no, we can't have a hash for all kernel versions.
Besides, you are missing the (presumably much fewer) CIP-SLTS and
CIP-RT-SLTS versions, but that's a detail...
> Would of course not apply to custom versions, for mainline only. But
> we all head for mainline first, anyways, don't we? ;-)
Muahahaha! :-]
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 561 099 427 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
next prev parent reply other threads:[~2021-05-28 20:49 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-28 17:15 [Buildroot] Verifying linux 5.4.x hashes Ian Merin
2021-05-28 19:55 ` Yann E. MORIN
2021-05-28 20:03 ` Arnout Vandecappelle
2021-05-28 20:17 ` Yann E. MORIN
2021-06-09 14:28 ` [Buildroot] [EXTERNAL] " Ian Merin
2021-06-12 11:54 ` Arnout Vandecappelle
2021-05-28 20:29 ` [Buildroot] " Alexander Dahl
2021-05-28 20:49 ` Yann E. MORIN [this message]
2021-05-28 19:59 ` Arnout Vandecappelle
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210528204950.GJ2788252@scaer \
--to=yann.morin.1998@free.fr \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.