Re: How can we decrease the cognitive overhead for contributors?

[Csepp]

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

> Hi,
>
> Csepp <raingloom@riseup.net> writes:
>
> [...]
>
>> but as soon as something breaks, you are thrown into the deep end,
>> having to dissect logs, bisect commit ranges, learn strace, gdb (which
>> still doesn't work well on Guix)
>
> Hm?  Why GDB on Guix may be sometimes more challenging than say, on
> Fedora, I only know of one problem, that is related to grafts (see: #48907).
>
> For running binaries wrapped in shell script, I have this 'run-gdb'
> wrapper which reads:
>
> --8<---------------cut here---------------start------------->8---
> #!/usr/bin/env bash
>
> wrapper=$(cat $(which $1))
> shift
> . <(echo "$wrapper" | grep ^export)
> binary=$(echo "$wrapper" | grep ^exec | grep -o -E '/gnu/store[^"]*')
> gdb --args "$binary" "$@"
> --8<---------------cut here---------------end--------------->8---
>
> Hope that helps,

Thanks, it does somewhat, but this is the kind of thing that should be
either packaged in Guix, documented in the cookbook, or preferably fixed
upstream.
At the very least I try to document these helper Guix-specific helper
scripts on the mailing list.  I've asked where it would be appropriate
to put them (cookbook, package, guix module, etc) but I don't think I
got a response.
This is exactly what I mean by core devs having their own scripts that
others don't have an easy way to find and/or access.

The other problem is the difficulty of accessing debug symbols.
One problem is the need to recompile the package you need symbols for,
the other is loading external symbols.  The first is a CI issue as far
as I know: all the debug outputs would take up too much space
(probably).  This may not be fixable in the short term without
additional funding.  The second is purely technical though.
Maybe someone fixed it since the last time I tried to use GDB, but if
not, it should be a priority IMHO.  Guix packages often have bugs and we
should do everything in our power to make fixing future problems easier,
otherwise the project risks the death of a thousand cuts.
This is why I chose to work on Mirage, to get a better understanding of
the importer and cross-compilation tooling.