As addition to @olf procedure:
Please mind that you are on an EA (i.e. beta) release of SailfishOS and hence you implicitly volunteered for testing: This is what we explicitly do here.
Still your feedback and testing is very valuable in order to get MeeCast Eventview into a state again, where it works out-of-the-box (i.e. without additional, manual steps after installing the RPM package), because neither Vasvlad nor I have a device with SailfishOS 4.6.0 on it.
NB: I just “love” Jolla for regularly introducing breaking changes unnecessarily, because they do not care at all about backward compatibility and the SailfishOS software ecosystem beyond their own components. They cause so much tedious work for zero gain, but as it is not them executing this work they obviously do not care; still, this erodes the SailfishOS software ecosystem more and more as developers are giving up this fight against the constant stream of breaking changes and consequently abandon their apps, while Jolla does not update completely outdated and insecure software components as Qt 5.6 from 2016, which is out of security support since March 2019; additionally a newer Qt would make programming much easier, especially of portable apps.
@kan_ibal, technically both Storeman / OpenRepos and the SailfishOS:Chum GUI application / the SailfishOS:Chum repository should be working fine. If you have any indication that this is not the case, please report that, preferably at the corresponding issue tracker at GitHub.
But as you can easily see, the SailfishOS:Chum repository currently contains a long outdated version of MeeCast (see e.g. Show sailfishos:chum / meecast - SailfishOS Open Build Service), which neither Vasvlad nor I submitted there.
To check which versions of MeeCast’s components are installed, execute
pkcon search name meecast | fgrep installed
Thank you @kan_ibal, these are definitely two valid points one has to ensure after installing Meecast Eventview for using or testing it.
May I add:
4. Do not miss to restart Lipstick or reboot after installing the MeeCast Eventview package or performing actions to fix MeeCast not being displayed in SailfishOS’ Eventsview.
@lakeboy: Yes, “latest Meecast” is a bit underspecified (as @kan_ibal already mentioned): Which version(s) from where? As you indicated to have followed my instructions above, I assume you installed the versions I mentioned (harbour-meecast-event-1.1-3, harbour-meecast-1.1.39-2 and harbour-meecast-daemon-1.10-2) from OpenRepos (e.g. by Storeman or pkcon). I have an idea why using these packages may not let Meecast Eventview work out-of-the-box, but as usual there could be many other reasons I do not think of.
In order to pinpoint what the culprit is, please perform two groups of checks:
dconf key set correctly? Please execute as regular user:dconf read /desktop/lipstick-jolla-home/force_weather_loadingtrue . Is it?dconf write /desktop/lipstick-jolla-home/force_weather_loading true), restart Lipstick or reboot, and then check if MeeCast is displayed in the Eventsview.lipstick-jolla-home-qt5-weather-widget-settings automatically installed? I do not believe this can go wrong, but a simple typo would render this belief futile.harbour-meecast-event-1.1-4 at OpenRepos. Please retest then.pkcon search name lipstick-jolla-home-qt5-weather-widget-settingspkcon install lipstick-jolla-home-qt5-weather-widget-settings), restart Lipstick or reboot, and then check if MeeCast is displayed in the Eventsview.sailfishos_chum_testing_3.1.0.12_%(arch)/%(arch)/, e.g. for aarch64 to Index of /obs/home:/vasvlad/sailfishos_chum_testing_3.1.0.12_aarch64/aarch64 You do not need to download the debuginfo package and harbour-meecast-lockscreen is a Patch to be utilised with Patchmanager (I wonder if this Patch still works).
aarch 64: harbour-meecast-1.1.39.2-1.2.1.jolla.aarch64.rpm,harbour-meecast-daemon-1.1.39.2-1.2.1.jolla.aarch64.rpm andharbour-meecast-event-1.1.39.2-1.2.1.jolla.aarch64.rpm (Edit: This package does not automatically install lipstick-jolla-home-qt5-weather-widget-settings, a later one with a higher release number (than 1.2.1), but the same version number (1.1.39.2) will do that.)) from the architecture-specific OBS-download-directory into a (preferably freshly created) directory on your device (e.g. by curl -LO <URL>). NB: Yes the version numbers are are all the same, this is Jolla’s wonderful tar_git at the Sailfish-OBS rewriting all %release numbers and setting the %version-%release strings of sub-packages to the one of the primary package. Nevertheless, the package sizes indicate that these packages were built correctly.pkcon install-local requires full RPM file names rsp. paths!):pkcon install-local harbour-meecast-1.1.39.2-1.2.1.jolla.aarch64.rpm harbour-meecast-daemon-1.1.39.2-1.2.1.jolla.aarch64.rpm harbour-meecast-event-1.1.39.2-1.2.1.jolla.aarch64.rpm
So after all that, I was missing lipstick-jolla-home-qt5-weather-widget-settings app. I installed that and presto. I can see the Meecast data in the event view. Now Meecast itself isn’t working for my weather source but I have messaged Vlad on Openrepos about that. Thanks for your assistance @olf
Thank you very much for testing. This made me look closely at the spec file again, and indeed there was a trivial typo! This is ought to be (but apparently is not) fixed by harbour-meecast-event-1.1-4 at OpenRepos.
Can you please retest, i.e. run through the steps 1 to 6 of my original instructions again.
You are very welcome. After a little rigmarole, alas, lipstick is not automatically pulled in from your updated harbour-meecast-event-1.1-4.
I only have:
[root@Xperia10III defaultuser]# pkcon search name lipstick | fgrep installed
Installed all-translations-pack-0.8.1-1.4.1.jolla.noarch (installed)
Installed lipstick-jolla-home-qt5-1.26.12.4-1.22.1.jolla.aarch64 (installed)
Installed lipstick-jolla-home-qt5-components-1.26.12.4-1.22.1.jolla.aarch64 (installed)
Installed lipstick-qt5-0.36.41-1.20.1.jolla.aarch64 (installed)
You are very welcome.
Thank you for your endurance! This is really getting tedious for all of us: You, Vasvlad and me. But as usual in software development the last 10% to get a software working as specified takes 50% of the development & testing time.
lipstick-jolla-home-qt5-weather-widget-settings not becoming automatically installed was (rsp. still is) the last apparent flaw, but obviously an indelible one. So ultimately MeeCast Eventview 1.1-4 behaves exactly like v1.1-3 for you?
Now I really do not understand it, especially as you state that the dconf key /desktop/lipstick-jolla-home/force_weather_loading is successfully created and set to true (which was much harder to get right; well, so I thought).
Edit: Ultimately I do understand it, but this dconf key was either not properly reset (or set to false) for testing or it was simply misreported as being set to true by installing the package harbour-meecast-event v1.1-4.
I am travelling ATM and will be away from home this week; I will try to think of potential reasons, thoroughly look at the spec file again and / or try to think of additional tests later, but have only little time available this week.
Any help rsp. more eyes and brains trying to find the flaw in the spec file are very welcome!
Spec file looks ok but it looks like harbour-meecast-event-1.1-4 rpms at OpenRepos are missing all scripts regarding"
# Require Lipstick Weather Widget on SailfishOS > 4.6.0
Should %if %{defined sailfishos_version} && 0%{?sailfishos_version} > 40600 looks like
%if %{defined sailfishos_version} && 0%{?sailfishos_version} = 40600
as far as I understand %sailfishos_version 40600 variable is set for compilator, not for installer and it looks like a little misunderstanding if it should be applicable for installer, doesn’t it?
Spec file looks ok but it looks like harbour-meecast-event-1.1-4 rpms at OpenRepos are missing all scripts regarding"
# Require Lipstick Weather Widget on SailfishOS > 4.6.0
Yeah, been too busy lately, thinking becomes hazy after a while.
If I understand you correctly, you mean (falls into the category “simple tests”) that these commands generate the same output on SailfishOS 4.6.0 as on an older version (with which I generated the output below), right?
cd /tmp
curl -LO https://openrepos.net/sites/default/files/packages/678/harbour-meecast-event-1.1-4.aarch64.rpm
rpm -q --scripts harbour-meecast-event-1.1-4.aarch64.rpm # Test 1
rpm -qR harbour-meecast-event-1.1-4.aarch64.rpm | fgrep lipstick-jolla-home-qt5-weather-widget-settings # Test 2
Test 1 outputs:
postinstall scriptlet (using /bin/sh):
# Activate Lipstick Weather Widget on SFOS > 4.6.0
postuninstall program: /bin/sh
Test 2 outputs nothing.
The only thing which does not fit then, is that @lakeboy seemed to have indicated that the dconf key was correctly created and set, after resetting it as a preparatory step for a prior test.
Well, basically yes. The quite sparse (in terms of concise specifications) and scattered RPM documentation distinguishes between “macro expansion at (S)RPM build time” and “macro expansion at (S)RPM install time” (what you called “compilator” and “installer”). The macro expansion in RPM spec files happens in the first of these steps, in which a specific macro is defined; i.e. if a macro is not defined at (S)RPM build time, it is left “as is” (i.e. unexpanded), and may be expanded at (S)RPM install time (or not at all).
The macros at an RPM target machine (for “install time”) can be seen by rpm --showrc (you might want to append a | less ).
The macros on a build machine are harder to inspect, at OBS you can look at them for e.g. targetting the sailfishos:3.1.0.12 DoD repo or the sailfishos:4.6 (.0.11) DoD repo; within the Sailfish-SDK basically the same macros should be set (depending on the target release set).
This is why I once suggested to try the built RPMs from the Sailfish-OBS if the ones at OpenRepos do not set the dconf key and/or install lipstick-jolla-home-qt5-weather-widget-setting, but later I forgot about this idea: The packages Vasvlad built at the Sailfish-OBS should be using sailfishos:4.6; now I checked that explicitly and the output of “Test 1” and “Test 2” is the same for them as above when downloaded and checked on a SailfishOS release < 4.6.0: Either they are not built correctly (the OBS config for them is a bit strange) or it takes a device with SailfishOS 4.6.0 to see a different result. Is the latter the case?
Ultimately I think your suggestion to perform this evaluation explicitly at “install time” is good, because more fail-safe; I already did this in sailfishos-chum-gui-installer, but for other reasons (it is a noarch package, hence there is not really a build process).
Edit: But one cannot easily install an RPM in a spec file by other means than a Requires: statement. A workaround exists, but that is “heavy lifting”. All this shit because Jolla deems displaying weather information in SailfishOS’ Events View superfluous since Foreca does not work out-of-the-box any longer.
Besides the intention of spec author regarding this contition I find that this requirement should be unconditional for this rpm.
The dconf command following with a restart worked on my XA2 Ultra.
Thanks for the help
The question is did Meecast-event-1.1-4 auto install lipstick for you?
I guess not because I must have had everything installed already since Meecast was in use by me right before the update. But I do not know what the dconf command actually does.
Sorry to say but Harbour-meecast-event-1.1-5 still did not auto install lipstick for my device. X10III
I tested with the current Chum version too - no dice. I will install lipstick manually and run the dconf key change.
…
Yes, I know: The code of harbour-meecast-event-1.1-5 should be fine now, but it needs to be git-tagged and recompiled at the Sailfish-OBS (where the SailfishOS:Chum is located). I hope to find the time to take care about this the upcoming weekend.
Just wanted to interject here that this is a really nice project.
The weather forecast feature in the side menu was a good feature of SFOS and it would be really nice to have it back at some point.
Thanks to all involved for their efforts,
This popped up in today’s community meeting. So if you’re trying to use MeeCast and are not seeing weather in the Events View place follow @pvuorela 's instructions and force weather loading.
every month i made a new foreca account to “test” the api, but since yesterday this doesn’t seem to work anymore, i tried to create an additional account, but with that it also doesn’t work. maybe they recognized a pattern and blocked my api calls?
@lakeboy, thanks again for testing. I am pretty sure I now have all issues resolved, as these two tests (“Test 1” and “Test 2”) finally run fine.
I would appreciate, if you or someone else tests “in real life” again (i.e. on a device with SailfishOS 4.6.0 installed), with the packages I recompiled. The command lines below assume you are using an aarch64 device (i.e. an Xperia 10 II or 10 III; for armv7hl and i486 the download paths and RPM file names are slightly different) and that you are starting as a regular user (the dconf command must be executed as a regular user):
dconf reset /desktop/lipstick-jolla-home/force_weather_loading
devel-su
pkcon remove lipstick-jolla-home-qt5-weather-widget-settings harbour-meecast-event harbour-meecast-daemon harbour-meecast
mkdir foo
cd foo
curl -LO https://repo.sailfishos.org/obs/home:/olf:/MeeCast/4.6_aarch64/aarch64/harbour-meecast-1.1.39-1.2.1.jolla.aarch64.rpm
curl -LO https://repo.sailfishos.org/obs/home:/olf:/MeeCast/4.6_aarch64/aarch64/harbour-meecast-daemon-1.1.39-1.2.1.jolla.aarch64.rpm
curl -LO https://repo.sailfishos.org/obs/home:/olf:/MeeCast/4.6_aarch64/aarch64/harbour-meecast-event-1.1.39-1.2.1.jolla.aarch64.rpm
pkcon install-local harbour-meecast-1.1.39.2-1.2.1.jolla.aarch64.rpm harbour-meecast-daemon-1.1.39.2-1.2.1.jolla.aarch64.rpm harbour-meecast-event-1.1.39.2-1.2.1.jolla.aarch64.rpm
rm -f harbour-meecast-*
cd ..
rmdir foo
exit
Does MeeCast-EventView now work out of the box?
If so, I will submit these packages to SailfishOS:Chum.
For me, after having set up sailfish weather event view, the packages currently in chum work out of the box. I just decided to switch to meecast for eventsview and lockscreen, and both work reliably
Sorry, this is well known, but not at all the requested test, hence not helpful.
Please test by executing every command line provided and report back here.