Displaying 5 results from an estimated 5 matches for "msg00268".
Did you mean:
msg00261
2009 Nov 26
1
[PATCH 2/2] daemon: Link guestfs_protocol.[ch] into the daemon directory.
I haven't received this yet, but read from the archive:
https://www.redhat.com/archives/libguestfs/2009-November/msg00268.html
The only suspicious part is the trailing ".c" on the command below:
+$(libsrcdir)/guestfs_protocol.c: force
+ $(MAKE) -C $(libsrcdir) guestfs_protocol.c
+$(libsrcdir)/guestfs_protocol.h: force
+ $(MAKE) -C $(libsrcdir) guestfs_protocol.c
Shouldn't that be .h?
2017 May 02
2
[PATCH v2] launch: Error if you try to launch with too many drives.
v1 was here:
https://www.redhat.com/archives/libguestfs/2017-April/msg00268.html
v1 broke some tests because the guestfs_max_disks API isn't supported
by some backends, specifically ?unix:?. This makes failure of
guestfs_max_disks non-fatal.
Rich.
2015 Feb 02
0
updated R-cairo bridge, official R-3.1.*-mavericks.pkg crippled, snpMatrix 1.19.0.20
.... I'd be interested
in anybody supplies an example to demonstrate snpStats 1.17.0 being buggy also.
I haven't decided what to do with link-time optimization of the OS X build -
Xcode/Clang is the default on OS X though gcc is more familiar
(https://gcc.gnu.org/ml/gcc-testresults/2014-11/msg00268.html) so I probably
will do both and see which one is better at some point.
The package uploads (12 in all, 2 packages x 3 R versions x 2 builds)
are now divided by R versions - those in unversion'ed directories are still for R 2.x.
--------------------------------------------
On Wed, 21/1/1...
2012 Aug 08
13
[PATCH] tools: don't expand prefix and exec_prefix too early
A comment in tools/configure says that it is intended for these to be
command line overridable, so they shouldn''t get expanded at configure
time.
The patch is fixing tools/m4/default_lib.m4 as far as I can see myself
doing this, but imo it is flawed altogether and should rather be
removed:
- setting prefix and exec_prefix to default values is being done later
in tools/configure anyway
2020 Aug 20
15
[PATCH nbdkit 0/13] Port to Windows without using a separate library.
...ate library. Instead, on Windows only, we build an "import
library" (library of stubs) which resolves references to nbdkit_*
functions in the main program and fixes up the plugin, basically the
first technique outlined in this email:
https://www.redhat.com/archives/libguestfs/2020-August/msg00268.html
Most tests fail, unsurprisingly. The vast majority fail because we
lack support for Unix domain sockets. There is some hope that we
could add this:
https://devblogs.microsoft.com/commandline/af_unix-comes-to-windows/
Although this could fix many tests, it's probably not going to be very...