[PATCH] bmap-tools: update from 3.4 to 3.5

[PATCH] bmap-tools: update from 3.4 to 3.5

[Alex Kiernan]

bmap-tools 3.5 was released August 2018 but has no release tarball, so
switch to using the git fetcher. Also pull in the fix for StopIteration
being transformed into RuntimeError for Python 3.7.

Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
---

 .../bmap-tools/{bmap-tools_3.4.bb => bmap-tools_3.5.bb}          | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)
 rename meta/recipes-support/bmap-tools/{bmap-tools_3.4.bb => bmap-tools_3.5.bb} (74%)

diff --git a/meta/recipes-support/bmap-tools/bmap-tools_3.4.bb b/meta/recipes-support/bmap-tools/bmap-tools_3.5.bb
similarity index 74%
rename from meta/recipes-support/bmap-tools/bmap-tools_3.4.bb
rename to meta/recipes-support/bmap-tools/bmap-tools_3.5.bb
index 2aae9a3fe0d8..25d66df623a0 100644
--- a/meta/recipes-support/bmap-tools/bmap-tools_3.4.bb
+++ b/meta/recipes-support/bmap-tools/bmap-tools_3.5.bb
@@ -9,12 +9,13 @@ SECTION = "console/utils"
 LICENSE = "GPLv2"
 LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
 
-SRC_URI = "https://github.com/intel/${BPN}/releases/download/v${PV}/${BP}.tgz"
+SRC_URI = "git://github.com/intel/${BPN}"
 
-SRC_URI[md5sum] = "883420183611aa137cbaf68a91ef0d7e"
-SRC_URI[sha256sum] = "0064891270c180c190f41925b0f6fb9cecac3056f1168d2592dbe90e5f226c0a"
+SRCREV = "db7087b883bf52cbff063ad17a41cc1cbb85104d"
+S = "${WORKDIR}/git"
+PV .= "+git${SRCPV}"
 
-UPSTREAM_CHECK_URI = "https://github.com/intel/${BPN}/releases"
+UPSTREAM_CHECK_GITTAGREGEX = "v(?P<pver>.*)"
 
 RDEPENDS_${PN} = "python3-core python3-compression python3-mmap python3-setuptools python3-fcntl"
 
-- 
2.7.4

Re: [PATCH] bmap-tools: update from 3.4 to 3.5

[Alexander Kanavin]

On Thu, 14 Feb 2019 at 22:10, Alex Kiernan <alex.kiernan@gmail.com> wrote:

> +PV .= "+git${SRCPV}"

This is unnecessary and adds clutter. Just the plain version number is enough.

Alex

Re: [PATCH] bmap-tools: update from 3.4 to 3.5

[Richard Purdie]

On Thu, 2019-02-14 at 22:17 +0100, Alexander Kanavin wrote:
> On Thu, 14 Feb 2019 at 22:10, Alex Kiernan <alex.kiernan@gmail.com>
> wrote:
> 
> > +PV .= "+git${SRCPV}"
> 
> This is unnecessary and adds clutter. Just the plain version number
> is enough.

If I read the original commit message correctly, it is necessary as the
version is 3.5 plus a bugfix?

Cheers,

Richard

Re: [PATCH] bmap-tools: update from 3.4 to 3.5

[Alexander Kanavin]

On Fri, 15 Feb 2019 at 12:27, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>
> On Thu, 2019-02-14 at 22:17 +0100, Alexander Kanavin wrote:
> > On Thu, 14 Feb 2019 at 22:10, Alex Kiernan <alex.kiernan@gmail.com>
> > wrote:
> >
> > > +PV .= "+git${SRCPV}"
> >
> > This is unnecessary and adds clutter. Just the plain version number
> > is enough.
>
> If I read the original commit message correctly, it is necessary as the
> version is 3.5 plus a bugfix?

Seems so. Sorry for the noise.

Alex

Re: [PATCH] bmap-tools: update from 3.4 to 3.5

[Alex Kiernan]

On Fri, Feb 15, 2019 at 11:27 AM Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>
> On Thu, 2019-02-14 at 22:17 +0100, Alexander Kanavin wrote:
> > On Thu, 14 Feb 2019 at 22:10, Alex Kiernan <alex.kiernan@gmail.com>
> > wrote:
> >
> > > +PV .= "+git${SRCPV}"
> >
> > This is unnecessary and adds clutter. Just the plain version number
> > is enough.
>
> If I read the original commit message correctly, it is necessary as the
> version is 3.5 plus a bugfix?
>

Yes it was 3.5 + a bug fix.

Ignore v2 that I sent!

-- 
Alex Kiernan

Re: [PATCH] bmap-tools: update from 3.4 to 3.5

[Richard Purdie]

On Thu, 2019-02-14 at 21:09 +0000, Alex Kiernan wrote:
> bmap-tools 3.5 was released August 2018 but has no release tarball,
> so
> switch to using the git fetcher. Also pull in the fix for
> StopIteration
> being transformed into RuntimeError for Python 3.7.
> 
> Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>

