Closed Bug 1223123 Opened 9 years ago Closed 9 years ago

We need a window manager of some type while running test jobs on linux

Categories

(Taskcluster Graveyard :: Docker Images, defect)

Product:
Taskcluster Graveyard
Component:
Docker Images
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: jmaher, Assigned: armenzg)

References

Details

Attachments

(3 files, 1 obsolete file)

Dockerfile
156 bytes, text/plain
Details
run-session
1.97 KB, text/plain
Details
Enable window manager + use pulseaudio
8.87 KB, patch
dustin
: review+
Details | Diff | Splinter Review 
I found that installing 'compiz' on the desktop-test image allowed me to run about 100 of the unittests without failure.  I am not sure if 'compiz' is the right thing, or if there are different versions we should consider.  I did 'apt-get install compiz' and 'Xvfb &; compiz &' to get the tests up and running.
Assignee: nobody → armenzg
Blocks: tc-linux64-debug
Summary: we need a window manager of some type while running test jobs on linux → We need a window manager of some type while running test jobs on linux
gardnt: what do you think of this change so far? Is this the correct approach?
https://hg.mozilla.org/try/rev/a03d46c48f24

Please ignore that we're skipping ubuntu1204-test-upd atm
On the buildbot testers we're installing all of `ubuntu-desktop` (which pulls in a huge number of deps):
http://mxr.mozilla.org/build/source/puppet/modules/gui/manifests/init.pp#36
http://mxr.mozilla.org/build/source/puppet/modules/packages/manifests/linux_desktop.pp#7

I thought I remembered us having code to explicitly launch a window manager, but maybe that went by the wayside at some point.
Agreed -- I remember some back-and-forth over whether lxde was good enough or we had to run unity (which had some pretty weird behvaior) on the tester hardware.

We already have code in test-linux.sh to run Xvfb, so we could just put the window-manager-starting bits after that in the same script, protected either by NEEDS_XVFB or another env var.
I had picked compiz because it was simple and it worked- we can use ubuntu-desktop if that would be better.  I am not sure what we would need to do in order to get that started up properly.

When I pushed to try, I had started compiz inside the Xvfb init block at the end.  I think until we have 99% green, we need to assume the failures are due to system wide packages/configurations we need to adjust and keep working on it.
ubuntu-desktop is a metapackage that winds up installing compiz through dependencies, FWIW.

I just couldn't find evidence as to what WM we're actually using on the buildbot testers or how it gets started. I assume it's Compiz, and maybe it gets run as part of the Ubuntu defaults because of installing ubuntu-desktop?
My point is mostly this: we should try to make the Taskcluster tester image as close to the buildbot tester environment as possible or we're going to be chasing down test failures.
Anyone has any ideas on how to do that?
Depends on: 1225484
I've requested a loaner to have something to compare with.
I'm going to try ubuntu-desktop.
Simply installing ubuntu-desktop is not enough. I would have to find out how to start up the window manager properly.

I tried with a docker image that starts up a window manager [1] (I thought it would have been the normal Ubuntu but it is LXPanel).
However, the test also fails there (bug 1224641).

[1]
docker pull dorowu/ubuntu-desktop-lxde-vnc
docker run -i -t -p 6080:6080 dorowu/ubuntu-desktop-lxde-vnc
Browse to http://127.0.0.1:6080/vnc.html ('ubuntu' is the password)
Open a terminal (under menu -> accessories)
sudo apt-get update
sudo apt-get wget unzip
sudo pip install virtualenv
mkdir workspace && cd workspace
wget https://queue.taskcluster.net/v1/task/CN0b2p9zQYq3A1iMaCmXiQ/artifacts/public/build/mozharness.zip
python mozharness/scripts/desktop_unittest.py --config-file mozharness/configs/unittests/linux_unittest.py --config-file mozharness/configs/remove_executables.py --no-read-buildbot-config --installer-url=https://queue.taskcluster.net/v1/task/CN0b2p9zQYq3A1iMaCmXiQ/artifacts/public/build/target.tar.bz2 --test-packages-url=https://queue.taskcluster.net/v1/task/CN0b2p9zQYq3A1iMaCmXiQ/artifacts/public/build/test_packages.json --download-symbols=ondemand --reftest-suite=reftest --total-chunk=4 --this-chunk=3 --no-run-tests --cfg developer_config.py
cd ~/workspace/build/tests/reftest
source ~/workspace/build/venv/bin/activate
python -u /home/ubuntu/workspace/build/tests/reftest/runreftest.py --appname=/home/ubuntu/workspace/build/application/firefox/firefox --utility-path=tests/bin --extra-profile-file=tests/bin/plugins --symbols-path=https://queue.taskcluster.net/v1/task/CN0b2p9zQYq3A1iMaCmXiQ/artifacts/public/build/target.crashreporter-symbols.zip --suite=reftest -- tests/layout/reftests/font-matching/italic-oblique-2.html
See modules/gui/manifests/init.pp in puppet -- there are a number of config files (all of which may not be required).
I will use that. Building ./build.sh ubuntu1204-test seems to fail with 'ubuntu-desktop'.

