GNU bug report logs -
#21767
Matching debug symbol and package versions
Previous Next
Reported by: Benno Evers <benno <at> bmevers.de>
Date: Tue, 27 Oct 2015 01:02:02 UTC
Severity: normal
Tags: wontfix
Fixed in version 0.9.0
Done: ludo <at> gnu.org (Ludovic Courtès)
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 21767 in the body.
You can then email your comments to 21767 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-guix <at> gnu.org
:
bug#21767
; Package
guix
.
(Tue, 27 Oct 2015 01:02:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Benno Evers <benno <at> bmevers.de>
:
New bug report received and forwarded. Copy sent to
bug-guix <at> gnu.org
.
(Tue, 27 Oct 2015 01:02:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hi all,
assume I have installed some package
/gnu/store/xxx-daemon-1.0
After a while I notice that it's inexplicably hanging, so I do 'guix
package -i daemon-1.0:debug', attach to the daemon with gdb, and...no
debug symbols can be loaded! Turns out, in the meantime the hash has
changed so i installed
/gnu/store/yyy-daemon-1.0:debug
It seems to me that there is currently no possibility to get the correct
debug symbols. Worse, as civodul mentioned in chat, the package hash is
part of the symbols itself, so I can't even cheat and force gdb manually
to use the symbols for version yyy.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#21767
; Package
guix
.
(Tue, 27 Oct 2015 15:57:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 21767 <at> debbugs.gnu.org (full text, mbox):
Benno Evers <benno <at> bmevers.de> skribis:
> assume I have installed some package
>
> /gnu/store/xxx-daemon-1.0
>
> After a while I notice that it's inexplicably hanging, so I do 'guix
> package -i daemon-1.0:debug', attach to the daemon with gdb, and...no
> debug symbols can be loaded! Turns out, in the meantime the hash has
> changed so i installed
>
> /gnu/store/yyy-daemon-1.0:debug
One thing that could be done, maybe, is for ‘guix package -i’ to try to
infer the right item to install.
That is, when running “guix package -i foo:bar”:
1. If no ‘foo’ is present in the profile, install the latest
‘foo:bar’, as is already the case.
2. If another output of ‘foo’ is already installed, do:
2a. Retrieve the .drv for that item using ‘query-path-info’.
i. If the .drv is present, parse it, and use the outputs
specified therein–i.e., the one that match.
ii. If the .drv is missing, well, install the latest ‘foo:bar’.
The obvious problem is that this all sounds a bit complex, and it’s
unclear whether case (i) would sufficiently frequent to justify this
complexity.
Thoughts?
Thanks,
Ludo’.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#21767
; Package
guix
.
(Tue, 27 Oct 2015 16:42:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 21767 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Tue, 27 Oct 2015 16:56:23 +0100
ludo <at> gnu.org (Ludovic Courtès) wrote:
> Benno Evers <benno <at> bmevers.de> skribis:
>
> > assume I have installed some package
> >
> > /gnu/store/xxx-daemon-1.0
> >
> > After a while I notice that it's inexplicably hanging, so I do 'guix
> > package -i daemon-1.0:debug', attach to the daemon with gdb, and...no
> > debug symbols can be loaded! Turns out, in the meantime the hash has
> > changed so i installed
> >
> > /gnu/store/yyy-daemon-1.0:debug
>
> One thing that could be done, maybe, is for ‘guix package -i’ to try to
> infer the right item to install.
>
> That is, when running “guix package -i foo:bar”:
>
> 1. If no ‘foo’ is present in the profile, install the latest
> ‘foo:bar’, as is already the case.
>
> 2. If another output of ‘foo’ is already installed, do:
>
> 2a. Retrieve the .drv for that item using ‘query-path-info’.
>
> i. If the .drv is present, parse it, and use the outputs
> specified therein–i.e., the one that match.
>
> ii. If the .drv is missing, well, install the latest ‘foo:bar’.
>
> The obvious problem is that this all sounds a bit complex, and it’s
> unclear whether case (i) would sufficiently frequent to justify this
> complexity.
>
> Thoughts?
Less complex would be `guix package -i foo:bar` to effectively be `guix
package -i foo foo:bar`. But then if you really only wanted foo:bar you'd
have to follow up with `guix package -r foo`.
--
Efraim Flashner <efraim <at> 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
[Message part 2 (application/pgp-signature, inline)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#21767
; Package
guix
.
(Tue, 27 Oct 2015 17:24:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 21767 <at> debbugs.gnu.org (full text, mbox):
Efraim Flashner <efraim <at> flashner.co.il> skribis:
> Less complex would be `guix package -i foo:bar` to effectively be `guix
> package -i foo foo:bar`.
But I think that’s not necessarily what you’d expect, nor what you’d want.
Ludo’.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#21767
; Package
guix
.
(Sat, 21 Nov 2015 16:58:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 21767 <at> debbugs.gnu.org (full text, mbox):
Benno Evers <benno <at> bmevers.de> skribis:
> assume I have installed some package
>
> /gnu/store/xxx-daemon-1.0
>
> After a while I notice that it's inexplicably hanging, so I do 'guix
> package -i daemon-1.0:debug', attach to the daemon with gdb, and...no
> debug symbols can be loaded! Turns out, in the meantime the hash has
> changed so i installed
>
> /gnu/store/yyy-daemon-1.0:debug
I realized that I quickly focused on the issue without looking at the
more general context.
The “in the meantime” above means that you had run ‘guix pull’ or
similar, thereby making the previous package recipe unavailable and
leaving you unable to install matching debugging symbols.
On my laptop, I typically run ‘guix package -u’ every time I do ‘guix
pull’, so I cannot find myself in a situation where I’m unable to
install debugging symbols of already installed packages.
This is just to say that the scenario described here can indeed happen,
but is probably not that common. And I don’t mean this to be an excuse
to avoid difficult work. ;-)
I think that the solutions I proposed are worse than the problem,
because they’re complex and would depend on external state, thus making
them look non-deterministic.
So I think I’ll punt and mark it as “wontfix.”
Thoughts?
Ludo’.
Added tag(s) wontfix.
Request was from
ludo <at> gnu.org (Ludovic Courtès)
to
control <at> debbugs.gnu.org
.
(Sun, 13 Dec 2015 18:19:02 GMT)
Full text and
rfc822 format available.
bug marked as fixed in version 0.9.0, send any further explanations to
21767 <at> debbugs.gnu.org and Benno Evers <benno <at> bmevers.de>
Request was from
ludo <at> gnu.org (Ludovic Courtès)
to
control <at> debbugs.gnu.org
.
(Sun, 13 Dec 2015 18:19:03 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Mon, 11 Jan 2016 12:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 9 years and 164 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.