Older dbus versions (at least 1.2.24) don't define it by default.
---
plugins/systemd_inhibit.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/plugins/systemd_inhibit.c b/plugins/systemd_inhibit.c
index badcc9e..1dd66e6 100644
--- a/plugins/systemd_inhibit.c
+++
On 03/05/2013 04:24 PM, Mark Wielaard wrote:
Older dbus versions (at least 1.2.24) don't define it by default.
---
plugins/systemd_inhibit.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/plugins/systemd_inhibit.c b/plugins/systemd_inhibit.c
index badcc9e..1dd66e6
On Mon, Mar 04, 2013 at 12:22:31PM +0100, Michael Schroeder wrote:
For 2000 packages we have about... ugh, that's actually hard
to tell as the avg and the median differ that much. Let's
use the average: 2000 * 130 = 26 files.
I would hash them using just a 32-bit number for each hash
On Tue, Mar 05, 2013 at 07:15:30PM +0200, Panu Matilainen wrote:
Hum... dbus 1.2.24 would be RHEL-6'ish, right? In which case the
whole plugin makes no sense at all because it actually needs to have
a fairly recent systemd running on the system to do anything at all.
Dunno, I can certainly
On 03/05/2013 09:38 PM, Mark Wielaard wrote:
On Tue, Mar 05, 2013 at 07:15:30PM +0200, Panu Matilainen wrote:
Hum... dbus 1.2.24 would be RHEL-6'ish, right? In which case the
whole plugin makes no sense at all because it actually needs to have
a fairly recent systemd running on the system to do
Hi,
I am probably doing something wrong with configuring, but I cannot get
make check to work with the attached patch. And even with that half of
the tests fail because for some reason there is a literal '${prefix}'
string used somewhat that cause the creation of an extra directory
I have been thinking about it now and I think having a hook for setting file
meta data is a good idea in any case (even if we decide to keep pre/post hooks
for some other purpose). It shows much clearer the purpose of the hook and it
can be placed nicely exactly where metadata is set (and
On 03/04/2013 10:56 AM, Reshetova, Elena wrote:
Looking at this, I just realized that rpm is currently doing chmod(),
chown() and all for each hardlink it creates, which just doesn't make
sense because ... by the very definition of a hardlink, it doesn't.
Probably worth fixing regardless of what
