similar to: [PATCH] inspection: deb: Seperate epoch field from version

This way source and summary can be specified for any package read from the guest. --- lib/inspect-apps.c | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/lib/inspect-apps.c b/lib/inspect-apps.c index 1216c52..eabe565 100644 --- a/lib/inspect-apps.c +++ b/lib/inspect-apps.c @@ -51,7 +51,7 @@ static struct guestfs_application2_list *list_applications_deb

This way source and summary can be specified for any package read from the guest. --- lib/inspect-apps.c | 17 ++++++++++------- 1 file changed, 10 insertions(+), 7 deletions(-) diff --git a/lib/inspect-apps.c b/lib/inspect-apps.c index 1216c52..eabe565 100644 --- a/lib/inspect-apps.c +++ b/lib/inspect-apps.c @@ -51,7 +51,7 @@ static struct guestfs_application2_list *list_applications_deb

Extend the guestfs_inspect_list_applications2 API call to work on Arch Linux guest images. Signed-off-by: Nikos Skalkotos <skalkoto@gmail.com> --- src/inspect-apps.c | 137 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 137 insertions(+) diff --git a/src/inspect-apps.c b/src/inspect-apps.c index 6fb9665..8e645b7 100644 --- a/src/inspect-apps.c +++

Here's the new API method and update to virt-inspector. I still need to implement app_arch for debian and windows (if applicable), for now they just return empty strings.

Implement the helper function for guestfs_inspect_list_applications2 to be able to parse the list of installed applications with the APK package manager (used on Alpine Linux). --- src/inspect-apps.c | 121 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 121 insertions(+) diff --git a/src/inspect-apps.c b/src/inspect-apps.c index b54cf07..78c32bf 100644 ---

This adds package arch inspection for deb-based systems. The patch returns package arch as given by dpkg, which means that it returns 'amd64' instead of 'x86_64', for example. Whether or not we should standardize this to match rpm output is up for debate. I see other places such as guestfs_file_architecture that use the rpm-style arch. I can understand though where a user of

OK, I'll make the suggested changes and I'll try to come up with a new patch by tomorrow or the day after tomorrow. I just noticed that a space is missing between STREQ and ( in the key assignment code which violates the project's coding style. I'll fix that too. For a test-case, I can write a make-archlinux-img.sh script and send it in another patch. It's not big deal.

Here's the new API method and update to virt-inspector. I still need to implement app_arch for debian and windows (if applicable), for now they just return empty strings. New in v2: incorporated feedback from v1, also added patch #3 which updates the documentation where it references the deprecated API. Take it or leave it.

Extend the guestfs_inspect_list_applications2 API call to work on Arch Linux guest images. --- src/inspect-apps.c | 125 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 125 insertions(+) diff --git a/src/inspect-apps.c b/src/inspect-apps.c index b62b432..b7a3b0e 100644 --- a/src/inspect-apps.c +++ b/src/inspect-apps.c @@ -60,6 +60,7 @@ static struct

Here's a partially implemented fix for RHBZ#859949. Seeing as this is my first libguestfs patch, I'd like some other eyeballs on it to make sure I've not done anything completely crazy. If the rpm case looks ok, I'll update the deb and windows cases if/where applicable.

On Sun, Nov 16, 2014 at 03:24:16PM +0200, Nikos Skalkotos wrote: > Extend the guestfs_inspect_list_applications2 API call to work on Arch > Linux guest images. Generally looks good. I have a few minor comments inline below. But also I think we could use a test case (see tests/guests/). I don't think we'd reject the patch for not having a test case, but the test case would ensure

OK, I'll try to fix the epoch thing for all three. Nikos On 17 November 2014 13:49, Richard W.M. Jones <rjones@redhat.com> wrote: > On Mon, Nov 17, 2014 at 01:41:28PM +0200, Nikos Skalkotos wrote: >> OK, I'll make the suggested changes and I'll try to come up with a new >> patch by tomorrow or the day after tomorrow. I just noticed that a >> space is

__map_domain_page() *must* be matched with an unmap_domain_page(). These five static inline functions each map a page (or two), then throw away the context needed to unmap it. Each of the changes are limited to their respective functions. In two cases, this involved replacing a large amount of pointer arithmetic with memcpy() (all callers were relying on memcpy() semantics of positive/negative

We do this by defining DB_DUMP unconditionally and then testing the special exit code given by the shell if the command is not found (see http://www.tldp.org/LDP/abs/html/exitcodes.html). Packagers may either: (1) Provide db_dump as a build requirement, but make it a weak dependency at runtime, or: (2) Not provide db_dump at build time, but define DB_DUMP to its expected path when configuring,

On Mon, Nov 17, 2014 at 01:41:28PM +0200, Nikos Skalkotos wrote: > OK, I'll make the suggested changes and I'll try to come up with a new > patch by tomorrow or the day after tomorrow. I just noticed that a > space is missing between STREQ and ( in the key assignment code which > violates the project's coding style. I'll fix that too. > > For a test-case, I can

This patch series changes a small part of the library to use __attribute__((cleanup(...))) to automatically free memory when pointers go out of the current scope. In general terms this seems to be a small win although you do have to use it carefully. For functions where you can completely get rid of the "exit code paths", it can simplify things. For a good example, see the

Hello, I am running Centos 4 fully updated (as of 1 week ago) I tried to use yum last night and I got this error: [root at localhost share]# yum update Setting up Update Process Setting up repositories update 100% |=========================| 951 B 00:00 rpmforge 100% |=========================| 1.1 kB 00:00 base 100%

Hello Does anybody know why is there so much packages with EPOCH cca? What is it good for? Petr Klima

Hi, all, ? ?On Centos 5 I am programming RPM with python recently. ?When I read the online RPM python programming guide at http://docs.fedoraproject.org/drafts/rpm-guide-en/ch16s05.html, I got confused at the EVR() function as the function returns the (epoch, version, release) as a string ?%epoch-%version-%release?, and so the RPM ?comparing process is simplified as string comparing ? which

On Mon, 8 Jul 2019 at 18:08, Leon Fauster via CentOS <centos at centos.org> wrote: > I am building a new workstation based on EL8 now. As someone else here > mentioned, the raw EL8 distribution > is unusable as a workstation. Therefore I am building lot of additional > packages. Today I came across a problem > with a custom package with an Epoch version, that kills the