guix system: error: qemu-CVE-2017-7493.patch: patch not found

After a clean guix make, guix system build produced this error ...

root@g1 ~/con/15# guix system --cores=4 --max-jobs=4 -K --on-error=debug build sys.scm

guix system: error: qemu-CVE-2017-7493.patch: patch not found

VERSION INFO:

root@g1 ~/con/15# guix --version

guix (GNU Guix) 0.13.0.4202-1f6f4

Copyright (C) 2017 the Guix authors

License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.

root@g1 ~/con/15# stat ~/.config/guix/latest | grep File:

File: /root/.config/guix/latest -> /home/g1/src/guix/

root@g1 ~/con/15# git -C ~/.config/guix/latest describe

v0.13.0-4202-g1f6f4c40c

root@g1 ~/con/15# git -C ~/.config/guix/latest log -n 1 --oneline

1f6f4c40c (HEAD -> o-master, origin/master, origin/HEAD) gnu: Add r-tgconfig.

root@g1 ~/con/15# git -C /home/g1/src/guix branch -av | grep '*'

SYS CONFIG:

On Mon, Oct 30, 2017 at 04:34:08PM -0400, myglc2 wrote:

What about `git status`? Is the worktree in a consistent state? This

patch file was removed in August 2017 [0] and nothing should refer to it

anymore.

[0] commit 2de7d137b3c6f528acb540a6ab3460627f484b0a

On 10/30/2017 at 20:31 Leo Famulari writes:

Thanks Leo.

git status is clean ...

g1@g1 ~/src/guix$ git status

On branch o-master

Your branch is up-to-date with 'origin/master'.

nothing to commit, working tree clean

g1@g1 ~/src/guix$ git remote -vv

origin git://git.savannah.gnu.org/guix.git (fetch)

origin git://git.savannah.gnu.org/guix.git (push)

g1@g1 ~/src/guix$

emacs 'M-x grep find qemu-CVE-2017-7493.patch' produces ...

***

-*- mode: grep; default-directory: "~/src/guix/" -*-

Grep started at Wed Nov 1 10:25:46

find . -type f -exec grep --color -nH -e qemu-CVE-2017-74

Binary file ./gnu/packages/qemu.go matches

./test-tmp/store/.links/0m1wjb06m31vw9jpimbmqkwxh1fzgyxag

./test-tmp/store/.links/0zk12m0jwp2n2380pq9x56mx71ry1dv42

./test-tmp/store/.links/0vrz62alwffjah2rj33wrwj7ypzbkv0pm

./test-tmp/store/.links/0xlcs15frjqbnhmcp2pv1ly9by84ncafn

./test-tmp/store/.links/00fiw7380k24qcq3k6pqgkz6j0c1l6ibw

./test-tmp/store/.links/066d4qpkxrf8p5vgay3x9bwn3zhzxp3gh

./test-tmp/store/.links/1z89050j89mz33c97b9bhvrb2h8972qyg

./test-tmp/store/.links/0cwv31pb892219rqgnmxzb950kd82b3mz

./test-tmp/store/.links/0bz2735f2x9f624yzmi6i3bryxsgn0qq7

./test-tmp/store/.links/0mvrdlqf3y989djjghinvsvsa80h250xm

./test-tmp/store/h5nhfi9941i4bh02s3sijgzqcxcswxrx-qemu-2.

./test-tmp/store/44p8aj7gqd97126gsw82anvhbbq2h080-qemu-2.

./test-tmp/store/0dkhz940aq4h1s6wg2lflhxswrpw93gs-qemu-2.

./test-tmp/store/xdmnickhpv89q568jhgrlkixnc873dx9-qemu-2.

./test-tmp/store/apspl851a4lv6fn94wcgwmvlmfn3m24l-qemu-2.

./test-tmp/store/zbiwif5nw7074bwbrzv3b93mybrbqjqc-qemu-2.

./test-tmp/store/i8h6n9p0rvl1ra3s1k1pz9q7z1rnqnyc-qemu-2.

./test-tmp/store/saq5a28g1c6gybnfdd3v1lilkil7kvjf-qemu-2.

./test-tmp/store/i9g8mrrzmbyfa4k5ra3alw69jw3bynz0-qemu-2.

./test-tmp/store/0jd1jrsm3387vl7yncr6988zw7a969a3-qemu-2.

Binary file ./test-tmp/db/db.sqlite matches

Grep exited abnormally with code 1 at Wed Nov 1 10:25:49

***

