Then let me put it this way: it doesn’t. You won’t be able to fulfil “has been tested with” for one. They need something non-volatile.
Sorry to state this clearly: The info I provided is not “volatile” at all, rather solid. All these statements will be true in the future, for whatever future releases. I simply updated the outdated information and links, which lead users to non-working versions of Storeman Installer, and fail to comprehend why you are criticising this.
P.S.: I know that sailors are well able to communicate what they need, do not worry about this.
This 
. Thank you. I went to install a utility after the update (unrelated), and suddenly there were no applications in the chum store anymore. This was baffling, as I had used chum just fine the day prior…
Update itself seems to have gone smoothly so far.
This Chum thing is the same every update time.
If the version setting in Chum is set manually to 4.4.0.64 , Chum’s content is back again.
Can’t imagine that there are big incompatibilities from .64 to .68 . So don’t worry about this.
1 Like
Just tested and does not work yet. Which means I cannot use the device. If it does not pair to my car Bluetooth and I get a call, or need to call, while driving I am in trouble.
Sorry, I don’t think we are talking about the same issue.
I was referring to this bug report.
Not being able to pair to your car is a completely different matter, that I do not know anything about.
Yes, this is the same issue.
If I reboot the device without setting up the name again, it won’t pair to my car.
Do You mean you can’t even manually connect?
It would be good if the Chum repo maintainters found a way to streamline this.
Honest question to the Chum crew (@piggz , @rinigus, etc.):
Does it make sense to keep the patch version of the OS as different targets? They are supposedly only minor bugfixes, the core libraries on which most apps rely should have incompatible API changes.
Would it make sense to alias, or to pre-populate new OS patch version targets, with packages built against the precend patch? (i.e.: either serve the same packages to users running either 4.4.0.68 or .64)?
Also similar question regarding minor OS revisions: they do introduce new libraries and features, but they should be still backward compatible. Pre-populating older builds before OBS finishes rebuilding everything against the latest minor revision could be a hassle solver for people.
A different way to solve these problems would be at the application level:
The chum App could have a white list of version to force automatically until the correct version is available.
5 Likes
I need to delete the old device and pair it as if it were a new one (unnamed).
OK, Then there is another dimension to this bug. I have never had any trouble connecting manually after reboot.
Can you please mention this in the original bug report thread.
Manual connection works, but it is not a viable option. I cannot have to remember to delete the old device and add the new one every time I take the car and have rebooted the phone.
That’s what I mean, You shouldn’t have to delete the old device and add the new one, it should just connect, except auto.
What’s with this bad-faith interpretation?
I am not criticizing the action of updating as such. It is great that information is kept up to date.
I never said anything to the effect of “don’t update”.
But will you really be able to fulfill “have been confirmed to work fine” for say 4.5?
Or are you expecting Jolla to test Storeman on future releases?
If Storeman has been rearchitected to not break (with) updates in general that’s great, but then just say so.
Hi,
my Sony XPeria 10 III got stuck at 100% while upgrading from 4.4.0.64 to 4.4.0.68. I can’t even turn it off.
Is there anything I can do?
Thanks
got it sorted by pressing “volume-up + power-button”.
Phone did a reboot and everything seems to be fine.
5 Likes
I will make a separate bug report about this but since upgrading my xperia 10ii to 4.4.0.68 the call diversion is no longer working at all. It just states every time I try that " Service message Problem with service request".
Same here for me, but for the ‘Call Waiting’ function which cannot be enabled. X10 III 4.4.0.68.
It seems that none of those handy codes work anymore and they all give the same exact error message.
It used to be that we don’t have those patched versions. But recently, the practice has changed. Whether for it to stay or we will get back to single main release, I have no idea.
It would be possible to “solve” it either via additional OBS targets, via GUI (and risk incompatibilities), maybe somehow else. Feel free to open an issue at Issues · sailfishos-chum/main · GitHub, suggest and/or implement the solution.
Note that while we have OBS running, we have no spoken commitment from Jolla regarding its future. Some seasoned developers think that it is as good as it can be (no news regarding closure), I would prefer to get some kind of confirmation that it would stay up. But the backlog of tasks/issues as well priorities for each of us are different - maybe someone wants to fix this one.
3 Likes