| 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
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.
>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
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
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, >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 >
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
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"