[PATCH] image_types: Fix bmaptool support for RSS

[PATCH] image_types: Fix bmaptool support for RSS

[Tom Rini]

With RSS we need to ensure that when making a bmap image that the
python3 that we created is found via /usr/bin/env rather than the host
python3.  Otherwise we're relying on the build host to have bmaptool
support installed.

Signed-off-by: Tom Rini <trini@konsulko.com>
---
I played around with a few ways to try and fix this problem, and this
was the best I could come up with.  Once this is in we need this in pyro
as well as it's broken there too.
---
 meta/classes/image_types.bbclass | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index 61dca626311e..3ff960e3a889 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -311,3 +311,6 @@ DEPLOYABLE_IMAGE_TYPES ?= "hddimg iso"
 # The IMAGE_TYPES_MASKED variable will be used to mask out from the IMAGE_FSTYPES,
 # images that will not be built at do_rootfs time: vmdk, vdi, qcow2, hdddirect, hddimg, iso, etc.
 IMAGE_TYPES_MASKED ?= ""
+
+# bmap requires python3 to be in the PATH
+EXTRANATIVEPATH += "${@'python3-native' if d.getVar('IMAGE_FSTYPES').find('bmap') else ''}"
-- 
1.9.1

Re: [PATCH] image_types: Fix bmaptool support for RSS

[Burton, Ross]

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

On 27 September 2017 at 18:00, Tom Rini <trini@konsulko.com> wrote:

> With RSS we need to ensure that when making a bmap image that the
> python3 that we created is found via /usr/bin/env rather than the host
> python3.  Otherwise we're relying on the build host to have bmaptool
> support installed.
>
> Signed-off-by: Tom Rini <trini@konsulko.com>
> ---
> I played around with a few ways to try and fix this problem, and this
> was the best I could come up with.  Once this is in we need this in pyro
> as well as it's broken there too.
>

Doesn't bmap in Pyro use Python 2?

Ross

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

Re: [PATCH] image_types: Fix bmaptool support for RSS

[Tom Rini]

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

On Wed, Sep 27, 2017 at 06:10:58PM +0100, Burton, Ross wrote:
> On 27 September 2017 at 18:00, Tom Rini <trini@konsulko.com> wrote:
> 
> > With RSS we need to ensure that when making a bmap image that the
> > python3 that we created is found via /usr/bin/env rather than the host
> > python3.  Otherwise we're relying on the build host to have bmaptool
> > support installed.
> >
> > Signed-off-by: Tom Rini <trini@konsulko.com>
> > ---
> > I played around with a few ways to try and fix this problem, and this
> > was the best I could come up with.  Once this is in we need this in pyro
> > as well as it's broken there too.
> 
> Doesn't bmap in Pyro use Python 2?

I hadn't tested my fix in pyro yet, only confirmed that it was broken
there.  I'll check and get back to you on that part.

-- 
Tom

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] image_types: Fix bmaptool support for RSS

[Tom Rini]

On Wed, Sep 27, 2017 at 01:52:18PM -0400, Tom Rini wrote:
> On Wed, Sep 27, 2017 at 06:10:58PM +0100, Burton, Ross wrote:
> > On 27 September 2017 at 18:00, Tom Rini <trini@konsulko.com> wrote:
> > 
> > > With RSS we need to ensure that when making a bmap image that the
> > > python3 that we created is found via /usr/bin/env rather than the host
> > > python3.  Otherwise we're relying on the build host to have bmaptool
> > > support installed.
> > >
> > > Signed-off-by: Tom Rini <trini@konsulko.com>
> > > ---
> > > I played around with a few ways to try and fix this problem, and this
> > > was the best I could come up with.  Once this is in we need this in pyro
> > > as well as it's broken there too.
> > 
> > Doesn't bmap in Pyro use Python 2?
> 
> I hadn't tested my fix in pyro yet, only confirmed that it was broken
> there.  I'll check and get back to you on that part.

