hugin was built on other machine and now it fails to install from binary (emerge -g) on other. >>> Installing (1 of 1) media-gfx/hugin-2009.4.0 * checking 627 files for package collisions /mnt/g/portage/media-gfx/hugin-2009.4.0/temp/environment: line 149: syntax error near unexpected token `(' /mnt/g/portage/media-gfx/hugin-2009.4.0/temp/environment: line 149: ` [[ ${r} -eq ${2} ]] || echo "FAIL: ${@} (got ${r} exp ${2})"' * * ERROR: media-gfx/hugin-2009.4.0 failed. Reproducible: Always
What versions of bash are on both machines?
Please attach the environment file.
Created attachment 213361 [details] emerge --info app-shells/bash: 4.0_p35 both machines are identical except kernel versions and some desktop software.
Created attachment 213362 [details] hugin-2009.4.0/temp/environment
Your environment file contains this corrupt line which seems to trigger the problem: mycmakeargs=([0]="-DENABLE_lapack=OFF Maybe it was a bug in cmake-utils.eclass that's been fixed. If I try to reproduce it now, the mycmakeargs is a normal space-separated string rather than an array. Adding the kde herd to CC since they might know how this happened.
Now I see that enable_cmake-utils_src_configure() converts mycmakeargs to an array. This can cause problems with <=portage-2.1.6.x since those versions don't preserve arrays correctly.
It was introduced in this commit on Dec 10: http://sources.gentoo.org/viewcvs.py/gentoo-x86/eclass/cmake-utils.eclass?r1=1.34&r2=1.35
I've updated the eclass to us a local variable for the mycmakeargs array, so it works with <=portage-2.1.6.x if the global mycmakeargs variable is not an array. However, it's still broken with <=portage-2.1.6.x if mycmakeargs happens to be a global array.
Did emerge --sync; recompiled hugin and now emerge -vg hugin works fine :)
Hi all, I think I have this problem with portage-2.2_rc61 too. Today I have compiled KDE SC 4.3.5 and my ~/.kde4.3 directory was ignored by KDE after relogin, in fact KDE is using ~/.kde instead. I did some debugging and it seems these lines in kde4-base_src_configure function in kde4-base.eclass are the culprit: if [[ $(declare -p mycmakeargs 2>&-) != "declare -a mycmakeargs="* ]]; then mycmakeargs=(${mycmakeargs}) fi commenting those lines makes kdelibs use ~/.kde4.3 as KDEHOME again. Those lines are overriding mycmakeargs when they must not do it. I am not sure how that code work, so I have not figure out how to fix it.
Arrays are safer now since portage-2.1.7.16 is marked stable.
(In reply to comment #11) > Arrays are safer now since portage-2.1.7.16 is marked stable. > I use portage-2.2_rc61, I had to start using it when that was the only option to install kde-4.0.0. I suppose portage-2.2_r61 should have all fixes 2.1.7.6 has, right? Anyway, I have found the problem, the command declare -p mycmakeargs returns "declare -ax mycmakeargs=" and not "declare -a mycmakeargs=" (notice the "x" after "-a"), because of that the if is resolved to true and kde4-base_src_configure tries to convert an array into an array, which is wrong and results in an empty mycmakeargs in the end. Unfortunately KDE_DEFAULT_HOME is still not set to .kde4.3. I had to add a patch to the ebuild to change it in kdelibs-4.3.5/CMakeList.txt. I do not know why it stopped working.
(In reply to comment #12) > (In reply to comment #11) > > Arrays are safer now since portage-2.1.7.16 is marked stable. > > > > I use portage-2.2_rc61, I had to start using it when that was the only option > to install kde-4.0.0. I suppose portage-2.2_r61 should have all fixes 2.1.7.6 > has, right? Anyway, I have found the problem, the command declare -p > mycmakeargs returns "declare -ax mycmakeargs=" and not "declare -a > mycmakeargs=" (notice the "x" after "-a"), because of that the if is resolved > to true and kde4-base_src_configure tries to convert an array into an array, > which is wrong and results in an empty mycmakeargs in the end. > > Unfortunately KDE_DEFAULT_HOME is still not set to .kde4.3. I had to add a > patch to the ebuild to change it in kdelibs-4.3.5/CMakeList.txt. I do not know > why it stopped working. > Hi again, I had to apply to /usr/portage/eclass/cmake-utils.eclass the same change I did in /usr/portage/eclass/kde4-base.eclass to make kdelibs-4.4.0 compile correctly here. It seems because of the "declare -p" problem not all mycmakeargs content is being passed to cmake. Please fix this problem because since it is in cmake-utils too it probably affects all packages that use cmake.
Is this still issue for you?
(In reply to comment #14) > Is this still issue for you? > I have added this script (/etc/portage/postsync.d/fix_eclass.sh) to patch cmake-utils.eclass and kde4-base.eclass on every "emerge --sync". Since then I do not have more problems :-) But I would like to see this patch added to portage, maybe other people has the some problem as me.
Created attachment 236663 [details, diff] Prevents erasing cmake args by accident This is the patch I am using.
Sorry, we'll have to reject the patch, since stable portage versions work fine with the eclass there is no reason to patch it. thanks for you report though
