diff mbox

boost: Fix SRC_URI checksums

Message ID 20161029194615.19954-1-raj.khem@gmail.com
State New
Headers show

Commit Message

Khem Raj Oct. 29, 2016, 7:46 p.m. UTC
Signed-off-by: Khem Raj <raj.khem@gmail.com>

---
 meta/recipes-support/boost/boost-1.62.0.inc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

-- 
2.10.1

-- 
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Comments

Richard Purdie Oct. 30, 2016, 4:40 p.m. UTC | #1
On Sat, 2016-10-29 at 12:46 -0700, Khem Raj wrote:
> Signed-off-by: Khem Raj <raj.khem@gmail.com>

Why, what happened?

Cheers,

Richard


> ---
>  meta/recipes-support/boost/boost-1.62.0.inc | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/recipes-support/boost/boost-1.62.0.inc
> b/meta/recipes-support/boost/boost-1.62.0.inc
> index a097ea1..1144ac9 100644
> --- a/meta/recipes-support/boost/boost-1.62.0.inc
> +++ b/meta/recipes-support/boost/boost-1.62.0.inc
> @@ -13,7 +13,7 @@ BOOST_P = "boost_${BOOST_VER}"
>  
>  SRC_URI = "${SOURCEFORGE_MIRROR}/boost/${BOOST_P}.tar.bz2"
>  
> -SRC_URI[md5sum] = "7ef085456c48c49a7fe8237f07e5f674"
> -SRC_URI[sha256sum] =
> "bce80293052e2d6230f1bec9b7524b33412e4fb26e9723460a0f362ac15b7acb"
> +SRC_URI[md5sum] = "21b799e5d35ba2beef75b225deaf199a"
> +SRC_URI[sha256sum] =
> "a715dc2adff2d451719352b1e863d78cbb100a03f7ed76097c89b9016c59091e"
>  
>  S = "${WORKDIR}/${BOOST_P}"
> -- 
> 2.10.1
>
Khem Raj Oct. 30, 2016, 5:39 p.m. UTC | #2
On Sun, Oct 30, 2016 at 9:40 AM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Sat, 2016-10-29 at 12:46 -0700, Khem Raj wrote:

>> Signed-off-by: Khem Raj <raj.khem@gmail.com>

>

> Why, what happened?


I haven't checked in detail but after the recent master commits my
builds started to fail with checksum errors.
since it was happening on two different machines I though it might
have been over sight.
>

> Cheers,

>

> Richard

>

>

>> ---

>>  meta/recipes-support/boost/boost-1.62.0.inc | 4 ++--

>>  1 file changed, 2 insertions(+), 2 deletions(-)

>>

>> diff --git a/meta/recipes-support/boost/boost-1.62.0.inc

>> b/meta/recipes-support/boost/boost-1.62.0.inc

>> index a097ea1..1144ac9 100644

>> --- a/meta/recipes-support/boost/boost-1.62.0.inc

>> +++ b/meta/recipes-support/boost/boost-1.62.0.inc

>> @@ -13,7 +13,7 @@ BOOST_P = "boost_${BOOST_VER}"

>>

>>  SRC_URI = "${SOURCEFORGE_MIRROR}/boost/${BOOST_P}.tar.bz2"

>>

>> -SRC_URI[md5sum] = "7ef085456c48c49a7fe8237f07e5f674"

>> -SRC_URI[sha256sum] =

>> "bce80293052e2d6230f1bec9b7524b33412e4fb26e9723460a0f362ac15b7acb"

>> +SRC_URI[md5sum] = "21b799e5d35ba2beef75b225deaf199a"

>> +SRC_URI[sha256sum] =

>> "a715dc2adff2d451719352b1e863d78cbb100a03f7ed76097c89b9016c59091e"

>>

>>  S = "${WORKDIR}/${BOOST_P}"

>> --

>> 2.10.1

>>

-- 
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Paul Eggleton Oct. 31, 2016, 3:27 a.m. UTC | #3
On Sun, 30 Oct 2016 10:39:34 Khem Raj wrote:
> On Sun, Oct 30, 2016 at 9:40 AM, Richard Purdie

> <richard.purdie@linuxfoundation.org> wrote:

> > On Sat, 2016-10-29 at 12:46 -0700, Khem Raj wrote:

> >> Signed-off-by: Khem Raj <raj.khem@gmail.com>

> > 

> > Why, what happened?

> 

> I haven't checked in detail but after the recent master commits my

> builds started to fail with checksum errors.

> since it was happening on two different machines I though it might

> have been over sight.


We need to be extremely cautious changing the SRC_URI checksums when there's a 
mismatch, otherwise we might as well not have them at all. The SRC_URI 
checksums definitely were changed when the last update was done, so this 
doesn't appear to be a case where they accidentally weren't updated.