OK, I need to investigate the pyro failure I saw more to see what else
was going in there.  Just oe-core pyro is fine as bamptool uses python2
and .../recipe-sysroot-native/usr/bin/bmaptool is /usr/bin/env
nativepython which is also in usr/bin and is thus found.

-- 
Tom

Re: [PATCH] image_types: Fix bmaptool support for RSS

[Khem Raj]

On Wed, Sep 27, 2017 at 10:00 AM, Tom Rini <trini@konsulko.com> wrote:
> With RSS we need to ensure that when making a bmap image that the
> python3 that we created is found via /usr/bin/env rather than the host
> python3.  Otherwise we're relying on the build host to have bmaptool
> support installed.
>
> Signed-off-by: Tom Rini <trini@konsulko.com>
> ---
> I played around with a few ways to try and fix this problem, and this
> was the best I could come up with.  Once this is in we need this in pyro
> as well as it's broken there too.
> ---
>  meta/classes/image_types.bbclass | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
> index 61dca626311e..3ff960e3a889 100644
> --- a/meta/classes/image_types.bbclass
> +++ b/meta/classes/image_types.bbclass
> @@ -311,3 +311,6 @@ DEPLOYABLE_IMAGE_TYPES ?= "hddimg iso"
>  # The IMAGE_TYPES_MASKED variable will be used to mask out from the IMAGE_FSTYPES,
>  # images that will not be built at do_rootfs time: vmdk, vdi, qcow2, hdddirect, hddimg, iso, etc.
>  IMAGE_TYPES_MASKED ?= ""
> +
> +# bmap requires python3 to be in the PATH
> +EXTRANATIVEPATH += "${@'python3-native' if d.getVar('IMAGE_FSTYPES').find('bmap') else ''}"
> --

I think somewhere inherit python3native should fix it.

> 1.9.1
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [PATCH] image_types: Fix bmaptool support for RSS

[Tom Rini]

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

On Wed, Sep 27, 2017 at 02:01:43PM -0700, Khem Raj wrote:
> On Wed, Sep 27, 2017 at 10:00 AM, Tom Rini <trini@konsulko.com> wrote:
> > With RSS we need to ensure that when making a bmap image that the
> > python3 that we created is found via /usr/bin/env rather than the host
> > python3.  Otherwise we're relying on the build host to have bmaptool
> > support installed.
> >
> > Signed-off-by: Tom Rini <trini@konsulko.com>
> > ---
> > I played around with a few ways to try and fix this problem, and this
> > was the best I could come up with.  Once this is in we need this in pyro
> > as well as it's broken there too.
> > ---
> >  meta/classes/image_types.bbclass | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
> > index 61dca626311e..3ff960e3a889 100644
> > --- a/meta/classes/image_types.bbclass
> > +++ b/meta/classes/image_types.bbclass
> > @@ -311,3 +311,6 @@ DEPLOYABLE_IMAGE_TYPES ?= "hddimg iso"
> >  # The IMAGE_TYPES_MASKED variable will be used to mask out from the IMAGE_FSTYPES,
> >  # images that will not be built at do_rootfs time: vmdk, vdi, qcow2, hdddirect, hddimg, iso, etc.
> >  IMAGE_TYPES_MASKED ?= ""
> > +
> > +# bmap requires python3 to be in the PATH
> > +EXTRANATIVEPATH += "${@'python3-native' if d.getVar('IMAGE_FSTYPES').find('bmap') else ''}"
> > --
> 
> I think somewhere inherit python3native should fix it.

Yes, image_types.bbclass could also inherit python3native but that
seemed heavy-handed.  There's not some other place that should be doing
it as the problem is saying we want to call bmaptool, and that's handled
here.

-- 
Tom

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] image_types: Fix bmaptool support for RSS

[Khem Raj]

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

On Wed, Sep 27, 2017 at 2:52 PM Tom Rini <trini@konsulko.com> wrote:

