Patchwork Modified fetch() checksums to be correct for libpng 1.4.28 released 15/3/12 (current) instead of previous 8/3/12 release

login
register
mail settings
Submitter Alex Lennon
Date March 27, 2012, 10:47 p.m.
Message ID <1332888458-15872-1-git-send-email-ajlennon@dynamicdevices.co.uk>
Download mbox | patch
Permalink /patch/24691/
State Accepted
Commit 5aaca5c679d26a9f12645dc44cdfa20d1c0b3f52
Headers show

Comments

Alex Lennon - March 27, 2012, 10:47 p.m.
From: Alex J Lennon <ajlennon@gmail.com>

Signed-off-by: Alex J Lennon <ajlennon@gmail.com>
---
 recipes/libpng/libpng_1.2.48.bb |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)
Frans Meulenbroeks - March 28, 2012, 8:34 a.m.
2012/3/28  <ajlennon@dynamicdevices.co.uk>:
> From: Alex J Lennon <ajlennon@gmail.com>
>
> Signed-off-by: Alex J Lennon <ajlennon@gmail.com>
> ---
>  recipes/libpng/libpng_1.2.48.bb |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/recipes/libpng/libpng_1.2.48.bb b/recipes/libpng/libpng_1.2.48.bb
> index 50a3c03..534962d 100644
> --- a/recipes/libpng/libpng_1.2.48.bb
> +++ b/recipes/libpng/libpng_1.2.48.bb
> @@ -2,5 +2,5 @@ require libpng.inc
>
>  PR = "${INC_PR}.0"
>
> -SRC_URI[libpng.md5sum] = "7612af5660cd4b5e8c433ce53bea01a7"
> -SRC_URI[libpng.sha256sum] = "f6db51aff81b6920203678b29e8c68a5e3703cf5b39ae5e9e56370d17f31b1c4"
> +SRC_URI[libpng.md5sum] = "74c8c261bdf9a75274e22875183fda07"
> +SRC_URI[libpng.sha256sum] = "b4c92df11eadf3e81705a58253dbffc4b95169186899e28abdfc8aada8a20fcc"
> --
> 1.7.5.4
>
You mean upstream changed their source tarball (or whatever) without
updating the version number.
Yuk.