Setting up cups-bsd (1.5.3-0ubuntu8.7) ...
debconf: unable to initialize frontend: Dialog
debconf: (TERM is not set, so the dialog frontend is not usable.)
debconf: falling back to frontend: Readline
debconf: unable to initialize frontend: Readline
debconf: (This frontend requires a controlling tty.)
debconf: falling back to frontend: Teletype
Setting up indicator-printers (0.1.6-0ubuntu1) ...
...
Processing triggers for libgdk-pixbuf2.0-0 ...
Processing triggers for bamfdaemon ...
Rebuilding /usr/share/applications/bamf.index...
Errors were encountered while processing:
 console-setup
 kbd
E: Sub-process /usr/bin/dpkg returned an error code (1)
The command '/bin/sh -c bash /tmp/system-setup.sh' returned a non-zero code: 100
I think there's an argument to apt-get to suppress the interactive configuration stuff.  I think rail found it?  I'm failing to discover it in the puppet repo at the moment.
I was able to get this installed by adding an environment variable for "DEBIAN_FRONTEND=noninteractive".
I managed to build with garndt's change.

This compares the run with compiz and know with ubuntu-desktop/gnome-session
https://treeherder.mozilla.org/#/jobs?repo=try&revision=e5f0ace1da70,e528537d34bc&group_state=expanded&filter-searchStr=tc

dustin, the packages ending with mozilla1; do they mean that were monkey patched it?

gbrown pointed out that I should make sure pulseaudio and gstreamer are also installed.

### Some of the puppet packages ###
Starting from http://mxr.mozilla.org/build/source/puppet/modules/gui/manifests/init.pp#38

http://mxr.mozilla.org/build/source/puppet/modules/packages/manifests/linux_desktop.pp#11
linux_desktop --> ubuntu_desktop

http://mxr.mozilla.org/build/source/puppet/modules/packages/manifests/gnome_settings_daemon.pp
gnome_settings_daemon [3]

http://mxr.mozilla.org/build/source/puppet/modules/packages/manifests/xrestop.pp
xrestop [4]
* I assume I don't need it since it is only for talos data collection

mesa -> ["libgl1-mesa-dri", "libgl1-mesa-glx", "libglapi-mesa", "libglu1-mesa", "libxatracker1", "libgl1-mesa-dev:i386"]:
          ensure => '8.0.4-0ubuntu0.6mozilla1';

Files needed?
http://mxr.mozilla.org/build/source/puppet/modules/gui/templates/x11.conf.erb
/etc/init/x11.conf
> X :0 -nolisten tcp

"/etc/init.d/x11": ensure  => link, target  => "/lib/init/upstart-job";

http://mxr.mozilla.org/build/source/puppet/modules/gui/templates/xvfb.conf.erb
> /etc/init/xvfb.conf
> Xvfb :0 -nolisten tcp -screen 0 <%= @screen_width %>x<%= @screen_height %>x<%= if @screen_depth.to_i <= 24 then @screen_depth else 24 end %>

"/etc/X11/xorg.conf": ensure => absent

http://mxr.mozilla.org/build/source/puppet/modules/gui/templates/Xwrapper.config.erb
> "/etc/X11/Xwrapper.config":
> allowed_users=anybody

http://mxr.mozilla.org/build/source/puppet/modules/gui/files/edid.bin?raw=1&ctype=application/octet-stream
85                 # this is the EDID data from an Extron EDID adapter configured for 1200x1600
86                 "/etc/X11/edid.bin":
87                     source => "puppet:///modules/${module_name}/edid.bin";