> On Wed, Sep 27, 2017 at 02:01:43PM -0700, Khem Raj wrote:
> > On Wed, Sep 27, 2017 at 10:00 AM, Tom Rini <trini@konsulko.com> wrote:
> > > With RSS we need to ensure that when making a bmap image that the
> > > python3 that we created is found via /usr/bin/env rather than the host
> > > python3.  Otherwise we're relying on the build host to have bmaptool
> > > support installed.


Who is staging python3 native here may be that's where it could be added

>
> > >
> > > Signed-off-by: Tom Rini <trini@konsulko.com>
> > > ---
> > > I played around with a few ways to try and fix this problem, and this
> > > was the best I could come up with.  Once this is in we need this in
> pyro
> > > as well as it's broken there too.
> > > ---
> > >  meta/classes/image_types.bbclass | 3 +++
> > >  1 file changed, 3 insertions(+)
> > >
> > > diff --git a/meta/classes/image_types.bbclass
> b/meta/classes/image_types.bbclass
> > > index 61dca626311e..3ff960e3a889 100644
> > > --- a/meta/classes/image_types.bbclass
> > > +++ b/meta/classes/image_types.bbclass
> > > @@ -311,3 +311,6 @@ DEPLOYABLE_IMAGE_TYPES ?= "hddimg iso"
> > >  # The IMAGE_TYPES_MASKED variable will be used to mask out from the
> IMAGE_FSTYPES,
> > >  # images that will not be built at do_rootfs time: vmdk, vdi, qcow2,
> hdddirect, hddimg, iso, etc.
> > >  IMAGE_TYPES_MASKED ?= ""
> > > +
> > > +# bmap requires python3 to be in the PATH
> > > +EXTRANATIVEPATH += "${@'python3-native' if
> d.getVar('IMAGE_FSTYPES').find('bmap') else ''}"
> > > --
> >
> > I think somewhere inherit python3native should fix it.
>
> Yes, image_types.bbclass could also inherit python3native but that
> seemed heavy-handed.  There's not some other place that should be doing
> it as the problem is saying we want to call bmaptool, and that's handled
> here.
>
> --
> Tom
>

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

Re: [PATCH] image_types: Fix bmaptool support for RSS

[Tom Rini]

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

On Wed, Sep 27, 2017 at 10:14:51PM +0000, Khem Raj wrote:
> On Wed, Sep 27, 2017 at 2:52 PM Tom Rini <trini@konsulko.com> wrote:
> 
> > On Wed, Sep 27, 2017 at 02:01:43PM -0700, Khem Raj wrote:
> > > On Wed, Sep 27, 2017 at 10:00 AM, Tom Rini <trini@konsulko.com> wrote:
> > > > With RSS we need to ensure that when making a bmap image that the
> > > > python3 that we created is found via /usr/bin/env rather than the host
> > > > python3.  Otherwise we're relying on the build host to have bmaptool
> > > > support installed.
> 
> Who is staging python3 native here may be that's where it could be added

What do you mean?  Adding whatever.bmap to IMAGE_FSTYPES is valid and
how you get the bmap file for the whatever image type.  bmap-tool-native
is correctly inherit'ing python3native which is why it's staged
correctly.  It's just that images aren't adding the EXTRANATIVEPATH
that's required because nothing is telling them that bmap requires it.

