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

myglc2 wrote on 30 Oct 2017 21:34

Recipients:(address . bug-guix@gnu.org)

Message-ID:86fua04bpb.fsf@gmail.com

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.scmguix system: error: qemu-CVE-2017-7493.patch: patch not found
VERSION INFO:
root@g1 ~/con/15# guix --versionguix (GNU Guix) 0.13.0.4202-1f6f4Copyright (C) 2017 the Guix authorsLicense GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.htmlThis 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 describev0.13.0-4202-g1f6f4c40c
root@g1 ~/con/15# git -C ~/.config/guix/latest log -n 1 --oneline1f6f4c40c (HEAD -> o-master, origin/master, origin/HEAD) gnu: Add r-tgconfig.
root@g1 ~/con/15# git -C /home/g1/src/guix branch -av | grep '*'* o-master 1f6f4c40c gnu: Add r-tgconfig.
SYS CONFIG:

Attachment: sys.scm

Leo Famulari wrote on 31 Oct 2017 01:31

Recipients:(name . myglc2)(address . myglc2@gmail.com)(address . 29072@debbugs.gnu.org)

Message-ID:20171031003153.GA24788@jasmine.lan

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

Toggle quote (5 lines)

> 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

What about `git status`? Is the worktree in a consistent state? Thispatch file was removed in August 2017 [0] and nothing should refer to itanymore.
[0] commit 2de7d137b3c6f528acb540a6ab3460627f484b0a

myglc2 wrote on 1 Nov 2017 15:40

Recipients:(name . Leo Famulari)(address . leo@famulari.name)(address . 29072@debbugs.gnu.org)

Message-ID:86y3nquko3.fsf@gmail.com

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

Toggle quote (12 lines)> On Mon, Oct 30, 2017 at 04:34:08PM -0400, myglc2 wrote:>> 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>> 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

Thanks Leo.
git status is clean ...
g1@g1 ~/src/guix$ git statusOn branch o-masterYour branch is up-to-date with 'origin/master'.
nothing to commit, working tree cleang1@g1 ~/src/guix$ git remote -vvorigin	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-74Binary 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

Leo Famulari wrote on 1 Nov 2017 16:27

Recipients:(name . myglc2)(address . myglc2@gmail.com)(address . 29072@debbugs.gnu.org)

Message-ID:20171101152708.GA21123@jasmine.lan

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

Toggle quote (2 lines)

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

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

myglc2 wrote on 2 Nov 2017 03:40

Recipients:(name . Leo Famulari)(address . leo@famulari.name)(address . 29072@debbugs.gnu.org)

Message-ID:86shdxv1w0.fsf@gmail.com

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

Toggle quote (5 lines)

