How to handle package udev rules?

How to handle package udev rules?

[Alexander Asteroth]

Dear all,

I'm trying to build my first guix package and so far, after a lot of
trial and error to find the right packages providing the necessary cmake
functionality I managed to get the package to compile. (up to the point
where the install script want's to copy some udev rules file) 

The package is a linux software that can be used with logitech
presenters [0]. Therefore it needs udev rules/devices to communicate
with the device.

The question now is, what is the correct guix-way to implement this:

I tried to import the libgudev module but that that only results in the
package wanting to write to another write-protected directory from the
store.

As I understand, the udev-rules are usually created on system
level. That would mean I need to split the package into a service part
and a package part? And remove the installation of the udev-file from
the package install process?

Or is there another way for a package to provide the udev rules from a
user-level install? 

Cheers,
        Alex

-----

[0] https://github.com/jahnf/Projecteur

How to handle package udev rules?

[Γυψ]

Sorry, I sent this email from a non-subscribed account and therefore it
probably wasn't sent (if you receive it twice sorry for that).

Dear all,

I'm trying to build my first guix package and so far, after a lot of
trial and error to find the right packages providing the necessary cmake
functionality I managed to get the package to compile. (up to the point
where the install script want's to copy some udev rules file) 

The package is a linux software that can be used with logitech
presenters [0]. Therefore it needs udev rules/devices to communicate
with the device.

The question now is, what is the correct guix-way to implement this:

I tried to import the libgudev module but that that only results in the
package wanting to write to another write-protected directory from the
store.

As I understand, the udev-rules are usually created on system
level. That would mean I need to split the package into a service part
and a package part? And remove the installation of the udev-file from
the package install process?

Or is there another way for a package to provide the udev rules from a
user-level install? 

Cheers,
        Alex

-----

[0] https://github.com/jahnf/Projecteur

Re: How to handle package udev rules?

[Tobias Geerinckx-Rice]

[-- Attachment #1: Type: text/plain, Size: 1334 bytes --]

Alexander,

Alexander Asteroth 写道：
> The question now is, what is the correct guix-way to implement 
> this:

Not as complicated as you fear!

udev rules aren't special.  Just install them to the package's own 
<out>/lib/udev/rules.d directory.  If the build system tries to 
write to another package's output, see if it provides any options 
to change that, or patch it in the worst case.

> As I understand, the udev-rules are usually created on system
> level. That would mean I need to split the package into a 
> service part
> and a package part? And remove the installation of the udev-file 
> from
> the package install process?

Guix System provides a ready-made udev-rules-service to gather up 
all desired udev rules and pass them to the running udev.  I think 
this is how it works:

  (operating-system
    […]
    (services
      (cons* […]
             (udev-rules-service 'projecteur
                                 projecteur)
             %base-services)))

‘Think’ because I do it differently in my own configurations.

> Or is there another way for a package to provide the udev rules 
> from a
> user-level install? 

If this means ‘can I use Guix's udev rules on a foreign 
distribution’: I'm not sure, but not out of the box.

Kind regards,

T G-R

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 247 bytes --]

Re: How to handle package udev rules?

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 3478 bytes --]

Hello Alexander,

On Sun, 12 Dec 2021 13:12:50 +0100
Alexander Asteroth <alexander.asteroth@h-brs.de> wrote:

> I tried to import the libgudev module but that that only results in the
> package wanting to write to another write-protected directory from the
> store.

It's supposed to write those to $output/lib/udev/rules.d (s.t. there's
*.rules inside) instead.   There's usually a cmake variable to make it do
that--but you need to look at the CMakeLists.txt in question.

Guix will pick those up if they originate in something it can see and add
those to Guix's udev service automatically (via the service extension mechanism,
which allows you to extend service config from outside the udev service).

Are you using Guix as an operating system? Or on top of another distribution?

> As I understand, the udev-rules are usually created on system level.

Yes.

> That would mean I need to split the package into a service part
> and a package part? And remove the installation of the udev-file from
> the package install process?

Kinda not really--at least not exactly.  See below.

Example I'm using (that one definitely works--but I only add the custom
package because the upstream package doesn't do it![1]):

/etc/config.scm :