> 
> >
> > > >
> > > > Signed-off-by: Tom Rini <trini@konsulko.com>
> > > > ---
> > > > I played around with a few ways to try and fix this problem, and this
> > > > was the best I could come up with.  Once this is in we need this in
> > pyro
> > > > as well as it's broken there too.
> > > > ---
> > > >  meta/classes/image_types.bbclass | 3 +++
> > > >  1 file changed, 3 insertions(+)
> > > >
> > > > diff --git a/meta/classes/image_types.bbclass
> > b/meta/classes/image_types.bbclass
> > > > index 61dca626311e..3ff960e3a889 100644
> > > > --- a/meta/classes/image_types.bbclass
> > > > +++ b/meta/classes/image_types.bbclass
> > > > @@ -311,3 +311,6 @@ DEPLOYABLE_IMAGE_TYPES ?= "hddimg iso"
> > > >  # The IMAGE_TYPES_MASKED variable will be used to mask out from the
> > IMAGE_FSTYPES,
> > > >  # images that will not be built at do_rootfs time: vmdk, vdi, qcow2,
> > hdddirect, hddimg, iso, etc.
> > > >  IMAGE_TYPES_MASKED ?= ""
> > > > +
> > > > +# bmap requires python3 to be in the PATH
> > > > +EXTRANATIVEPATH += "${@'python3-native' if
> > d.getVar('IMAGE_FSTYPES').find('bmap') else ''}"
> > > > --
> > >
> > > I think somewhere inherit python3native should fix it.
> >
> > Yes, image_types.bbclass could also inherit python3native but that
> > seemed heavy-handed.  There's not some other place that should be doing
> > it as the problem is saying we want to call bmaptool, and that's handled
> > here.
> >
> > --
> > Tom
> >

-- 
Tom

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] image_types: Fix bmaptool support for RSS

[Khem Raj]

On Wed, Sep 27, 2017 at 3:17 PM, Tom Rini <trini@konsulko.com> wrote:
> On Wed, Sep 27, 2017 at 10:14:51PM +0000, Khem Raj wrote:
>> On Wed, Sep 27, 2017 at 2:52 PM Tom Rini <trini@konsulko.com> wrote:
>>
>> > On Wed, Sep 27, 2017 at 02:01:43PM -0700, Khem Raj wrote:
>> > > On Wed, Sep 27, 2017 at 10:00 AM, Tom Rini <trini@konsulko.com> wrote:
>> > > > With RSS we need to ensure that when making a bmap image that the
>> > > > python3 that we created is found via /usr/bin/env rather than the host
>> > > > python3.  Otherwise we're relying on the build host to have bmaptool
>> > > > support installed.
>>
>> Who is staging python3 native here may be that's where it could be added
>
> What do you mean?  Adding whatever.bmap to IMAGE_FSTYPES is valid and
> how you get the bmap file for the whatever image type.  bmap-tool-native
> is correctly inherit'ing python3native which is why it's staged
> correctly.  It's just that images aren't adding the EXTRANATIVEPATH
> that's required because nothing is telling them that bmap requires it.

hmm, I see, I wonder if these paths should be added unconditionally.
During image build.

Re: [PATCH] image_types: Fix bmaptool support for RSS

[Ed Bartosh]

On Wed, Sep 27, 2017 at 01:00:09PM -0400, Tom Rini wrote:
> With RSS we need to ensure that when making a bmap image that the
> python3 that we created is found via /usr/bin/env rather than the host
> python3.  Otherwise we're relying on the build host to have bmaptool
> support installed.
> 

Can you suggest how to reproduce the issue you're trying to fix with
this patch?

Here is what I did:

1. Checked if bmaptools are available for host python3:

$ python3 -c 'import bmaptools'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
ImportError: No module named 'bmaptools'

2. Added cpio.bmap to my build configuration:

$ grep ^IMAGE_FSTYPES ./conf/local.conf 
IMAGE_FSTYPES = "cpio.bmap"

3. Built core-image-minimal:
[build (master)]$ rm -rf tmp/
[build (master)]$ bitbake core-image-minimal
...
NOTE: Tasks Summary: Attempted 2395 tasks of which 2186 didn't need to
be rerun and all succeeded.

4. Checked if bmap file has been generated:
[build (master)]$ ls ./tmp/deploy/images/qemux86-64/ |grep cpio
core-image-minimal-qemux86-64-20170928135949.rootfs.cpio.bmap
core-image-minimal-qemux86-64.cpio.bmap

