When building ct-ng-1.18.0 (or 1.19.0, it's the same) then Gentoo's install.py program is detected during build and recorded in ct-ng's scripts. This causes strange behaviour when using ct-ng, because it uses Gentoo's install script which is using python and a lot of memory, so my build broke with python error messages. Instead the regular /usr/bin/install should be used by ct-ng. On a normal ct-ng install I get the following entry: # grep install /usr/lib/ct-ng.1.18.0/paths.sh export install="/usr/lib64/portage/bin/ebuild-helpers/xattr/install -c" When manually changing this to: % grep install /usr/lib/ct-ng.1.18.0/paths.sh export install="/usr/bin/install -c" things work okay for me again. Reproducible: Always Steps to Reproduce: 1. emerge ct-ng 2. look into /usr/lib/ct-ng.*/paths.sh 3. find the wrong install program recorded there Actual Results: /usr/lib64/portage/bin/ebuild-helpers/xattr/install was recorded in paths.sh Expected Results: /usr/bin/install should be recorded in paths.sh
Just come to say this is always reproducible in 1.20.0. install.py is used by ct-ng and when using ct-ng to build other toolchain, install.py keeped forking and eat a huge bunch of memory.
(In reply to aleiphoenix from comment #1) > Just come to say this is always reproducible in 1.20.0. install.py is used > by ct-ng and when using ct-ng to build other toolchain, install.py keeped > forking and eat a huge bunch of memory. Yeah sorry guys, I've been busy and this has been on the back burner. Do either of you have a patch?
(In reply to Anthony Basile from comment #2) > (In reply to aleiphoenix from comment #1) > > Just come to say this is always reproducible in 1.20.0. install.py is used > > by ct-ng and when using ct-ng to build other toolchain, install.py keeped > > forking and eat a huge bunch of memory. > > Yeah sorry guys, I've been busy and this has been on the back burner. Do > either of you have a patch? Actually please post your emerge --info because I'm not able to reproduce this. My suspicion is that this is a fork bomb which was fixed. But I need to know your system details to make sure we're on the same page.
Created attachment 387638 [details] emerge --info of x86-64 Gentoo system affected by the bug
Created attachment 387640 [details] emerge --info of i686 system affected by the bug
I can still reproduce the bug on independently configured Gentoo systems one is a 32bit machine, one is a 64bit machine. Using the currently stable ct-ng-1.20.0
Created attachment 387642 [details] ct-ng related emerge info on amd64 I just tried on my another Gentoo box. It's still in 'fork hell'.
(In reply to aleiphoenix from comment #7) > Created attachment 387642 [details] > ct-ng related emerge info on amd64 > > I just tried on my another Gentoo box. It's still in 'fork hell'. Okay I think I know what's going on. If my suspicions are right, you are using install-xattr-0.3. Try installing install-xattr-0.4. Its ~arch right now, but if it fixes your issue I'll fast stabilize it.
(In reply to Anthony Basile from comment #8) > (In reply to aleiphoenix from comment #7) > > Created attachment 387642 [details] > > ct-ng related emerge info on amd64 > > > > I just tried on my another Gentoo box. It's still in 'fork hell'. > > Okay I think I know what's going on. If my suspicions are right, you are > using install-xattr-0.3. Try installing install-xattr-0.4. Its ~arch right > now, but if it fixes your issue I'll fast stabilize it. If that doesn't work, can you try adding the following patch: --- ct-ng-1.20.0.ebuild 2014-09-09 05:27:46.000000000 -0400 +++ ct-ng-1.20.0-r1.ebuild 2014-10-28 06:19:39.401274660 -0400 @@ -30,6 +30,10 @@ eautoconf -Wall --force } +src_configure () { + econf --with-install="/usr/bin/install" +} + src_install() { emake DESTDIR="${D%/}" install newbashcomp ${PN}.comp ${PN}
(In reply to Anthony Basile from comment #8) > Okay I think I know what's going on. If my suspicions are right, you are > using install-xattr-0.3. Try installing install-xattr-0.4. Its ~arch right > now, but if it fixes your issue I'll fast stabilize it. Actually I don't have install-xattr installed at all on the affected systems. What is installed is pyxattr-0.5.2, however.
(In reply to mg from comment #10) > (In reply to Anthony Basile from comment #8) > > > Okay I think I know what's going on. If my suspicions are right, you are > > using install-xattr-0.3. Try installing install-xattr-0.4. Its ~arch right > > now, but if it fixes your issue I'll fast stabilize it. > > Actually I don't have install-xattr installed at all on the affected systems. > > What is installed is pyxattr-0.5.2, however. Okay. We had a different fork bomb with istall-xattr itself but this isn't the problem here. Please try my patch in comment #9 and let me know. I'll push out as soon as i have confirmation.
All right, I've applied the patch to the ebuild and reemerged ct-ng-1.20.0. The additional configure option was passed during the prepare step. The installed paths.* files are looking okay now. Thank you!
(In reply to mg from comment #12) > All right, I've applied the patch to the ebuild and reemerged ct-ng-1.20.0. > The additional configure option was passed during the prepare step. The > installed paths.* files are looking okay now. > > Thank you! Okay its in the tree. I removed 1.18.0 and previous because of a recursion problem in the Makefile triggered by that patch. Those versions are old anyhow. I hope you can live with 1.19.0 and above. Let me know if this is good. Reopen if there are still problems.
I didn't use install-xattr either. I've tried new 1.20.0-r1 version of ct-ng. It works now. Thanks!
(In reply to aleiphoenix from comment #14) > I didn't use install-xattr either. I've tried new 1.20.0-r1 version of > ct-ng. It works now. Thanks! yeah that fork bomb is there in the python wrapper *without* independantly of anything else. You can cause it manually by just invoking that wrapper.