Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 501678 - sys-devel/ct-ng-1.18.0 records /usr/lib64/portage/bin/ebuild-helpers/xattr/install in /usr/lib/ct-ng.1.18.0/paths.sh
Summary: sys-devel/ct-ng-1.18.0 records /usr/lib64/portage/bin/ebuild-helpers/xattr/in...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: AMD64 Linux
: Normal normal (vote)
Assignee: Anthony Basile
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-02-18 12:02 UTC by mg
Modified: 2014-10-28 17:10 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
emerge --info of x86-64 Gentoo system affected by the bug (jenkins.info,5.39 KB, text/plain)
2014-10-28 09:47 UTC, mg
Details
emerge --info of i686 system affected by the bug (cilt.info,4.81 KB, text/plain)
2014-10-28 09:48 UTC, mg
Details
ct-ng related emerge info on amd64 (ct-ng.related.emerge.info.of.amd64.txt,4.62 KB, text/plain)
2014-10-28 09:51 UTC, aleiphoenix
Details

Note You need to log in before you can comment on or make changes to this bug.
Description mg 2014-02-18 12:02:49 UTC
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
Comment 1 aleiphoenix 2014-10-27 16:15:33 UTC
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.
Comment 2 Anthony Basile gentoo-dev 2014-10-27 18:39:25 UTC
(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?
Comment 3 Anthony Basile gentoo-dev 2014-10-27 18:46:34 UTC
(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.
Comment 4 mg 2014-10-28 09:47:44 UTC
Created attachment 387638 [details]
emerge --info of x86-64 Gentoo system affected by the bug
Comment 5 mg 2014-10-28 09:48:30 UTC
Created attachment 387640 [details]
emerge --info of i686 system affected by the bug
Comment 6 mg 2014-10-28 09:49:23 UTC
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
Comment 7 aleiphoenix 2014-10-28 09:51:18 UTC
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'.
Comment 8 Anthony Basile gentoo-dev 2014-10-28 10:09:57 UTC
(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.
Comment 9 Anthony Basile gentoo-dev 2014-10-28 10:23:05 UTC
(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}
Comment 10 mg 2014-10-28 10:25:04 UTC
(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.
Comment 11 Anthony Basile gentoo-dev 2014-10-28 10:27:41 UTC
(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.
Comment 12 mg 2014-10-28 10:46:44 UTC
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!
Comment 13 Anthony Basile gentoo-dev 2014-10-28 11:31:34 UTC
(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.
Comment 14 aleiphoenix 2014-10-28 13:13:02 UTC
I didn't use install-xattr either. I've tried new 1.20.0-r1 version of ct-ng. It works now. Thanks!
Comment 15 Anthony Basile gentoo-dev 2014-10-28 17:10:44 UTC
(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.