Unfortunately this triggers a selftest failure:

https://autobuilder.yoctoproject.org/typhoon/#/builders/56/builds/236

(ignore the virtgl piece, that is something else)

oe-selftest -r wic.Wic2.test_bmap_short
and
oe-selftest -r wic.Wic2.test_bmap_long 

should reproduce. Might be as simple as a missing RDEPENDS.

Cheers,

Richard

> 
>  .../bmap-tools/{bmap-tools_3.4.bb => bmap-tools_3.5.bb}          | 9
> +++++----
>  1 file changed, 5 insertions(+), 4 deletions(-)
>  rename meta/recipes-support/bmap-tools/{bmap-tools_3.4.bb => bmap-
> tools_3.5.bb} (74%)
> 
> diff --git a/meta/recipes-support/bmap-tools/bmap-tools_3.4.bb
> b/meta/recipes-support/bmap-tools/bmap-tools_3.5.bb
> similarity index 74%
> rename from meta/recipes-support/bmap-tools/bmap-tools_3.4.bb
> rename to meta/recipes-support/bmap-tools/bmap-tools_3.5.bb
> index 2aae9a3fe0d8..25d66df623a0 100644
> --- a/meta/recipes-support/bmap-tools/bmap-tools_3.4.bb
> +++ b/meta/recipes-support/bmap-tools/bmap-tools_3.5.bb
> @@ -9,12 +9,13 @@ SECTION = "console/utils"
>  LICENSE = "GPLv2"
>  LIC_FILES_CHKSUM =
> "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
>  
> -SRC_URI = "
> https://github.com/intel/${BPN}/releases/download/v${PV}/${BP}.tgz"
> +SRC_URI = "git://github.com/intel/${BPN}"
>  
> -SRC_URI[md5sum] = "883420183611aa137cbaf68a91ef0d7e"
> -SRC_URI[sha256sum] =
> "0064891270c180c190f41925b0f6fb9cecac3056f1168d2592dbe90e5f226c0a"
> +SRCREV = "db7087b883bf52cbff063ad17a41cc1cbb85104d"
> +S = "${WORKDIR}/git"
> +PV .= "+git${SRCPV}"
>  
> -UPSTREAM_CHECK_URI = "https://github.com/intel/${BPN}/releases"
> +UPSTREAM_CHECK_GITTAGREGEX = "v(?P<pver>.*)"
>  
>  RDEPENDS_${PN} = "python3-core python3-compression python3-mmap
> python3-setuptools python3-fcntl"
>  
> -- 
> 2.7.4
> 

Re: [PATCH] bmap-tools: update from 3.4 to 3.5

[Alex Kiernan]

On Fri, Feb 15, 2019 at 11:16 PM Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>
> On Thu, 2019-02-14 at 21:09 +0000, Alex Kiernan wrote:
> > bmap-tools 3.5 was released August 2018 but has no release tarball,
> > so
> > switch to using the git fetcher. Also pull in the fix for
> > StopIteration
> > being transformed into RuntimeError for Python 3.7.
> >
> > Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
>
> Unfortunately this triggers a selftest failure:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/56/builds/236
>
> (ignore the virtgl piece, that is something else)
>
> oe-selftest -r wic.Wic2.test_bmap_short
> and
> oe-selftest -r wic.Wic2.test_bmap_long
>
> should reproduce. Might be as simple as a missing RDEPENDS.
>

Looks like it's gained a dependency on six. And thanks for the
reproducing steps - I've never got to grips with that stuff before.

That said I'm struggling to get the tests to actually pass. I've added
in python3-six to RDEPENDS, but it still fails with
`ModuleNotFoundError: No module named 'six'`?

-- 
Alex Kiernan

Re: [PATCH] bmap-tools: update from 3.4 to 3.5

[Richard Purdie]

On Sat, 2019-02-16 at 09:25 +0000, Alex Kiernan wrote:
> On Fri, Feb 15, 2019 at 11:16 PM Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > On Thu, 2019-02-14 at 21:09 +0000, Alex Kiernan wrote:
> > > bmap-tools 3.5 was released August 2018 but has no release tarball,
> > > so
> > > switch to using the git fetcher. Also pull in the fix for
> > > StopIteration
> > > being transformed into RuntimeError for Python 3.7.
> > > 
> > > Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
> > 
> > Unfortunately this triggers a selftest failure:
> > 
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/56/builds/236
> > 
> > (ignore the virtgl piece, that is something else)
> > 
> > oe-selftest -r wic.Wic2.test_bmap_short
> > and
> > oe-selftest -r wic.Wic2.test_bmap_long
> > 
> > should reproduce. Might be as simple as a missing RDEPENDS.
> > 
> 
> Looks like it's gained a dependency on six. And thanks for the
> reproducing steps - I've never got to grips with that stuff before.
> 
> That said I'm struggling to get the tests to actually pass. I've
> added
> in python3-six to RDEPENDS, but it still fails with
> `ModuleNotFoundError: No module named 'six'`?

