On Mon, Sep 19, 2022 at 16:31:25 +0000, Vishal Gupta (vishagu2) wrote: > Hi Peter , Hi, I firstly want to ask you to avoid top-posting on technical mailing lists. > > > > Thanks for ur reply . > > > > Kirkstone is the latest release from Yocto foundation . details https://docs.yoctoproject.org/dev/migration-guides/migration-4.0.html > > > > Kirkstone support libvirt 8.10 https://layers.openembedded.org/layerindex/recipe/3052/ > > > > We are trying to port 2016 smack patch " https://listman.redhat.com/archives/libvir-list/2016-July/msg00456.html"; for libvirt which is based on automake make file Okay so that is quite an old patch which was never finished and merged. > But above patch is incompatible with libvirt 8.10 .as libvirt 8.1 supports only meson > > > I was just wondering if above smack patch is already ported for meson based libvirt 8.10? > > We have issue in porting m4/virt-smack.m4 to meson.build file . virt-smack.m4 is define in 2016 smack patch No it is not ported. I want to warn you though that porting the build system part to meson will not be biggest of the problems. 1) The patch is more than 6 years old at this point There's quite a lot of change in libvirt during that time. Many helpers and internal APIs were refactored. The patch even once you port the build system will require *significant* rework to actually even compile. 2) libsmack (smack-utils) used by the new security module is not present in distros The library it requires doesn't seem to be adopted much: https://repology.org/project/smack-utils/versions Did you make sure that it's present in your environment? Additionally if you want to get the patch accepted upstream note that there were outstanding problems with the patch in the last version which is on the mailing list. I can see that there are definitely problems with coding style and the patch will need to be split to logical chunks as it's now just a big blob of code. Also given that the library is simply not present in distros it will require a justification why upstream should cary the patch. Carying code which is not compiled because of lack of dependencies is a burden to upstream and still can bitrot in the future. Even if you are not striving for upstreaming the patch, be prepared for more work than just porting the build system.
