Request to backport libvmi to krogoth

Request to backport libvmi to krogoth

[HackDef]

[-- Attachment #1: Type: text/plain, Size: 632 bytes --]

Recently libvmi recipe was added to meta-virtualization on master branch:

http://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/tree/recipes-extended/libvmi/libvmi_git.bb

But I use krogoth branch with my current board, so, tried to copy the
recipe to krogoth branch but throw error on libvirt about: *Nothing
PROVIDES libxl*, then added new dependencies found on libvirt from master
and now throws: *Nothing PROVIDES libdevmapper,* so I guess the best
approach should be to request backporting libvmi to krogoth branch.

Your help is much appreciated.

Please let me know if possible.

Thanks

--
Hector

[-- Attachment #2: Type: text/html, Size: 997 bytes --]

Re: Request to backport libvmi to krogoth

[Mark Asselstine]

On Sat, Nov 17, 2018 at 4:29 AM HackDef <hackdef@hack-defender.mx> wrote:
>
> Recently libvmi recipe was added to meta-virtualization on master branch:
>
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/tree/recipes-extended/libvmi/libvmi_git.bb
>
> But I use krogoth branch with my current board, so, tried to copy the recipe to krogoth branch but throw error on libvirt about: Nothing PROVIDES libxl, then added new dependencies found on libvirt from master and now throws: Nothing PROVIDES libdevmapper, so I guess the best approach should be to request backporting libvmi to krogoth branch.
>
> Your help is much appreciated.

Hector,

So what would have happened is krogoth was branched and then at some
later time a commit was applied to master which added the
libvmi_git.bb recipe. So start by using git to identify this commit,
you can do this while on the krogoth branch still
ie.: git log master -- ./recipes-extended/libvmi/libvmi_git.bb

This will identify commit e2ab59ec3e4b547da635cda725090d42126dcfd2 as
the commit which brought in the libvmi_git.bb recipe, so cherry-pick
it
ie: git cherry-pick e2ab59ec3e4b547da635cda725090d42126dcfd2

Now attempt to build it 'bitbake libvmi', as you have indicated this
most likely fail as libvirt will require libxl. DO NOT port the
libvirt recipe from master back to krogoth, libvirt has been around
for ages in meta-virtualization and libvmi does not have a version
dependency on libvirt. Instead when you inspect the libvirt recipe
already present on the krogoth branch you will see that libxl is a
dependency we can control, we need to ensure we have a suitable
PACKAGECONFIG for libvirt AND that "xen" is not set in the
DISTRO_FEATURES. By default neither of these are set so without having
access to your build I don't know where you are setting either of
these, you will have to use bitbake -e libvmi or similar to find out
where your build is setting either of these and mitigate against this.

Try the above and follow up and we can then move on with any other
bits. It is important that you can prep the backport as you have the
krogoth build ready to go along with a usecase to test the backport,
something Bruce will not have.

Regards,
Mark



>
> Please let me know if possible.
>
> Thanks
>
> --
> Hector
> --
> _______________________________________________
> meta-virtualization mailing list
> meta-virtualization@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-virtualization

Re: Request to backport libvmi to krogoth

[HackDef]

[-- Attachment #1: Type: text/plain, Size: 3068 bytes --]

Thanks Mark for the great recommendation.
Something that I tried so far and worked was to remove the libvirt
dependency in the libvmi recipe (since it is not needed by xen).

But your recommendation is great for other cases that wont be fixed by a
simple dependency removal.

Will check it out. Thanks.

On Wed, Nov 21, 2018 at 6:40 AM Mark Asselstine <
mark.asselstine@windriver.com> wrote:

> On Sat, Nov 17, 2018 at 4:29 AM HackDef <hackdef@hack-defender.mx> wrote:
> >
> > Recently libvmi recipe was added to meta-virtualization on master branch:
> >
> >
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/tree/recipes-extended/libvmi/libvmi_git.bb
> >
> > But I use krogoth branch with my current board, so, tried to copy the
> recipe to krogoth branch but throw error on libvirt about: Nothing PROVIDES
> libxl, then added new dependencies found on libvirt from master and now
> throws: Nothing PROVIDES libdevmapper, so I guess the best approach should
> be to request backporting libvmi to krogoth branch.
> >
> > Your help is much appreciated.
>
> Hector,
>
> So what would have happened is krogoth was branched and then at some
> later time a commit was applied to master which added the
> libvmi_git.bb recipe. So start by using git to identify this commit,
> you can do this while on the krogoth branch still
> ie.: git log master -- ./recipes-extended/libvmi/libvmi_git.bb
>
> This will identify commit e2ab59ec3e4b547da635cda725090d42126dcfd2 as
> the commit which brought in the libvmi_git.bb recipe, so cherry-pick
> it
> ie: git cherry-pick e2ab59ec3e4b547da635cda725090d42126dcfd2
>
> Now attempt to build it 'bitbake libvmi', as you have indicated this
> most likely fail as libvirt will require libxl. DO NOT port the
> libvirt recipe from master back to krogoth, libvirt has been around
> for ages in meta-virtualization and libvmi does not have a version
> dependency on libvirt. Instead when you inspect the libvirt recipe
> already present on the krogoth branch you will see that libxl is a
> dependency we can control, we need to ensure we have a suitable
> PACKAGECONFIG for libvirt AND that "xen" is not set in the
> DISTRO_FEATURES. By default neither of these are set so without having
> access to your build I don't know where you are setting either of
> these, you will have to use bitbake -e libvmi or similar to find out
> where your build is setting either of these and mitigate against this.
>
> Try the above and follow up and we can then move on with any other
> bits. It is important that you can prep the backport as you have the
> krogoth build ready to go along with a usecase to test the backport,
> something Bruce will not have.
>
> Regards,
> Mark
>
>
>
> >
> > Please let me know if possible.
> >
> > Thanks
> >
> > --
> > Hector
> > --
> > _______________________________________________
> > meta-virtualization mailing list
> > meta-virtualization@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/meta-virtualization
>

[-- Attachment #2: Type: text/html, Size: 4158 bytes --]

Re: Request to backport libvmi to krogoth

[Mark Asselstine]

On Wed, Nov 21, 2018 at 12:16 PM HackDef <hackdef@hack-defender.mx> wrote:
>
> Thanks Mark for the great recommendation.
> Something that I tried so far and worked was to remove the libvirt dependency in the libvmi recipe (since it is not needed by xen).
>
> But your recommendation is great for other cases that wont be fixed by a simple dependency removal.
>
> Will check it out. Thanks.

To be honest I would have to go look at the origin of the 'libxl'
dependency, I don't believe there is a recipe for this or any recipe
which provides this in the 'master' branch of any of the main Yocto
repos. At least nothing that is found in the index
(https://layers.openembedded.org/layerindex/branch/master/recipes/).

At any rate at this point you should be able to follow up to the list
to ask Bruce to cherry pick the libvmi commit to krogoth.

Mark


>
> On Wed, Nov 21, 2018 at 6:40 AM Mark Asselstine <mark.asselstine@windriver.com> wrote:
>>
>> On Sat, Nov 17, 2018 at 4:29 AM HackDef <hackdef@hack-defender.mx> wrote:
>> >
>> > Recently libvmi recipe was added to meta-virtualization on master branch:
>> >
>> > http://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/tree/recipes-extended/libvmi/libvmi_git.bb
>> >
>> > But I use krogoth branch with my current board, so, tried to copy the recipe to krogoth branch but throw error on libvirt about: Nothing PROVIDES libxl, then added new dependencies found on libvirt from master and now throws: Nothing PROVIDES libdevmapper, so I guess the best approach should be to request backporting libvmi to krogoth branch.
>> >
>> > Your help is much appreciated.
>>
>> Hector,
>>
>> So what would have happened is krogoth was branched and then at some
>> later time a commit was applied to master which added the
>> libvmi_git.bb recipe. So start by using git to identify this commit,
>> you can do this while on the krogoth branch still
>> ie.: git log master -- ./recipes-extended/libvmi/libvmi_git.bb
>>
>> This will identify commit e2ab59ec3e4b547da635cda725090d42126dcfd2 as
>> the commit which brought in the libvmi_git.bb recipe, so cherry-pick
>> it
>> ie: git cherry-pick e2ab59ec3e4b547da635cda725090d42126dcfd2
>>
>> Now attempt to build it 'bitbake libvmi', as you have indicated this
>> most likely fail as libvirt will require libxl. DO NOT port the
>> libvirt recipe from master back to krogoth, libvirt has been around
>> for ages in meta-virtualization and libvmi does not have a version
>> dependency on libvirt. Instead when you inspect the libvirt recipe
>> already present on the krogoth branch you will see that libxl is a
>> dependency we can control, we need to ensure we have a suitable
>> PACKAGECONFIG for libvirt AND that "xen" is not set in the
>> DISTRO_FEATURES. By default neither of these are set so without having
>> access to your build I don't know where you are setting either of
>> these, you will have to use bitbake -e libvmi or similar to find out
>> where your build is setting either of these and mitigate against this.
>>
>> Try the above and follow up and we can then move on with any other
>> bits. It is important that you can prep the backport as you have the
>> krogoth build ready to go along with a usecase to test the backport,
>> something Bruce will not have.
>>
>> Regards,
>> Mark
>>
>>
>>
>> >
>> > Please let me know if possible.
>> >
>> > Thanks
>> >
>> > --
>> > Hector
>> > --
>> > _______________________________________________
>> > meta-virtualization mailing list
>> > meta-virtualization@yoctoproject.org
>> > https://lists.yoctoproject.org/listinfo/meta-virtualization
>
> --
> _______________________________________________
> meta-virtualization mailing list
> meta-virtualization@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-virtualization

Re: Request to backport libvmi to krogoth

[HackDef]

[-- Attachment #1: Type: text/plain, Size: 4193 bytes --]

Will do Mark, thanks!

On Wed, Nov 21, 2018 at 9:56 AM Mark Asselstine <
mark.asselstine@windriver.com> wrote:

> On Wed, Nov 21, 2018 at 12:16 PM HackDef <hackdef@hack-defender.mx> wrote:
> >
> > Thanks Mark for the great recommendation.
> > Something that I tried so far and worked was to remove the libvirt
> dependency in the libvmi recipe (since it is not needed by xen).
> >
> > But your recommendation is great for other cases that wont be fixed by a
> simple dependency removal.
> >
> > Will check it out. Thanks.
>
> To be honest I would have to go look at the origin of the 'libxl'
> dependency, I don't believe there is a recipe for this or any recipe
> which provides this in the 'master' branch of any of the main Yocto
> repos. At least nothing that is found in the index
> (https://layers.openembedded.org/layerindex/branch/master/recipes/).
>
> At any rate at this point you should be able to follow up to the list
> to ask Bruce to cherry pick the libvmi commit to krogoth.
>
> Mark
>
>
> >
> > On Wed, Nov 21, 2018 at 6:40 AM Mark Asselstine <
> mark.asselstine@windriver.com> wrote:
> >>
> >> On Sat, Nov 17, 2018 at 4:29 AM HackDef <hackdef@hack-defender.mx>
> wrote:
> >> >
> >> > Recently libvmi recipe was added to meta-virtualization on master
> branch:
> >> >
> >> >
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/tree/recipes-extended/libvmi/libvmi_git.bb
> >> >
> >> > But I use krogoth branch with my current board, so, tried to copy the
> recipe to krogoth branch but throw error on libvirt about: Nothing PROVIDES
> libxl, then added new dependencies found on libvirt from master and now
> throws: Nothing PROVIDES libdevmapper, so I guess the best approach should
> be to request backporting libvmi to krogoth branch.
> >> >
> >> > Your help is much appreciated.
> >>
> >> Hector,
> >>
> >> So what would have happened is krogoth was branched and then at some
> >> later time a commit was applied to master which added the
> >> libvmi_git.bb recipe. So start by using git to identify this commit,
> >> you can do this while on the krogoth branch still
> >> ie.: git log master -- ./recipes-extended/libvmi/libvmi_git.bb
> >>
> >> This will identify commit e2ab59ec3e4b547da635cda725090d42126dcfd2 as
> >> the commit which brought in the libvmi_git.bb recipe, so cherry-pick
> >> it
> >> ie: git cherry-pick e2ab59ec3e4b547da635cda725090d42126dcfd2
> >>
> >> Now attempt to build it 'bitbake libvmi', as you have indicated this
> >> most likely fail as libvirt will require libxl. DO NOT port the
> >> libvirt recipe from master back to krogoth, libvirt has been around
> >> for ages in meta-virtualization and libvmi does not have a version
> >> dependency on libvirt. Instead when you inspect the libvirt recipe
> >> already present on the krogoth branch you will see that libxl is a
> >> dependency we can control, we need to ensure we have a suitable
> >> PACKAGECONFIG for libvirt AND that "xen" is not set in the
> >> DISTRO_FEATURES. By default neither of these are set so without having
> >> access to your build I don't know where you are setting either of
> >> these, you will have to use bitbake -e libvmi or similar to find out
> >> where your build is setting either of these and mitigate against this.
> >>
> >> Try the above and follow up and we can then move on with any other
> >> bits. It is important that you can prep the backport as you have the
> >> krogoth build ready to go along with a usecase to test the backport,
> >> something Bruce will not have.
> >>
> >> Regards,
> >> Mark
> >>
> >>
> >>
> >> >
> >> > Please let me know if possible.
> >> >
> >> > Thanks
> >> >
> >> > --
> >> > Hector
> >> > --
> >> > _______________________________________________
> >> > meta-virtualization mailing list
> >> > meta-virtualization@yoctoproject.org
> >> > https://lists.yoctoproject.org/listinfo/meta-virtualization
> >
> > --
> > _______________________________________________
> > meta-virtualization mailing list
> > meta-virtualization@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/meta-virtualization
>

[-- Attachment #2: Type: text/html, Size: 6142 bytes --]