Like someone already stated in the stabilization bug 569874 the ebuild has wrong checksum for the bash43-042 file (seems to have been replaced in December 2015 (why?) and checksum seems to be for the old file) Very strange why the stabilization testers didn't notice that. Reproducible: Always Steps to Reproduce: emerge -v bash Download the bash-4.3_p42 from gnu.org and verify checksum ac219322db2791da87a496ee6e8e5544846494bdaaea2626270c2f73c1044919 bash43-042 Actual Results: !!! Fetched file: bash43-042 VERIFY FAILED! !!! Reason: Failed on SHA256 verification !!! Got: ac219322db2791da87a496ee6e8e5544846494bdaaea2626270c2f73c1044919 !!! Expected: b75a53141ab3d8fff3fa74b5f3dc76468b01eae299f50bbc2bc71ae395d690af Expected Results: Corrected checksum in the ebuild manifest.
Created attachment 421856 [details] bash43-042 from GNU ftp server fetched on 04.01.2016
https://lists.gnu.org/archive/html/ftp-upload-report/2015-12/msg00000.html states that the file had been replaced in December, because the old one was corrupted?! Maybe someone should verify the gpg signature whether the file is now really correct.
Diff between the new file and the old one (latter one from a macports mirror) seems that the wrong source file had been given in the old version. the line with "lex_rwlen" is being contained in both patchfiles, it is only shown through unified diff, but is no difference by itself: --- bash43-042 2016-01-04 10:15:58.000000000 +0100 +++ bash43-042a 2016-01-04 11:42:51.000000000 +0100 @@ -27,7 +27,7 @@ + lex_rwlen = 0; } } -*** ../bash-4.3-patched/y.tab.c 2015-05-18 19:27:05.000000000 -0400 +*** ../bash-4.3-patched/parse.y 2015-05-18 19:27:05.000000000 -0400 --- y.tab.c 2015-06-29 10:59:27.000000000 -0400 *************** *** 6021,6024 **** 30c30 < *** ../bash-4.3-patched/y.tab.c 2015-05-18 19:27:05.000000000 -0400 --- > *** ../bash-4.3-patched/parse.y 2015-05-18 19:27:05.000000000 -0400
Created attachment 421860 [details] Old version of the file fetched from a macports mirror
commit 2c7fab566eb4a711c7b8359ee81ba194e5d79bf8 Author: Lars Wendler <polynomial-c@gentoo.org> Date: Mon Jan 4 13:37:15 2016 app-shells/bash: Revbump to apply correct 042 patch (bug #570820). Committed straight to stable where -r0 was stable. Package-Manager: portage-2.2.26 RepoMan-Options: --force Signed-off-by: Lars Wendler <polynomial-c@gentoo.org>
I am still getting bash43-042 with the previous checksum from tux.rainside.sk: curl -s http://tux.rainside.sk/gentoo//distfiles/bash43-042 | sha256sum b75a53141ab3d8fff3fa74b5f3dc76468b01eae299f50bbc2bc71ae395d690af -
Created attachment 422282 [details] Result of sha check of http mirrors
(In reply to Kamil Dudka from comment #6) > I am still getting bash43-042 with the previous checksum from tux.rainside.sk I've checked and it seems *ALL* of http mirrors still have the file with that checksum. curl -s https://www.gentoo.org/downloads/mirrors/ | grep -oe "\"http://[^\"]*\"" | sed -e s/\"//g | while read -r l; do echo $l; curl -sL "$l/distfiles/bash43-042" | sha256sum; done Someone should do something about this.
Changing status back to unconfirmed in hope to reopen the bug by doing so. Current situation: Upstream on the GNU ftp server there is the new version of the bash43-042 file with the new checksum. On the Gentoo distfile mirror's there seems to be still the old version. As the by me used distfile mirror was unreachable, Gentoo fetched the file directly from the GNU ftp server for me and thus I had the checksum problem. For all others with working Gentoo distfile mirrors the checksum is now broken, because they seem to contain the old version of the file (that seems to be the reason why the arch testers didn't notice that the checksum is wrong, because they got the old file). So it seems that the copy on the Gentoo distfile server has to be updated (I don't have write access there).
Just noticed that bug 571286 deals with the missing sync of the mirrors, so closing this bug as the checksum would be correct for the upstream version now and the sync issue will be probably handled via the other bug.
*** Bug 571286 has been marked as a duplicate of this bug. ***
(In reply to Huemi from comment #10) > closing this bug as the checksum would be correct for the upstream version > now and the sync issue will be probably handled via the other bug. Ahem. The other bug just got closed as a duplicate of this bug. I think reopening this bug is in order.
(In reply to Alex Belykh from comment #12) > (In reply to Huemi from comment #10) > > closing this bug as the checksum would be correct for the upstream version > > now and the sync issue will be probably handled via the other bug. > Ahem. The other bug just got closed as a duplicate of this bug. I think > reopening this bug is in order. The other bug has been reopened by Mike Gilbert from the Gentoo dev team and been changed from duplicate to confirmed, so I leave this bug closed and let them handle the mirroring issue in the other bug as it explicitly mentions that it is about having an old copy of the file on the mirrors.