The freshly stabilized gtk+-2.24.17 gets stuck in the test phase during the test "filechooser". Stracing the test process suggests a cause: inotify_add_watch(5, "/var/tmp/portage", IN_MODIFY|IN_ATTRIB|IN_CLOSE_WRITE|IN_MOVED_FROM|IN_MOVED_TO|IN_CREATE|IN_DELETE|IN_DELETE_SELF|IN_MOVE_SELF|IN_UNMOUNT|IN_ONLYDIR) = -1 ENOENT (No such file or directory) recvfrom(3, 0x5f9fddd2e4, 4096, 0, 0, 0) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=7, events=0}, {fd=5, events=POLLIN}], 4, 3981) = 0 (Timeout) These three repeat indefinitely at 1 Hz. I don't have /var/tmp/portage - that's probably the cause. Stdout is: TEST: filechooser... (pid=5834) Xlib: extension "RANDR" missing on display ":101". /GtkFileChooserButton/open-1: There's nothing more to see in the build.log. Xorg.0.log says RANDR is enabled, by the way. But I suppose that's irrelevant here. Reproducible: Always
Created attachment 346302 [details] emerge --info I'm compiling gtk+ with USE="introspection {test} vim-syntax (-aqua) -cups -debug -examples -xinerama".
Please also attach your /etc/make.conf
Created attachment 346330 [details] make.conf
Can you attach /var/tmp/portage/dev-libs/x11-libs/gtk+-2.24.17/temp/environment?
Created attachment 346364 [details] "environment" file
When I emerge with FEATURES="-usersandbox -userpriv sandbox fakeroot", the test passes. With FEATURES="-usersandbox userpriv -sandbox fakeroot" it hangs. So it does also with FEATURES="-usersandbox userpriv -sandbox -fakeroot". However, if I: start the emerge -> wait until the actual compiling starts (after ./configure) -> Ctrl+C -> chown the workdir and its contents to my own user account -> run (as my user acc) make clean -> make distclean -> export CFLAGS, CXXFLAGS, LDFLAGS as set in make.conf -> ./configure with the same parameters emerge calls it -> make -j4 -> make check ... then the test passes.
I'm guessing it might be because in /etc/passwd the user "portage"'s home dir is set to /var/tmp/portage. If that's the cause, I wonder if there could be other issues caused by this. Shall I request that the Portage team handles this? With "userpriv" emerge should probably check (every time it's run) if PORTAGE_TMPDIR matches the account's home and if not then export some variable (HOME or something) appropriately before starting to build anything or even change the account's home dir. Or - if not either of these - then at least check if the account's home exists and if not then print a warning.
(In reply to comment #7) > I'm guessing it might be because in /etc/passwd the user "portage"'s home > dir is set to /var/tmp/portage. > > If that's the cause, I wonder if there could be other issues caused by this. > Shall I request that the Portage team handles this? With "userpriv" emerge > should probably check (every time it's run) if PORTAGE_TMPDIR matches the > account's home and if not then export some variable (HOME or something) > appropriately before starting to build anything or even change the account's > home dir. Or - if not either of these - then at least check if the account's > home exists and if not then print a warning. This problem with userpriv looks familiar to me... but I cannot find the bug, will CC portage team to check this situation
The original idea is that the filechooser might be trying to "open" some directory and "~" could likely be the default pick. But for user portage that may not exist.
Portage already creates a separate temporary home directory for each package, and exports the HOME variable. This issue seems related to virtualx.eclass usage, so maybe the x11 herd has a idea what could go wrong here. I don't see any notes about userpriv in the eclass.
Just to confirm: when I change in /etc/passwd the homedir of user portage to something that exists, the test phase proceeds normally (with userpriv). The sourcecode of the test filechooser is full of requests for the home dir.
Oh, I see. In the sources of glib, file glib/gutils.c: /** * g_get_home_dir: * * Gets the current user's home directory as defined in the * password database. * * Note that in contrast to traditional UNIX tools, this function * prefers <filename>passwd</filename> entries over the <envar>HOME</envar> * environment variable. This function is the one called by the hanging test module in gtk+.
(In reply to comment #12) The fact that it doesn't respect the HOME variable also caused bug 128289 and bug 345659.
Does the problem go away if you create the /var/tmp/portage directory? If so, then it seems like there's something wrong with the test case, and there's nothing portage or virtualx.eclass could do to improve the situation.
(In reply to comment #14) > Does the problem go away if you create the /var/tmp/portage directory? Yes, this fixes the problem. > If so, then it seems like there's something wrong with the test case, and > there's nothing portage or virtualx.eclass could do to improve the situation. The test module certainly shouldn't enter an indefinite loop. I don't know if that's the best solution, but Portage could fix the problem by putpwent()-ing an appropriate home dir for the account portage. On each run of emerge without -p. By "appropriate" I mean something like PORTAGE_TMPDIR from make.conf. This would fix all analogous issues in packages that rely on glib and its get_home().
(In reply to comment #15) Given that we support parallel builds (emerge --jobs), it would make more sense for portage have a pool of users, with each one having a unique homedir. It could automatically allocate new users as necessary for the number of parallel builds. However, it seems a little bit ridiculous to do all this just because the test case doesn't respect the HOME variable.
(In reply to comment #16) > However, it seems a little bit ridiculous to do all this just because the > test case doesn't respect the HOME variable. If it is known that this one test is the only thing in that is broken by this particular glibly behavior, then it is overkill, yes.
If we do make any change to portage, it should also be covered by PMS. The HOME variable is already documented in "The Ebuild Environment" chapter: http://dev.gentoo.org/~ulm/pms/5/pms.html#x1-11800011.1
The HOME variable (In reply to comment #16) > Given that we support parallel builds (emerge --jobs), it would make more > sense for portage have a pool of users, with each one having a unique > homedir. It could automatically allocate new users as necessary for the > number of parallel builds. http://en.wikipedia.org/wiki/KISS_principle > However, it seems a little bit ridiculous to do all this just because the > test case doesn't respect the HOME variable. +1 The HOME variable is specified by POSIX, whereas /etc/passwd isn't. So I'd say that any program (with few exceptions, like /bin/login itself) that ignores HOME is in error. But maybe the portage entry in our passwd file should have a home dir that's better defined? Either some dir that's guaranteed to exist, or something like /dev/null that's guaranteed to fail. (This would be a baselayout issue though.)
(Apart from the general Portage discussion,) >=glib-2.35.3 has this whole thing fixed and honors $HOME. If it's not against anything else, stabilizing it might be a good way to close this particular bug.
Please note that we carry a specific for this in eclass, it is most likely that we forgot to backport that env fix in gtk ebuild, or someone was a bit too optimistic and dropped it. Exporting G_HOME=$HOME in src_test should fix it.
(In reply to comment #21) > Please note that we carry a specific for this in eclass, it is most likely > that we forgot to backport that env fix in gtk ebuild, or someone was a bit > too optimistic and dropped it. > > Exporting G_HOME=$HOME in src_test should fix it. FWIW, when I run # G_HOME="/boot/tmp/portage" emerge -v1 gtk+:2 then the test hangs (userpriv). (That dir there does exist.)
(In reply to comment #21) > Please note that we carry a specific for this in eclass, it is most likely > that we forgot to backport that env fix in gtk ebuild, or someone was a bit > too optimistic and dropped it. > > Exporting G_HOME=$HOME in src_test should fix it. It also hangs when I alter the ebuild such that: src_test() { unset DBUS_SESSION_BUS_ADDRESS # Exporting HOME fixes tests using XDG directories spec since all defaults # are based on $HOME. It is also backward compatible with functions not # yet ported to this spec. G_HOME="${T}" XDG_DATA_HOME="${T}" HOME="${T}" Xemake check || die "tests failed" }
Try inheritting gnome2-utils.eclass and calling: gnome2_environment_reset at the top of src_test phase
(In reply to comment #24) > Try inheritting gnome2-utils.eclass and calling: > gnome2_environment_reset > > at the top of src_test phase No gain.
please retry with 2.24.23
