[Bug debuginfod/25583] Use libarchive to extract .deb packages?
https://sourceware.org/bugzilla/show_bug.cgi?id=25583 Mark Wielaard changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- Summary|Use libarchive to extract |Use libarchive to extract |packages? |.deb packages? --- Comment #5 from Mark Wielaard --- Great we have .rpm done now. Lets keep this open in case someone wants to do the .deb variant too. BTW. It seems we should tweak elfutils.spec too. rpm isn't needed anymore, but we should recommend/require dpkg? diff --git a/config/elfutils.spec.in b/config/elfutils.spec.in index e992812a..ef7fe31f 100644 --- a/config/elfutils.spec.in +++ b/config/elfutils.spec.in @@ -157,8 +157,9 @@ Requires(post): systemd Requires(preun): systemd Requires(postun): systemd Requires(pre): shadow-utils -# For /usr/bin/cpio2rpm -Requires: rpm +# To extract .deb files with dpkg-deb --fsys-tarfile +# Can be Recommends if rpm supports that +Requires: dpkg %description debuginfod-client The elfutils-debuginfod-client package contains shared libraries -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/25583] Use libarchive to extract .deb packages?
https://sourceware.org/bugzilla/show_bug.cgi?id=25583 --- Comment #6 from Frank Ch. Eigler --- > -# For /usr/bin/cpio2rpm > -Requires: rpm Heh, that was always moot on an rpm based system (.spec file!). > +# To extract .deb files with dpkg-deb --fsys-tarfile > +# Can be Recommends if rpm supports that > +Requires: dpkg Sure, as long as one remembers to remove it from rhel distros that have dpkg only in epel. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/25628] New: client should cache negative results
https://sourceware.org/bugzilla/show_bug.cgi?id=25628 Bug ID: 25628 Summary: client should cache negative results Product: elfutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: debuginfod Assignee: unassigned at sourceware dot org Reporter: amerey at redhat dot com CC: elfutils-devel at sourceware dot org Target Milestone: --- When a query for a file fails the client should save this information in the cache, possibly as an empty file with the usual name. This can save time by allowing for skipping queries that are likely to fail. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/25628] client should cache negative results
https://sourceware.org/bugzilla/show_bug.cgi?id=25628 Frank Ch. Eigler changed: What|Removed |Added CC||fche at redhat dot com --- Comment #1 from Frank Ch. Eigler --- debuginfod misses are pretty quick tho - maybe it's harmless? If these are to be cached, they shouldn't be cached too long, as the data could appear later. -- You are receiving this mail because: You are on the CC list for the bug.
[PATCH] debuginfod-client: update cache_path when new default path exists
From 46010f911b72610452c2c58a709af8609992225b Mon Sep 17 00:00:00 2001
From: Aaron Merey
Date: Tue, 3 Mar 2020 14:11:48 -0500
Subject: [PATCH] debuginfod-client: Update cache_path when the new default
path exists
Update cache_path with the path of the new default directory when this
directory already exists. Previously cache_path was updated only when
creating the new default directory and would otherwise be set to the
old default path.
Signed-off-by: Aaron Merey
---
debuginfod/ChangeLog | 5 +
debuginfod/debuginfod-client.c | 16 +++-
tests/run-debuginfod-find.sh | 7 +++
3 files changed, 19 insertions(+), 9 deletions(-)
diff --git a/debuginfod/ChangeLog b/debuginfod/ChangeLog
index 21d9ed87..ab32b523 100644
--- a/debuginfod/ChangeLog
+++ b/debuginfod/ChangeLog
@@ -1,3 +1,8 @@
+2020-03-03 Aaron Merey
+
+ * debuginfod-client.c (debuginfod_query_server): Update
+ cache_path even when new default path already exists.
+
2020-02-27 Aaron Merey
* debuginfod-client.c (xalloc_str): New macro. Call
diff --git a/debuginfod/debuginfod-client.c b/debuginfod/debuginfod-client.c
index 2825e625..8923099f 100644
--- a/debuginfod/debuginfod-client.c
+++ b/debuginfod/debuginfod-client.c
@@ -509,20 +509,18 @@ debuginfod_query_server (debuginfod_client *c,
/* Also check for EEXIST and S_ISDIR in case another client just
happened to create the cache. */
- if (rc == 0
- || (errno == EEXIST
- && stat (cachedir, &st) != 0
- && S_ISDIR (st.st_mode)))
-{
- free (cache_path);
- xalloc_str (cache_path, "%s/%s", cachedir, cache_xdg_name);
-}
- else
+ if (rc < 0
+ && (errno != EEXIST
+ || stat (cachedir, &st) != 0
+ || ! S_ISDIR (st.st_mode)))
{
rc = -errno;
goto out;
}
}
+
+ free (cache_path);
+ xalloc_str (cache_path, "%s/%s", cachedir, cache_xdg_name);
}
}
diff --git a/tests/run-debuginfod-find.sh b/tests/run-debuginfod-find.sh
index 56e61216..587eaaa3 100755
--- a/tests/run-debuginfod-find.sh
+++ b/tests/run-debuginfod-find.sh
@@ -158,6 +158,13 @@ if [ ! -f $PWD/tmphome/.cache/debuginfod_client/$BUILDID/debuginfo ]; then
exit 1
fi
+# $HOME/.cache should be found.
+testrun env HOME=$PWD/tmphome XDG_CACHE_HOME= DEBUGINFOD_CACHE_PATH= ${abs_top_builddir}/debuginfod/debuginfod-find executable $BUILDID
+if [ ! -f $PWD/tmphome/.cache/debuginfod_client/$BUILDID/executable ]; then
+ echo "could not find cache in $PWD/tmphome/.cache"
+ exit 1
+fi
+
# $XDG_CACHE_HOME should take priority over $HOME.cache.
testrun env HOME=$PWD/tmphome XDG_CACHE_HOME=$PWD/tmpxdg DEBUGINFOD_CACHE_PATH= ${abs_top_builddir}/debuginfod/debuginfod-find debuginfo $BUILDID
if [ ! -f $PWD/tmpxdg/debuginfod_client/$BUILDID/debuginfo ]; then
--
2.24.1
[Bug debuginfod/25628] client should cache negative results
https://sourceware.org/bugzilla/show_bug.cgi?id=25628 Aaron Merey changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at sourceware dot org |amerey at redhat dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug debuginfod/25628] client should cache negative results
https://sourceware.org/bugzilla/show_bug.cgi?id=25628 --- Comment #2 from Aaron Merey --- (In reply to Frank Ch. Eigler from comment #1) > debuginfod misses are pretty quick tho - maybe it's harmless? If these are > to be cached, they shouldn't be cached too long, as the data could appear > later. Some delay is noticeable when doing multiple queries over a short time. Usually harmless but I think control over this may improve user experience. Another config file could be added to the top level of the cache to control how long to wait until querying the server again for these files. If we are worried about missing server updates then a default of 0 may be appropriate. -- You are receiving this mail because: You are on the CC list for the bug.
