Re: [libvirt] Initial working Mac OS X libvirt client build

2010-10-25 Thread Ruben Kerkhof 
On Mon, Oct 25, 2010 at 07:09, Justin Clift jcl...@redhat.com wrote:
 On 10/25/2010 12:18 PM, Ruben Kerkhof wrote:
 On Sun, Oct 24, 2010 at 02:46, Justin Clift jcl...@redhat.com wrote:
 On 10/24/2010 09:33 AM, Ruben Kerkhof wrote:
 snip
 None at all, actually. I just started libvirtd on my local mac on
 which I also have VirtualBox installed.
 Speaking of which, it would be nice to have a launchctl file for
 libvirtd. I might be able to come up with something...

 Please do. It'd be nice to have that part working out of the box for
 people as well. :)

 For that to work, I'd like to run libvirtd as my own user, so I can
 add the launchtl file to my own Library directory.

 I'm curious, can you successfully run libvirtd as your own user (no sudo)?

 03:10:17.562: error : qemudListenUnix:582 : Failed to bind socket to
 '@/Users/ruben/.libvirt/libvirt-sock': No such file or directory

 Actually, that looks familiar.  I think I tried the same thing, but was
 ok running it as root instead after getting the same error.

 I didn't look into it any more though. ;)


 Stepping through the code now, I see 2 (possible) issues:

 First: qemudInitPaths doesn't seem to create the ~/.libvirt directory
 Second: in qemudListenUnix, this piece of code:

 addr.sun_family = AF_UNIX;
     if (virStrcpyStatic(addr.sun_path, path) == NULL) {
         VIR_ERROR(_(Path %s too long for unix socket), path);
         goto cleanup;
     }
     if (addr.sun_path[0] == '@')
         addr.sun_path[0] = '\0';

 So the first byte of the sun_path is '\0', something that Leopard
 doesn't seem to like.
 Breaking into gdb and setting the path manually to
 /Users/ruben/.libvirt/libvirt-sock seems to work.

 Interesting.  We can definitely pull together a temporary OSX workaround
 patch for the moment (purely in the Homebrew formula).  But it would be
 better to have a proper fix in libvirt instead.

 How good is your C coding? :)

Terrible ;) I think the easiest fix is

if (addr[0] == '@')
addr[0] = '\0';

if (virStrcpyStatic(addr.sun_path, path) == NULL) {
VIR_ERROR(_(Path %s too long for unix socket), path);
   goto cleanup;
}

Or am I missing something?

I haven't been able to bootstrap a build from libvirt git yet, mainly
gettext issues.
Otherwise I would have come up with a proper patch.

Thanks,

Ruben

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] Initial working Mac OS X libvirt client build

2010-10-25 Thread Ruben Kerkhof 
On Mon, Oct 25, 2010 at 10:20, Ruben Kerkhof ru...@rubenkerkhof.com wrote:
 On Mon, Oct 25, 2010 at 07:09, Justin Clift jcl...@redhat.com wrote:
 On 10/25/2010 12:18 PM, Ruben Kerkhof wrote:
 On Sun, Oct 24, 2010 at 02:46, Justin Clift jcl...@redhat.com wrote:
 On 10/24/2010 09:33 AM, Ruben Kerkhof wrote:
 snip
 None at all, actually. I just started libvirtd on my local mac on
 which I also have VirtualBox installed.
 Speaking of which, it would be nice to have a launchctl file for
 libvirtd. I might be able to come up with something...

 Please do. It'd be nice to have that part working out of the box for
 people as well. :)

 For that to work, I'd like to run libvirtd as my own user, so I can
 add the launchtl file to my own Library directory.

 I'm curious, can you successfully run libvirtd as your own user (no sudo)?

 03:10:17.562: error : qemudListenUnix:582 : Failed to bind socket to
 '@/Users/ruben/.libvirt/libvirt-sock': No such file or directory

 Actually, that looks familiar.  I think I tried the same thing, but was
 ok running it as root instead after getting the same error.

 I didn't look into it any more though. ;)


 Stepping through the code now, I see 2 (possible) issues:

 First: qemudInitPaths doesn't seem to create the ~/.libvirt directory
 Second: in qemudListenUnix, this piece of code:

 addr.sun_family = AF_UNIX;
     if (virStrcpyStatic(addr.sun_path, path) == NULL) {
         VIR_ERROR(_(Path %s too long for unix socket), path);
         goto cleanup;
     }
     if (addr.sun_path[0] == '@')
         addr.sun_path[0] = '\0';

 So the first byte of the sun_path is '\0', something that Leopard
 doesn't seem to like.
 Breaking into gdb and setting the path manually to
 /Users/ruben/.libvirt/libvirt-sock seems to work.

 Interesting.  We can definitely pull together a temporary OSX workaround
 patch for the moment (purely in the Homebrew formula).  But it would be
 better to have a proper fix in libvirt instead.

 How good is your C coding? :)

 Terrible ;) I think the easiest fix is

 if (addr[0] == '@')
    addr[0] = '\0';