Is this needed only for talos? bug 984944 says that it prevents taking screenshots
http://mxr.mozilla.org/build/source/puppet/modules/gui/templates/jockey-gtk.desktop
http://mxr.mozilla.org/build/source/puppet/modules/gui/templates/deja-dup-monitor.desktop
96                 "/etc/xdg/autostart/jockey-gtk.desktop":
97                     content => template("${module_name}/jockey-gtk.desktop");
98 
99                 "/etc/xdg/autostart/deja-dup-monitor.desktop":
100                     content => template("${module_name}/deja-dup-monitor.desktop");



Nothing here:
103             # start x11 *or* xvfb, depending on whether we have a GPU or not
104             service {
105                 'x11':
106                     ensure => stopped
110 
111                 'xvfb':
112                     ensure => undef
116             }


http://mxr.mozilla.org/build/source/puppet/modules/gui/templates/Xsession.conf.erb
118             file {
119                 "/etc/init/Xsession.conf":
120                     content => template("${module_name}/Xsession.conf.erb"),
121                     notify => Service['Xsession'];
122 
123                 "/etc/init.d/Xsession":
124                     ensure  => link,
125                     target  => "/lib/init/upstart-job";
126 
127                 "${users::builder::home}/.xsessionrc":
128                     content => "DESKTOP_SESSION=ubuntu\n",
129                     owner => $::users::builder::username,
130                     group => $::users::builder::group,
131                     mode => 0644,
132                     notify => Service['x11'];
133 
134                 # make sure the builder user doesn't have any funny business
135                 ["${users::builder::home}/.xsession",
136                  "${users::builder::home}/.xinitrc",
137                  "${users::builder::home}/.Xsession"]:
138                     ensure => absent;
139             }
140 
141             service {
142                 'Xsession':
143                     # we do not ensure this is running; the system will start
144                     # it after puppet is done
145                     enable => true,
146                     require => File['/etc/init.d/Xsession'];
147             }
dustin, garndt: how can we tell the spec differences between the EC2 instances used by releng and the ones used for the TC jobs?

I want to determine if the timing out mochitests have to do with it.
It looks like these are using the b2gtest worker type which are r3/m3/c3.xlarge, can run 4 tasks in parallel, and use 1 cpu per task.
> dustin, the packages ending with mozilla1; do they mean that were monkey patched it?

Possibly, or just that they were rebuilt from newer src.deb's against the old distro.  I think the latter was the case for mesa.

