no matching pattern #<package polkit..

OpenSubmitted by Guu, Jin-Cheng.
Details
4 participants
  • Josselin Poiret
  • Guu, Jin-Cheng
  • Ludovic Courtès
  • Mathieu Othacehe
Owner
unassigned
Severity
important
G
G
Guu, Jin-Cheng wrote on 28 Jan 02:45 +0100
(address . bug-guix@gnu.org)
CAErjG5fe21uSsXLGFTycCGS=eMnpAyA=bEBwjJrVqQTOzhcEPw@mail.gmail.com
Hello Guix,

I obtained a latest dev ISO for guix system and tried installing it
just now. With the graphical installer, I received the error below for
two times. Perhaps it's a bug?

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" #<package polkit@0.120 gnu/packages/polkit.scm: 54
7f6e64aa7b00>)'.

Command failed with exit code 1.
Press Enter to continue.

Thank you for all your work!

Best Regards,
Jin
M
M
Mathieu Othacehe wrote on 2 Feb 18:28 +0100
(name . Guu, Jin-Cheng)(address . jin-cheng.guu@stonybrook.edu)(address . 53594@debbugs.gnu.org)
874k5hch4d.fsf@gnu.org
Hey,

Thanks for the report.

Toggle quote (5 lines)
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> Throw to key `match-error' with args `("match" "no matching
> pattern" #<package polkit@0.120 gnu/packages/polkit.scm: 54
> 7f6e64aa7b00>)'.

I had the exact same issue while trying to build an installer
image. Running `make clean-go` and retrying fixed the error. Did you
build the installation image or downloaded it from the Guix website?

Thanks,

Mathieu
G
G
Guu, Jin-Cheng wrote on 2 Feb 18:31 +0100
(name . Mathieu Othacehe)(address . othacehe@gnu.org)(address . 53594@debbugs.gnu.org)
CAErjG5efUuB7aW-x13whyXQKNsbWB2A_NqcqFUnWp81Ca2iPpQ@mail.gmail.com
I downloaded it form the Guix website. If memory served me right, it was from

Jin
J
J
Josselin Poiret wrote on 22 Apr 17:44 +0200
(address . 53594@debbugs.gnu.org)
87k0bh3yy8.fsf@jpoiret.xyz
Hello everyone,

Someone reported the exact same issue today on IRC [1], with polkit
being the culprit. With a bigger backtrace, the match error happens at
line 901 in guix/gexp.scm, in the match inside the return part of
lower-inputs. This suggests that lower-object doesn't manage to return
a derivation but only the polkit package. I suspect that this has to do
with the complex polkit package interactions that we have, with polkit
being an identifier syntax for either polkit-mozjs or polkit-duktape,
with duktape package/inherit'ing polkit-mozjs with is itself replaced by
polkit-mozjs/fixed.

Maybe there's an interaction with the caching as well, while grafting
and looping?

I've tried to reproduce this locally by building a gexp that has either
polkit, polkit-duktape or polkit-mozjs as an input, enabling or
disabling fallback or grafting, to no avail.

Maybe someone else has another idea?


Best,
--
Josselin Poiret
L
L
Ludovic Courtès wrote on 11 May 22:11 +0200
control message for bug #53594
(address . control@debbugs.gnu.org)
87y1z7n82t.fsf@gnu.org
severity 53594 important
quit
L
L
Ludovic Courtès wrote on 11 May 22:11 +0200
control message for bug #53214
(address . control@debbugs.gnu.org)
87wnern81q.fsf@gnu.org
block 53214 by 53594
quit
L
L
Ludovic Courtès wrote on 11 May 22:15 +0200
Re: bug#53594: no matching pattern #<package polkit..
(name . Josselin Poiret)(address . dev@jpoiret.xyz)
87sfpfn7uv.fsf@gnu.org
Hi!

I hit this as well while running `guix system reconfigure'
(unfortunately I didn't capture the stack trace).

Re-running `guix system reconfigure' right after it had failed
worked...

So my guess is that it's a stateful issue, having to do with
grafts: if polkit is not in the store, then we build/download
it and fail right after that, which is why it succeeds the
second time.

To be continued...

Ludo'.
L
L
Ludovic Courtès wrote on 14 May 17:55 +0200
(name . Josselin Poiret)(address . dev@jpoiret.xyz)
87a6bkf6rb.fsf@inria.fr
Hello,

The failing code is at gexp.scm:901:23, which corresponds to this:

(mlet %store-monad ((obj (lower-object thing system
#:target
(and (not native?)
target))))
901: (return (match obj
((? derivation? drv)
(derivation-input drv (list output)))
((? store-item? item)
item)
((? self-quoting?)
;; Some inputs such as <system-binding> can lower to
;; a self-quoting object that FILTERM will filter
;; out.
#f))))

That means (lower-object polkit) returned polkit (the package object)
instead of a derivation, hence ‘match-error’.

This is normally impossible: ‘lower-object’ calls ‘package->derivation’,
which returns a derivation. But maybe something weird is happening when
‘build-derivations’ aborts to the build-handler prompt, or when the
continuation is eventually resumed; maybe the object cache gets
“poisoned” with an incorrect value during that process.

So far the only reproducer we have seems to be along the lines of: grab
the ISO, run ‘guix pull’ (if it’s the 1.3.0 ISO; if it’s a fresh ISO,
that’s not necessary), run ‘guix system init’, watch it crash.

Does anyone have a simpler reproducer?

To be continued…

Ludo’.
?