On 01/12/22 12:26, Daniel P. Berrangé wrote:
> On Tue, Jan 11, 2022 at 11:22:56AM +0000, Richard W.M. Jones wrote:
>> On Tue, Jan 11, 2022 at 12:15:13PM +0100, Laszlo Ersek wrote:
>>> By the way, we have more "offenders" left:
>>>
>>> - three in "bundled/libvirt-ocaml/libvirt_c_common.c":
>>
>> I'm quite sure this happens in a lot of places.
>>
>> BTW libvirt-ocaml is a separate project, so fixes should go to:
>>
>> https://libvirt.org/git/?p=libvirt-ocaml.git;a=summary
>>
>> (and really we should remove all bundled code - I can't recall why it
>> was added, but it's not needed now.)
> 
> NB that's a read-only mirror, the primary repo is:
> 
>   https://gitlab.com/libvirt/libvirt-ocaml/
> 
> and takes patches via merge requests

What is the status of
"contrib/0001-Add-Libvirt.Domain.get_cpu_stats_total.patch"?

It is affected by the issue, but I totally don't want to touch it if the
patch is not actually applied. It is a patch from Hu Tao
<[email protected]>, from 2012, which got added in 2018 (commit
669cbc5a0ce1), but not actually merged. I can't see any machinery within
the project that would apply it.

My recommendation would be to just delete this directory (contrib). I
certainly can't do anyting about this patch (prove it right or wrong,
test it, etc). On the other hand, fixing some instances of

  Store_field (block, fieldnr, caml_copy_... (...));

but not the instance in this explicit patch, feels wrong.

If we can't drop the "contrib" directory, I'll abandon this effort.

Thanks
Laszlo

_______________________________________________
Libguestfs mailing list
[email protected]
https://listman.redhat.com/mailman/listinfo/libguestfs

Reply via email to