similar to: CI for nbdkit

On Wed, Oct 14, 2020 at 10:37:26AM +0100, Richard W.M. Jones wrote: > On Tue, Oct 13, 2020 at 03:21:35PM -0600, alan somers wrote: > > Would libguestfs be willing to enable CI for the nbdkit project?  It's very > > easy to set up, at least for the Rust portion.  I'm comfortable with both > > Cirrus CI and Github's native CI.  I can get it started if you agree to do

On Mon, Oct 19, 2020 at 10:58 AM alan somers <asomers@gmail.com> wrote: > On Wed, Oct 14, 2020 at 3:41 AM Daniel P. Berrangé <berrange@redhat.com> > wrote: > >> On Wed, Oct 14, 2020 at 10:37:26AM +0100, Richard W.M. Jones wrote: >> > On Tue, Oct 13, 2020 at 03:21:35PM -0600, alan somers wrote: >> > > Would libguestfs be willing to enable CI for the

On 6/17/20 6:23 AM, Richard W.M. Jones wrote: > I pushed 2 & 3, thanks. > > But ... > >> From 9fa3e443467e3c06761ec54241327e8daf8701ca Mon Sep 17 00:00:00 2001 >> From: Alan Somers <asomers@gmail.com> >> Date: Mon, 15 Jun 2020 16:59:53 -0600 >> Subject: [PATCH 1/3] Add a Cargo.toml file to the top-level directory >> >> This is necessary

I took the easy route of crippling what I couldn't get working, on the grounds that partial coverage is better than none now that we have Cirrus CI checking commits on additional platforms. This series got me to a green checkmark: https://gitlab.com/ebblake/nbdkit/-/pipelines/793156983 but depends on an as-yet uncommitted patch in libvirt-ci:

On 3/1/23 17:54, Eric Blake wrote: > I took the easy route of crippling what I couldn't get working, on the > grounds that partial coverage is better than none now that we have > Cirrus CI checking commits on additional platforms. > > This series got me to a green checkmark: > https://gitlab.com/ebblake/nbdkit/-/pipelines/793156983 > > but depends on an as-yet

On Wed, Oct 14, 2020 at 3:41 AM Daniel P. Berrangé <berrange@redhat.com> wrote: > On Wed, Oct 14, 2020 at 10:37:26AM +0100, Richard W.M. Jones wrote: > > On Tue, Oct 13, 2020 at 03:21:35PM -0600, alan somers wrote: > > > Would libguestfs be willing to enable CI for the nbdkit project? It's > very > > > easy to set up, at least for the Rust portion.

On Wed, Mar 01, 2023 at 06:43:11PM +0100, Laszlo Ersek wrote: > On 3/1/23 17:54, Eric Blake wrote: > > I took the easy route of crippling what I couldn't get working, on the > > grounds that partial coverage is better than none now that we have > > Cirrus CI checking commits on additional platforms. > > > > This series got me to a green checkmark: > >

On Wed, Jun 17, 2020 at 5:23 AM Richard W.M. Jones <rjones@redhat.com> wrote: > I pushed 2 & 3, thanks. > > But ... > > > From 9fa3e443467e3c06761ec54241327e8daf8701ca Mon Sep 17 00:00:00 2001 > > From: Alan Somers <asomers@gmail.com> > > Date: Mon, 15 Jun 2020 16:59:53 -0600 > > Subject: [PATCH 1/3] Add a Cargo.toml file to the top-level

On Tue, Oct 13, 2020 at 03:21:35PM -0600, alan somers wrote: > Would libguestfs be willing to enable CI for the nbdkit project?  It's very > easy to set up, at least for the Rust portion.  I'm comfortable with both > Cirrus CI and Github's native CI.  I can get it started if you agree to do it. Sure. Be aware we may move to gitlab (same as libvirt) at some point soon.

