Hi -
asmadeus wrote:
- My usecase admitedly wasn't a very nice one (graphical
application,
info dll says I have 265 linked libraries...), but it felt very slow.
Yes, a first-time download series for such a program is going to take
time. (Afterwards, it's cached.)
Looking at iftop the server was reliably sending me things at 1mbps
which isn't great but with the amount of data involved being slow can't
be helped, I guess.
Right. The fedora debuginfod server seems well situated on the net, so
can generally send you compressed DWARF files fast. (I'm getting 5ish
megabytes/s across https.)
[...] Most of these libraries are nothing I care about. [...] but
could it be possible to not download anything at this point and only
download debuginfos when they are really used [...]
This sounds like a worthwhile suggestion for upstream gdb. We will
follow up with them.
[...] - None of ^C, ^\, ^Z work, when I grew tired of waiting I had
to switch to another terminal and kill the gdb process. [...]
OK, in my experiments, ^C did work, so something must have broken here.
We will follow up with gdb folks.
- unsetting DEBUGINFOD_URLS completely disables the debuginfod
client,
it would have been nice to use the data available in the client cache
anyway. Ultimately I set it to localhost so debuginfod would give up
immediately on new requests but still use previously downloaded data.
Perhaps there could be an "offline mode" of sorts?
I'll document this trick on the wiki.
By the way, consider operating your own debuginfod (rawhide or 0.185)
server, federating to upstream. The gdb-gui-download-series process you
experienced could be maybe twice as fast, due to http connection
keepalive improvements. Maybe even faster, once gdb itself takes direct
advantage (patches there are pending). Plus you get a shared cache for
your network.
[... re. security ...] (distributing just checksums of all debug
files
in the main package, so when debuginfod downloads something it can
compare with the checksum that was installed and verified locally by
signed rpm?
That sounds like something that could fall out from this effort [1], when/if
comes to fruition. We in debuginfod land could naturally follow up with
interfacing & checking glue code.
[1]
https://fedoraproject.org/wiki/Changes/Signed_RPM_Contents
All in all I think it's a very valuable tool, but it would be
really
great if we could minimize the amount of data actually downloaded, and
establish some chain of trust.
I'm hoping we can make some improvements between now and F35 release,
though practically all of these rely on changes to other projects.
- FChE