Guess we might want to mirror a version and pull from the mirror.
(changing the checksum alone creates issues because other people might
already have the version with the old checksum in their downloads.

Frans

PS: thinking of it: we might be able to resolve the latter issue by
forcing the removal of a file from downloads (and trigger a refetch)
if the .md5 does not match the md5 in the recipe.
Alex Lennon - March 28, 2012, 10:16 a.m.
>You mean upstream changed their source tarball (or whatever) without

That's correct. I compared my cached tar.bz2 with what's current from 
their SRC_URI
and sure enough there are differences, the most obvious being they've 
changed the
dates I reference. Yuk indeed, but it happens not infrequently I believe?

>Guess we might want to mirror a version and pull from the mirror.

I think that would be an excellent idea.

Cheers,

Alex

On 28/03/2012 09:34, Frans Meulenbroeks wrote:
> 2012/3/28<ajlennon@dynamicdevices.co.uk>:
>> From: Alex J Lennon<ajlennon@gmail.com>
>>
>> Signed-off-by: Alex J Lennon<ajlennon@gmail.com>
>> ---
>>   recipes/libpng/libpng_1.2.48.bb |    4 ++--
>>   1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/recipes/libpng/libpng_1.2.48.bb b/recipes/libpng/libpng_1.2.48.bb
>> index 50a3c03..534962d 100644
>> --- a/recipes/libpng/libpng_1.2.48.bb
>> +++ b/recipes/libpng/libpng_1.2.48.bb
>> @@ -2,5 +2,5 @@ require libpng.inc
>>
>>   PR = "${INC_PR}.0"
>>
>> -SRC_URI[libpng.md5sum] = "7612af5660cd4b5e8c433ce53bea01a7"
>> -SRC_URI[libpng.sha256sum] = "f6db51aff81b6920203678b29e8c68a5e3703cf5b39ae5e9e56370d17f31b1c4"
>> +SRC_URI[libpng.md5sum] = "74c8c261bdf9a75274e22875183fda07"
>> +SRC_URI[libpng.sha256sum] = "b4c92df11eadf3e81705a58253dbffc4b95169186899e28abdfc8aada8a20fcc"
>> --
>> 1.7.5.4
>>
> You mean upstream changed their source tarball (or whatever) without
> updating the version number.
> Yuk.
>
> Guess we might want to mirror a version and pull from the mirror.
> (changing the checksum alone creates issues because other people might
> already have the version with the old checksum in their downloads.
>
> Frans
>
> PS: thinking of it: we might be able to resolve the latter issue by
> forcing the removal of a file from downloads (and trigger a refetch)
> if the .md5 does not match the md5 in the recipe.
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Alex Lennon - March 28, 2012, 7:39 p.m.
Frans,

>Guess we might want to mirror a version and pull from the mirror.

I don't mind putting a mirrow up at the Dynamic Devices wbesite with a
SRC_URI link to it there.

That''s a bit of a patchy solution though isn't it? Ideally (imho) as I 
suggested the
other day there would be an official OE mirror that the standard OE 
framework
fell back to when it couldn't find the primary source material, but then 
somebody
has to pay for that of course :)

>PS: thinking of it: we might be able to resolve the latter issue by

I'm not sure if that would help us though, as (presumably) the point of 
the MD5
is to notify us that "something" is wrong with the file that has been 
pulled down,
whether because it is incomplete or the developers are being naughty.

Cheers,

Alex

On 28/03/2012 09:34, Frans Meulenbroeks wrote:
> 2012/3/28<ajlennon@dynamicdevices.co.uk>:
>> From: Alex J Lennon<ajlennon@gmail.com>
>>
>> Signed-off-by: Alex J Lennon<ajlennon@gmail.com>
>> ---
>>   recipes/libpng/libpng_1.2.48.bb |    4 ++--
>>   1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/recipes/libpng/libpng_1.2.48.bb b/recipes/libpng/libpng_1.2.48.bb
>> index 50a3c03..534962d 100644
>> --- a/recipes/libpng/libpng_1.2.48.bb
>> +++ b/recipes/libpng/libpng_1.2.48.bb
>> @@ -2,5 +2,5 @@ require libpng.inc
>>
>>   PR = "${INC_PR}.0"
>>
>> -SRC_URI[libpng.md5sum] = "7612af5660cd4b5e8c433ce53bea01a7"
>> -SRC_URI[libpng.sha256sum] = "f6db51aff81b6920203678b29e8c68a5e3703cf5b39ae5e9e56370d17f31b1c4"
>> +SRC_URI[libpng.md5sum] = "74c8c261bdf9a75274e22875183fda07"
>> +SRC_URI[libpng.sha256sum] = "b4c92df11eadf3e81705a58253dbffc4b95169186899e28abdfc8aada8a20fcc"
>> --
>> 1.7.5.4
>>
> You mean upstream changed their source tarball (or whatever) without
> updating the version number.
> Yuk.
>
> Guess we might want to mirror a version and pull from the mirror.
> (changing the checksum alone creates issues because other people might
> already have the version with the old checksum in their downloads.
>
> Frans
>
> PS: thinking of it: we might be able to resolve the latter issue by
> forcing the removal of a file from downloads (and trigger a refetch)
> if the .md5 does not match the md5 in the recipe.
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
Paul Eggleton - March 28, 2012, 7:45 p.m.
On Wednesday 28 March 2012 10:34:16 Frans Meulenbroeks wrote:
> PS: thinking of it: we might be able to resolve the latter issue by
> forcing the removal of a file from downloads (and trigger a refetch)
> if the .md5 does not match the md5 in the recipe.

FYI, I'm pretty sure that fetch2 from the version of bitbake we use with OE-
Core will skip to the next available option (mirror) if the downloaded file 
doesn't match the SRC_URI checksum. Of course that's assuming there is a 
mirror available.

Cheers,
Paul
Alex Lennon - March 28, 2012, 7:50 p.m.
Paul,

>FYI, I'm pretty sure that fetch2 from the version of bitbake we use with OE-

I thought it might. Does it still do that if the checksum fails though?

>Of course that's assuming there is a mirror available.

I'm happy to host a 2nd copy and mod the .bb to add another source if 
that helps (the
libpng repo seems to have a history of deleting versions from what I saw 
of the patch
history so it might be a good idea?). Is that ok for everybody?

Cheers,

Alex

On 28/03/2012 20:45, Paul Eggleton wrote:
> On Wednesday 28 March 2012 10:34:16 Frans Meulenbroeks wrote:
>> PS: thinking of it: we might be able to resolve the latter issue by
>> forcing the removal of a file from downloads (and trigger a refetch)
>> if the .md5 does not match the md5 in the recipe.
> FYI, I'm pretty sure that fetch2 from the version of bitbake we use with OE-
> Core will skip to the next available option (mirror) if the downloaded file
> doesn't match the SRC_URI checksum. Of course that's assuming there is a
> mirror available.
>
> Cheers,
> Paul
>
Paul Eggleton - March 28, 2012, 8:32 p.m.
On Wednesday 28 March 2012 20:50:55 Alex J Lennon wrote:
> Paul,
> 
> >FYI, I'm pretty sure that fetch2 from the version of bitbake we use with
> >OE-
> I thought it might. Does it still do that if the checksum fails though?

Yes, I believe (without having tested it recently) that a SRC_URI checksum 
failure is considered in the same way as if the download failed.

> >Of course that's assuming there is a mirror available.
> 
> I'm happy to host a 2nd copy and mod the .bb to add another source if
> that helps (the
> libpng repo seems to have a history of deleting versions from what I saw
> of the patch
> history so it might be a good idea?). Is that ok for everybody?

No harm in it, however I believe it may be better to get it on 
sources.openembedded.org - I think the usual procedure is to ping Tom King 
(ka6sox on IRC) and then send get the files to him so he can upload them there.

Cheers,
Paul
Frans Meulenbroeks - March 28, 2012, 8:38 p.m.
2012/3/28 Alex J Lennon <ajlennon@dynamicdevices.co.uk>:

>> FYI, I'm pretty sure that fetch2 from the version of bitbake we use with
>> OE-
>> Core will skip to the next available option (mirror) if the downloaded
>> file
>> doesn't match the SRC_URI checksum. Of course that's assuming there is a
>> mirror available.

There is an official oe mirror iirc. Not really sure who is exactly
responsible for it. Perhaps khem or kasox6

Frans

Patch

diff --git a/recipes/libpng/libpng_1.2.48.bb b/recipes/libpng/libpng_1.2.48.bb
index 50a3c03..534962d 100644
--- a/recipes/libpng/libpng_1.2.48.bb
+++ b/recipes/libpng/libpng_1.2.48.bb
@@ -2,5 +2,5 @@  require libpng.inc
 
 PR = "${INC_PR}.0"
 
-SRC_URI[libpng.md5sum] = "7612af5660cd4b5e8c433ce53bea01a7"
-SRC_URI[libpng.sha256sum] = "f6db51aff81b6920203678b29e8c68a5e3703cf5b39ae5e9e56370d17f31b1c4"
+SRC_URI[libpng.md5sum] = "74c8c261bdf9a75274e22875183fda07"
+SRC_URI[libpng.sha256sum] = "b4c92df11eadf3e81705a58253dbffc4b95169186899e28abdfc8aada8a20fcc"