Created attachment 584740 [details, diff] patch to virtualx.eclass If using GNOME GDM, X is started on DISPLAY :0 but a lock file /tmp/.X1024-lock is created instead of /tmp/.X0-lock. virtx() will initially set XDISPLAY to 0 and attempt to start Xvfb on DISPLAY :0 which fails but DISPLAY :1 (and greater) is not attempted if a previous emerge left /tmp/.X1-lock behind. A simple patch that works around this for me is attached - starting the search for a DISPLAY at :1. The other problem that exposed this is that the lock files are not being removed. This patch allows you to keep testing but does result in lock files accumulating.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6f680e4fe73925ae130343e02adb416cb799ce7d commit 6f680e4fe73925ae130343e02adb416cb799ce7d Author: Chris Mayo <aklhfex@gmail.com> AuthorDate: 2019-07-26 18:48:13 +0000 Commit: Matt Turner <mattst88@gentoo.org> CommitDate: 2019-07-30 01:49:41 +0000 virtualx.eclass: Fix no display for an emerge following a failure If using GNOME GDM, X is started on DISPLAY :0 but a lock file /tmp/.X1024-lock is created instead of /tmp/.X0-lock. virtx() will initially set XDISPLAY to 0 and attempt to start Xvfb on DISPLAY :0 which fails but DISPLAY :1 (and greater) is not attempted if a previous emerge left /tmp/.X1-lock behind. Closes: https://bugs.gentoo.org/690778 Signed-off-by: Chris Mayo <aklhfex@gmail.com> Signed-off-by: Matt Turner <mattst88@gentoo.org> eclass/virtualx.eclass | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-)
