[-- Attachment #1: Type: text/plain, Size: 512 bytes --] Hi, Quite often when packaging and iterating, the daemon produces backtraces on errors, which could be very useful to understand what's wrong, but unfortunately the output is truncated to some 80-ish column. Which, more often than not, truncates the interesting part because the store names tend to be long ("/gnu/store/longhashmumblemumble..."). Is there a way to either enlarge the backtrace width or to reproduce the untruncated backtrace to a log? -- Pierre Neidhardt https://ambrevar.xyz/ [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 487 bytes --]
Hi Pierre,
> Quite often when packaging and iterating, the daemon produces backtraces
> on errors, which could be very useful to understand what's wrong, but
> unfortunately the output is truncated to some 80-ish column.
Set the COLUMNS environment variable to some large value.
--
Ricardo
[-- Attachment #1: Type: text/plain, Size: 472 bytes --] Ricardo Wurmus <rekado@elephly.net> writes: > Set the COLUMNS environment variable to some large value. Hmm... I use Eshell (in Emacs), in which the COLUMNS env variable is automatically set to the Emacs window width. For instance right now I have 190. And the daemon still displays truncated message (i.e. way shorter than 190). Is there something else to do then? I'll also try with a (more) regular shell. -- Pierre Neidhardt https://ambrevar.xyz/ [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 487 bytes --]
On 2019-07-15 14:47, Ricardo Wurmus wrote:
>
> Hi Pierre,
>
>> Quite often when packaging and iterating, the daemon produces backtraces
>> on errors, which could be very useful to understand what's wrong, but
>> unfortunately the output is truncated to some 80-ish column.
>
> Set the COLUMNS environment variable to some large value.
This should be added to the manual I think.
--
Cheers
Swedebugia
> Hi Pierre,
>
> > Quite often when packaging and iterating, the daemon produces backtraces
> > on errors, which could be very useful to understand what's wrong, but
> > unfortunately the output is truncated to some 80-ish column.
>
> Set the COLUMNS environment variable to some large value.
>
> ------------------------------------------------------------
>
> Ricardo
Can't it just not truncate them? This is a very brutish way of condensing log output and breaks some workflows. I for one often use Acme because I can just right click on paths in it and it opens them with the plumber. If a path is split across lines, Acme can't pick that up.
P <pronaip@protonmail.com> writes: >> Hi Pierre, >> >> > Quite often when packaging and iterating, the daemon produces backtraces >> > on errors, which could be very useful to understand what's wrong, but >> > unfortunately the output is truncated to some 80-ish column. >> >> Set the COLUMNS environment variable to some large value. >> > Can't it just not truncate them? This is a very brutish way of > condensing log output and breaks some workflows. I also don’t like it, but that’s what Guile does. (It’s not Guix that truncates the output.) > I for one often use > Acme because I can just right click on paths in it and it opens them > with the plumber. If a path is split across lines, Acme can't pick > that up. Same here with Emacs (M-x ffap). -- Ricardo
> On 15. Jul 2019, at 17:40, Ricardo Wurmus <rekado@elephly.net> wrote:
>
>
> P <pronaip@protonmail.com> writes:
>
>>> Hi Pierre,
>>>
>>>> Quite often when packaging and iterating, the daemon produces backtraces
>>>> on errors, which could be very useful to understand what's wrong, but
>>>> unfortunately the output is truncated to some 80-ish column.
>>>
>>> Set the COLUMNS environment variable to some large value.
>>>
>> Can't it just not truncate them? This is a very brutish way of
>> condensing log output and breaks some workflows.
>
> I also don’t like it, but that’s what Guile does. (It’s not Guix that
> truncates the output.)
It’s open source, though, isn’t it? Let’s fix it!
On 15. Jul 2019, at 20:38, Robert Vollmert <rob@vllmrt.net> wrote: > >> On 15. Jul 2019, at 17:40, Ricardo Wurmus <rekado@elephly.net> wrote: >> >> P <pronaip@protonmail.com> writes: >> >>>> Hi Pierre, >>>> >>>>> Quite often when packaging and iterating, the daemon produces backtraces >>>>> on errors, which could be very useful to understand what's wrong, but >>>>> unfortunately the output is truncated to some 80-ish column. >>>> >>>> Set the COLUMNS environment variable to some large value. >>>> >>> Can't it just not truncate them? This is a very brutish way of >>> condensing log output and breaks some workflows. >> >> I also don’t like it, but that’s what Guile does. (It’s not Guix that >> truncates the output.) > > It’s open source, though, isn’t it? Let’s fix it! I sent a patch against guile: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=36677 If you’d like to try it in guix, here’s a patch to apply the patch to guile-next, though I guess to make it apply to the build daemon you’d have to apply it to gnu/packages/guile.scm:guile/fixed. Happy to submit a patch to do that.
Hello Pierre,
Pierre Neidhardt <mail@ambrevar.xyz> writes:
> Ricardo Wurmus <rekado@elephly.net> writes:
>
>> Set the COLUMNS environment variable to some large value.
>
> Hmm... I use Eshell (in Emacs), in which the COLUMNS env variable is automatically
> set to the Emacs window width. For instance right now I have 190. And
> the daemon still displays truncated message (i.e. way shorter than 190).
>
> Is there something else to do then?
> I'll also try with a (more) regular shell.
The daemon is run as 'root' on a Guix system, so you need to set this
environment variable for the 'root' user session. As an example, I set
this in my /root/.bash_profile file:
--8<---------------cut here---------------start------------->8---
export COLUMNS=160 # wider Guile backtraces
--8<---------------cut here---------------end--------------->8---
HTH!
Maxim
[-- Attachment #1: Type: text/plain, Size: 84 bytes --] Will try that, thanks for the tip! -- Pierre Neidhardt https://ambrevar.xyz/ [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 487 bytes --]
[-- Attachment #1: Type: text/plain, Size: 144 bytes --] This has stopped working for me a while ago. Could it be that Guile's behaviour changed here? -- Pierre Neidhardt https://ambrevar.xyz/ [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 487 bytes --]
Pierre Neidhardt <mail@ambrevar.xyz> writes:
> This has stopped working for me a while ago.
> Could it be that Guile's behaviour changed here?
Is this increase a function of Guix, or of Guile? This is a constant
source of pain for me as I package things since very useful information
is often elided due to this limit (e.g. symlink failed during a build
between store item `/gnu/store/xyz`...` and... ???).
I would be very happy if the limit were increased at the daemon level!
--
Katherine
[-- Attachment #1: Type: text/plain, Size: 170 bytes --] It's Guile, not Guix. But I suppose we could start the Guix daemon while making sure the backtraces are not truncated. -- Pierre Neidhardt https://ambrevar.xyz/ [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 487 bytes --]
Hi,
Pierre Neidhardt <mail@ambrevar.xyz> skribis:
> This has stopped working for me a while ago.
What stopped working exactly?
Users are not supposed to see backtraces coming from the daemon or its
helpers (‘guix substitute’, ‘guix offload’, etc.).
Thanks,
Ludo’.
[-- Attachment #1: Type: text/plain, Size: 183 bytes --] The COLUMN environment option (set in root's .bash_profile) does not extend the print width of backtraces when running `guix build`. -- Pierre Neidhardt https://ambrevar.xyz/ [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 487 bytes --]
[-- Attachment #1: Type: text/plain, Size: 778 bytes --] Hullo, Ludovic Courtès 写道: > Users are not supposed to see backtraces coming from the daemon > or its > helpers (‘guix substitute’, ‘guix offload’, etc.). Put that in the EULA then, because those naughty users insist on doing so regularly :-) It's not clear what you're arguing for. Pierre Neidhardt 写道: > The COLUMN environment option (set in root's .bash_profile) does > not > extend the print width of backtraces when running `guix build`. Nor should it[0]. What you describe sounds like a convenient bug being fixed(?). Was this on Guix System or a foreign distribution? Yours in curiosity and frustration, T G-R [0]: https://www.gnu.org/software/bash/manual/html_node/Bash-Startup-Files.html#Bash-Startup-Files [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 227 bytes --]
[-- Attachment #1: Type: text/plain, Size: 257 bytes --] Tobias Geerinckx-Rice <me@tobias.gr> writes: > Nor should it[0]. What you describe sounds like a convenient bug > being fixed(?). Was this on Guix System or a foreign > distribution? Guix System. -- Pierre Neidhardt https://ambrevar.xyz/ [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 487 bytes --]
[-- Attachment #1: Type: text/plain, Size: 279 bytes --] Ludovic Courtès <ludo@gnu.org> writes: > Users are not supposed to see backtraces coming from the daemon or its > helpers (‘guix substitute’, ‘guix offload’, etc.). How are we supposed to debug Guix daemon errors? -- Pierre Neidhardt https://ambrevar.xyz/ [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 487 bytes --]
[-- Attachment #1: Type: text/plain, Size: 494 bytes --] Pierre Neidhardt <mail@ambrevar.xyz> writes: > Ludovic Courtès <ludo@gnu.org> writes: > >> Users are not supposed to see backtraces coming from the daemon or its >> helpers (‘guix substitute’, ‘guix offload’, etc.). > > How are we supposed to debug Guix daemon errors? You can run it directly from a shell, and/or attach a debugger. I agree that if a failure happens on the daemon level, Guix should print an actionable error message instead of a confusing back trace. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 487 bytes --]
Hi,
Pierre Neidhardt <mail@ambrevar.xyz> skribis:
> The COLUMN environment option (set in root's .bash_profile) does not
> extend the print width of backtraces when running `guix build`.
I understand, but which backtraces are we talking about?
COLUMNS only helps if you wish to debug ‘guix build’ itself. It cannot
influence Guile processes launched by the daemon, such as those that
build derivations and the helper processes (‘guix substitute’, etc.).
In most cases, we’re interested in backtraces coming from Guile
processes that build derivations. For that, we need to set COLUMNS in
the #:env-vars argument of ‘gexp->derivation’ or similar.
HTH!
Ludo’.
[-- Attachment #1: Type: text/plain, Size: 912 bytes --] Ludovic Courtès <ludo@gnu.org> writes: > Hi, > > Pierre Neidhardt <mail@ambrevar.xyz> skribis: > >> The COLUMN environment option (set in root's .bash_profile) does not >> extend the print width of backtraces when running `guix build`. > > I understand, but which backtraces are we talking about? > > COLUMNS only helps if you wish to debug ‘guix build’ itself. It cannot > influence Guile processes launched by the daemon, such as those that > build derivations and the helper processes (‘guix substitute’, etc.). I'm confused. `guix build' uses the daemon to build, doesn't it? > In most cases, we’re interested in backtraces coming from Guile > processes that build derivations. For that, we need to set COLUMNS in > the #:env-vars argument of ‘gexp->derivation’ or similar. Can't we do this globally and by default? -- Pierre Neidhardt https://ambrevar.xyz/ [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 487 bytes --]
[-- Attachment #1: Type: text/plain, Size: 219 bytes --] Marius Bakke <marius@gnu.org> writes: > You can run it directly from a shell, and/or attach a debugger. Thanks for the tip. Any idea how to attach Geiser to it? -- Pierre Neidhardt https://ambrevar.xyz/ [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 487 bytes --]
[-- Attachment #1: Type: text/plain, Size: 427 bytes --] Pierre Neidhardt <mail@ambrevar.xyz> writes: > Marius Bakke <marius@gnu.org> writes: > >> You can run it directly from a shell, and/or attach a debugger. > > Thanks for the tip. > > Any idea how to attach Geiser to it? The daemon is a C++ program, so I'm not sure that would work ... If you are trying to increase the trace width within a build expression, you probably just need to (setenv "COLUMNS" "200") in the builder. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 487 bytes --]
[-- Attachment #1: Type: text/plain, Size: 189 bytes --] Marius Bakke <marius@gnu.org> writes: > The daemon is a C++ program, so I'm not sure that would work ... Hahaha, completely forgot :D -- Pierre Neidhardt https://ambrevar.xyz/ [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 487 bytes --]
Marius Bakke <marius@gnu.org> writes: > Pierre Neidhardt <mail@ambrevar.xyz> writes: > >> Marius Bakke <marius@gnu.org> writes: >> >>> You can run it directly from a shell, and/or attach a debugger. >> >> Thanks for the tip. >> >> Any idea how to attach Geiser to it? > > The daemon is a C++ program, so I'm not sure that would work ... > > If you are trying to increase the trace width within a build expression, > you probably just need to (setenv "COLUMNS" "200") in the builder. A daemon built with this change prevents truncation in the Guile builders (without having to modify the Guile builders): diff --git a/nix/libstore/build.cc b/nix/libstore/build.cc index 29266f1dd6..94609e07f5 100644 --- a/nix/libstore/build.cc +++ b/nix/libstore/build.cc @@ -2247,6 +2247,7 @@ void DerivationGoal::runChild() Strings envStrs; foreach (Environment::const_iterator, i, env) envStrs.push_back(rewriteHashes(i->first + "=" + i->second, rewritesToTmp)); + envStrs.push_back("COLUMNS=1024"); /* If we are running in `build-users' mode, then switch to the user we allocated above. Make sure that we drop all root -- Ricardo
[-- Attachment #1: Type: text/plain, Size: 721 bytes --] Ricardo Wurmus <rekado@elephly.net> writes: > diff --git a/nix/libstore/build.cc b/nix/libstore/build.cc > index 29266f1dd6..94609e07f5 100644 > --- a/nix/libstore/build.cc > +++ b/nix/libstore/build.cc > @@ -2247,6 +2247,7 @@ void DerivationGoal::runChild() > Strings envStrs; > foreach (Environment::const_iterator, i, env) > envStrs.push_back(rewriteHashes(i->first + "=" + i->second, rewritesToTmp)); > + envStrs.push_back("COLUMNS=1024"); > > /* If we are running in `build-users' mode, then switch to the > user we allocated above. Make sure that we drop all root What about merging this then? -- Pierre Neidhardt https://ambrevar.xyz/ [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 487 bytes --]
Hi,
Pierre Neidhardt <mail@ambrevar.xyz> skribis:
> Ricardo Wurmus <rekado@elephly.net> writes:
>
>> diff --git a/nix/libstore/build.cc b/nix/libstore/build.cc
>> index 29266f1dd6..94609e07f5 100644
>> --- a/nix/libstore/build.cc
>> +++ b/nix/libstore/build.cc
>> @@ -2247,6 +2247,7 @@ void DerivationGoal::runChild()
>> Strings envStrs;
>> foreach (Environment::const_iterator, i, env)
>> envStrs.push_back(rewriteHashes(i->first + "=" + i->second, rewritesToTmp));
>> + envStrs.push_back("COLUMNS=1024");
>>
>> /* If we are running in `build-users' mode, then switch to the
>> user we allocated above. Make sure that we drop all root
>
> What about merging this then?
This modifies the environment of every single build process, so no.
Environment contents are set in stone, it’s key to reproducibility.
However, what we can do is add COLUMNS to #:env-vars in
‘package-derivation’ on ‘core-updates’ and/or as the default value of
#:env-vars in ‘gexp->derivation’.
HTH!
Ludo’.
[-- Attachment #1: Type: text/plain, Size: 297 bytes --] Ludovic Courtès <ludo@gnu.org> writes: > However, what we can do is add COLUMNS to #:env-vars in > ‘package-derivation’ on ‘core-updates’ and/or as the default value of > #:env-vars in ‘gexp->derivation’. Yes, that'd be great! -- Pierre Neidhardt https://ambrevar.xyz/ [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 487 bytes --]