Microscheme failed

Microscheme failed

[Daniel Pimentel]

Hi Guix,

I try compile to Arduino plataform using Microscheme (installed with: 
guix package -i microscheme) on GuixSD, but there are errors.

I did:
sudo microscheme -m UNO -d /dev/ttyACM0 -au lightom.ms

Errors:
...
>> 32 lines compiled OK
>> Assembling...
avr-ld: cannot find crtatmega328p.o: No such file or directory
...
avrdude: Device signature = 0x1e950f
avrdude: reading input file "lightom.hex"
avrdude: can't open input file lightom.hex: No such file or directory
avrdude: read from file 'lightom.hex' failed

I have avr-gcc avr-libc avrdude avr-binutils avr-toolchain installed.

Thanks,

-- 
Daniel Pimentel (aka d4n1)

Re: Microscheme failed

[Ricardo Wurmus]

Hi Daniel,

> I try compile to Arduino plataform using Microscheme (installed with: 
> guix package -i microscheme) on GuixSD, but there are errors.
>
> I did:
> sudo microscheme -m UNO -d /dev/ttyACM0 -au lightom.ms

This is unrelated but I recommend not using “sudo” here.  You can add a
udev rule to your system configuration to change the ownership of
/dev/ttyACM0.

For my AVR programmers I have this in my system configuration:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(define avrispmkii-udev-rule
  (udev-rule "90-avrispmkii.rules"
             "\
SUBSYSTEM!=\"usb\", ACTION!=\"add\", GOTO=\"avrisp_end\"

# Atmel Corp. JTAG ICE mkII
ATTR{idVendor}==\"03eb\", ATTR{idProduct}==\"2103\", MODE=\"660\", GROUP=\"dialout\"
# Atmel Corp. AVRISP mkII
ATTR{idVendor}==\"03eb\", ATTR{idProduct}==\"2104\", MODE=\"660\", GROUP=\"dialout\"
# Atmel Corp. Dragon
ATTR{idVendor}==\"03eb\", ATTR{idProduct}==\"2107\", MODE=\"660\", GROUP=\"dialout\"

LABEL=\"avrisp_end\"\n"))