Argh, I meant path[0] here of course.


 if (virStrcpyStatic(addr.sun_path, path) == NULL) {
    VIR_ERROR(_(Path %s too long for unix socket), path);
   goto cleanup;
 }

 Or am I missing something?

 I haven't been able to bootstrap a build from libvirt git yet, mainly
 gettext issues.
 Otherwise I would have come up with a proper patch.

 Thanks,

 Ruben

Here's a (completely untested) patch. I will have more time tomorrow
to dig into this.

From 3fa6bcfca4bb50b18935cc4637426ef3ac3cdcbd Mon Sep 17 00:00:00 2001
From: Ruben Kerkhof ru...@tilaa.nl
Date: Mon, 25 Oct 2010 10:31:15 +0200
Subject: [PATCH] Fix binding to a unix socket on OSX

addr.sun_path doesn't like the first
byte to be NULL

Signed-off-by: Ruben Kerkhof ru...@tilaa.nl
---
 daemon/libvirtd.c |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/daemon/libvirtd.c b/daemon/libvirtd.c
index 8e88d05..76b8dc8 100644
--- a/daemon/libvirtd.c
+++ b/daemon/libvirtd.c
@@ -571,13 +571,14 @@ static int qemudListenUnix(struct qemud_server *server,
 virSetNonBlock(sock-fd)  0)
 goto cleanup;

+if (path[0] == '@')
+path[0] = '\0';
+
 sock-addr.data.un.sun_family = AF_UNIX;
 if (virStrcpyStatic(sock-addr.data.un.sun_path, path) == NULL) {
 VIR_ERROR(_(Path %s too long for unix socket), path);
 goto cleanup;
 }
-if (sock-addr.data.un.sun_path[0] == '@')
-sock-addr.data.un.sun_path[0] = '\0';

 oldgrp = getgid();
 oldmask = umask(readonly ? ~unix_sock_ro_mask : ~unix_sock_rw_mask);
-- 
1.7.3.1

Regards, Ruben


0001-Fix-binding-to-a-unix-socket-on-OSX.patch
Description: Binary data
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] Initial working Mac OS X libvirt client build

