Re: HELP: Apply local patch in phase
> Hello,
>
> could you please suggest how to apply local patch using gexp?
>
> The reason the patch is not applied to source is that it patches code from
> submodule which is downloaded after unpack phase finishes.
Hi!
I'd personally avoid having anything download during build phases.
Actually, I thought Guix would disable network access at that point
anyway.
Are you using `(git-fetch)` with `(git-reference)` in `(origin)`? If
so, you can instruct Guix to automatically pull git submodules by
adding `(recursive? #t)` to `(git-reference)`. You can look at how it
is done in existing packages.
grep -RE 'recursive\?' -A2 -B4
~/.config/guix/current/share/guile/site/3.0/gnu/packages
Once you do this, you should be able to utilize the `(patches)` field
of `(origin)` as you normally would.
If the "submodule" you mentioned is not an actual git submodule, you
could probably instead write a separate `(origin)` definition for it
and `(ungexp)` that origin inside your phases definitions. See how it
is done in the gnome-recipes package[1].
Btw, you can use `$+` (aka `gexp-native`) instead of `#$`. The result,
in case of an origin, is the same (since origin's gexp compiler ignores
its `target` argument) but it's going to make more sense to the human
reader (I think).
Good luck,
Wojtek
[1]
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/gnome.scm?id=5f222e7b7a088d741027b8ab9908ecb4cc79751a#n843
-- (sig_start)
website: https://koszko.org/koszko.html
PGP: https://koszko.org/key.gpg
fingerprint: E972 7060 E3C5 637C 8A4F 4B42 4BC5 221C 5A79 FD1A
Meet Kraków saints! #41: blessed Piotr Dańkowski
Poznaj świętych krakowskich! #41: błogosławiony Piotr Dańkowski
https://pl.wikipedia.org/wiki/Piotr_Dańkowski
-- (sig_end)
On Wed, 28 Dec 2022 01:48:00 +
phodina via wrote:
> Hello,
>
> could you please suggest how to apply local patch using gexp?
>
> The reason the patch is not applied to source is that it patches code from
> submodule which is downloaded after unpack phase finishes.
>
> There's nice example in the file 'gnu/packages/games.scm'
>
> Here we list the patch as dependency:
> ```
> (native-inputs
> `(("unzip" ,unzip)
> ("patch" ,patch) ("love-11.patch" ,(search-patch
> "mrrescue-support-love-11.patch"
> ```
> Here's transformation to inputs without labels for my case:
> ```
> (native-inputs
> `(("unzip" ,unzip)
> ("patch" ,patch) ("love-11.patch" ,(search-patch
> "mrrescue-support-love-11.patch"
> ```
> And later we apply the patch:
> ```
> (invoke patch "-p1" "-i"
> (assoc-ref %build-inputs "love-11.patch")))
> ```
> The issue here is when I attempt to do so with following code the expression
> returns #f as the patch is not found:
> ```
> (invoke (search-input-file inputs "/bin/patch") "-p1" "-i" (search-input-file
> inputs "zenlib_dynamic_physfs.diff"))
> ```
>
> Any ideas what to change?
>
>
> Petr
pgpg_woBUwWmb.pgp
Description: OpenPGP digital signature
HELP: Apply local patch in phase
Hello,
could you please suggest how to apply local patch using gexp?
The reason the patch is not applied to source is that it patches code from
submodule which is downloaded after unpack phase finishes.
There's nice example in the file 'gnu/packages/games.scm'
Here we list the patch as dependency:
```
(native-inputs
`(("unzip" ,unzip)
("patch" ,patch) ("love-11.patch" ,(search-patch
"mrrescue-support-love-11.patch"
```
Here's transformation to inputs without labels for my case:
```
(native-inputs
`(("unzip" ,unzip)
("patch" ,patch) ("love-11.patch" ,(search-patch
"mrrescue-support-love-11.patch"
```
And later we apply the patch:
```
(invoke patch "-p1" "-i"
(assoc-ref %build-inputs "love-11.patch")))
```
The issue here is when I attempt to do so with following code the expression
returns #f as the patch is not found:
```
(invoke (search-input-file inputs "/bin/patch") "-p1" "-i" (search-input-file
inputs "zenlib_dynamic_physfs.diff"))
```
Any ideas what to change?
Petr
Re: Sourcing a script in phases
Hi, thanks for both ideas. I went the easiest path and opted for: (invoke "bash" "-c" "source env.sh && kmk") Not the most polished line of code but it moves me a step ahead :-D FIY: I'm attempting to build Virtualbox Petr
Re: Help with DBus Tests Failing for Python Package
Hello,
Jaft writes:
> So I tried a different tactic and, noticing the error said the issue
> was ~dbus-session~ didn't exist, did this, instead:
>
>> (arguments (list #:phases #~(modify-phases %standard-phases
>> (add-before 'check 'start-xserver
>> (lambda _
>> ;; Tests require a running dbus-daemon.
>> (system "dbus-daemon &")
>> ;; For missing '/etc/machine-id'.
>> (setenv "DBUS_FATAL_WARNINGS" "0"))
>> (inputs (list python python-pygobject))
>> (native-inputs (list xorg-server-for-tests))
>
> This works much better and the 232 tests get run; most, even pass…except 4.
> The output is thus:
>
>> test_get_object_path (tests.test_proxy.DBusProxyTestCase)
>> Test get_object_path. ... ok
>>
>> ==
>> FAIL: test_async_calls (tests.test_unix.DBusUnixExampleTestCase)
>> Test DBus async calls with fds.
>> --
>> Traceback (most recent call last):
>> File
>> "/tmp/guix-build-python-dasbus-1.7.drv-0/dasbus-1.7/tests/test_unix.py",
>> line 420, in test_async_calls
>> self._run_test()
>> File
>>"/tmp/guix-build-python-dasbus-1.7.drv-0/dasbus-1.7/tests/lib_dbus.py", line
>>194, in _run_test
>> self.assertEqual(client.exitcode, 0, msg)
>> AssertionError: 1 != 0 : _call_hello_async has finished with 1
>>
>> ==
>> FAIL: test_properties (tests.test_unix.DBusUnixExampleTestCase)
>> Test DBus properties with fds.
>> --
>> Traceback (most recent call last):
>> File
>> "/tmp/guix-build-python-dasbus-1.7.drv-0/dasbus-1.7/tests/test_unix.py",
>> line 457, in test_properties
>> self._run_test()
>> File
>>"/tmp/guix-build-python-dasbus-1.7.drv-0/dasbus-1.7/tests/lib_dbus.py", line
>>194, in _run_test
>> self.assertEqual(client.exitcode, 0, msg)
>> AssertionError: 1 != 0 : _set_pipes has finished with 1
>>
>> ==
>> FAIL: test_signals (tests.test_unix.DBusUnixExampleTestCase)
>> Test DBus signals with fds.
>> --
>> Traceback (most recent call last):
>> File
>> "/tmp/guix-build-python-dasbus-1.7.drv-0/dasbus-1.7/tests/test_unix.py",
>> line 481, in test_signals
>> self._run_test()
>> File
>>"/tmp/guix-build-python-dasbus-1.7.drv-0/dasbus-1.7/tests/lib_dbus.py", line
>>194, in _run_test
>> self.assertEqual(client.exitcode, 0, msg)
>> AssertionError: 1 != 0 : _trigger_signal has finished with 1
>>
>> ==
>> FAIL: test_sync_calls (tests.test_unix.DBusUnixExampleTestCase)
>> Test DBus sync calls with fds.
>> --
>> Traceback (most recent call last):
>> File
>> "/tmp/guix-build-python-dasbus-1.7.drv-0/dasbus-1.7/tests/test_unix.py",
>> line 398, in test_sync_calls
>> self._run_test()
>> File
>>"/tmp/guix-build-python-dasbus-1.7.drv-0/dasbus-1.7/tests/lib_dbus.py", line
>>194, in _run_test
>> self.assertEqual(client.exitcode, 0, msg)
>> AssertionError: 1 != 0 : _call_hello_sync has finished with 1
>>
>> --
>> Ran 232 tests in 681.414s
>>
>> FAILED (failures=4)
>> Test failed:
>> error: Test failed: > failures=4>
>> error: in phase 'check': uncaught exception:
>> %exception #<&invoke-error program: "python" arguments: ("-c"
>> "import setuptools, tokenize;__file__='setup.py';f=getattr(tokenize,
>> 'open', open)(__file__);code=f.read().replace('\r\n',
>> '\n');f.close();exec(compile(code, __file__, 'exec'))" "test")
>> exit-status: 1 term-signal: #f stop-signal: #f>
I bet this is because of the expectation of python-dbus on the processes
being reaped by PID 1 instead of staying around as zombies, as currently
happens in the Guix build container (see:
https://issues.guix.gnu.org/30948).
The current workaround currently used in Guix involves the use of tini
and of a forked process... it's not very pretty (see 'guix edit mutter'
for such an example).
Good luck!
--
Thanks,
Maxim
Re: Specifying rust version
Hi, phodina writes: [...] >> It's typical that build system or services expose a way for the user to >> use a variant of a package, but in the case of rust, I don't think it >> should be advertised as a way to use different rust versions (given only >> the last version is supported by upstream, e.g. sometimes fixing CVEs). > > I have to agree with you that this is just an anti-pattern and the #:rust > should not be advertised. > > The best approach would be to add new rust version and switch to it. > > So do you think Maxim the `#:rust` parameter should be dropped and the > documentation also removed? I don't think it needs to be dropped, as it can be useful for experimentation. Sometimes, newer rust may be needed and the work to update the entire collection (with the risks it entails or the build time) deferred, in which case it could be used. It's preferable though to do the work to package the latest and greatest rust and rebuild the whole collection with it, on a branch though. I hope that helps, -- Thanks, Maxim
Re: Specifying rust version
Hi, >> the documentation for 'cargo-build-system' [1] refers to parameter >> '#:rust' which allows user to specify the Rust compiler version. >> However, I've found this commit >> 9635119a61a9ab1b023558727fcdf1816fdc7fc6 from Maxim which makes all >> 'rust-.*' definitions private. Is there a way to specify newer Rust >> compiler? Something like 'rust-next'? The package requires version >> 1.62 but the current is 1.60. Also both version are already defined. >> What's missing is just way to select them. >> >> [1] https://guix.gnu.org/manual/en/html_node/Build-Systems.html >> > > I checked gnu/packages/rust.scm and it looks like the rust packages > aren't hidden but actually not exported. If they were just hidden then > you could still do `#:rust ,rust-1.62`. Since they're actually not > exported you need to use the not-really-supported `@@` to refer to that > variable, so you'd have to use something like: > #:rust ,(@@ (gnu packages rust) rust-1.62) Thanks Efraim, this is exactly what I've been looking for atm as temporary hack. > Given how it would be useful to have access to newer rust versions I > think it'd be worthwhile to make a post in guix-devel about making the > newer versions of rust use define-public but be hidden, so they can be > used as expected for the #:rust keyword. It would be definitely great to have access to the latest packaged version of rust. However, I understand this will trigger a lot of rebuilds. > > > > > > the documentation for 'cargo-build-system' [1] refers to parameter > > > '#:rust' which allows user to specify the Rust compiler version. > > > However, I've found this commit > > > 9635119a61a9ab1b023558727fcdf1816fdc7fc6 from Maxim which makes all > > > 'rust-.*' definitions private. Is there a way to specify newer Rust > > > compiler? Something like 'rust-next'? The package requires version > > > 1.62 but the current is 1.60. Also both version are already defined. > > > What's missing is just way to select them. > > > > > > [1] https://guix.gnu.org/manual/en/html_node/Build-Systems.html > > > > I checked gnu/packages/rust.scm and it looks like the rust packages > > aren't hidden but actually not exported. If they were just hidden then > > you could still do `#:rust ,rust-1.62`. Since they're actually not > > exported you need to use the not-really-supported `@@` to refer to that > > variable, so you'd have to use something like: > > #:rust ,(@@ (gnu packages rust) rust-1.62) > > > Normally only the newest released Rust version is supported by upstream, > so what we should do is add a newer rust and use it by default. > > The reasons previous rust versions are not exported is because they > aren't intended to be used by applications; they are built using > '--stage=1' to speed up compilation, which creates slower binaries and > may expose ABI stability problems (*if I remember the rust people's > explanation correctly). > > When adding new version of rust, we move all the tests and final rust > version specifics to the leaf (last) rust version, and keep the > intermediary rusts minimal (no test, no tools, stage=1, etc.) > > > Given how it would be useful to have access to newer rust versions I > > think it'd be worthwhile to make a post in guix-devel about making the > > newer versions of rust use define-public but be hidden, so they can be > > used as expected for the #:rust keyword. > > > It's typical that build system or services expose a way for the user to > use a variant of a package, but in the case of rust, I don't think it > should be advertised as a way to use different rust versions (given only > the last version is supported by upstream, e.g. sometimes fixing CVEs). I have to agree with you that this is just an anti-pattern and the #:rust should not be advertised. The best approach would be to add new rust version and switch to it. So do you think Maxim the `#:rust` parameter should be dropped and the documentation also removed? I guess same approach would apply for antioxidant-build-system, right? [1] 1 https://notabug.org/maximed/cargoless-rust-experiments Petr
Re: Specifying rust version
Hello, Efraim Flashner writes: > On Mon, Dec 26, 2022 at 09:00:40AM +, phodina wrote: >> Hi, >> >> the documentation for 'cargo-build-system' [1] refers to parameter >> '#:rust' which allows user to specify the Rust compiler version. >> However, I've found this commit >> 9635119a61a9ab1b023558727fcdf1816fdc7fc6 from Maxim which makes all >> 'rust-.*' definitions private. Is there a way to specify newer Rust >> compiler? Something like 'rust-next'? The package requires version >> 1.62 but the current is 1.60. Also both version are already defined. >> What's missing is just way to select them. >> >> [1] https://guix.gnu.org/manual/en/html_node/Build-Systems.html >> > > I checked gnu/packages/rust.scm and it looks like the rust packages > aren't hidden but actually not exported. If they were just hidden then > you could still do `#:rust ,rust-1.62`. Since they're actually not > exported you need to use the not-really-supported `@@` to refer to that > variable, so you'd have to use something like: > #:rust ,(@@ (gnu packages rust) rust-1.62) Normally only the newest released Rust version is supported by upstream, so what we should do is add a newer rust and use it by default. The reasons previous rust versions are not exported is because they aren't intended to be used by applications; they are built using '--stage=1' to speed up compilation, which creates slower binaries and may expose ABI stability problems (*if I remember the rust people's explanation correctly). When adding new version of rust, we move all the tests and final rust version specifics to the leaf (last) rust version, and keep the intermediary rusts minimal (no test, no tools, stage=1, etc.) > Given how it would be useful to have access to newer rust versions I > think it'd be worthwhile to make a post in guix-devel about making the > newer versions of rust use define-public but be hidden, so they can be > used as expected for the #:rust keyword. It's typical that build system or services expose a way for the user to use a variant of a package, but in the case of rust, I don't think it should be advertised as a way to use different rust versions (given only the last version is supported by upstream, e.g. sometimes fixing CVEs). -- Thanks, Maxim
Re: installing of two versions of package Musescore
Wojtek Kosior writes: > [[PGP Signed Part:Undecided]] > Hi Gottfried, > >> 3. I want to have "Musescore3.6.2" as the name of this profile, so that >> I quickly now what is in there. Is that possible? If not how this >> profile is specified to see the difference to my main profile? >> >> 4. what should I write in "path/to/profile" >> because AFAIU the profile will be in >> /etc/ >> >> like this?: >> >> profileMusescore3.6.2 >> >> /etc/profileMusescore3.6.2 >> >> "guix package --profileMusescore3.6.2=/etc/profileMusescore3.6.2" > > Good news for you — the profile does not need to reside under `/etc/`. > In fact, it would be abnormal to have a non-root user's profile there > since `/etc/` is usually only writeable by root. > > User's profiles usually live somewhere under the user's HOME directory. > I'd personally choose a path like `~/.guix-profiles/musescore-3.6.2`. > Someone else would perhaps use `~/.config/guix/Musescore3.6.2`. Just > pick what you like the most. I usually put them in project specific directories, like so: "$HOME/Graphics/.guix-profile" "$HOME/Projects/Advent of Code/2022/.guix-profile" and so on... I find that it's much easier to use than if they were centralized under one directory, because this way they are close to the project they correspond to. Also, a useful command to know: guix package --list-profiles
Re: Help with DBus Tests Failing for Python Package
Jaft writes:
> So I tried a different tactic and, noticing the error said the issue was
> ~dbus-session~ didn't exist, did this, instead:
>
>> (arguments (list #:phases #~(modify-phases %standard-phases
>> (add-before 'check 'start-xserver
>> (lambda _
>> ;; Tests require a running dbus-daemon.
>> (system "dbus-daemon &")
>> ;; For missing '/etc/machine-id'.
>> (setenv "DBUS_FATAL_WARNINGS" "0"))
>> (inputs (list python python-pygobject))
>> (native-inputs (list xorg-server-for-tests))
>
> This works much better and the 232 tests get run; most, even pass…except 4.
> The output is thus:
>
>> test_get_object_path (tests.test_proxy.DBusProxyTestCase)
>> Test get_object_path. ... ok
>>
>> ==
>> FAIL: test_async_calls (tests.test_unix.DBusUnixExampleTestCase)
>> Test DBus async calls with fds.
>> --
>> Traceback (most recent call last):
>> File
>>"/tmp/guix-build-python-dasbus-1.7.drv-0/dasbus-1.7/tests/test_unix.py", line
>>420, in test_async_calls
>> self._run_test()
>> File
>>"/tmp/guix-build-python-dasbus-1.7.drv-0/dasbus-1.7/tests/lib_dbus.py", line
>>194, in _run_test
>> self.assertEqual(client.exitcode, 0, msg)
>> AssertionError: 1 != 0 : _call_hello_async has finished with 1
>>
>> ==
>> FAIL: test_properties (tests.test_unix.DBusUnixExampleTestCase)
>> Test DBus properties with fds.
>> --
>> Traceback (most recent call last):
>> File
>>"/tmp/guix-build-python-dasbus-1.7.drv-0/dasbus-1.7/tests/test_unix.py", line
>>457, in test_properties
>> self._run_test()
>> File
>>"/tmp/guix-build-python-dasbus-1.7.drv-0/dasbus-1.7/tests/lib_dbus.py", line
>>194, in _run_test
>> self.assertEqual(client.exitcode, 0, msg)
>> AssertionError: 1 != 0 : _set_pipes has finished with 1
>>
>> ==
>> FAIL: test_signals (tests.test_unix.DBusUnixExampleTestCase)
>> Test DBus signals with fds.
>> --
>> Traceback (most recent call last):
>> File
>>"/tmp/guix-build-python-dasbus-1.7.drv-0/dasbus-1.7/tests/test_unix.py", line
>>481, in test_signals
>> self._run_test()
>> File
>>"/tmp/guix-build-python-dasbus-1.7.drv-0/dasbus-1.7/tests/lib_dbus.py", line
>>194, in _run_test
>> self.assertEqual(client.exitcode, 0, msg)
>> AssertionError: 1 != 0 : _trigger_signal has finished with 1
>>
>> ==
>> FAIL: test_sync_calls (tests.test_unix.DBusUnixExampleTestCase)
>> Test DBus sync calls with fds.
>> --
>> Traceback (most recent call last):
>> File
>>"/tmp/guix-build-python-dasbus-1.7.drv-0/dasbus-1.7/tests/test_unix.py", line
>>398, in test_sync_calls
>> self._run_test()
>> File
>>"/tmp/guix-build-python-dasbus-1.7.drv-0/dasbus-1.7/tests/lib_dbus.py", line
>>194, in _run_test
>> self.assertEqual(client.exitcode, 0, msg)
>> AssertionError: 1 != 0 : _call_hello_sync has finished with 1
>>
>> --
>> Ran 232 tests in 681.414s
>>
>> FAILED (failures=4)
>> Test failed:
>> error: Test failed: > failures=4>
>> error: in phase 'check': uncaught exception:
>> %exception #<&invoke-error program: "python" arguments: ("-c"
>> "import setuptools, tokenize;__file__='setup.py';f=getattr(tokenize,
>> 'open', open)(__file__);code=f.read().replace('\r\n',
>> '\n');f.close();exec(compile(code, __file__, 'exec'))" "test")
>> exit-status: 1 term-signal: #f stop-signal: #f>
>
> It doesn't look like enough to clearly tell /why/ things failed (and
> looking through the source of the particular failing tests isn't much
> clearer, for me, unfortunately) but maybe someone's run across a
> similar experience, before, that might indicate something to try.
Just a guess but maybe you should wrap the check phase in dbus-run-session.
Re: Help with DBus Tests Failing for Python Package
So I tried a different tactic and, noticing the error said the issue was
~dbus-session~ didn't exist, did this, instead:
> (arguments (list #:phases #~(modify-phases %standard-phases
> (add-before 'check 'start-xserver
> (lambda _
> ;; Tests require a running dbus-daemon.
> (system "dbus-daemon &")
> ;; For missing '/etc/machine-id'.
> (setenv "DBUS_FATAL_WARNINGS" "0"))
> (inputs (list python python-pygobject))
> (native-inputs (list xorg-server-for-tests))
This works much better and the 232 tests get run; most, even pass…except 4. The
output is thus:
> test_get_object_path (tests.test_proxy.DBusProxyTestCase)
> Test get_object_path. ... ok
>
> ==
> FAIL: test_async_calls (tests.test_unix.DBusUnixExampleTestCase)
> Test DBus async calls with fds.
> --
> Traceback (most recent call last):
> File
>"/tmp/guix-build-python-dasbus-1.7.drv-0/dasbus-1.7/tests/test_unix.py", line
>420, in test_async_calls
> self._run_test()
> File
>"/tmp/guix-build-python-dasbus-1.7.drv-0/dasbus-1.7/tests/lib_dbus.py", line
>194, in _run_test
> self.assertEqual(client.exitcode, 0, msg)
> AssertionError: 1 != 0 : _call_hello_async has finished with 1
>
> ==
> FAIL: test_properties (tests.test_unix.DBusUnixExampleTestCase)
> Test DBus properties with fds.
> --
> Traceback (most recent call last):
> File
>"/tmp/guix-build-python-dasbus-1.7.drv-0/dasbus-1.7/tests/test_unix.py", line
>457, in test_properties
> self._run_test()
> File
>"/tmp/guix-build-python-dasbus-1.7.drv-0/dasbus-1.7/tests/lib_dbus.py", line
>194, in _run_test
> self.assertEqual(client.exitcode, 0, msg)
> AssertionError: 1 != 0 : _set_pipes has finished with 1
>
> ==
> FAIL: test_signals (tests.test_unix.DBusUnixExampleTestCase)
> Test DBus signals with fds.
> --
> Traceback (most recent call last):
> File
>"/tmp/guix-build-python-dasbus-1.7.drv-0/dasbus-1.7/tests/test_unix.py", line
>481, in test_signals
> self._run_test()
> File
>"/tmp/guix-build-python-dasbus-1.7.drv-0/dasbus-1.7/tests/lib_dbus.py", line
>194, in _run_test
> self.assertEqual(client.exitcode, 0, msg)
> AssertionError: 1 != 0 : _trigger_signal has finished with 1
>
> ==
> FAIL: test_sync_calls (tests.test_unix.DBusUnixExampleTestCase)
> Test DBus sync calls with fds.
> --
> Traceback (most recent call last):
> File
>"/tmp/guix-build-python-dasbus-1.7.drv-0/dasbus-1.7/tests/test_unix.py", line
>398, in test_sync_calls
> self._run_test()
> File
>"/tmp/guix-build-python-dasbus-1.7.drv-0/dasbus-1.7/tests/lib_dbus.py", line
>194, in _run_test
> self.assertEqual(client.exitcode, 0, msg)
> AssertionError: 1 != 0 : _call_hello_sync has finished with 1
>
> --
> Ran 232 tests in 681.414s
>
> FAILED (failures=4)
> Test failed:
> error: Test failed: failures=4>
> error: in phase 'check': uncaught exception:
> %exception #<&invoke-error program: "python" arguments: ("-c" "import
> setuptools, tokenize;__file__='setup.py';f=getattr(tokenize, 'open',
> open)(__file__);code=f.read().replace('\r\n',
> '\n');f.close();exec(compile(code, __file__, 'exec'))" "test") exit-status: 1
> term-signal: #f stop-signal: #f>
It doesn't look like enough to clearly tell /why/ things failed (and looking
through the source of the particular failing tests isn't much clearer, for me,
unfortunately) but maybe someone's run across a similar experience, before,
that might indicate something to try.
On Monday, December 26, 2022 at 10:18:55 PM CST, Jaft
wrote:
> I'm attempting to package the Python package DasBus
> (https://github.com/rhinstaller/dasbus/) and the tests, when it tries to test
> by making DBus calls, are failing.
>
> For specificity, the error output is:
>
> > test_additional_arguments (tests.test_dbus.DBusExampleTestCase)
> > Call a DBus method. ... **
> > GLib-GIO:ERROR:../glib-2.70.2/gio/gtestdbus.c:667:start_daemon: assertion
> > failed (error == NULL): Failed to execute child process “dbus-daemon” (No
> > such file or directory) (g-exec-error-quark, 8)
> > Bail out! GLib-GIO:ERROR:../glib-2.70.2/gio/gtestdbus.c:667:start_daemon:
> > assertion failed (error == NULL): Failed to execute child proc