(operating-system
  …
  (services (cons* (modify-services %desktop-services
                     (udev-service-type config =>
                                        (udev-configuration
                                         (inherit config)
                                         (rules (append (udev-configuration-rules config)
                                                        (list avrispmkii-udev-rule))))))))
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

> Errors:
> ...
>>> 32 lines compiled OK
>>> Assembling...
> avr-ld: cannot find crtatmega328p.o: No such file or directory

This is a bug in our AVR toolchain.  The internal search path for these
files appears to be wrong.  What I did was copy the “crt*.o” file I
needed to my working directory.  Maybe you can send an email to
bug-guix@gnu.org to report this as a bug?

> I have avr-gcc avr-libc avrdude avr-binutils avr-toolchain installed.

You only need “avr-toolchain” as it contains all the other packages.

~~ Ricardo

Re: Microscheme failed

[Ludovic Courtès]

Hello!

Ricardo Wurmus <rekado@elephly.net> skribis:

> For my AVR programmers I have this in my system configuration:
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> (define avrispmkii-udev-rule
>   (udev-rule "90-avrispmkii.rules"
>              "\
> SUBSYSTEM!=\"usb\", ACTION!=\"add\", GOTO=\"avrisp_end\"
>
> # Atmel Corp. JTAG ICE mkII
> ATTR{idVendor}==\"03eb\", ATTR{idProduct}==\"2103\", MODE=\"660\", GROUP=\"dialout\"
> # Atmel Corp. AVRISP mkII
> ATTR{idVendor}==\"03eb\", ATTR{idProduct}==\"2104\", MODE=\"660\", GROUP=\"dialout\"
> # Atmel Corp. Dragon
> ATTR{idVendor}==\"03eb\", ATTR{idProduct}==\"2107\", MODE=\"660\", GROUP=\"dialout\"
>
> LABEL=\"avrisp_end\"\n"))
>
> (operating-system
>   …
>   (services (cons* (modify-services %desktop-services
>                      (udev-service-type config =>
>                                         (udev-configuration
>                                          (inherit config)
>                                          (rules (append (udev-configuration-rules config)
>                                                         (list avrispmkii-udev-rule))))))))
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Should we add this as an optional service or to the default set of udev
rules?

Ludo’.

Re: Microscheme failed

[Daniel Pimentel]

Thank you Ricardo for help me.

> For my AVR programmers I have this in my system configuration:
> 
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> (define avrispmkii-udev-rule
>   (udev-rule "90-avrispmkii.rules"
>              "\
> SUBSYSTEM!=\"usb\", ACTION!=\"add\", GOTO=\"avrisp_end\"
> 
> # Atmel Corp. JTAG ICE mkII
> ATTR{idVendor}==\"03eb\", ATTR{idProduct}==\"2103\", MODE=\"660\",
> GROUP=\"dialout\"
> # Atmel Corp. AVRISP mkII
> ATTR{idVendor}==\"03eb\", ATTR{idProduct}==\"2104\", MODE=\"660\",
> GROUP=\"dialout\"
> # Atmel Corp. Dragon
> ATTR{idVendor}==\"03eb\", ATTR{idProduct}==\"2107\", MODE=\"660\",
> GROUP=\"dialout\"
> 
> LABEL=\"avrisp_end\"\n"))
> 
> (operating-system
>   …
>   (services (cons* (modify-services %desktop-services
>                      (udev-service-type config =>
>                                         (udev-configuration
>                                          (inherit config)
>                                          (rules (append
> (udev-configuration-rules config)
>                                                         (list
> avrispmkii-udev-rule))))))))
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I'll try this configuration.

> This is a bug in our AVR toolchain.  The internal search path for these
> files appears to be wrong.  What I did was copy the “crt*.o” file I
> needed to my working directory.  Maybe you can send an email to
> bug-guix@gnu.org to report this as a bug?
> 
>> I have avr-gcc avr-libc avrdude avr-binutils avr-toolchain installed.
> 
> You only need “avr-toolchain” as it contains all the other packages.

I'll report in bug-guix.

Thanks,

-- 
Daniel Pimentel (aka d4n1)

udev rules and system configuration (was: Microscheme failed)

[Ricardo Wurmus]

Ludovic Courtès <ludo@gnu.org> writes:

> Hello!
>
> Ricardo Wurmus <rekado@elephly.net> skribis:
>
>> For my AVR programmers I have this in my system configuration:
>>
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> (define avrispmkii-udev-rule
>>   (udev-rule "90-avrispmkii.rules"
>>              "\
>> SUBSYSTEM!=\"usb\", ACTION!=\"add\", GOTO=\"avrisp_end\"
>>
>> # Atmel Corp. JTAG ICE mkII
>> ATTR{idVendor}==\"03eb\", ATTR{idProduct}==\"2103\", MODE=\"660\", GROUP=\"dialout\"
>> # Atmel Corp. AVRISP mkII
>> ATTR{idVendor}==\"03eb\", ATTR{idProduct}==\"2104\", MODE=\"660\", GROUP=\"dialout\"
>> # Atmel Corp. Dragon
>> ATTR{idVendor}==\"03eb\", ATTR{idProduct}==\"2107\", MODE=\"660\", GROUP=\"dialout\"
>>
>> LABEL=\"avrisp_end\"\n"))
>>
>> (operating-system
>>   …
>>   (services (cons* (modify-services %desktop-services
>>                      (udev-service-type config =>
>>                                         (udev-configuration
>>                                          (inherit config)
>>                                          (rules (append (udev-configuration-rules config)
>>                                                         (list avrispmkii-udev-rule))))))))
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> Should we add this as an optional service or to the default set of udev
> rules?

I don’t think this should be the default.  This rule is only useful for
those who own one of Atmel’s USB programmer devices.  There is a
multitude of programmers for AVRs and users may want to use different
rules for different devices.

However, I’ve been wondering if we shouldn’t introduce nicer
abstractions for udev rules and make loading them a little less verbose.
It’s a bit unfortunate that while on other systems users are often told
to just dump a file somewhere in “/etc” to make device access work
without root on GuixSD it’s quite a bit more involved to achieve the
same.

Our documentation is also a little lacking in this respect.  The manual
has very little to say about the “udev-service” and how to extend it (or
any of the other services, really), making it hard for users coming from
other systems to find where they need to change something to make the
udev rules work that they were told to add somewhere.

Here’s an idea, which might be bad: how about adding a feature to load
and merge a directory tree of configuration files as they are?  For
example, if I had a directory “/etc/guix/system/udev/rules.d” then all
files therein would automatically be considered part of the system
configuration, maybe after adding “/etc/guix/system” as a prefix path to
some new field in the “operating-system” declaration.

I have a feeling that this will be considered a bad idea, but it also
seems to me that it would make the configuration of some parts of the
system easier than embedding file contents as strings in variables in
“/etc/config.scm” and modifying services manually.

~~ Ricardo

Re: udev rules and system configuration

[Ludovic Courtès]

Ricardo Wurmus <rekado@elephly.net> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Hello!
>>
>> Ricardo Wurmus <rekado@elephly.net> skribis:
>>
>>> For my AVR programmers I have this in my system configuration:
>>>
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>> (define avrispmkii-udev-rule
>>>   (udev-rule "90-avrispmkii.rules"
>>>              "\
>>> SUBSYSTEM!=\"usb\", ACTION!=\"add\", GOTO=\"avrisp_end\"
>>>
>>> # Atmel Corp. JTAG ICE mkII
>>> ATTR{idVendor}==\"03eb\", ATTR{idProduct}==\"2103\", MODE=\"660\", GROUP=\"dialout\"
>>> # Atmel Corp. AVRISP mkII
>>> ATTR{idVendor}==\"03eb\", ATTR{idProduct}==\"2104\", MODE=\"660\", GROUP=\"dialout\"
>>> # Atmel Corp. Dragon
>>> ATTR{idVendor}==\"03eb\", ATTR{idProduct}==\"2107\", MODE=\"660\", GROUP=\"dialout\"
>>>
>>> LABEL=\"avrisp_end\"\n"))
>>>
>>> (operating-system
>>>   …
>>>   (services (cons* (modify-services %desktop-services
>>>                      (udev-service-type config =>
>>>                                         (udev-configuration
>>>                                          (inherit config)
>>>                                          (rules (append (udev-configuration-rules config)
>>>                                                         (list avrispmkii-udev-rule))))))))
>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>
>> Should we add this as an optional service or to the default set of udev
>> rules?
>
> I don’t think this should be the default.  This rule is only useful for
> those who own one of Atmel’s USB programmer devices.  There is a
> multitude of programmers for AVRs and users may want to use different
> rules for different devices.
>
> However, I’ve been wondering if we shouldn’t introduce nicer
> abstractions for udev rules and make loading them a little less verbose.
> It’s a bit unfortunate that while on other systems users are often told
> to just dump a file somewhere in “/etc” to make device access work
> without root on GuixSD it’s quite a bit more involved to achieve the
> same.

Yeah, it doesn’t support the quick-hack style of doing things, which can
be frustrating.

> Our documentation is also a little lacking in this respect.  The manual
> has very little to say about the “udev-service” and how to extend it (or
> any of the other services, really), making it hard for users coming from
> other systems to find where they need to change something to make the
> udev rules work that they were told to add somewhere.

Yeah.

> Here’s an idea, which might be bad: how about adding a feature to load
> and merge a directory tree of configuration files as they are?  For
> example, if I had a directory “/etc/guix/system/udev/rules.d” then all
> files therein would automatically be considered part of the system
> configuration, maybe after adding “/etc/guix/system” as a prefix path to
> some new field in the “operating-system” declaration.
>
> I have a feeling that this will be considered a bad idea, but it also
> seems to me that it would make the configuration of some parts of the
> system easier than embedding file contents as strings in variables in
> “/etc/config.scm” and modifying services manually.

It’s a bad idea!  :-)

Seriously, I think having a directory that is automatically picked up is
a bad idea in the sense that it would defeat one of the main goals of
GuixSD, which is to support reproducibility.  The hypothetical
/etc/guix/udev directory would not be controlled by GuixSD, so rolling
back wouldn’t be enough to return to the previous state, copying the
GuixSD config file wouldn’t be enough to duplicate the system state on
another machine, and so on.

However, what we can do is improve the interface.  Things that come to
mind:

  1. Change or remove the ‘udev-rule’ procedure; we should be using
     file-like objects instead, so one could store them alongside
     config.scm and write:

       (local-file "./my-udev-rule")

  2. Add a ‘extra-udev-rule’ procedure that you could use like this:

       (operating-system
         ;; …
         (services (extra-udev-rule (local-file "./my-udev-rule"))
                   …))

     thus avoiding the verbose ‘modify-services’ stanza.

  3. (Instead of #2) Introduce a ‘udev-rules’ field in
     ‘operating-system’, just like we do for firmware.

WDYT?

I don’t deny that this is still more heavyweight than dropping a file in
/etc.  We should think about other ways to improve on that (what would
be the equivalent of C-M-x for GuixSD?), but for now it’s the only way I
can think of to preserve reproducibility.

Ludo’.

Re: udev rules and system configuration

[Ricardo Wurmus]

Ludovic Courtès <ludo@gnu.org> writes:

> Ricardo Wurmus <rekado@elephly.net> skribis:

>> Here’s an idea, which might be bad: how about adding a feature to load
>> and merge a directory tree of configuration files as they are?  For
>> example, if I had a directory “/etc/guix/system/udev/rules.d” then all
>> files therein would automatically be considered part of the system
>> configuration, maybe after adding “/etc/guix/system” as a prefix path to
>> some new field in the “operating-system” declaration.
>>
>> I have a feeling that this will be considered a bad idea, but it also
>> seems to me that it would make the configuration of some parts of the
>> system easier than embedding file contents as strings in variables in
>> “/etc/config.scm” and modifying services manually.
>
> It’s a bad idea!  :-)
>
> Seriously, I think having a directory that is automatically picked up is
> a bad idea in the sense that it would defeat one of the main goals of
> GuixSD, which is to support reproducibility.  The hypothetical
> /etc/guix/udev directory would not be controlled by GuixSD, so rolling
> back wouldn’t be enough to return to the previous state, copying the
> GuixSD config file wouldn’t be enough to duplicate the system state on
> another machine, and so on.

These files are not loaded at system runtime but upon running “guix
system reconfigure”.  Their contents *at that time* would be embedded in
the configuration.  Their state *at runtime* would not matter (just like
the contents of “config.scm” don’t matter at runtime).

The files would become part of the configuration in the store.  Changing
them would always require the additional step of reconfiguring the
system.

> However, what we can do is improve the interface.  Things that come to
> mind:
>
>   1. Change or remove the ‘udev-rule’ procedure; we should be using
>      file-like objects instead, so one could store them alongside
>      config.scm and write:
>
>        (local-file "./my-udev-rule")

Is this really so different from the bad idea I proposed?  As soon as we
load files outside of “config.scm” users would need to copy more than
just the GuixSD config file to duplicate the system state on another
machine.  In this example we would need both “config.scm” and
“my-udev-rule” in the same directory.

The bad idea still requires a user to tell Guix to load udev rule files
from somewhere.  The difference is that instead of loading files
individually by name it would load *all* rules from the directory.

I guess it’s not very different form what you propose in #3, actually.

>   2. Add a ‘extra-udev-rule’ procedure that you could use like this:
>
>        (operating-system
>          ;; …
>          (services (extra-udev-rule (local-file "./my-udev-rule"))
>                    …))
>
>      thus avoiding the verbose ‘modify-services’ stanza.
>
>   3. (Instead of #2) Introduce a ‘udev-rules’ field in
>      ‘operating-system’, just like we do for firmware.
>
> WDYT?

I don’t know.  Although this would simplify configuration I don’t really
like either of them for somewhat conflicting reasons.  #3 gives special
treatment to udev rules (“What about Xorg config snippets?”), and with
#2 it seems like an unnecessary implementation detail that this
“extra-udev-rule” procedure is inside of the “services” field (“How come
this is a service?”).

I also feel that we should avoid adding “special” syntax.  Actually, I
really like how generic this whole “modify-services” business is.  It’s
just a little too verbose to be user-friendly, in my opinion.

~~ Ricardo

Re: udev rules and system configuration

[Ludovic Courtès]

Hello!

Ricardo Wurmus <rekado@elephly.net> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Ricardo Wurmus <rekado@elephly.net> skribis:
>
>>> Here’s an idea, which might be bad: how about adding a feature to load
>>> and merge a directory tree of configuration files as they are?  For
>>> example, if I had a directory “/etc/guix/system/udev/rules.d” then all
>>> files therein would automatically be considered part of the system
>>> configuration, maybe after adding “/etc/guix/system” as a prefix path to
>>> some new field in the “operating-system” declaration.
>>>
>>> I have a feeling that this will be considered a bad idea, but it also
>>> seems to me that it would make the configuration of some parts of the
>>> system easier than embedding file contents as strings in variables in
>>> “/etc/config.scm” and modifying services manually.

[...]

> These files are not loaded at system runtime but upon running “guix
> system reconfigure”.  Their contents *at that time* would be embedded in
> the configuration.  Their state *at runtime* would not matter (just like
> the contents of “config.scm” don’t matter at runtime).
>
> The files would become part of the configuration in the store.  Changing
> them would always require the additional step of reconfiguring the
> system.

OK, I had misunderstood your suggestion.  It doesn’t have the drawbacks
I mentioned.

However, I don’t like the idea of having special directories that are
automatically scanned.  In my mind, it’s a problem similar to “macro
hygiene”: we should not scan files whose name does not appear in
config.scm.

>> However, what we can do is improve the interface.  Things that come to
>> mind:
>>
>>   1. Change or remove the ‘udev-rule’ procedure; we should be using
>>      file-like objects instead, so one could store them alongside
>>      config.scm and write:
>>
>>        (local-file "./my-udev-rule")
>
> Is this really so different from the bad idea I proposed?  As soon as we
> load files outside of “config.scm” users would need to copy more than
> just the GuixSD config file to duplicate the system state on another
> machine.  In this example we would need both “config.scm” and
> “my-udev-rule” in the same directory.

It’s similar to your idea, except that the file is explicitly named in
the <operating-system> object.

If that helps, we could also allow users to specify a directory
containing several rules, instead of just a single rule:

  (local-file "./my-udev-rule-directory")

>>   2. Add a ‘extra-udev-rule’ procedure that you could use like this:
>>
>>        (operating-system
>>          ;; …
>>          (services (extra-udev-rule (local-file "./my-udev-rule"))
>>                    …))
>>
>>      thus avoiding the verbose ‘modify-services’ stanza.
>>
>>   3. (Instead of #2) Introduce a ‘udev-rules’ field in
>>      ‘operating-system’, just like we do for firmware.
>>
>> WDYT?
>
> I don’t know.  Although this would simplify configuration I don’t really
> like either of them for somewhat conflicting reasons.  #3 gives special
> treatment to udev rules (“What about Xorg config snippets?”), and with
> #2 it seems like an unnecessary implementation detail that this
> “extra-udev-rule” procedure is inside of the “services” field (“How come
> this is a service?”).
>
> I also feel that we should avoid adding “special” syntax.  Actually, I
> really like how generic this whole “modify-services” business is.  It’s
> just a little too verbose to be user-friendly, in my opinion.

I sympathize with that.

In fact, <operating-system> translates to a <service> graph.  The whole
<operating-system> thing is just “syntax.”

I would like to have a more formal way to describe this translation.  I
think this would allow us to fearlessly add or remove fields to
<operating-system>.  But I don’t know how to achieve it.

In the meantime, we should still address the usability issue that you
raised, which is why I made these suggestions.

Thoughts?

Thank you,
Ludo’.

Re: Microscheme failed

[Daniel Pimentel]

>> (define avrispmkii-udev-rule
>>   (udev-rule "90-avrispmkii.rules"
>>              "\
>> SUBSYSTEM!=\"usb\", ACTION!=\"add\", GOTO=\"avrisp_end\"
>> 
>> # Atmel Corp. JTAG ICE mkII
>> ATTR{idVendor}==\"03eb\", ATTR{idProduct}==\"2103\", MODE=\"660\", 
>> GROUP=\"dialout\"
>> # Atmel Corp. AVRISP mkII
>> ATTR{idVendor}==\"03eb\", ATTR{idProduct}==\"2104\", MODE=\"660\", 
>> GROUP=\"dialout\"
>> # Atmel Corp. Dragon
>> ATTR{idVendor}==\"03eb\", ATTR{idProduct}==\"2107\", MODE=\"660\", 
>> GROUP=\"dialout\"
>> 
>> LABEL=\"avrisp_end\"\n"))
>> 
>> (operating-system
>>   …
>>   (services (cons* (modify-services %desktop-services
>>                      (udev-service-type config =>
>>                                         (udev-configuration
>>                                          (inherit config)
>>                                          (rules (append 
>> (udev-configuration-rules config)
>>                                                         (list 
>> avrispmkii-udev-rule))))))))
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
> Should we add this as an optional service or to the default set of udev
> rules?
> 

It works. I think a good solution as optional service now.

Thanks,

Note: Ricardo, I reported avr-toolchain bug in bug-guix. I'll try debug 
and fix it.

-- 
Daniel Pimentel (aka d4n1)