2010-10-25 Thread Daniel P. Berrange 
On Mon, Oct 25, 2010 at 10:37:36AM +0200, Ruben Kerkhof wrote:
 On Mon, Oct 25, 2010 at 10:20, Ruben Kerkhof ru...@rubenkerkhof.com wrote:
  On Mon, Oct 25, 2010 at 07:09, Justin Clift jcl...@redhat.com wrote:
  On 10/25/2010 12:18 PM, Ruben Kerkhof wrote:
  On Sun, Oct 24, 2010 at 02:46, Justin Clift jcl...@redhat.com wrote:
  On 10/24/2010 09:33 AM, Ruben Kerkhof wrote:
  snip
  None at all, actually. I just started libvirtd on my local mac on
  which I also have VirtualBox installed.
  Speaking of which, it would be nice to have a launchctl file for
  libvirtd. I might be able to come up with something...
 
  Please do. It'd be nice to have that part working out of the box for
  people as well. :)
 
  For that to work, I'd like to run libvirtd as my own user, so I can
  add the launchtl file to my own Library directory.
 
  I'm curious, can you successfully run libvirtd as your own user (no sudo)?
 
  03:10:17.562: error : qemudListenUnix:582 : Failed to bind socket to
  '@/Users/ruben/.libvirt/libvirt-sock': No such file or directory
 
  Actually, that looks familiar.  I think I tried the same thing, but was
  ok running it as root instead after getting the same error.
 
  I didn't look into it any more though. ;)
 
 
  Stepping through the code now, I see 2 (possible) issues:
 
  First: qemudInitPaths doesn't seem to create the ~/.libvirt directory
  Second: in qemudListenUnix, this piece of code:
 
  addr.sun_family = AF_UNIX;
      if (virStrcpyStatic(addr.sun_path, path) == NULL) {
          VIR_ERROR(_(Path %s too long for unix socket), path);
          goto cleanup;
      }
      if (addr.sun_path[0] == '@')
          addr.sun_path[0] = '\0';
 
  So the first byte of the sun_path is '\0', something that Leopard
  doesn't seem to like.
  Breaking into gdb and setting the path manually to
  /Users/ruben/.libvirt/libvirt-sock seems to work.
 
  Interesting.  We can definitely pull together a temporary OSX workaround
  patch for the moment (purely in the Homebrew formula).  But it would be
  better to have a proper fix in libvirt instead.
 
  How good is your C coding? :)
 
  Terrible ;) I think the easiest fix is
 
  if (addr[0] == '@')
     addr[0] = '\0';
 
 Argh, I meant path[0] here of course.
 
 
  if (virStrcpyStatic(addr.sun_path, path) == NULL) {
     VIR_ERROR(_(Path %s too long for unix socket), path);
    goto cleanup;
  }
 
  Or am I missing something?
 
  I haven't been able to bootstrap a build from libvirt git yet, mainly
  gettext issues.
  Otherwise I would have come up with a proper patch.
 
  Thanks,
 
  Ruben
 
 Here's a (completely untested) patch. I will have more time tomorrow
 to dig into this.
 
 From 3fa6bcfca4bb50b18935cc4637426ef3ac3cdcbd Mon Sep 17 00:00:00 2001
 From: Ruben Kerkhof ru...@tilaa.nl
 Date: Mon, 25 Oct 2010 10:31:15 +0200
 Subject: [PATCH] Fix binding to a unix socket on OSX
 
 addr.sun_path doesn't like the first
 byte to be NULL
 
 Signed-off-by: Ruben Kerkhof ru...@tilaa.nl
 ---
  daemon/libvirtd.c |5 +++--
  1 files changed, 3 insertions(+), 2 deletions(-)
 
 diff --git a/daemon/libvirtd.c b/daemon/libvirtd.c
 index 8e88d05..76b8dc8 100644
 --- a/daemon/libvirtd.c
 +++ b/daemon/libvirtd.c
 @@ -571,13 +571,14 @@ static int qemudListenUnix(struct qemud_server *server,
  virSetNonBlock(sock-fd)  0)
  goto cleanup;
 
 +if (path[0] == '@')
 +path[0] = '\0';
 +
  sock-addr.data.un.sun_family = AF_UNIX;
  if (virStrcpyStatic(sock-addr.data.un.sun_path, path) == NULL) {
  VIR_ERROR(_(Path %s too long for unix socket), path);
  goto cleanup;
  }
 -if (sock-addr.data.un.sun_path[0] == '@')
 -sock-addr.data.un.sun_path[0] = '\0';

NACK, this results in 'path' being a zer-length string, so no data is
copied in the next virStrcpyStatic line. The original code is correctly
creating a socket in the abstract namespace, ie one which does not
appear in the filesystem

Daniel
-- 
|: Red Hat, Engineering, London-o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org-o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] Initial working Mac OS X libvirt client build

2010-10-25 Thread Ruben Kerkhof 
On Mon, Oct 25, 2010 at 10:48, Daniel P. Berrange berra...@redhat.com wrote:

 NACK, this results in 'path' being a zer-length string, so no data is
 copied in the next virStrcpyStatic line. The original code is correctly
 creating a socket in the abstract namespace, ie one which does not
 appear in the filesystem

 Daniel

Ah, I didn't knew that, sorry.

Am I right in assuming that an abstract namespace is a linux-only feature?
The unix manpage on my Mac doesn't describe it, neither does FreeBSD
(http://www.freebsd.org/cgi/man.cgi?query=unixapropos=0sektion=0manpath=FreeBSD+8.1-RELEASEformat=html).

Thanks,

Ruben

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] Initial working Mac OS X libvirt client build

2010-10-25 Thread Justin Clift 
On 10/25/2010 07:20 PM, Ruben Kerkhof wrote:
snip
 I haven't been able to bootstrap a build from libvirt git yet, mainly
 gettext issues.

