It sure was the right measure to drop that flag: While some Android apps may use more RAM then, these will also exhibit their full (i.e., usual) functionality.
Specifically the “auto-killing behaviour” is completely independent of flagging isLowRamDevice to apps.
I wait a minute or two before I turn mobile network off after turning on WiFi and vice versa. This seems to work most of the times. XA2, 4.2
+1 to this. The mobile/wifi alteration connection issue was gone for a couple of days after the update but then started happening again.
“Remove or revert…
git-minimal
gittin
mapboxgl-qml
ofon-alien-binder-plugin”
What a bloody useless warning on the 4.3 upgrade:
They’re not apps I installed and can recognise, they components used invisbly by other apps.
I have absolutely no idea what uses them, so other than randomly uninstalling some apps i have installed we’re flying blind into this upgrade.
Huzzah!
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)
Right now this regression is an irritant.
Can somebody give me a hint how to remove those packages (git-minimal & gittin)?
I ignored it…and then the update process hanged around 100%. Had to wait until battery was empty. But now everything is ok…
Remove or revert the following
packages, as they may cause
problems during update:
git-minimal
gittin
ofono-alien-binder-plugin
This is a “vanilla” XA2, initial install was v3.1.0.11 (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 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.