Like a charm. 10 Mk3.
No preparations with Storeman or Chum.
Thank you Jolla Team!
No, Itās to new reported. Maybe next mayor release if we are lucky
At lest some, and potentially a lot of packages, are device dependent.
Without all the parts there cannot be a whole; and it has to be published (by the maintainer) that it exists at all.
If just to say that the unique files for the previous version plus centrally updated ones makes a new version.
I am no expert either, but it is very a very observable thing that ports come a bit after and should not come as a surprise.
And it must have come up loads of times that chum is quite version-centricā¦ and has an override.
You could ask @piggz. I would guess heāll say something like:
gitlab ci, continuous integration of upstream with a lot of wagging my tail at device specified HAL bits. Sorry piggz, I know itās more like throwing figs at the approaching hordes!
2 Likes
piggz Ā· GitLab go here and or directly here: sailfishos-porters-ci Ā· GitLab
Itās a lot of reading but quite instructive.
3 Likes
Iām just shooting the shiā¦ but, isnāt much of that device dependent stuff hiden behind the HAL and weāre surfing on android open source lower level device drivers and co?
I noticed since last update, Vanha Rauma 4.4.0.68, Chum did not work anymore. Problem solved by Settings / Override automatic SailfishOS:Chum repository selection to 4.4.0.64.
2 Likes
Sure it does, just read it thoroughly. 
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.