Alex, any idea what's happened here? Do you have the originals from when you 
did the upgrade?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Paul Eggleton Oct. 31, 2016, 3:45 a.m. UTC | #4
On Mon, 31 Oct 2016 16:27:15 Paul Eggleton wrote:
> On Sun, 30 Oct 2016 10:39:34 Khem Raj wrote:

> > On Sun, Oct 30, 2016 at 9:40 AM, Richard Purdie

> > <richard.purdie@linuxfoundation.org> wrote:

> > > On Sat, 2016-10-29 at 12:46 -0700, Khem Raj wrote:

> > >> Signed-off-by: Khem Raj <raj.khem@gmail.com>

> > > 

> > > Why, what happened?

> > 

> > I haven't checked in detail but after the recent master commits my

> > builds started to fail with checksum errors.

> > since it was happening on two different machines I though it might

> > have been over sight.

> 

> We need to be extremely cautious changing the SRC_URI checksums when there's

> a mismatch, otherwise we might as well not have them at all. The SRC_URI

> checksums definitely were changed when the last update was done, so this

> doesn't appear to be a case where they accidentally weren't updated.

> 

> Alex, any idea what's happened here? Do you have the originals from when you

> did the upgrade?


Hmm, it seems we aren't the only ones to have hit this:

  http://osdir.com/ml/blfs-dev/2016-10/msg00013.html

That said, I still don't think we should blindly trust the latest archives 
until we're sure of what the differences are.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Alexander Kanavin Oct. 31, 2016, 12:53 p.m. UTC | #5
On 10/31/2016 05:45 AM, Paul Eggleton wrote:
>> Alex, any idea what's happened here? Do you have the originals from when you

>> did the upgrade?

>

> Hmm, it seems we aren't the only ones to have hit this:

>

>   http://osdir.com/ml/blfs-dev/2016-10/msg00013.html

>

> That said, I still don't think we should blindly trust the latest archives

> until we're sure of what the differences are.


Sourceforge is doing too-clever redirecting that fails miserably here:

Proxy request sent, awaiting response... 301 Moved Permanently
Location: 
http://downloads.sourceforge.net/project/boost/boost/snapshots/master/boost_1_62_0.tar.bz2 
[following]

So we've been fetching a moving master snapshot all along. Patch is 
coming shortly.

Alex

-- 
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Khem Raj Oct. 31, 2016, 4:22 p.m. UTC | #6
> On Oct 31, 2016, at 5:53 AM, Alexander Kanavin <alexander.kanavin@linux.intel.com> wrote:

> 

> On 10/31/2016 05:45 AM, Paul Eggleton wrote:

>>> Alex, any idea what's happened here? Do you have the originals from when you

>>> did the upgrade?

>> 

>> Hmm, it seems we aren't the only ones to have hit this:

>> 

>>  http://osdir.com/ml/blfs-dev/2016-10/msg00013.html

>> 

>> That said, I still don't think we should blindly trust the latest archives

>> until we're sure of what the differences are.

> 

> Sourceforge is doing too-clever redirecting that fails miserably here:

> 

> Proxy request sent, awaiting response... 301 Moved Permanently

> Location: http://downloads.sourceforge.net/project/boost/boost/snapshots/master/boost_1_62_0.tar.bz2 [following]

> 

> So we've been fetching a moving master snapshot all along. Patch is coming shortly.


we should specify boost/boost/1.62.0/boost_1_62_0.tar.bz2 instead of boost/boost/boost_1_62_0.tar.bz2

> 

> Alex

>
-- 
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Alexander Kanavin Nov. 1, 2016, 12:40 p.m. UTC | #7
On 10/31/2016 06:22 PM, Khem Raj wrote:

>> Sourceforge is doing too-clever redirecting that fails miserably here:

>>

>> Proxy request sent, awaiting response... 301 Moved Permanently

>> Location: http://downloads.sourceforge.net/project/boost/boost/snapshots/master/boost_1_62_0.tar.bz2 [following]

>>

>> So we've been fetching a moving master snapshot all along. Patch is coming shortly.

>

> we should specify boost/boost/1.62.0/boost_1_62_0.tar.bz2 instead of boost/boost/boost_1_62_0.tar.bz2


Incorrect. That will still download a master snapshot tarball. Only if 
the 'project/' is prefixed, SF will give you the release tarball.


Alex

-- 
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Khem Raj Nov. 1, 2016, 4:06 p.m. UTC | #8
> On Nov 1, 2016, at 5:40 AM, Alexander Kanavin <alexander.kanavin@linux.intel.com> wrote:

> 

> On 10/31/2016 06:22 PM, Khem Raj wrote:

> 

>>> Sourceforge is doing too-clever redirecting that fails miserably here:

>>> 

>>> Proxy request sent, awaiting response... 301 Moved Permanently

>>> Location: http://downloads.sourceforge.net/project/boost/boost/snapshots/master/boost_1_62_0.tar.bz2 [following]

>>> 

>>> So we've been fetching a moving master snapshot all along. Patch is coming shortly.

>> 

