From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 11 01:16:30 2025 Received: (at submit) by debbugs.gnu.org; 11 Sep 2025 05:16:30 +0000 Received: from localhost ([127.0.0.1]:41682 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1uwZfZ-00059S-V5 for submit@debbugs.gnu.org; Thu, 11 Sep 2025 01:16:30 -0400 Received: from lists.gnu.org ([2001:470:142::17]:59766) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1uwUsQ-0001C3-Ef for submit@debbugs.gnu.org; Wed, 10 Sep 2025 20:09:27 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1uwUsL-00028b-2l for bug-guix@gnu.org; Wed, 10 Sep 2025 20:09:21 -0400 Received: from mail-pg1-x52f.google.com ([2607:f8b0:4864:20::52f]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1uwUsI-0005LJ-Rw for bug-guix@gnu.org; Wed, 10 Sep 2025 20:09:20 -0400 Received: by mail-pg1-x52f.google.com with SMTP id 41be03b00d2f7-b520c9c291dso183657a12.1 for ; Wed, 10 Sep 2025 17:09:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1757549355; x=1758154155; darn=gnu.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=1BDAgLaGi0h6hsc85xmxgvCDpV1YNkVrQsrno9TFByY=; b=P1+jWlK+1F27NaXTaSmvsD+PKOzf2h/3qoUvmy1ngv5oGSJfXHTKNvSL2F86wSKvqo GxRKQntgP0L9IrCV3T55BJePk4nfXBZZ/3aAmmtOMVlywnF5x70Bl9fkBRVgZ9tEGGFS f8Sfut582T0LpMYbl0w75q6vDG4rFE0v/Grj8/0D1ewPi5Eid8cu6Bpyf0CsdtOyAHVY 2XD9HQ6hSfss9hI68PjHHVVNCOdrzGFgZAZeXfLqJkJD0TGCnfS8WPx0cRJikt6iYaK6 fCkKOpLKltJg8coe+UPPQDdCyk0dc4xoVTvm4x558p+Zi+IY+loQ1TdQos9+qPQ/pN1l P/Kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1757549355; x=1758154155; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=1BDAgLaGi0h6hsc85xmxgvCDpV1YNkVrQsrno9TFByY=; b=ljmLMHOlogbQJ2w0y/B38KsYFAowprVnug0QzP9nAKDrm+jeY/zv3HGub+Xr16kTqw 73/HpbNKXVJyBXuBaQtsE4rHpSNUa2FwO51ItuhWaXCr15C9K+nkA1glXBYcdSdYVLlA mlKFjduKsmtamAvppw8gJxiWKCO42iVOa3h4eSpHSKz8aE8un6nf0Y26vGrSD1UCFuy2 pL/dHmYVizfGpU8iowuOKwJydnnJ1gGWjkvKs0OQ9o9UYD3Tj23p+9W4Spr2UOEKehJB kDV77D7Ak8d//LToAb2B50diBA9OZeruMRr9Y5PTvVpwjC7GL9eicrBZ27eWCKKTIIVv +abg== X-Gm-Message-State: AOJu0YyNPd6R0TmWGxKR5NJol/VbQdoiFFK/EdwH6qv+V2iP14r/KivG cC7tYvSieu1848A4tonJyE4PF1chJtX3B5gchpGjda3761Qzny5MJu7NutZ7/wxWtjU0K4GxP9A vAuitq8UO2JVnt3s2fhBMlCF3pQSy7vlQxg== X-Gm-Gg: ASbGncuynbFi0MVnrts43LVAEiKy7zWGVk5MQPg14YDK7OCvWL7A4iB/oUXLaa+gdIX UvtJOKiirtPzVmf4UUoFi/i9lbfrQf2TGyXRv6zeEsNAwaM0etkfigrukb0JyYFJ/xYkhJ23RVe 1jJZVxIBWbpVWq24IL64u1SHXx4/nxpwubKMgrr71QKBUS3t6h/9cAJscA1JQh/zLlAbmPP6rjh dUfbk/nyh2znzEM X-Google-Smtp-Source: AGHT+IHxwL397YENBNBQH3pIIlzegTVH7PKsRsgRgVJ53cxae96j1c1Hsuefqt0Ml/3VOlzw2jcldwpFW8ZnoUhDem0= X-Received: by 2002:a17:90b:350b:b0:32b:9d3c:13c4 with SMTP id 98e67ed59e1d1-32d43f8ea76mr23533113a91.24.1757549355234; Wed, 10 Sep 2025 17:09:15 -0700 (PDT) MIME-Version: 1.0 From: snalewife Date: Wed, 10 Sep 2025 17:09:04 -0700 X-Gm-Features: AS18NWC3rSkYDCWKxa0Lq9KObnx3ljB02VepsDd50KBVFtSsr44HAAHJyRJnyMk Message-ID: Subject: Incus Package Build Failing To: bug-guix@gnu.org Content-Type: multipart/alternative; boundary="000000000000fe789c063e7b58b4" Received-SPF: pass client-ip=2607:f8b0:4864:20::52f; envelope-from=snalewife@gmail.com; helo=mail-pg1-x52f.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Thu, 11 Sep 2025 01:16:28 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --000000000000fe789c063e7b58b4 Content-Type: text/plain; charset="UTF-8" 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 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 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 in their latest release. The Incus maintainers appear to have solved this issue by pinning the version of TableWriter to the "legacy" 0.0.5 release, but the Guix package definition for Incus pulls in the Guix package for TableWriter , 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! --000000000000fe789c063e7b58b4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 yesterday= , and it failed to build on my machine. I looked into why it wasn't ava= ilable from ci.guix.gn= u.org, and found that the build is failing there as well. Based o= n the error messages in the logs, I think this is because the TableWriter G= o library, which Incus depends on, made some breaking changes= =C2=A0in their latest release. The Incus maintainers appear to have solved = this issue by pinning the version of Ta= bleWriter to the "legacy" 0.0.5 release, but the Guix package definition for Incus pulls in th= e Guix package for TableWriter, w= hich is on the latest release, and the breaking changes cause the build to = fail.

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

Pinning the version of TableWriter in the package definition for Incu= s would be one option, but I am not sure how to do that. Is the accepted wa= y of doing this to create a secondary package called something like=C2=A0go= -github-com-olekukonko-tablewriter-legacy which builds version 0.0.5, and u= se that instead of the one with the latest changes?

But also, I am confused about why the package pulls in the Go dependencie= s as Guix packages in the first place. It seems to me that the Incus mainta= iners could pin any of their dependencies to whatever versions they feel li= ke, and the package definition would then have to be updated to pin those v= ersions 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 ne= eded. 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!
--000000000000fe789c063e7b58b4--