Re: [libvirt] Fwd: libvirtd failing on MacOS in setgroups

2019-10-01 Thread Bruno Haible
Daniel P. Berrangé wrote: > > For what purpose is libvirt or QEMU using setgroups()? What goes wrong if > > setgroups() fails? > > QEMU potentially needs access to files owned by a supplementary group. > On Linux for example, /dev/kvm is often owned by 'kvm' group, but the > 'qemu' user on Fedora

Re: [libvirt] Fwd: libvirtd failing on MacOS in setgroups

2019-09-30 Thread Bruno Haible
Daniel P. Berrangé wrote: > > > FWIW I compiled libvirt without the setgroups code on Mac and it > > > worked as expected. Not sure what the implications of that are though? > > > > OK, then the fix would be to not use setgroups on Mac, and nothing to do > > in gnulib. Right? > > Not calling setg

Re: [libvirt] Fwd: libvirtd failing on MacOS in setgroups

2019-09-28 Thread Bruno Haible
Marcus Furlong wrote: > FWIW I compiled libvirt without the setgroups code on Mac and it > worked as expected. Not sure what the implications of that are though? OK, then the fix would be to not use setgroups on Mac, and nothing to do in gnulib. Right? Bruno -- libvir-list mailing list libvir-li

Re: [libvirt] Fwd: libvirtd failing on MacOS in setgroups

2019-08-30 Thread Bruno Haible
Hi Eric, > I wonder if gnulib could provide a workaround setgroups() that overcomes > this issue I don't see how a workaround could look like. The problem is not the value of NGROUPS_MAX in user-space, but the same value NGROUPS_MAX in the kernel. More precisely, in the Darwin kernel file bsd/ker

Re: [libvirt] gnulib tests in libvirt broken by newer glibc 2.26

2017-10-09 Thread Bruno Haible
Daniel P. Berrange wrote: > Tested-by: Daniel P. Berrange > > > Confirmed it fixes the failure on Fedora 28, and does not cause a regression > on Fedora 26 with older glibc. Thanks. Pushing it: 2017-10-09 Bruno Haible getopt-posix: Fix build fai

Re: [libvirt] gnulib tests in libvirt broken by newer glibc 2.26

2017-10-06 Thread Bruno Haible
Daniel P. Berrange wrote: > From my own F28 rawhide install with glibc-2.26.90-16.fc28.x86_64 > > > > > 1) The output of > > $ nm test-getopt-posix | grep getopt > > $ nm test-getopt-posix | grep getopt > U getopt@@GLIBC_2.2.5 > 00400ab0 t getopt_loop.constprop.0

Re: [libvirt] gnulib tests in libvirt broken by newer glibc 2.26

2017-09-29 Thread Bruno Haible
Hi, Christian Ehrhardt wrote: > > Fedora 26 only has glibc 2.25 - you need to have Fedora rawhide to get > > the broken behaviour, as that has glibc 2.26.90 > As Daniel said at least glibc 2.26 as in Fedora rawhide or Ubuntu Artful. This tip is not helpful: I spent two hours trying Fedora Rawhide

Re: [libvirt] namespace clean shared libraries

