Overhaul spec file #91
Conversation
* Use %post instead of %posttrans. %post can be limited to either only on installation, only on upgrade or allow for both. %posttrans cannot be limited and is very last executed before the RPM transaction finishes; it is provided for special cases, using it for generic purposes in rather unusual. * Only add repositories, if they are not already configured. * Cease executing `rm -f /var/cache/ssu/features.ini` when adding repositories. * Limit removal of repositories to when %postun is run upon removal of the package (not also on upgrades)
- Replace `printf %s` by `echo`, because then `%` would have to be escaped with another `%`.
- Enhance comment
- Omit `-n %{name}-%{version}`, because it is the default for the `%setup`macro, see:
http://ftp.rpm.org/max-rpm/s1-rpm-inside-macros.html#S3-RPM-INSIDE-SETUP-N-OPTION
* Specify that ssu is already needed for the %post scriptlet. * Append `exit 0` to scriptlets for safety and clarity.
|
@Olf0: For me, the problem with this and GUI SPEC PRs is that it is has to be checked and made sure that it doesn't introduce any regressions. As current SPEC files work and there is already huge backlog for OSS projects that need my attention, it is hard to prioritize this review. I am sorry for delays, just trying to give my perspective on this work. |
|
Well understood, as I often lack time for this spare-time stuff for many, many weeks. Currently I am using up last years holidays (i.e, "days off from work"), as these off-days are due to the 31. December 2022. So I started working on the Storeman Installer, ultimately to eliminate all manual steps (except for triggering the installation of the installer, but not any longer the package to install). BTW, I have that working via a systemd unit (also with the indirection via a timer unit, but for no advantage), but it needs more testing (this is what I am currently at) and I still try to do without systemd (no success yet). Though to be honest, I have to state that having MRs stalled for many months is ineffective (because the author may not remember much, as I did with sailfishos-chum-gui MR 124, even though there it was trivial to retrace why I considered and implemented these little changes) and frustrating (especially for trivial changes as sailfishos-chum-gui MR 122). Yes, my changes in the two spec files (here and for the GUI app) range from no-gos ("try to own Assurances I can make
Things I can offer
TL;DRDelays for a couple of weeks is sure fine, but months are problematic, both socially (causing frustration among submitters) and technically (it limits progress by limiting the amount of contributors and contributions). I am willing to support this project with the measures (GitHub CI pipelines, Transifex-Integration) I have successfully employed elsewhere (Patchmanager, Storeman etc.), plus continue to work on things I have a expertise for: Packaging, Shell scripts and the use of UNIX tools. OTOH, your message can be read as "Go away, I don't want your contributions", which would be sad (because I liked to contribute and also believe that my contributions significantly enhanced the "user experience" / look&feel of the SailfishOS:Chum documentation and GUI application), but there is no way around if you as the project lead think so. I would appreciate a clarification, if that was an aspect you intended to express. |
|
@Olf0: just a short reply right now. My message should be read as the one from maintainer who knows that a proper feedback is needed and it is delayed. You are very valuable contributor and I think we would need to change something to avoid loosing your contributions and make it all way more timely. So, it is as far from "go away" as possible :) . |
|
@Olf0: we would like to invite you to join the maintainers of Github Chum core repositories. Corresponding invitations have been sent through the system. I hope you would accept these invitations. If you do, please feel free to merge the outstanding PRs in the appropriate order. As we don't have any objections to the PRs raised, I would consider them fine. I hope I didn't miss any permissions, sometimes it is confusing. In this respect, maybe we should just set default member permissions to "Write" for all repositories (setting for the organization account). /cc @piggz |
Thank you.
Will do, likely next week.
Yes, they are confusing, changing at times (because GitHub is introducing new features or cleaning up their web-frontend's UI), some settings are a bit hidden (at these places GitHub's web-frontend becomes a point-and-click adventure: "I once saw this setting, but cannot remember how to get there.") and IMO inconsistent (at least the way the UI is designed) between organisation and project level. I will notify you, when I run into access right issues. AFAIR I chose rather restrictive default settings for the "storeman-developers" org, which I open up on individual basis (criteria, e.g., work items, skills, experience, mishap rate in the past etc.). I will take a look a the settings I settled on after reading a lot of GitHub-documentation and some testing, then report back here, if I still regard them as relevant settings changes. |
|
Thank you very much for accepting it and joining! |
… syntax, either because of its ancient OBS release or [`tar_git`](https://github.com/MeeGoIntegration/obs-service-tar-git). Hence this in now expressed in two *Requires* statements: `Requires(A):` and `Requires(B):`
|
@rinigus, can you please either consider issues #95 and #99 for this repository, plus "pin" the SailfishOS:Chum GUI Installer repository ("Customize your pins" on the front-page for the GitHub-"organisation", or provide me with the rights to perform these actions. In either case, if you do not concur, please denote that, so we can discuss how to proceed (or not at all, if we cannot find a compromise). I am also considering a brief README for the "organisation" with links to the relevant READMEs for users, developers etc. in the "main" repo. |
|
@rinigus & @piggz, even more off-topic: Jolla's reply to your Qt-update question is a catastrophe (literally!), technically, socially and security-wise! I am considering more drastic steps to put more pressure on Jolla than just writing and talking nicely, but fiercely, e.g., like I did 1,5 years ago face-to-face with Sami and Joona (separately). Sami's reply back then was a crude managerial bail-out by saying "Maybe we should use something completely different?" and then kindly refusing to discuss the topic any further. Addressing this topic in a conversation with Joona a little later, he stated "we can switch to a newer QT 5 release at any time" (he missed to add "technically": this is no news at all for us) and then started a technical deep dive what the pros and cons of Qt 5.12 versus 5.15 might be, which I dryly countered with "5.15 for sure, because it will take quite some time for you to integrate, test and release"; the fact that 5.15 receives external long-term support by the KDE community seemed to be new to him, as did the fact that the rotting Qt 5.6 is massively hindering cross-distribution development of apps (me naming PureMaps as a prime example). Confronted with Sami's statement his eyes widened and he mumbled "this is technically impossible", a truth we all know for long, because the whole UI is based on QML and Qt. Their handling of this has become completely insane, foobar'ed, … (I am lacking sufficiently strong words to express my thoughts and feelings properly without resorting to a level of language I avoid publicly), as if there would be anything to gain by continually refusing to make any decision for so long (either accept GPLv3 or pay the Qt company). It is just crazy, that we (Rinigus and me) discussed this publicly and in depth 2,5 years ago, both of us being aware of the consequences for much longer (for Qt 5.6 bug-fix support ended in 2018, security support in 2019 and even earlier it was absolutely obvious that a decision must be met). And any try to promote / market / propose SailfishOS as a "secure, mobile OS" has become a foul joke since 2019, now without any perspective of a change. Furthermore the undertone and behaviour of the sailor(s) present at that meeting also constitutes a vast regression WRT community management and clearly transports the old, well known mantra that "the community" (developers, SailfishX licensees and users without a bought license alike) are by no means customers, but simply subordinates ("paying beta testers" is my usual depiction of SailfishX licensees). Once even explicitly (though most SFOS users will always misinterpret such statements and believe they address them, because such statements are almost always being deliberately phrased ambiguously; as a sailor one expresses such uncomfortable facts clearly at most twice, then you are fired (remember James Noori?)), something I have not read for about 2 years. If there would be any sound alternative I would prepare a change of mobile OS for me, but each time I lurked into UBports (formerly Ubuntu touch, before that Ubuntu mobile), KDE's Plasma mobile, PostmarketOS etc. the impression was devastating: technically (e.g., UBports still being based on Ubuntu 16.04), WRT stability, functionality, software "ecosystem" etc. Do you share this impression or do you see a viable alternative for everyday use? Back to the original topic: Any ideas how to seriously increase pressure on Jolla to meet a decision? I reconsidered reviving the old notion of condensing the former discussion at TMO into an "open letter" at FSO, but I am pretty sure that this will be completely ignored (i.e., sailors will be instructed to not reply in such a discussion thread) and may even result in some form of banning, muting etc. at FSO. OTOH we three are not nobodies to "the community" and some people at Jolla, because the whole third-party software infrastructure relies on us (except for apps which pass Jolla's Store hurdles), but still I am afraid (actually, pretty sure) that the decision makers at Jolla do not care at all: Extrapolate Sami's and Joona's aforementioned reactions, plus no private user or developer being anything close to a customer for them. Thoughts on this, ideas how to proceed? P.S.: Another problematic point is, that some in "the community" will happily fight fiercely against any statement which shows understanding, that the *GPLv3 licenses are problematic for Jolla's corporate customers etc., e.g. lolek at the recent "community IRC meeting" or javispedro in that old TMO thread: "stabbed in the back by believers / disciples" is my phrase for this behaviour, these people are so fanatic that they will never regard anything of higher priority than the objects of their fanatism (the FSF, *GPLv3 licenses, Richard M. Stallman). P.P.S.: My gut feeling tells me the SailfishOS-OBS will not be available for long (well, "Jolla time": months), given the tone and character of the statements in the recent "community IRC meeting". |
|
@Olf0, odd place to discuss it, but OK. Indeed, absence of any progress with Qt upgrade is depressing. However, I don't think we can apply any kind of pressure on Jolla in this respect. Not that they will care. I presume that they have made a decision to stick with Qt 5.6 and not care about at all. Otherwise it is hard to explain their response and actions. As for alternatives, UT is not based on 20.04. I haven't looked into them recently, maybe they improved. But I do prefer SFOS UI. With the alternatives, I don't know any good email reader. At least when I looked around a year or two ago. So, for transition, some serious work on that would be needed. Re how to proceed: One option would be to package new Qt in /opt and try to use that for other software. In theory, it would allow us to start packaging newer Qt apps and contribute to their development. GNOME apps would require newer Wayland or Wayland shell (can't remember what was exactly an issue). Alternative is to try to revive Flatpak. But that failed for me still when I tried after 4.5 update. Namely, I can't get HW acceleration working and, without it, some QML apps are just buggy (Angelfish, for example). Although, flatpak is attractive as it does come with full environment and we don't have to package apps if it works. If we get somehow access to newer Linux apps, we can start working with others and, in longer term, develop apps that are needed for reasonable mobile use. Re OBS: Very hard to tell. I would not read much into the tone of the last meeting. It was a new chair and he was immediately greeted with Qt and VoLTE questions :) . Not the easiest start... |
Yes, an awkward place for this, I know, sorry: I (ab)used this closed PR spontaneously to have public, but slightly hidden place, where this discussion is recorded lastingly.
After I had overcome my initial frustration, I took some time to evaluate if there might be convincing arguments for Jolla, either old or new ones. The result is even more grim:
Now a couple of things fully make sense to me:
Thus I will slowly wind down and wrap up my activities WRT SailfishOS and reduce myself to a simple user. As long as I am using SailfishOS I will continue to invest minimal maintenance work into my software.
I know they are still on 16.04, but (from December 2022) the first beta based on 20.04 is out.
… which includes Jolla Mail: K-9 is excellent, under Alien Dalvik / "AAS" or Waydroid. I never used anything else, starting on a Jolla 1 in 2015, because Jolla's thing is at most on par with The same applies to the browser: Despite all updating Jolla's browser is always far behind and many webpages just do not work properly. I always used Firefox with a handful of plug-ins, the three most essential ones being NoScript, uBlockOrigin (uBO) and Cookie AutoDelete (CAD). I am not willing to use anything below this standard.
Thank you for your assessment which helped me shaping a plan much better: Use SailfishOS as long as there is no viable alternative, but rather invest time into alternatives than SailfishOS.
Thank you for depicting the routes you see, but none seems to be straightforward and any may lead to a cul de sac / dead end. Even if something can be achieved, this may break any time, as all your prior works following one of these routes did (e.g., Flatpack). For me personally Flatpack is absolute un-concept, but as a bad workaround I would sure accept it. Nevertheless, IMO we cannot and we should not try to fix things Jolla refuses to address: newer Qt or newer Wayland. Because next we would have to convince app authors that we provide something more sustainable than Jolla: impossible, because it would be a lie (three people in their spare time vs. a small company). Additionally, security has become a big culprit with the core software component (Qt) being more than 5 years out of security support: Search a Qt-CVE (e.g., in the HTML renderer) and attack, e.g., via email. It is as simple as that. IMO designing exit strategies which can be executed with all calmness and time needed is the only thing which makes sense.
Ville "vige" N. is an aged sailor and has been "community" manager before David "flypig" L.-J. assumed this role about a year ago (and performed excellently in it): He is exactly the right person to minimise Jolla's community activities to irrelevance. You likely did not notice him in this role before, because it rarely becomes visible and he continued to do that perfectly right from his new start (at the aforementioned IRC "community meeting"): dismissing everything in terse, cold statements, often borderline to toxic. I currently have a private conversation with him ongoing at FSO (he took a public question privately) where he proves that his social skills stretch beyond that: outright toxic, without revealing anything technically. If there is no sudden turn in that conversation, this was the very last time, I tried to support Jolla technically (only to receive poisonous replies, as often before, from multiple sailors: this is a company culture thing). So back to the future of the SailfishOS-OBS: In the light of my assessments above, I am even more convinced that its days are over. It is just a matter of time until Jolla presents some pseudo-solution, again (remember that it was vige who initially suggested to use the Sailfish-SDK instead, about 2 or 2½ years ago). |
|
Well, that was an interesting conversation to wake up to! I share many of the concerns TBH, not sure of the solution. If I was to switch OS, it would probably be to something using Plasma Mobile, but ive not investigated any options yet. KDE/Qt have always been a draw, and im sure it would be simple to port my apps there fully. On the other hand, the Sailfish Community is a friendly place, and Ive good relationships with many devs and sailors, so leaving would be with sorrow. I actually quite like @rinigus suggestion of installing new Qt in /opt (there is also some place in /home/.system?) it would allow us to experiment. Lets see what happens with OBS, i was hoping that you being so active in Chum recently you would take-over my work to get the mtime working, but I guess thats not the case! :) Jolla have recently fixed the build.sailfishos.org issue, so maybe the future is more positive? If they were to kill it, it would certainly be disappointing. |
|
I think we all agree with the concerns and it makes sense to have an escape plan. And, as @piggz described, it will be sad to leave SFOS for social reasons. But, taking into account mix of close- and open-sourced bits, we should be ready for it anyway. What we seem to lack so far is an alternative which you could use as a daily driver. But, as I mentioned above, it is conclusion that I reached when I looked into it last time. Having newer Qt in /opt would allow you to work with the other platforms (Plasma Mobile, for example) while using SFOS as daily driver. Same goes for Flatpak. Although, Qt in /opt probably would allow more, such as experiments with Wayland. We don't have to attract developers to such mixed environment as they could develop for Plasma. |
|
Thank you for your replies. As we all see Plasma Mobile as technically attractive, going for Qt 5.15 or 6 in
Rinigus did a while ago, and I had a look at the various options on a Pine Phone (not mine) 2 years ago: The internationally hyped (e.g., regularly at Phoronix.com) UBports was not usable. Little has happened since then.
Ack.
I also agree to this assessment, but that does not extend to the company: They always have been fully opaque, the idea of collaborating with a developer community is mostly foreign (rather: alien) to them. They deliberately run a classic walled garden development model, hence there never can be any outside participation (in the very meaning of this term), starting with commits always only carrying "Fixes JBxxxx" messages with these Jolla-Bug references being unresolvable outside Jolla. My experiences with sailors are extremely mixed, the most positive ones have either left the company or are not "real sailors" (e.g., slava and lbt are just contracted, not employees). Still, ...
I had learnt to endure this aspect, but the Qt answer (5.6 forever; plus the "no VoLTE for ports" answer) were the nails in the coffin for me, because these replies take away any technical perspective, as already pointed out.
Sorry, never was, because I do not code C++. I care about infrastructure.
I would not read anything into somebody carrying out the task on some low-priority, internal ticket after more than a year to fix this DNS entry. Thank you guys, I think we can conclude this here. Despite the rather sad events which triggered this conversation, it was constructive, helpful and provided me with some orientation. Personally I will try to finish a couple of open tasks in the next months, before seriously considering to try new things. |
|
@Olf0, when you get to test alternatives, please write it up. Ideally, at SFOS forum as it would be of interest for many. |
|
Well, my primary alternative is going to be LineageOS on my FxTec Pro¹: I believe that this works well (at least others have reported that), but I doubt this installation procedure is worth to be documented. Although I intend to evaluate TWRP and multi-boot for it, see how / if that works and if some aspects are worth being documented at the FxTec forums. Still I consider to write something about that at FSO when I have it up and running, but rather for the political aspects (i.e., the show: to indicate that one shall have an alternative to SailfishOS at hand, likely spiced with some reasons). |
|
Decent choice, I think. Don't want to go down that route, not yet. |
Use %post instead of %posttrans. %post can be limited to either only on installation, only on upgrade or allow for both. %posttrans cannot be limited and is very last executed before the RPM transaction finishes; it is provided for special cases, using it for generic purposes in rather unusual.
Only add repositories, if they are not already configured.
Cease executing
rm -f /var/cache/ssu/features.iniwhen adding repositories.Limit removal of repositories to when %postun is run upon removal of the package (i.e., not also on upgrades).
Omit
-n %{name}-%{version}, because it is the default for the%setupmacro, see: http://ftp.rpm.org/max-rpm/s1-rpm-inside-macros.html#S3-RPM-INSIDE-SETUP-N-OPTIONSpecify that
ssuis already needed for the %post scriptlet.