github-starred/vikunja
2
0
Fork 0
mirror of https://github.com/go-vikunja/vikunja.git synced 2026-05-05 19:18:16 -05:00
Code Issues 690 Packages Projects Releases 11 Wiki Activity

[GH-ISSUE #528] .deb package available only for amd64 #6220

New Issue
Open
opened 2026-04-20 16:48:46 -05:00 by GiteaMirror · 3 comments
GiteaMirror commented 2026-04-20 16:48:46 -05:00
Owner
Copy Link

Originally created by @vikunja-bot on GitHub (Apr 1, 2025).
Original GitHub issue: https://github.com/go-vikunja/vikunja/issues/528

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?

Original issue on Gitea

@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/

Originally created by @vikunja-bot on GitHub (Apr 1, 2025). Original GitHub issue: https://github.com/go-vikunja/vikunja/issues/528 _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? [Original issue on Gitea](https://kolaente.dev/vikunja/vikunja/issues/1331) --- _**@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/
GiteaMirror added the area/dockerarea/internal-code labels 2026-04-20 16:48:46 -05:00
GiteaMirror commented 2026-04-20 16:48:48 -05:00
Author
Owner
Copy Link

@andrewwippler commented on GitHub (Apr 11, 2025):

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.

<!-- gh-comment-id:2796285025 --> @andrewwippler commented on GitHub (Apr 11, 2025): 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.
GiteaMirror commented 2026-04-20 16:48:49 -05:00
Author
Owner
Copy Link

@kolaente commented on GitHub (Apr 11, 2025):

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.

<!-- gh-comment-id:2796347637 --> @kolaente commented on GitHub (Apr 11, 2025): 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.
GiteaMirror commented 2026-04-20 16:48:51 -05:00
Author
Owner
Copy Link

@BCMM commented on GitHub (Jun 29, 2025):

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:

  1. 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.
  2. 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?

<!-- gh-comment-id:3017214695 --> @BCMM commented on GitHub (Jun 29, 2025): 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: 1. 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. 2. 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?
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area/api
area/attachments
area/auth
area/avatars
area/backup-restore
area/caldav
area/calendar-view
area/comments
area/config
area/database
area/desktop
area/docker
area/email
area/favorites
area/filters
area/frontend
area/gantt
area/i18n
area/import-export
area/internal-code
area/kanban
area/labels
area/list-view
area/mobile
area/notifications
area/permissions
area/projects
area/pwa
area/recurring-tasks
area/reminders
area/search
area/shortcuts
area/subtasks
area/sync
area/table-view
area/task-editor
area/task-metadata
area/task-relations
area/teams
area/theming
area/time-tracking
area/typesense
area/views
area/webhooks
bug
changes requested
concern/accessibility
concern/performance
concern/regression
concern/ux
confirmed
db/mysql
dependencies
enhancement
good first issue
help wanted
integration/inbound
integration/outbound
kind/bug
kind/feature
needs reproduction
pull-request
Mirrored from GitHub Pull Request
 question
security
support
upstream issue
waiting for reply
wontfix
No Label area/docker area/internal-code
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/vikunja#6220
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?