build: Call 'systemd-tmpfiles --create' when installing #965
Conversation
|
Build failed.
|
|
recheck |
|
Build failed.
|
|
recheck |
|
Build failed.
|
|
Did you try running this locally? On my machine (when ran inside of a toolbx) this often results in: The goal of this step is to create |
HarryMichal
added
2. Build System
I only tried the build with By the way, this makes me think that we need a test that tries to build Toolbox from source inside a Toolbox container. |
Do we? I'm wondering why is that required. What does it test? That Toolbx is buildable? That a software can be built? If we were to add this test, it should not exist in the system tests but in a different group of tests. |
It's required because our test suite clearly failed to catch that this pull request breaks the build inside a Toolbx container. :)
It should test that Toolbx can be built from source inside a Toolbx container. Toolbx is necessary for hacking on Toolbx, so we shouldn't be pushing changes that break the build. |
Technically speaking Toolbx can be built even without this fix being applied. It can not be run though due to missing
Despite what I've written above, I agree the test can be written but I still believe such a test should exist outside of the current system test test suite.
This generally applies only to Fedora Silverblue. |
In the past,
Does this snippet actually work? Or is it meant to be pseudo-code? :) The build failed inside a Toolbx container because |
Eh? :) This pull request is trying to fix #955 which is about the built binary Since we are trying to fix #955, we might as well ensure that we do so without breaking the build. :)
It doesn't matter so much exactly what we call the test, as long as it tests the right thing and it is called from
... and Fedora Silverblue is the primary reason for Toolbx to exist. It will be a major problem if it becomes impossible to hack on Toolbx on a Silverblue system. |
This is true but The reason for the suggestion is not to have a failing statement as part of Toolbx build. That way we'll never get a successful build.
Yes, it works :). Comparison of the ; systemd-tmpfiles --create
Failed to open directory 'cryptsetup': Permission denied
Failed to open directory 'portables': Permission denied
Failed to open directory 'sudo': Permission denied
Failed to open directory 'ts': Permission denied
Failed to open directory 'svnserve': Permission denied
fchownat() of /var/lib/systemd/coredump failed: Read-only file system
Failed to open directory 'private': Permission denied
Failed to open directory 'private': Permission denied
Failed to open directory 'private': Permission denied
fchownat() of /tmp failed: Operation not permitted
Setting access ACL "u::rwx,g::r-x,g:adm:r-x,g:wheel:r-x,g:4294967295:r-x,g:4294967295:r-x,m::r-x,o::r-x" on /var/log/journal failed: Read-only file system
Failed to re-open '/var/log/journal': Operation not permitted
fchownat() of /var/log/journal failed: Read-only file system
Setting access ACL "u::rwx,g::r-x,g:adm:r-x,g:wheel:r-x,g:4294967295:r-x,g:4294967295:r-x,m::r-x,o::r-x" on /var/log/journal/64ea8f1e4b534013843813476c178ab7 failed: Read-only file system
Failed to re-open '/var/log/journal/64ea8f1e4b534013843813476c178ab7': Operation not permitted
fchownat() of /var/log/journal/64ea8f1e4b534013843813476c178ab7 failed: Read-only file system
fchownat() of /dev/snd/seq failed: Operation not permitted
fchownat() of /dev/snd/timer failed: Operation not permitted
fchownat() of /dev/loop-control failed: Operation not permitted
fchownat() of /dev/kvm failed: Operation not permitted
fchownat() of /dev/vhost-net failed: Operation not permitted
fchownat() of /dev/vhost-vsock failed: Operation not permitted
Setting access ACL "u::rw-,g::r-x,g:adm:r--,g:wheel:r--,g:4294967295:r--,g:4294967295:r--,m::r--,o::---" on /var/log/journal/64ea8f1e4b534013843813476c178ab7/system.journal failed: Read-only file system
fchownat() of /var/log/journal/64ea8f1e4b534013843813476c178ab7/system.journal failed: Read-only file system
Setting default ACL "u::rwx,g::rwx,g:tss:rwx,m::rwx,o::r-x" on /var/lib/tpm2-tss/system/keystore failed: Operation not permitted
Setting default ACL "u::rwx,g::rwx,g:tss:rwx,m::rwx,o::r-x" on /run/tpm2-tss/eventlog failed: Operation not permitted
; echo $status
73
; systemd-tmpfiles --create --prefix=/run/host /var/home/marty/Documents/projects/toolbox/data/tmpfiles.d/toolbox.conf
; echo $status
0
|
debarshiray
force-pushed
the
wip/rishi/call-systemd-tmpfiles
branch
from
1cc8083 to
73a33e2
Compare
Ideally, we don't want to differentiate between breakages. We want our build to generate a fully working binary, as far as reasonably and practically possible. Also, replicating a different subset of the files in
Umm... I didn't understand.
I asked because this snippet didn't look valid: ... and the Meson logs didn't exactly match what I was seeing. eg., I suppose you had defined
We are talking about |
|
Build succeeded.
|
debarshiray
force-pushed
the
wip/rishi/call-systemd-tmpfiles
branch
from
73a33e2 to
cc26c42
Compare
|
Build failed.
|
It's only necessary to call 'systemd-tmpfiles --create' when building
and installing from source on the host operating system.
It's not needed when using a pre-built binary downstream package,
because:
* When 'meson install' is called as part of building the package,
that's not when the temporary files need to be created. They need
to be created when the binary package is later downloaded and
installed by the user.
* Downstream tools can sometimes handle it automatically. eg., on
Fedora, the systemd RPM installs a trigger that tells RPM to call
'systemd-tmpfiles --create' automatically when a tmpfiles.d snippet
is installed.
It's also not needed when installing inside a toolbox container because
the files that 'systemd-tmpfiles --create' is supposed to create are
meant to be on the host.
Downstream distributors set the DESTDIR environment variable when
building their packages. Therefore, it's used to detect when a
downstream package is being built.
Unfortunately, environment variables are messy and, generally, Meson
doesn't support accessing them inside its scripts [1]. Therefore, this
adds a spurious build-time dependency on systemd for downstream
distributors. However, that's probably not a big problem because all
supported downstream operating systems are already expected to use
systemd for the tmpfiles.d(5) snippets to work.
[1] mesonbuild/meson#9
containers#955
Fair enough.
Fair enough.
Reason why I'm suggesting to run
Of course And
I don't understand what do you mean by "
Of course. Still, the point about |
I still don't understand. Why would we run a subset of the It already works without a subset. We detect that we are inside a container and skip the
Ah, you are right that it's failing because the locations are owned by Regardless, why |
debarshiray
force-pushed
the
wip/rishi/call-systemd-tmpfiles
branch
from
cc26c42 to
be2ba6d
Compare
|
Build succeeded.
|
It's only necessary to call 'systemd-tmpfiles --create' when building
and installing from source, and not when using a downstream package,
because:
When 'meson install' is called as part of building the package,
that's not when the temporary files need to be created. They need
to be created when the package is later downloaded and installed
by the user.
Downstream tools can sometimes handle it automatically. eg., on
Fedora, the systemd RPM installs a trigger that tells RPM to call
'systemd-tmpfiles --create' automatically when a tmpfiles.d snippet
is installed.
#955