| Summary: | PATCHRESOLVE's devshell opens up multiple new terminals | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] BitBake | Reporter: | Alejandro Hernandez <alejandro.hernandez> |
| Component: | bitbake | Assignee: | Alejandro Hernandez <alejandro.hernandez> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | minor | ||
| Priority: | Medium | CC: | alejandro.hernandez, anibal.limon, benjamin.esquivel, jacob.kroon, jose.a.lamego, leonardo.sandoval.gonzalez, poky.bs.watcher, poky.watcher, richard.purdie, sgw |
| Version: | unspecified | ||
| Target Milestone: | 2.2 M3 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | Don't know | |
|
Description
Alejandro Hernandez
2015-01-26 23:53:42 UTC
I can confirm it is Gnome Terminal related, setting OE_TERMINAL to either "xfce" or "xterm" for example presents no problems whatsoever This behavior is caused because when opening a new Gnome Terminal, it reuses a gnome-terminal process that is already running and opens a new window instead of creating a new process for it. Appending the flag "--disable-factory" to the command being run, forces it to create a new process and solves the issue. More info at: http://www.unix.com/man-page/all/0/gnome-terminal/ The commit in OE-Core that fixed this bug b457e0b028418260aee25858b8af8938dd038fac "terminal.py: fixes launching multiple windows of gnome-terminal" actually breaks my Fedora 21 setup. I now get an error message when running devshell: Failed to parse arguments: Option "--disable-factory" is no longer supported in this version of gnome-terminal. I fixed this one year ago in OE-Core, in commit e8dca725ed8211a874472300a3ed50e494039ab9 "meta/lib/oe/terminal.py: Don't pass non-supported '--disable-factory' flag to gnome-terminal" I'm using version 3.14.2 of gnome-terminal, which is quite a bit newer than Alejandro's 3.6.2. Unless there is an easy way to support both versions, I suggest that the bugfix gets reverted, in order to support newer gnome-terminals. Indeed, support for this option was dropped by gnome-terminal here: https://git.gnome.org/browse/gnome-terminal/commit/?id=aef122c916719763f6d0d404b4131456d84c482f There is not an equivalent option on newer gnome-terminals, so the bugfix should be reverted to partially support newer gnome terminals. There is a "hacky" way to get one-process-per-gnome-terminal described here: https://wiki.gnome.org/Apps/Terminal/Debugging I can understand the problem you're seeing Alejandro, and I'm not sure my invocations of gnome-terminal are 100% accurate since I get a couple of warnings on devshell startup, although those warnings might not be related to the gnome-terminal issue. Nonetheless, if Yocto maintainers decide to revert the bugfix, it might be worth to also add a comment in terminal.py why "--disable-factory" isn't being passed. I will try to work this out, I don't believe the comment is necessary, it is my fault that I did not check the git log for this previous change. So, are you saying you're not able to reproduce this bug on a newer version of gnome-terminal?. The easiest way to reproduce it is to find a recipe i.e. <foo> with more than 1 patch, modify the first patch on the list to make it fail, comment the PATCHRESOLVE = noop line on your local.conf file and then call the patch task using bitbake -c patch <foo>, you should automatically get several new windows of gnome-terminal depending on the number of patches for that recipe. If you are not able reproduce this, perhaps the best decision will be to drop support for older versions of gnome-terminal. So I've locally reverted b457e0b028418260aee25858b8af8938dd038fac "terminal.py: fixes launching multiple windows of gnome-terminal" I've commented out 'PATCHRESOLVE = "noop"' in my local.conf, and then I b0rked meta/recipes-core/glib-2.0/glib-2.0/configure-libtool.patch so that it will fail to apply. Running "bitbake -c patch glib-2.0" I get, in one gnome-terminal: *** Manual patch resolution mode *** Dropping to a shell, so patch rejects can be fixed manually. Run "quilt refresh" when patch is corrected, press CTRL+D to exit. Applying patch configure-libtool.patch patching file configure.ac Hunk #1 FAILED at 1470. Hunk #2 succeeded at 1499 (offset -36 lines). Hunk #3 succeeded at 1578 (offset -36 lines). 1 out of 3 hunks FAILED -- saving rejects to file configure.ac.rej Applied patch configure-libtool.patch (forced; needs refresh) but I also immediately at the same time get several other gnome-terminals, all saying the same thing: *** Manual patch resolution mode *** Dropping to a shell, so patch rejects can be fixed manually. Run "quilt refresh" when patch is corrected, press CTRL+D to exit. The topmost patch configure-libtool.patch needs to be refreshed first. Is this behaviour correct ? No, the other gnome-terminals should not appear, after you "fix" the first patch you should if needed be promted with another *** Manual patch resolution mode *** for the next patch that failed. I will try to find a workaround for this, for it to work on both newer and older versions of gnome-terminal. A workaround was found to only enable --disable-factory on supported versions of gnome-terminal here, Thanks to Paul and Sven: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=f160730bbdb06cca5c1443e6688365cffe6deb00 It'd still be nice to make it work on the newer versions of gnome-terminal, perhaps it could be done by checking if the process of the "first" terminal ended somehow so then a "second" terminal can be opened for the next patch and so on. According to this comment: https://bugzilla.gnome.org/show_bug.cgi?id=707899#c3 There is **no** way to have separated gnome-terminal processes on recent g-t versions (due to the client-server architecture) unless debugging the latter which is not possible in our case (because gdb would be needed). A possible workaround would be to force using another OE_TERMINAL which I do not think this is a good option. Ok, so after diving a little bit more into it, here's a better explanation of the problem and how it can be solved: When spawning a new terminal via bitbake, we wait for its return value, the default behavior of terminals is that they return once the user closes the terminal/devshell, so that works great for us, since after getting a return value were able to continue doing our job. The problem with newer versions of Gnome-terminal is that, once they get spawned they call bash/sh (which is ok), but gnome-terminal works in a somewhat server-client model, so at this point the new terminal process returns and the bash process gets reparented, the new parent being gnome-terminal (server), a process we don't know anything about, but the problem is that now there is no relationship between our running process and the new bash process whatsoever. This brings us lots of trouble since when we get a return value, we continue doing our work, in the case of fixing patches we go on with the process of spawning new terminals for every patch left we got, following the same workflow: spawning a new terminal, launching bash, getting reparented to the gnome-terminal server and returning immediately. We need a new way of waiting for the bash process to end, before we can continue, but to do this we need to know which bash process is the one we launched to do this I created a patch (will submit to the list) that in a somewhat dirty way, gets the PID of the gnome-terminal process, gets its children processes before and after launching the new one, hence obtaining the PID of the new process we launched, monitors this process to see if its still running, and forces bitbake to not continue until it returns. While this is not ideal, since we loose a little bit of accuracy when checking for errors, it does provide bitbake support for gnome-terminal >= v3.10. |