go-vikunja
.deb package available only for amd64
Original issue by BCMM on 2022-12-02T10:29:52.000Z
I would like to install the backend on a Debian armhf server. Is it intentional that the Debian package is only available for amd64?
@kolaente commented on 2022-12-02T15:24:49.000Z:
It's not intentional, it just hasn't been implemented yet. Looks like nfpm does support different architectures but not different binaries for these architectures. If I understand it correctly that means we'd need to template the nfpm config file and run it once for every architecture, adding the previously built binaries for each arch.
Do you want to send a PR?
BCMM commented on 2023-01-25T18:00:58.000Z:
Do you want to send a PR?
I'm afraid the whole Go ecosystem, including its build tools, is rather unfamiliar to me. I'm still not quite clear which components are involved in building Vikunja and how they interact.
(Sorry for the closing/reopening. I pressed the wrong button.)
@kolaente commented on 2023-01-25T21:18:46.000Z:
Sure, that's fine!
The nfpm config docs show they expand environment variables, maybe that could be used to release packages from different binaries (talking about the ci)
https://nfpm.goreleaser.com/configuration/
I can offer my help for this issue.
I think it is as simple as adding an environment variable to the config file and running the nfpm command for each arch.
Would love a PR for this. During the move to GitHub actions I've already changed the build so that we're depending on all binaries being built which should make this relatively easy.
I've started looking in to this again, and would like to ask a couple of questions about the direction I've been taking.
armhf package names
the build system produces two binaries which map to the "armhf" architecture, in .deb nomenclature: *-linux-arm-7 and *-linux-arm-6. I believe that these correspond to Debian's and Raspberry Pi OS's definitions of "armhf", respectively, and I propose to name the packages vikunja_${version}_armhf.deb and vikunja_${version}_armhf-rpi1.deb.
The reason I'm suggesting naming it after the hardware rather than the distro:
- Because the binary is statically-linked, the arm-7 bin should run on a Pi 2, even though it doesn't strictly match the OS's ABI. I'll be sure to actually test that before creating any PRs, though.
- I am not aware of any significant usage of APT distros on armv6 platforms other than Raspberry Pi 1 (but would be happy to be corrected on that).
Do the proposed package names make sense? Is there a different convention you would prefer?
Automating this properly
I still haven't really got my head around magefile.go.
However, I think I've got all the packages generating correctly with some changes to nfpm.yaml and a short shell script. If I can't manage to translate this in to Go, would you consider a PR to add the script? Its functionality could always be moved back in to mage at a later date.
Also, any advice on testing changes to the release workflow? Am I right in saying that this isn't the kind of thing that one can just play with on a forked repo, due to the Blacksmith and Hetzner integration?