> On Wed, Nov 01, 2017 at 10:40:28AM -0400, myglc2 wrote:>> Binary file ./gnu/packages/qemu.go matches >> Try deleting this compiled qemu.go and then try again.

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 4g1@g1 ~/src/guix [env]$ makemake  all-recursivemake[1]: Entering directory '/home/g1/src/guix'Making all in po/guixmake[2]: Entering directory '/home/g1/src/guix/po/guix'make[2]: Leaving directory '/home/g1/src/guix/po/guix'Making all in po/packagesmake[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.gols: cannot access './gnu/packages/qemu.go': No such file or directoryg1@g1 ~/src/guix$ git statusOn branch o-masterYour branch is up-to-date with 'origin/master'.
nothing to commit, working tree cleang1@g1 ~/src/guix$ git branch -vv* o-master 1f6f4c40c [origin/master] gnu: Add r-tgconfig.

Leo Famulari wrote on 2 Nov 2017 03:44

Recipients:(name . myglc2)(address . myglc2@gmail.com)(address . 29072@debbugs.gnu.org)

Message-ID:20171102024440.GA17609@jasmine.lan

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

Toggle quote (15 lines)> On 11/01/2017 at 11:27 Leo Famulari writes:> > > On Wed, Nov 01, 2017 at 10:40:28AM -0400, myglc2 wrote:> >> Binary file ./gnu/packages/qemu.go matches		 > >> > Try deleting this compiled qemu.go and then try again.> > 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.

The 'gnu/packages/qemu.scm' file was removed from Guix in July 2017,with commit 59132b800093e486e4d81aed6b837e9ac76aa86c. The QEMU packageswere moved into 'gnu/packages/virtualization.scm'.
I'm not an Autotools expert, but in cases like this I usually try `makeclean && ./configure --localstatedir=/var && make`. Did you trysomething like that yet?

myglc2 wrote on 5 Nov 2017 00:50

Recipients:(name . Leo Famulari)(address . leo@famulari.name)(address . 29072@debbugs.gnu.org)

Message-ID:86wp35wqml.fsf@gmail.com

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

Toggle quote (24 lines)> On Wed, Nov 01, 2017 at 10:40:47PM -0400, myglc2 wrote:>> On 11/01/2017 at 11:27 Leo Famulari writes:>> >> > On Wed, Nov 01, 2017 at 10:40:28AM -0400, myglc2 wrote:>> >> Binary file ./gnu/packages/qemu.go matches		 >> >>> > Try deleting this compiled qemu.go and then try again.>> >> 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.>> 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?

Thanks Leo.
I did a new git pull and a clean build as you suggested (please see thegrep 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 4g1@g1 ~/src/guix [env]$ git fetchg1@g1 ~/src/guix [env]$ git pullg1@g1 ~/src/guix [env]$ git statusg1@g1 ~/src/guix [env]$ rm -fr /home/g1/.cache/guile/ccache/*g1@g1 ~/src/guix [env]$ make clean-gog1@g1 ~/src/guix [env]$ ./bootstrapg1@g1 ~/src/guix [env]$ ./configure --localstatedir=/varg1@g1 ~/src/guix [env]$ make -j 10 checkg1@g1 ~/src/guix [env]$ ln -f -s -T ~/src/guix/ ~/.config/guix/latestg1@g1 ~/src/guix [env]$ sudo ln -f -s -T ~/src/guix/ /root/.config/guix/latestg1@g1 ~/src/guix [env]$ git statusg1@g1 ~/src/guix [env]$ git remote -vvg1@g1 ~/src/guix [env]$ git branch -av | grep \*g1@g1 ~/src/guix [env]$ exitg1@g1 ~/src/guix$ exitg1@g1 ~/src/guix$

root@g1 ~/con/15# guix system --cores=4 --max-jobs=4 -K --on-error=debug build sys.scmguix 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 backtraceGNU Guile 2.2.2Copyright (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 itunder certain conditions; type `,show c' for details.
Enter `,help' for help.scheme@(#{ g440}#)> ,qroot@g1 ~/con/15# which guix/run/current-system/profile/bin/guixroot@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 statusOn branch o-masterYour branch is up-to-date with 'origin/master'.
nothing to commit, working tree cleanroot@g1 ~/con/15# git -C ~/.config/guix/latest remote -vvorigin	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 --oneline46dea1241 (HEAD -> o-master, origin/master, origin/HEAD) gnu: icedtea: Update to 3.6.0 [security fixes].root@g1 ~/con/15# exitexit
Process shell finished

Efraim Flashner wrote on 5 Nov 2017 18:46

Recipients:(name . myglc2)(address . myglc2@gmail.com)

Message-ID:20171105174634.GA1815@macbook41

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

Toggle quote (52 lines)> On 11/01/2017 at 22:44 Leo Famulari writes:> > > On Wed, Nov 01, 2017 at 10:40:47PM -0400, myglc2 wrote:> >> On 11/01/2017 at 11:27 Leo Famulari writes:> >> > >> > On Wed, Nov 01, 2017 at 10:40:28AM -0400, myglc2 wrote:> >> >> Binary file ./gnu/packages/qemu.go matches		 > >> >> >> > Try deleting this compiled qemu.go and then try again.> >> > >> 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.> >> > 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?> > 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

was there any mention at the end of 'make clean-go' about there beingstray *go files left?

Toggle quote (19 lines)> 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)> 

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 8351Confidentiality cannot be guaranteed on emails sent or received unencrypted

myglc2 wrote on 6 Nov 2017 02:15

Recipients:(name . Efraim Flashner)(address . efraim@flashner.co.il)

Message-ID:86tvy82on6.fsf@gmail.com

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

Toggle quote (6 lines)> On Sat, Nov 04, 2017 at 07:50:10PM -0400, myglc2 wrote:>> On 11/01/2017 at 22:44 Leo Famulari writes:>> >> > On Wed, Nov 01, 2017 at 10:40:47PM -0400, myglc2 wrote:>> >> On 11/01/2017 at 11:27 Leo Famulari writes:>> >> 

[...]

Toggle quote (4 lines)

>> > 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'.>> >

[...]

Toggle quote (10 lines)>> >> 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)>> >> Can you post your sys.scm? It sounds like you might have a references to> (gnu packages qemu) listed there.

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

myglc2 wrote on 6 Nov 2017 21:12

The usability of Guix configurations

Recipients:(name . Guix-devel)(address . guix-devel@gnu.org)

Message-ID:868tfjw4is.fsf@gmail.com

My system recently broke when I did an upgrade. I reported what Ithought was a bug (bug#29072) but it turned out that, because qemupackage code had been moved, my system configuration had become broken;-(
Confronted with my situation, helpful developers said "The package codewas moved in commit xxx" (Leo) and "maybe you have a mistake in yourconfig (Efraim)."
Once I understood what had happened I wondered, "Gee, I have been usingguix for 18 months so why didn't I figure this out myself." ;-)
But a less committed user might say, "Wow, Guix breaks at random, errormessages are hard to understand, and support is difficult." :-(
ISTM this raises issues and questions about Guix configurationusability:
Guix config errors are reported as raw scheme errors which are notuser-friendly, except, perhaps, to guile users ;-) Could we improve thissituation by adding config troubleshooting guidance to the doc?
Guix config errors consume meaningful amounts of user and supporteffort. I say this because a) it took quite a few iterations to figureout what was wrong in my situation, and b) google search for '"no codefor module" guix' finds 613 hits, which will no doubt grow linearly withnumber of Guix users unless something is done. So I wonder, could anerror handler that translates into more user-friendly terms reduce userfrustration, 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/Linuxdistribution user? If not, don't they need to be improved before we callit 1.0? Does this mean that package code must not be moved after 1.0?
Finally: Should I close bug#29072? ;-)

Leo Famulari wrote on 6 Nov 2017 23:16

Recipients:(name . myglc2)(address . myglc2@gmail.com)

Message-ID:20171106221621.GA2534@jasmine.lan

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

Toggle quote (9 lines)

> 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)."

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

Toggle quote (6 lines)

> 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." :-(

Good point.

Toggle quote (3 lines)

> ISTM this raises issues and questions about Guix configuration> usability:

Indeed.

Toggle quote (4 lines)

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

Yes, we do try to add helpful error messages, although obviously thereis a lot more work to be done.
As far as I can tell, the issue was related to the fact that you areusing Guix by building it from source and re-using the same builddirectory, 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 tobe deployed and updated. `guix pull && guix package --upgrade` is stillwhat we recommend and support.
If you want to deploy Guix by building it "by hand", I recommend using afresh Git checkout and directory each time you build it. That way, youcan be sure to avoid this class of error (stale module references inleftover .go files), which is well-known to the seasoned Guix developersbut totally confounding for everyone else.

Toggle quote (9 lines)

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

That would be awesome!

Toggle quote (4 lines)

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

Based on how much time it's possible to spend on IRC helping people, I'dsay there is lots of room for improvement in this area.

Toggle quote (2 lines)

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

A couple thoughts... it would be nice if the GuixSD configurationexample templates used a filename agnostic method of resolving moduleimports. I'm not a strong enough Schemer to evaluate the situation orsuggest a solution, but I think that the filenames should not berelevant at that level. Perhaps one could use'specification->package+output',as demonstrated in the documentation of package manifests:
https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-package.html

Toggle quote (2 lines)

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

The problem of the missing QEMU patch is resolved. The broader issue ofconfusing error messages could be continued here, or elsewhere. It's upto you :)

myglc2 wrote on 7 Nov 2017 00:26

Recipients:(name . Leo Famulari)(address . leo@famulari.name)

Message-ID:86wp330z19.fsf@gmail.com

Please note: these replies separated by topics in an effort to make thethreads more topical ...
On 11/06/2017 at 22:16 Leo Famulari writes:

Toggle quote (12 lines)> On Mon, Nov 06, 2017 at 03:12:11PM -0500, myglc2 wrote:>> 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).">> I'm sorry that my comment was not enough on its own!

Hey Leo,
Please understand that don't mean this as a complaint your reply, whichwas helpful and I was very happy to receive.
I am just trying to step back and think about the bigger picture.

myglc2 wrote on 7 Nov 2017 02:56

Recipients:(name . Leo Famulari)(address . leo@famulari.name)

Message-ID:86o9oex34v.fsf@gmail.com

Please note: these replies are separated by topics in an effort to make thethreads more topical ...
On 11/06/2017 at 17:16 Leo Famulari writes:

Toggle quote (1 lines)

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

[...]

Toggle quote (7 lines)

>> 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?>> Yes, we do try to add helpful error messages, although obviously there> is a lot more work to be done.

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

Toggle quote (3 lines)

>> Could we improve this situation by adding config troubleshooting>> guidance to the doc?

... 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 nameof a package module that contains the definition of <package name>.
You can determine which, if any, module contains a package definition byyada yada yada
^^^^^^^^^^^^^^^^^^
... thinking that then there would be a search hit in the doc for 'nocode for module' which might enable some users to understand what theyare doing wrong.
WDYT? - George

myglc2 wrote on 7 Nov 2017 03:30

Recipients:(name . Leo Famulari)(address . leo@famulari.name)

Message-ID:86h8u6x1ke.fsf@gmail.com

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

Toggle quote (31 lines)> On Mon, Nov 06, 2017 at 03:12:11PM -0500, myglc2 wrote:>> 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).">> I'm sorry that my comment was not enough on its own!>>> 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."  :-(>> Good point.>>> ISTM this raises issues and questions about Guix configuration>> usability:>> Indeed.>>> 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?>> Yes, we do try to add helpful error messages, although obviously there> is a lot more work to be done.

[...]

Toggle quote (31 lines)>>> 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?>> That would be awesome!>>> 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?>> 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.>>> Does this mean that package code must not be moved after 1.0?>> 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:>> https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-package.html>

There is a parallel solution

Toggle quote (5 lines)>> Finally: Should I close bug#29072? ;-)>> 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 :)

Ludovic Courtès wrote on 7 Nov 2017 11:23

Recipients:(name . myglc2)(address . myglc2@gmail.com)

Message-ID:87po8u9ylu.fsf@gnu.org

Hello,
myglc2 <myglc2@gmail.com> skribis:

Toggle quote (5 lines)

It should be noted that you were using a “developer setup”, specificallyrunning Guix from a checkout with ./pre-inst-env and all.
The issue with the stale module wouldn’t happen with “guix pull”, whichis the recommended “user setup.”
While I agree the situation is not ideal, I think we have to admit thatdevelopers can always shoot themselves in the foot, and that was one wayof doing it. ;-)
Thoughts?
Ludo’.

myglc2 wrote on 7 Nov 2017 19:28

control message for bug #29072

Recipients:(address . control@debbugs.gnu.org)

Message-ID:86zi7yrlip.fsf@gmail.com

tags 29072 notabugclose 29072

Your comment

This issue is archived.

To comment on this conversation send email to 29072@debbugs.gnu.org

is:open	open issues
is:done	closed issues
submitter:<who>	search issue submitter
author:<who>	search by message author
date:yesterday..now	search by issue date
mdate:3m..2d	search by message date