>> we should specify boost/boost/1.62.0/boost_1_62_0.tar.bz2 instead of boost/boost/boost_1_62_0.tar.bz2

> 

> Incorrect. That will still download a master snapshot tarball. Only if the 'project/' is prefixed, SF will give you the release tarball.


if we need projects/ then it should be encoded into SOURCEFORGE_MIRROR variable in bitbake.conf. Since that required for
every sf.net project.

> 

> 

> Alex

>
-- 
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Alexander Kanavin Nov. 1, 2016, 4:33 p.m. UTC | #9
On 11/01/2016 06:06 PM, Khem Raj wrote:

>>> we should specify boost/boost/1.62.0/boost_1_62_0.tar.bz2 instead of boost/boost/boost_1_62_0.tar.bz2

>>

>> Incorrect. That will still download a master snapshot tarball. Only if the 'project/' is prefixed, SF will give you the release tarball.

>

> if we need projects/ then it should be encoded into SOURCEFORGE_MIRROR variable in bitbake.conf. Since that required for

> every sf.net project.


Would you then also fix the remaining recipe-specific part of the URI in 
all those recipes? I don't have the bandwidth for that right now, and 
it's a problem that is unlikely to happen in other recipes.

Alex

-- 
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Khem Raj Nov. 1, 2016, 4:45 p.m. UTC | #10
> On Nov 1, 2016, at 9:33 AM, Alexander Kanavin <alexander.kanavin@linux.intel.com> wrote:

> 

> On 11/01/2016 06:06 PM, Khem Raj wrote:

> 

>>>> we should specify boost/boost/1.62.0/boost_1_62_0.tar.bz2 instead of boost/boost/boost_1_62_0.tar.bz2

>>> 

>>> Incorrect. That will still download a master snapshot tarball. Only if the 'project/' is prefixed, SF will give you the release tarball.

>> 

>> if we need projects/ then it should be encoded into SOURCEFORGE_MIRROR variable in bitbake.conf. Since that required for

>> every sf.net project.

> 

> Would you then also fix the remaining recipe-specific part of the URI in all those recipes? I don't have the bandwidth for that right now, and it's a problem that is unlikely to happen in other recipes.

> 


I wonder if same problem would not happen for other sf.net packages.
probably we never run into it probably because it gets backed up on yp download mirror
and then used. I am not expecting you to fix it, don't worry.
-- 
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Paul Eggleton Nov. 2, 2016, 2:43 a.m. UTC | #11
On Tue, 01 Nov 2016 09:45:48 Khem Raj wrote:
> > On Nov 1, 2016, at 9:33 AM, Alexander Kanavin

> > <alexander.kanavin@linux.intel.com> wrote:> 

> > On 11/01/2016 06:06 PM, Khem Raj wrote:

> >>>> we should specify boost/boost/1.62.0/boost_1_62_0.tar.bz2 instead of

> >>>> boost/boost/boost_1_62_0.tar.bz2>>> 

> >>> Incorrect. That will still download a master snapshot tarball. Only if

> >>> the 'project/' is prefixed, SF will give you the release tarball.>> 

> >> if we need projects/ then it should be encoded into SOURCEFORGE_MIRROR

> >> variable in bitbake.conf. Since that required for every sf.net project.

> > 

> > Would you then also fix the remaining recipe-specific part of the URI in

> > all those recipes? I don't have the bandwidth for that right now, and

> > it's a problem that is unlikely to happen in other recipes.

>

> I wonder if same problem would not happen for other sf.net packages.

> probably we never run into it probably because it gets backed up on yp

> download mirror and then used. I am not expecting you to fix it, don't

> worry.


I think it's less likely to happen elsewhere because most projects don't 
release snapshot tarballs with the exact same name as the latest stable 
release ones. Someone really ought to explain to the boost folks why that is a 
bad idea.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
-- 
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
diff mbox

Patch

diff --git a/meta/recipes-support/boost/boost-1.62.0.inc b/meta/recipes-support/boost/boost-1.62.0.inc
index a097ea1..1144ac9 100644
--- a/meta/recipes-support/boost/boost-1.62.0.inc
+++ b/meta/recipes-support/boost/boost-1.62.0.inc
@@ -13,7 +13,7 @@  BOOST_P = "boost_${BOOST_VER}"
 
 SRC_URI = "${SOURCEFORGE_MIRROR}/boost/${BOOST_P}.tar.bz2"
 
-SRC_URI[md5sum] = "7ef085456c48c49a7fe8237f07e5f674"
-SRC_URI[sha256sum] = "bce80293052e2d6230f1bec9b7524b33412e4fb26e9723460a0f362ac15b7acb"
+SRC_URI[md5sum] = "21b799e5d35ba2beef75b225deaf199a"
+SRC_URI[sha256sum] = "a715dc2adff2d451719352b1e863d78cbb100a03f7ed76097c89b9016c59091e"
 
 S = "${WORKDIR}/${BOOST_P}"