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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
