Formatting fix and sed for KCoreAddons fix

[pfeerick]

This started as fixing a formatting issue and adding the sed one-liner... Two commands were being merged into one, and a one line sed command to fix the kcoreaddons dependency name issue.

And also now includes some subsequent typos/missing bits found when getting the build working at last ;)

[pfeerick]

Hm, should I add something about the service ExecPath being wrong, or can that be fixed in the code? Also, I suppose instruction on how to start and enable the service would be good to add also? i.e.

Enabling the service

Now that you have installed Amazfish, the systemd service needs to have the path tweaked, and then the service can be enabled and then started.

blurb on tweaking the execpath

sudo sed -i 's+/usr/bin/harbour-amazfishd+/usr/local/bin/harbour-amazfishd+' '/usr/local/lib/systemd/user/harbour-amazfish.service'

To enable and start the amazfish background service, run the following two commands:

sudo systemctl --user enable /usr/local/lib/systemd/user/harbour-amazfish.service
sudo systemctl --user start harbour-amazfish

Or words to that effect?

[piggz]

The path is supposed to be handled automatically already. Is it possible you had an old version around? Try removing the file, issuing a "make clean && sudo make install" in the build folder to double check.

[piggz]

I read a discussion last night about a user struggling with qt4 .... on my system, qmake is actually qmake-qt5, so maybe add this as an option in the doc.

Also, I have just removed the requirement for KContacts, it was actually used (yet) but i would leave it in the doc as an option for the future anyway.

[pfeerick]

~I doubt it (old version), as I only just got it built this morning, from code pulled either yesterday or the day before, but I will give it a try anyway just to be sure.~ Actually, it probably old code on my part... I see you made changes yesterday which looks like it determines what PREFIX to use for the Execpath, and I didn't check for changes to the repo this morning, so that hasn't been included. I'll try again tomorrow and see what happens.

The user struggling with qt4 atm on debian is most likely due to pre-existing stuff QT4 stuff installed on the system, and everything just going pear shaped, as the Makefile is referencing QT5 properly, but make then still goes and looks for something QT4 just to confuse. I'll make sure the references to qmake are qmake-qt5 though.

[pfeerick]

New day, fresh pull from the repo and a make clean and other spring cleaning later... the paths are correct in the service, but now there is ... more of an annoyance than an issue... at hand...

With the creation of the service file as follows:

[Unit]
Description=Amazfish daemon
After=graphical.target

[Service]
ExecStart=/usr/local/bin/harbour-amazfishd
Restart=always
RestartSec=5
Environment=HOME=%h XDG_CONFIG_HOME=/home/%u/.config DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/%U/bus XDG_RUNTIME_DIR=/run/user/%U

when enabled (i.e. systemctl --user enable harbour-amazfish) it does enable, but also spits out this blurb. So a different ... type? ... is needed.

The unit files have no installation config (WantedBy=, RequiredBy=, Also=,
Alias= settings in the [Install] section, and DefaultInstance= for template
units). This means they are not meant to be enabled using systemctl.

Possible reasons for having this kind of units are:
• A unit may be statically enabled by being symlinked from another unit's
  .wants/ or .requires/ directory.
• A unit's purpose may be to act as a helper for some other unit which has
  a requirement dependency on it.
• A unit may be started when needed via activation (socket, path, timer,
  D-Bus, udev, scripted systemctl call, ...).
• In case of template units, the unit is meant to be enabled with some
  instance name specified.

Addition of

[Install]
WantedBy=default.target

to the service file (or the template ) not only prevents this spew of info, but also allows the service to auto-start on boot/login. I was able to restart my Ubuntu system and after login and bluetooth waking up, the amazfish service automatically connected to the pinetime/infinitime without any user interaction.

[piggz]

Yes, i considered this when creating the service. On sailfish it is quite easy, because there is a user-session.target, for general linux I wasnt sure when the user session is running. It could be default, or graphical I guess. With default, does the service only start when the user logs in? Thats how it needs to work because it has to communicate on the same user session dbus bus.

[pfeerick]

Since it's enabled at the user level, it won't be able to start before the user logs in.

The systemd user instance is started after the first login of a user and killed after the last session of the user is closed.

I would use default.target over graphical.target simply because 1) it's the target used by the Arch wiki examples for user services, and 2) is there actually a requirement that the graphical UI be present for the service to function? If not, this would probably allow it to function with console logins as well. Either way, as I said before, using default.target is working for me with no intervention/interaction required to get the service running.