What are the gettext errors that happen for you?

Thinking you'll need to install a newer gettext that the OSX provided
one (as Homebrew does), and then make sure the headers/libraries for
it are found first.  Same as you've done for the readline libraries.

Something like:



./configure \
  CPPFLAGS='-I/usr/local/Cellar/gettext/0.17/include
-I/usr/local/Cellar/libxml2/2.7.7/include
-I/usr/local/Cellar/readline/6.1/include' \
  LDFLAGS='-L/usr/local/Cellar/gettext/0.17/lib
-L/usr/local/Cellar/libxml2/2.7.7/lib -L/usr/local/Cellar/readline/6.1/lib'



(That should actually work, as long as you have gettext 0.17 installed.)

:)

Regards and best wishes,

Justin Clift

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] Initial working Mac OS X libvirt client build

2010-10-25 Thread Eric Blake 

On 10/25/2010 05:19 AM, Ruben Kerkhof wrote:

On Mon, Oct 25, 2010 at 10:48, Daniel P. Berrangeberra...@redhat.com  wrote:


NACK, this results in 'path' being a zer-length string, so no data is
copied in the next virStrcpyStatic line. The original code is correctly
creating a socket in the abstract namespace, ie one which does not
appear in the filesystem

Daniel


Ah, I didn't knew that, sorry.

Am I right in assuming that an abstract namespace is a linux-only feature?
The unix manpage on my Mac doesn't describe it, neither does FreeBSD
(http://www.freebsd.org/cgi/man.cgi?query=unixapropos=0sektion=0manpath=FreeBSD+8.1-RELEASEformat=html).


Correct - sun_path starting with a NUL byte is a Linux extension, and 
not portable to other hosts (except maybe Cygwin).  We need to come up 
with an alternative to the abstract namespace for use on non-Linux hosts.


--
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] Initial working Mac OS X libvirt client build

2010-10-24 Thread Daniel Veillard 
On Sat, Oct 23, 2010 at 10:55:16AM +1100, Justin Clift wrote:
 On 10/23/2010 06:06 AM, Ruben Kerkhof wrote:
 snip
  It's getting a bit further, the logs are at http://fpaste.org/DC3R/
  
  It seems to have some problems with libxml2.
 
 Daniel, any idea what would cause this libxml2 failure?
 
   GEN virt-pki-validate
   GEN virt-xml-validate.1
   GEN virt-pki-validate.1
   GEN virsh.1
   CCLD virsh
   Undefined symbols:
   _xmlSaveToBuffer, referenced from:
   _cmdCPUBaseline in virsh-virsh.o
   _rl_completion_matches, referenced from:
   _vshReadlineCompletion in virsh-virsh.o
   _vshReadlineCompletion in virsh-virsh.o
   ld: symbol(s) not found
   collect2: ld returned 1 exit status
   make[3]: *** [virsh] Error 1
   make[2]: *** [all] Error 2
   make[1]: *** [all-recursive] Error 1
   make: *** [all] Error 2
 
 Ruben, the readline one can probably be worked around in the short
 term.  I've just submitted a patch to libvirt, allowing the use of
 readline can be disabled.  (easiest way forward)
 
 We'll need to figure out the libxml2 problem though.  Probably not
 going to be today, more likely sometime next week. (with luck)

  The only thing strange about this entry point in libxml2 is that
it got dropped by mistake in 2.6.11 and readded in 2.6.23 so if you
have a version of libxml2 in that range that may raise that problem

history of all symbols since 2.4.30 available from
  http://xmlsoft.org/symbols.xml

Daniel

-- 
Daniel Veillard  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
dan...@veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] Initial working Mac OS X libvirt client build

2010-10-24 Thread Ruben Kerkhof 
On Sun, Oct 24, 2010 at 02:46, Justin Clift jcl...@redhat.com wrote:
 On 10/24/2010 09:33 AM, Ruben Kerkhof wrote:
 snip
 None at all, actually. I just started libvirtd on my local mac on
 which I also have VirtualBox installed.
 Speaking of which, it would be nice to have a launchctl file for
 libvirtd. I might be able to come up with something...

 Please do. It'd be nice to have that part working out of the box for
 people as well. :)

For that to work, I'd like to run libvirtd as my own user, so I can
add the launchtl file to my own Library directory.


I'm curious, can you successfully run libvirtd as your own user (no sudo)?

