Question regarding qmk firmware

Question regarding qmk firmware

[Fredrik Salomonsson]

Hi,

Today I was tweaking a keymap for one of my qmk based keyboards but some
of the packages I used when building the firmware has been removed.  My
commad was as follows:

```sh
    guix shell avr-toolchain dfu-programmer qmk -- qmk flash -kb ergodox_infinity -km plattfot -bl dfu-split-left
```

But `avr-toolchain` is gone.  When I tried to just drop it and see if it
worked I get

```
Ψ Compiling keymap with make --jobs=1 ergodox_infinity:plattfot:dfu-split-left


QMK Firmware 0.14.19
Making ergodox_infinity with keymap plattfot and target dfu-split-left

/gnu/store/rib9g2ig1xf3kclyl076w28parmncg4k-bash-minimal-5.1.16/bin/sh: line 1: arm-none-eabi-gcc: command not found
```

It seems `arm-none-eabi-toolchain` is also removed.  Looking at the
commit history for guix it looks like they got replaced by
[proceduers][0] instead.

[0] https://git.savannah.gnu.org/cgit/guix.git/commit/?id=35c1df5bd6317b1cd038c1a4aca1c7e4a52d4d93

My question is how do I get access to the arm-none-eabi-toolchain from
the commandline with guix shell?

Thanks

-- 
s/Fred[re]+i[ck]+/Fredrik/g

Re: Question regarding qmk firmware

[Ekaitz Zarraga]

------- Original Message -------
On Saturday, October 7th, 2023 at 21:23, Fredrik Salomonsson <plattfot@posteo.net> wrote:


> Hi,
> 
> Today I was tweaking a keymap for one of my qmk based keyboards but some
> of the packages I used when building the firmware has been removed. My
> commad was as follows:
> 
> `sh guix shell avr-toolchain dfu-programmer qmk -- qmk flash -kb ergodox_infinity -km plattfot -bl dfu-split-left`
> 
> But `avr-toolchain` is gone. When I tried to just drop it and see if it
> worked I get
> 
> `Ψ Compiling keymap with make --jobs=1 ergodox_infinity:plattfot:dfu-split-left QMK Firmware 0.14.19 Making ergodox_infinity with keymap plattfot and target dfu-split-left /gnu/store/rib9g2ig1xf3kclyl076w28parmncg4k-bash-minimal-5.1.16/bin/sh: line 1: arm-none-eabi-gcc: command not found`
> 
> It seems `arm-none-eabi-toolchain` is also removed. Looking at the
> commit history for guix it looks like they got replaced by
> [proceduers][0] instead.
> 
> [0] https://git.savannah.gnu.org/cgit/guix.git/commit/?id=35c1df5bd6317b1cd038c1a4aca1c7e4a52d4d93
> 
> My question is how do I get access to the arm-none-eabi-toolchain from
> the commandline with guix shell?
> 
> Thanks


Hi Fredrik,

Now what you need to do is call to the `make-avr-toolchain` function from `(gnu packages avr)` to get that.