We appear to have walked into spools of razor wire :/

This is an open bug:

https://bugzilla.yoctoproject.org/show_bug.cgi?id=10113

which I'm struggling to know how to fix.

What does appear to work locally is adding something like:

# We need the native dependency on python3-six at runtime
# See bug 10113
EXTRASYSROOTDEPTASK = ""
EXTRASYSROOTDEPTASK_class-native = "do_populate_sysroot"
do_populate_sysroot[rdeptask] = "${EXTRASYSROOTDEPTASK}"

Whether this is the right thing to do I'm less sure about.

It may be an idea to start introducing these dependencies where we need
them to fix bugs, until we can sort the problem properly in
native.bbclass.

Cheers,

Richard

Re: [PATCH] bmap-tools: update from 3.4 to 3.5

[Alex Kiernan]

On Sat, Feb 16, 2019 at 11:32 AM Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>
> On Sat, 2019-02-16 at 09:25 +0000, Alex Kiernan wrote:
> > On Fri, Feb 15, 2019 at 11:16 PM Richard Purdie
> > <richard.purdie@linuxfoundation.org> wrote:
> > > On Thu, 2019-02-14 at 21:09 +0000, Alex Kiernan wrote:
> > > > bmap-tools 3.5 was released August 2018 but has no release tarball,
> > > > so
> > > > switch to using the git fetcher. Also pull in the fix for
> > > > StopIteration
> > > > being transformed into RuntimeError for Python 3.7.
> > > >
> > > > Signed-off-by: Alex Kiernan <alex.kiernan@gmail.com>
> > >
> > > Unfortunately this triggers a selftest failure:
> > >
> > > https://autobuilder.yoctoproject.org/typhoon/#/builders/56/builds/236
> > >
> > > (ignore the virtgl piece, that is something else)
> > >
> > > oe-selftest -r wic.Wic2.test_bmap_short
> > > and
> > > oe-selftest -r wic.Wic2.test_bmap_long
> > >
> > > should reproduce. Might be as simple as a missing RDEPENDS.
> > >
> >
> > Looks like it's gained a dependency on six. And thanks for the
> > reproducing steps - I've never got to grips with that stuff before.
> >
> > That said I'm struggling to get the tests to actually pass. I've
> > added
> > in python3-six to RDEPENDS, but it still fails with
> > `ModuleNotFoundError: No module named 'six'`?
>
> We appear to have walked into spools of razor wire :/
>
> This is an open bug:
>
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=10113
>
> which I'm struggling to know how to fix.
>
> What does appear to work locally is adding something like:
>
> # We need the native dependency on python3-six at runtime
> # See bug 10113
> EXTRASYSROOTDEPTASK = ""
> EXTRASYSROOTDEPTASK_class-native = "do_populate_sysroot"
> do_populate_sysroot[rdeptask] = "${EXTRASYSROOTDEPTASK}"
>
> Whether this is the right thing to do I'm less sure about.
>
> It may be an idea to start introducing these dependencies where we need
> them to fix bugs, until we can sort the problem properly in
> native.bbclass.
>

Thanks, that seems to work... I'd have been here forever trying to find that.

I'll send a v3 with that change in it.

-- 
Alex Kiernan

Re: [PATCH] bmap-tools: update from 3.4 to 3.5

[Richard Purdie]

On Sat, 2019-02-16 at 12:22 +0000, Alex Kiernan wrote:
> On Sat, Feb 16, 2019 at 11:32 AM Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > We appear to have walked into spools of razor wire :/
> > 
> > This is an open bug:
> > 
> > https://bugzilla.yoctoproject.org/show_bug.cgi?id=10113
> > 
> > which I'm struggling to know how to fix.
> > 
> > What does appear to work locally is adding something like:
> > 
> > # We need the native dependency on python3-six at runtime
> > # See bug 10113
> > EXTRASYSROOTDEPTASK = ""
> > EXTRASYSROOTDEPTASK_class-native = "do_populate_sysroot"
> > do_populate_sysroot[rdeptask] = "${EXTRASYSROOTDEPTASK}"
> > 
> > Whether this is the right thing to do I'm less sure about.
> > 
> > It may be an idea to start introducing these dependencies where we
> > need
> > them to fix bugs, until we can sort the problem properly in
> > native.bbclass.
> > 
> 
> Thanks, that seems to work... I'd have been here forever trying to
> find that.
> 
> I'll send a v3 with that change in it.

Thanks! I poked a bit more at that underlying RDEPENDS problem as it
bothers me. Once I fixed the dependency loop detection code in bitbake,
the real errors became clear and once two of them were fixed, things
started working more as they should.

I've put together a patchset and thrown it at the autobuilder, see what
it makes of it.

I'll either merge your patch with or without the hack depending on how
that goes...

Cheers,

Richard