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?
1 Like
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?
1 Like
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.
6 Likes
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,
5 Likes
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.
3 Likes
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.
1 Like
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.
yes it works with your packages
1 Like
@olf nice work! Yes I can confirm that Event view of Meecast is now working. Nice work!!!
What was the missing step?
Thanks for your persistent work - whilst my home weather source isn’t working, I can follow other cities through other sources.
Happy chappy here. 
2 Likes