Open denix0 opened 2 years ago
Endorsed!
But is there a reasonable way for the
capture
module to support both generations of bitbake? My org will soon be maintaining two concurrent mainlines, one on bitbake1.38
and the other on >2.0
. I'd like to be able to continue using the pyrexmaster
ref on the old bitbake, if possible.Maybe pyrex can prefer to use whichever whitelist variable is defined within the container-host environment? Then at least the user can fixup their host to match their bitbake version.
FWIW, this is exactly the reason it hasn't been merged for 7 month.
My workaround - I use my fork with the patch applied for Kirkstone+ projects, and use the original for Dunfell- projects otherwise.
I hope @JoshuaWatt is able to figure out how to handle this :)
Endorsed! But is there a reasonable way for the
capture
module to support both generations of bitbake? My org will soon be maintaining two concurrent mainlines, one on bitbake1.38
and the other on >2.0
. I'd like to be able to continue using the pyrexmaster
ref on the old bitbake, if possible. Maybe pyrex can prefer to use whichever whitelist variable is defined within the container-host environment? Then at least the user can fixup their host to match their bitbake version.FWIW, this is exactly the reason it hasn't been merged for 7 month.
My workaround - I use my fork with the patch applied for Kirkstone+ projects, and use the original for Dunfell- projects otherwise.
I hope @JoshuaWatt is able to figure out how to handle this :)
Yep, it's on the TODO list; I was hoping we could figure out a way to do it without make separate releases, but I'm just not sure if that's going to work. If anyone has any ideas to make it work, let me know.
I believe this is resolved by #81 Please confirm and close if so
As part of OE-Core/Bitbake inclusive language variable renames.
Signed-off-by: Denys Dmytriyenko denis@denix.org