On Tue, Feb 05, 2008 at 12:53:57AM +0100, Loic Dachary wrote:
> In reply to
>
> http://www.redhat.com/archives/libvir-list/2007-April/msg00177.html
>
> an area where vde_switch support is usefull is an unprivileged user
> running tests. A test suite involving the creation of qemu instances
> th
In reply to
http://www.redhat.com/archives/libvir-list/2007-April/msg00177.html
an area where vde_switch support is usefull is an unprivileged user
running tests. A test suite involving the creation of qemu instances
thru libvirt should not be forced to create a bridge or alter the
iptables c
I noticed a little glitch here:
src/xml.c: virBufferAdd(buf, "(usbdevice tablet)", 13);
src/xml.c: virBufferAdd(buf, "(usbdevice tablet)", 18);
So I mounted a campaign to remove all such uses of virBufferAdd
and make sure no more sneak back in.
First, I added this definition:
On Mon, Feb 04, 2008 at 06:45:33PM +, Daniel P. Berrange wrote:
> On Mon, Feb 04, 2008 at 06:42:01PM +, Richard W.M. Jones wrote:
> > Jim Meyering wrote:
> > I looked into it, and there is a show-trailing-whitespace variable in
> > emacs, so one might consider modifying our "standard" trai
"Daniel P. Berrange" <[EMAIL PROTECTED]> wrote:
> (require 'show-wspace)
> (add-hook 'font-lock-mode-hook 'highlight-trailing-whitespace)
>
> Which does the trick for me
I've found it useful to highlight space-before-TAB
and blank-lines-at-EOB, too.
(when window-system
;;; Create faces for high
Daniel P. Berrange wrote:
[...]
Looks good, but needs to update the documentation too.
Rich.
--
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod
Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in
On Mon, Feb 04, 2008 at 06:42:01PM +, Richard W.M. Jones wrote:
> Jim Meyering wrote:
> >Any objection to a mass removal of trailing blanks?
> >
> >[ If you haven't yet been adversely affected by e.g., pointless conflicts
> > due solely to differences in white space, count yourself lucky, and
Jim Meyering wrote:
Any objection to a mass removal of trailing blanks?
[ If you haven't yet been adversely affected by e.g., pointless conflicts
due solely to differences in white space, count yourself lucky, and
chalk it up to not having to deal with many branches.
The sooner we do this
"Richard W.M. Jones" <[EMAIL PROTECTED]> wrote:
> Jim Meyering wrote:
>> -error (flags & REMOTE_CALL_IN_OPEN ? NULL : conn, VIR_ERR_RPC,
>> "xdr_int (length word)");
>> +error (flags & REMOTE_CALL_IN_OPEN ? NULL : conn, VIR_ERR_RPC,
>> _("xdr_int (length word)"));
>
> +1 to the p
On Mon, Feb 04, 2008 at 06:31:17PM +, Richard W.M. Jones wrote:
> Jim Meyering wrote:
> >-error (flags & REMOTE_CALL_IN_OPEN ? NULL : conn, VIR_ERR_RPC,
> >"xdr_int (length word)");
> >+error (flags & REMOTE_CALL_IN_OPEN ? NULL : conn, VIR_ERR_RPC,
> >_("xdr_int (length word)"
Jim Meyering wrote:
-error (flags & REMOTE_CALL_IN_OPEN ? NULL : conn, VIR_ERR_RPC, "xdr_int
(length word)");
+error (flags & REMOTE_CALL_IN_OPEN ? NULL : conn, VIR_ERR_RPC, _("xdr_int
(length word)"));
+1 to the patch, but I wonder what translators will make of errors like
t
Jim Meyering wrote:
This change marks for translation some more messages.
It adds a few new ones, too, e.g., replacing "domain" with
_("failed to parse domain description") in two places.
Likewise, there are some like this:
-virXendError (conn, VIR_ERR_NO_MEMORY, "strdup");
+
Any objection to a mass removal of trailing blanks?
[ If you haven't yet been adversely affected by e.g., pointless conflicts
due solely to differences in white space, count yourself lucky, and
chalk it up to not having to deal with many branches.
The sooner we do this the better, IME. ]
I'
This change marks for translation some more messages.
It adds a few new ones, too, e.g., replacing "domain" with
_("failed to parse domain description") in two places.
Likewise, there are some like this:
-virXendError (conn, VIR_ERR_NO_MEMORY, "strdup");
+virXendError (con
On Mon, Feb 04, 2008 at 09:44:12AM -0500, Daniel Veillard wrote:
>
> So basically Xen PV, Xen FV and KVM blocks should now share the
> same set of functionalities, sharight the same syntax, right ? And the
> refactoring comes from the 3 being able to share more code, if yes that
> sounds excel
On Mon, Feb 04, 2008 at 12:36:29PM +0100, Jim Meyering wrote:
> This makes it so some diagnostics emitted via the error function
> are checked for use of "_(...)" when you run "make syntax-check",
> and fixes the ones that lacked that:
>
> Enable the sc_unmarked_diagnostics test and correct
On Sun, Feb 03, 2008 at 06:47:18PM +, Daniel P. Berrange wrote:
> The latest xen-unstable tree has support for booting HVM guests using an
> explicit kernel+initrd+cmdline, as an alternative to the traditional BIOS
> boot from harddisk/cdrom/network. This gives Xen HVM parity with KVM in
> ter
This makes it so some diagnostics emitted via the error function
are checked for use of "_(...)" when you run "make syntax-check",
and fixes the ones that lacked that:
Enable the sc_unmarked_diagnostics test and correct all violations
involving the "error" function.
* Makef
Brecht Sanders wrote:
Did you have a win32 Python version of gconf?
Nope.
Please CC questions to libvir-list so that everyone can see questions &
answers.
Rich.
--
Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Pea
19 matches
Mail list logo
