Using a chroot as working environment
Although WebKit working environment and building system is quite self contained, some people like still to work in a chroot so they can move the complete environment from a computer to another or from a distribution to a different one without major problems and keeping their own production environment clean and totally independent from WebKit development.
Working in a chroot, however, brings some drawbacks. Here you can find some tips, common problems and solutions.
Problems with shared memory
Different components and programs may need access to the shared memory and this may lead to some problems.
Running python based test with multiprocess support
For example, in WebKitGtkLayoutTests it is explained how to run WebKit tests.
I'm running my development environment in a schroot with Ubuntu in an Ubuntu host.
It hapenned to me the following error when trying to run the tests
$ ./Tools/Scripts/run-webkit-tests --gtk --debug
Using port 'gtk'
Test configuration: <, x86, debug>
Placing test results in /opt/webkit/WebKit.git/WebKitBuild/Debug/layout-test-results
Baseline search path: gtk -> generic
Using Debug build
Pixel tests disabled
Regular timeout: 12000, slow test timeout: 60000
Command line: /opt/webkit/WebKit.git/WebKitBuild/Debug/Programs/DumpRenderTree -
Found 31495 tests; running 28693, skipping 2802.
Running 4 DumpRenderTrees in parallel over 727 shards (1 locked).
Releasing server lock ...
OSError raised: [Errno 38] Function not implemented
File "/opt/webkit/WebKit.git/Tools/Scripts/webkitpy/layout_tests/run_webkit_tests.py", line 110, in run
unexpected_result_count = manager.run(args)
File "/opt/webkit/WebKit.git/Tools/Scripts/webkitpy/layout_tests/controllers/manager.py", line 411, in run
self._run_tests(self._test_names, result_summary, int(self._options.child_processes))
File "/opt/webkit/WebKit.git/Tools/Scripts/webkitpy/layout_tests/controllers/manager.py", line 464, in _run_tests
return self._runner.run_tests(test_inputs, self._expectations, result_summary, num_workers, needs_http, needs_websockets, self._retrying)
File "/opt/webkit/WebKit.git/Tools/Scripts/webkitpy/layout_tests/controllers/layout_test_runner.py", line 141, in run_tests
with message_pool.get(self, self._worker_factory, num_workers, self._port.worker_startup_delay_secs(), self._port.host) as pool:
File "/opt/webkit/WebKit.git/Tools/Scripts/webkitpy/common/message_pool.py", line 61, in get
return _MessagePool(caller, worker_factory, num_workers, worker_startup_delay_secs, host)
File "/opt/webkit/WebKit.git/Tools/Scripts/webkitpy/common/message_pool.py", line 79, in __init__
self._messages_to_worker = multiprocessing.Queue()
File "/usr/lib/python2.7/multiprocessing/__init__.py", line 218, in Queue
return Queue(maxsize)
File "/usr/lib/python2.7/multiprocessing/queues.py", line 63, in __init__
self._rlock = Lock()
File "/usr/lib/python2.7/multiprocessing/synchronize.py", line 147, in __init__
SemLock.__init__(self, SEMAPHORE, 1, 1)
File "/usr/lib/python2.7/multiprocessing/synchronize.py", line 75, in __init__
sl = self._semlock = _multiprocessing.SemLock(kind, value, maxvalue)
Failed to execute Tools/Scripts/new-run-webkit-tests at ./Tools/Scripts/run-webkit-tests line 126.
The reason is explained in this post http://www.boris.co/2012/02/server-ubuntu-11.html
Python's _multithreading requires /dev/shm to work.
WebView not rendering
When running a non-debug build of Gtk MiniBrowser, only a big grey rectangle is shown in the place where the web content should be. Pressing right click at some place in the grey area, different context menus are shown depending on the contents that should be there if the browser worked properly.
This problem is related to WB#117063.
SHM Fix
SHM Ubuntu
In Ubuntu /dev/shm points to /run/shm by default. One of the possible ways of fixing this is the one explained at http://www.boris.co/2012/02/server-ubuntu-11.html
However, in order provide a solution that will also cover pulse audio's case a good solution would be to bind mount /dev into the chroot and also /run/shm
Pulse Audio
In order to have the audio output working correctly pulse audio working in the chroot is not strictly needed. GStreamer, through the playbin2 element, tries to use pulsesink as audio sink but will fall to alsasink if pulsesink fails. In case the local pulse audio daemon is not making use of the audio device, alsa will work without problems in the chroot.
In any case, having pulse audio working in the chroot would be nice.
Pulse running user-wide
This is the default mode and the one shipped in most distributions. In this mode, only the process being run by the user and environment running the Pulse Audio server will be allowed to connect.
There are different ways of overcoming this limitation.
Fix through tcp connection
One of the simplest ones would be to set the local server to listen for TCP connections in the loopback interface, allowing any connection, and the Pulse client processes running in the chroot to connect to the server listening in the loopback interface. This can be sent system-wide, to all the users in the local host and the chroot or just per user.
This is an example of configuration for the Pulse server run by a user in the local host:
$ cat $HOME/.config/pulse/default.pa ... load-module module-native-protocol-tcp auth-anonymous=1 listen=127.0.0.1 ...
You may want to restart Pulse Audio's running server after changing this setting. You can do that with:
$ pulseaudio -k
This is an example of configuration for the Pulse clients run by a user in the chroot:
(webkit-chroot)$ cat $HOME/.config/pulse/client.conf ... default-server = 127.0.0.1:4713 ...
Fix through unix connection
This was a way of making a working connection to the pulse audio server running in the host while a soft link to the /tmp/pulse-XXXX working directory was stored at $HOME/.pulse/.
This is not like this any since the /tmp/pulse-XXXX directory is not created by pulse audio any more. Therefore, THIS METHOD IS NOT WORKING ANY MORE. You are free to correct this method for a way that would actually work.
This were the steps to follow, though ...
First, we have to make work /dev/shm (in some distributions, this is actually a soft link to /run/shm) following the instructions above.
We also need to mount bind /var/lib/dbus , ~/.pulse and /tmp.
For example, this is my working fstab file using schroot:
$ cat /etc/schroot/webkit/fstab # fstab: static file system information for chroots. # Note that the mount point will be prefixed by the chroot path # (CHROOT_PATH) # # <file system> <mount point> <type> <options> <dump> <pass> /proc /proc none rw,bind 0 0 /sys /sys none rw,bind 0 0 /dev /dev none rw,bind 0 0 /home /home none rw,bind 0 0 /tmp /tmp none rw,bind 0 0 # Added /var/lib/dbus /var/lib/dbus none rw,bind 0 0 /run/shm /run/shm none rw,bind 0 0 devpts /dev/pts devpts gid=5,mode=620 0 0 /opt/my-webkit-home /home/user none rw,bind 0 0 /home/user/.pulse /home/user/.pulse none rw,bind 0 0
Pulse running system-wide
In system-wide mode any client process can connect to the running pulse audio instance.
The complete information about this can be found at http://www.freedesktop.org/wiki/Software/PulseAudio/FAQ/#index36h3
As this is not the default running mode for pulse, you will have to set the proper setting:
$ cat /etc/pulse/daemon.conf
...
system-instance = yes
...