03:10:17.562: error : qemudListenUnix:582 : Failed to bind socket to
'@/Users/ruben/.libvirt/libvirt-sock': No such file or directory

Stepping through the code now, I see 2 (possible) issues:

First: qemudInitPaths doesn't seem to create the ~/.libvirt directory
Second: in qemudListenUnix, this piece of code:

addr.sun_family = AF_UNIX;
if (virStrcpyStatic(addr.sun_path, path) == NULL) {
VIR_ERROR(_(Path %s too long for unix socket), path);
goto cleanup;
}
if (addr.sun_path[0] == '@')
addr.sun_path[0] = '\0';


So the first byte of the sun_path is '\0', something that Leopard
doesn't seem to like.
Breaking into gdb and setting the path manually to
/Users/ruben/.libvirt/libvirt-sock seems to work.

Regards,

Ruben

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] Initial working Mac OS X libvirt client build

2010-10-24 Thread Justin Clift 
On 10/25/2010 12:18 PM, Ruben Kerkhof wrote:
 On Sun, Oct 24, 2010 at 02:46, Justin Clift jcl...@redhat.com wrote:
 On 10/24/2010 09:33 AM, Ruben Kerkhof wrote:
 snip
 None at all, actually. I just started libvirtd on my local mac on
 which I also have VirtualBox installed.
 Speaking of which, it would be nice to have a launchctl file for
 libvirtd. I might be able to come up with something...

 Please do. It'd be nice to have that part working out of the box for
 people as well. :)
 
 For that to work, I'd like to run libvirtd as my own user, so I can
 add the launchtl file to my own Library directory.
 
 I'm curious, can you successfully run libvirtd as your own user (no sudo)?
 
 03:10:17.562: error : qemudListenUnix:582 : Failed to bind socket to
 '@/Users/ruben/.libvirt/libvirt-sock': No such file or directory

Actually, that looks familiar.  I think I tried the same thing, but was
ok running it as root instead after getting the same error.

I didn't look into it any more though. ;)


 Stepping through the code now, I see 2 (possible) issues:
 
 First: qemudInitPaths doesn't seem to create the ~/.libvirt directory
 Second: in qemudListenUnix, this piece of code:
 
 addr.sun_family = AF_UNIX;
 if (virStrcpyStatic(addr.sun_path, path) == NULL) {
 VIR_ERROR(_(Path %s too long for unix socket), path);
 goto cleanup;
 }
 if (addr.sun_path[0] == '@')
 addr.sun_path[0] = '\0';
 
 So the first byte of the sun_path is '\0', something that Leopard
 doesn't seem to like.
 Breaking into gdb and setting the path manually to
 /Users/ruben/.libvirt/libvirt-sock seems to work.

Interesting.  We can definitely pull together a temporary OSX workaround
patch for the moment (purely in the Homebrew formula).  But it would be
better to have a proper fix in libvirt instead.

How good is your C coding? :)

Regards and best wishes,

Justin Clift

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] Initial working Mac OS X libvirt client build

2010-10-23 Thread Ruben Kerkhof 
On Sat, Oct 23, 2010 at 20:15, Justin Clift jcl...@redhat.com wrote:
 On 10/23/2010 06:06 AM, Ruben Kerkhof wrote:
 snip
 It seems to have some problems with libxml2. I've also tried with
 libxml2-2.7.7 installed by brew, but that didn't help
 Readline has always been a problem on Tiger/Leopard. I remember
 something about it being libedit in readline-compatibility mode.

 It also looks like there's a specific readline formula in brew
 too.  Would you be ok to add a dependency for it to your libvirt
 formula, and try again?

 It'll just mean adding this line to your libvirt.rb formula file:

  depends_on readline

 (just add it after the existing 'depends_on gnutls' line)

 My understanding (which might need adjustment), is that the Homebrew
 readline build is normally hidden from things (keg_only).  This can
 be modified for a specific formula, by adding that depends_on line.

Ah, ok, I already had readline installed from brew, but that explains
it not being picked upt

 So, that's also worth a shot I reckon, to see if it stops those
 readline specific errors from turning up in the libvirt compile
 run.

 You ok to try it out?

 Regards and best wishes,

 Justin Clift

Works great, thanks!

Ruben

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] Initial working Mac OS X libvirt client build

