I'd like to run some unit tests as part of an RPM build. I've set it up so that Xvnc gets started and the tests run in it (some are GUI tests that need X to run). This fails in koji due to the fact that dbus can't start. Colin Walters kindly wrote a small patch to fix this and posted it here:
In case that gets erased, I'll copy it here:
diff --git a/py/mock/backend.py b/py/mock/backend.py
index 3cc0a9f..566f615 100644
@@ -13,6 +13,7 @@ import logging
# our imports
@@ -207,6 +208,7 @@ class Root(object):
self.root_log.debug('touch required files')
for item in [self.makeChrootPath('etc', 'mtab'),
+ self.makeChrootPath('var', 'lib', 'dbus')]:
self.makeChrootPath('var', 'log', 'yum.log')]:
@@ -233,6 +235,15 @@ class Root(object):
+ # Anything that tries to use libdbus inside the chroot will require this
+ # FIXME - merge this code with other OS-image building code
+ machine_uuid = uuid.uuid4().hex()
+ dbus_uuid_path = self.makeChrootPath('var', 'lib', 'dbus', 'machine-id')
+ f = open(dbus_uuid_path, 'w')
# files in /etc that need doing
for key in self.chroot_file_contents:
p = self.makeChrootPath(key)
I don't have any fundamental objection to having the ability to use dbus in the chroot, but I wonder if there are going to be any side effects of having (at least) two dbus daemons running on a system?
There's normally at least two - the system bus and the per-user session bus. This patch simply enables the session bus to run; there should be no effect whatsoever on the rest of the OS.
Starting a system bus in the chroot is a different matter and while it would likely mostly work I would strongly discourage people from doing that. But this bug was about the session.
Ugh, I missed this in the 0.9.14 spin. queued for 0.9.15