Discussion: building for amd64 too

[julianfairfax]

I have forked this repo to build for amd64. These are my changes.

My question to you is: do you think it would be possible to include both arm64 and amd64 support in the same repo?

The reason is that this would effectively solve https://github.com/flathub/org.signal.Signal/issues/208

[adamthiede]

Cool; it looks like it works well. Nice job.

Honestly I'm putting minimal effort into these builds at this point. There already is a Signal amd64 flatpak (even though it's just a deb repackage) I don't see any advantage of this over that. Plus it'd take up more space on my cheap VPS, where I only have a 10G disk anyway.

What would be the goal of this - to submit it to the upstream flathub maintainers and ask for them to build and include it? Or for me to continue to host it myself? (It's not unreasonable to ask me to host it; I'm open to it.)

[julianfairfax]

What would be the goal of this - to submit it to the upstream flathub maintainers and ask for them to build and include it?

For the upstream flathub maintainers to basically copy the GitHub action from your repo to theirs. It would really cool though if we can get it working for both amd64 and arm64 with minimal changes. You can always build for arm64 only and those wishing to build for amd64 can copy your code and actually run it.

(Ideally the upstream flathub maintainers would also support arm64, but that requires building on an arm64 machine?)

[adamthiede]

Flathub likely won't take the github action; flathub builds on its own infrastructure. We'd have to get the build steps out of the action and into a flathub manifest (this file https://github.com/adamthiede/signal-desktop-builder/blob/master/flatpak.yml). This is how flathub does it: https://github.com/flathub/org.signal.Signal/blob/master/org.signal.Signal.yaml

Flathub also repackages the .deb. I might work on it this weekend. Alpine recently introduced an aarch64 signal-desktop package, too, so it's possible to have the same build steps for 2 architectures. https://gitlab.alpinelinux.org/alpine/aports/-/tree/master/testing/signal-desktop?ref_type=heads

[julianfairfax]

Flathub likely won't take the github action; flathub builds on its own infrastructure.

True.

Flathub also repackages the .deb.

In that case, this repo could just release both amd64 and arm64 debs, and the Flatpak could then use both of them as a way to add arm64 support and show that it's being built from source.

[adamthiede]

I'm not sure they'd be happy about taking .debs from a random source instead of the official linux release. I know I'd trust Signal themselves over me!

[julianfairfax]

This isn't a random source though, it's built from the Signal source.

[adamthiede]

Yeah, but I'm just some random guy, not the official distribution. I could have a malicious compiler on my build machine, etc... adding me in the chain of trust for this paints a target on my back I'm uncomfortable with as well.

If the flathub maintainer is comfortable with it, we can just have him add a second source section in his flatpak manifest to consume the .deb in the release artifacts here and repackage it the same way as the official .deb. But I doubt he and flathub would be comfortable with this.

I think the ideal situation is to have the flathub infrastructure build both x86_64 and aarch64 from source. But that's a significant effort. Again, I can work on it this weekend, but the build system for signal is fairly complex.

[adamthiede]

I posited this to flathub's signal maintainer and got a "no", as expected: https://github.com/flathub/org.signal.Signal/issues/137

But he suggested the right direction is moving all the build stuff into the flatpak manifest. That'll be a bit difficult since flatpak builds by default can't access the Internet. An interesting challenge!

[julianfairfax]

@adamthiede have you had time to look into this recently?

[adamthiede]

I've not, sorry. Family+work keeping me busy. I have a friend who knows web dev quite well and I've intended to ask him to help with this, and it would be a good excuse to visit him. No promises, but I still haven't forgotten!

[julianfairfax]

@adamthiede should I maybe look into merging our two repos myself? Or is this intended to also help close this?

[adamthiede]

Yes, that's intended to be the way forward. I worked on it a bit last weekend. Building an electron app from source in flatpak is pretty tough; having to deal with all the downloaded dependencies and all that. I'll continue again this weekend.