2010-10-23 Thread Justin Clift 
On 10/24/2010 05:26 AM, Ruben Kerkhof wrote:
snip
 Works great, thanks!

Hey, that's good news. :)

That means we just need to figure the libxml2 errors out,
then we can tweak the libvirt formula so it works on Leopard as
well. :)

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] Initial working Mac OS X libvirt client build

2010-10-23 Thread Justin Clift 
On 10/24/2010 06:49 AM, Ruben Kerkhof wrote:
snip
 That depends_on line in the formula also works for libxml2 :-)

Hey, good work. :)

Looks like I need to tweak the libvirt formula next. ;

As a thought, what sort of connection URL did you use with virsh
in your example, and what sort of remote box were you connecting to?

Asking because I've been having troubles with qemu+ssh:// connections
to remote RHEL 6 and Fedora boxes, due to what I think is an interaction
with PolicyKit on the remote boxes.

Kind of thinking it won't happen for remote Ubuntu boxes though as
they don't have PolicyKit set up in the same way.

The more data I have around this, the better, just in case it turns out
to be something different. :)


--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] Initial working Mac OS X libvirt client build

2010-10-23 Thread Justin Clift 
On 10/24/2010 07:04 AM, Justin Clift wrote:
 On 10/24/2010 06:49 AM, Ruben Kerkhof wrote:
 snip
 That depends_on line in the formula also works for libxml2 :-)
 
 Hey, good work. :)
 
 Looks like I need to tweak the libvirt formula next. ;

Ruben, would you be ok to test the following code snippet for me,
in the libvirt formula?

if MACOS_VERSION  10.6
  # Needed on Leopard, but not Snow Leopard
  depends_on readline
  depends_on libxml2
end

If so, it should go after the other depends_on lines, like this:

depends_on gawk
depends_on gnutls

if MACOS_VERSION  10.6
  # Needed on Leopard, but not Snow Leopard
  depends_on readline
  depends_on libxml2
end

If that works, then we'll be able to get that into the libvirt
formula pronto. :)

Regards and best wishes,

Justin Clift



--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] Initial working Mac OS X libvirt client build

2010-10-23 Thread Justin Clift 
On 10/24/2010 09:28 AM, Ruben Kerkhof wrote:
snip
 Yes, this works perfectly.

Thanks.  Submitted that addition to the Homebrew guys, which hopefully
they'll get done soon.  Adam V is normally pretty responsive. :)

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] Initial working Mac OS X libvirt client build

2010-10-23 Thread Justin Clift 
On 10/24/2010 12:05 PM, Justin Clift wrote:
 On 10/24/2010 09:28 AM, Ruben Kerkhof wrote:
 snip
 Yes, this works perfectly.
 
 Thanks.  Submitted that addition to the Homebrew guys, which hopefully
 they'll get done soon.  Adam V is normally pretty responsive. :)

Done.  It's now in the main Homebrew libvirt formula.  Thanks Ruben. :)

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] Initial working Mac OS X libvirt client build

2010-10-22 Thread Justin Clift 
On 10/22/2010 05:18 PM, Ruben Kerkhof wrote:
snip
 I thought I'd give it a try, to see how far I get on Leopard (10.5).

Hey Ruben, thanks for the attempt. :)

Would you be ok to try a slightly updated version of the libvirt
formula?  If so, you just need to update the libvirt.rb formula file,
to use this url and md5:

  url
'http://justinclift.fedorapeople.org/libvirt_experimental/libvirt-0.8.4-7.tar.gz'
  md5 '2b8948e336070c94c5278ccd36495709'

It uses a somewhat newer source snapshot for libvirt than the previous
one, plus Mitchell Hashimoto has been hacking away at it to further
increase it's robustness on OSX.

No guarantees, but I think it's worth a shot, just in case. :)

?

Regards and best wishes,

Justin Clift

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] Initial working Mac OS X libvirt client build

2010-10-22 Thread Ruben Kerkhof 
On Fri, Oct 22, 2010 at 08:54, Justin Clift jcl...@redhat.com wrote:
 On 10/22/2010 05:18 PM, Ruben Kerkhof wrote:
 snip
 I thought I'd give it a try, to see how far I get on Leopard (10.5).

 Hey Ruben, thanks for the attempt. :)

 Would you be ok to try a slightly updated version of the libvirt
 formula?  If so, you just need to update the libvirt.rb formula file,
 to use this url and md5:

  url
 'http://justinclift.fedorapeople.org/libvirt_experimental/libvirt-0.8.4-7.tar.gz'
  md5 '2b8948e336070c94c5278ccd36495709'

 It uses a somewhat newer source snapshot for libvirt than the previous
 one, plus Mitchell Hashimoto has been hacking away at it to further
 increase it's robustness on OSX.

 No guarantees, but I think it's worth a shot, just in case. :)

 ?