I don't see which specific packages you're referring to.  I'd rather *not* use custom-built deb's, where possible -- and where necessary, we will need a taskcluster task to build such custom-built debs, checked into the tree, with the resulting debs uploaded to tooltool and installed from there (in other words, we're not hosting apt repos).

https://hg.mozilla.org/try/rev/7c7d0605d656 looks great, as do the additional font things in https://hg.mozilla.org/try/rev/7f0644d2a85c

I like that your approach is largely *not* just copying everything over from puppet, but getting the sense of what we've done in puppet and reproducing the minimal amount in the docker test images.
For some reason I can VNC [1], see the Unity desktop, see the mouse move but nothing is interactive.
In fact the clock is stuck.

I used `gnome-session &` to start this.

[1]
apt-get install x11vnc
x11vnc &

How to run tests:
docker run -ti --device=/dev/video1:/dev/video1 armenzg/desktop-test:0.4.6
export DISPLAY=:0
Xvfb :0 -nolisten tcp -screen 0 1600x1200x24 &
gnome-session & (or compiz &)
cd ~worker
mkdir workspace && cd workspace
chown -R worker:worker /home/worker
curl --fail -o mozharness.zip --retry 10 -L https://queue.taskcluster.net/v1/task/JL5xdrwOQGqbf0pooeQ6Aw/artifacts/public/build/mozharness.zip
unzip mozharness.zip
sudo -E -u worker python2.7 /home/worker/workspace/mozharness/scripts/desktop_unittest.py --config-file mozharness/configs/unittests/linux_unittest.py --config-file mozharness/configs/remove_executables.py --no-read-buildbot-config --installer-url=https://queue.taskcluster.net/v1/task/JL5xdrwOQGqbf0pooeQ6Aw/artifacts/public/build/target.tar.bz2 --test-packages-url=https://queue.taskcluster.net/v1/task/JL5xdrwOQGqbf0pooeQ6Aw/artifacts/public/build/test_packages.json --download-symbols=ondemand --mochitest-suite=browser-chrome-chunked --total-chunk=7 --this-chunk=4
I see a few issues there:

x11vnc doesn't like to start up before the X server

gnome-session takes a while to start up -- it'd probably be better to have some startup item in place that the script can wait for, so it knows when the gnome env is started

This is running everything but the tests as root, but none of these tools need to (or should) run as root.

This doesn't start up the dbus daemon (I suspect at least some of the tests are testing things where Firefox is communicating with other UI components via dbus).

I'm trying to reproduce with some of those issues fixed..
Oh, and this isn't using the xvinfo command to wait for Xvfb to start up the way production jobs do
Attached file run-session — 
I built a docker image with these two files, currently being pushed as djmtiche/rundesktop.

Try running it with

  docker run -ti --rm --expose=5900:5900 djmitche/rundesktop

and the connect to port 5900 with your VNC viewer.
I got like half of that command line right

  docker run --device=/dev/video1:/dev/video1 -p=5900:5900 -ti --rm djmitche/rundesktop:latest
The image of dustin worked better with VNC; thanks dustin!

jmaher is having some focus issues.

I'm hitting this when trying to install mesa; I don't know how it knows that a mozilla1 package is needed.

###################
root@taskcluster-worker:~/workspace/build# apt-get install -y --force-yes libgl1-mesa-dri libgl1-mesa-glx libglapi-mesa libglu1-mesa libxatracker1 libgl1-mesa-dev:i386 mesa-common-dev:i386 libxext-dev:i386 libx11-dev:i386 libxcb1-dev:i386 libxcb1:i386
Reading package lists... Done
Building dependency tree       
Reading state information... Done
libgl1-mesa-dri is already the newest version.
libgl1-mesa-glx is already the newest version.
libglapi-mesa is already the newest version.
libglu1-mesa is already the newest version.
libxatracker1 is already the newest version.
libxatracker1 set to manually installed.
libxcb1:i386 is already the newest version.
libxcb1:i386 set to manually installed.
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libxcb1-dev:i386 : Depends: libxcb1:i386 (= 1.8.1-1ubuntu0.2) but 1.8.1-2ubuntu2.1mozilla1 is to be installed
E: Unable to correct problems, you have held broken packages
Here's a better technique for starting gnome-session:

---
# start up the gnome session, using a semaphore file to know when the session has fully started
# (at least to the point where apps are automatically started)
semaphore=/tmp/gnome-session-started
rm -f $semaphore
mkdir -p ~/.config/autostart
cat <<EOF > ~/.config/autostart/gnome-started.desktop
[Desktop Entry]
Type=Application
Exec=touch $semaphore
Hidden=false
X-GNOME-Autostart-enabled=true
Name=Startup Complete
Comment=Notify test-linux.sh that GNOME session startup is complete
StartupNotify=false
Terminal=false
Type=Application
EOF

gnome-session &
---

This should all end up in test-linux.sh in the end.

One possible complication here is that there may be environment variables set within the gnome session that aren't reflected back into the test-linux.sh execution.  If that's the case, we should figure out a way to dump the environment from the gnome-started.desktop run and then import that into test-linux.sh.  I think it will be *far* better to have test-linux.sh running the test script, rather than trying to redirect stdout from some script run in a gnome terminal.
(In reply to Armen Zambrano Gasparnian [:armenzg] from comment #28)
> I'm hitting this when trying to install mesa; I don't know how it knows that
> a mozilla1 package is needed.

https://dxr.mozilla.org/mozilla-central/source/testing/docker/ubuntu1204-test/system-setup.sh#181 installs libxcb from a repo on tooltool, then removes that repo.

You might experiment with trying to install the mesa stuff before `cp sources.list.orig /etc/apt/sources.list`?
Blocks: 1226676
Sorry, I left off the last bit, after gnome-sesion &:
---
while [ ! -f $semaphore ]; do
    sleep 1
done
---
(In reply to Dustin J. Mitchell [:dustin] from comment #30)
> (In reply to Armen Zambrano Gasparnian [:armenzg] from comment #28)
> > I'm hitting this when trying to install mesa; I don't know how it knows that
> > a mozilla1 package is needed.
> 
> https://dxr.mozilla.org/mozilla-central/source/testing/docker/ubuntu1204-
> test/system-setup.sh#181 installs libxcb from a repo on tooltool, then
> removes that repo.
> 
> You might experiment with trying to install the mesa stuff before `cp
> sources.list.orig /etc/apt/sources.list`?


Wrt to mesa, how can I find where the package in hosted?
All I know about it is this (from the puppet repo):
mesa -> ["libgl1-mesa-dri", "libgl1-mesa-glx", "libglapi-mesa", "libglu1-mesa", "libxatracker1", "libgl1-mesa-dev:i386"]:
          ensure => '8.0.4-0ubuntu0.6mozilla1';
I think those come from http://puppetagain.pub.build.mozilla.org/data/repos/apt/custom/mesa-lts-saucy/ ?  Although that has a very recent modification date, just a week or so ago, so maybe not.  I don't recall anything going on with mesa at that time.
that might be from bug 1220658.  We might want to use the old mesa until that get sorted out.
I appended this to /etc/apt/sources.list
deb http://puppetagain.pub.build.mozilla.org/data/repos/apt/releng/ precise main

Is this the right way of installing it? [1] I specified more packages as from looking at a test machine [2]
Should I generate an image based on this for now?
Should I open a separate bug for this mesa work and make less noise in here?

You mentioned that we would need to go about using this by putting this into tooltool.
I inspected the file referenced in here [3]
I see a bunch of .deb file and some metadata files and dist/ dir.
How do I go about generating something like it?

[1]
apt-get install -y --force-yes libgl1-mesa-dev:i386=8.0.4-0ubuntu0.6mozilla1 libgl1-mesa-dri=8.0.4-0ubuntu0.6mozilla1 libgl1-mesa-dri:i386=8.0.4-0ubuntu0.6mozilla1 libgl1-mesa-glx=8.0.4-0ubuntu0.6mozilla1 libgl1-mesa-glx:i386=8.0.4-0ubuntu0.6mozilla1 libglapi-mesa=8.0.4-0ubuntu0.6mozilla1 libglapi-mesa:i386=8.0.4-0ubuntu0.6mozilla1 libglu1-mesa=8.0.4-0ubuntu0.6mozilla1 libglu1-mesa:i386=8.0.4-0ubuntu0.6mozilla1 libxatracker1=8.0.4-0ubuntu0.6mozilla1 mesa-common-dev:i386=8.0.4-0ubuntu0.6mozilla1
[2]
[cltbld@tst-linux64-ec2-armenzg.test.releng.use1.mozilla.com ~]$ dpkg -l | grep 6mozilla1 | sort
ii  libgl1-mesa-dev:i386                   8.0.4-0ubuntu0.6mozilla1                free implementation of the OpenGL API -- GLX development files
ii  libgl1-mesa-dri                        8.0.4-0ubuntu0.6mozilla1                free implementation of the OpenGL API -- DRI modules
ii  libgl1-mesa-dri:i386                   8.0.4-0ubuntu0.6mozilla1                free implementation of the OpenGL API -- DRI modules
ii  libgl1-mesa-glx                        8.0.4-0ubuntu0.6mozilla1                free implementation of the OpenGL API -- GLX runtime
ii  libgl1-mesa-glx:i386                   8.0.4-0ubuntu0.6mozilla1                free implementation of the OpenGL API -- GLX runtime
ii  libglapi-mesa                          8.0.4-0ubuntu0.6mozilla1                free implementation of the GL API -- shared library
ii  libglapi-mesa:i386                     8.0.4-0ubuntu0.6mozilla1                free implementation of the GL API -- shared library
ii  libglu1-mesa                           8.0.4-0ubuntu0.6mozilla1                Mesa OpenGL utility library (GLU)
ii  libglu1-mesa:i386                      8.0.4-0ubuntu0.6mozilla1                Mesa OpenGL utility library (GLU)
ii  libxatracker1                          8.0.4-0ubuntu0.6mozilla1                X acceleration library -- runtime
ii  mesa-common-dev:i386                   8.0.4-0ubuntu0.6mozilla1                Developer documentation for Mesa

[3] https://dxr.mozilla.org/mozilla-central/source/testing/docker/ubuntu1204-test/system-setup.sh#181
[4] https://mozilla-releng-usw2-tooltool.s3-us-west-2.amazonaws.com/sha512/45005c7e1fdb4839f3bb96bfdb5e448672e7e40fa3cfc22ef646e2996a541f151e88c61b8a568cc00b7fcf5cb5e98e00c4e603acb0b73f85125582fa00aae76e?Signature=tTOHHkXRtWGRPZeogMcCi8l2FSM%3D&Expires=1448321058&AWSAccessKeyId=AKIAILEHYUYSBPB5N3DQ
(In reply to Armen Zambrano Gasparnian [:armenzg] from comment #35)
> Should I generate an image based on this for now?

For testing with in try, sure.

> Should I open a separate bug for this mesa work and make less noise in here?

Up to you -- other than mesa, are you ready to land a patch that includes gnome-desktop?

> How do I go about generating something like it?

There's an update.sh in that tarball which you can adapt to your purposes.  Bascially you put the .deb's you want into a subdirectory, run ./update.sh to generate the metadatas, and then tar up the whole thing.  If the image works out for you, I can build a repo with just the files you mentioned.
Spun off mesa work to bug 1227637.
dustin: there is a bunch of gnome-session output if you can see anything bad happening:
https://public-artifacts.taskcluster.net/AyJ9qF7-TBiinw2t9yo6GA/0/public/logs/live_backing.log

Any reason I can't wget that url without turning into gibberish in my disk?
I'm no better at reading such things than you are.  Anything in particular you're looking for?
I see:
gnome-session[41]: WARNING: Session 'ubuntu' runnable check failed: Exited with code 1
gnome-keyring-daemon: insufficient process capabilities, unsecure memory might get used
(gnome-settings-daemon:62): power-plugin-WARNING **: Unable to start power manager: RANDR extension is not present
(gnome-settings-daemon:62): color-plugin-WARNING **: Unable to start color manager: RANDR extension is not present
(gnome-settings-daemon:62): xrandr-plugin-WARNING **: Unable to start xrandr manager: RANDR extension is not present
** (gnome-settings-daemon:62): WARNING **: cannot connect to ConsoleKit: Could not connect: No such file or directory
(gnome-settings-daemon:62): media-keys-plugin-WARNING **: Failed to get proxy for upower: Could not connect: No such file or directory
unity-2d-shell: [34m[DEBUG][0m bool KeyMonitor::registerEvents(): Could not open device:  Virtual core pointer 
unity-2d-shell: [34m[DEBUG][0m bool KeyMonitor::registerEvents(): Could not open device:  Virtual core keyboard 
(polkit-gnome-authentication-agent-1:100): polkit-gnome-1-WARNING **: Error getting authority: Error initializing authority: Could not connect: No such file or directory


but it appears that we are still running gnome-session.  I recall seeing that locally as well.

Maybe we should see if this shows up on an ec2 instance- maybe we need to install a few other packages.  I would prefer to see that we fix the update prompt in bug 1227657, before doing too much.
Any ideas on how to put the test-linux.sh into its own artifact?
Or to append it at the very end once the Mozharness run is completed?

It is pretty difficult to figure out what is relevant and comparing logs from other runs.
For some reason the mochitest-6 and mochitest-9 time out while all the other ones run in a short time:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=2c1f486cc0ff

        Attachment #8691613 -
        Flags: feedback?(dustin)

    
    

    
  
In my last two pushes I managed to set NEED_PULSEAUDIO and mesa without increasing the number of jobs going green.

I assume the next two important matters is to fix the Ubuntu update prompt and uploading screenshots and other artifacts for failures.

    
    

    
  
Uploading test-linux.sh in production doesn't make much sense (by the same logic we should upload the entire gecko tree).  But for try it does.  Just have it cp itself into the artifact directory.

    
    

    
  
Comment on attachment 8691613 [details] [diff] [review]
WIP with window manager plus other changes

Review of attachment 8691613 [details] [diff] [review]:
-----------------------------------------------------------------

::: .hgignore
@@ +98,5 @@
>  ^testing/mozharness/logs/
>  ^testing/mozharness/build/
>  
> +# Ignore tox generated dir
> +.tox/

I don't think this would be objectionable, but I'm not sure why it's needed?

::: testing/docker/desktop-test/Dockerfile
@@ +46,5 @@
> +# Install pygtk (some mochitest were having an import failure)
> +# RUN pip install pygtk
> +
> +# XXX: add note why this is needed for
> +# http://mxr.mozilla.org/build/source/puppet/modules/gui/manifests/init.pp#81

Interesting, in https://bugzilla.mozilla.org/show_bug.cgi?id=838351#c3 this came from :digi, but was later described as "probably unnecessary".  If you've found something that succeeds with this included, and fails without, I'd be very interested!

::: testing/docker/ubuntu1204-test/system-setup.sh
@@ +112,5 @@
>  apt_packages+=('xvfb')
>  apt_packages+=('yasm')
>  apt_packages+=('zip')
>  
> +# install fonts to remove Xvfb errors during startup

Are these still needed with ubuntu-desktop, or does it pull the fonts in for you?

        Attachment #8691613 -
        Flags: feedback?(dustin) → feedback+

    
    

    
  
Comment on attachment 8691613 [details] [diff] [review]
WIP with window manager plus other changes

Review of attachment 8691613 [details] [diff] [review]:
-----------------------------------------------------------------

::: .hgignore
@@ +98,5 @@
>  ^testing/mozharness/logs/
>  ^testing/mozharness/build/
>  
> +# Ignore tox generated dir
> +.tox/

I only added it for when we run tox for Mozharness.
I can move it to another patch if preferred.

::: testing/docker/desktop-test/Dockerfile
@@ +46,5 @@
> +# Install pygtk (some mochitest were having an import failure)
> +# RUN pip install pygtk
> +
> +# XXX: add note why this is needed for
> +# http://mxr.mozilla.org/build/source/puppet/modules/gui/manifests/init.pp#81

I don't know if it fixes anything.
We can take on this patch only necessary parts and carry the rest forward.

::: testing/docker/ubuntu1204-test/system-setup.sh
@@ +112,5 @@
>  apt_packages+=('xvfb')
>  apt_packages+=('yasm')
>  apt_packages+=('zip')
>  
> +# install fonts to remove Xvfb errors during startup

jmaher suggested these changes. We can consider it optional until we hear otherwise.

    
    

    
  
I vote for removing the extra fonts I added and install what is necessary based on warnings/errors/failing tests.

    
    

    
  


  
I removed all changes that were not required.

        Attachment #8691613 -
        Attachment is obsolete: true

        Attachment #8692088 -
        Flags: review?(dustin)

    
    

    
  
Comment on attachment 8692088 [details] [diff] [review]
Enable window manager + use pulseaudio

Review of attachment 8692088 [details] [diff] [review]:
-----------------------------------------------------------------

::: testing/docker/desktop-test/Dockerfile
@@ +40,5 @@
>  RUN rm -Rf .cache && mkdir -p .cache
>  
> +# In case you end up wanting to run VNC
> +EXPOSE 5900
> +

Let's remove this -- the new interactive stuff should make this easier in TaskCluster, and for home use of the images I think you can do this on the command line, or at worst hack it into the Dockerfile temporarily.

        Attachment #8692088 -
        Flags: review?(dustin) → review+

    
    

    
  
OK, the images in this patch are all pushed to docker hub now.  You can land at will (with the EXPOSE removed).

    
    

    
  
Jonas, is there a bug with the work you have been doing with novnc? I'm guessing this work Armen has been doing might have some crossover with parts you have been working on - so wanted to bring this bug to your attention.
Flags: needinfo?(jopsen)

    
    

    
  
https://hg.mozilla.org/integration/mozilla-inbound/rev/6eeb5d9cc0d8a34303fa6871a58e0b130ec55131
Bug 1223123 - Enable pulse_audio for Linux64 TC desktop jobs + proper window manager. r=dustin

    
  
No longer depends on: 1225484

    
    

    
  
https://hg.mozilla.org/mozilla-central/rev/6eeb5d9cc0d8
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED

    
    

    
  
There is no novnc bug :)
It's not super relevant as the novnc feature hooks into existing X display servers,
so X11/window-manager config etc still lives in the image, not in docker-worker.

(nevertheless I look forward to playing with one of these images)
Flags: needinfo?(jopsen)

    
  
Product: Taskcluster → Taskcluster Graveyard

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: