When updating permissions using command line chmod within the sdk, permissions appear to update correctly, but on the host the remain the same. Becuase on the host there is no r permission, its not possible to cp a file within the sdk
[SailfishOS-4.6.0.11EA-aarch64] upstream # cp test.out test.2
cp: cannot open ‘test.out’ for reading: Operation not permitted
[SailfishOS-4.6.0.11EA-aarch64] upstream # ls -lh test.*
-rw-r–r-- 1 1001 1001 239 Sep 19 16:17 test.cpp
-rw----r-- 1 root root 239 Sep 19 16:24 test.out
As far as I understand, its a bug that goes into mb2/sb2. And that is in SFOS Platform SDK, and SFOS SDK and SFOS OBS. Or you cannot reproduce it on some of the SDKs?
Ive actually been using the regular SDK, not the platform SDK for these builds, via the sfdk tool. And as @ringus says, its in sb2/mb2 which is common to all environments
The reason I’m asking is that the bug in sb2 should be relatively¹ easy to fix. However, that is not enough to fix this on the Sailfish SDK. The Sailfish SDK works on three operating systems and two very different virtualization platforms, and in addition to that there are quite a few filesystems the host operating system might use. Getting the permissions to work in an even closely sane manner in all possible configurations is on a whole different ballpark.
¹ it’s not easy - just relatively when comparing to getting the permissions to work in all possible configurations.
When we get to these bugs, I do wonder whether it makes sense these days to switch over to native builds. aarch64 is available in cloud providers and, as an alternative, qemu could be used for smaller projects. I could work around permissions bugs using qemu and native builds on PC.
I tried to replicate on Linux Host (debian bookworm), with Docker build engine and ext4 filesystem. The permissions are shown correctly on host. I suspect the culprit is the VirtualBox engine, as it does not really support permissions.
What about the same issue on OBS though? on aarch 64 builds of qt6, files created by the build have invalid permissions and become uninstallable at the install section
And I think in this case, the issue is in the execution of qmlregistrar for the creation of the .qmltypes file… which is the same in all the failing cases (except qtbase)