boost: fix the SRC_URI to point to an actual release, and not a master snapshot
PATCH 1/1 boost: fix the SRC_URI to point to an actual release, and not a master snapshot
Sourceforge does a not-so-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]
Also, boost developers are naming their snapshot tarballs the same as release tarballs. The two things conspired together.
The new tarball does have the same checksum as the one in release announcement, so we should be good now:
http://lists.boost.org/Archives/boost/2016/09/230886.php
--- meta/recipes-support/boost/boost-1.62.0.inc | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
meta/recipes-support/boost/boost-1.62.0.inc +5 -3
@@ -11,9 +11,11 @@ BOOST_VER = "${@"_".join(d.getVar("PV", True).split("."))}" BOOST_MAJ = "${@"_".join(d.getVar("PV", True).split(".")[0:2])}" BOOST_P = "boost_${BOOST_VER}" -SRC_URI = "${SOURCEFORGE_MIRROR}/boost/${BOOST_P}.tar.bz2" +SRC_URI = "${SOURCEFORGE_MIRROR}/project/boost/boost/${PV}/${BOOST_P}.tar.bz2" -SRC_URI[md5sum] = "7ef085456c48c49a7fe8237f07e5f674" -SRC_URI[sha256sum] = "bce80293052e2d6230f1bec9b7524b33412e4fb26e9723460a0f362ac15b7acb" +SRC_URI[md5sum] = "5fb94629535c19e48703bdb2b2e9490f" +SRC_URI[sha256sum] = "36c96b0f6155c98404091d8ceb48319a28279ca0333fba1ad8611eb90afb2ca0" + +PR = "r1" S = "${WORKDIR}/${BOOST_P}"
Signature · 1 line
2.9.3
Hello Alexander,
Quoted 25 lines · Alexander Kanavin
Sourceforge does a not-so-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]Also, boost developers are naming their snapshot tarballs the same as release tarballs. The two things conspired together.
The new tarball does have the same checksum as the one in release announcement, so we should be good now:
http://lists.boost.org/Archives/boost/2016/09/230886.php
Signed-off-by Alexander Kanavin <[email protected]>--- meta/recipes-support/boost/boost-1.62.0.inc | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)meta/recipes-support/boost/boost-1.62.0.inc +0
-0@@ -11,9 +11,11 @@ BOOST_VER = "${@"_".join(d.getVar("PV", True).split("."))}" BOOST_MAJ = "${@"_".join(d.getVar("PV", True).split(".")[0:2])}" BOOST_P = "boost_${BOOST_VER}"
meta/recipes-support/boost/boost-1.62.0.inc BOOST_VER = "${@"_".join(d.getVar("PV", True).split("."))}" · line 19
Quoted 10 lines
meta/recipes-support/boost/boost-1.62.0.inc +5
-3-SRC_URI = "${SOURCEFORGE_MIRROR}/boost/${BOOST_P}.tar.bz2" +SRC_URI = "${SOURCEFORGE_MIRROR}/project/boost/boost/${PV}/${BOOST_P}.tar.bz2" -SRC_URI[md5sum] = "7ef085456c48c49a7fe8237f07e5f674" -SRC_URI[sha256sum] = "bce80293052e2d6230f1bec9b7524b33412e4fb26e9723460a0f362ac15b7acb" +SRC_URI[md5sum] = "5fb94629535c19e48703bdb2b2e9490f" +SRC_URI[sha256sum] = "36c96b0f6155c98404091d8ceb48319a28279ca0333fba1ad8611eb90afb2ca0" + +PR = "r1"
doesn't the changed SRC_URI (or even the modified checksums alone) render the PR bump unnecessary?
Regards,
Andreas
Quoted 12 lines · Andreas Oberritter
meta/recipes-support/boost/boost-1.62.0.inc BOOST_VER = "${@"_".join(d.getVar("PV", True).split("."))}" · line 19
Quoted 9 lines
meta/recipes-support/boost/boost-1.62.0.inc +5
-3-SRC_URI = "${SOURCEFORGE_MIRROR}/boost/${BOOST_P}.tar.bz2" +SRC_URI = "${SOURCEFORGE_MIRROR}/project/boost/boost/${PV}/${BOOST_P}.tar.bz2" -SRC_URI[md5sum] = "7ef085456c48c49a7fe8237f07e5f674" -SRC_URI[sha256sum] = "bce80293052e2d6230f1bec9b7524b33412e4fb26e9723460a0f362ac15b7acb" +SRC_URI[md5sum] = "5fb94629535c19e48703bdb2b2e9490f" +SRC_URI[sha256sum] = "36c96b0f6155c98404091d8ceb48319a28279ca0333fba1ad8611eb90afb2ca0" + +PR = "r1"doesn't the changed
SRC_URI(or even the modified checksums alone) render the PR bump unnecessary?
Frankly I'm not sure, but I thought bumping PR ensures that anyone using package feeds will get an updated package.
Alex