[Bug debuginfod/25739] New: client cache sometimes has incorrect mtimes for downloaded files
https://sourceware.org/bugzilla/show_bug.cgi?id=25739 Bug ID: 25739 Summary: client cache sometimes has incorrect mtimes for downloaded files Product: elfutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: debuginfod Assignee: unassigned at sourceware dot org Reporter: eschwartz at archlinux dot org CC: elfutils-devel at sourceware dot org Target Milestone: --- When running debuginfod-find repeatedly against some files, it seems that if you rm a file from the cache, it spoils the mtime of all future files being downloaded (so that it results in the current time instead). As a result my gdb-git complains "warning: Source file is more recent than executable." After some IRC debugging, fche suggested trying to run the server using --fdcache-fds=0 which solved the issue. 12:54 PM <@fche> we just neglect to save the timestamps of fdcache'd files extracted from archives 12:54 PM <@fche> ok 12:54 PM <@fche> betcha if you run debuginfod with--fdcache-fds=0 12:54 PM <@fche> and even --fdcache-prefetch=0 12:54 PM <@fche> things will work -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/25509] Break a cyclic dependency by core packages
https://sourceware.org/bugzilla/show_bug.cgi?id=25509 --- Comment #13 from Eli Schwartz --- I think we'd prefer to have the ability to build libdebuginfod without the server. Ambivalent about a special option to force the libdebuginfod dummy to be created, but... If it's just for testing purposes, maybe you could always build the dummy, but only install it if the real libdebuginfod was not enabled? The testsuite could verify the dummy works by using LD_LIBRARY_PATH/LD_PRELOAD (depending on build directory layout) to run some tests explicitly using the dummy. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/25509] Break a cyclic dependency by core packages
https://sourceware.org/bugzilla/show_bug.cgi?id=25509 --- Comment #15 from Eli Schwartz --- Wouldn't that be covered by "libdebuginfod disabled equals dummy enabled"? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/25509] Break a cyclic dependency by core packages
https://sourceware.org/bugzilla/show_bug.cgi?id=25509 --- Comment #19 from Mark Wielaard --- (In reply to Eli Schwartz from comment #13) > I think we'd prefer to have the ability to build libdebuginfod without the > server. I believe you get that with --enable-libdebuginfod --disable-debuginfod, but maybe I don't understand your use case correctly. I tried to explain more fully in comment #17. Maybe you can try out the patch and let me know if it helps your use case or, if not, what would make things easier for you? --- Comment #20 from Eli Schwartz --- That should be fine, I think. > At least for Arch Linux, curl is part of the base system while libmicrohttpd > is not. Actually truth be told, by now we moved libmicrohttpd to core, which solves our immediate problem there. But having --enable-libdebuginfod --disable-debuginfod would let us remove it again, which might be beneficial. So it's still IMHO a good-to-have. :) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/25509] Break a cyclic dependency by core packages
https://sourceware.org/bugzilla/show_bug.cgi?id=25509 --- Comment #21 from Eli Schwartz --- (In reply to Mark Wielaard from comment #17) > I admit that having the combination --enable-libdebuginfod=dummy and > --enable-libdebuginfod is somewhat redundant/non-sensical, but it helps with > (build time) testing. Other testing matrix would imho be as complicated > (you'll get extra install flags or need to setup compile time or runtime > environment variables). Yeah, I just had a thought that you could avoid doing one configure/build/test with --enable-libdebuginfod=dummy and another with --enable-libdebuginfod. If the buildsystem logic to have test-time env vars testing both feels too clumsy and you'd rather just build twice in your test matrix, then of course you are the boss. :D -- You are receiving this mail because: You are on the CC list for the bug.
