While trying to build evolution as flatpak the evolution-data-server build fails with: ERROR: Command failed: # /usr/bin/systemd-nspawn -q -M 221f80f8b1d14268b0ffd938aff42a13 -D /var/lib/mock/module-evolution-master-3020190709134225-ThreadPoolExecutor-0_2/root -a --capability=cap_ipc_lock --bind=/tmp/mock-resolv.mrj0f11q:/etc/resolv.conf --setenv=TERM=vt100 --setenv=SHELL=/bin/bash --setenv=HOME=/builddir --setenv=HOSTNAME=mock --setenv=PATH=/usr/bin:/bin:/usr/sbin:/sbin --setenv=PROMPT_COMMAND=printf "\033]0;<mock-chroot>\007" --setenv=PS1=<mock-chroot> \s-\v\$ --setenv=LANG=en_US.utf8 -u mockbuild bash --login -c /usr/bin/rpmbuild -bb --target x86_64 --nodeps /builddir/build/SPECS/evolution-data-server.spec Checking the stderr log more carefully (the above line is the last printed in it) shows that systemd service files are installed into: /app/lib/systemd/user/ but the evolution-data-server.spec file references /usr/lib/systemd/user/ The thing is that this path comes from: %{_userunitdir}/evolution-addressbook-factory.service thus nothing I'd be able to influence. I do not know whom overwrites these macros and as the macros are overwritten in the fedmod already I'd start here, because you may want to overwrite also this one. If I'm wrong and this should go to systemd instead, then feel free to let me know or move it there. I'm fine with it. By the way, the last error in the stderr log is also rather cryptic, I'd not decipher from it that the .service files were not found where they had been expected.
We have been using the {?flatpak} macro provided by flatpak-rpm-macros to exclude files in unsupported prefixes. I have build gnome-maps which pulls in evolution-data-server, so for that I had it locally patched until I could finish the gnome-maps rpm2flatpak conversion. But since it would help you as well, I proposed the PR already in https://src.fedoraproject.org/rpms/evolution-data-server/pull-request/1
Right, I commented there as well. My main concern here is that the _userunitdir doesn't respect different prefix, which is bug of it. From my point of view, at least.
(In reply to Milan Crha from comment #2) > Right, I commented there as well. > > My main concern here is that the _userunitdir doesn't respect different > prefix, which is bug of it. From my point of view, at least. Any other prefix would prevent the host systemd from consuming the unit files. So the "proper" fix would be for Flatpak to start having a way for sandboxed apps to request (see the permission-store story) the installation of such files. For that, we have https://github.com/flatpak/flatpak/issues/2787 upstream.
Owen, can you take a look at this? I have no real idea about flatpak generation, besides that I'm on another team now and have only few cycles to spare on fedmod (none until early October when I return from vacation).
This message is a reminder that Fedora 30 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '30'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 30 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 30 changed to end-of-life (EOL) status on 2020-05-26. Fedora 30 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
Installing user units in /app/lib/systemd/user doesn't make much sense, so it's possible that the right resolution here is that someone needs to look, decide that the package is still useful without the user units and exclude explictly. But we could also add to macros.flatpak to make things rebuild more transparently. Going to reopen and update the version, since nothing was done here.
This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle. Changing version to 34.
I spent some time thinking of this issue and I think my conclusion is that the macros are all already correct. The directory where the systemd unit files should be installed is going to be always /usr/lib/system/systemd/, never /app/lib/system/systemd/. systemd just doesn't read anything from /app so it's conceptually incorrect for us to install systemd service files into /app. Because of this I don't think it makes sense to change systemd macros to use %prefix instead of /usr. The macros should always point to the location where the systemd is expecting them, so in our case in /usr for usr-installed systemd build. We of course have the issue how to handle this in flatpak builds :) What I think makes sense here is that even if we are building for prefix=/app, we should still install systemd unit files into /usr/lib, and then just discard them when building the actual flatpak container. Luckily, this is what is already happening (we discard anything that doesn't have /app prefix). So I think what we need is to fix all apps to make sure that they install the unit files into %{_userunitdir} (not prefix/lib/blah-blah), and make sure that their %files also lists %{_userunitdir}. This is going to expand as /usr/lib/..., which I think is the correct thing to do here (and also easiest way to handle it in the packaging side). As for evolution-data-service, I put together a MR that does this (and simplifies things!): https://src.fedoraproject.org/rpms/evolution-data-server/pull-request/4 As for libvirt, I would suggest changing it upstream so that it reads the directory to install into using pkg-config from systemd.pc. Alternatively, it could have an override in the build system where we can pass the directory to install into (similar to e-d-s's -DWITH_SYSTEMDUSERUNITDIR=%{_userunitdir}).
This message is a reminder that Fedora Linux 34 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '34'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 34 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 34 entered end-of-life (EOL) status on 2022-06-07. Fedora Linux 34 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. Thank you for reporting this bug and we are sorry it could not be fixed.