Yea, after a few more days of use. I agree. I get alot of freezing most likely due to memory. 4.3 was great and fixed this now it seems like a regression. Its alot better than 4.1, there memory leaks constantly crashed my phone (to such an extent I nearly gave up on SF)
Remove or revert the following
packages, as they may cause
problems during update:
This is a “vanilla” XA2, initial install was v126.96.36.199 (Seitseminen). It received every OS update since in a timely manner. No additional repos configured. Weird.
I felt confident to remove git-minimal and gittin, however ofono-alien-binder-plugin gives me: [root@Sailfish nemo]# pkcon remove ofono-alien-binder-plugin Resolving Testing changes Finished [ ] (0%) The following packages have to be removed: aliendalvik-1.1.0-1.1.1.jolla.armv7hl Android App Support aliendalvik-configs-10.0.50-1.1.1.jolla.armv7hl Android App Support configurations ofono-alien-binder-plugin-0.1.5-1.3.1.jolla.armv7hl Radio interfaces for Alien Proceed with changes? [N/y]
What’s going on here? Since I’m not on EA, I’m quite surprised that I find myself in a position to “fix” an ordinary update.
@dmz You don’t need to remove the Ofono-Alien-Binder-Plugin, I had the same message on my XA2 (without the two git ones though). I tried to remove said package too, and ran in the same “these three must be removed too” warning too, so I let it be. On the first try, after selecting “install”, it aborted the update process (“try again later”) before it even began, after the restart (and a pkcon refresh - can’t hurt) the ofono-package warning was gone, and the update went through smoothly.
@Solidus Speaking of the Jolla Tablet, I had these two warnings too, but pulled through anyway (with one pkcon refresh for good luck ), the update went through fine on the first try.
OK, I took the plunge, hit “install” (leaving the conflict around ofono-alien-binder-plugin unresolved), and the update went through without further ado. I’m on 188.8.131.52 now and even Alien Dalvik is working!
Got the message to remove or revert a bunch of packages (most of them seemed to be basic sailfish apps, such as Deadbeef music player nothing vital to my eye, so I ignored the warning). The update went smoothly until it got stuck at 100%. The phone was unresponsive, so after 45 mins or so I forced a restart with power+vol up. It restarted just fine and the phone seems to work ok. I did notice that some of the app icons are not where they used to be, I’m not sure if so apps got uninstalled or if I’m just seeing things.
But Sailfish sure likes to keep me on my toes, with all the weird warnings and hick-ups during updating.
Wrt to Browser still not making it to at least ESR78 engine, I’ve recently noticed that in the wild, Sailfish Discourse is maybe the only Discourse instance left that still works with it. Everyone else with Discourse has apparently upgraded to a version that rejects Browser as not-modern-enough and don’t render anything but this error message
As Discourse popularity seems to be growing for forums, I’ve now seen this fail message often enough across different companies and products to have motivation for writing this.
So, on my XA2 I have the 4 packages marked as possible ‘obstacles’ for the update process to 4.3 as well:
We have several community responses to this, where everyone seems to find some way out of it, but these all look like educated guesses (no offence: If you’ve managed to overcome any issues so far: Kudos to you!). But what is the official approach from jolla here: How should we end users deal with this? Which package should really be deleted and how? Or can this message be ignored? The only answer I could find was, that we maybe shouldn’t get such message in the first place. I understand that some issues look strange and need time to get thoroughly addressed, but at least I’d like to know what to do:
‘Go on and ignore the warning’, ‘delete just this and/or that, but leave the other ones’ or ‘don’t proceed until we’re done with investigations’. I’m fine with all of it, but it would be nice to have something at hand (maybe a good idea to put this in the hints for specific devices - because it seems to be related to the XA2 model - of the original post as well).
S | Naam | Type | Versie | Arch | Opslagruimte
i+ | harbour-whisperfish | pakket | 0.6.0.beta.7-0.sf4 | armv7hl | openrepos-rubdos
v | harbour-whisperfish | pakket | 0.6.0.beta.7-0.sf3 | armv7hl | openrepos-rubdos
v | harbour-whisperfish | pakket | 0.6.0-0.beta.6 | armv7hl | openrepos-rubdos
v | harbour-whisperfish | pakket | 0.6.0-0.beta.5 | armv7hl | openrepos-rubdos
S | Naam | Type | Versie | Arch | Opslagruimte
i+ | crypto-sdcard | pakket | 1.7.2-1.sfos401regular | noarch | openrepos-olf
v | crypto-sdcard | pakket | 1.7.2-1.sfos340regular | noarch | openrepos-olf
v | crypto-sdcard | pakket | 1.7.2-1.sfos340qcrypto | noarch | openrepos-olf
v | crypto-sdcard | pakket | 1.7.2-1.sfos321regular | noarch | openrepos-olf
v | crypto-sdcard | pakket | 1.7.2-1.sfos321qcrypto | noarch | openrepos-olf
v | crypto-sdcard | pakket | 1.7.2-1.sfos220regular | noarch | openrepos-olf
v | crypto-sdcard | pakket | 1.7.2-1.sfos220qcrypto | noarch | openrepos-olf
I don’t really see the difference at this point. If you’d have an idea, would be nice if you could send me a message here/on IRC (#whisperfish on Libera would be great) or Matrix (#whisperfish:rubdos.be)
This is a really elegant and sophisticated implementation of this versioning scheme for compiled software.
but it only correctly installs on SailfishOS 4.x now.
a. everything you did and the results achieved look correct.
b. but I remembered having issues with this, which are documented in Storemans’s issue #108: Initially, all was fine, but after almost a year I occasionally had similar issues.
Storeman’s solution ultimately was to switch to SailfishOS:Chum:
I will, once I figured out what I understood wrong. Most specifically, I’m still confused by the “dependency pairs”, and the “mutually exclusive dependencies”. I think it would help to have some real examples (without the and placeholders) worked out that clarify your terminology.
Thank you, very nice of you
That’s good to know, but I would’ve liked that you had found something
Ultimately, I really wonder why it would have worked it the first place. Zypper doesn’t seem able to cope with this: it wants to use the highest version of a package no matter what, it seems. To me, that would mean this property trickles down onto PackageKit and onto Storeman. So unless Storeman has some additional logic in place, it shouldn’t have been possible in the first place.
Ok. I will keep on publishing the packages like I do now, and put a note on the OpenRepos page with some zypper instructions. When Chum comes out with a GUI, and when Jolla decides to fix their cargo build, I will also move to Chum with Whisperfish. Separate repositories for every SailfishOS version is the better approach anyway, given that all normal Linux distro’s have that approach.
EDIT: would it maybe work (from within Storeman) if I made a second “application”?
But you did it the way I meant it and it is supposed to be.
Yes, they all use libzypp, which uses libsolv as its dependency resolver.
But it was working fine for a year (and not only for crypto-sdcard, also for Storeman), hence I assume some update of libzypp / libsolv broke it. Edit: Looking at the dates, that cannot be the case: I detected the change in behaviour mid 2021 on a device still being on SFOS 3.2.1 (from December 2019; the libzypp RPM was updated from v17.3.1 to v17.9.0 in SFOS 3.2.0 in November 2019), so that does not tell any conclusive story.
Still the RPMs created this way will only install on the intended OS releases, but that has to be performed manually for older OS releases.