On Tue, Apr 08, 2014 at 03:03:55PM +0200, Martin Kletzander wrote: > On Tue, Apr 08, 2014 at 12:52:36PM +0100, Daniel P. Berrange wrote: > >On Tue, Apr 08, 2014 at 01:47:14PM +0200, Martin Kletzander wrote: > >>On Tue, Apr 08, 2014 at 12:49:25PM +0200, Guido Günther wrote: > >>>On Tue, Apr 08, 2014 at 10:09:59AM +0100, Daniel P. Berrange wrote: > >>>>On Mon, Apr 07, 2014 at 04:40:24PM -0600, Eric Blake wrote: > >>>>> On 04/07/2014 02:02 AM, Guido Günther wrote: > >>>>> > When building packages in a clean chroot the QEMU_USER and QEMU_GROUP > >>>>> > don't exist making VirQemuDriverConfigNew fail with privileged=true. > >>>>> > > >>>>> > Avoid that by not requiring priviliged mode and skipping tests that need > >>>>> > >>>>> s/priviliged/privileged/ > >>>>> > >>>>> > it. > >>>>> > --- > >>>>> > tests/qemuxml2argvtest.c | 24 ++++++++++++++++-------- > >>>>> > 1 file changed, 16 insertions(+), 8 deletions(-) > >>>>> > >>>>> Seems like this is what avoids the fail pointed out in 1/3. It still > >>>>> feels fishy that our testsuite is that dependent on the system (ideally, > >>>>> we'd provide a way to mock things up so that creating the config file > >>>>> NEVER fails when run from the testsuite, even if the uid doesn't exist - > >>>>> because we shouldn't be probing the live system, only our mockups). I'd > >>>>> wait for a second opinion on whether this patch is papering over a > >>>>> bigger problem of depending on the current system state, or whether it > >>>>> is an acceptable way to avoid the issue without investing the effort to > >>>>> tackle at the uid lookup level. > >>>> > >>>>IMHO we should be passing privileged == false unconditionally, so that > >>>>we always skip any magic username lookups. > >>> > >>>I would have done that but Martin's 29151830e468f1a9d8006a62702591958a4e3481 > >>>did the opposite, so o.k. to revert that? > >> > >>Reverting that will make *tune tests fail. We could, however, create > >>our own test config instead of virQEMUDriverConfigNew() or add a > >>parameter to it which will decide on what to do, the least being: > > > >What about passing 'false' to ConfigNew() but then manually > >set 'cfg->privileged = true' on the object we get back. > > > > That could work. All tests passed on my setup like that. And it > doesn't seem weird since we're playing with the config a lot in the > tests. I do wonder if my approach wouldn't be cleaner since it doesn't poke into the objects internals. Cheers, -- Guido -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list