In an attempt at self-help, I deleting ./test-tmp/*

But I am still getting this error.

TIA - George

On Wed, Nov 01, 2017 at 10:40:28AM -0400, myglc2 wrote:

Try deleting this compiled qemu.go and then try again.

On 11/01/2017 at 11:27 Leo Famulari writes:

Thank you Leo.

I deleted ./gnu/packages/qemu.go and re-ran make.

Make failed to regenerate ./gnu/packages/qemu.go

So now I am really confused.

DETAILS:

g1@g1 ~/src/guix$ guix environment -e "(@ (gnu packages package-management) guix)" -M 4 -c 4

g1@g1 ~/src/guix [env]$ make

make all-recursive

make[1]: Entering directory '/home/g1/src/guix'

Making all in po/guix

make[2]: Entering directory '/home/g1/src/guix/po/guix'

make[2]: Leaving directory '/home/g1/src/guix/po/guix'

Making all in po/packages

make[2]: Entering directory '/home/g1/src/guix/po/packages'

make[2]: Leaving directory '/home/g1/src/guix/po/packages'

make[2]: Entering directory '/home/g1/src/guix'

Compiling Scheme modules...

make[2]: Leaving directory '/home/g1/src/guix'

make[1]: Leaving directory '/home/g1/src/guix'

g1@g1 ~/src/guix [env]$ ls -l ./gnu/packages/qemu.go

ls: cannot access './gnu/packages/qemu.go': No such file or directory

g1@g1 ~/src/guix$ git status

On branch o-master

Your branch is up-to-date with 'origin/master'.

nothing to commit, working tree clean

g1@g1 ~/src/guix$ git branch -vv

On Wed, Nov 01, 2017 at 10:40:47PM -0400, myglc2 wrote:

The 'gnu/packages/qemu.scm' file was removed from Guix in July 2017,

with commit 59132b800093e486e4d81aed6b837e9ac76aa86c. The QEMU packages

were moved into 'gnu/packages/virtualization.scm'.

I'm not an Autotools expert, but in cases like this I usually try `make

clean && ./configure --localstatedir=/var && make`. Did you try

something like that yet?

On 11/01/2017 at 22:44 Leo Famulari writes:

Thanks Leo.

I did a new git pull and a clean build as you suggested (please see the

grep of the make.log below for details)

Now when I try 'guix system build sys.scm I get ...

guix system: error: failed to load 'sys.scm':

ice-9/boot-9.scm:2795:6: In procedure resolve-interface:

ice-9/boot-9.scm:2795:6: no code for module (gnu packages qemu)

... please see details further below. Obviously something is calling

'gnu/packages/qemu.scm' but I don't understand what.

TIA - George

make.log

--------

g1@g1 ~/src/guix$ grep g1@g1 make.log

g1@g1 ~/src/guix$ guix environment -e "(@ (gnu packages package-management) guix)" -M 4 -c 4

g1@g1 ~/src/guix [env]$ git fetch

g1@g1 ~/src/guix [env]$ git pull

g1@g1 ~/src/guix [env]$ git status

g1@g1 ~/src/guix [env]$ rm -fr /home/g1/.cache/guile/ccache/*

g1@g1 ~/src/guix [env]$ make clean-go

g1@g1 ~/src/guix [env]$ ./bootstrap

g1@g1 ~/src/guix [env]$ ./configure --localstatedir=/var

g1@g1 ~/src/guix [env]$ make -j 10 check

g1@g1 ~/src/guix [env]$ ln -f -s -T ~/src/guix/ ~/.config/guix/latest

g1@g1 ~/src/guix [env]$ sudo ln -f -s -T ~/src/guix/ /root/.config/guix/latest

g1@g1 ~/src/guix [env]$ git status

g1@g1 ~/src/guix [env]$ git remote -vv

g1@g1 ~/src/guix [env]$ git branch -av | grep \*

g1@g1 ~/src/guix [env]$ exit

g1@g1 ~/src/guix$ exit

g1@g1 ~/src/guix$

root@g1 ~/con/15# guix system --cores=4 --max-jobs=4 -K --on-error=debug build sys.scm

guix system: error: failed to load 'sys.scm':

ice-9/boot-9.scm:2795:6: In procedure resolve-interface:

ice-9/boot-9.scm:2795:6: no code for module (gnu packages qemu)

entering debugger; type ',bt' for a backtrace

GNU Guile 2.2.2

Copyright (C) 1995-2017 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.

This program is free software, and you are welcome to redistribute it

under certain conditions; type `,show c' for details.

Enter `,help' for help.

scheme@(#{ g440}#)> ,q

root@g1 ~/con/15# which guix

/run/current-system/profile/bin/guix

root@g1 ~/con/15# stat ~/.config/guix/latest | grep File:

File: /root/.config/guix/latest -> /home/g1/src/guix/

root@g1 ~/con/15#

root@g1 ~/con/15# git -C ~/.config/guix/latest status

On branch o-master

Your branch is up-to-date with 'origin/master'.

nothing to commit, working tree clean

root@g1 ~/con/15# git -C ~/.config/guix/latest remote -vv

origin git://git.savannah.gnu.org/guix.git (fetch)

origin git://git.savannah.gnu.org/guix.git (push)

root@g1 ~/con/15# git -C ~/.config/guix/latest log -n 1 --oneline

46dea1241 (HEAD -> o-master, origin/master, origin/HEAD) gnu: icedtea: Update to 3.6.0 [security fixes].

root@g1 ~/con/15# exit

exit

Process shell finished

On Sat, Nov 04, 2017 at 07:50:10PM -0400, myglc2 wrote:

was there any mention at the end of 'make clean-go' about there being

stray *go files left?

Can you post your sys.scm? It sounds like you might have a references to

(gnu packages qemu) listed there.

--

Efraim Flashner <efraim@flashner.co.il> ????? ?????

GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351

Confidentiality cannot be guaranteed on emails sent or received unencrypted

On 11/05/2017 at 19:46 Efraim Flashner writes:

[...]

[...]

Yes Efraim, that was it. Actually, Leo mentioned that qemu had moved

(above) but I failed to realize the implication for the config file.

Many thanks! - George

My system recently broke when I did an upgrade. I reported what I

thought was a bug (bug#29072) but it turned out that, because qemu

package code had been moved, my system configuration had become broken

;-(

Confronted with my situation, helpful developers said "The package code

was moved in commit xxx" (Leo) and "maybe you have a mistake in your

config (Efraim)."

Once I understood what had happened I wondered, "Gee, I have been using

guix for 18 months so why didn't I figure this out myself." ;-)

But a less committed user might say, "Wow, Guix breaks at random, error

messages are hard to understand, and support is difficult." :-(

ISTM this raises issues and questions about Guix configuration

usability:

Guix config errors are reported as raw scheme errors which are not

user-friendly, except, perhaps, to guile users ;-) Could we improve this

situation by adding config troubleshooting guidance to the doc?

Guix config errors consume meaningful amounts of user and support

effort. I say this because a) it took quite a few iterations to figure

out what was wrong in my situation, and b) google search for '"no code

for module" guix' finds 613 hits, which will no doubt grow linearly with

number of Guix users unless something is done. So I wonder, could an

error handler that translates into more user-friendly terms reduce user

frustration, increase the rate of user self help, reduce support load,

and effectively pay for itself?

Are the current Guix config errors usable by the average GNU/Linux

distribution user? If not, don't they need to be improved before we call

it 1.0?

Does this mean that package code must not be moved after 1.0?

Finally: Should I close bug#29072? ;-)

On Mon, Nov 06, 2017 at 03:12:11PM -0500, myglc2 wrote:

I'm sorry that my comment was not enough on its own!

Good point.

Indeed.

Yes, we do try to add helpful error messages, although obviously there

is a lot more work to be done.

As far as I can tell, the issue was related to the fact that you are

using Guix by building it from source and re-using the same build

directory, which may contain stale compiled .go files. In this case,

there was a leftover qemu.go, which shadowed the correct file,

virtualization.go.

This is a useful development technique but not how Guix is supposed to

be deployed and updated. `guix pull && guix package --upgrade` is still

what we recommend and support.

If you want to deploy Guix by building it "by hand", I recommend using a

fresh Git checkout and directory each time you build it. That way, you

can be sure to avoid this class of error (stale module references in

leftover .go files), which is well-known to the seasoned Guix developers

but totally confounding for everyone else.

That would be awesome!

Based on how much time it's possible to spend on IRC helping people, I'd

say there is lots of room for improvement in this area.

A couple thoughts... it would be nice if the GuixSD configuration

example templates used a filename agnostic method of resolving module

imports. I'm not a strong enough Schemer to evaluate the situation or

suggest a solution, but I think that the filenames should not be

relevant at that level. Perhaps one could use

'specification->package+output',

as demonstrated in the documentation of package manifests:

The problem of the missing QEMU patch is resolved. The broader issue of

confusing error messages could be continued here, or elsewhere. It's up

to you :)

Please note: these replies separated by topics in an effort to make the

threads more topical ...

On 11/06/2017 at 22:16 Leo Famulari writes:

Hey Leo,

Please understand that don't mean this as a complaint your reply, which

was helpful and I was very happy to receive.

I am just trying to step back and think about the bigger picture.

Please note: these replies are separated by topics in an effort to make the

threads more topical ...

On 11/06/2017 at 17:16 Leo Famulari writes:

[...]

I didn't mean this point critically. Rather as a statement of fact. When

I said ...

... I was thinking something like ...

vvvvvvvvvvvvvvvvvv

Troubleshooting your config file:

If you get an error like:

ice-9/boot-9.scm:[...] no code for module (gnu packages <package name>)

You have either specified a package name that does not exist, or your

(use-package-modules <package module names>) does not contain the name

of a package module that contains the definition of <package name>.

You can determine which, if any, module contains a package definition by

yada yada yada

^^^^^^^^^^^^^^^^^^

... thinking that then there would be a search hit in the doc for 'no

code for module' which might enable some users to understand what they

are doing wrong.

WDYT? - George

On 11/06/2017 at 17:16 Leo Famulari writes:

[...]

There is a parallel solution

Hello,

myglc2 <myglc2@gmail.com> skribis:

It should be noted that you were using a “developer setup”, specifically

running Guix from a checkout with ./pre-inst-env and all.

The issue with the stale module wouldn’t happen with “guix pull”, which

is the recommended “user setup.”

While I agree the situation is not ideal, I think we have to admit that

developers can always shoot themselves in the foot, and that was one way

of doing it. ;-)

Thoughts?

Ludo’.

tags 29072 notabug

close 29072