I’m trying to package Screen Usage Monitor for aarch64. Compiling the application (if I click on the “Hammer”-Icon in the Sailfish IDE), works without errors but when I try to package the application (by clicking on the green “Play”-Icon in the Sailfish IDE), I get the following error (some parts translated from German, I appologise for possible translation errors):
Processing files: jolla-settings-screenmonitor-1.0.4-1.aarch64
error: File not found: /home/deploy/installroot/usr/bin
RPM build errors:
File not found: /home/deploy/installroot/usr/bin
15:58:02: The proccess "/home/nsc/SailfishOS/bin/sfdk" exitted with return code 1.
Error when creating/deploying the project jolla-settings-screenmonitor (Kit: SailfishOS-4.5.0.18-aarch64 (in Sailfish SDK Build Engine))
When executing the "RPM Build" step
Has anyone an idea what could be the problem here?
Spec file is the problem and using two names for package that leads to unexpected behaviour. %{_bindir} should be %{_bindir}/%{name}
but in this case replace %{_bindir}
with %{_bindir}/ScreenMonitor
Hmm, I have done what you suggested, but this just changes the error message to the new directory not being found. (I am quite new to RPM-packaging, so I am sorry if I don’t understand obvious things )
Processing files: jolla-settings-screenmonitor-1.0.4-1.aarch64
error: File not found: /home/deploy/installroot/usr/bin/ScreenMonitor
RPM build errors:
File not found: /home/deploy/installroot/usr/bin/ScreenMonitor
19:56:26: The process "/home/nsc/SailfishOS/bin/sfdk" exitted with return code 1.
Error when creating/deploying the project jolla-settings-screenmonitor (Kit: SailfishOS-4.5.0.18-aarch64 (in Sailfish SDK Build Engine))
When executing the "RPM Build" step
(I’ve uploaded the code here if you want to check)
The problem is not with the RPM spec file but with the .pro file. It’s written in such a way that qmake will not generate install rules for screenmonitor-executable unless ScreenMonitor already exists. Which means that if you run sfdk build twice it will succeed.
Easy fix would be adding screenmonitor-executable.CONFIG += no_check_exist to the .pro file.
Hmm, I might look into that, if I find the time. For now, I have modified it to use /usr/bin/systemctl which now complains that Unit file ScreenMonitor.service does not exist., which leads me to believe that it might not get bundled/installed with the RPM correctly?
Wrong/old-style path used again. This is now also /usr/lib/systemd/system. Again, use a macro in the .spec file For example %_unitdir/*.service. (Side note: an RPM file should also not own that directory, so /lib/systemd/system is doubly wrong.)
And check the .pro file so that it installs to the correct place.
Another side note: some might argue that one should use /etc/systemd instead of $PREFIX/lib/systemd with 3rd party packages, because $PREFIX/lib is supposed to be managed by the OS distribution, while /etc is for the local system administrator.
I can see why, but do not completely agree this applies to 3rd party packages.
Okay, so I recently picked up this project again. I made all the changes @nephros suggested (you can see them here and here )
But I still have the problem with the packaging:
RPM build errors:
error: File not found: /home/deploy/installroot/usr/lib/systemd/system/system/*.service
File not found: /home/deploy/installroot/usr/lib/systemd/system/system/*.service
I’ve also tried removing the /system/, but then the message just changes to File not found: /home/deploy/installroot/usr/lib/systemd/system/*.service
I also tried instead of * writing ScreenMonitor, same result.
I’ve also tried messing around with the .yaml-file for the RPM-packaging (here)but with no success.
Ok, in both the .spec and the .yaml, it’s %_unitdir/*.service, or the full name.
In the .pro, I’d just hardcode /usr instead of PREFIX to be consistent with the rest of the file.
Just changed …unitdir}/system/*.service to unitdir}/ScreenMonitor.service in your yaml and removed next line and it built successfully (resulting rpm here: https://files.catbox.moe/o111hy.rpm ), but you need to manually ‘systemctl enable /usr/lib/systemd/system/ScreenMonitor.service’ and then ‘systemctl start ScreenMonitor’ for it to run
Okay, now I have a real problem…
I had some (non-working) version of this installed on my device, which contains all the errors in the RPM and now it is not able to remove the old version(s).
It fails with this:
Installing jolla-settings-screenmonitor-1.0.6-1.aarch64.rpm
Please confirm installation on device.
jolla-settings-screenmonitor: Subprocess failed. Error: RPM failed: Created symlink /etc/systemd/system/graphical.target.wants/ScreenMonitor.service -> /home/nsc/SailfishOS/mersdk/targets/SailfishOS-4.5.0.18-aarch64.default/usr/lib/systemd/system/ScreenMonitor.service.
/var/tmp/rpm-tmp.z3nxq9: line 2: /bin/systemctl: not found
error: %preun(jolla-settings-screenmonitor-1.0.5-1.aarch64) scriptlet failed, exit status 127
error: jolla-settings-screenmonitor-1.0.5-1.aarch64: erase failed
/var/tmp/rpm-tmp.H7Oxba: line 2: /bin/systemctl: not found
error: %preun(jolla-settings-screenmonitor-1.0.4-1.aarch64) scriptlet failed, exit status 127
error: jolla-settings-screenmonitor-1.0.4-1.aarch64: erase failed
/var/tmp/rpm-tmp.nihc88: line 2: /bin/systemctl: not found
error: %preun(jolla-settings-screenmonitor-1.0.4-1.aarch64) scriptlet failed, exit status 127
error: jolla-settings-screenmonitor-1.0.4-1.aarch64: erase failed
(code: 58)
Installation failed
Deploy failed
Is there any way I can remove those broken packages?
Wow, it looks like this is more messed up than I thought. It listed 4 versions of this package to be installed, with your method I was able to remove two of them, for the rest it fails with this:
[defaultuser@NSC-Handy ~]$ devel-su rpm -e --noscripts --notriggers jolla-settings-screenmonitor-1.0.4-1.aarch64
Password:
Error: »jolla-settings-screenmonitor-1.0.4-1.aarch64« refers to several packages:
jolla-settings-screenmonitor-1.0.4-1.aarch64
jolla-settings-screenmonitor-1.0.4-1.aarch64
(translated from German)
How can I specify that I want to remove BOTH of them? And how can it even be that one package with the same version number is installed twice?
That’s what I normally do anyway, but it didn’t work here. As I come from a Debian/Ubuntu world, I didn’t even know anything about the RPM command, so I learned something new here
)