Summary: | dev-vcs/mercurial-1.7 fails test-mq.t and test-rename-merge2.t | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Dustin Polke <DuPol> |
Component: | [OLD] Unspecified | Assignee: | Krzysztof Pawlik (RETIRED) <nelchael> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | djc, levertond, zmedico |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | build.log |
Description
Dustin Polke
2010-12-16 09:25:03 UTC
Created attachment 257288 [details]
build.log
Same for both cases: ERROR: /var/tmp/portage/dev-vcs/mercurial-1.7/work/mercurial-1.7/tests/test-mq.t output changed and returned error code -15 --- /var/tmp/portage/dev-vcs/mercurial-1.7/work/mercurial-1.7/tests/test-mq.t +++ /var/tmp/portage/dev-vcs/mercurial-1.7/work/mercurial-1.7/tests/test-mq.t.err @@ -1,1368 +1,8 @@ + + ### Abort: timeout after 180 seconds. Dirkjan: any hint about why it times out? Maybe we should replace -j4 with the -j we extract from MAKEOPTS? This could apparently be due to running with a -j that's too high. I'm getting timeouts with -j4 on dual core system where I normally use -j4. Maybe we should drop to -j1 entirely (ie. drop the -jX argument)? It's better to be slower but correct than faster but wrong. (In reply to comment #4) > I'm getting timeouts with -j4 on dual core system where I normally use -j4. > Maybe we should drop to -j1 entirely (ie. drop the -jX argument)? It's better > to be slower but correct than faster but wrong. I'm getting timeouts even with -j1... It should be possible to extract from the MAKEOPTS whatever it has for -j, using some clever shell-script? I think I've seen it before... One way of doing it: for i in ${MAKEOPTS}; do case "${i}" in -j*|--jobs=*) our_j="${i}" ;; *) # Ignore ;; esac done Dustin: have you removed -j4 from the ebuild or from MAKEOPTS? Currently we're using -j4 regardless of your MAKEOPTS settings -- check mercurial-1.7.2.ebuild file. (In reply to comment #7) > Dustin: have you removed -j4 from the ebuild or from MAKEOPTS? Currently we're > using -j4 regardless of your MAKEOPTS settings -- check mercurial-1.7.2.ebuild > file. I just lowered -j in my MAKEOPTS. Generally, it is a bad idea to hardcode -j greater than 1 in the ebuild, IMO. I will hardcode -j1 in the ebuild and test tomorrow. (In reply to comment #8) > I will hardcode -j1 in the ebuild and test tomorrow. Hardcoding -j1 in the ebuild prevents the time-out. However, I ran now in bug #339670. As far as I read there, this has been fixed in portage-2.2.0_alpha8, but not sure whether this fix has been included into stable portage. Could you please check with zmedico? (In reply to comment #9) > (In reply to comment #8) > > I will hardcode -j1 in the ebuild and test tomorrow. > Hardcoding -j1 in the ebuild prevents the time-out. However, I ran now in bug > #339670. Cool, thank you for testing this. Dirkjan: I think that keeping it safe and sticking with -j1 (or no -j option at all) is the best bet. > As far as I read there, this has been fixed in portage-2.2.0_alpha8, but not > sure whether this fix has been included into stable portage. Could you please > check with zmedico? Now it has not been integrated with <2.2.0_alpha8. Zac: could we get the fix for recursion limit with symlinks in 2.1.9.26? It affects stable dev-vcs/mercurial. (In reply to comment #10) > Now it has not been integrated with <2.2.0_alpha8. Zac: could we get the fix > for recursion limit with symlinks in 2.1.9.26? It affects stable > dev-vcs/mercurial. Yes, it's already merged in the 2.1.9 branch and I plan to release it just after 2.1.9.25 is stabilized. Okay. I applied the patch attached to bug #339670 to portage and with -j1, I was able to successfully emerge mercurial-1.7. I've removed -j4 from 1.7, 1.7.1 and 1.7.2. |