[PATCH] build-self: Try printing nicer error messages.

Hi guix,

This patch improves the error message generated by "guix time-machine"

and presumably "guix pull" as well when the guix derivation fails to

compute.

Before: something like https://issues.guix.gnu.org/50232.

After: something like

[...]

substitute: lijst van substitutes van ?[...]? aan het bijwerken... 100.0%

/gnu/store/4yx3vms0rfpzd1430za3g4pa6jvjsfw9-nowhere.tar.bz2.drv bouwen...

/error: build of `/gnu/store/6s0cmkfa4hq7d9w8g08mv2rhq0cr7wqc-subversion-1.14.1.drv' failed

guix time-machine: fout: You found a bug: the program '/gnu/store/j07lizpjf7v65shdgxyxddz171g6vjvx-compute-guix-derivation'

failed to compute the derivation for Guix (version: "9fc551e089c25f510f918a2c52917ba4e842f1c3"; system: "x86_64-linux";

host version: "75a3413b4e5c1f7443eb944a36ff364f4c4085f4"; pull-version: 1).

Please report it by email to <bug-guix@gnu.org

To test, apply the patch, and introduce an error in the hash of subversion:

;;; (gnu packages version-control)

(define-public subversion

(package

(name "subversion")

(version "1.14.1")

(source (origin

(method url-fetch)

;; Oops!

(uri "http://localhost/nowhere.tar.bz2")

#;(string-append "mirror://apache/subversion/"

"subversion-" version ".tar.bz2")

(sha256

(base32

;; Oops! 1->0

#;"1ag1hvcm9q92kgalzbbgcsq9clxnzmbj9nciz9lmabjx4lyajp9c"

"0ag1hvcm9q92kgalzbbgcsq9clxnzmbj9nciz9lmabjx4lyajp9c"))))

(build-system gnu-build-system)

[...]

and commit that mistake. Then run

guix time-machine --branch=master --url=$PWD --disable-authentication

Repeat without the error in subversion.

Greetings,

Maxime

Hi,

Maxime Devos <maximedevos@telenet.be> skribis:

I sympathize with the goal but unsure about the implementation.

To me, compute-guix-derivation should remain as simple as possible and

it shouldn't take care of UI concerns. Having said that, I don't know

how to address the problem above while sticking to this principle.

WDYT?

Ludo'.

*Something* should take care of UI concerns, and 'build-program' is in

a good position to do so. I don't really see another way to do it

(except by serialising the exception and letting the Guix that is doing

the pulling report it, but that's even more fragile). Where else could

the UI bits be done?

Additionally, while importing (guix ui) may seem rather daunting,

the error handling bits are only run when there's actually an error to

handle, so I expect it to be fine in practice --- it seems only

possible for this to break "guix pull" if "guix pull" would have failed

anyway.

I have one concern though: (guix ui) used with-exception-handler which

is new-ish with Guile 3.0 IIUC. Do we need to support pulling from a

Guix of version Guile <2.2? If so, a little compatibility code may

be necessary -- e.g., not doing the 'with-error-handling' when guile-

version=2.2.

I think the little bit of extra non-simplicity is worth the clarity

(not very much, but still useful) it brings to people on bug-guix and

people reporting the ‘guix pull: error: You found a bug: ...’ issues --

-- see the long list at

https://issues.guix.gnu.org/search?query=%22you+found+a+bug%22, and

compare it with the two extra lines of code.

In other terms, if we do a risk-benefit analysis, there is some risk,

but due to the large number of reports there would be much benefit.

And even though there is some risk (see e.g. the Guile 2.2/3.0 thing

above), whenever such an accident happens, it could quickly addressed

by pushing a new commit.

Greetings,

Maxime.

Hi,

On ven., 24 sept. 2021 at 13:59, Ludovic Courtès <ludo@gnu.org> wrote:

On one hand, I agree that the import of '(guix ui)' here feels "hum, it

seems an incorrect location", but...

...on the other hand, where 'build-program' is called, i.e, 'build,

there is:

which is UI, no? Idem for the message "You found a bug".

Well, I am unsure about the addition of '(guix ui)' and by

'with-error-handlng' in 'build-program'. However, maybe the exception

handling could happen in the 'build' part. WDYT?

Cheers,

simon

zimoun schreef op di 08-03-2022 om 20:22 [+0100]:

Keep in mind that the result of the '(build-program ...)' is a program

that will be invoked as a separate program. Exceptions do not

propagate accross process boundaries, so 'build' cannot catch the

exceptions happening inside, so 'build' cannot catch the exceptions

happening inside 'build-program'. Hence, the error handling bits need

to be inside the 'compute-guix-derivation'.

Greetings,

Maxime.

To make sure the patch doesn't break "guix pull", I've begun testing

using "guix time-machine" to go to an older version of Guix and then go

to the latest version of Guix (with the patch applied).

Older commits tested so far:

* 1.3.0

# 1.3.0 --> master + the patch applied

guix time-machine --url=$PWD --commit=a0178d34f582b50e9bdbb0403943129ae5b560ff -- time-machine --url=$PWD --commit=47ffd21fa177e300df5346f275da1759870540b3 --disable-authentication -- describe

(succeeds!)

1.3.0 is not a good test though because it's relatively recent, I'll

try some older versions as well.

Maxime Devos schreef op za 19-03-2022 om 10:13 [+0100]:

I tried from 1.1.0, seems like it fails because guile@2.2 does not have

with-exception-handler:

Backtrace:

5 (primitive-load "/gnu/store/jdf2z2vl4gc6yzl5gglixd5jpflcgikm-compute-guix-derivation")

In ice-9/eval.scm:

155:9 4 (_ #(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#<directory (guile-u?> ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))

159:9 3 (_ #(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#(#<directory (guile-u?> ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))

In ice-9/boot-9.scm:

152:2 2 (with-fluid* _ _ _)

152:2 1 (with-fluid* _ _ _)

In srfi/srfi-34.scm:

38:0 0 (with-exception-handler #<procedure 7f3a57d078b8 at ./guix/ui.scm:694:2 (c)> #<procedure 7f3a582457c0 ?> ?)

srfi/srfi-34.scm:38:0: In procedure with-exception-handler:

Wrong number of arguments to #<procedure with-exception-handler (handler thunk)>

Computing Guix derivation for 'x86_64-linux'... guix time-machine: error: You found a bug: the program '/gnu/store/jdf2z2vl4gc6yzl5gglixd5jpflcgikm-compute-guix-derivation'

failed to compute the derivation for Guix (version: "aac29b952e558e20ac97a95713b15ac453e59742"; system: "x86_64-linux";

host version: "1.1.0rc2-1.9d0d27f"; pull-version: 1).

Please report the COMPLETE output above by email to <bug-guix@gnu.org>.

I guess the simplest solution is to only do 'with-error-handler' wrapping

when guile-version>=3.0 ...

Greetings,

Maxime.

Maxime Devos schreef op di 22-03-2022 om 21:46 [+0100]:

Actually, it does, but it does not support #:unwind?.

Maxime Devos schreef op di 22-03-2022 om 21:46 [+0100]:

Actually, it looks like it exists since 2.0, but #:unwind is new.

The revised patch allows time travelling from v1.1.0 to

(master + patch), by not always setting #:unwind?. Next step: test

some older versions (v1.0.0, v0.2?, ...?)?

Greetings,

Maxime.

Maxime Devos schreef op di 22-03-2022 om 23:24 [+0100]:

I think the current patch is good enough as-is. WDYT?

Greetings,

Maxime.

Seems required for effectively debugging #55279.

block 55339 with 50238

block 55279 with 50238

thanks

Would presumably have improved the error message at

and

block 56466 with 50238

thanks

This error message isn't informative, maybe the patch at

https://issues.guix.gnu.org/50238would give some context, though not really sure, it was written with other kind of errors in mind.

Greetings,

Maxime.

block 56836 with 50238

thanks

On 30-07-2022 02:52, DDC via Bug reports for GNU Guix wrote:

Maybe try tab-expanding

/gnu/store/ljaz2ql0pwxdlxi5as32vp7j8vnh9fd6-guile-ssh- and doing "guix

build" on the result to get an useful error message.

This backtrace is almost useless, the guile-ssh is rather hidden and

might not even be the actual issue.  If

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=50238was applied, we

would probably have more useful information.

Greetings,

Maxime.

This (reviewed since 5 months, at least the previous versions) patch

would be helpful for debugging

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=56836 and many other

"guix pull: You found a bug" reports.

Greetings,

Maxime.

block 57177 with 50238

thanks

On 13-08-2022 17:42, Philip Kaludercic wrote:

I've a patch at https://issues.guix.gnu.org/50238 that might make the

error message more useful.

As-is, we don't really have any information for debugging.

Greetings,

Maxime

Would be useful for debugging https://issues.guix.gnu.org/57177.

Greetings,

Maxime.

block 57411 with 50238

thanks

On 25-08-2022 19:50, Jessica Tallon wrote:

This backtrace does not appear to have useful information for debugging

the issue, perhaps https://issues.guix.gnu.org/50238could help by using

the with-error-handling to format the error messages properly.

As mentioned previously in another thread, the name is Guix, not GUIX.

GUIX is a Microsoft thing.

To test for out-of-memory problems, you could dmesg (ideally Guix would

hook into cgroups or whatever to be notified about out-of-memory and

properly indicate the error message).

&nar-error sounds more like a substitute-related (because 'nar) network

error to me though.

Greetings,

Maxime.