Ah, great, I'll give it a shot when I get home in a few hours!

Thanks,

Ruben

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] Initial working Mac OS X libvirt client build

2010-10-22 Thread Mitchell Hashimoto 
On Thu, Oct 21, 2010 at 11:18 PM, Ruben Kerkhof ru...@rubenkerkhof.com wrote:

 I thought I'd give it a try, to see how far I get on Leopard (10.5).


From what I know following this list, I don't think anyone has ever
tried to compile for Leopard (10.5) and has focussed exclusively on
Snow Leopard (10.6), so there very well may be errors during
compilation/linking.

I'll wait for you to try the new formula but if that errors as well
then I may have to spin up  a leopard VM to play around see if I can
figure out what is going on there.

Mitchell

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] Initial working Mac OS X libvirt client build

2010-10-22 Thread Ruben Kerkhof 
On Fri, Oct 22, 2010 at 18:19, Mitchell Hashimoto
mitchell.hashim...@gmail.com wrote:
 On Thu, Oct 21, 2010 at 11:18 PM, Ruben Kerkhof ru...@rubenkerkhof.com 
 wrote:

 I thought I'd give it a try, to see how far I get on Leopard (10.5).


 From what I know following this list, I don't think anyone has ever
 tried to compile for Leopard (10.5) and has focussed exclusively on
 Snow Leopard (10.6), so there very well may be errors during
 compilation/linking.

 I'll wait for you to try the new formula but if that errors as well
 then I may have to spin up  a leopard VM to play around see if I can
 figure out what is going on there.

 Mitchell

It's getting a bit further, the logs are at http://fpaste.org/DC3R/

It seems to have some problems with libxml2. I've also tried with
libxml2-2.7.7 installed by brew, but that didn't help
Readline has always been a problem on Tiger/Leopard. I remember
something about it being libedit in readline-compatibility mode.

Thanks for your help!

Ruben

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] Initial working Mac OS X libvirt client build

2010-10-22 Thread Justin Clift 
On 10/23/2010 06:06 AM, Ruben Kerkhof wrote:
snip
 It's getting a bit further, the logs are at http://fpaste.org/DC3R/
 
 It seems to have some problems with libxml2.

Daniel, any idea what would cause this libxml2 failure?

  GEN virt-pki-validate
  GEN virt-xml-validate.1
  GEN virt-pki-validate.1
  GEN virsh.1
  CCLD virsh
  Undefined symbols:
  _xmlSaveToBuffer, referenced from:
  _cmdCPUBaseline in virsh-virsh.o
  _rl_completion_matches, referenced from:
  _vshReadlineCompletion in virsh-virsh.o
  _vshReadlineCompletion in virsh-virsh.o
  ld: symbol(s) not found
  collect2: ld returned 1 exit status
  make[3]: *** [virsh] Error 1
  make[2]: *** [all] Error 2
  make[1]: *** [all-recursive] Error 1
  make: *** [all] Error 2

Ruben, the readline one can probably be worked around in the short
term.  I've just submitted a patch to libvirt, allowing the use of
readline can be disabled.  (easiest way forward)

We'll need to figure out the libxml2 problem though.  Probably not
going to be today, more likely sometime next week. (with luck)

:)

Regards and best wishes,

Justin Clift

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] Initial working Mac OS X libvirt client build

2010-10-06 Thread Justin Clift 

On 09/22/2010 11:56 PM, Justin Clift wrote:
snip

As a follow up, our libvirt formula has been pulled into the
upstream repository, and is now available on OSX to everyone using
Homebrew:

  http://mxcl.github.com/homebrew/

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] Initial working Mac OS X libvirt client build

