Felix Lechner <felix.lechner@HIDDEN>
to control <at> debbugs.gnu.org.
Full text available.
Received: (at 63787) by debbugs.gnu.org; 29 May 2023 17:32:24 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon May 29 13:32:24 2023
Received: from localhost ([127.0.0.1]:59099 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1q3gjH-0002d3-Ct
for submit <at> debbugs.gnu.org; Mon, 29 May 2023 13:32:24 -0400
Received: from mail-ed1-f68.google.com ([209.85.208.68]:50205)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <liliana.prikler@HIDDEN>) id 1q3gjE-0002cp-Qp
for 63787 <at> debbugs.gnu.org; Mon, 29 May 2023 13:32:21 -0400
Received: by mail-ed1-f68.google.com with SMTP id
4fb4d7f45d1cf-5149429c944so3685302a12.0
for <63787 <at> debbugs.gnu.org>; Mon, 29 May 2023 10:32:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20221208; t=1685381535; x=1687973535;
h=mime-version:user-agent:content-transfer-encoding:references
:in-reply-to:date:to:from:subject:message-id:from:to:cc:subject:date
:message-id:reply-to;
bh=FmgKcWnjvrh6OJvXvqRH+nqzhGGoyt0vW5tYHWnsNCc=;
b=FQY3V1M+kizXjRYGhfOZ3ejfaYBuELENAkJr+qCgDsjdfTZlhV0paIet/n41s4hKb/
kMm9a9iKxoQS3Apbd1otWwceGmcONxyiQxQ9wErjZ/3jHUw39MSDQG7+BfxUolOOJLgK
uEBUxtMjjDCjS2rQRBn5tYz5lQ47XPkulySDhvnrqKX+lt2LsZo7tblAkDSGV8NtiKrm
1YgZcNZihYB96Fg+hYQLrFEznOK2z7P0gywd+N8RHhctK2lJ54GJziYQ6SskuTLVSkPq
vY6nG+9TcFRNpSBQLtolEyGa/xzzrsLYDIKf+Qniu6h+urv7GHj4O7dt7FtwpALlB0Y3
Lq4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20221208; t=1685381535; x=1687973535;
h=mime-version:user-agent:content-transfer-encoding:references
:in-reply-to:date:to:from:subject:message-id:x-gm-message-state:from
:to:cc:subject:date:message-id:reply-to;
bh=FmgKcWnjvrh6OJvXvqRH+nqzhGGoyt0vW5tYHWnsNCc=;
b=XkCZ4pXRixEWfO8y54NR+3+3uz6KkN+W5GnrdlMc41cM9nM7AowijFguYTK8MJOQEr
oEb3x7Qw+IfPEivIVL2Gzu1yF2OGqdyaDQ29J7TFWsJEe66/KqRMHCTswlyPKU5WNEsg
WTElX4zBst6neM/nQt9P1W7qZYVjWgAdxGeLyMXVbfWRsKtIHPlZ9o2Helb5G21dm2lQ
RJ2UU7edAWaMMcMW1aXeaXgvAW9cpZyJQEBLSzAZowqa3rvsOlGqkh1Tz4+JQw0kh+Ce
kDivepYgCkZqJEYimuQd6l2kAZT+748pmuIFqBFtYV8x6T1hwrIRMJaUujgQ9JLlhJ6R
29mw==
X-Gm-Message-State: AC+VfDy9nxvDX6Lo6/xIMky9Gtgv90+T34X6hpJYhT0Hy0LyL6dWus/i
9iuYrdSddBgJhOwcggrXuLZCo6Ow9RibLKpw
X-Google-Smtp-Source: ACHHUZ7QQkZScDHQ4UwmLD7DJ1hU71JTNJRd+De8LyVe17D5vocwrl7YYAKLGYjx5DTFXBV9rHnR+A==
X-Received: by 2002:aa7:d3d6:0:b0:514:7fab:294d with SMTP id
o22-20020aa7d3d6000000b005147fab294dmr284151edr.36.1685381534885;
Mon, 29 May 2023 10:32:14 -0700 (PDT)
Received: from lumine.fritz.box (85-127-52-93.dsl.dynamic.surfer.at.
[85.127.52.93]) by smtp.gmail.com with ESMTPSA id
a21-20020aa7d755000000b0050bc041d2a8sm3263390eds.15.2023.05.29.10.32.14
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Mon, 29 May 2023 10:32:14 -0700 (PDT)
Message-ID: <afc26db863444d1d148b6d043c8cfc86b98a4548.camel@HIDDEN>
Subject: Re: udev-rules-service inoperable for some rules
From: Liliana Marie Prikler <liliana.prikler@HIDDEN>
To: Felix Lechner <felix.lechner@HIDDEN>, 63787 <at> debbugs.gnu.org
Date: Mon, 29 May 2023 19:32:13 +0200
In-Reply-To: <CAFHYt55059XYmkR_UFw0FjHg5iHcw8-=O=hxSjt9-hgLMgaxKg@HIDDEN>
References: <CAFHYt55059XYmkR_UFw0FjHg5iHcw8-=O=hxSjt9-hgLMgaxKg@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.46.4
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 63787
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Hi Felix,
Am Montag, dem 29.05.2023 um 08:25 -0700 schrieb Felix Lechner:
> Hi,
>=20
> A brief thread from guix-devel about trying to use MAC-based names
> for network interfaces [1] shall be incorporated herein by reference.
>=20
> =C2=A0 [1]
> https://lists.gnu.org/archive/html/guix-devel/2023-05/msg00192.html
>=20
> On Wed, May 17, 2023 at 6:14=E2=80=AFPM Felix Lechner
> <felix.lechner@HIDDEN> wrote:
> >=20
> > In a concession to Liliana's opposition, I retitled the bug to
> > sidestep the question of the MAC-based names as a default setting.
>=20
> It was not enough of a concession.
Heads up, that was not a nice way of phrasing things =E2=80=93 at least as =
I, a
non-native English speaker take it. To me, "concession" implies some
backdrop of a fight between opposing forces, whereas I do see the
problem you're facing but want to find a better solution. In other
words, we share a goal.
> In Guix, many custom rules like the following=E2=80=94namely those that u=
se
> values determined by udevadm=E2=80=94are inoperable.
>=20
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (ude=
v-rules-service 'net-name-mac
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 (udev-rule
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "79-net-name-mac.rules"
> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 "
> > SUBSYSTEM=3D=3D\"net\", ACTION=3D=3D\"add\", NAME=3D\"$env{ID_NET_NAME_=
MAC}\"
> > ")))
>=20
> The issue is that udevadm looks in the installation folder for udev
> rules. In standard distros, that works fine because the installation
> folder and the runtime folder are the same. Unfortunately, that is
> not so for Guix. The installation folder is in the store.
For the record, I'm not sure whether udevadm is the sole component at
play here. Sure, it's a tool you may invoke at the command line, but
the big daemon thingy, that's udevd.
> The way I understand our strategy in Guix, we construct another,
> aggregate folder with links to rules in /etc/udev/rules.d. (That
> location also happens to be the installation directory for many
> traditional distros.) I proposed a local patch that causes udevadm to
> look in that folder instead. [2] It replaces one line in the source
> code.
>=20
> =C2=A0 [2] https://issues.guix.gnu.org/63508#12
>=20
> Liliana, who kindly reviewed my patch, disagreed with that solution.
> For reasons I do not fully understand, she prefers a more generalized
> solution via an environmental variable called EUDEV_RULES_DIRECTORY.
> [3] As far as I can tell, that variable is not provided by upstream.
> It was invented by a custom patch to Guix [4] and currently does not
> seem to work all the way.
>=20
> =C2=A0 [3] https://issues.guix.gnu.org/63508#6
> =C2=A0 [4]
> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/patches/eude=
v-rules-directory.patch
Note: EUDEV_RULES_DIRECTORY was implemented by Ludo in 2014 [6, 7]. In
one year and a little bit it will celebrate ten years of being with us.
I think it is allowed to grow up.
> Liliana insists on improving the environment variable
> EUDEV_RULES_DIRECTORY, while I have several issues with that.
Just as I take issue with not using an environment variable for the
purpose it serves :)
> For starters, my substitution is simpler.=C2=A0
Simpler is not always better. One might say that overwriting files as
you install packages is simpler than worrying about setting the right
symlinks, but Guix, being a functional distribution, does the latter.
> It is also a common packaging strategy in Guix. (I furthermore cannot
> envision setting the variable to any value other than
> /etc/udev/rules.d, although maybe the flexibility comes in handy one
> day.)=C2=A0
Supplying an environment where there previously was none is also a
common packaging strategy for Guix. The fact that said environment
variable was already introduced prior to my patch should tell you as
much.
> Mainly, however, I believe that her patch goes beyond the typical
> packaging activity.
Note how said environment variable already exists prior to this patch.
It is well within typical packaging activity.
> By implementing a new feature, the patch for EUDEV_RULES_DIRECTORY
> should really be sent upstream. I do not know whether that's already
> happened, but I am not convinced upstream would accept it.
I doubt that I'd need upstream permission to modify local patches that
haven't been accepted upstream yet. Granted, our patch could be sent
upstream, but at this point I feel like we've already diverged a little
bit from the usual scenario.
> In the latest 3.2.12 release, which does not work without further
> modifications in Guix, the upstream developers added a command-line
> option called '--root' to udevadm [5] that offers another solution to
> setting the runtime path. Unfortunately, that option does not change
> the default, which is the issue in this bug.
>=20
> =C2=A0 [5]
> https://github.com/eudev-project/eudev/blob/2703baf55615b7554fb67c4f1c241=
f057f8c0a79/man/udevadm.8#L378C2-L380
You're again assuming that udevadm is the only component at play here.
I have yet to hear your reason for believing so.
> Finally, programming styles also differ. I have philosophical
> objections to the use of pointer arithmetic, although the upstream
> code may have some of that, too.
You may object to the use of pointer arithmetic, but it's not a
requirement for my solution; it's just how I chose to implement it.=20
You can get a semantically equivalent patch without pointer arithmetic
and a virtually equivalent patch without either pointer arithmetic or
equivalent C code by assuming a default value for
EUDEV_RULES_DIRECTORY. I simply didn't want to do any of those at the
time of writing.
> With the discussion at an impasse, I am not sure how to proceed.
> Eudev, which is an essential part of any modern Linux operating
> system, is not working properly in Guix.
>=20
> Liliana challenged me to "file a formal complaint." [6] I do not know
> what that means and now filed this bug in hope of finding an
> acceptable way forward. Maybe it is easier to discuss the reasoning
> for one fix or another when the arguments for and against are not
> separated by multiple versions of competing inline patches.
By "fil[ing] a formal complaint", I meant to discuss my patch in more
than passing. I would have liked for that to take place in the other
thread or the one you've started over at guix-devel, but I can also
take criticism here. =C2=A0As for why I "challenged" you in the first place=
:
I take my time to read and reply to your patches, so by the principle
of reciprocity I assume it to be fair for you to do the same. I feel
as though you don't give my words the consideration they deserve: I am
reading the same patch for the third time by now and you are still
using (regexp-quote ...) instead of manually quoting the nasty bits as
is done throughout the codebase.
Cheers
[6]
https://git.savannah.gnu.org/cgit/guix.git/patch/?id=3Dc19ce3a711fea24c173d=
615a4a7b162dbc86ce68
[7]
https://git.savannah.gnu.org/cgit/guix.git/patch/?id=3D66a99a06761b2cf0aa3f=
a6d70e97e767ab237fcb
bug-guix@HIDDEN:bug#63787; Package guix.
Full text available.
Received: (at submit) by debbugs.gnu.org; 29 May 2023 15:26:08 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon May 29 11:26:08 2023
Received: from localhost ([127.0.0.1]:58914 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1q3el6-0002YE-4C
for submit <at> debbugs.gnu.org; Mon, 29 May 2023 11:26:08 -0400
Received: from lists.gnu.org ([209.51.188.17]:54774)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <felix.lechner@HIDDEN>) id 1q3eku-0002Xh-VS
for submit <at> debbugs.gnu.org; Mon, 29 May 2023 11:26:07 -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 <felix.lechner@HIDDEN>)
id 1q3eku-00059P-LN
for bug-guix@HIDDEN; Mon, 29 May 2023 11:25:56 -0400
Received: from sail-ipv4.us-core.com ([208.82.101.137])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_CHACHA20_POLY1305:256)
(Exim 4.90_1) (envelope-from <felix.lechner@HIDDEN>)
id 1q3eks-0006Fy-NP
for bug-guix@HIDDEN; Mon, 29 May 2023 11:25:56 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=2017; bh=nJjPEa6lahAySzA
HZhNPejasxPEsS+gtjkpR29oBigM=; h=cc:to:subject:date:from;
d=lease-up.com; b=U62ZKGxho9qn42uYDUaS9gO+Kxd6zN8o3rysyiABeZjAysMNfRHS
0ISsVgThXvwICZhxoOPVJvgL9HdFG1Fo7MijjKOddRSPZX/n5R2cO7meYHqOrbR+isTU6d
KGz8ughOg91xSOVEGftNMkq1/ggmfNyCbbfBBwWAV41gjczWQ=
Received: by sail-ipv4.us-core.com (OpenSMTPD) with ESMTPSA id f14cd0b8
(TLSv1.3:TLS_CHACHA20_POLY1305_SHA256:256:NO) for <bug-guix@HIDDEN>;
Mon, 29 May 2023 15:25:49 +0000 (UTC)
Received: by mail-lj1-f170.google.com with SMTP id
38308e7fff4ca-2af20198f20so34921951fa.0
for <bug-guix@HIDDEN>; Mon, 29 May 2023 08:25:49 -0700 (PDT)
X-Gm-Message-State: AC+VfDxOj3v+pYXTC1F175tgJyEx1j7urYYpSmL3C2/A+vzInyho4piQ
20lV38cBFQH4E9/tSF3zjzSdQPvnINyVhAsP0fw=
X-Google-Smtp-Source: ACHHUZ5ZAeNyNQgKcGHP/4j967w2cRu346d9Mm167eEvFDJ84A3j66LbQnd3YxtQmDNUxiq89TRvYwhMUTAUQyEuKQY=
X-Received: by 2002:a2e:8544:0:b0:2ad:a78a:df0d with SMTP id
u4-20020a2e8544000000b002ada78adf0dmr4012159ljj.44.1685373947351; Mon, 29 May
2023 08:25:47 -0700 (PDT)
MIME-Version: 1.0
From: Felix Lechner <felix.lechner@HIDDEN>
Date: Mon, 29 May 2023 08:25:11 -0700
X-Gmail-Original-Message-ID: <CAFHYt55059XYmkR_UFw0FjHg5iHcw8-=O=hxSjt9-hgLMgaxKg@HIDDEN>
Message-ID: <CAFHYt55059XYmkR_UFw0FjHg5iHcw8-=O=hxSjt9-hgLMgaxKg@HIDDEN>
Subject: udev-rules-service inoperable for some rules
To: bug-guix@HIDDEN
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=208.82.101.137;
envelope-from=felix.lechner@HIDDEN; helo=sail-ipv4.us-core.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, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 0.9 (/)
X-Debbugs-Envelope-To: submit
Cc: Liliana Marie Prikler <liliana.prikler@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.4 (--)
Hi,
A brief thread from guix-devel about trying to use MAC-based names for
network interfaces [1] shall be incorporated herein by reference.
[1] https://lists.gnu.org/archive/html/guix-devel/2023-05/msg00192.html
On Wed, May 17, 2023 at 6:14=E2=80=AFPM Felix Lechner
<felix.lechner@HIDDEN> wrote:
>
> In a concession to Liliana's opposition, I retitled the bug to
> sidestep the question of the MAC-based names as a default setting.
It was not enough of a concession.
In Guix, many custom rules like the following=E2=80=94namely those that use
values determined by udevadm=E2=80=94are inoperable.
> (udev-rules-service 'net-name-mac
> (udev-rule
> "79-net-name-mac.rules"
> "
> SUBSYSTEM=3D=3D\"net\", ACTION=3D=3D\"add\", NAME=3D\"$env{ID_NET_NAME_MA=
C}\"
> ")))
The issue is that udevadm looks in the installation folder for udev
rules. In standard distros, that works fine because the installation
folder and the runtime folder are the same. Unfortunately, that is not
so for Guix. The installation folder is in the store.
The way I understand our strategy in Guix, we construct another,
aggregate folder with links to rules in /etc/udev/rules.d. (That
location also happens to be the installation directory for many
traditional distros.) I proposed a local patch that causes udevadm to
look in that folder instead. [2] It replaces one line in the source
code.
[2] https://issues.guix.gnu.org/63508#12
Liliana, who kindly reviewed my patch, disagreed with that solution.
For reasons I do not fully understand, she prefers a more generalized
solution via an environmental variable called EUDEV_RULES_DIRECTORY.
[3] As far as I can tell, that variable is not provided by upstream.
It was invented by a custom patch to Guix [4] and currently does not
seem to work all the way.
[3] https://issues.guix.gnu.org/63508#6
[4] https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/patches/=
eudev-rules-directory.patch
Liliana insists on improving the environment variable
EUDEV_RULES_DIRECTORY, while I have several issues with that. For
starters, my substitution is simpler. It is also a common packaging
strategy in Guix. (I furthermore cannot envision setting the variable
to any value other than /etc/udev/rules.d, although maybe the
flexibility comes in handy one day.) Mainly, however, I believe that
her patch goes beyond the typical packaging activity.
By implementing a new feature, the patch for EUDEV_RULES_DIRECTORY
should really be sent upstream. I do not know whether that's already
happened, but I am not convinced upstream would accept it.
In the latest 3.2.12 release, which does not work without further
modifications in Guix, the upstream developers added a command-line
option called '--root' to udevadm [5] that offers another solution to
setting the runtime path. Unfortunately, that option does not change
the default, which is the issue in this bug.
[5] https://github.com/eudev-project/eudev/blob/2703baf55615b7554fb67c4f1=
c241f057f8c0a79/man/udevadm.8#L378C2-L380
Finally, programming styles also differ. I have philosophical
objections to the use of pointer arithmetic, although the upstream
code may have some of that, too.
With the discussion at an impasse, I am not sure how to proceed.
Eudev, which is an essential part of any modern Linux operating
system, is not working properly in Guix.
Liliana challenged me to "file a formal complaint." [6] I do not know
what that means and now filed this bug in hope of finding an
acceptable way forward. Maybe it is easier to discuss the reasoning
for one fix or another when the arguments for and against are not
separated by multiple versions of competing inline patches.
[6] https://issues.guix.gnu.org/63508#22
For the success of any group, it is essential that problems are being
solved. Perhaps someone with an independent perspective would be so
kind to comment and help bring this bug one step closer to being
closed. Thanks!
Kind regards,
Felix
cc: Liliana
Felix Lechner <felix.lechner@HIDDEN>:bug-guix@HIDDEN.
Full text available.bug-guix@HIDDEN:bug#63787; Package guix.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.