[PATCH] doc: Fix DEBUGINFOD_PROGRESS description to just mention output on stderr.
An earlier variant of the default progress function could write to any file. Which is still in the documentation. But the actual implementation just uses stderr. Fix the documentation to match. Signed-off-by: Mark Wielaard --- doc/ChangeLog | 5 + doc/debuginfod_find_debuginfo.3 | 4 ++-- 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/doc/ChangeLog b/doc/ChangeLog index b40a141b..c7e451d7 100644 --- a/doc/ChangeLog +++ b/doc/ChangeLog @@ -1,3 +1,8 @@ +2020-01-10 Mark Wielaard + + * debuginfod_find_debuginfo.3 (DEBUGINFOD_PROGRESS): Mention progress + output goes to stderr. + 2020-01-02 Mark Wielaard * debuginfod.8 (DEBUGINFOD_TIMEOUT): Document as seconds to diff --git a/doc/debuginfod_find_debuginfo.3 b/doc/debuginfod_find_debuginfo.3 index f6ea7a45..7e5060f2 100644 --- a/doc/debuginfod_find_debuginfo.3 +++ b/doc/debuginfod_find_debuginfo.3 @@ -173,8 +173,8 @@ or negative means "no timeout".) This environment variable governs the default progress function. If set, and if a progressfn is not explicitly set, then the library will configure a default progressfn. This function will append a simple -progress message periodically to the given file. Consider using -"/dev/stderr" on platforms that support it. The default is nothing. +progress message periodically to stderr. The default is no progress +function output. .TP 21 .B DEBUGINFOD_CACHE_PATH -- 2.18.1
[Bug libdw/24856] dwarf_diename() cannot get correct name
https://sourceware.org/bugzilla/show_bug.cgi?id=24856 Frank Ch. Eigler changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||fche at redhat dot com Resolution|--- |INVALID --- Comment #4 from Frank Ch. Eigler --- as per comment #3, the test was based on a misunderstanding of the libdw api -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/25365] New: debuginfod client cleanup safety: restrict to client-pattern files
https://sourceware.org/bugzilla/show_bug.cgi?id=25365
Bug ID: 25365
Summary: debuginfod client cleanup safety: restrict to
client-pattern files
Product: elfutils
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: debuginfod
Assignee: amerey at redhat dot com
Reporter: fche at redhat dot com
CC: elfutils-devel at sourceware dot org
Target Milestone: ---
During cache cleanup, we should only erase files that match the pattern of file
names that we ourselves wrote (HEXCODE/{debuginfo,executable,source}), in
order to avoid nuking contents of a general directory if a user mis-sets
$DEBUGINFOD_CACHE_PATH .
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug debuginfod/25366] New: debuginfod scan: more progress/status
https://sourceware.org/bugzilla/show_bug.cgi?id=25366 Bug ID: 25366 Summary: debuginfod scan: more progress/status Product: elfutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: debuginfod Assignee: fche at redhat dot com Reporter: fche at redhat dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- With the workqueue based scanning, there is less progress information available on the console. A periodic report should show data like the last file that was processed by each thread. prometheus metrics should include their counters. prometheus metrics could include string status contents as comments. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/25367] New: web request status logging improvements
https://sourceware.org/bugzilla/show_bug.cgi?id=25367 Bug ID: 25367 Summary: web request status logging improvements Product: elfutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: debuginfod Assignee: unassigned at sourceware dot org Reporter: fche at redhat dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- debuginfod log webapi GET requests after completion, so they can include a data amount and precise service-time measurement -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/25368] New: handle native golang buildids
https://sourceware.org/bugzilla/show_bug.cgi?id=25368 Bug ID: 25368 Summary: handle native golang buildids Product: elfutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: debuginfod Assignee: unassigned at sourceware dot org Reporter: fche at redhat dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- Native golang puts unique buildids into a .note.go.buildid section, with a much longer textual string than our normal 20-byte blob. debuginfod would need to add these to the index, and golang debuginfo consumers would have to learn to pass it. hex-encoding the textual golang buildid should make it fit right into the webapi, instead of worrying about '/' characters embedded inside. RHEL packaged golang binaries get a normal gnu-style buildid also as a part of package postprocessing, so this functionality may not be required there. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/25369] New: make DEBUGINFOD_PROGRESS prettier
https://sourceware.org/bugzilla/show_bug.cgi?id=25369 Bug ID: 25369 Summary: make DEBUGINFOD_PROGRESS prettier Product: elfutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: debuginfod Assignee: unassigned at sourceware dot org Reporter: fche at redhat dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- It would be interesting to also print the URL being fetched, or other such textual status. This is probably most easily implemented by extending the debuginfod_client object with some progress-related state, which at some point could be externalized with new API ... or not. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/25370] New: container image/registry scanning
https://sourceware.org/bugzilla/show_bug.cgi?id=25370 Bug ID: 25370 Summary: container image/registry scanning Product: elfutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: debuginfod Assignee: unassigned at sourceware dot org Reporter: fche at redhat dot com CC: elfutils-devel at sourceware dot org, lberk at redhat dot com Target Milestone: --- There may be a use case where debuginfo-carrying container images are available on registries or filesystems, and where extracting that content could serve container debugging tasks. hypothetical algorithm: - given a list of image names - periodically make contact with designated registry across https://docs.docker.com/registry/spec/api/ - fetch authentication token if needed - download image manifest json, thence layer fs-delta files (tarballs) - scan resulting tarballs as ordinary libarchive inputs - use fs-delta blob hexid as archive path key - need only ever scan once! - https://gist.github.com/cirocosta/17ea17be7ac11594cb0f290b0a3ac0d1 or podman-intermediated: - given a list of image names - perform periodic "podman pull"s - podman mount - scan contents in -F mode - "podman unmount" afterwards - ... or podman save; scan the resulting tarball's contents as sub tarballs - one problem is how to scan only new layers (and not waste time instantiating old at all) -- You are receiving this mail because: You are on the CC list for the bug.
