* Request to backport libvmi to krogoth @ 2018-11-17 9:28 HackDef 2018-11-21 14:40 ` Mark Asselstine 0 siblings, 1 reply; 5+ messages in thread From: HackDef @ 2018-11-17 9:28 UTC (permalink / raw) To: meta-virtualization [-- 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 --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Request to backport libvmi to krogoth 2018-11-17 9:28 Request to backport libvmi to krogoth HackDef @ 2018-11-21 14:40 ` Mark Asselstine 2018-11-21 17:15 ` HackDef 0 siblings, 1 reply; 5+ messages in thread From: Mark Asselstine @ 2018-11-21 14:40 UTC (permalink / raw) To: hackdef; +Cc: meta-virtualization 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Request to backport libvmi to krogoth 2018-11-21 14:40 ` Mark Asselstine @ 2018-11-21 17:15 ` HackDef 2018-11-21 17:56 ` Mark Asselstine 0 siblings, 1 reply; 5+ messages in thread From: HackDef @ 2018-11-21 17:15 UTC (permalink / raw) To: mark.asselstine; +Cc: meta-virtualization [-- 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 --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Request to backport libvmi to krogoth 2018-11-21 17:15 ` HackDef @ 2018-11-21 17:56 ` Mark Asselstine 2018-11-22 2:43 ` HackDef 0 siblings, 1 reply; 5+ messages in thread From: Mark Asselstine @ 2018-11-21 17:56 UTC (permalink / raw) To: hackdef; +Cc: meta-virtualization 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Request to backport libvmi to krogoth 2018-11-21 17:56 ` Mark Asselstine @ 2018-11-22 2:43 ` HackDef 0 siblings, 0 replies; 5+ messages in thread From: HackDef @ 2018-11-22 2:43 UTC (permalink / raw) To: mark.asselstine; +Cc: meta-virtualization [-- 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 --] ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2018-11-22 2:43 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-11-17 9:28 Request to backport libvmi to krogoth HackDef 2018-11-21 14:40 ` Mark Asselstine 2018-11-21 17:15 ` HackDef 2018-11-21 17:56 ` Mark Asselstine 2018-11-22 2:43 ` HackDef
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.