Maybe the easiest way is to create a `manifest.scm` where you do something like this (i'm doing it by memory):

``` scheme
(use-modules (gnu packages avr)
             (gnu packages flashing-tools)
             (gnu packages firmware))

(packages->manifest (list (make-avr-toolchain) dfu-programmer qmk))
```

Then use `guix shell -m manifest.scm`.

There are other ways to do it, but I find this the easiest.
You can even make a package for your firmware and let guix compile it for you (and maybe flash it too?).

Cheers,
Ekaitz

Fw: Question regarding qmk firmware

[Ekaitz Zarraga]

Hi

I want to forward this message to guix-devel because it is a clear case of some (actually good) technical decision affecting users in unexpected ways.

Now, after the change, a user might run `guix search avr-toolchain`  and find nothing. Same for ARM.

This is a shame, because we have toolchains for those architectures but converting them to a function that returns the package leave many users that are not used to read guix's code thinking those packages are gone.

Maybe we should create some kind of fake packages that show up in `guix show` and `guix search` that have a short tutorial on how to use packages that come from a function like these.
This way providing the same interface for every package regardless where they are coming from.

I leave it as food for thought.

Thanks,

Ekaitz 


------- Forwarded Message -------
From: Fredrik Salomonsson <plattfot@posteo.net>
Date: On Saturday, October 7th, 2023 at 21:23
Subject: Question regarding qmk firmware
To: help-guix <help-guix@gnu.org>


> Hi,
> 
> Today I was tweaking a keymap for one of my qmk based keyboards but some
> of the packages I used when building the firmware has been removed. My
> commad was as follows:
> 
> `sh guix shell avr-toolchain dfu-programmer qmk -- qmk flash -kb ergodox_infinity -km plattfot -bl dfu-split-left`
> 
> But `avr-toolchain` is gone. When I tried to just drop it and see if it
> worked I get
> 
> `Ψ Compiling keymap with make --jobs=1 ergodox_infinity:plattfot:dfu-split-left QMK Firmware 0.14.19 Making ergodox_infinity with keymap plattfot and target dfu-split-left /gnu/store/rib9g2ig1xf3kclyl076w28parmncg4k-bash-minimal-5.1.16/bin/sh: line 1: arm-none-eabi-gcc: command not found`
> 
> It seems `arm-none-eabi-toolchain` is also removed. Looking at the
> commit history for guix it looks like they got replaced by
> [proceduers][0] instead.
> 
> [0] https://git.savannah.gnu.org/cgit/guix.git/commit/?id=35c1df5bd6317b1cd038c1a4aca1c7e4a52d4d93
> 
> My question is how do I get access to the arm-none-eabi-toolchain from
> the commandline with guix shell?
> 
> Thanks
> 
> --
> s/Fred[re]+i[ck]+/Fredrik/g

Re: Fw: Question regarding qmk firmware

[John Kehayias]

Hello,

On Sun, Oct 08, 2023 at 10:34 AM, Ekaitz Zarraga wrote:

> Hi
>
> I want to forward this message to guix-devel because it is a clear
> case of some (actually good) technical decision affecting users in
> unexpected ways.
>
> Now, after the change, a user might run `guix search avr-toolchain`
> and find nothing. Same for ARM.
>

In this case would it have helped to deprecate the package? Or can we
(ab)use this as a way to notify a user that either something has
changed (use a procedure now) or that a package you might expect at
this name is available some other way?

> This is a shame, because we have toolchains for those architectures
> but converting them to a function that returns the package leave many
> users that are not used to read guix's code thinking those packages
> are gone.
>
> Maybe we should create some kind of fake packages that show up in
> `guix show` and `guix search` that have a short tutorial on how to use
> packages that come from a function like these.
> This way providing the same interface for every package regardless
> where they are coming from.
>

At the very least this should be documented, perhaps adding to
information about the kernel in the manual and generally
customizing/building your own.

I like the idea in general of making sure people can find things and
if they are not where you'd expect not having a hard time to find
them. Some tips in a package description about how to use or where to
look in the manual for information would be good, but I don't think
we'd want to get too verbose here, adding another maintenance point
that should be proper documentation (or cookbook).

As an example, we don't need to always say how to add udev rules from
a package, but letting users know (if it is not obvious from the name)
that rules are included and should be added to a system configuration
for something to work (pointing to the manual about udev service) I
think can be helpful. I don't know though, I guess the package's
documentation itself needs to tell a user how to use it, and then one
looks in the Guix manual how to add udev rules.

Anyway, perhaps I run on a tangent here.

John

> I leave it as food for thought.
>
> Thanks,
>
> Ekaitz
>
>
> ------- Forwarded Message -------
> From: Fredrik Salomonsson <plattfot@posteo.net>
> Date: On Saturday, October 7th, 2023 at 21:23
> Subject: Question regarding qmk firmware
> To: help-guix <help-guix@gnu.org>
>
>
>> Hi,
>>
>> Today I was tweaking a keymap for one of my qmk based keyboards but some
>> of the packages I used when building the firmware has been removed. My
>> commad was as follows:
>>
>> `sh guix shell avr-toolchain dfu-programmer qmk -- qmk flash -kb
>> ergodox_infinity -km plattfot -bl dfu-split-left`
>>
>> But `avr-toolchain` is gone. When I tried to just drop it and see if it
>> worked I get
>>
>> `Ψ Compiling keymap with make --jobs=1
>> ergodox_infinity:plattfot:dfu-split-left QMK Firmware 0.14.19 Making
>> ergodox_infinity with keymap plattfot and target dfu-split-left
>> /gnu/store/rib9g2ig1xf3kclyl076w28parmncg4k-bash-minimal-5.1.16/bin/sh:
>> line 1: arm-none-eabi-gcc: command not found`
>>
>> It seems `arm-none-eabi-toolchain` is also removed. Looking at the
>> commit history for guix it looks like they got replaced by
>> [proceduers][0] instead.
>>
>> [0]
>> <https://git.savannah.gnu.org/cgit/guix.git/commit>/?id=35c1df5bd6317b1cd038c1a4aca1c7e4a52d4d93
>>
>> My question is how do I get access to the arm-none-eabi-toolchain from
>> the commandline with guix shell?
>>
>> Thanks
>>
>> --
>> s/Fred[re]+i[ck]+/Fredrik/g

Re: Question regarding qmk firmware

[Fredrik Salomonsson]

Hi Ekaitz,

Ekaitz Zarraga <ekaitz@elenq.tech> writes:

> Hi Fredrik,
>
> Now what you need to do is call to the `make-avr-toolchain` function from `(gnu packages avr)` to get that.
>
> Maybe the easiest way is to create a `manifest.scm` where you do something like this (i'm doing it by memory):
>
> ``` scheme
> (use-modules (gnu packages avr)
>              (gnu packages flashing-tools)
>              (gnu packages firmware))
>
> (packages->manifest (list (make-avr-toolchain) dfu-programmer qmk))
> ```
>
> Then use `guix shell -m manifest.scm`.
>
> There are other ways to do it, but I find this the easiest.

Thank you for pointing me in the right direction!  This is what I ended
up with:

```scheme
(use-modules
 (gnu packages embedded)
 (gnu packages flashing-tools)
 (gnu packages firmware))

(packages->manifest
 (list (make-arm-none-eabi-nano-toolchain-6)
       dfu-util
       qmk))
```
Then just simply run

```sh
guix shell -m manifest.scm -- qmk flash -kb ergodox_infinity -km plattfot -bl dfu-util-split-left
```
And that worked like a charm.

I had forgotten that my ergodox is using different tools than my kyria.
Also the nano lib threw me for a loop.  I was using the
`make-arm-none-eabi-toolchain-6` at first.

> You can even make a package for your firmware and let guix compile it
> for you (and maybe flash it too?).

Oh, that sounds that it might be useful.  Especially if it can flash it
too.  As I have a few keyboards and not all keymaps are pushed upstream
(yet).

-- 
s/Fred[re]+i[ck]+/Fredrik/g

Re: Fw: Question regarding qmk firmware

[Fredrik Salomonsson]

John Kehayias <john.kehayias@protonmail.com> writes:

> Hello,
>
> On Sun, Oct 08, 2023 at 10:34 AM, Ekaitz Zarraga wrote:
>
>> Hi
>>
>> I want to forward this message to guix-devel because it is a clear
>> case of some (actually good) technical decision affecting users in
>> unexpected ways.
>>
>> Now, after the change, a user might run `guix search avr-toolchain`
>> and find nothing. Same for ARM.
>>
>
> In this case would it have helped to deprecate the package? Or can we
> (ab)use this as a way to notify a user that either something has
> changed (use a procedure now) or that a package you might expect at
> this name is available some other way?
>
>> This is a shame, because we have toolchains for those architectures
>> but converting them to a function that returns the package leave many
>> users that are not used to read guix's code thinking those packages
>> are gone.
>>
>> Maybe we should create some kind of fake packages that show up in
>> `guix show` and `guix search` that have a short tutorial on how to use
>> packages that come from a function like these.
>> This way providing the same interface for every package regardless
>> where they are coming from.
>>
>
> At the very least this should be documented, perhaps adding to
> information about the kernel in the manual and generally
> customizing/building your own.
>
> I like the idea in general of making sure people can find things and
> if they are not where you'd expect not having a hard time to find
> them. Some tips in a package description about how to use or where to
> look in the manual for information would be good, but I don't think
> we'd want to get too verbose here, adding another maintenance point
> that should be proper documentation (or cookbook).
>
> As an example, we don't need to always say how to add udev rules from
> a package, but letting users know (if it is not obvious from the name)
> that rules are included and should be added to a system configuration
> for something to work (pointing to the manual about udev service) I
> think can be helpful. I don't know though, I guess the package's
> documentation itself needs to tell a user how to use it, and then one
> looks in the Guix manual how to add udev rules.
>
> Anyway, perhaps I run on a tangent here.
>
> John
>
>> I leave it as food for thought.
>>
>> Thanks,
>>
>> Ekaitz
>>
>>

Adding my two cents here as a user.

It would be great to have some sort of documentation about this.  Just a
tiny snippet on how to use them will be sufficient.

And a guix pull --news that notified you about the packages changed to
procedures.  It was not obvious to me when avr-toolchain disappeared how
to proceed.  I had to look in the commit log to figure out what happened
to it (the issue tracker would probably also have worked).  Even then it
wasn't super obvious how I would use them as my mind was fixed on the
`guix shell PACKAGE0 PACKAGE1 …` workflow.  I never really use manifests
as I have guix home to handle all my packages, and guix.scm for package
development.

-- 
s/Fred[re]+i[ck]+/Fredrik/g

Re: Fw: Question regarding qmk firmware

[Maxim Cournoyer]

Hi Ekaitz,

Ekaitz Zarraga <ekaitz@elenq.tech> writes:

> Hi
>
> I want to forward this message to guix-devel because it is a clear
> case of some (actually good) technical decision affecting users in
> unexpected ways.
>
> Now, after the change, a user might run `guix search avr-toolchain`  and find nothing. Same for ARM.
>
> This is a shame, because we have toolchains for those architectures
> but converting them to a function that returns the package leave many
> users that are not used to read guix's code thinking those packages
> are gone.
>
> Maybe we should create some kind of fake packages that show up in
> `guix show` and `guix search` that have a short tutorial on how to use
> packages that come from a function like these.
> This way providing the same interface for every package regardless where they are coming from.
>
> I leave it as food for thought.

There's this series: https://issues.guix.gnu.org/66263 that proposes to
still have a module which would include the cross-toolchain as packages
again; it'd be in a new module, and as I pointed to in my review we'd
need to stress hard that this module is only for convenience and
shouldn't be imported anywhere else in the Guix source code (which seems
a bit of a slippery slope to me, as people rarely read the module
commentary, and rightly assume that any package present in Guix can be
used as another package's input).

We can't deprecate the package I think, as the replacement is not of the
same type (it's replaced by a procedure).  A NEWS could perhaps have
helped, though it's not as good as a deprecation.

-- 
Thanks,
Maxim