2010-09-22 Thread Daniel Veillard 
On Tue, Sep 21, 2010 at 04:37:26PM +1000, Justin Clift wrote:
 Hi all,
 
 This is for anyone using the Homebrew package management system on
 Mac OS X. :)
 
 A first working (but still experimental) libvirt formula is online:
 
   http://github.com/justinclift/libvirt
 
 It includes the libvirt text mode client (virsh), and the libvirt
 development libraries.
 
 If you have time to test it and report success/failure/(etc), please do.

  I would suggest to put the experimental binaries that you managed to
build on libvirt.org ~ftp/libvirt/osx/ , you should have write access
to that directory and this may help getting more people to try it out
even if limited. Just put a README or something along the binaries.
There is already old tarballs from May last year, we should probably
keep them for now,

Daniel

-- 
Daniel Veillard  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
dan...@veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] Initial working Mac OS X libvirt client build

2010-09-22 Thread Justin Clift 

On 09/22/2010 10:52 PM, Daniel Veillard wrote:
SNIP

If you have time to test it and report success/failure/(etc), please do.


   I would suggest to put the experimental binaries that you managed to
build on libvirt.org ~ftp/libvirt/osx/ , you should have write access
to that directory and this may help getting more people to try it out
even if limited. Just put a README or something along the binaries.


Thanks.  Will be looking at proper binary packages for it in a bit, so
that will be appropriate then. :)

The Homebrew packaging system is possibly a bit different from others.

It's a system that uses git as their main versioning tool, pulling from
a central git repository on github:

  http://github.com/mxcl/homebrew

The master branch there is used for the mainline stuff, and other 
branches are used for various other things.


People are encouraged to fork that on github, develop their own package
script(s), then submit them.  If accepted, they get pulled back into
the main git repository for everyone's use.

So, we're on track with this. :)

The github.com URL I gave before is a properly created fork (using the
github tools), and should be of direct use to a Homebrew user.

They can use that URL, and Homebrew will work with it.

Or so the theory goes. :





--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

[libvirt] Initial working Mac OS X libvirt client build

2010-09-21 Thread Justin Clift 

Hi all,

This is for anyone using the Homebrew package management system on Mac 
OS X. :)


A first working (but still experimental) libvirt formula is online:

  http://github.com/justinclift/libvirt

It includes the libvirt text mode client (virsh), and the libvirt 
development libraries.


If you have time to test it and report success/failure/(etc), please do.

Be aware, for the moment, it pulls down a tarred up snapshot of libvirt 
git, with a few trivial patches applied to make compiling work:


What works:

  + Remote connections using TLS (qemu+tls://)  -- encrypted
  + Remote connections using TCP (qemu+tls://)  -- not encrypted!

What doesn't work:

  + Remote connections using SSH (qemu+ssh://), if the server has
PolicyKit enabled. (possible bug, will look into it)

In theory, this means connecting to Ubuntu server should work,
as that uses groups to control access rather than PolicyKit.
Haven't tried it though, so if you do, please let me know how
it goes. ;)

Testing and feedback is encouraged.  The aim here is to have the libvirt 
client (virsh) plus development libraries work properly on OS X.


Please note, I'm new to OS X, github, and Homebrew, so if you notice 
things that should be done better/differently/etc, please let me know. :)


Regards and best wishes,

Justin Clift

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Re: [libvirt] Initial working Mac OS X libvirt client build

2010-09-21 Thread Matthias Bolte 
2010/9/21 Daniel P. Berrange berra...@redhat.com:
 On Tue, Sep 21, 2010 at 04:37:26PM +1000, Justin Clift wrote:
 Hi all,

 This is for anyone using the Homebrew package management system on Mac
 OS X. :)

 A first working (but still experimental) libvirt formula is online:

   http://github.com/justinclift/libvirt

 If this is intended to be rnu with proper release tarballs,
 then you should change autogen.sh to ./configure, so you avoid
 needing automake/autoconf/etc on OS-X.

 Also, does libvirtd not actually work ? If QEMU itself builds on
 OS-X, then in theory it ought to be possible to  build libvirtd
 and manage it.

 Do you need a depends_on for  libxml2  portablexdr too ?

 What's the situation with Python on OS-X ? Any liklihood of python
 bindings working  ?

 If you add curl + xmlrpc-c then the ESX driver ought to work. If
 there's a virtualbox port to OS-X that driver should work too.
 I'd be interest to see what configure prints as the summary for
 features it enabled...


The ESX driver needs libcurl only. libxmlrpc-c is for the OpenNebula driver.

There is a VirtualBox version for Intel Macs.

Matthias

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list