Hm, cpio image got removed for some reason. Looks like a bug, but not
related to bmaptool. (I remember you're fixing that code some time ago).

Should I use another MACHINE or anything else that can trigger build
failure?

PS. I used latest poky master. commit id: fcdfe09d9cc4e2977bd602dfd18f729cd9f6d73d

> Signed-off-by: Tom Rini <trini@konsulko.com>
> ---
> I played around with a few ways to try and fix this problem, and this
> was the best I could come up with.  Once this is in we need this in pyro
> as well as it's broken there too.
> ---
>  meta/classes/image_types.bbclass | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
> index 61dca626311e..3ff960e3a889 100644
> --- a/meta/classes/image_types.bbclass
> +++ b/meta/classes/image_types.bbclass
> @@ -311,3 +311,6 @@ DEPLOYABLE_IMAGE_TYPES ?= "hddimg iso"
>  # The IMAGE_TYPES_MASKED variable will be used to mask out from the IMAGE_FSTYPES,
>  # images that will not be built at do_rootfs time: vmdk, vdi, qcow2, hdddirect, hddimg, iso, etc.
>  IMAGE_TYPES_MASKED ?= ""
> +
> +# bmap requires python3 to be in the PATH
> +EXTRANATIVEPATH += "${@'python3-native' if d.getVar('IMAGE_FSTYPES').find('bmap') else ''}"
> -- 
> 1.9.1
> 
> -- 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

--
Regards,
Ed

Re: [PATCH] image_types: Fix bmaptool support for RSS

[Tom Rini]

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

On Thu, Sep 28, 2017 at 05:13:03PM +0300, Ed Bartosh wrote:
> On Wed, Sep 27, 2017 at 01:00:09PM -0400, Tom Rini wrote:
> > With RSS we need to ensure that when making a bmap image that the
> > python3 that we created is found via /usr/bin/env rather than the host
> > python3.  Otherwise we're relying on the build host to have bmaptool
> > support installed.
> > 
> 
> Can you suggest how to reproduce the issue you're trying to fix with
> this patch?
> 
> Here is what I did:
> 
> 1. Checked if bmaptools are available for host python3:
> 
> $ python3 -c 'import bmaptools'
> Traceback (most recent call last):
>   File "<string>", line 1, in <module>
> ImportError: No module named 'bmaptools'
> 
> 2. Added cpio.bmap to my build configuration:
> 
> $ grep ^IMAGE_FSTYPES ./conf/local.conf 
> IMAGE_FSTYPES = "cpio.bmap"
> 
> 3. Built core-image-minimal:
> [build (master)]$ rm -rf tmp/
> [build (master)]$ bitbake core-image-minimal
> ...
> NOTE: Tasks Summary: Attempted 2395 tasks of which 2186 didn't need to
> be rerun and all succeeded.
> 
> 4. Checked if bmap file has been generated:
> [build (master)]$ ls ./tmp/deploy/images/qemux86-64/ |grep cpio
> core-image-minimal-qemux86-64-20170928135949.rootfs.cpio.bmap
> core-image-minimal-qemux86-64.cpio.bmap
> 
> Hm, cpio image got removed for some reason. Looks like a bug, but not
> related to bmaptool. (I remember you're fixing that code some time ago).
> 
> Should I use another MACHINE or anything else that can trigger build
> failure?
> 
> PS. I used latest poky master. commit id: fcdfe09d9cc4e2977bd602dfd18f729cd9f6d73d

I'm on oe-core only, abf2e9526a11bcb51b71b90a7b76bd33af656494 and just
replicated the problem again.  I'm doing ext4.bmap, but that shouldn't
matter.

-- 
Tom

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] image_types: Fix bmaptool support for RSS

[Ed Bartosh]

On Wed, Sep 27, 2017 at 01:00:09PM -0400, Tom Rini wrote:
> With RSS we need to ensure that when making a bmap image that the
> python3 that we created is found via /usr/bin/env rather than the host
> python3.  Otherwise we're relying on the build host to have bmaptool
> support installed.
> 
> Signed-off-by: Tom Rini <trini@konsulko.com>
> ---
> I played around with a few ways to try and fix this problem, and this
> was the best I could come up with.  Once this is in we need this in pyro
> as well as it's broken there too.
> ---
>  meta/classes/image_types.bbclass | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
> index 61dca626311e..3ff960e3a889 100644
> --- a/meta/classes/image_types.bbclass
> +++ b/meta/classes/image_types.bbclass
> @@ -311,3 +311,6 @@ DEPLOYABLE_IMAGE_TYPES ?= "hddimg iso"
>  # The IMAGE_TYPES_MASKED variable will be used to mask out from the IMAGE_FSTYPES,
>  # images that will not be built at do_rootfs time: vmdk, vdi, qcow2, hdddirect, hddimg, iso, etc.
>  IMAGE_TYPES_MASKED ?= ""
> +
> +# bmap requires python3 to be in the PATH
> +EXTRANATIVEPATH += "${@'python3-native' if d.getVar('IMAGE_FSTYPES').find('bmap') else ''}"

+1

Would ...find('.bmap') be a bit more safe?

--
Regards,
Ed

Re: [PATCH] image_types: Fix bmaptool support for RSS

[Tom Rini]

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

On Fri, Sep 29, 2017 at 02:16:21PM +0300, Ed Bartosh wrote:
> On Wed, Sep 27, 2017 at 01:00:09PM -0400, Tom Rini wrote:
> > With RSS we need to ensure that when making a bmap image that the
> > python3 that we created is found via /usr/bin/env rather than the host
> > python3.  Otherwise we're relying on the build host to have bmaptool
> > support installed.
> > 
> > Signed-off-by: Tom Rini <trini@konsulko.com>
> > ---
> > I played around with a few ways to try and fix this problem, and this
> > was the best I could come up with.  Once this is in we need this in pyro
> > as well as it's broken there too.
> > ---
> >  meta/classes/image_types.bbclass | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
> > index 61dca626311e..3ff960e3a889 100644
> > --- a/meta/classes/image_types.bbclass
> > +++ b/meta/classes/image_types.bbclass
> > @@ -311,3 +311,6 @@ DEPLOYABLE_IMAGE_TYPES ?= "hddimg iso"
> >  # The IMAGE_TYPES_MASKED variable will be used to mask out from the IMAGE_FSTYPES,
> >  # images that will not be built at do_rootfs time: vmdk, vdi, qcow2, hdddirect, hddimg, iso, etc.
> >  IMAGE_TYPES_MASKED ?= ""
> > +
> > +# bmap requires python3 to be in the PATH
> > +EXTRANATIVEPATH += "${@'python3-native' if d.getVar('IMAGE_FSTYPES').find('bmap') else ''}"
> 
> +1
> 
> Would ...find('.bmap') be a bit more safe?

Could be.  Do I need to v2 or can someone just fix up while applying?
Thanks!

-- 
Tom

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] image_types: Fix bmaptool support for RSS