On Mon, Jun 15, 2020 at 02:22:32PM +0100, Richard W.M. Jones wrote: > On Thu, Jun 11, 2020 at 04:19:08PM -0600, alan somers wrote: > > The existing Rust bindings for nbdkit aren't very idiomatic Rust, and they > > are missing a lot of features. So I've rewritten them. The new bindings > > aren't backwards compatible, but I doubt that's a problem. Most

The existing Rust bindings for nbdkit aren't very idiomatic Rust, and they are missing a lot of features. So I've rewritten them. The new bindings aren't backwards compatible, but I doubt that's a problem. Most likely, nobody has tried to use them yet, since the crate hasn't even published to crates.io. Please review the attached patch. -Alan

On Wed, Jun 17, 2020 at 08:38:30AM -0600, alan somers wrote: > On Wed, Jun 17, 2020 at 7:33 AM Eric Blake <eblake@redhat.com> wrote: > > > On 6/17/20 6:23 AM, Richard W.M. Jones wrote: > > > I pushed 2 & 3, thanks. > > > > > > But ... > > > > > >> From 9fa3e443467e3c06761ec54241327e8daf8701ca Mon Sep 17 00:00:00 2001 > >

On Mon, Jun 15, 2020 at 08:11:47AM -0600, alan somers wrote: > On Mon, Jun 15, 2020 at 8:04 AM Daniel P. Berrangé <berrange@redhat.com> > wrote: > > > On Mon, Jun 15, 2020 at 02:22:32PM +0100, Richard W.M. Jones wrote: > > > On Thu, Jun 11, 2020 at 04:19:08PM -0600, alan somers wrote: > > > > The existing Rust bindings for nbdkit aren't very idiomatic

On Wed, Jun 17, 2020 at 7:33 AM Eric Blake <eblake@redhat.com> wrote: > On 6/17/20 6:23 AM, Richard W.M. Jones wrote: > > I pushed 2 & 3, thanks. > > > > But ... > > > >> From 9fa3e443467e3c06761ec54241327e8daf8701ca Mon Sep 17 00:00:00 2001 > >> From: Alan Somers <asomers@gmail.com> > >> Date: Mon, 15 Jun 2020 16:59:53 -0600

From: Alan Somers <asomers@gmail.com> There was a missing #include. It only worked on Linux due to header pollution. --- plugins/ssh/ssh.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/plugins/ssh/ssh.c b/plugins/ssh/ssh.c index ea199a93..a4007c40 100644 --- a/plugins/ssh/ssh.c +++ b/plugins/ssh/ssh.c @@ -30,6 +30,8 @@ * SUCH DAMAGE. */ +#include <sys/stat.h> +

Hi R developers, On R-devel (2020-06-24 r78746) I am getting those two new exceptions during R check. I found a change which eventually may be related https://github.com/wch/r-source/commit/69de92b9fb1b7f2a7c8d1394b8d56050881a5465 I think this may be a regression. I grep'ed package manuals and R code for unique.default but don't see any. Usage section of the unique method looks fine as

>>>>> Jan Gorecki writes: > So the unique.default is from the R tools package during checks. > I don't see those issues on CRAN checks. I cannot reproduce this locally (and have no clues about docker). Perhaps you can try to debug this on your end? And see what env_list is when the error occurs? Best -k > Exact environment where I am reproducing this issue is a

[To continue the conversation from https://github.com/libguestfs/nbdkit/issues/5] > Currently there's no way for the Rust plugin to report an error. The > idiomatic way to do it would be for each callback to return a Result > object, much like how the Go plugin currently does it. I'm sure it's not idiomatic for Rust, but I just wanted to say that there is a way to return an

On Tue, Mar 21, 2023 at 07:04:59AM +0100, Laszlo Ersek wrote: > On 3/20/23 20:41, Eric Blake wrote: > > On Sun, Mar 19, 2023 at 10:41:37AM +0100, Laszlo Ersek wrote: > >> This is version 4 of the following sub-series: > >> > >> [libnbd PATCH v3 09/29] lib/utils: introduce async-signal-safe execvpe() > >> [libnbd PATCH v3 10/29] lib/utils: add unit tests