2012-08-02 Thread Bruno Haible
Daniel P. Berrange wrote: > Try applying this patch to your source tree > > diff --git a/configure.ac b/configure.ac > index 6b189db..4f906bb 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -2876,6 +2876,10 @@ test "x$lv_cv_static_analysis" = xyes && t=1 > AC_DEFINE_UNQUOTED([STATIC_ANALYSI

Re: [libvirt] namespace clean shared libraries

2012-07-08 Thread Bruno Haible
Daniel P. Berrange wrote: > If its better to just do it in libvirt config.h, then we > can do that too Yes, doing '#define foo libvirt_foo' in config.h is the preferred way of achieving a namespace clean shared library. There are two ways to generate these #defines: 1) You collect manually, on v

Re: [libvirt] Libvirt / GNULIB failures using Mingw64 toolchain

2012-06-21 Thread Bruno Haible
The attached patch looks like it should fix the compilation error. I'm committing it. Can you please try it (you need to re-bootstrap libvirt to this effect, I guess)? 2012-06-21 Bruno Haible nonblocking: Avoid compilation error on mingw64. * m4/stdio_h.m4 (gl_STDIO_H): In

Re: [libvirt] Libvirt / GNULIB failures using Mingw64 toolchain

2012-06-19 Thread Bruno Haible
fstat64 = _fstati64 #endif #endif therefore what gnulib does in stat.c and fstat.c is equivalent to it. We lose nothing by silencing the warning. I'm applying this: 2012-06-19 Bruno Haible stat, fstat: Avoid warnings on mingw64. * lib/stat.c (stat) [_GL_WINDOWS

Re: [libvirt] Libvirt / GNULIB failures using Mingw64 toolchain

2012-06-17 Thread Bruno Haible
Hello Daniel, > CC fstat.lo > ../../../gnulib/lib/fstat.c:27:0: warning: "stat" redefined [enabled by > default] > In file included from ./sys/stat.h:32:0, > from ../../../gnulib/lib/fstat.c:25: > /usr/x86_64-w64-mingw32/sys-root/mingw/include/sys/stat.h:258:0: note: this

Re: [libvirt] regcomp warnings using Mingw64 toolchain

2012-06-17 Thread Bruno Haible
Hi Paul, Daniel P. Berrange wrote: > While on x86_64-w64-mingw32 only I see: > > > In file included from ../../../gnulib/lib/regex.c:69:0: > ../../../gnulib/lib/regcomp.c: In function 'parse_dup_op': > ../../../gnulib/lib/regcomp.c:2624:39: warning: cast to pointer from integer > of different s

Re: [libvirt] [PATCH] show compiled in options in virsh --version

2010-10-28 Thread Bruno Haible
Hi Eric, > >>> case 'v': > >>> -/* FIXME - list a copyright blurb, as in GNU programs? */ > >>> -puts(VERSION); > >>> +vshShowVersion(ctl); > >>> exit(EXIT_SUCCESS); > > The gnulib module closeout can automatically take care of this, but

Re: [libvirt] [RFC PATCH] build: avoid %zu in translated strings

2010-08-28 Thread Bruno Haible
Hi Eric, > after looking into this deeper, it (happily) appears that I > may have been mistaken. It looks like the gnulib vasprintf module > _already_ performs printf parsing on mingw; and that as a virtue of that > printf parsing, %zu and %llu are already rewritten into modifiers > understood by

Re: [libvirt] how to print size_t in LGPLv2+ program

2010-08-18 Thread Bruno Haible
> > What a shame that POSIX omitted an PRIu* for size_t. > > You can define it by yourself ... Or use uintptr_t instead of size_t. By the definition of these types, you can be sure that uintptr_t is at least as wide as size_t. Then use printf ("%" PRIuPTR, (uintptr_t) size_t_value); - Works

Re: [libvirt] PRIuSIZE

2010-08-18 Thread Bruno Haible
Eric Blake wrote: > Here's where a cross-project change to GNU Coding Standards could be > helpful - if we all agree that gnulib should add the macro and gettext > should add the support for it at the same time, then it would be much > easier for all remaining GNU projects to take advantage of a >

Re: [libvirt] gettext and need-formatstring-macros

2010-08-18 Thread Bruno Haible
[This question ought to have been sent to bug-gettext, not bug-gnulib.] Hi Eric, > Use of PRIuMAX in a translated string produces a .pot file that > refers to the special string , and which requires the > need-formatstring-macros option passed to AM_GNU_GETTEXT in configure.ac > to be universally

Re: [libvirt] detecting uses of "%zu"

2010-08-18 Thread Bruno Haible
Eric Blake wrote: > it still requires auditing code > and forbidding "%zu" in favor of "%"PRIuSIZE (or whatever other name we > settle on). You could hack GCC, clang, or even xgettext to produce a warning when it sees a 'z' size modifier in a format string. Bruno -- libvir-list mailing list libv

Re: [libvirt] how to print size_t in LGPLv2+ program

2010-08-18 Thread Bruno Haible
Hi Eric, > My understanding is that on 64-bit windows, > sizeof(long)==4 but sizeof(void*)==8; and ... sizeof(size_t) is also 8. Yes, correct. > Which means you _can't_ use "%lu",(unsigned long)size_t_val. You _can_ use this. It will work as long as each of your program's data structures is les

Re: [libvirt] how to print size_t in LGPLv2+ program

2010-08-18 Thread Bruno Haible
[removed bug-gnulib from CC] Eric Blake wrote: > > printf ("%" PRIuPTR, (uintptr_t) size_t_value); > > But still needs the use of need-formatstring-macros, and gettext 0.16.1 > or newer (whereas libvirt is stuck on 0.14.1 at the moment). The uses of these formatstring macros require - at pac

Re: [Libvir] [Q] gnulib comment

2008-02-28 Thread Bruno Haible
Jim Meyering wrote: > Thank you for the patch. That is indeed a typo. > I've attached a patch adding a ChangeLog entry, > for application to gnulib's git repository. Thanks, applied. > [Bruno, to apply this, you can remove the two '>' and then > run "git am THIS_MESSAGE". ] Which '>' should I