[Ed Bartosh]

On Fri, Sep 29, 2017 at 08:36:52AM -0400, Tom Rini wrote:
> On Fri, Sep 29, 2017 at 02:16:21PM +0300, Ed Bartosh wrote:
> > On Wed, Sep 27, 2017 at 01:00:09PM -0400, Tom Rini wrote:
> > > With RSS we need to ensure that when making a bmap image that the
> > > python3 that we created is found via /usr/bin/env rather than the host
> > > python3.  Otherwise we're relying on the build host to have bmaptool
> > > support installed.
> > > 
> > > Signed-off-by: Tom Rini <trini@konsulko.com>
> > > ---
> > > I played around with a few ways to try and fix this problem, and this
> > > was the best I could come up with.  Once this is in we need this in pyro
> > > as well as it's broken there too.
> > > ---
> > >  meta/classes/image_types.bbclass | 3 +++
> > >  1 file changed, 3 insertions(+)
> > > 
> > > diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
> > > index 61dca626311e..3ff960e3a889 100644
> > > --- a/meta/classes/image_types.bbclass
> > > +++ b/meta/classes/image_types.bbclass
> > > @@ -311,3 +311,6 @@ DEPLOYABLE_IMAGE_TYPES ?= "hddimg iso"
> > >  # The IMAGE_TYPES_MASKED variable will be used to mask out from the IMAGE_FSTYPES,
> > >  # images that will not be built at do_rootfs time: vmdk, vdi, qcow2, hdddirect, hddimg, iso, etc.
> > >  IMAGE_TYPES_MASKED ?= ""
> > > +
> > > +# bmap requires python3 to be in the PATH
> > > +EXTRANATIVEPATH += "${@'python3-native' if d.getVar('IMAGE_FSTYPES').find('bmap') else ''}"
> > 
> > +1
> > 
> > Would ...find('.bmap') be a bit more safe?
> 
> Could be.  Do I need to v2 or can someone just fix up while applying?

