From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1/2] package/poco: bump to version 1.6.1
Date: Mon, 10 Aug 2015 20:54:27 +0200 [thread overview]
Message-ID: <20150810205427.156aa7b9@free-electrons.com> (raw)
In-Reply-To: <1439217249.5186.18.camel@embedded.rocks>
Dear J?rg Krause,
On Mon, 10 Aug 2015 16:34:09 +0200, J?rg Krause wrote:
> In that case I do not understand the help text from
> nightly.buildroot.org, 17.4. The .hash file:
>
> "The none hash type is reserved to those archives downloaded from a
> repository, like a git clone, a subversion checkout? or archives
> downloaded with the github helper Section 17.19.2, ?How to add a
> ^^^^^^^^^^^^^
> package from GitHub?."
>
> And from the example:
> "# No hash for 1234, comes from the github-helper:
> none xxx
> libfoo-1234.tar.gz"
I think the case where we really need the "none" type is for packages
that sometimes get downloaded as a tarball, and sometimes from Github.
Look for example at binutils.hash:
# From ftp://gcc.gnu.org/pub/binutils/releases/sha512.sum
sha512 ffe8ef263ef99183e8cc823fe8487ff7d0f7bf9a8efd2853b5f4636aca0023850d13de4eac7d77a5f69413d8a50e6f95bb14569be53df86c0bce38034525ab74 binutils-2.22.tar.bz2
sha512 dec753bbba008f1526b89cf1bd85feba78f362f5333ffdf93953fd131eb755976dec82a0a4ba38c43d2434da007137780cfe674de5414be5cf7ce7fbc6af6d16 binutils-2.23.2.tar.bz2
sha512 5ec95ad47d49b12c4558a8db0ca2109d3ee1955e3776057f3330c4506f8f4d1cf5e505fbf8a16b98403a0fcdeaaf986fe0a22be6456247dbdace63ce1f776b12 binutils-2.24.tar.bz2
sha512 0b36dda0e6d32cd25613c0e64b56b28312515c54d6a159efd3db9a86717f114ab0a0a1f69d08975084d55713ebaeab64e4085c9b3d1c3fa86712869f80eb954d binutils-2.25.1.tar.bz2
# No hash for the ARC variant, comes from the github-helper:
none xxx binutils-arc-2015.06.tar.gz
We want hashes for the tarballs, so we added them. But then, the logic
of the hash verification is that if a .hash file exists, then *all*
files downloaded by the package should have hashes. If not, then the
build is aborted. That's why we added this "none" type.
Now, we could also decided to add just a single "none" entry in the
hash file of packages downloaded from Github just to make it clear that
there is voluntarily no hash being provided, and therefore clarify
between packages that don't have a hash file because it hasn't been
added yet from packages that don't have a hash file because they are
downloaded from Github. But it means adding quite a bunch of pretty
useless .hash files to the ~220+ packages we download from github.
In any case, we should clarify that in the documentation, indeed.
Yann, thoughts?
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
next prev parent reply other threads:[~2015-08-10 18:54 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-04 9:57 [Buildroot] [PATCH 1/2] package/poco: bump to version 1.6.1 Jörg Krause
2015-08-04 9:57 ` [Buildroot] [PATCH 2/2] package/poco: disable for static build Jörg Krause
2015-08-06 6:56 ` Thomas Petazzoni
2015-08-10 14:22 ` [Buildroot] [PATCH 1/2] package/poco: bump to version 1.6.1 Thomas Petazzoni
2015-08-10 14:34 ` Jörg Krause
2015-08-10 18:54 ` Thomas Petazzoni [this message]
2015-08-10 20:47 ` Yann E. MORIN
2015-08-11 8:13 ` [Buildroot] .hash files for all packages? Thomas Petazzoni
2015-08-11 8:55 ` Yann E. MORIN
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=20150810205427.156aa7b9@free-electrons.com \
--to=thomas.petazzoni@free-electrons.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