Closed Olf0 closed 6 months ago
Done. https://openrepos.net/content/vasvlad/meecast-event-view Thanks so much Olf0.
https://openrepos.net/content/vasvlad/meecast-event-view Thanks so much Olf0.
My pleasure. BTW, just realised that I am using your triplet comprising MeeCast
, MeeCast daemon
and MeeCast Events View
for more than 10 years. :smiley:
I hope PR #49 is working fine: I have not tested it, as I will never use EA ("Early Access") releases of SailfishOS and am quite reluctant to upgrade SailfishOS on my devices.
But I assume users will tell: here, at OpenRepos or at FSO.
There still seems to be a flaw under SailfishOS 4.6.0, I am awaiting feedback, see messages 16 and 17 in this thread at FSO.
P.S.: Maybe this is needed
su --login "$(loginctl --no-legend list-sessions | grep -F seat0 | tr -s ' ' | cut -f 4 -d ' ')" --command='dconf write /desktop/lipstick-jolla-home/force_weather_loading true'
instead of the simple dconf
call.
I can't try it. :( I've bought Sony Experia 10 V for experiments. But I can't have access EA ("Early Access") for this device.
I can't try it. :( I've bought Sony Xperia 10 V for experiments. But I can't have access EA ("Early Access") for this device.
Do not worry Vlad, I am trying to get this tested by people at FSO, see aforementioned thread.
I cannot try this, too, because I do not want to test EA releases, but I think others will, especially when asked to do so.
Edit:
P.S.: Maybe this is needed
I read about (man 7 dconf
) and experimented a bit with dconf
(man 1 dconf
) and gsettings
: Yes, this is a user-specific database. The command line I developed seems to be the only way to achieve altering the correct dconf key from the root-context. (BTW, to me dconf seems to be as dreaded as all the GTK / Gnome stuff.)
Hence please merge PR #52 first, then read and act on the original message below.
Oh, you only uploaded the armv7hl
package of harbour-meecast-event-1.1-2
at OpenRepos, but missed to upload the i486
and aarch64
packages. That is an easy explanation why v1.1-2 does not fix anything for most users, as they use 64-bit devices: Thus they install v1.1-1, because this is the latest version for i486
and aarch64
.
Hence please upload all three packages (i486
, armv7hl
and aarch64
) of harbour-meecast-event-1.1-3
at OpenRepos.
You may have to compile with a Sailfish-SDK which supports at least 4.6.0.11
as a target release (you may mind this note at FSO), or in a repository at the Sailfish-OBS (e.g. SailfishOS:Chum:testing) which utilises Jolla's 4.6
-DoD-repository there.
But I am not sure about this point.
I've just uploaded the new version of Meecast's packages to openrepos: https://openrepos.net/content/vasvlad/meecast https://openrepos.net/content/vasvlad/meecast-daemon https://openrepos.net/content/vasvlad/meecast-event-view These packages was build for Sailfisos -4.5.0.16 Packages for 4.6 are here: https://repo.sailfishos.org/obs/home:/vasvlad/sailfishos_chum_testing_3.1.0.12_armv7hl/armv7hl/ https://repo.sailfishos.org/obs/home:/vasvlad/sailfishos_chum_testing_3.1.0.12_486/i486/ https://repo.sailfishos.org/obs/home:/vasvlad/sailfishos_chum_testing_3.1.0.12_aarch64/aarch64/
Thanks for your help again.
Thank you; so I asked for testing at FSO.
P.S.: Just for the completeness' (of information) sake:
… Sailfish-SDK which supports at least 4.6.0.11 as a target release (there was something mentioned at FSO …
That was mentioned here at FSO.
Packages for 4.6 are here:
Thank you. The repository configuration looks a bit awkward to me, but it seems to have compiled fine.
Because I remember well, that the learning curve with OBS is a bit steep (additionally the Sailfish-OBS uses a outdated version), some suggestions:
Either (creating a subproject allows for sharing work with co-maintainers, because OBS-subprojects are completely independent from one's "home"-project):
MeeCast
in your OBS-home.
Side note: You may have to remove the package MeeCast
in your "home"-project for this, but try first, usually OBS does not care much about package and repo names.MeeCast
and also open the project-configuration of Storeman in another browser tab to copy some lines. Copy&paste at least this block:
<repository name="4.6_i486">
<path project="sailfishos:4.6" repository="latest_i486"/>
<arch>i586</arch>
</repository>
<repository name="4.6_armv7hl">
<path project="sailfishos:4.6" repository="latest_armv7hl"/>
<arch>armv8el</arch>
</repository>
<repository name="4.6_aarch64">
<path project="sailfishos:4.6" repository="latest_aarch64"/>
<arch>aarch64</arch>
</repository>
You may also copy additional target repos and stuff from the header; e.g. you may add me as a maintainer, then I can directly support you with these things (configuration etc.) at the Sailfish-OBS.
MeeCast
(as you already did in your "home"-project)._service
file locally on your computer with this content:
<services>
<service name="tar_git">
<param name="url">https://github.com/Meecast/meecast.git</param>
<param name="branch">sailfishos</param>
<param name="revision"/>
<param name="token"/>
<param name="debian">N</param>
<param name="dumb">N</param>
</service>
</services>
Then upload this _service
file to your package repository MeeCast/MeeCast
at OBS.
This _service
configuration allows you to click on "Trigger services" in the package overview to build the current state of the branch sailfishos
of MeeCast. For submitting this package to the SailfishOS:Chum testing repository you will have to temporarily set the revision
to a valid git-tag, else it will not be accepted by rinigus / piggz. After a package submission is accepted at SailfishOS:Chum testing once, this can be reverted for good, because then you can edit the package metadata for MeeCast directly at SailfishOS:Chum testing.
or (slightly simpler, but work cannot be shared, unless you provide co-maintainers full access to your "home"-project at OBS, which I would not want):
MeeCast
in your OBS-home, but this way you have to configure your "home"-project to fulfil MeeCast's needs.MeeCast
in your "home"-project.P.S.: The version numbers are the same for all packages at the Sailfish-OBS (being the one of the main package harbour-meecast
), see e.g. https://repo.sailfishos.org/obs/home:/vasvlad/sailfishos_chum_testing_3.1.0.12_aarch64/aarch64/
I had no time to analyse the build-log yet, but for Patchmanager building sub-packages is working well No, we intentionally use the same %version-%release
strings for all packages.
LOL, it already happens when the stupid Sailfish-OBS rewrites the spec file, see https://build.sailfishos.org/package/view_file/home:vasvlad/MeeCast/_service:tar_git:meecast.spec?expand=1
The release version is altered later in the process, see the unmerged README I once wrote for tar_git
.
So this is "fine", because there is no way to prevent that at the Sailfish-OBS.
My bad. Please merge, rebuild and publish. From what I gather at FSO this typo was the last hurdle, which prevented MeeCast Eventview from working (without additional, manual measures) after installation.
My bad. Please merge, rebuild and publish. From what I gather at FSO this typo was the last hurdle, which prevented MeeCast Eventview from working (without additional, manual measures) after installation.
I've just uploaded MeeCast Eventview packages to openrepos.net
I had overlooked this, but it's building on chum now and should be available today.
Thank you @poetaster, though I am trying to guide @vasvlad to set up an own MeeCast package or subproject (the latter is preferable IMO; I edited the guide WRT this yesterday night) at the Sailfish-OBS in a way that he can submit it to SailfishOS:Chum:testing. This would enable him to handle the whole release process for SailfishOS:Chum on his own, without triggering you (or me or anybody else).
You may consider to add him and/or me to the list of maintainers in SailfishOS:Chum:testing/meecast
's meta configuration by adding these lines under the <person userid="poetaster" role="maintainer"/>
one:
<person userid="vasvlad" role="maintainer"/>
<person userid="olf" role="maintainer"/>
This would eliminate the need for @vasvlad to submit MeeCast to SailfishOS:Chum:testing in order to be able to handle releases there on his own.
Unfortunately this way the preferred spelling MeeCast
cannot be achieved, because package names at OBS cannot be directly altered retrospectively, only indirectly by submitting the package to a new name at the same project. But this is a nitpick without any real relevance, IMO.
Still I would appreciate if @vasvlad establishes a proper subproject or/and package configuration in his OBS-"home" in order to test-compile MeeCast there: As some people actually use SailfishOS:Chum:testing, I believe one should not put outright broken builds there. This is why I usually test-build apps in an own OBS-subrepository first (only for a few SailfishOS target releases), before I trigger a build at SailfishOS:Chum:testing. Because the Sailfish-OBS tends to be slightly oversensitive WRT build configuration (spec file etc.), I do this in addition to CI builds at GitHub.
Thinking about it while writing the prior paragraph, I could actually create such a MeeCast OBS-subrepo in my OBS-"home" and add both of you as maintainers; maybe next weekend, when I have a little more time.
BTW @poetaster, what was your reason to disable building MeeCast for all SailfishOS releases from 3.1.0 to 4.1.0? Did these not build correctly?
My biggest, current concern WRT MeeCast is actually still a fully automatic installation (i.e. without additional, manual work) of MeeCast Eventview: I am currently out of ideas what exactly goes wrong. Hence any help is much appreciated.
My biggest, current concern WRT MeeCast is actually still a fully automatic installation (i.e. without additional, manual work) of MeeCast Eventview: I am currently out of ideas what exactly goes wrong. Hence any help is much appreciated.
I've only had time to test the update in 4.5 which worked without issue. As I understand it, the issue with the event view is the need to use dconf after the jolla event view deprecation (cough!)?
I'll add you both to the maintainers ... now.
I've added you both to the obs testing repo, but do not have the authority on the chum repo proper.
I'm not really sure about the automation myself, and do far too much manual work even for having set up both webhooks (in subprojects) to respond to releases on github. I find that get's me 2/3s of the way there (using release semantics to drive github actions and a webhook on release for obs). Still, I end up building the packages for openrepos via the sdk to 'keep on top' of the behaviour of the sdk and see if I spot errors in the packaging on build.
Hmmm. meta.
As I understand it, the issue with the event view is the need to use dconf after the jolla event view deprecation (cough!)?
Yes, and I think I am now at the point to address that properly with the current (as of today) code, but only at SailfishOS:Chum. I know how to also achieve that at OpenRepos, but that is a lot more hassle to implement. For the upcoming months the MeeCast Event package from OpenRepos will continue to require the two manual steps as described at FSO to work.
Finally the harbour-meecast-event
RPM compiled at the Sailfish-OBS from the source tree tagged v1.1.39-3
is installing fine and running "out of the box" without additional, manual work on SailfishOS 4.6.0. :tada:
I submitted this to SailfishOS:Chum.
I exchanged SailfishOS:Chum:testing/meecast with SailfishOS:Chum:testing/MeeCast: All three of us are also maintainers of this (new) package, as we were of the old one. Subsequently I requested the same exchange at SailfishOS:Chum proper: Adding MeeCast and removing meecast.
@vasvlad, I also suggest to remove OBS-package MeeCast at the Sailfish-OBS, because its configuration has issues.
You and @poetaster have full maintainer access to the package MeeCast in my sub-repository MeeCast. I now reconfigured it so hitting "Trigger services" compiles a git-checkout of the current state of the sailfishos
branch here at GitHub, so it can be easily used for test-building: "Does it compile?" and one can try the generated packages.
Thanks for the heads up. I haven't had time to test since test phone is in a very odd state and I'm about to go on vacation ... so don't want to risk anything till I'm back in August :)
That is fine. Pleasant holidays!
Also, there is currently nothing to test: There is a fully working version for SailfishOS ≥ 4.6.0 at SailfishOS:Chum (for < 4.6.0 it was already working) and I have a concept how to provide fully working versions at OpenRepos, both for SailfishOS ≥ 4.6.0 and < 4.6.0 concurrently. When the latter is ready, you may test that.
AFAIU MeeCast Event View (
harbour-meecast-event
) is also affected by this change in SailfishOS 4.6.0, which is in Jolla's tradition to introduce changes which break for third-party apps unnecessarily.Consequently the
harbour-meecast-event
RPM file would need toRequire: lipstick-jolla-home-qt5-weather-widget-settings
, but only on SailfishOS ≥ 4.6.0.0. E.g. by adding this to the body of the RPM spec file:and in the
%post
section of the RPM spec file:HTH
P.S.: I understood that MeeCast Event View is affected only by reading e.g. post #6 and post #13 in the FSO-thread "SFOS 4.6 (Foreca / MeeCast): How to (re-)enable the weather infos in Events View" and some posts in the FSO-thread "[Release notes] Sauna 4.6.0.11".