From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms9.migadu.com with LMTPS id yEQ9H+fhdGRJZgAASxT56A (envelope-from ) for ; Mon, 29 May 2023 19:33:27 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id 4CQYH+fhdGQLUQAA9RJhRA (envelope-from ) for ; Mon, 29 May 2023 19:33:27 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 1FC8DA375 for ; Mon, 29 May 2023 19:33:27 +0200 (CEST) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q3gjw-0007rJ-JZ; Mon, 29 May 2023 13:33:04 -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 1q3gjv-0007ou-1j for bug-guix@gnu.org; Mon, 29 May 2023 13:33:03 -0400 Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1q3gjt-0003ed-Px for bug-guix@gnu.org; Mon, 29 May 2023 13:33:01 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1q3gjt-0002e8-Ln for bug-guix@gnu.org; Mon, 29 May 2023 13:33:01 -0400 X-Loop: help-debbugs@gnu.org Subject: bug#63787: udev-rules-service inoperable for some rules Resent-From: Liliana Marie Prikler Original-Sender: "Debbugs-submit" Resent-CC: bug-guix@gnu.org Resent-Date: Mon, 29 May 2023 17:33:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63787 X-GNU-PR-Package: guix X-GNU-PR-Keywords: To: Felix Lechner , 63787@debbugs.gnu.org Received: via spool by 63787-submit@debbugs.gnu.org id=B63787.168538154410115 (code B ref 63787); Mon, 29 May 2023 17:33:01 +0000 Received: (at 63787) by debbugs.gnu.org; 29 May 2023 17:32:24 +0000 Received: from localhost ([127.0.0.1]:59099 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q3gjH-0002d3-Ct for submit@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 ) id 1q3gjE-0002cp-Qp for 63787@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@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: From: Liliana Marie Prikler Date: Mon, 29 May 2023 19:32:13 +0200 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4 MIME-Version: 1.0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-guix@gnu.org List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+larch=yhetil.org@gnu.org Sender: bug-guix-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN ARC-Seal: i=1; s=key1; d=yhetil.org; t=1685381607; a=rsa-sha256; cv=none; b=pGYYv+V6dZiKm1KvG6XIWpD8HPvbvBCjf0kT9WjM7aiw88WAbBu2fdSvumafEFz4BCuf6w Yx9PYnR0ly9IMgzLBU+Y7Ghl+xdlfeRtBw0YBuHjWZbLmJ68F+/YwmRXMYq0g40K82KejR 5/WoAs5vl7vqIWO+4hXjTxVXLKd0ag0+hQOSYKM4JN5rMoGdBBvpx/nbW8bFi5rLJXO1r/ CfzTefdG0+Fg5KMbqPnP93UwHzVJiMN6YQPU4Hsdbg+Xs2GfdD5xvGZ60/pKNdQp86/YD1 yRV/d1AAAoLjz1gGlivpirRZ02f2QjkKGj6Lfp+rSYWSKjXjTPdRPkH1VJSHZQ== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20221208 header.b=FQY3V1M+; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of "bug-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="bug-guix-bounces+larch=yhetil.org@gnu.org" ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1685381607; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding:resent-cc: resent-from:resent-sender:resent-message-id:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=FmgKcWnjvrh6OJvXvqRH+nqzhGGoyt0vW5tYHWnsNCc=; b=RDYcUgCCSTzk4pP2zqruWQRDYYHLRe1xBRrDeGIxQErK4xNdtj7G7oAeyr5uSCU0FLyClb q3/n2u1ElblBnN3uZ9vChGKZ0bgnKNRYp2/nxfc6GNsW7dt2s2HPtd4emLLzGQPRs1WzPU hIHehSLUApAEcr5DUmp6J1E9Np4wE2+bE4h4IUG1fOlhxluOZHKUP8HY4/+OGfmTAjmBeV 0ZsmM61q7cebJ+ymhOkvD8REA35IoywvEnN0XO5maHf0shRxqRAO9aFVojSc7WgbCJs97d sKK7JZIT1jcBQU8RjEEift45cgN+AE2IRDHo2/ndAHbdw8g16JUjZkQ+1Ariag== X-Migadu-Spam-Score: -2.84 X-Spam-Score: -2.84 X-Migadu-Queue-Id: 1FC8DA375 X-Migadu-Scanner: scn0.migadu.com Authentication-Results: aspmx1.migadu.com; dkim=fail ("headers rsa verify failed") header.d=gmail.com header.s=20221208 header.b=FQY3V1M+; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=none); spf=pass (aspmx1.migadu.com: domain of "bug-guix-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="bug-guix-bounces+larch=yhetil.org@gnu.org" X-TUID: BD7Gv00YJ/lP 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 > 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