(define my-ledger-nano
  (package
    (name "my-ledger-nano")
    (version "1")
    (source #f)
    (build-system trivial-build-system)
    (synopsis "")
    (description "")
    (license #f)
    (home-page #f)
    (arguments
     `(#:builder
       (begin
         (mkdir %output)
         (mkdir (string-append %output "/lib"))
         (mkdir (string-append %output "/lib/udev"))
         (mkdir (string-append %output "/lib/udev/rules.d"))
         (call-with-output-file (string-append %output "/lib/udev/rules.d/99-my-ledger-nano.rules")
           (lambda (port)
             (format port
"SUBSYSTEM==\"usb\", ATTRS{idVendor}==\"2c97\", MODE=\"0600\", OWNER=\"dannym\", TAG+=\"uaccess\", TAG+=\"udev-acl\"
KERNEL==\"hidraw*\", ATTRS{idVendor}==\"2c97\", MODE=\"0600\", OWNER=\"dannym\", SYMLINK+=\"ledger_%n\", TAG+=\"uaccess\", TAG+=\"udev-acl\"
")))
         #t)))))

(operating-system
  ...
  (services
            (simple-service 'custom-udev-rules udev-service-type (list sane-backends my-ledger-nano)))

You can add your package reference there and it will work.

Or you can try adding your package reference into
  (operating-system (packages (list ...)))--should be enough.

If you mean adding your package's udev rules to the operating system
configuration without being the "root" user in-between: no, that would be a
(very bad! those rules run as root!) security problem.

In the case of your package, it seems[0] that they calculate the directory to
store the udev rules to from pkg-config--which will result in the udev
package's install directory. That won't work.

But in line 214 in [0] they seem to allow you to override it anyway.
So you can try to call cmake with

  -DCMAKE_INSTALL_UDEVRULESDIR=$output//lib/udev/rules.d

like this (in your package definition):

(package
  ...
  (arguments
 '(#:configure-flags (list (string-append "-DCMAKE_INSTALL_UDEVRULESDIR="
                                          (assoc-ref %outputs "out")
                                          "/lib/udev/rules.d"))))

[0] https://github.com/jahnf/Projecteur/blob/develop/CMakeLists.txt#L231
[1] https://github.com/LedgerHQ/udev-rules/pull/8

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: How to handle package udev rules?

[gyps]

Dear Danny, dear Tobias,

thanks for the hints which immediately solved my issue.
It now compiles and everyting is fine but one thing.

If I change my operating-system config to inlcude udev-rules from
package "projecteur" everything works fine - at least if I do it as a
regular user. As soon as I sudo the guix system reconfigure command the
package is known but it's code is not. Error message is:

> $ sudo guix system reconfigure ~/etc/config.scm
> ice-9/boot-9.scm:3329:6: In procedure resolve-interface:
> no code for module (projecteur)

Could it be the case that sudo'ed the variable GUIX_PACKAGE_PATH is not
known or not interpreted correctly? Does the package need to reside
somewhere else than in GUIX_PACKAGE_PATH?

Cheers,

Alex

On Sun, Dec 12 2021, 19:17:26, Danny Milosavljevic <dannym@scratchpost.org> wrote:

> [[PGP Signed Part:Undecided]]
> Hello Alexander,
>
> On Sun, 12 Dec 2021 13:12:50 +0100
> Alexander Asteroth <alexander.asteroth@h-brs.de> wrote:
>
>> I tried to import the libgudev module but that that only results in the
>> package wanting to write to another write-protected directory from the
>> store.
>
> It's supposed to write those to $output/lib/udev/rules.d (s.t. there's
> *.rules inside) instead.   There's usually a cmake variable to make it do
> that--but you need to look at the CMakeLists.txt in question.
>
> Guix will pick those up if they originate in something it can see and add
> those to Guix's udev service automatically (via the service extension mechanism,
> which allows you to extend service config from outside the udev service).
>
> Are you using Guix as an operating system? Or on top of another distribution?
>
>> As I understand, the udev-rules are usually created on system level.
>
> Yes.
>
>> That would mean I need to split the package into a service part
>> and a package part? And remove the installation of the udev-file from
>> the package install process?
>
> Kinda not really--at least not exactly.  See below.
>
> Example I'm using (that one definitely works--but I only add the custom
> package because the upstream package doesn't do it![1]):
>
> /etc/config.scm :
>
> (define my-ledger-nano
>   (package
>     (name "my-ledger-nano")
>     (version "1")
>     (source #f)
>     (build-system trivial-build-system)
>     (synopsis "")
>     (description "")
>     (license #f)
>     (home-page #f)
>     (arguments
>      `(#:builder
>        (begin
>          (mkdir %output)
>          (mkdir (string-append %output "/lib"))
>          (mkdir (string-append %output "/lib/udev"))
>          (mkdir (string-append %output "/lib/udev/rules.d"))
>          (call-with-output-file (string-append %output "/lib/udev/rules.d/99-my-ledger-nano.rules")
>            (lambda (port)
>              (format port
> "SUBSYSTEM==\"usb\", ATTRS{idVendor}==\"2c97\", MODE=\"0600\", OWNER=\"dannym\", TAG+=\"uaccess\", TAG+=\"udev-acl\"
> KERNEL==\"hidraw*\", ATTRS{idVendor}==\"2c97\", MODE=\"0600\", OWNER=\"dannym\", SYMLINK+=\"ledger_%n\", TAG+=\"uaccess\", TAG+=\"udev-acl\"
> ")))
>          #t)))))
>
> (operating-system
>   ...
>   (services
>             (simple-service 'custom-udev-rules udev-service-type (list sane-backends my-ledger-nano)))
>
> You can add your package reference there and it will work.
>
> Or you can try adding your package reference into
>   (operating-system (packages (list ...)))--should be enough.
>
> If you mean adding your package's udev rules to the operating system
> configuration without being the "root" user in-between: no, that would be a
> (very bad! those rules run as root!) security problem.
>
> In the case of your package, it seems[0] that they calculate the directory to
> store the udev rules to from pkg-config--which will result in the udev
> package's install directory. That won't work.
>
> But in line 214 in [0] they seem to allow you to override it anyway.
> So you can try to call cmake with
>
>   -DCMAKE_INSTALL_UDEVRULESDIR=$output//lib/udev/rules.d
>
> like this (in your package definition):
>
> (package
>   ...
>   (arguments
>  '(#:configure-flags (list (string-append "-DCMAKE_INSTALL_UDEVRULESDIR="
>                                           (assoc-ref %outputs "out")
>                                           "/lib/udev/rules.d"))))
>
> [0] https://github.com/jahnf/Projecteur/blob/develop/CMakeLists.txt#L231
> [1] https://github.com/LedgerHQ/udev-rules/pull/8
>
> [[End of PGP Signed Part]]

Re: How to handle package udev rules?

[Danny Milosavljevic]

[-- Attachment #1: Type: text/plain, Size: 853 bytes --]

Hi,

On Sun, 12 Dec 2021 21:58:14 +0100
gyps@member.fsf.org wrote:

> If I change my operating-system config to inlcude udev-rules from
> package "projecteur" everything works fine - at least if I do it as a
> regular user. As soon as I sudo the guix system reconfigure command the
> package is known but it's code is not. Error message is:
> 
> > $ sudo guix system reconfigure ~/etc/config.scm
> > ice-9/boot-9.scm:3329:6: In procedure resolve-interface:
> > no code for module (projecteur)  
> 
> Could it be the case that sudo'ed the variable GUIX_PACKAGE_PATH is not
> known or not interpreted correctly? Does the package need to reside
> somewhere else than in GUIX_PACKAGE_PATH?

Yeah, sudo is very paranoid. You need to pass -E GUIX_PACKAGE_PATH to it:

   sudo -E GUIX_PACKAGE_PATH guix system reconfigure ~/etc/config.scm

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: How to handle package udev rules?

[Γυψ]

[-- Attachment #1: Type: text/plain, Size: 1498 bytes --]

Dear Danny,

thanks! That lead me on the right track. In fact it's just

> sudo -E guix ...

without the Varibale name. "-E" passes the whole environment to
sudo. Now the package works (at least on my system) and the Logitech
presenter can be used under EXWM+xcompmgr under guix-system - Great! I
would be willing to provide the package description and maintain it if
that's helpful. Have to find out about the necessary steps then...

Cheers,
Alex

On Sun, Dec 12 2021, 23:37:06, Danny Milosavljevic <dannym@scratchpost.org> wrote:

> [[PGP Signed Part:Undecided]]
> Hi,
>
> On Sun, 12 Dec 2021 21:58:14 +0100
> gyps@member.fsf.org wrote:
>
>> If I change my operating-system config to inlcude udev-rules from
>> package "projecteur" everything works fine - at least if I do it as a
>> regular user. As soon as I sudo the guix system reconfigure command the
>> package is known but it's code is not. Error message is:
>> 
>> > $ sudo guix system reconfigure ~/etc/config.scm
>> > ice-9/boot-9.scm:3329:6: In procedure resolve-interface:
>> > no code for module (projecteur)  
>> 
>> Could it be the case that sudo'ed the variable GUIX_PACKAGE_PATH is not
>> known or not interpreted correctly? Does the package need to reside
>> somewhere else than in GUIX_PACKAGE_PATH?
>
> Yeah, sudo is very paranoid. You need to pass -E GUIX_PACKAGE_PATH to it:
>
>    sudo -E GUIX_PACKAGE_PATH guix system reconfigure ~/etc/config.scm
>
> [[End of PGP Signed Part]]


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 515 bytes --]

Re: How to handle package udev rules?

[Alexander Asteroth]

[-- Attachment #1: Type: text/plain, Size: 2239 bytes --]

Now that the package is working and after I read the guidelines for
contributing a package description I was wondering one thing:

guix is not only guix system but also running as a packet manager on
other distros. But a package developed for guix system, has to handle
files like udev rule files differently from other FSH based
distributions. Therefore a package using e.g. udev rules will never work
without additional steps on other distributions.

What is the policy here? How do other guix packages deal with that?

Cheers,

Alex


On Mon, Dec 13 2021, 09:48:53, Γυψ <gyps@member.fsf.org> wrote:

> [[PGP Signed Part:Undecided]]
> Dear Danny,
>
> thanks! That lead me on the right track. In fact it's just
>
>> sudo -E guix ...
>
> without the Varibale name. "-E" passes the whole environment to
> sudo. Now the package works (at least on my system) and the Logitech
> presenter can be used under EXWM+xcompmgr under guix-system - Great! I
> would be willing to provide the package description and maintain it if
> that's helpful. Have to find out about the necessary steps then...
>
> Cheers,
> Alex
>
> On Sun, Dec 12 2021, 23:37:06, Danny Milosavljevic <dannym@scratchpost.org> wrote:
>
>> [[PGP Signed Part:Undecided]]
>> Hi,
>>
>> On Sun, 12 Dec 2021 21:58:14 +0100
>> gyps@member.fsf.org wrote:
>>
>>> If I change my operating-system config to inlcude udev-rules from
>>> package "projecteur" everything works fine - at least if I do it as a
>>> regular user. As soon as I sudo the guix system reconfigure command the
>>> package is known but it's code is not. Error message is:
>>> 
>>> > $ sudo guix system reconfigure ~/etc/config.scm
>>> > ice-9/boot-9.scm:3329:6: In procedure resolve-interface:
>>> > no code for module (projecteur)  
>>> 
>>> Could it be the case that sudo'ed the variable GUIX_PACKAGE_PATH is not
>>> known or not interpreted correctly? Does the package need to reside
>>> somewhere else than in GUIX_PACKAGE_PATH?
>>
>> Yeah, sudo is very paranoid. You need to pass -E GUIX_PACKAGE_PATH to it:
>>
>>    sudo -E GUIX_PACKAGE_PATH guix system reconfigure ~/etc/config.scm
>>
>> [[End of PGP Signed Part]]
>
> [[End of PGP Signed Part]]


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 524 bytes --]

Re: How to handle package udev rules?

[Josselin Poiret via Development of GNU Guix and the GNU System distribution.]

Hello,

Alexander Asteroth <alexander.asteroth@h-brs.de> writes:

> Now that the package is working and after I read the guidelines for
> contributing a package description I was wondering one thing:
>
> guix is not only guix system but also running as a packet manager on
> other distros. But a package developed for guix system, has to handle
> files like udev rule files differently from other FSH based
> distributions. Therefore a package using e.g. udev rules will never work
> without additional steps on other distributions.
>
> What is the policy here? How do other guix packages deal with that?

To maintain isolation and compatibility, Guix on a foreign distribution
doesn't want to mess with how the other distro operates, and so it won't
touch the FHS in any way, except for its own files in /var/guix/.  It
should theoretically be possible to move the udev rules manually to the
udev rules folder, but that means that those files will not be managed
by either Guix or the foreign package manager!

In any case, on a foreign distro, you shouldn't use Guix for anything
system-related, as that would be the responsibility of the running
distribution.

Best,
Josselin Poiret

Re: How to handle package udev rules?

[SeerLite]

On 12/13/21 04:48, Γυψ wrote:
> Dear Danny,
> 
> thanks! That lead me on the right track. In fact it's just
> 
>> sudo -E guix ...

Hi!
I recommend avoiding the use of sudo -E, as it will make guix system use 
your non-root user's $HOME/.cache to write its compiled files, which 
might become a problem in the future. I myself had an issue because of 
this where all of ~/.cache/guile was owned by root, meaning my user was 
unable to write to it.

Just to make sure, try running

     find ~ -user root

to see if you've got any root-owned files in your $HOME.

I think the right command in your case is

     sudo --preserve-env=GUIX_PACKAGE_PATH guix system reconfigure 
/etc/config.scm

Replying bit late, but I hope it's useful. I see sudo -E recommended a 
lot yet it always causes issues on my end, so I'm against it.

SeerLite