Hello, I made a package named "qmk-cli" and it seems Guix doesn't like it. Running "./pre-inst-env guix install "qmk-cli"" results in this: guix install: error: Unbound variable: ~S Jan Wielkiewicz
It seems it's not about the name, but the package - I changed the name to "qmk" and it still doesn't work. Not that this is an excuse for writing such a strange message. Make output: [100%] GUILEC gnu/packages/hardware.go gnu/packages/hardware.scm:486:4: warning: possibly unbound variable `arm-none-eabi-toolchain' gnu/packages/hardware.scm:486:4: warning: possibly unbound variable `avr-toolchain' gnu/packages/hardware.scm:486:4: warning: possibly unbound variable `dfu-programmer' gnu/packages/hardware.scm:486:4: warning: possibly unbound variable `dfu-util' My wip package: (define-public qmk (package (name "qmk") (version "0.0.35") (source (origin (method url-fetch) (uri (pypi-uri "qmk" version)) (sha256 (base32 "1dd3q38r5bs9ih8jiwsb7q2655wyka2a8wlwv7yln9narlqwl177")))) (build-system python-build-system) (propagated-inputs `(("arm-none-eabi-toolchain" ,arm-none-eabi-toolchain) ("avr-toolchain" ,avr-toolchain) ("dfu-programmer" ,dfu-programmer) ("dfu-util" ,dfu-util) ("python3" ,python) ("python-appdirs" ,python-appdirs) ("python-argcomplete" ,python-argcomplete) ("python-colorama" ,python-colorama) ("python-flake8" ,python-flake8) ("python-hjson" ,python-hjson) ("python-nose2" ,python-nose2) ("python-yapf" ,python-yapf))) (arguments `(#:tests? #f)) ; no tests (home-page "https://github.com/qmk/qmk_cli") (synopsis "Work with QMK Firmware") (description "A program to help users work with QMK Firmware.") (license license:expat))) Jan Wielkiewicz
On Wed, Jul 29, 2020 at 06:16:47PM +0200, Jan Wielkiewicz wrote:
> It seems it's not about the name, but the package - I changed the name
> to "qmk" and it still doesn't work. Not that this is an excuse for
> writing such a strange message.
I think some interface changed elsewhere in the codebase and these
errors are confusing. Try `make clean-go && make` before using the
./pre-inst-env script again.
Dnia 2020-07-29, o godz. 13:00:59
Leo Famulari <leo@famulari.name> napisał(a):
> On Wed, Jul 29, 2020 at 06:16:47PM +0200, Jan Wielkiewicz wrote:
> > It seems it's not about the name, but the package - I changed the
> > name to "qmk" and it still doesn't work. Not that this is an excuse
> > for writing such a strange message.
>
> I think some interface changed elsewhere in the codebase and these
> errors are confusing. Try `make clean-go && make` before using the
> ./pre-inst-env script again.
Same thing, didn't work
Jan Wielkiewicz <tona_kosmicznego_smiecia@interia.pl> writes:
> It seems it's not about the name, but the package - I changed the name
> to "qmk" and it still doesn't work. Not that this is an excuse for
> writing such a strange message.
>
> Make output:
>
> [100%] GUILEC gnu/packages/hardware.go
> gnu/packages/hardware.scm:486:4: warning: possibly unbound variable
> `arm-none-eabi-toolchain' gnu/packages/hardware.scm:486:4: warning:
> possibly unbound variable `avr-toolchain'
> gnu/packages/hardware.scm:486:4: warning: possibly unbound variable
> `dfu-programmer' gnu/packages/hardware.scm:486:4: warning: possibly
> unbound variable `dfu-util'
What is the actual diff? I see that (gnu packages hardware) does not
import (gnu packages avr), so it’s expected that “avr-toolchain” cannot
be found.
--
Ricardo
Dnia 2020-07-29, o godz. 19:57:35
Ricardo Wurmus <rekado@elephly.net> napisał(a):
> What is the actual diff? I see that (gnu packages hardware) does not
> import (gnu packages avr), so it’s expected that “avr-toolchain”
> cannot be found.
>
Just added it and I get the same result. Anyway, the error message is
useless. I'll try removing some inputs and check what causes this.
Dnia 2020-07-29, o godz. 19:57:35
Ricardo Wurmus <rekado@elephly.net> napisał(a):
>
> What is the actual diff? I see that (gnu packages hardware) does not
> import (gnu packages avr), so it’s expected that “avr-toolchain”
> cannot be found.
>
Okay, I tested it and it fails on "avr-toolchain", even though I have
#:use-module (gnu packages avr).
Jan Wielkiewicz <tona_kosmicznego_smiecia@interia.pl> writes:
> Dnia 2020-07-29, o godz. 19:57:35
> Ricardo Wurmus <rekado@elephly.net> napisał(a):
>
>>
>> What is the actual diff? I see that (gnu packages hardware) does not
>> import (gnu packages avr), so it’s expected that “avr-toolchain”
>> cannot be found.
>>
>
> Okay, I tested it and it fails on "avr-toolchain", even though I have
> #:use-module (gnu packages avr).
“avr-toolchain” is a procedure, not a package. Use “avr-toolchain-4.9”
or “avr-toolchain-5”.
--
Ricardo
Dnia 2020-07-29, o godz. 22:17:01
Ricardo Wurmus <rekado@elephly.net> napisał(a):
>
> “avr-toolchain” is a procedure, not a package. Use
> “avr-toolchain-4.9” or “avr-toolchain-5”.
>
Success!
What about the strange message though?
"incorrect package definition" would be better.
Jan Wielkiewicz <tona_kosmicznego_smiecia@interia.pl> writes:
> Dnia 2020-07-29, o godz. 22:17:01
> Ricardo Wurmus <rekado@elephly.net> napisał(a):
>
>>
>> “avr-toolchain” is a procedure, not a package. Use
>> “avr-toolchain-4.9” or “avr-toolchain-5”.
>>
>
> Success!
>
> What about the strange message though?
> "incorrect package definition" would be better.
“Unbound variable: ~S” looks like a format string with a placeholder
that didn’t get replaced with an actual value. It would be marginally
better if it said “Unbound variable: avr-toolchain”.
We should, I think, take advantage of the fact that the type of inputs
is known: it can only be an origin or a package value. Perhaps we can
catch unbound variables in inputs and print a more valuable error
message.
--
Ricardo
On Thu, Jul 30, 2020 at 12:15:56AM +0200, Ricardo Wurmus wrote: > “Unbound variable: ~S” looks like a format string with a placeholder > that didn’t get replaced with an actual value. It would be marginally > better if it said “Unbound variable: avr-toolchain”. The reason I suggested an interface change being responsible for "Unbound variable: ~S" is that I noticed it a couple days ago after changes to (guix ui), and it was fixed by `make clean-go`: http://logs.guix.gnu.org/guix/2020-07-27.log#015055 I think that error message is an example of what can go wrong when using a development environment without rebuilding everything first.
Hi, On +2020-07-30 00:15:56 +0200, Ricardo Wurmus wrote: > > Jan Wielkiewicz <tona_kosmicznego_smiecia@interia.pl> writes: > > > Dnia 2020-07-29, o godz. 22:17:01 > > Ricardo Wurmus <rekado@elephly.net> napisał(a): > > > >> > >> “avr-toolchain” is a procedure, not a package. Use > >> “avr-toolchain-4.9” or “avr-toolchain-5”. > >> > > > > Success! > > > > What about the strange message though? > > "incorrect package definition" would be better. > > “Unbound variable: ~S” looks like a format string with a placeholder > that didn’t get replaced with an actual value. It would be marginally > better if it said “Unbound variable: avr-toolchain”. I suspect there are also bugs lurking in the exception-reporting chain between a (throw 'exception args ...) and the ultimate format statement that produces a message with "~S" in it. Perhaps one got fixed or avoided in the upgrade? It seems like something must receive a malformed (key . args) pair where the args don't match the standard(?) tuple expected for the key. I'd look for dynamic format string generation splitting arg strings and mistakenly recomposing a format string and args for it, such that "~S" got placed in the arg list instead of string-appended into the proper final format. Just a hunch. IIRC I've seen mangling the final format string and its args wind up with a mismatch in number of args and interpolation "~s" elements and if not papered over, that gets reported as a formatting error (which it is, but which hides the real error). > > We should, I think, take advantage of the fact that the type of inputs > is known: it can only be an origin or a package value. Perhaps we can > catch unbound variables in inputs and print a more valuable error > message. I think you are right. And all implicit meta-data should be seen as potential security vulnerabilities IMO :) Who do you trust to do a reinterpret-cast for you? > > -- > Ricardo > > > -- Regards, Bengt Richter
Hi, Bengt Richter <bokr@bokr.com> writes: > Hi, > > On +2020-07-30 00:15:56 +0200, Ricardo Wurmus wrote: >> >> Jan Wielkiewicz <tona_kosmicznego_smiecia@interia.pl> writes: >> >> > Dnia 2020-07-29, o godz. 22:17:01 >> > Ricardo Wurmus <rekado@elephly.net> napisał(a): >> > >> >> >> >> “avr-toolchain” is a procedure, not a package. Use >> >> “avr-toolchain-4.9” or “avr-toolchain-5”. >> >> >> > >> > Success! >> > >> > What about the strange message though? >> > "incorrect package definition" would be better. >> >> “Unbound variable: ~S” looks like a format string with a placeholder >> that didn’t get replaced with an actual value. It would be marginally >> better if it said “Unbound variable: avr-toolchain”. > > I suspect there are also bugs lurking in the exception-reporting chain between > a (throw 'exception args ...) and the ultimate format statement that produces > a message with "~S" in it. Perhaps one got fixed or avoided in the upgrade? That would be my hunch too! I had reported and tried to fix such problems here: http://issues.guix.gnu.org/41956. Still unresolved, it requires more effort to be fixed properly (writing tests mostly). Maxim
Hi,
> I made a package named "qmk-cli" and it seems Guix doesn't like it.
> Running "./pre-inst-env guix install "qmk-cli"" results in this:
> guix install: error: Unbound variable: ~S
My bad, I believe this is fixed by
05f3d34094b23dc9612ff6641a0257bc4f7dcd12.
Thanks for reporting the issue!
Is this bug closed, though?
Ludo’.
Dnia 2020-08-05, o godz. 22:33:14
Ludovic Courtès <ludo@gnu.org> napisał(a):
> My bad, I believe this is fixed by
> 05f3d34094b23dc9612ff6641a0257bc4f7dcd12.
>
> Thanks for reporting the issue!
>
> Is this bug closed, though?
>
> Ludo’.
I can close it if needed.
[-- Attachment #1: Type: text/plain, Size: 3502 bytes --] Hello, I believe there's still something wrong here. The bug (the new one, described below) occurs after adding #:use-module (gnu packages avr) to the firmware.scm file. Attached the diff file of my package below. I'm packaging qmk-firmware and here's what happens running guix build: error: binutils: unbound variable hint: Did you forget a `use-modules' form? error: googletest: unbound variable hint: Did you forget a `use-modules' form? error: bzip2: unbound variable hint: Did you forget a `use-modules' form? error: gcc-4.9: unbound variable hint: Did you forget a `use-modules' form? error: perl-module-build: unbound variable hint: Did you forget a `use-modules' form? error: python2-numpy: unbound variable hint: Did you forget a `use-modules' form? error: gzip: unbound variable hint: Did you forget a `use-modules' form? error: xcb-proto: unbound variable hint: Did you forget a `use-modules' form? error: gnu-make: unbound variable hint: Did you forget a `use-modules' form? error: unzip: unbound variable hint: Did you forget a `use-modules' form? error: curl: unbound variable hint: Did you forget a `use-modules' form? error: binutils: unbound variable hint: Did you forget a `use-modules' form? error: pjproject: unbound variable hint: Did you forget a `use-modules' form? error: xorg-server: unbound variable hint: Did you forget a `use-modules' form? error: libdvdnav: unbound variable hint: Did you forget a `use-modules' form? error: perl: unbound variable hint: Did you forget a `use-modules' form? error: coreutils: unbound variable hint: Did you forget a `use-modules' form? error: libetpan: unbound variable hint: Did you forget a `use-modules' form? Throw to key `unbound-variable' with args `("resolve-interface" "no binding `~A' in module ~A" (python (gnu packages python)) #f)'. Backtrace: In ice-9/boot-9.scm: 1736:10 19 (with-exception-handler _ _ #:unwind? _ # _) In guix/store.scm: 631:22 18 (thunk) 1299:8 17 (call-with-build-handler #<procedure 7fd7f867b420 at g…> …) In guix/scripts/build.scm: 817:2 16 (_) In srfi/srfi-1.scm: 673:15 15 (append-map _ _ . _) 586:17 14 (map1 ((argument . "qmk-firmware") (build-mode . 0) # …)) In guix/scripts/build.scm: 837:30 13 (_ _) In gnu/packages.scm: 477:2 12 (%find-package "qmk-firmware" "qmk-firmware" #f) 362:6 11 (find-best-packages-by-name _ _) 292:55 10 (_ "qmk-firmware" _) In unknown file: 9 (force #<promise #<procedure 7fd7f9172a00 at gnu/packag…>) In gnu/packages.scm: 239:33 8 (fold-packages #<procedure 7fd7f76d6f18 at gnu/package…> …) In guix/discovery.scm: 153:11 7 (all-modules _ #:warn _) In srfi/srfi-1.scm: 460:18 6 (fold #<procedure 7fd7f8626300 at guix/discovery.scm:1…> …) In guix/discovery.scm: 143:19 5 (_ _ ()) In srfi/srfi-1.scm: 691:23 4 (filter-map #<procedure 7fd7f86262c0 at guix/discove…> . #) In guix/discovery.scm: 118:22 3 (_ . _) In guix/ui.scm: 329:2 2 (report-unbound-variable-error _ #:frame _) In ice-9/boot-9.scm: 1669:16 1 (raise-exception _ #:continuable? _) 1669:16 0 (raise-exception _ #:continuable? _) ice-9/boot-9.scm:1669:16: In procedure raise-exception: Throw to key `match-error' with args `("match" "no matching pattern" (unbound-variable "resolve-interface" "no binding `~A' in module ~A" (python (gnu packages python)) #f))'. Jan Wielkiewicz [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: 0001-gnu-Add-qmk-firmware.patch --] [-- Type: text/x-patch, Size: 2684 bytes --] From 39b3791efd06c4895c844548937d421f8359b1e0 Mon Sep 17 00:00:00 2001 From: Jan Wielkiewicz <tona_kosmicznego_smiecia@interia.pl> Date: Sun, 9 Aug 2020 23:43:08 +0200 Subject: [PATCH] gnu: Add qmk-firmware. * gnu/packages/firmware.scm (qmk-firmware): New variable. --- gnu/packages/firmware.scm | 37 +++++++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) diff --git a/gnu/packages/firmware.scm b/gnu/packages/firmware.scm index 15a6725c67..a0c65752d4 100644 --- a/gnu/packages/firmware.scm +++ b/gnu/packages/firmware.scm @@ -7,6 +7,7 @@ ;;; Copyright © 2018 Vagrant Cascadian <vagrant@debian.org> ;;; Copyright © 2019 Mathieu Othacehe <m.othacehe@gmail.com> ;;; Copyright © 2020 Marius Bakke <mbakke@fastmail.com> +;;; Copyright © 2020 Jan Wielkiewicz <tona_kosmicznego_smiecia@interia.pl> ;;; ;;; This file is part of GNU Guix. ;;; @@ -33,6 +34,8 @@ #:use-module (gnu packages) #:use-module (gnu packages admin) #:use-module (gnu packages assembly) + #:use-module (gnu packages autotools) + #:use-module (gnu packages avr) #:use-module (gnu packages base) #:use-module (gnu packages bison) #:use-module (gnu packages cmake) @@ -41,6 +44,7 @@ #:use-module (gnu packages gcc) #:use-module (gnu packages linux) #:use-module (gnu packages perl) + #:use-module (gnu packages pkg-config) #:use-module (gnu packages python)) (define-public ath9k-htc-firmware @@ -621,3 +625,36 @@ switching support).\n") #t))))) (native-inputs `(("cross-gcc" ,(cross-gcc "arm-none-eabi" #:xgcc gcc-7)) ("cross-binutils" ,(cross-binutils "arm-none-eabi")))))) + +(define-public qmk-firmware + (package + (name "qmk-firmware") + (version "0.9.50") + (source + (origin + (method git-fetch) + (uri (git-reference + (url "https://github.com/qmk/qmk_firmware") + (commit version))) + (file-name (git-file-name name version)) + (sha256 + (base32 + "0153glswflsaslz79k4r7a98rn1p8762qnjjfifzv82gfbcl2jj9")))) + (build-system gnu-build-system) + (native-inputs + `(("pkg-config" ,pkg-config) + ("autoconf" ,autoconf) + ("automake" ,automake))) + (arguments + `(#:phases + (modify-phases %standard-phases + (delete 'configure)))) + (home-page "https://qmk.fm/") + (synopsis "") + (description + "") + (license (list license:gpl2 + license:gpl3 + license:expat + license:bsd-3 + license:asl2.0)))) -- 2.28.0
Hi,
Jan Wielkiewicz <tona_kosmicznego_smiecia@interia.pl> skribis:
> Dnia 2020-08-05, o godz. 22:33:14
> Ludovic Courtès <ludo@gnu.org> napisał(a):
>
>> My bad, I believe this is fixed by
>> 05f3d34094b23dc9612ff6641a0257bc4f7dcd12.
>>
>> Thanks for reporting the issue!
>>
>> Is this bug closed, though?
>>
>> Ludo’.
>
> I can close it if needed.
Sure, if you think the other aspects mentioned in this thread are fixed,
please go ahead!
Thanks,
Ludo’.
Hi, I have experienced the same issue to build a package in Guix source. It's built just fine outside the source. My package definition https://git.sr.ht/~hellseher/ffab/tree/5c3071c6e3490ee285d245ada5e161cd272a161f/item/ffab/packages/lisp-xyz.scm#L50 > ./pre-inst-env guix describe Git checkout: repository: /mnt/library/code/guix branch: local/lisp-xyz/glop commit: c23d4871a609018b16ce27f2a131f9a20bf075c2 [env: /gnu/store/q781h6gmv1n2d05gkjs0fq84fjis78v3-profile] Throw to key `unbound-variable' with args `("resolve-interface" "no binding `~A' in module ~A" (python (gnu packages python)) #f)'. Backtrace: In guix/store.scm: 659:37 19 (thunk) 1298:8 18 (call-with-build-handler #<procedure 7fdf50705870 at g…> …) In guix/scripts/build.scm: 567:2 17 (_) In srfi/srfi-1.scm: 673:15 16 (append-map _ _ . _) 586:17 15 (map1 ((argument . "sbcl-glop") (build-mode . 0) (. #) …)) In guix/scripts/build.scm: 587:31 14 (_ _) In gnu/packages.scm: 479:2 13 (%find-package "sbcl-glop" "sbcl-glop" #f) 364:6 12 (find-best-packages-by-name _ _) 294:56 11 (_ "sbcl-glop" _) In unknown file: 10 (force #<promise #<procedure 7fdf5072a5e0 at gnu/packag…>) In gnu/packages.scm: 241:33 9 (fold-packages #<procedure 7fdf4fdcf528 at gnu/package…> …) In guix/discovery.scm: 159:11 8 (all-modules _ #:warn _) In srfi/srfi-1.scm: 460:18 7 (fold #<procedure 7fdf53215f60 at guix/discovery.scm:1…> …) In guix/discovery.scm: 149:19 6 (_ _ ()) 116:5 5 (scheme-modules _ _ #:warn _) In srfi/srfi-1.scm: 691:23 4 (filter-map #<procedure 7fdf53215e00 at guix/discove…> . #) In guix/discovery.scm: 124:24 3 (_ . _) In guix/ui.scm: 319:2 2 (report-unbound-variable-error _ #:frame _) In ice-9/boot-9.scm: 1685:16 1 (raise-exception _ #:continuable? _) 1685:16 0 (raise-exception _ #:continuable? _) ice-9/boot-9.scm:1685:16: In procedure raise-exception: Throw to key `match-error' with args `("match" "no matching pattern" (unbound-variable "resolve-interface" "no binding `~A' in module ~A" (python (gnu packages python)) #f))'. -- … наш разум - превосходная объяснительная машина которая способна найти смысл почти в чем угодно, истолковать любой феномен, но совершенно не в состоянии принять мысль о непредсказуемости.