GNU logs - #63787, boring messages

Message sent to bug-guix@HIDDEN:

Subject: bug#63787: udev-rules-service inoperable for some rules
Resent-From: Felix Lechner <felix.lechner@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Mon, 29 May 2023 15:27:01 +0000
Resent-Message-ID: <handler.63787.B.16853739689816 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 63787 <at> debbugs.gnu.org
Cc: Liliana Marie Prikler <liliana.prikler@HIDDEN>
MIME-Version: 1.0
From: Felix Lechner <felix.lechner@HIDDEN>
Date: Mon, 29 May 2023 08:25:11 -0700
Message-ID: <CAFHYt55059XYmkR_UFw0FjHg5iHcw8-=O=hxSjt9-hgLMgaxKg@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-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

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Felix Lechner <felix.lechner@HIDDEN>
Subject: bug#63787: Acknowledgement (udev-rules-service inoperable for
 some rules)
Message-ID: <handler.63787.B.16853739689816.ack <at> debbugs.gnu.org>
References: <CAFHYt55059XYmkR_UFw0FjHg5iHcw8-=O=hxSjt9-hgLMgaxKg@HIDDEN>
X-Gnu-PR-Message: ack 63787
X-Gnu-PR-Package: guix
Reply-To: 63787 <at> debbugs.gnu.org
Date: Mon, 29 May 2023 15:27:01 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-guix@HIDDEN

If you wish to submit further information on this problem, please
send it to 63787 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
63787: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D63787
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-guix@HIDDEN:

Subject: bug#63787: udev-rules-service inoperable for some rules
Resent-From: Liliana Marie Prikler <liliana.prikler@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guix@HIDDEN
Resent-Date: Mon, 29 May 2023 17:33:01 +0000
Resent-Message-ID: <handler.63787.B63787.168538154410115 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Felix Lechner <felix.lechner@HIDDEN>, 63787 <at> debbugs.gnu.org
Message-ID: <afc26db863444d1d148b6d043c8cfc86b98a4548.camel@HIDDEN>
From: Liliana Marie Prikler <liliana.prikler@HIDDEN>
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
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

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

Message received at control <at> debbugs.gnu.org:

Received: (at control) by debbugs.gnu.org; 17 Jun 2023 03:49:11 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 16 23:49:11 2023
Received: from localhost ([127.0.0.1]:50688 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qAMw2-0006Of-Sl
	for submit <at> debbugs.gnu.org; Fri, 16 Jun 2023 23:49:11 -0400
Received: from sail-ipv4.us-core.com ([208.82.101.137]:35986)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <felix.lechner@HIDDEN>) id 1qAMvy-0006O2-Cj
 for control <at> debbugs.gnu.org; Fri, 16 Jun 2023 23:49:08 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=2017; bh=rtMpWWUXp9PugYx
 tgxTzzFGzngFdw2rtNo3vCceGyVo=; h=to:subject:date:from;
 d=lease-up.com; 
 b=JK3IdRvBXufjfaykQ7gI8XRj/5JxAKVrBaDuTgLYWYmsM+eQEW0Oq8yr8MkFM3G0g/nG
 Gkl16ueEVz8ptByb4CdHpqh67VnkfUhZc1DqFFF+Kb725Bxj08jQMZcVQNij7A46eBaLyP
 qBFdKgdc/A5tMVVLvCfIYNdsIqqH15/fk=
Received: by sail-ipv4.us-core.com (OpenSMTPD) with ESMTPSA id c070a26c
 (TLSv1.3:TLS_CHACHA20_POLY1305_SHA256:256:NO)
 for <control <at> debbugs.gnu.org>; Sat, 17 Jun 2023 03:48:57 +0000 (UTC)
Received: by mail-lj1-f174.google.com with SMTP id
 38308e7fff4ca-2b448470602so20165861fa.2
 for <control <at> debbugs.gnu.org>; Fri, 16 Jun 2023 20:48:57 -0700 (PDT)
X-Gm-Message-State: AC+VfDye/PQGkoLn7o1TwoUnTjVaVkILWnkeWtRDBi3qj0doSE7nNbDz
 BYmMRTncTU0+koFN+pT9FzlNCqve5x0CWLLFuF4=
X-Google-Smtp-Source: ACHHUZ4qs1FnQpE3uM5Tk8r5COSGA+SEEoCQbAUljZ/mZmjTPnmPZush06KHBBznqH8papLR6PcTpjBtDOqJCR7hJIE=
X-Received: by 2002:a2e:9799:0:b0:2b3:4cff:60c6 with SMTP id
 y25-20020a2e9799000000b002b34cff60c6mr3213984lji.1.1686973735219; Fri, 16 Jun
 2023 20:48:55 -0700 (PDT)
MIME-Version: 1.0
From: Felix Lechner <felix.lechner@HIDDEN>
Date: Fri, 16 Jun 2023 20:48:18 -0700
X-Gmail-Original-Message-ID: <CAFHYt55vHeP=bKmuoiNn6FQ+KZfithy9ONMket_wpJ5esGUEwg@HIDDEN>
Message-ID: <CAFHYt55vHeP=bKmuoiNn6FQ+KZfithy9ONMket_wpJ5esGUEwg@HIDDEN>
Subject: 
To: control <at> debbugs.gnu.org
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: 2.0 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  severity 63787 important thanks 
 Content analysis details:   (2.0 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 -0.0 SPF_PASS               SPF: sender matches SPF record
 2.0 BLANK_SUBJECT          Subject is present but empty
X-Debbugs-Envelope-To: control
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 (+)

severity 63787 important
thanks

Last modified: Sat, 17 Jun 2023 04:00:02 UTC

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