#79432 Incus Package Build Failing

Message #5 received at submit@debbugs.gnu.org (full text, mbox, reply):

From: snalewife <snalewife@gmail.com>

To: bug-guix@gnu.org

Subject: Incus Package Build Failing

Date: Wed, 10 Sep 2025 17:09:04 -0700

[Message part 1 (text/plain, inline)]

Hello,

I am new to the Guix community, so I'm sorry if this is the wrong place to
ask about this, but I was trying to install the Incus package
<https://packages.guix.gnu.org/packages/incus> yesterday, and it failed to
build on my machine. I looked into why it wasn't available from
ci.guix.gnu.org, and found that the build is failing
<https://ci.guix.gnu.org/build/13578404/details> there as well. Based on
the error messages in the logs, I think this is because the TableWriter Go
library, which Incus depends on, made some breaking changes
<https://github.com/olekukonko/tablewriter/issues/270> in their latest
release. The Incus maintainers appear to have solved this issue by pinning
the version
<https://github.com/lxc/incus/commit/341d4252f4c1d5d9ce185598b7781cef2fbdaede>
of TableWriter to the "legacy" 0.0.5 release, but the Guix package
definition
<https://codeberg.org/guix/guix/src/branch/master/gnu/packages/virtualization.scm#L1350>
for Incus pulls in the Guix package for TableWriter
<https://packages.guix.gnu.org/packages/go-github-com-olekukonko-tablewriter/1.0.7/>,
which is on the latest release, and the breaking changes cause the build to
fail.

I would like to try and contribute a patch to both fix this issue and
update the Incus package to the latest release, but I am not sure what
would be the best way to proceed.

Pinning the version of TableWriter in the package definition for Incus
would be one option, but I am not sure how to do that. Is the accepted way
of doing this to create a secondary package called something
like go-github-com-olekukonko-tablewriter-legacy which builds version
0.0.5, and use that instead of the one with the latest changes?

But also, I am confused about why the package pulls in the Go dependencies
as Guix packages in the first place. It seems to me that the Incus
maintainers could pin any of their dependencies to whatever versions they
feel like, and the package definition would then have to be updated to pin
those versions as well. I feel like a better approach might involve relying
on Go to pull the packages in during the build instead, so that the
project's dependency file can be the single source of truth for what
versions are needed. I'm not even sure if that idea makes sense in the
context of how Guix works; am I just missing an understanding of some
fundamentals here?

Anyway, thanks for reading, appreciate y'all!

[Message part 2 (text/html, inline)]

Send a report that this bug log contains spam.