Summary: | distcc breaks current stable x11-drivers/xf86-video-intel-2.19.0 | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Joe Breuer <gentoo> |
Component: | Current packages | Assignee: | MATSUU Takuto (RETIRED) <matsuu> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | cluster, x11 |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
full Xorg.0.log with the problem
List of packages installed after the first build of xorg-server Packages whose files are used by the xorg-server build Files per package used by the xorg-server configure phase Files per package used by the xorg-server compile phase |
Description
Joe Breuer
2012-07-12 09:22:47 UTC
Created attachment 317978 [details]
full Xorg.0.log with the problem
Something must be special about your system. What USE flags was xf86-video-intel built with? (In reply to comment #2) > Something must be special about your system. What USE flags was > xf86-video-intel built with? Nothing (knowingly) special: +dri -sna In the mean time, I rebuilt x11-base/xorg-server-1.12.2 (which is what /usr/lib/xorg/modules/libfb.so which has the symbol in question belongs to). No change. Then I also rebuilt x11-drivers/xf86-video-intel-2.19.0 (again). A-ha! Now X11 starts as usual. So apparently due to the exact environment in my upgrade scenario, first x11-base/xorg-server-1.12.2 was built "broken" which also causes the x11-drivers/xf86-video-intel-2.19.0 built against it to build correctly, but not work. In my @world build there were 70 packages built after xorg-server. I'll dig the list out of my emerge.log and attach it. So it might be a different package that's affecting the xorg-server build, but is not correctly considered as a dependency. But this behaviour is also consistent with the following scenario: The xorg-server ebuild uses headers (or other files with similar effect) not from its own build directory, but from the version already installed in the system - I believe this is a "normal" problem every now and then for certain packages. I'd be happy to investigate this further; how do I go about finding "uses installed instance" occurences from an ebuild? Created attachment 317996 [details]
List of packages installed after the first build of xorg-server
I did some analyses on this with the help of the sandbox in debug mode and a script I'd hacked together to help me analyze the results. The script is here: https://github.com/jmbreuer/gentoo-utils/tree/master/daz While I'm still analyzing these results, I've obviously done rebuilds of xorg-server and xf86-video-intel to generate data, which led to one interesting observation: I'd rebuilt first xf86-video-intel and then xorg-server to generate logs for analysis. After this, the X server would not load intel_drv with the original error message: fbScreenInit undefined. Is this intended behavior? What's going on here? Simply rebuilding xf86-video-intel does not change anything. I'm now off to rebuilding xorg-server again and keeping the various binary packages, in the hopes of finding the specific difference... ... and the first results from the script are in: xorg-server does not appear to use any of its own installed resources; also it does not read any files from packages built after xorg-server in the original emerge. So that's good news. To give you an idea, I'll attach the script's output, slightly cleaned up. Created attachment 318510 [details]
Packages whose files are used by the xorg-server build
Created attachment 318512 [details]
Files per package used by the xorg-server configure phase
Created attachment 318514 [details]
Files per package used by the xorg-server compile phase
I now have some indication that using distcc might break (specifically) the x11-drivers/xf86-video-intel package; the other failures might be related to where a certain object happened to get compiled undert distcc. I'm still miles away from a conclusive result, but first order seems to indicate: - building with FEATURES="distcc" with a certain probability breaks x11-drivers/xf86-video-intel for me; regardless of whether distcc-pump is enabled as well (probability does not appear to be affected) - building with FEATURES="-distcc" seems to always result in a working driver I'll try to dig into this further. I'd have understood problems with pump mode, but problems with plain distcc are contrary to my experiences in this setup. I used to be able to do full KDE system builds against these distcc servers without any conspicuities. Reassigning to distcc maintainers then. Thank you I've tried to run some more tests, but this is getting exceedingly frustrating. Enviroment: tiny: The machine I'm running the emerge on. Ideally, it should not run a compiler at all, since it's quite anemic compared to the other hosts. MAKEOPTS is set to -j16. average: One of the helper machines (4 cores, 8 jobs). large: One of the helper machines (16 cores, 32 jobs). The compiler for tiny (i686-pc-linux-gnu) is a cross-compiler (crossdev -S) on the amd64 helper machines. What I see is this: - Sometimes compiles apparently still happen on tiny, dispite not having tiny or localhost in my distcc host list. I'm still trying to figure out what's going on here. One theory is that distcc falls back to compiling on localhost is when it thinks it has exhausted the number of remote jobs (according to /num in the distcc host configuration). - When I try to force mixed compiles (here: localhost + average), this seems to give the largest probability that the resulting build is broken. Damn. I cannot reproduce this anymore. Yesterday, roughly every second build using a mixture of remote and local compiles would result in a broken module. Today, every combination I've tried yesterday (and every other I can think of) yields a working module. Sunspots? Solar storm perhaps. Closing. Thanks |