GNU bug report logs - #67707
Fresh installation leaks details about ISO build environment

Previous Next

Full log

View this message in rfc822 format

From: Rutherther <rutherther <at> ditigal.xyz>
To: Ludovic Courtès <ludovic.courtes <at> inria.fr>
Cc: 67707 <at> debbugs.gnu.org
Subject: bug#67707: Fresh installation leaks details about ISO build environment
Date: Sat, 03 May 2025 19:29:06 +0200

Hi Ludo,

Ludovic Courtès <ludovic.courtes <at> inria.fr> writes:

>
> Rutherther <rutherther <at> ditigal.xyz> writes:
>
>>> That the URL is wrong doesn’t have any impact because it’s not used by
>>> ‘guix pull’ or anything, but it’s obviously not great.
>>
>> this is not exactly true. It might be used, by the forward update check
>> on guix system reconfigure.
>> When the user hasn't pulled yet, they don't have any checkout, and a new
>> one is being created by looking at the folder
>> /home/ludo/src/guix/version/... That will end up with an error.
>
> True.
>
>> Maybe the installation-os should not use (current-guix) as that can lead
>> to issues like this? Could we instead just detect the commit and change
>> the url to the savannah/codeberg one?
>> Or will it just be ensured next time that the channels used to build it
>> point to the hosting url and not at a local one?
>
> I think so.  It should be as simple as this:
>
> diff --git a/gnu/packages/package-management.scm b/gnu/packages/package-management.scm
> index f0a9b39e25..46cf9b8512 100644
> --- a/gnu/packages/package-management.scm
> +++ b/gnu/packages/package-management.scm
> @@ -1,5 +1,5 @@
>  ;;; GNU Guix --- Functional package management for GNU
> -;;; Copyright © 2013-2024 Ludovic Courtès <ludo <at> gnu.org>
> +;;; Copyright © 2013-2025 Ludovic Courtès <ludo <at> gnu.org>
>  ;;; Copyright © 2015, 2017, 2020, 2021, 2022, 2023 Ricardo Wurmus <rekado <at> elephly.net>
>  ;;; Copyright © 2017 Muriithi Frederick Muriuki <fredmanglis <at> gmail.com>
>  ;;; Copyright © 2017, 2018 Oleg Pykhalov <go.wigust <at> gmail.com>
> @@ -673,7 +673,8 @@ (define-public current-guix-package
>              ((? channel? source)
>               (package
>                 (inherit guix)
> -               (source source)
> +               (source (channel (inherit %default-guix-channel)
> +                                (commit (channel-commit source))))
>                 (build-system channel-build-system)
>                 (inputs '())
>                 (native-inputs '())
>
> Maybe there are cases where it’s not desirable (someone maintaining a
> fork for example), but those are hypothetical edge cases.
>
> WDYT?

What I had in mind in the first place was replacing it just in the
install.scm, I didn't even think about changing it here.

I don't know, it feels a bit icky. This might be a good default - one
commonly uses (current-guix) for putting to virtual machines and you
don't want to end up with a local folder there. On the other hand,
there are cases when you do want the same channels and will get more
complicated with this change since one will have to get to know
repository->guix-channel and current-source-directory. What about making
two procedures, one that replaces with the default channel url and one
that doesn't?

Btw given the current state of things, I think this is quite 'dangerous'
as savannah is commonly failing, and people using (current-guix) end up
with it. This will hopefully be resolved in the future (either by switch
to codeberg or hopefully savannah will get better), but if this was
merged now I think it can cause more confusion.

Related to this issue, I am playing with an idea to introduce a new
option to guix system reconfigure that would skip the forward update
check. While it makes sense, especially lately it shows how problematic
it can get. There are people who cannot reconfigure because they have
savannah in their channels, they first have to pull from codeberg, and
even that is just a workaround (thankfully the forward update check will
use the repository you currently have configured instead of the older
one). This could happen even with other channels, not just guix.
Additionally it's also not so good for virtual machines where you
are just quickly testing something, and have to wait for a full checkout
fetch just because you decided to reconfigure. (maybe if the commit is
the same one as the old one there should be an additional check so that
nothing is fetched in the first place)

Thanks
Rutherther

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.