catalyst fails to build stage1 using portage-20121002 snapshot. portage-20121001 was OK. I think this is due to this change: 02 Oct 2012; Fabian Groffen <grobian@gentoo.org> libffi-3.0.11.ebuild: Fix non-fatal typo effectively disabling the link-check Part of the error log: >>> Failed to emerge dev-libs/libffi-3.0.11 for /tmp/stage1root/, Log file: >>> '/var/tmp/portage/dev-libs/libffi-3.0.11/temp/build.log' * Package: dev-libs/libffi-3.0.11 * Repository: gentoo * Maintainer: toolchain@gentoo.org * USE: build elibc_glibc kernel_linux userland_GNU x86 * FEATURES: sandbox * The linker reported linking against -lffi to be working while it shouldn't have. * This is wrong and you should find and delete the old copy of libffi before continuing. * ERROR: dev-libs/libffi-3.0.11 failed (setup phase): * The system is in inconsistent state with unknown libffi installed. * * Call stack: * ebuild.sh, line 85: Called pkg_setup * libffi-3.0.11.ebuild, line 36: Called die * The specific snippet of code: * die "The system is in inconsistent state with unknown libffi installed." * * If you need support, post the output of `emerge --info '=dev-libs/libffi-3.0.11'`, * the complete build log and the output of `emerge -pqv '=dev-libs/libffi-3.0.11'`. * The complete build log is located at '/var/tmp/portage/dev-libs/libffi-3.0.11/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/dev-libs/libffi-3.0.11/temp/die.env'. * Working directory: '/var/tmp/portage/dev-libs/libffi-3.0.11' * S: '/var/tmp/portage/dev-libs/libffi-3.0.11/work/libffi-3.0.11' Reproducible: Always
I've tried different seed stages with the same result: official stage3 and stage3 which I build from 20121001 snapshot. Archs: x86 and amd64.
Same on arm. I believe it's down to yesterday's change: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-libs/libffi/libffi-3.0.11.ebuild?r1=1.12&r2=1.13
The simplest solution is to add "build" USE flag to libffi ebuild that disables this link-check.
(In reply to comment #3) > The simplest solution is to add "build" USE flag to libffi ebuild that > disables this link-check. But there is a chance that other stages will fail. =/
Question is, why in stage building the sys-devel/gcc package installs libffi to the filesystem? It shouldn't be required to be installed Therefore "the link sanity check" should pass also during stage building...
(In reply to comment #5) > Question is, why in stage building the sys-devel/gcc package installs libffi > to the filesystem? It shouldn't be required to be installed > Therefore "the link sanity check" should pass also during stage building... This code is in eclass/toolchain.eclass: <quote> # Prevent libffi from being installed sed -i -e 's/\(install.*:\) install-.*recursive/\1/' "${S}"/libffi/Makefile.in sed -i -e 's/\(install-data-am:\).*/\1/' "${S}"/libffi/include/Makefile.in </quote>
(In reply to comment #5) > Question is, why in stage building the sys-devel/gcc package installs libffi > to the filesystem? It shouldn't be required to be installed > Therefore "the link sanity check" should pass also during stage building... gcc doesn't install libffi. Furthermore in stage1 building libffi is installed before gcc. While building stage1 catalyst installs all packages in /tmp/stage1root inside chroot by setting ROOT variable. So has_version() fails but linking with libffi does not (because it is available in stage3).
@grobian / @toolchain: The change to libffi is breaking stage building. Can we get a revert or an update to ensure stages are able to build?
I just fixed a syntax error that prevented the check being run.
Created attachment 325602 [details, diff] USE=build? I'm not sure why libffi is installed from sys-devel/gcc during stage building, why isn't the code from toolchain.eclass executed to prevent it? So this is ugly workaround and propably not suitable for tree inclusion
(In reply to comment #10) > So this is ugly workaround and propably not suitable for tree inclusion or is it? after reading Comment #7 this seems reasonable :o
(In reply to comment #10) > Created attachment 325602 [details, diff] [details, diff] > USE=build? > I've already started to test the same patch one hour ago =P.
(In reply to comment #10) how about checking ROOT==/ also, that link test should use CFLAGS/LDFLAGS too ...
(In reply to comment #13) > (In reply to comment #10) > > how about checking ROOT==/ > This would be better. Not only catalyst will be able to do this: gentoo ~ # mkdir /tmp/testroot gentoo ~ # ROOT=/tmp/testroot emerge -1q libffi * IMPORTANT: 1 news items need reading for repository 'gentoo'. * Use eselect news to read news items. >>> Verifying ebuild manifests >>> Emerging (1 of 1) dev-libs/libffi-3.0.11 for /tmp/testroot/ >>> Failed to emerge dev-libs/libffi-3.0.11 for /tmp/testroot/, Log file: >>> '/var/tmp/portage/dev-libs/libffi-3.0.11/temp/build.log' * Package: dev-libs/libffi-3.0.11 * Repository: gentoo * Maintainer: toolchain@gentoo.org * USE: amd64 elibc_glibc kernel_linux multilib userland_GNU * FEATURES: sandbox userpriv usersandbox * The linker reported linking against -lffi to be working while it shouldn't have. * This is wrong and you should find and delete the old copy of libffi before continuing. * ERROR: dev-libs/libffi-3.0.11 failed (setup phase): * The system is in inconsistent state with unknown libffi installed. * * Call stack: * ebuild.sh, line 85: Called pkg_setup * libffi-3.0.11.ebuild, line 36: Called die * The specific snippet of code: * die "The system is in inconsistent state with unknown libffi installed." * * If you need support, post the output of `emerge --info '=dev-libs/libffi-3.0.11'`, * the complete build log and the output of `emerge -pqv '=dev-libs/libffi-3.0.11'`. * The complete build log is located at '/var/tmp/portage/dev-libs/libffi-3.0.11/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/dev-libs/libffi-3.0.11/temp/die.env'. * Working directory: '/var/tmp/portage/dev-libs/libffi-3.0.11' * S: '/var/tmp/portage/dev-libs/libffi-3.0.11/work/libffi-3.0.11'
*** Bug 437132 has been marked as a duplicate of this bug. ***
(In reply to comment #13) > (In reply to comment #10) > how about checking ROOT==/ Good idea + 04 Oct 2012; Samuli Suominen <ssuominen@gentoo.org> libffi-3.0.11.ebuild: + Check if ${ROOT} is / or not before executing the -lffi sanity link check wrt + #437046 http://sources.gentoo.org/viewvc.cgi/gentoo-x86/dev-libs/libffi/ChangeLog?r1=1.154&r2=1.155 > > also, that link test should use CFLAGS/LDFLAGS too ... I left them out in purpose, what possible cause could they serve when all we want to know is if -lffi is linkable or not... (and write it in the build.log so us, maintainers, will save a lot of time figuring out lib vs. headers conflicts)
(In reply to comment #16) > (In reply to comment #13) > > (In reply to comment #10) > > how about checking ROOT==/ > > Good idea > > + 04 Oct 2012; Samuli Suominen <ssuominen@gentoo.org> libffi-3.0.11.ebuild: > + Check if ${ROOT} is / or not before executing the -lffi sanity link check > wrt > + #437046 > This expression is invalid: if [[ ${ROOT} != / ]] || ! has_version ${CATEGORY}/${PN}; then should be: if [[ ${ROOT} == / ]] && ! has_version ${CATEGORY}/${PN}; then
(In reply to comment #17) > (In reply to comment #16) > > (In reply to comment #13) > > > (In reply to comment #10) > > > how about checking ROOT==/ > > > > Good idea > > > > + 04 Oct 2012; Samuli Suominen <ssuominen@gentoo.org> libffi-3.0.11.ebuild: > > + Check if ${ROOT} is / or not before executing the -lffi sanity link check > > wrt > > + #437046 > > > > This expression is invalid: > > if [[ ${ROOT} != / ]] || ! has_version ${CATEGORY}/${PN}; then > > should be: > > if [[ ${ROOT} == / ]] && ! has_version ${CATEGORY}/${PN}; then why? looks proper to me. the exit code for [[ ${ROOT} != / ]] is either 0 with success, or 1 with failure then || will enter the next piece of code depending on anything else than 0 closing again...
> why? looks proper to me. the exit code for [[ ${ROOT} != / ]] is either 0 > with success, or 1 with failure > then || will enter the next piece of code depending on anything else than 0 > > closing again... This link check should run _ONLY_ if ROOT == / _AND_ if there is no libffi installed. You can also test the change your are made as described in comment 14. It still fails.
(In reply to comment #19) > > why? looks proper to me. the exit code for [[ ${ROOT} != / ]] is either 0 > > with success, or 1 with failure > > then || will enter the next piece of code depending on anything else than 0 > > > > closing again... > > This link check should run _ONLY_ if ROOT == / _AND_ if there is no libffi > installed. You can also test the change your are made as described in > comment 14. It still fails. that's what it does now. return 0 from first check only if / is not ${ROOT} and then || won't pass it along as 0 equals true... could test it all day and it still keeps working...
(In reply to comment #20) > (In reply to comment #19) > > > why? looks proper to me. the exit code for [[ ${ROOT} != / ]] is either 0 > > > with success, or 1 with failure > > > then || will enter the next piece of code depending on anything else than 0 > > > > > > closing again... > > > > This link check should run _ONLY_ if ROOT == / _AND_ if there is no libffi > > installed. You can also test the change your are made as described in > > comment 14. It still fails. > > that's what it does now. return 0 from first check only if / is not ${ROOT} > and then || won't pass it along as 0 equals true... > could test it all day and it still keeps working... # if true || true; then echo 1; fi 1 # if true || false; then echo 1; fi 1 # if false || true; then echo 1; fi 1 # if false || false; then echo 1; fi #
(In reply to comment #21) > (In reply to comment #20) > > (In reply to comment #19) > > > > why? looks proper to me. the exit code for [[ ${ROOT} != / ]] is either 0 > > > > with success, or 1 with failure > > > > then || will enter the next piece of code depending on anything else than 0 > > > > > > > > closing again... > > > > > > This link check should run _ONLY_ if ROOT == / _AND_ if there is no libffi > > > installed. You can also test the change your are made as described in > > > comment 14. It still fails. > > > > that's what it does now. return 0 from first check only if / is not ${ROOT} > > and then || won't pass it along as 0 equals true... > > could test it all day and it still keeps working... > > # if true || true; then echo 1; fi > 1 > # if true || false; then echo 1; fi > 1 > # if false || true; then echo 1; fi > 1 > # if false || false; then echo 1; fi > # $ export ROOT=/ $ [[ ${ROOT} != / ]] || echo "Entering has_version check..." Entering has_version check... $ export ROOT=/test $ [[ ${ROOT} != / ]] || echo "Entering has_version check..." ssuominen@null ~ $ export ROOT=/ ssuominen@null ~ $ [[ ${ROOT} != / ]] || false ssuominen@null ~ $ echo $? 1 ssuominen@null ~ $ [[ ${ROOT} != / ]] || true ssuominen@null ~ $ echo $? 0 The logic still looks solid to me.
The current check runs the has_version test for ROOT != /, which means that one can return true, and hence the entire expression return true, which is not what you wanted. Hence Alexander turned it around, so you a) benefit from the shortcut operator &&, and b) ensure you never run the check when ROOT != /.
the check added started to break stages!
(In reply to comment #23) > The current check runs the has_version test for ROOT != /, which means that > one can return true, and hence the entire expression return true, which is > not what you wanted. Hence Alexander turned it around, so you a) benefit > from the shortcut operator &&, and b) ensure you never run the check when > ROOT != /. right. i'm in need of more coffee I suppose ;) changed it in tree...
* Package: dev-libs/libffi-3.0.11 * Repository: gentoo * Maintainer: toolchain@gentoo.org * USE: bindist build elibc_glibc kernel_linux userland_GNU x86 * FEATURES: preserve-libs * The linker reported linking against -lffi to be working while it shouldn't have. * This is wrong and you should find and delete the old copy of libffi before continuing. * ERROR: dev-libs/libffi-3.0.11 failed (setup phase): * The system is in inconsistent state with unknown libffi installed. * * Call stack: * ebuild.sh, line 85: Called pkg_setup * libffi-3.0.11.ebuild, line 36: Called die * The specific snippet of code: * die "The system is in inconsistent state with unknown libffi installed." * * If you need support, post the output of `emerge --info '=dev-libs/libffi-3.0.11'`, * the complete build log and the output of `emerge -pqv '=dev-libs/libffi-3.0.11'`. * The complete build log is located at '/var/tmp/portage/dev-libs/libffi-3.0.11/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/dev-libs/libffi-3.0.11/temp/die.env'. * Working directory: '/var/tmp/portage/dev-libs/libffi-3.0.11' * S: '/var/tmp/portage/dev-libs/libffi-3.0.11/work/libffi-3.0.11' this doesn't happen without check in ebuild
(In reply to comment #26) Read the bug. You just duplicated Comment #0, that's all.
i don't know what i duplicated, your changes to libffi with ROOT check just started to break stage1 builds. Reverting it back fixed.
(In reply to comment #28) > i don't know what i duplicated, your changes to libffi with ROOT check just > started to break stage1 builds. Reverting it back fixed. $ grep Header libffi-3.0.11.ebuild # $Header: /var/cvsroot/gentoo-x86/dev-libs/libffi/libffi-3.0.11.ebuild,v 1.16 2012/10/04 11:17:21 working with out of date tree?
there should be "/" in check? Anyway such things supposed to be controlled by gentoo-releng, libffi known to make problems with updates. So before stabilization, stages should be successfully built.
(In reply to comment #30) > there should be "/" in check? > Anyway such things supposed to be controlled by gentoo-releng, libffi known > to make problems with updates. So before stabilization, stages should be > successfully built. This was neither update nor stabilization. Read this discussion, please.
