* [Buildroot] [PATCH 1/4] dhrystone: add a hash file
2015-12-02 20:45 ` [Buildroot] [PATCH 1/4] dhrystone: " Peter Korsgaard
@ 2015-12-02 21:58 ` Arnout Vandecappelle
2015-12-02 22:03 ` Yann E. MORIN
2015-12-03 10:35 ` Vicente Olivert Riera
2 siblings, 0 replies; 17+ messages in thread
From: Arnout Vandecappelle @ 2015-12-02 21:58 UTC (permalink / raw)
To: buildroot
On 02-12-15 21:45, Peter Korsgaard wrote:
>>>>>> "Vicente" == Vicente Olivert Riera <Vincent.Riera@imgtec.com> writes:
>
> > Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
> > ---
> > package/dhrystone/dhrystone.hash | 2 ++
> > 1 file changed, 2 insertions(+)
> > create mode 100644 package/dhrystone/dhrystone.hash
>
> > diff --git a/package/dhrystone/dhrystone.hash b/package/dhrystone/dhrystone.hash
> > new file mode 100644
> > index 0000000..9ea22a3
> > --- /dev/null
> > +++ b/package/dhrystone/dhrystone.hash
> > @@ -0,0 +1,2 @@
> > +# Locally calculated
> > +sha256 038a7e9169787125c3451a6c941f3aca5db2d2f3863871afcdce154ef17f4e3e dhry-c
>
> Hmm, what are we going to do if this file ever changes?
>
Isn't that the whole point of the hash, that we notice when it changes?
That said, I'm not sure what we can do about it when that happens, except
switch to a more reliable mirror.
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Buildroot] [PATCH 1/4] dhrystone: add a hash file
2015-12-02 20:45 ` [Buildroot] [PATCH 1/4] dhrystone: " Peter Korsgaard
2015-12-02 21:58 ` Arnout Vandecappelle
@ 2015-12-02 22:03 ` Yann E. MORIN
2015-12-03 10:35 ` Vicente Olivert Riera
2 siblings, 0 replies; 17+ messages in thread
From: Yann E. MORIN @ 2015-12-02 22:03 UTC (permalink / raw)
To: buildroot
Peter, Vicente, All,
On 2015-12-02 21:45 +0100, Peter Korsgaard spake thusly:
> >>>>> "Vicente" == Vicente Olivert Riera <Vincent.Riera@imgtec.com> writes:
>
> > Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
> > ---
> > package/dhrystone/dhrystone.hash | 2 ++
> > 1 file changed, 2 insertions(+)
> > create mode 100644 package/dhrystone/dhrystone.hash
>
> > diff --git a/package/dhrystone/dhrystone.hash b/package/dhrystone/dhrystone.hash
> > new file mode 100644
> > index 0000000..9ea22a3
> > --- /dev/null
> > +++ b/package/dhrystone/dhrystone.hash
> > @@ -0,0 +1,2 @@
> > +# Locally calculated
> > +sha256 038a7e9169787125c3451a6c941f3aca5db2d2f3863871afcdce154ef17f4e3e dhry-c
>
> Hmm, what are we going to do if this file ever changes?
That's a good question...
Since ultimately I'd like we get hash files for the packages, and make
it an error when the hash file is missing, we'd have to handle those
cases in a consistent way.
There are two options here:
- add a real hash, and break older releases when the file is updated
upstream,
- add a 'none' hash, but loose the detection tht upstream has changed
(but the autobuilders would tell us if that change breaks the
build).
I'm afraid the only possible solution if we want to have a hash is the
second solution (but with a comment explaning why it is so).
But until we make the .hash files mandatory, we can just not add it for
non-versioned upstreams. So I'd say we drop that one.
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
^ permalink raw reply [flat|nested] 17+ messages in thread* [Buildroot] [PATCH 1/4] dhrystone: add a hash file
2015-12-02 20:45 ` [Buildroot] [PATCH 1/4] dhrystone: " Peter Korsgaard
2015-12-02 21:58 ` Arnout Vandecappelle
2015-12-02 22:03 ` Yann E. MORIN
@ 2015-12-03 10:35 ` Vicente Olivert Riera
2015-12-03 10:44 ` Thomas Petazzoni
2 siblings, 1 reply; 17+ messages in thread
From: Vicente Olivert Riera @ 2015-12-03 10:35 UTC (permalink / raw)
To: buildroot
Hi Peter,
On 02/12/15 20:45, Peter Korsgaard wrote:
>>>>>> "Vicente" == Vicente Olivert Riera <Vincent.Riera@imgtec.com> writes:
>
> > Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
> > ---
> > package/dhrystone/dhrystone.hash | 2 ++
> > 1 file changed, 2 insertions(+)
> > create mode 100644 package/dhrystone/dhrystone.hash
>
> > diff --git a/package/dhrystone/dhrystone.hash b/package/dhrystone/dhrystone.hash
> > new file mode 100644
> > index 0000000..9ea22a3
> > --- /dev/null
> > +++ b/package/dhrystone/dhrystone.hash
> > @@ -0,0 +1,2 @@
> > +# Locally calculated
> > +sha256 038a7e9169787125c3451a6c941f3aca5db2d2f3863871afcdce154ef17f4e3e dhry-c
>
> Hmm, what are we going to do if this file ever changes?
isn't the purpose of the hash files to ensure that we download exactly
what we want to download, so we can make the builds reproducible?
If that file changes, we will notice it thanks to its hash file. You
could ask the same for tarballs. What are we going to do if this
tarballs ever changes?
Regards,
Vincent.
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Buildroot] [PATCH 1/4] dhrystone: add a hash file
2015-12-03 10:35 ` Vicente Olivert Riera
@ 2015-12-03 10:44 ` Thomas Petazzoni
2015-12-03 11:42 ` Peter Korsgaard
0 siblings, 1 reply; 17+ messages in thread
From: Thomas Petazzoni @ 2015-12-03 10:44 UTC (permalink / raw)
To: buildroot
Vicente,
On Thu, 3 Dec 2015 10:35:01 +0000, Vicente Olivert Riera wrote:
> > > diff --git a/package/dhrystone/dhrystone.hash b/package/dhrystone/dhrystone.hash
> > > new file mode 100644
> > > index 0000000..9ea22a3
> > > --- /dev/null
> > > +++ b/package/dhrystone/dhrystone.hash
> > > @@ -0,0 +1,2 @@
> > > +# Locally calculated
> > > +sha256 038a7e9169787125c3451a6c941f3aca5db2d2f3863871afcdce154ef17f4e3e dhry-c
> >
> > Hmm, what are we going to do if this file ever changes?
>
> isn't the purpose of the hash files to ensure that we download exactly
> what we want to download, so we can make the builds reproducible?
>
> If that file changes, we will notice it thanks to its hash file. You
> could ask the same for tarballs. What are we going to do if this
> tarballs ever changes?
It also took me a bit to understand Peter's comment. I believe what
Peter means is that this file has no version in its name. So if
upstream changes the file, the hash will change, and we will notice.
But it will break every previous Buildroot version that has been
released, since the old file can no longer be fetched from anywhere.
But unless I'm missing something, I believe that this is exactly what
we want: if upstream changes the file, it *does* affect old Buildroot
versions, and we want users of such old Buildroot versions to be loudly
notified that the dhry-c file they are building from is no longer the
same than the one that existed at the time the Buildroot they are using
was released.
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Buildroot] [PATCH 1/4] dhrystone: add a hash file
2015-12-03 10:44 ` Thomas Petazzoni
@ 2015-12-03 11:42 ` Peter Korsgaard
2015-12-03 20:52 ` Peter Seiderer
0 siblings, 1 reply; 17+ messages in thread
From: Peter Korsgaard @ 2015-12-03 11:42 UTC (permalink / raw)
To: buildroot
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
Hi,
>> > Hmm, what are we going to do if this file ever changes?
>>
>> isn't the purpose of the hash files to ensure that we download exactly
>> what we want to download, so we can make the builds reproducible?
>>
>> If that file changes, we will notice it thanks to its hash file. You
>> could ask the same for tarballs. What are we going to do if this
>> tarballs ever changes?
> It also took me a bit to understand Peter's comment. I believe what
> Peter means is that this file has no version in its name. So if
> upstream changes the file, the hash will change, and we will notice.
Yes, my reply was perhaps a bit too terse.
> But it will break every previous Buildroot version that has been
> released, since the old file can no longer be fetched from anywhere.
No, it will not break as long as we keep a backup of the old file on
sources.buildroot.net, as buildroot will fall back to using that.
> But unless I'm missing something, I believe that this is exactly what
> we want: if upstream changes the file, it *does* affect old Buildroot
> versions, and we want users of such old Buildroot versions to be loudly
> notified that the dhry-c file they are building from is no longer the
> same than the one that existed at the time the Buildroot they are using
> was released.
Agreed, but the problem is if upstream ever changes the file content (for
bugfixes or new features) then we cannot use the new version without
updating our sources.buildroot.net mirror (and hence break old
releases).
But ok, for something as old as dhrystone this probably isn't very
likely to happen (and we could carry the improvements/fixes as a local
patch if it does).
--
Venlig hilsen,
Peter Korsgaard
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Buildroot] [PATCH 1/4] dhrystone: add a hash file
2015-12-03 11:42 ` Peter Korsgaard
@ 2015-12-03 20:52 ` Peter Seiderer
2015-12-03 21:18 ` Peter Korsgaard
0 siblings, 1 reply; 17+ messages in thread
From: Peter Seiderer @ 2015-12-03 20:52 UTC (permalink / raw)
To: buildroot
Hello Peter,
On Thu, 03 Dec 2015 12:42:50 +0100, Peter Korsgaard <peter@korsgaard.com> wrote:
> >>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
>
> Hi,
>
> >> > Hmm, what are we going to do if this file ever changes?
> >>
> >> isn't the purpose of the hash files to ensure that we download exactly
> >> what we want to download, so we can make the builds reproducible?
> >>
> >> If that file changes, we will notice it thanks to its hash file. You
> >> could ask the same for tarballs. What are we going to do if this
> >> tarballs ever changes?
>
> > It also took me a bit to understand Peter's comment. I believe what
> > Peter means is that this file has no version in its name. So if
> > upstream changes the file, the hash will change, and we will notice.
>
> Yes, my reply was perhaps a bit too terse.
>
> > But it will break every previous Buildroot version that has been
> > released, since the old file can no longer be fetched from anywhere.
>
> No, it will not break as long as we keep a backup of the old file on
> sources.buildroot.net, as buildroot will fall back to using that.
>
>
> > But unless I'm missing something, I believe that this is exactly what
> > we want: if upstream changes the file, it *does* affect old Buildroot
> > versions, and we want users of such old Buildroot versions to be loudly
> > notified that the dhry-c file they are building from is no longer the
> > same than the one that existed at the time the Buildroot they are using
> > was released.
>
> Agreed, but the problem is if upstream ever changes the file content (for
> bugfixes or new features) then we cannot use the new version without
> updating our sources.buildroot.net mirror (and hence break old
> releases).
>
Why not append a (short) hash to the saved file for unversioned downloads?
e.g. dhry-c-038a7e9
Regards,
Peter
> But ok, for something as old as dhrystone this probably isn't very
> likely to happen (and we could carry the improvements/fixes as a local
> patch if it does).
>
^ permalink raw reply [flat|nested] 17+ messages in thread
* [Buildroot] [PATCH 1/4] dhrystone: add a hash file
2015-12-03 20:52 ` Peter Seiderer
@ 2015-12-03 21:18 ` Peter Korsgaard
0 siblings, 0 replies; 17+ messages in thread
From: Peter Korsgaard @ 2015-12-03 21:18 UTC (permalink / raw)
To: buildroot
>>>>> "Peter" == Peter Seiderer <ps.report@gmx.net> writes:
Hi,
> Hello Peter,
> Why not append a (short) hash to the saved file for unversioned downloads?
> e.g. dhry-c-038a7e9
This could be done, but it complicates the primary/backup site handling
(E.G. should they use the upstream name or "our" name) - The way
sources.buildroot.net is kept up to date would mean that they would need
to use "our" name.
--
Venlig hilsen,
Peter Korsgaard
^ permalink raw reply [flat|nested] 17+ messages in thread