I got curious (and i guess i should have been from the beginning), it starts just fine for me - after installing background services and tapping that checkmark button.
Not really used the app before, so that could be a difference.
Worked fine here, after first click on the green icon got the install prompt for the daemon, after install second click proceeded to intro of the app (XIII 4.5.0.21)
Edit: also clean first install here
For me it’s not running. service was istalled successfully and is running. But when tapping on the green checkmark button, it just changes to a plus icon again. (Xperia X II 4.5.0.21)
1 Like
I wonder if it could be the local socket name (“com.pastillilabs.situations:server”) causing problems on some devices / setups. It has not changed from the previous version - but then again I know that it did earlier cause problems on some Android devices.
So, I’ve updated the packages in github to use much simpler “situationsserver” name instead. Could someone with the problem please try again with the latest package?
I installed the updated version. Nothing’s changed on my end.
Edit: This is what I get when I start the app through the terminal -
harbour-situations2application
[D] unknown:0 - Using Wayland-EGL
library “libutils.so” not found
library “libcutils.so” not found
library “libhardware.so” not found
library “android.hardware.graphics.mapper@2.0.so” not found
library “android.hardware.graphics.mapper@2.1.so” not found
library “android.hardware.graphics.mapper@3.0.so” not found
library “android.hardware.graphics.mapper@4.0.so” not found
library “libc++.so” not found
library “libhidlbase.so” not found
library “libgralloctypes.so” not found
library “android.hardware.graphics.common@1.2.so” not found
library “libion.so” not found
library “libz.so” not found
library “libhidlmemory.so” not found
library “android.hidl.memory@1.0.so” not found
library “vendor.qti.qspmhal@1.0.so” not found
[W] unknown:203 - qrc:/qml/application/Welcome.qml:203:21: QML ListView: Binding loop detected for property “height”
The phone doesn’t even open the app properly. I only get a spinning wheel loop.
version number is still the same?
I downloaded and installed it again. Unfortunately with the same behaviour.
starting situations from cli unfortunately doesn’t work. Only the startscreen with the spinning situations icon is loaded.
1 Like
Ok, thanks! Any chance you could retry also with a clean ~/.local/share/harbour-situations2application folder? And by killing any existing server instace before trying it?
I deinstalled situations, checked, that the service isn’t still running in the background, deleted ~/.local/share/harbour-situations2application as well as ~/.config/harbour-situations2application.
Installed it again. Unfortunately still the same problem.
After installation I checked both folders. They are still empty. Better to say in ~/.local/share/harbour-situations2application there is an empty situations folder.
Starting to get out of ideas 
Do you see anything interesting in system logs (journalctl) when starting the UI?
Completely another thing mentioned already in maemo.org - again copy-pasting:
"Another known issue is that single instance app launching does not work - with the Launch action or from tapping a notification, Situations used to call invoker which had a single instance flag. But it is not there anymore.
If anyone knows how to do it properly, I’d appreciate some knowledge sharing. Current version uses ContentAction::Action::launcherAction for it."
Out of curiosity installed .284, can’t install .285 over it (endless spinning symbol), can’t now install even after uninstalling .284, so seems to be the culprit (though again endless spinner on black background, not even getting the install page with green icon)
1 Like
I have seen that ‘Situations loads its splash screen forever’ thing frequently in past versions too.
Sometimes, it does start after a while (like several minutes), sometimes not. Sometimes it doesn’t happen at all.
Never got to the cause of it, but it may be related to networking, so try around with/without wifi, mobile network, airplane mode…
(Note by splash screen I mean the Situations own splash screen, NOT the native Lipstick launch spinner).
Ok, uninstalling still left ‘/usr/bin/harbour-situations2application server’ process running, killing that helped and managed to get back to the intro screen with green icon and .285 installed correctly with its daemon once again, that could be the cause of endless spinner for at least some
I too am a bit confused over that access to singleton behaviour is not readily available, despite clearly being done for us in simple cases.
Here is me doing it the complicated way:
Note especially dbusadaptor-files, .desktop and main().
So what this does is that if the app is not available on dbus, it gets started (with the prestart flag or whatever you like), and once available the standard freedesktop method is called.
On top of that i have since added my own dbus methods that are easier to call - this is how i start the app from a sharing plugin, while still maintaining a single, jailed, instance.
Freedesktop methods didn’t use to be callable from the declarative dbus plugin (fancy data type), so until last release it was even strictly necessary.
2 Likes
Don’t think, this is if helpful?:
[root@Xperia10II-DualSIM defaultuser]# journalctl | grep situations
Jul 28 09:45:08 Xperia10II-DualSIM invoker[14430]: warning: enforcing sandboxing for ‘/usr/bin/harbour-situations2application’
Jul 28 09:45:09 Xperia10II-DualSIM harbour-situations2application[14535]: [D] unknown:0 - Using Wayland-EGL
Jul 28 09:45:10 Xperia10II-DualSIM harbour-situations2application[14535]: [W] unknown:203 - qrc:/qml/application/Welcome.qml:203:21: QML ListView: Binding loop detected for property “height”
Jul 28 09:45:11 Xperia10II-DualSIM lipstick[14427]: [D] onCompleted:320 - coverActionIndicators created harbour-situations2application.desktop
Jul 28 09:45:34 Xperia10II-DualSIM llationhandler[2080]: [D] unknown:0 - RPM Package info: “situations-daemon” “1.0” “Background service launcher and plugins for Situations”
Jul 28 09:45:35 Xperia10II-DualSIM lipstick[14427]: [D] unknown:0 - Specified Desktop file does not exist “/usr/share/applications/situations-daemon.desktop”
Jul 28 09:45:37 Xperia10II-DualSIM [RPM][15094]: erase situations-daemon-1.0-0.aarch64: success
Jul 28 09:45:37 Xperia10II-DualSIM [RPM][15094]: install situations-daemon-1.0-0.aarch64: success
Jul 28 09:45:37 Xperia10II-DualSIM [RPM][15094]: erase situations-daemon-1.0-0.aarch64: success
Jul 28 09:45:37 Xperia10II-DualSIM [RPM][15094]: install situations-daemon-1.0-0.aarch64: success
Jul 28 09:45:38 Xperia10II-DualSIM lipstick[14427]: [D] displayNotification:549 - Warning: Notification has both preview summary and preview body but no actions. Remove the preview body or add an action: RPM MimeHandler Installation erfolgreich situations-daemon
What is somewhat irritating is, that whenever II install the background service there are some messages around like that:
Jul 28 09:58:02 Xperia10II-DualSIM systemd[1]: selinux: Unknown class service
It seems to work okay in its current state I think.
However depending on where the socket (file) is located, for SailJail there may be whitelisting needed.
E.g. if you are using /tmp/myapp.socket created from a daemon running as root, for a jailed app to be able to access that from within a jail, you need to have an application profile whitelisting that file.
whitelist /tmp/myapp.socket
In Patchmanager we do that not through a SailJail application profile, but a Firejail one. See here.
It may be interesting to look through that file’s history’s PRs (PM #58, PM #55) for some related (and lots of unrelated) discussion on this.
1 Like
Ok, so probably the best thing to do - at least for those with the endless spinner problem - is to install old version, go to About page and uninstall Sonar from there. Then reboot so that we are sure(ish) situations server is not running. And then install the new version.
All this updating works fine and automatically on my rather clean test setup. But apparently reality hits back with its own view of how things should go I will probably need to add additional code that makes sure Sonar gets uninstalled when running the new client - currently situations-daemon package is responsible for it, but no luck if the user never gets that far.
PS. It seems that I hit a “new user reply limit” on this forum and had to wait for several hours to post anything. Wtf?
PS2. It seems that the initial post and a reply (with github links) have been marked as spam. Wtf x 2?
Don’t think, this is if helpful?:
It is, but I don’t see anything concerning there at the moment. Server side logs (if there are any) might be more helpful.
Yeah, it’s an automatic antispam/bot/alt-account measure by the Forum software for New users. You should be out of this phase by now, and are at “basic user” Trust Level. (Reference)
That’s the full output of
journalctl | grep situations
I would have thought, that there should be the output of the situations server included…
Or am I wrong? Then I need assistance, how to look for server side logs.