Fw: Question regarding qmk firmware

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: 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