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
<hutao(a)cn.fujitsu.com>, 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.
I don't see any benefit in keeping this patch in the contrib
directory. Either it is correct and should be applied properly,
or it is incorrect and should be dropped. Leaving it in contrib
isn't helping anyone. It will be present in git history if anyone
wants to get it back later.
Regards,
Daniel
--
|: