Matching debug symbol and package versions

DoneSubmitted by Benno Evers.
Details
3 participants
  • Benno Evers
  • Efraim Flashner
  • Ludovic Courtès
Owner
unassigned
Severity
normal
B
B
Benno Evers wrote on 27 Oct 2015 00:15
(address . bug-guix@gnu.org)
562EB405.30207@bmevers.de
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.
L
L
Ludovic Courtès wrote on 27 Oct 2015 16:56
(name . Benno Evers)(address . benno@bmevers.de)(address . 21767@debbugs.gnu.org)
87bnbktie0.fsf@gnu.org
Benno Evers <benno@bmevers.de> skribis:
Toggle quote (11 lines)> 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 toinfer 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’sunclear whether case (i) would sufficiently frequent to justify thiscomplexity.
Thoughts?
Thanks,Ludo’.
E
E
Efraim Flashner wrote on 27 Oct 2015 17:40
(name . Ludovic Courtès)(address . ludo@gnu.org)
20151027184054.72c492f9@debian-netbook
On Tue, 27 Oct 2015 16:56:23 +0100ludo@gnu.org (Ludovic Courtès) wrote:
Toggle quote (36 lines)> Benno Evers <benno@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 `guixpackage -i foo foo:bar`. But then if you really only wanted foo:bar you'dhave to follow up with `guix package -r foo`.-- 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
-----BEGIN PGP SIGNATURE-----Version: GnuPG v2
iQIcBAEBCgAGBQJWL6kWAAoJEPTB05F+rO6TNz8P/3LaSSkKOBWBn9LMLURVzYf0fkDqtnLbo6OqgzyhEAHVTu/Lan7al7RWsK64b7LdjllcwzYwd/v6pmDTo3c6RGqbsEU2+jK7zs4azNecOYM1w0zJ2Eq/aYL8UtXz7HsmVB/fL84Meu8EsrtBWKEtM9rAFyFBo7koHWZiPh63dc+TRYXaLyL9qYfUkSWncV7SQyaKzb6+kXmQMLo86XcAcRZ4/oKyEV4DHxSNvBxOiiExFFBRBPZDdFNef0obE1IaJZfVYG8Lfs3kSxyna4SBeDNLHgo8oI88olUaF39xrJjUAqYbC97bW1o5S9Ouc0qWhk4bD2K7x/dpyztPJg/81BZT0YU6Eos4kAmdybHYjv6yRhcEDuDUahowxd0re0je4kwHTaxkeetay+CffaaH8G0uMXOUWcr/u7w155veu2kYShfkUxOlBIYnfAN1TRbYAP580VUuaf6oggBgE2GhGAfOWIhKAcYRYsMD8vewxopKp48XAueL2XnsYTx4R8gta5dSb4kFGLMnn5CTKsajxp7ugR78tgyIhSeWwzfFEHCTci/VCRDYcVMB/O3zajKMjpPhdj1LLMtmZGMjjr7KsQnCHbDt4IuCRSTlyHwE12jgRhA6SSBeBm8+SSMpvzhxntOjlHaff1ki4giq+eDbjPUtj8Zpm38zWNW3KV/KB3sC=dDwt-----END PGP SIGNATURE-----

L
L
Ludovic Courtès wrote on 27 Oct 2015 18:23
(name . Efraim Flashner)(address . efraim@flashner.co.il)
87lhaorzso.fsf@gnu.org
Efraim Flashner <efraim@flashner.co.il> skribis:
Toggle quote (3 lines)> 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’.
L
L
Ludovic Courtès wrote on 21 Nov 2015 17:56
(name . Benno Evers)(address . benno@bmevers.de)(address . 21767@debbugs.gnu.org)
87mvu770kn.fsf@gnu.org
Benno Evers <benno@bmevers.de> skribis:
Toggle quote (11 lines)> 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 themore general context.
The “in the meantime” above means that you had run ‘guix pull’ orsimilar, thereby making the previous package recipe unavailable andleaving you unable to install matching debugging symbols.
On my laptop, I typically run ‘guix package -u’ every time I do ‘guixpull’, so I cannot find myself in a situation where I’m unable toinstall 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 excuseto 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 makingthem look non-deterministic.
So I think I’ll punt and mark it as “wontfix.”
Thoughts?
Ludo’.
L
L
Ludovic Courtès wrote on 13 Dec 2015 19:18
control message for bug #21767
(address . control@debbugs.gnu.org)
87poyaus8y.fsf@gnu.org
tags 21767 wontfix
L
L
Ludovic Courtès wrote on 13 Dec 2015 19:18
(address . control@debbugs.gnu.org)
87oaduus8p.fsf@gnu.org
close 21767 0.9.0
?
Your comment

This issue is archived.

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