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 4.3.0.12 now and even Alien Dalvik is working!
Thank you very much for sharing your experience.
Well, i removed the packages in the terminal:
[nemo@Sailfish ~]$ devel-su
Password:*****
[root@Sailfish nemo]# pkcon remove git
-minimal
After the upgrade to EA 4.3, I miss the simkit tools app icon on Xperia X.
My update process (XA2 Dual SIM):
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).
Best regards
Thanks for the update. After the update to 4.3.0 my third camera is missing on Xperia 10 II. Am I the only one with this bug?
edit: reboot fixed it for me.
Hi @olf, I might be slightly confused by your write-up. I think I managed to replicate what you did, see rpm/harbour-whisperfish.spec · master · Whisperfish / Whisperfish - Signal on Sailfish OS · GitLab, but it only correctly installs on SailfishOS 4.x now. I tried creating two packages, one for 3.x and one for 4.x, and added a .sf3 or .sf4 suffix to the release field to differentiate the RPM names. Dependencies seem correctly set in my macro, so at least syntactically I’m correct:
$ rpm -qpR harbour-whisperfish-0.6.0.beta.7-0.sf3.armv7hl.rpm
sailfish-version >= 3.0
sailfish-version >= 3.3
sailfish-version < 4.0
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)
If you specify which statements were imprecise, I will gladly enhance them.
I think I managed to replicate what you did, see rpm/harbour-whisperfish.spec · master · Whisperfish / Whisperfish - Signal on Sailfish OS · GitLab,
This is a really elegant and sophisticated implementation of this versioning scheme for compiled software.
Cool!
but it only correctly installs on SailfishOS 4.x now.
Oh,
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.
And it IMO it is supposed to work this way, but obviously needs a proper bug report at https://github.com/openSUSE/libsolv/issues
I think the observations we made here and at Storeman issue #108 are sufficient for this.
Hi,
I eventually experience the same as Samule: on a Xperia x f5122, all went apparently well, in spite of showing many system packages as being in the way if the upgrade but now, few seconds after each boot, it reboots on and on. There is not enough delay to analyse.
Unfortunately, that is the 2nd upgrade with a problem: 4.2 forced me to reinstall from ground up. Let’s hope I will avoid that.
Has anyone a clue how to stop that boot loop else than reinstalling fresh?
Ddelamarre
Me too, Xperia X. Ran ‘jolla-camera’ in terminal and got
[D] unknown:0 - Using Wayland-EGL
jolla-camera: /usr/share/droidmedia/hybris.c:53: __resolve_sym: Väite ”ptr != NULL” ei pidä paikkaansa.
Aborted (core dumped)
Claims that ptr != NULL is not true.
Erm…
And a nice workaround
Maybe some insights, @Jolla?
Thanks for flagging these posts here @peterleinchen. There’s a relevant comment from @abranson in the thread you reference on this. It would be good to please refer to his comment before jumping straight in and trying the workaround. It’ll help us diagnose the problem and may also prevent further issues down the line.
The SIM Application Toolkit icons appear to be broken in the UI after the update. Logs show QML errors.
I was able to run a SIM application manually from the command line:
dbus-send --dest=org.sailfish.simkit --type=method_call / org.sailfish.simkit.show
There is also another method signature which takes a list of strings, presumably the application name(s).
Reference: D-Bus APIs - SailfishOS Documentation
I just updated
When I try to enable the internet I see “Connecting” then “Limited connectivity” then back to connecting!
My phone didn’t do this prior to the update, anyone else seen this?
With this new version, I have the following regression:
When starting the camera from the lock screen (while the phone is locked, i.e. you’re asked the pin to get out of the lock screen), and you record a video, the screen will turn off and the app will stop the recording after a bit more than 30 seconds. (I have to touch the screen to prevent this.)
Anyone else have this issue?
I have a Sony Xperia XA2.
Yes, confirmed.
And created a bug report
Try version 3.11 or 4.16. Works for me but there is a slight audio delay with the sound.