Please send v2.

--
Regards,
Ed

[PATCHv2] image_types: Fix bmaptool support for RSS

[Tom Rini]

With RSS we need to ensure that when making a bmap image that the
python3 that we created is found via /usr/bin/env rather than the host
python3.  Otherwise we're relying on the build host to have bmaptool
support installed.

Signed-off-by: Tom Rini <trini@konsulko.com>
---
Changes in v2:
- Switch to checking for '.bmap' not 'bmap', per Ed Bartosh.
---
 meta/classes/image_types.bbclass | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index 61dca626311e..b373b217145f 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -311,3 +311,6 @@ DEPLOYABLE_IMAGE_TYPES ?= "hddimg iso"
 # The IMAGE_TYPES_MASKED variable will be used to mask out from the IMAGE_FSTYPES,
 # images that will not be built at do_rootfs time: vmdk, vdi, qcow2, hdddirect, hddimg, iso, etc.
 IMAGE_TYPES_MASKED ?= ""
+
+# bmap requires python3 to be in the PATH
+EXTRANATIVEPATH += "${@'python3-native' if d.getVar('IMAGE_FSTYPES').find('.bmap') else ''}"
-- 
1.9.1

Re: [PATCHv2] image_types: Fix bmaptool support for RSS

[Ed Bartosh]

On Fri, Sep 29, 2017 at 10:28:19AM -0400, Tom Rini wrote:
> With RSS we need to ensure that when making a bmap image that the
> python3 that we created is found via /usr/bin/env rather than the host
> python3.  Otherwise we're relying on the build host to have bmaptool
> support installed.
> 

Thank you for the patch.

+1

> Signed-off-by: Tom Rini <trini@konsulko.com>
> ---
> Changes in v2:
> - Switch to checking for '.bmap' not 'bmap', per Ed Bartosh.
> ---
>  meta/classes/image_types.bbclass | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
> index 61dca626311e..b373b217145f 100644
> --- a/meta/classes/image_types.bbclass
> +++ b/meta/classes/image_types.bbclass
> @@ -311,3 +311,6 @@ DEPLOYABLE_IMAGE_TYPES ?= "hddimg iso"
>  # The IMAGE_TYPES_MASKED variable will be used to mask out from the IMAGE_FSTYPES,
>  # images that will not be built at do_rootfs time: vmdk, vdi, qcow2, hdddirect, hddimg, iso, etc.
>  IMAGE_TYPES_MASKED ?= ""
> +
> +# bmap requires python3 to be in the PATH
> +EXTRANATIVEPATH += "${@'python3-native' if d.getVar('IMAGE_FSTYPES').find('.bmap') else ''}"
> -- 
> 1.9.1
> 
> -- 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
--
Regards,
Ed