Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1/4] package/openjdk: fix hash
Date: Sat, 18 Apr 2020 12:01:34 +0200	[thread overview]
Message-ID: <20200418120134.0a54a287@windsurf.home> (raw)
In-Reply-To: <20200417232922.3762195-1-aduskett@gmail.com>

On Fri, 17 Apr 2020 16:29:19 -0700
aduskett at gmail.com wrote:

> From: Adam Duskett <Aduskett@gmail.com>
> 
> The hash should be
> 6815dbac7dd0f86291254e84ed17565c89477eeb6b0847a9648b00ecb4f07634

No, the hash was
6815dbac7dd0f86291254e84ed17565c89477eeb6b0847a9648b00ecb4f07634, and
it is now
fcd13ebd63d40c1c2f3cabfb7bc368962ff7b5935523be2a0e769352987145ae.

But still, why do you fix hashes like that, without investigating at
least a little bit what's going on? How come we committed a wrong hash?
How come there are no build failures related to this incorrect hash?

If you look at
http://autobuild.buildroot.net/results/0a4/0a4608828365df301114b533d6b59a4733599d94/build-end.log,
you will see why:

 - We download from the original upstream location, and indeed the hash
   of the upstream tarball is
   fcd13ebd63d40c1c2f3cabfb7bc368962ff7b5935523be2a0e769352987145ae,
   but we expect
   6815dbac7dd0f86291254e84ed17565c89477eeb6b0847a9648b00ecb4f07634

 - So we fallback to sources.buildroot.net, and here the tarball has
   the expected hash, i.e
   6815dbac7dd0f86291254e84ed17565c89477eeb6b0847a9648b00ecb4f07634

So this means that:

 (1) Upstream changed the contents of their tarball, which is really
     BAD and we want to understand what are the changes. So you should
     diff the new upstream  tarball, and the tarball that we have in
     sources.buildroot.net and investigate the differences.

 (2) We need to notify upstream that this is really bad.

 (3) You can't change the hash just like this, because it would mean
     that the hash would no longer match with the tarball we have
     backed up on sources.buildroot.net.

If we have hashes, it's not to blindly update them. We have hashes
precisely to detect that kind of situation, so if you blindly update
the hashes without doing any investigation, it makes it completely
useless to have hashes.

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

      parent reply	other threads:[~2020-04-18 10:01 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-17 23:29 [Buildroot] [PATCH 1/4] package/openjdk: fix hash aduskett at gmail.com
2020-04-17 23:29 ` [Buildroot] [PATCH 2/4] package/openjdk: fix installation with merged usr directories aduskett at gmail.com
2020-04-18 12:17   ` Yann E. MORIN
2020-04-18 12:26   ` Yann E. MORIN
2020-04-17 23:29 ` [Buildroot] [PATCH 3/4] package/openjdk: copy all directories and files when installing aduskett at gmail.com
2020-04-18 12:21   ` Yann E. MORIN
2020-04-18 17:00     ` Adam Duskett
2020-04-17 23:29 ` [Buildroot] [PATCH 4/4] package/openjdk: add support for building the full jdk aduskett at gmail.com
2020-04-18 10:03   ` Thomas Petazzoni
2020-04-18 12:02   ` Yann E. MORIN
2020-04-18 10:01 ` Thomas Petazzoni [this message]

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=20200418120134.0a54a287@windsurf.home \
    --to=thomas.petazzoni@bootlin.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox