I see that the SDK supports Docker but is it possible to run it with podman which is very common in the fedora-family distributions? Also the podman command is quite compatible with docker.
When I try to install the SDK it says that Docker is not installed.
Slightly OT: Coderusā SFOS-SDK Docker-images run using Podman.
No itās not possible. āquite compatibleā is not compatible enough in this case.
Podman would also allow for running the VMs under FreeBSD. Is this part of SDK open source?
Well, it depends on what you mean with āthis partā. The docker integration is mostly done in GitHub - sailfishos/sailfish-qtcreator: SDK IDE for SailfishOS application development.. However, the installer is not open source. So, even if you modified the qt creator/sfdk part so that it would work with podman, you would probably have to first install the SDK with real docker and then swap your self built binaries in place.
Thanks for the reply. Leaving the installer aside, is adding podman support as āsimpleā as adding podmanvirtualmachine.cpp analogous to the docker virtual machine or there is more to it? Also is this true for libvirtd support?
Well, yes and no. I believe that by default podman runs in rootless mode, which is going to be an issue. Then again, once someone figures out how to make it work, we could probably also add support for rootless Docker.
I did this - it worked a while - but bitrot pretty quickly 
It contains quite a lot of information what had to be tuned (6 years ago) to get it working,
which may be useful if anyone is attempting such a job.
These days I build from command line ā using containers in podman
(or just with zig cc -target aarch64-linux-gnu.2.30 or zig cc -target arm-linux-gnueabihf.2.30
on x86_64 linux host)
I should do something with that repo; too much obsoleted stuff laying around thereā¦
Wow, this is quite interesting! So as I understand it - the script extracts the VDI image from the offline SDK and imports it into podman. Also there is some more podman trickery that I dont understand. And finally it fakes the VirtualBoxexecutable to proxy the calls topodman`. This is amazing.
Thanks for the positive feedback. Was the podman trickery that
one which uses the same script to start container in host and then
running rest of it in container ā finally doing some post-run activities
in host - that is due to dockerfile/containerfile did not have enough
āfeaturesā (not even now) to do all the things Iād like it to doā¦
Now that I looked what I did at that time I remebered that was done
before sdk had docker option. the docker option requires (IIRC)
online installer. If one tried that (and made wrapper command docker just exec podman 2 problems would arise:
524288 subuids and subgids (100001 is not enough anymore)In one of these days I have to download the latest online installer,
make shell wrapper named docker and see how far I can get
and how easy would it be to get further with it. Was it so that
simulation on host cannot be run in (docker) container (but
that it needed VM environment) ?
Ok, I tried, had already too:524288:524288
in both /etc/subuid and /etc/subgid files, and
also had symlink from docker to podman in $PATH
downloaded SailfishSDK-3.12.5-linux64-online.run, chmodād
it and run (wayland application on wayland desktop to qt6 or qt5ā¦)
got as far as installer failing due to trying to run
docker network create --driver bridge sailfish-sdk:too
tried to run same from command line, sudo podman ... which failed with:
Error: network name sailfish-sdk:too invalid: names must match [a-zA-Z0-9][a-zA-Z0-9_.-]*: invalid argument
That looks like a regexp that disallows that ā:ā in the name, so Iād
guess that is hard to workaround, if the final installation expects
such a bridge to existā¦
[EDIT] workarounded with the following script as docker
#!/bin/sh -euf
echo "$@" >> /tmp/${0##*/}.x.txt
case $* in *sailfish-sdk:$USER*)
for arg
do test $arg = sailfish-sdk:$USER && arg=sailfish-sdk_$USER
shift; set -- "$@" "$arg"
done
esac
if test "${1-}" = run
then shift; set -- run --privileged "$@"
fi
exec podman "$@"
With this I am seeing 1-3 errors (which I ignored)
the log says (/tmp/docker.x.txt)
run --rm --volume sailfish-sdk-tools_too:/srv/mer --volume /home/too/SailfishOS:/host_install sailfish-sdk-build-engine:too bash -c
set -xe
tar -C /srv/mer --numeric-owner -xpf /host_install/mersdk/sailfish-tools.tar.xz
chown -R '1000' /srv/mer/targets
(run as podman run --privileged ... after wrapping)
but there is no ā¦/sailfish-tools.tar.xz there. however, /srv/mer/ is populated with quite a few dirs (*-aarch64, *-armv7hl and *-i486)ā¦
Then, in case of (rootless) podman, the chown -R 1000 ... may not
be needed (or then is ā or may hurt being there ā or then, may notā¦)
Hm, this is intersting. I do not know if it is a simillar issue, but I noticed a similar error and the cause was that the arguments for the bash call were not quoted properly (but mine was on the virtualbox path). I did soomething like this:
run --rm --volume sailfish-sdk-tools_too:/srv/mer --volume /home/too/SailfishOS:/host_install sailfish-sdk-build-engine:too bash -c
"set -xe
tar -C /srv/mer --numeric-owner -xpf /host_install/mersdk/sailfish-tools.tar.xz
chown -R '1000' /srv/mer/targets"
And the call passed. Note the double quotes around the bash -c argument.
The lack of āquotesā in arg(s?) after that bash -c in that log is due to:
i.e. the echo (builtin shell command) doesnāt show that the shell script is (most probably) all in one arg.
to be sure oneā¢ could change that to
{ echo --; printf %s\\n "$@"; } >> /tmp/"${0##*/}".x.txt
(sorry for that, too obvious for me after 10ā000s of times Iāve used such a thingā¦ ;D)
Thank you. I just tried a similar thing with libvirt. Using this approach I managed to fake VBoxManage and got the SDK installed. Then I converted mer.vdi to qcow2 format using this command:
qemu-img convert -f vdi mer.vdi -O qcow2 mer.qcow2
Then I created a new VM from the Boxes GUI app and selected the mer.qcow2 file and it booted up successfully! I suppose that the VM needs further tweaks to get it to build a package - networks, file sharing, dbus etc. And also the second-stage VBoxManage command needs to be updated to proxy the calls to ā¦ I donāt know ā¦ maybe virsh?
Great stuff. A KVM solution would be interesting to tryā¦