Fix multi-arch container

[darkdragon-001]

Move build steps into container to actually build for other architectures. Fixes arm64 support added in #298.

[barthalion]

Not sure this is going to work, but we can always roll back.

[darkdragon-001]

@barthalion pull_request_target uses the workflow file from main which still has the step to build flatpak-builder outside of the Dockerfile. But as the new Dockerfile doesn't copy these files in, this could actually work.

[darkdragon-001]

@barthalion Also as the event is not pull_request but pull_request_target this will actually push the image with tag latest.

[barthalion]

Yeah, I noticed that in the actions log -- which is why I'm still online to get this tested.

[barthalion]

And for what it's worth, it would at best try to push it, the token wouldn't have permissions to do that.

[darkdragon-001]

bwrap: Creating new namespace failed: Operation not permitted, I guess we need to run the container as --privileged or run flatpak-builder with --disable-rofiles-fuse?

[barthalion]

--disable-rofiles-fuse may be enough. Image building process cannot use --privileged, the bwrap error is a red herring.

[darkdragon-001]

flatpak-github-actions uses --privileged: https://github.com/flatpak/flatpak-github-actions/blob/b8be6bc0ede43cb3a2cc55895654312b14f84a0d/README.md?plain=1#L31. I will try with --disable-rofiles-fuse.

[barthalion]

They use it to run the image, not build it.

[darkdragon-001]

They use it to run the image, not build it.

But they run flatpak-builder within the image...

[darkdragon-001]

Did I disable fuse correctly? I get

#20 104.4 FB: Running: flatpak build --die-with-parent --env=FLATPAK_BUILDER_BUILDDIR=/run/build/libxcvt --nofilesystem=host:reset --filesystem=/build/org.flatpak.Builder/.flatpak-builder/build/libxcvt-1 --bind-mount=/run/build/libxcvt=/build/org.flatpak.Builder/.flatpak-builder/build/libxcvt-1 --build-dir=/run/build/libxcvt/_flatpak_build --bind-mount=/run/ccache=/build/org.flatpak.Builder/.flatpak-builder/ccache --env=SOURCE_DATE_EPOCH=1708294716 '--env=CFLAGS=-O2 -pipe -g -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer ' '--env=CXXFLAGS=-O2 -pipe -g -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer ' '--env=LDFLAGS=-L/app/lib -Wl,-z,relro,-z,now -Wl,--as-needed ' --env=V=1 --env=MOUNT_FUSE_PATH=../tmp/
#20 104.4 bwrap: Creating new namespace failed: Operation not permitted

[barthalion]

I don't think this is going to work without building it outside the container. I can try to sort this out tomorrow.

[darkdragon-001]

With security.insecure, I now get Creating new namespace failed: Invalid argument.

[barthalion]

Assuming this works, we will need another job to create and push a single manifest including both when the dependant jobs succeed.

[barthalion]

Also would be nice to have some cache stored externally for the flatpak build, if you want to take care of it.

[barthalion]

Ok, implemented some caching. Let's see if it finishes before adding the manifest job.

[barthalion]

Seems to have worked until the log in part. Do you want to handle adding the manifest job?

[darkdragon-001]

Seems to have worked until the log in part. Do you want to handle adding the manifest job?

Sure, I will give it a try.

[darkdragon-001]

It doesn't seem to be possible to create manifests for images which are not yet pushed. I created the steps as I think they work but can't test them without permissions to push to a registry. @barthalion could you please take over from here?

[barthalion]

A few force-pushes later, this is live!

[barthalion]

https://github.com/flathub-infra/flatpak-github-actions/actions/runs/7951847449 is also green now

[darkdragon-001]

@barthalion Thank you so much for your help! Works like a charm!