[OE-core] bash-completion

[Slater, Joseph]

I see a bbclass for this, but no IMAGE_FEATURE to get the resultant packages 
into an image.  Is there, or should there, be one?  I also see reference to 
various similar packages, like *-dbg in an sdk bbclass, but have not found how 
any of this stuff actually gets put into a target image.  Any pointers would be 
appreciated.

Joe

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][PATCH 1/1] oeqa: small modification to oe_syslog

[Slater, Joseph]

I thought of that, but I think the package might be variable and we would have 
to list all the possibles, which requires monitoring.  If "logger" isn't on the 
path, we could take the position that the test is pointless and not worry about 
where it might have come from.

Joe

-Original Message-
From: Richard Purdie  
Sent: Thursday, July 25, 2019 2:45 PM
To: Slater, Joseph ; 
openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [oe-core][PATCH 1/1] oeqa: small modification to 
oe_syslog

On Thu, 2019-07-25 at 13:30 -0700, Joe Slater wrote:
> Skip logger test if logger is not a command.
> 
> Signed-off-by: Joe Slater 
> ---
>  meta/lib/oeqa/runtime/cases/oe_syslog.py | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/meta/lib/oeqa/runtime/cases/oe_syslog.py 
> b/meta/lib/oeqa/runtime/cases/oe_syslog.py
> index 3a8271a..04f8345 100644
> --- a/meta/lib/oeqa/runtime/cases/oe_syslog.py
> +++ b/meta/lib/oeqa/runtime/cases/oe_syslog.py
> @@ -83,6 +83,8 @@ class SyslogTestConfig(OERuntimeTestCase):
>  def test_syslog_logger(self):
>  status, output = self.target.run('logger foobar')
>  msg = "Can't log into syslog. Output: %s " % output
> +if status == 127:
> +self.skipTest("We cannot test logger because it is not 
> + there.")
>  self.assertEqual(status, 0, msg=msg)
>  
>  # There is no way to flush the logger to disk in all cases

Should we not be marking up the test to skip if the appropriate package isn't 
in the image?

Cheers,

Richard

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][PATCH 1/1] libtool: allow for use of reproducible_build bbclass

[Slater, Joseph]

That's a question I have about things like this, where some information seems 
of minimal use, but is there and is now malignant.  Chuck it or modify it to be 
benign.

Joe

-Original Message-
From: Burton, Ross  
Sent: Thursday, July 11, 2019 2:56 PM
To: Adrian Bunk 
Cc: Slater, Joseph ; OE-core 

Subject: Re: [OE-core] [oe-core][PATCH 1/1] libtool: allow for use of 
reproducible_build bbclass

On Thu, 11 Jul 2019 at 21:45, Adrian Bunk  wrote:
> The Debian patch for the same purpose simply removes the problematic 
> line - a comment with the build host was anyways not important information.

Agreed, it's just a comment, and replacing it with logic just means more effort 
when we need to rebase.  Ideally, upstream remove that comment too, as it 
doesn't have much value at all.

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][PATCH 1/1] parted: change device manager check in ptest

[Slater, Joseph]

Hm, I searched for parted development, and it looks like the last release was 
five years ago.  We could have a long wait for this ptest fix.

Joe

From: openembedded-core-boun...@lists.openembedded.org 
[openembedded-core-boun...@lists.openembedded.org] on behalf of Slater, Joseph 
[joe.sla...@windriver.com]
Sent: Wednesday, June 19, 2019 2:56 PM
To: Richard Purdie; openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [oe-core][PATCH 1/1] parted: change device manager check 
in ptest

I will send a patch upstream.   Joe

From: Richard Purdie [richard.pur...@linuxfoundation.org]
Sent: Wednesday, June 19, 2019 2:39 PM
To: Slater, Joseph; openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [oe-core][PATCH 1/1] parted: change device manager check 
in ptest

On Wed, 2019-06-19 at 14:26 -0700, Joe Slater wrote:
> t6001-psep should check for device manager the same way as
> other ptests for parted -- look for an environment variable.
>
> Signed-off-by: Joe Slater 
> ---
>  meta/recipes-extended/parted/files/dm_check.patch | 22
> ++
>  meta/recipes-extended/parted/parted_3.2.bb|  1 +
>  2 files changed, 23 insertions(+)
>  create mode 100644 meta/recipes-extended/parted/files/dm_check.patch
>
> diff --git a/meta/recipes-extended/parted/files/dm_check.patch
> b/meta/recipes-extended/parted/files/dm_check.patch
> new file mode 100644
> index 000..bc0e95f
> --- /dev/null
> +++ b/meta/recipes-extended/parted/files/dm_check.patch
> @@ -0,0 +1,22 @@
> +parted: change check for device-manager
> +
> +Other ptests use this method.
> +
> +Upstream-Status: Pending
> +
> +Signed-off-by: Joe Slater 

This sounds like something which should be an obvious/easy fix for
upstream, any chance we can submit it?

I'm hoping we can get our patch load down a bit so pushing obvious
things to upstream is good...

Cheers,

Richard

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][PATCH 1/1] parted: change device manager check in ptest

[Slater, Joseph]

I will send a patch upstream.   Joe

From: Richard Purdie [richard.pur...@linuxfoundation.org]
Sent: Wednesday, June 19, 2019 2:39 PM
To: Slater, Joseph; openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [oe-core][PATCH 1/1] parted: change device manager check 
in ptest

On Wed, 2019-06-19 at 14:26 -0700, Joe Slater wrote:
> t6001-psep should check for device manager the same way as
> other ptests for parted -- look for an environment variable.
>
> Signed-off-by: Joe Slater 
> ---
>  meta/recipes-extended/parted/files/dm_check.patch | 22
> ++
>  meta/recipes-extended/parted/parted_3.2.bb|  1 +
>  2 files changed, 23 insertions(+)
>  create mode 100644 meta/recipes-extended/parted/files/dm_check.patch
>
> diff --git a/meta/recipes-extended/parted/files/dm_check.patch
> b/meta/recipes-extended/parted/files/dm_check.patch
> new file mode 100644
> index 000..bc0e95f
> --- /dev/null
> +++ b/meta/recipes-extended/parted/files/dm_check.patch
> @@ -0,0 +1,22 @@
> +parted: change check for device-manager
> +
> +Other ptests use this method.
> +
> +Upstream-Status: Pending
> +
> +Signed-off-by: Joe Slater 

This sounds like something which should be an obvious/easy fix for
upstream, any chance we can submit it?

I'm hoping we can get our patch load down a bit so pushing obvious
things to upstream is good...

Cheers,

Richard

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] sysstat and sysvinit

[Slater, Joseph]

Although the exact issues have changed over releases, I think that sysstat has 
dependencies on host /etc files or directories when using sysvinit instead of 
systemd.   Since any "fixes" would potentially change target behavior, what are 
we looking for?

Joe
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/3] core-image-sato-ptest-fast: Add 'fast' ptest execution image

[Slater, Joseph]

gdk-pixbuf is fast?  Not for me.  Some of its tests take about 2000 seconds on 
qemux86-64 on a 32 core machine with 64GB ram.

Joe

From: openembedded-core-boun...@lists.openembedded.org 
[openembedded-core-boun...@lists.openembedded.org] on behalf of akuster808 
[akuster...@gmail.com]
Sent: Wednesday, April 17, 2019 9:57 AM
To: Richard Purdie; openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH 1/3] core-image-sato-ptest-fast: Add 'fast' ptest 
execution image

On 4/17/19 8:59 AM, Richard Purdie wrote:
> Create a common include file which lists recipes that have ptests divided
> into 'fast' and 'slow' groups. This allows us to include ptests which 
> otherwise
> may not get included in images and allows us to test the faster running things
> more regularly.
>
> The new image allows access to these faster executing tests. 'fast' is defined
> as tests which execute in under 30s roughly speaking.
Maybe at some point allow recipes to define their own groupings. It
would lend itself to scaling better.

Can we define the system at ~30 seconds? All these may be fast on a 196
core system where as on my laptop all would be slow ; )

- armin
>
> Signed-off-by: Richard Purdie 
> ---
>  .../distro/include/ptest-packagelists.inc | 75 +++
>  .../images/core-image-sato-ptest-fast.bb  | 16 
>  2 files changed, 91 insertions(+)
>  create mode 100644 meta/conf/distro/include/ptest-packagelists.inc
>  create mode 100644 meta/recipes-sato/images/core-image-sato-ptest-fast.bb
>
> diff --git a/meta/conf/distro/include/ptest-packagelists.inc 
> b/meta/conf/distro/include/ptest-packagelists.inc
> new file mode 100644
> index 000..768ba743ed0
> --- /dev/null
> +++ b/meta/conf/distro/include/ptest-packagelists.inc
> @@ -0,0 +1,75 @@
> +#
> +# Lists of the ptests in OE-Core, sorted into two sets by the time they take
> +#
> +# ptests which take less than ~30s each
> +#
> +PTESTS_FAST = "\
> +acl-ptest \
> +apr-ptest \
> +apr-util-ptest \
> +attr-ptest \
> +bluez5-ptest \
> +bzip2-ptest \
> +dbus-test-ptest \
> +diffstat-ptest \
> +diffutils-ptest \
> +elfutils-ptest \
> +ethtool-ptest \
> +flex-ptest \
> +gawk-ptest \
> +gdbm-ptest \
> +gdk-pixbuf-ptest \
> +gzip-ptest \
> +json-glib-ptest \
> +kbd-ptest \
> +libconvert-asn1-perl-ptest \
> +liberror-perl-ptest \
> +libpcre-ptest \
> +libtimedate-perl-ptest \
> +libtest-needs-perl-ptest \
> +liburi-perl-ptest \
> +libusb1-ptest \
> +libxml-namespacesupport-perl-ptest \
> +libxml-perl-ptest \
> +libxml-parser-perl-ptest \
> +libxml-sax-perl-ptest \
> +libxml-sax-base-perl-ptest \
> +libxml-simple-perl-ptest \
> +libxml2-ptest \
> +lzo-ptest \
> +nettle-ptest \
> +openssl-ptest \
> +opkg-ptest \
> +pango-ptest \
> +parted-ptest \
> +quilt-ptest \
> +sed-ptest \
> +slang-ptest \
> +zlib-ptest \
> +"
> +
> +#PTESTS_PROBLEMS = "\
> +#qemu-ptest \ # Doesn't run any tests?
> +#ruby-ptest \ # Timeout
> +#mdadm-ptest \ # Timeout
> +#clutter-1.0-ptest \ # Doesn't build due to depends on cogl-1.0
> +#"
> +
> +PTESTS_SLOW = "\
> +bash-ptest \
> +busybox-ptest \
> +e2fsprogs-ptest \
> +glib-2.0-ptest \
> +gstreamer1.0-ptest \
> +libevent-ptest \
> +lttng-tools-ptest \
> +openssh-ptest \
> +openssl-ptest \
> +perl-ptest \
> +python-ptest \
> +python3-ptest \
> +strace-ptest \
> +tcl-ptest \
> +util-linux-ptest \
> +valgrind-ptest \
> +"
> diff --git a/meta/recipes-sato/images/core-image-sato-ptest-fast.bb 
> b/meta/recipes-sato/images/core-image-sato-ptest-fast.bb
> new file mode 100644
> index 000..b794a7dc9e9
> --- /dev/null
> +++ b/meta/recipes-sato/images/core-image-sato-ptest-fast.bb
> @@ -0,0 +1,16 @@
> +require core-image-sato-sdk.bb
> +require conf/distro/include/ptest-packagelists.inc
> +
> +IMAGE_INSTALL += "${PTESTS_FAST}"
> +
> +DESCRIPTION += "Also includes ptest packages with fast execution times to 
> allow for more automated QA."
> +
> +# This image is sufficiently large (~1.8GB) that it can't actually fit in a 
> live
> +# image (which has a 4GB limit), so nullify the overhead factor (1.3x out of 
> the
> +# box) and explicitly add just 1500MB.
> +# strace-ptest in particular needs more than 500MB
> +IMAGE_OVERHEAD_FACTOR = "1.0"
> +IMAGE_ROOTFS_EXTRA_SPACE = "1524288"
> +
> +# ptests need more memory than standard to avoid the OOM killer
> +QB_MEM = "-m 1024"

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] when is native.bbclass applied

[Slater, Joseph]

I think it might.  This is distro related, I think.  Should distro's be fooling 
with things like CXXFLAGS, and if so, how?


From: Andre McCurdy [armccu...@gmail.com]
Sent: Monday, August 06, 2018 5:33 PM
To: Slater, Joseph
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] when is native.bbclass applied

On Mon, Aug 6, 2018 at 5:24 PM, Slater, Joseph  wrote:
> This class clobbers a number of things that might be manipulated in a
> recipe.  If, say, I want to add something to CXXFLAGS, what/where do I put
> it?  It looks like "_append" works, but "+=" might not.

+= should work. Either way, "bitbake -e" will tell you the definitive answer.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] when is native.bbclass applied

[Slater, Joseph]

This class clobbers a number of things that might be manipulated in a recipe.  
If, say, I want to add something to CXXFLAGS, what/where do I put it?  It looks 
like "_append" works, but "+=" might not.

Joe

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] aclocal question

[Slater, Joseph]

aclocal can generate rather large command lines (194000 characters) when 
calling autom4te to trace macros.  I think that this breaks at a little beyond 
the argument length I've mentioned.  I'm not familiar with this code but I 
think the bulk of the items could be piped into autom4te rather than the way it 
is done now.  This might not solve the problem but I wondered if anyone has 
looked at this issue.

Specifically, we have seen failures when building libvirt for a project with a 
long pathname.

Joe

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][PATCH 1/1] tiff: security fix CVE-2018-10963

[Slater, Joseph]

Should this be resubmitted?  I could always remove the comment about 4.0.8.
Joe

From: Slater, Joseph
Sent: Tuesday, July 10, 2018 4:56 PM
To: akuster808; openembedded-core@lists.openembedded.org
Subject: RE: [OE-core] [oe-core][PATCH 1/1] tiff: security fix CVE-2018-10963

Yes, it is not clear.  What it means is that the patch was applied to 4.0.8 
code, but not, I think, 4.0.8 code as seen on openembedded-core before 4.0.8 
was obsolete.  It still applies for 4.0.9.

Joe

-Original Message-
From: akuster808 [mailto:akuster...@gmail.com]
Sent: Tuesday, July 10, 2018 4:48 PM
To: Slater, Joseph; openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [oe-core][PATCH 1/1] tiff: security fix CVE-2018-10963



On 07/10/2018 04:03 PM, Joe Slater wrote:
> Denial of service described at 
> https://nvd.nist.gov/vuln/detail/CVE-2018-10963.
>
> Signed-off-by: Joe Slater 
> ---
>  .../libtiff/files/CVE-2018-10963.patch | 41 
> ++
>  meta/recipes-multimedia/libtiff/tiff_4.0.9.bb  |  1 +
>  2 files changed, 42 insertions(+)
>  create mode 100644 meta/recipes-multimedia/libtiff/files/CVE-2018-10963.patch
>
> diff --git a/meta/recipes-multimedia/libtiff/files/CVE-2018-10963.patch 
> b/meta/recipes-multimedia/libtiff/files/CVE-2018-10963.patch
> new file mode 100644
> index 000..13a1eb5
> --- /dev/null
> +++ b/meta/recipes-multimedia/libtiff/files/CVE-2018-10963.patch
> @@ -0,0 +1,41 @@
> +From de144fd228e4be8aa484c3caf3d814b6fa88c6d9 Mon Sep 17 00:00:00 2001
> +From: Even Rouault 
> +Date: Sat, 12 May 2018 14:24:15 +0200
> +Subject: [PATCH] TIFFWriteDirectorySec: avoid assertion. Fixes
> + http://bugzilla.maptools.org/show_bug.cgi?id=2795.
> + CVE-2018-10963
> +
> +---
> +CVE: CVE-2018-10963
> +
> +Same patch as applied to 4.0.8.
I don't know what that means. The fix is in 4.0.8 or this patch applies
cleanly to 4.0.8 or affects < 4.0.8.
- armin

> +
> +Upstream-Status: Backport [gitlab.com/libtiff/libtiff/commit/de144f...]
> +
> +Signed-off-by: Joe Slater 
> +
> +---
> + libtiff/tif_dirwrite.c |7 +--
> + 1 file changed, 5 insertions(+), 2 deletions(-)
> +
> +diff --git a/libtiff/tif_dirwrite.c b/libtiff/tif_dirwrite.c
> +index 2430de6..c15a28d 100644
> +--- a/libtiff/tif_dirwrite.c
>  b/libtiff/tif_dirwrite.c
> +@@ -695,8 +695,11 @@ TIFFWriteDirectorySec(TIFF* tif, int isimage, int 
> imagedone, uint64* pdiroff)
> + }
> + break;
> + default:
> +-assert(0);   /* 
> we should never get here */
> +-break;
> ++
> TIFFErrorExt(tif->tif_clientdata,module,
> ++
> "Cannot write tag %d (%s)",
> ++
> TIFFFieldTag(o),
> ++
> o->field_name ? o->field_name : "unknown");
> ++goto bad;
> + }
> + }
> + }
> +--
> +1.7.9.5
> +
> diff --git a/meta/recipes-multimedia/libtiff/tiff_4.0.9.bb 
> b/meta/recipes-multimedia/libtiff/tiff_4.0.9.bb
> index 8c3bba5..e8e2a11 100644
> --- a/meta/recipes-multimedia/libtiff/tiff_4.0.9.bb
> +++ b/meta/recipes-multimedia/libtiff/tiff_4.0.9.bb
> @@ -9,6 +9,7 @@ SRC_URI = 
> "http://download.osgeo.org/libtiff/tiff-${PV}.tar.gz \
> file://CVE-2017-9935.patch \
> file://CVE-2017-18013.patch \
> file://CVE-2018-5784.patch \
> +   file://CVE-2018-10963.patch \
>"
>
>  SRC_URI[md5sum] = "54bad211279cc93eb4fca31ba9bfdc79"

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][PATCH 1/1] tiff: security fix CVE-2018-10963

[Slater, Joseph]

Yes, it is not clear.  What it means is that the patch was applied to 4.0.8 
code, but not, I think, 4.0.8 code as seen on openembedded-core before 4.0.8 
was obsolete.  It still applies for 4.0.9.

Joe

-Original Message-
From: akuster808 [mailto:akuster...@gmail.com] 
Sent: Tuesday, July 10, 2018 4:48 PM
To: Slater, Joseph; openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [oe-core][PATCH 1/1] tiff: security fix CVE-2018-10963



On 07/10/2018 04:03 PM, Joe Slater wrote:
> Denial of service described at 
> https://nvd.nist.gov/vuln/detail/CVE-2018-10963.
>
> Signed-off-by: Joe Slater 
> ---
>  .../libtiff/files/CVE-2018-10963.patch | 41 
> ++
>  meta/recipes-multimedia/libtiff/tiff_4.0.9.bb  |  1 +
>  2 files changed, 42 insertions(+)
>  create mode 100644 meta/recipes-multimedia/libtiff/files/CVE-2018-10963.patch
>
> diff --git a/meta/recipes-multimedia/libtiff/files/CVE-2018-10963.patch 
> b/meta/recipes-multimedia/libtiff/files/CVE-2018-10963.patch
> new file mode 100644
> index 000..13a1eb5
> --- /dev/null
> +++ b/meta/recipes-multimedia/libtiff/files/CVE-2018-10963.patch
> @@ -0,0 +1,41 @@
> +From de144fd228e4be8aa484c3caf3d814b6fa88c6d9 Mon Sep 17 00:00:00 2001
> +From: Even Rouault 
> +Date: Sat, 12 May 2018 14:24:15 +0200
> +Subject: [PATCH] TIFFWriteDirectorySec: avoid assertion. Fixes
> + http://bugzilla.maptools.org/show_bug.cgi?id=2795.
> + CVE-2018-10963
> +
> +---
> +CVE: CVE-2018-10963
> +
> +Same patch as applied to 4.0.8.
I don't know what that means. The fix is in 4.0.8 or this patch applies
cleanly to 4.0.8 or affects < 4.0.8.
- armin

> +
> +Upstream-Status: Backport [gitlab.com/libtiff/libtiff/commit/de144f...]
> +
> +Signed-off-by: Joe Slater 
> +
> +---
> + libtiff/tif_dirwrite.c |7 +--
> + 1 file changed, 5 insertions(+), 2 deletions(-)
> +
> +diff --git a/libtiff/tif_dirwrite.c b/libtiff/tif_dirwrite.c
> +index 2430de6..c15a28d 100644
> +--- a/libtiff/tif_dirwrite.c
>  b/libtiff/tif_dirwrite.c
> +@@ -695,8 +695,11 @@ TIFFWriteDirectorySec(TIFF* tif, int isimage, int 
> imagedone, uint64* pdiroff)
> + }
> + break;
> + default:
> +-assert(0);   /* 
> we should never get here */
> +-break;
> ++
> TIFFErrorExt(tif->tif_clientdata,module,
> ++
> "Cannot write tag %d (%s)",
> ++
> TIFFFieldTag(o),
> ++
> o->field_name ? o->field_name : "unknown");
> ++goto bad;
> + }
> + }
> + }
> +-- 
> +1.7.9.5
> +
> diff --git a/meta/recipes-multimedia/libtiff/tiff_4.0.9.bb 
> b/meta/recipes-multimedia/libtiff/tiff_4.0.9.bb
> index 8c3bba5..e8e2a11 100644
> --- a/meta/recipes-multimedia/libtiff/tiff_4.0.9.bb
> +++ b/meta/recipes-multimedia/libtiff/tiff_4.0.9.bb
> @@ -9,6 +9,7 @@ SRC_URI = 
> "http://download.osgeo.org/libtiff/tiff-${PV}.tar.gz \
> file://CVE-2017-9935.patch \
> file://CVE-2017-18013.patch \
> file://CVE-2018-5784.patch \
> +   file://CVE-2018-10963.patch \
>"
>  
>  SRC_URI[md5sum] = "54bad211279cc93eb4fca31ba9bfdc79"

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][PATCH 1/1] gtk-immodules-cache: add conditional delay_to_first_boot

[Slater, Joseph]

Actually, it is a screw-up trying to deal with something that was already 
fixed.  At least it never gets executed.

Joe

From: Alexander Kanavin [alex.kana...@gmail.com]
Sent: Tuesday, June 26, 2018 12:19 PM
To: Slater, Joseph
Cc: OE-core
Subject: Re: [OE-core] [oe-core][PATCH 1/1] gtk-immodules-cache: add 
conditional delay_to_first_boot

2018-06-26 20:51 GMT+02:00 Joe Slater :
> -bindir=${bindir}
> +bindir=${bindir} || \
> +$INTERCEPT_DIR/postinst_intercept delay_to_first_boot ${PKG} \
> +mlprefix=${MLPREFIX}

Please read the postinst_intercept script. It does not actually
execute qemu at all, and so never fails due to non-working qemu. It
only requests such execution at the end of package installation
transaction. Also, if such later qemu execution does fail, then the
postinst does get deferred to first boot automatically. How did you
come up with this patch?

Alex
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][PATCH 1/1] gnome-desktop: do not free() a static buffer

[Slater, Joseph]

In looking at the patch, I think the second part, which eliminates an atol() 
assignment to a time_t variable is still necessary, at least in theory.  So, I 
would not remove the patch, but would replace it.

Joe

From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Thursday, March 08, 2018 2:10 AM
To: Slater, Joseph
Cc: OE-core
Subject: Re: [OE-core] [oe-core][PATCH 1/1] gnome-desktop: do not free() a 
static buffer

I'm not sure we need this patch anymore, it's been rebased on top of upstream 
changes but one of those changes were to fix x32 builds:

https://git.gnome.org/browse/gnome-desktop/commit/libgnome-desktop/gnome-desktop-thumbnail.c?id=012cad653253ae5f5248988cda89159f22c1fb1d

I believe we can drop this patch to gnome-desktop.

Ross

On 8 March 2018 at 01:35, Joe Slater 
<joe.sla...@windriver.com<mailto:joe.sla...@windriver.com>> wrote:
Do not free() the buffer returned by localtime().  Also,
switch to calling localtime_r() which is re-entrant.

Signed-off-by: Joe Slater 
<joe.sla...@windriver.com<mailto:joe.sla...@windriver.com>>
---
 ...op-thumbnail-don-t-convert-time_t-to-long.patch | 27 +-
 1 file changed, 11 insertions(+), 16 deletions(-)

diff --git 
a/meta/recipes-gnome/gnome-desktop/gnome-desktop/gnome-desktop-thumbnail-don-t-convert-time_t-to-long.patch
 
b/meta/recipes-gnome/gnome-desktop/gnome-desktop/gnome-desktop-thumbnail-don-t-convert-time_t-to-long.patch
index c1a7d4f..be657a8 100644
--- 
a/meta/recipes-gnome/gnome-desktop/gnome-desktop/gnome-desktop-thumbnail-don-t-convert-time_t-to-long.patch
+++ 
b/meta/recipes-gnome/gnome-desktop/gnome-desktop/gnome-desktop-thumbnail-don-t-convert-time_t-to-long.patch
@@ -9,12 +9,11 @@ build for X32, where long's size doesn't match that of time_t.
 Upstream-Status: Pending
 Signed-off-by: Christopher Larson 
<chris_lar...@mentor.com<mailto:chris_lar...@mentor.com>>


- libgnome-desktop/gnome-desktop-thumbnail.c | 16 ++--
- 1 file changed, 14 insertions(+), 2 deletions(-)
+Modified to use localtime_r() and not free() a static structure.
+
+Signed-off-by: Joe Slater <jsla...@windriver.com<mailto:jsla...@windriver.com>>
+

-diff --git a/libgnome-desktop/gnome-desktop-thumbnail.c 
b/libgnome-desktop/gnome-desktop-thumbnail.c
-index e56c3d7..5d96bf3 100644
 --- a/libgnome-desktop/gnome-desktop-thumbnail.c
 +++ b/libgnome-desktop/gnome-desktop-thumbnail.c
 @@ -120,6 +120,8 @@
@@ -30,24 +29,23 @@ index e56c3d7..5d96bf3 100644
char *tmp_path = NULL;
int tmp_fd;
char mtime_str[21];
-+  struct tm *tmp_mtime = NULL;
++  struct tm tmp_mtime;
gboolean ret = FALSE;
GError *error = NULL;
const char *width, *height;
-@@ -1124,7 +1127,11 @@ save_thumbnail (GdkPixbuf  *pixbuf,
+@@ -1124,7 +1127,10 @@ save_thumbnail (GdkPixbuf  *pixbuf,
  goto out;
close (tmp_fd);

 -  g_snprintf (mtime_str, 21, "%" G_GINT64_FORMAT, (gint64) mtime);
-+  tmp_mtime = localtime ();
-+  if (!tmp_mtime)
++  if (!localtime_r (,_mtime))
 +goto out;
-+  strftime (mtime_str, 21, "%s", tmp_mtime);
-+  free (tmp_mtime);
++
++  strftime (mtime_str, 21, "%s", _mtime);
width = gdk_pixbuf_get_option (pixbuf, "tEXt::Thumb::Image::Width");
height = gdk_pixbuf_get_option (pixbuf, "tEXt::Thumb::Image::Height");

-@@ -1319,6 +1326,7 @@ gnome_desktop_thumbnail_is_valid (GdkPixbuf  
*pixbuf,
+@@ -1319,6 +1325,7 @@ gnome_desktop_thumbnail_is_valid (GdkPix
  {
const char *thumb_uri, *thumb_mtime_str;
time_t thumb_mtime;
@@ -55,7 +53,7 @@ index e56c3d7..5d96bf3 100644

thumb_uri = gdk_pixbuf_get_option (pixbuf, "tEXt::Thumb::URI");
if (g_strcmp0 (uri, thumb_uri) != 0)
-@@ -1327,7 +1335,11 @@ gnome_desktop_thumbnail_is_valid (GdkPixbuf  
*pixbuf,
+@@ -1327,7 +1334,11 @@ gnome_desktop_thumbnail_is_valid (GdkPix
thumb_mtime_str = gdk_pixbuf_get_option (pixbuf, "tEXt::Thumb::MTime");
if (!thumb_mtime_str)
  return FALSE;
@@ -68,6 +66,3 @@ index e56c3d7..5d96bf3 100644
if (mtime != thumb_mtime)
  return FALSE;

---
-2.14.1
-
--
2.7.4

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org<mailto:Openembedded-core@lists.openembedded.org>
http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][PATCH 1/1] gnome-desktop: do not free() a static buffer

[Slater, Joseph]

I think you are correct.  I took out the patch and built sato for qemux86.  
Epiphany does not abort after loading a url, which was the problem my patch 
alterations fixed.  I’ll try x86-64 with no patch now.

Joe


From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Thursday, March 08, 2018 2:10 AM
To: Slater, Joseph
Cc: OE-core
Subject: Re: [OE-core] [oe-core][PATCH 1/1] gnome-desktop: do not free() a 
static buffer

I'm not sure we need this patch anymore, it's been rebased on top of upstream 
changes but one of those changes were to fix x32 builds:

https://git.gnome.org/browse/gnome-desktop/commit/libgnome-desktop/gnome-desktop-thumbnail.c?id=012cad653253ae5f5248988cda89159f22c1fb1d

I believe we can drop this patch to gnome-desktop.

Ross

On 8 March 2018 at 01:35, Joe Slater 
<joe.sla...@windriver.com<mailto:joe.sla...@windriver.com>> wrote:
Do not free() the buffer returned by localtime().  Also,
switch to calling localtime_r() which is re-entrant.

Signed-off-by: Joe Slater 
<joe.sla...@windriver.com<mailto:joe.sla...@windriver.com>>
---
 ...op-thumbnail-don-t-convert-time_t-to-long.patch | 27 +-
 1 file changed, 11 insertions(+), 16 deletions(-)

diff --git 
a/meta/recipes-gnome/gnome-desktop/gnome-desktop/gnome-desktop-thumbnail-don-t-convert-time_t-to-long.patch
 
b/meta/recipes-gnome/gnome-desktop/gnome-desktop/gnome-desktop-thumbnail-don-t-convert-time_t-to-long.patch
index c1a7d4f..be657a8 100644
--- 
a/meta/recipes-gnome/gnome-desktop/gnome-desktop/gnome-desktop-thumbnail-don-t-convert-time_t-to-long.patch
+++ 
b/meta/recipes-gnome/gnome-desktop/gnome-desktop/gnome-desktop-thumbnail-don-t-convert-time_t-to-long.patch
@@ -9,12 +9,11 @@ build for X32, where long's size doesn't match that of time_t.
 Upstream-Status: Pending
 Signed-off-by: Christopher Larson 
<chris_lar...@mentor.com<mailto:chris_lar...@mentor.com>>


- libgnome-desktop/gnome-desktop-thumbnail.c | 16 ++--
- 1 file changed, 14 insertions(+), 2 deletions(-)
+Modified to use localtime_r() and not free() a static structure.
+
+Signed-off-by: Joe Slater <jsla...@windriver.com<mailto:jsla...@windriver.com>>
+

-diff --git a/libgnome-desktop/gnome-desktop-thumbnail.c 
b/libgnome-desktop/gnome-desktop-thumbnail.c
-index e56c3d7..5d96bf3 100644
 --- a/libgnome-desktop/gnome-desktop-thumbnail.c
 +++ b/libgnome-desktop/gnome-desktop-thumbnail.c
 @@ -120,6 +120,8 @@
@@ -30,24 +29,23 @@ index e56c3d7..5d96bf3 100644
char *tmp_path = NULL;
int tmp_fd;
char mtime_str[21];
-+  struct tm *tmp_mtime = NULL;
++  struct tm tmp_mtime;
gboolean ret = FALSE;
GError *error = NULL;
const char *width, *height;
-@@ -1124,7 +1127,11 @@ save_thumbnail (GdkPixbuf  *pixbuf,
+@@ -1124,7 +1127,10 @@ save_thumbnail (GdkPixbuf  *pixbuf,
  goto out;
close (tmp_fd);

 -  g_snprintf (mtime_str, 21, "%" G_GINT64_FORMAT, (gint64) mtime);
-+  tmp_mtime = localtime ();
-+  if (!tmp_mtime)
++  if (!localtime_r (,_mtime))
 +goto out;
-+  strftime (mtime_str, 21, "%s", tmp_mtime);
-+  free (tmp_mtime);
++
++  strftime (mtime_str, 21, "%s", _mtime);
width = gdk_pixbuf_get_option (pixbuf, "tEXt::Thumb::Image::Width");
height = gdk_pixbuf_get_option (pixbuf, "tEXt::Thumb::Image::Height");

-@@ -1319,6 +1326,7 @@ gnome_desktop_thumbnail_is_valid (GdkPixbuf  
*pixbuf,
+@@ -1319,6 +1325,7 @@ gnome_desktop_thumbnail_is_valid (GdkPix
  {
const char *thumb_uri, *thumb_mtime_str;
time_t thumb_mtime;
@@ -55,7 +53,7 @@ index e56c3d7..5d96bf3 100644

thumb_uri = gdk_pixbuf_get_option (pixbuf, "tEXt::Thumb::URI");
if (g_strcmp0 (uri, thumb_uri) != 0)
-@@ -1327,7 +1335,11 @@ gnome_desktop_thumbnail_is_valid (GdkPixbuf  
*pixbuf,
+@@ -1327,7 +1334,11 @@ gnome_desktop_thumbnail_is_valid (GdkPix
thumb_mtime_str = gdk_pixbuf_get_option (pixbuf, "tEXt::Thumb::MTime");
if (!thumb_mtime_str)
  return FALSE;
@@ -68,6 +66,3 @@ index e56c3d7..5d96bf3 100644
if (mtime != thumb_mtime)
  return FALSE;

---
-2.14.1
-
--
2.7.4

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org<mailto:Openembedded-core@lists.openembedded.org>
http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [oe-core] SSTATEPOSTINSTFUNCS

[Slater, Joseph]

Neglecting buildhistory, there is only one recipe, I think, that uses 
SSTATEPOSTINSTFUNCS -- php-native, and that does not work.  Since there is 
nothing to compare to, I do not know if sysconfdir is set incorrectly, or if 
the function is supposed to realize it is under sysroot-destdir and adjust the 
path when modifying perf.conf.

I'd appreciate any advice.

Joe

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][PATCH 1/1] allarch: do not set baselib

[Slater, Joseph]

We should change fontcache.bbclass to not pass libdir, etc, to the 
update_font_cache script, since the environment will be set when the script 
executes.

That would solve the original problem, but it leaves the general problem of 
matching LD_LIBRARY_PATH for postinstall intercepts to the multilib for which 
the target binaries they run were compiled.  Or, of generating a 
LD_LIBRARY_PATH containing all possible paths for the rootfs being constructed.

Joe

From: Richard Purdie [richard.pur...@linuxfoundation.org]
Sent: Wednesday, January 03, 2018 1:58 PM
To: Slater, Joseph; Alexander Kanavin; 
openembedded-core@lists.openembedded.org; BURTON, ROSS
Subject: Re: [OE-core] [oe-core][PATCH 1/1] allarch: do not set baselib

On Wed, 2018-01-03 at 21:46 +, Slater, Joseph wrote:
> Currently, we do have to provide qemuwrapper with
> LD_LIBRARY_PATH.  We could hard-code all possible paths into that and
> not use ${libdir} and ${base_libdir}.  (I tried it and it works.)  We
> could also create a couple of new variables, like
> original_base_libdir, that don't get clobbered by allarch.   Maybe
> qemuwrapper should be smart enough to compute LD_LIBRARY_PATH...

I suspect somehow we therefore need to decouple qemuwrapper from the
target packages and just ensure that a separate script is available in
PATH when the rootfs is generated?

The rootfs should know which multilibs are enabled and be able to
generate the wrapper correctly?

Cheers,

Richard

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][PATCH 1/1] allarch: do not set baselib

[Slater, Joseph]

Currently, we do have to provide qemuwrapper with LD_LIBRARY_PATH.  We could 
hard-code all possible paths into that and not use ${libdir} and 
${base_libdir}.  (I tried it and it works.)  We could also create a couple of 
new variables, like original_base_libdir, that don't get clobbered by allarch.  
 Maybe qemuwrapper should be smart enough to compute LD_LIBRARY_PATH...

Joe

-Original Message-
From: Alexander Kanavin [mailto:alexander.kana...@linux.intel.com] 
Sent: Wednesday, January 03, 2018 12:43 AM
To: Richard Purdie; Slater, Joseph; openembedded-core@lists.openembedded.org; 
BURTON, ROSS
Subject: Re: [OE-core] [oe-core][PATCH 1/1] allarch: do not set baselib

On 01/03/2018 12:45 AM, Richard Purdie wrote:
> Sorry, but I don't think this can work :/.
> 
> Do the sstate sig selftests pass with this change?
> 
> I appreciate this will make some things "work" but it will mean that 
> allarch packages rebuild for each architecture or multilib and that 
> isn't right either.
> 
> So we need a better solution here. Why do we need libdir paths to run 
> binaries anyway? Is this a libexec issue? Perhaps the things in 
> question shouldn't be allarch?

I think Ross has spent some time developing a fix for this same issue, perhaps 
he can chime in?

Alex
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][PATCH 1/1] liberation-fonts: do not inherit allarch

[Slater, Joseph]

I tried the patch to the allarch class and the problem does away.Joe

From: Alexander Kanavin [alexander.kana...@linux.intel.com]
Sent: Friday, December 22, 2017 12:34 AM
To: Slater, Joseph; Richard Purdie; openembedded-core@lists.openembedded.org; 
BURTON, ROSS
Subject: Re: [OE-core] [oe-core][PATCH 1/1] liberation-fonts: do not inherit 
allarch

On 12/22/2017 02:00 AM, Slater, Joseph wrote:
> A number of postinstall's run target binaries, whether on the host or
> target.  This means they invoke qemu on the host and try to tell it
> where bits are.  I think it might not be necessary to pass explicit
> information about library locations to qemu, but that is the way it
> is done, and that information is arch dependent.  It might well be
> the case that "confusion" occurs only when multilib is enabled, but
> the point is that it does happen.

I think Ross had a different patch to deal with the multilib-qemu libray
confusion, so this might not yet be necessary.

Also, if this needs to be fixed, you need to fix it everywhere -
cantarell-fonts, adwaita-icon-theme, etc. etc.

Alex
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][PATCH 1/1] liberation-fonts: do not inherit allarch

[Slater, Joseph]

A number of postinstall's run target binaries, whether on the host or target.  
This means they invoke qemu on the host and try to tell it where bits are.  I 
think it might not be necessary to pass explicit information about library 
locations to qemu, but that is the way it is done, and that information is arch 
dependent.  It might well be the case that "confusion" occurs only when 
multilib is enabled, but the point is that it does happen.

I think it used to be the case that an attempt was made to run native versions 
of target tools during postinstall, but that seems to have been abandoned in 
favor of using qemu.  This means that if there is no qemu support, postinstall 
is deferred to first boot.  This is no problem except for read-only fs's, but 
they have other problems anyway.

Joe

-Original Message-
From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org] 
Sent: Thursday, December 21, 2017 2:28 PM
To: Slater, Joseph; openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [oe-core][PATCH 1/1] liberation-fonts: do not inherit 
allarch

On Thu, 2017-12-21 at 13:23 -0800, Joe Slater wrote:
> The fontcache class performs post-installation cache updating and 
> needs target architecture information.

Can you expand a bit on this? Do you mean that the postinstalls written into 
the packages are arch specific? Can we stop the scripts being arch specific?

Cheers,

Richard
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] backfill mechanism

[Slater, Joseph]

The problem is that when backfilling is done, TUNE_FEATURES, etc, all have 
values associated with the base arch, not the current multilib.  The "generic" 
solution, below, should work, although I would still use overrides when 
available.

Beyond what actually works, if the special backfill processing can be 
eliminated and regular constructs used I think that would be desirable.

Joe

From: Andre McCurdy [armccu...@gmail.com]
Sent: Monday, November 20, 2017 7:24 PM
To: Slater, Joseph
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] backfill mechanism

On Fri, Nov 17, 2017 at 3:32 PM, Slater, Joseph
<joe.sla...@windriver.com> wrote:
> The backfill mechanism is not compatible with multilib.

Did anyone ever explain why?

> This could possibly
> be fixed, but the backfill_considered functionality is also obscure, so I
> think in at least the machine related .inc files we should replace lines
> like
>
> MACHINE_FEATURES_BACKFILL_CONSIDERED_append = "
> ${@bb.utils.contains('TUNE_FEATURES', 'n32', 'qemu-usermode', '', d)}"
>
> with lines like
>
> MACHINE_FEATURES_remove_mipsarchn32 = " qemu-usermode"

That only works for TUNE_FEATURES which happen to have a corresponding
over-ride, so may not be a generic solution. Does something like:

  MACHINE_FEATURES_remove = "${@bb.utils.contains('TUNE_FEATURES',
'n32', 'qemu-usermode', '', d)}"

work for multilib?

> There are two advantages:  the second line works for multilib, and it is far
> more readable.
>
> Joe
>
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] backfill mechanism

[Slater, Joseph]

The backfill mechanism is not compatible with multilib.  This could possibly be 
fixed, but the backfill_considered functionality is also obscure, so I think in 
at least the machine related .inc files we should replace lines like

MACHINE_FEATURES_BACKFILL_CONSIDERED_append = " 
${@bb.utils.contains('TUNE_FEATURES', 'n32', 'qemu-usermode', '', d)}"

with lines like

MACHINE_FEATURES_remove_mipsarchn32 = " qemu-usermode"

There are two advantages:  the second line works for multilib, and it is far 
more readable.

Joe

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][PATCH 1/1] nss: pay attention to CFLAGS

[Slater, Joseph]

It is intentional that nss tries to configure CFLAGS for the particular build 
environment.  Another approach we could take here would be to only put in the 
prefix-mapping options (and -g).

Joe


-Original Message-
From: Khem Raj [mailto:raj.k...@gmail.com] 
Sent: Wednesday, November 15, 2017 11:39 AM
To: Slater, Joseph
Cc: Patches and discussions about the oe-core layer
Subject: Re: [OE-core] [oe-core][PATCH 1/1] nss: pay attention to CFLAGS

On Wed, Nov 15, 2017 at 10:54 AM, Joe Slater <jsla...@windriver.com> wrote:
> nss ignores CFLAGS so we suggest them via CC.

is that a limitation or intentional in nss build system.

>
> Signed-off-by: Joe Slater <jsla...@windriver.com>
> ---
>  meta/recipes-support/nss/nss_3.33.bb | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/meta/recipes-support/nss/nss_3.33.bb 
> b/meta/recipes-support/nss/nss_3.33.bb
> index e3d4f96..06d81ce 100644
> --- a/meta/recipes-support/nss/nss_3.33.bb
> +++ b/meta/recipes-support/nss/nss_3.33.bb
> @@ -104,7 +104,12 @@ do_compile() {
>  # We can modify CC in the environment, but if we set it via an
>  # argument to make, nsinstall, a host program, will also build with it!
>  #
> -export CC="${CC} -g"
> +# nss pretty much does its own thing with CFLAGS, so we put them into CC.
> +# Optimization will get clobbered, but most of the stuff will survive.
> +# The motivation for this is to point to the correct place for debug
> +# source files and CFLAGS does that.  Nothing uses CCC.
> +#
> +export CC="${CC} ${CFLAGS}"
>  make -C ./nss CCC="${CXX} -g" \
>  OS_TEST=${OS_TEST} \
>  RPATH="${RPATH}"
> --
> 2.7.4
>
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][PATCH 1/1] qemumips64: no qemu-usermode for n32

[Slater, Joseph]

Could be a multilib issue.  I do see that these constructs work in a poky build 
environment.  Are there any "standard" configurations that enable multilib?  I 
am typically building in a (surprise!) Wind River build environment which does 
support multilib.

Joe

From: Alexander Kanavin [alexander.kana...@linux.intel.com]
Sent: Friday, October 27, 2017 2:13 AM
To: Slater, Joseph; Andre McCurdy
Cc: OE Core mailing list
Subject: Re: [OE-core] [oe-core][PATCH 1/1] qemumips64: no qemu-usermode for n32

On 10/26/2017 11:51 PM, Slater, Joseph wrote:
> I think values for the BACKFILL_CONSIDERED can be used, but only if they are 
> literals.  I don't think any variable expansion occurs when getVar() is used 
> at the point of backfilling.  I think the a better way of setting MACHINE or 
> DISTRO_FEATURES would be to directly append/remove  using overrides.  In any 
> case, I do not believe any of the CONSIDERED definitions work.

We use the same-style disabling of qemu-usermode in other machine
definitions (powerpc64, x86 x32), and they do seem to work there.
Something's not right here.


Alex
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][PATCH 1/1] qemumips64: no qemu-usermode for n32

[Slater, Joseph]

I think values for the BACKFILL_CONSIDERED can be used, but only if they are 
literals.  I don't think any variable expansion occurs when getVar() is used at 
the point of backfilling.  I think the a better way of setting MACHINE or 
DISTRO_FEATURES would be to directly append/remove  using overrides.  In any 
case, I do not believe any of the CONSIDERED definitions work.

Joe

-Original Message-
From: Andre McCurdy [mailto:armccu...@gmail.com] 
Sent: Thursday, October 26, 2017 11:09 AM
To: Slater, Joseph
Cc: Alexander Kanavin; OE Core mailing list
Subject: Re: [OE-core] [oe-core][PATCH 1/1] qemumips64: no qemu-usermode for n32

On Thu, Oct 26, 2017 at 10:15 AM, Slater, Joseph <joe.sla...@windriver.com> 
wrote:
> Okay, I don't know why, but at the time of backfilling the CONSIDERED list is 
> empty!  This is not true if I use "=" to set it unconditionally in 
> arch-mips.inc, but it IS true if I try to set it via anything involving an 
> override (including append).
>
> Isn't getVar() supposed to expand the variable?  Put print msg's in 
> meta/lib/oe/utils.py to see this behavior.

features_backfill() is called from meta/classes/base.bbclass ->
base_eventhandler() in response to bb.event.ConfigParsed (ie "when the base 
configuration; which consists of bitbake.conf, base.bbclass and any global 
INHERIT statements; has been parsed") so anything assigned to 
DISTRO_FEATURES_BACKFILL_CONSIDERED or MACHINE_FEATURES_BACKFILL_CONSIDERED 
after that event won't be seen...
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][PATCH 1/1] qemumips64: no qemu-usermode for n32

[Slater, Joseph]

Okay, I don't know why, but at the time of backfilling the CONSIDERED list is 
empty!  This is not true if I use "=" to set it unconditionally in 
arch-mips.inc, but it IS true if I try to set it via anything involving an 
override (including append).

Isn't getVar() supposed to expand the variable?  Put print msg's in 
meta/lib/oe/utils.py to see this behavior.

Joe

____
From: Slater, Joseph
Sent: Wednesday, October 25, 2017 11:24 AM
To: Andre McCurdy; Alexander Kanavin
Cc: OE Core mailing list
Subject: RE: [OE-core] [oe-core][PATCH 1/1] qemumips64: no qemu-usermode for n32

I found that libn32-gobject-introspection would not compile without the remove, 
but I could check again.  Joe

-Original Message-
From: Andre McCurdy [mailto:armccu...@gmail.com]
Sent: Wednesday, October 25, 2017 10:19 AM
To: Alexander Kanavin
Cc: Slater, Joseph; OE Core mailing list
Subject: Re: [OE-core] [oe-core][PATCH 1/1] qemumips64: no qemu-usermode for n32

On Wed, Oct 25, 2017 at 4:14 AM, Alexander Kanavin 
<alexander.kana...@linux.intel.com> wrote:
> On 10/25/2017 02:43 AM, Andre McCurdy wrote:
>>
>> On Tue, Oct 24, 2017 at 4:23 PM, Joe Slater <jsla...@windriver.com> wrote:
>>>
>>> qemu-usermode is only available for mips64 and o32 code.
>>
>> Isn't that already handled by
>> meta/conf/machine/include/mips/arch-mips.inc
>>
>># user mode qemu doesn't support mips64 n32: "Invalid ELF image
>> for this architecture"
>>MACHINE_FEATURES_BACKFILL_CONSIDERED_append = "
>> ${@bb.utils.contains('TUNE_FEATURES', 'n32', 'qemu-usermode', '', d)}"
>
> Yes, but this is really unreadable isn't it :) I don't see how anyone
> could grasp that the above means "remove qemu-usermode from
> MACHINE_FEATURES if
> n32 is in TUNE_FEATURES" (without diving into documentation).
>
> Any better way to express this would be appreciated.

Yes, BACKFILL_CONSIDERED always has been concept which baffles a lot of users - 
especially so since we quietly redefined it to mean not only "functionality 
which used to always be enabled but is now configurable" but now also 
"functionality which was not previously enabled but is now configurable and we 
want to enable by default and make it difficult for users to accidentally leave 
disabled".
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][PATCH 1/1] qemumips64: no qemu-usermode for n32

[Slater, Joseph]

I found that libn32-gobject-introspection would not compile without the remove, 
but I could check again.  Joe

-Original Message-
From: Andre McCurdy [mailto:armccu...@gmail.com] 
Sent: Wednesday, October 25, 2017 10:19 AM
To: Alexander Kanavin
Cc: Slater, Joseph; OE Core mailing list
Subject: Re: [OE-core] [oe-core][PATCH 1/1] qemumips64: no qemu-usermode for n32

On Wed, Oct 25, 2017 at 4:14 AM, Alexander Kanavin 
<alexander.kana...@linux.intel.com> wrote:
> On 10/25/2017 02:43 AM, Andre McCurdy wrote:
>>
>> On Tue, Oct 24, 2017 at 4:23 PM, Joe Slater <jsla...@windriver.com> wrote:
>>>
>>> qemu-usermode is only available for mips64 and o32 code.
>>
>> Isn't that already handled by 
>> meta/conf/machine/include/mips/arch-mips.inc
>>
>># user mode qemu doesn't support mips64 n32: "Invalid ELF image 
>> for this architecture"
>>MACHINE_FEATURES_BACKFILL_CONSIDERED_append = "
>> ${@bb.utils.contains('TUNE_FEATURES', 'n32', 'qemu-usermode', '', d)}"
>
> Yes, but this is really unreadable isn't it :) I don't see how anyone 
> could grasp that the above means "remove qemu-usermode from 
> MACHINE_FEATURES if
> n32 is in TUNE_FEATURES" (without diving into documentation).
>
> Any better way to express this would be appreciated.

Yes, BACKFILL_CONSIDERED always has been concept which baffles a lot of users - 
especially so since we quietly redefined it to mean not only "functionality 
which used to always be enabled but is now configurable" but now also 
"functionality which was not previously enabled but is now configurable and we 
want to enable by default and make it difficult for users to accidentally leave 
disabled".
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] AUTOREV, tags...

[Slater, Joseph]

I think it would be nicer if recipes that currently require network access to 
check repo version info warned, but did not fail to parse.  I actually think 
that allowing AUTOREV at all should be conditional, because it subverts 
reproducible builds.  I'd also guess that if tags change that is not a good 
sign, so is it really good to check for that?

Joe

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] go-runtime does not build for mips32r2 tune

[Slater, Joseph]

This is the default tune for qemumips.  It appears that the problem does not 
occur for an oe-core checkout just before the split creating go-runtime.

Before the split, go-helloworld will build, but after the split it will not 
because it needs go-runtime.

Joe
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] building module tools (do_make_scripts)

[Slater, Joseph]

A while ago I sent a patch to change the way the kernel module tools get built 
such that they would be built once, not each time a recipe that inherits 
module.bbclass runs.  The current way is wasteful and allows module recipes to 
interfere with each other.

I can send the patch again, but I would like to know if anyone, on principle, 
objects there being a module tool building recipe.

Joe
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] master-next

[Slater, Joseph]

Is there something "different" about this branch?  I find that if I have a 
local master and master-next, and am on master, when I do a pull master-next 
will wind up both ahead and behind origin/master-next.  If I switch to 
master-next and rebase, it might fail, or it might leave me with one or more 
"local" commits that are not mine.   For the case I tried today, it is commit 
3d4f241 which seems to only be on my local master-next, but came from Mark 
Horn/Ross Burton on August 2.

Can anyone explain this?

Joe

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][PATCH 1/1] php: move to version 7.1.8

[Slater, Joseph]

I’ll look at the CVEs.  LICENSE updated from 2016 to 2017.  Text is the same.   
 Joe

From: Martin Jansa [mailto:martin.ja...@gmail.com]
Sent: Tuesday, August 08, 2017 1:31 PM
To: Leonardo Sandoval
Cc: Slater, Joseph; Patches and discussions about the oe-core layer
Subject: Re: [OE-core] [oe-core][PATCH 1/1] php: move to version 7.1.8

And wrong ML

On Tue, Aug 8, 2017 at 9:37 PM, Leonardo Sandoval 
<leonardo.sandoval.gonza...@linux.intel.com<mailto:leonardo.sandoval.gonza...@linux.intel.com>>
 wrote:
On Tue, 2017-08-08 at 13:16 -0700, Joe Slater wrote:
> Fixes many CVEs.

would be a plus if you list those.

why LIC_FILES_CHKSUM changed?

Leo

>
> Signed-off-by: Joe Slater 
> <jsla...@windriver.com<mailto:jsla...@windriver.com>>
> ---
>  .../{php-7.1.0 => php-7.1.8}/change-AC_TRY_RUN-to-AC_TRY_LINK.patch | 0
>  meta-oe/recipes-devtools/php/{php_7.1.0.bb<http://php_7.1.0.bb> => 
> php_7.1.8.bb<http://php_7.1.8.bb>} | 6 +++---
>  2 files changed, 3 insertions(+), 3 deletions(-)
>  rename meta-oe/recipes-devtools/php/{php-7.1.0 => 
> php-7.1.8}/change-AC_TRY_RUN-to-AC_TRY_LINK.patch (100%)
>  rename meta-oe/recipes-devtools/php/{php_7.1.0.bb<http://php_7.1.0.bb> => 
> php_7.1.8.bb<http://php_7.1.8.bb>} (64%)
>
> diff --git 
> a/meta-oe/recipes-devtools/php/php-7.1.0/change-AC_TRY_RUN-to-AC_TRY_LINK.patch
>  
> b/meta-oe/recipes-devtools/php/php-7.1.8/change-AC_TRY_RUN-to-AC_TRY_LINK.patch
> similarity index 100%
> rename from 
> meta-oe/recipes-devtools/php/php-7.1.0/change-AC_TRY_RUN-to-AC_TRY_LINK.patch
> rename to 
> meta-oe/recipes-devtools/php/php-7.1.8/change-AC_TRY_RUN-to-AC_TRY_LINK.patch
> diff --git a/meta-oe/recipes-devtools/php/php_7.1.0.bb<http://php_7.1.0.bb> 
> b/meta-oe/recipes-devtools/php/php_7.1.8.bb<http://php_7.1.8.bb>
> similarity index 64%
> rename from meta-oe/recipes-devtools/php/php_7.1.0.bb<http://php_7.1.0.bb>
> rename to meta-oe/recipes-devtools/php/php_7.1.8.bb<http://php_7.1.8.bb>
> index 210d91f..c0b2541 100644
> --- a/meta-oe/recipes-devtools/php/php_7.1.0.bb<http://php_7.1.0.bb>
> +++ b/meta-oe/recipes-devtools/php/php_7.1.8.bb<http://php_7.1.8.bb>
> @@ -1,10 +1,10 @@
>  require php.inc
>
> -LIC_FILES_CHKSUM = 
> "file://LICENSE;md5=b602636d46a61c0ac0432bbf5c078fe4"
> +LIC_FILES_CHKSUM = 
> "file://LICENSE;md5=c0af599f66d0461c5837c695fcbc5c1e"
>
>  SRC_URI += 
> "file://change-AC_TRY_RUN-to-AC_TRY_LINK.patch"
> -SRC_URI[md5sum] = "54e364b60a88db77adb96aacb10f10a4"
> -SRC_URI[sha256sum] = 
> "68bcfd7deed5b3474d81dec9f74d122058327e2bed0ac25bbc9ec70995228e61"
> +SRC_URI[md5sum] = "d22451dc20bbdf4b8bb656dc787c2a36"
> +SRC_URI[sha256sum] = 
> "7064a00a9450565190890c7a4be04e646e0be73b2e0f8c46ae34419f343ca2f8"
>
>  PACKAGECONFIG[mysql] = "--with-mysqli=${STAGING_BINDIR_CROSS}/mysql_config \
>  
> --with-pdo-mysql=${STAGING_BINDIR_CROSS}/mysql_config \
> --
> 2.7.4
>


--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org<mailto:Openembedded-core@lists.openembedded.org>
http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] module.bbclass: move make scripts earlier

[Slater, Joseph]

This will break application of a patch submitted a little later yesterday which 
moves the make_scripts task.

Joe

From: openembedded-core-boun...@lists.openembedded.org 
[openembedded-core-boun...@lists.openembedded.org] on behalf of California 
Sullivan [california.l.sulli...@intel.com]
Sent: Thursday, July 27, 2017 11:14 AM
To: openembedded-core@lists.openembedded.org
Cc: WOLD, SAUL
Subject: [OE-core] [PATCH] module.bbclass: move make scripts earlier

Some out of tree modules require the scripts for configuration. For
example, backport-iwlwifi.

Signed-off-by: California Sullivan 
---
 meta/classes/module.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/module.bbclass b/meta/classes/module.bbclass
index 391776d..78d1b21 100644
--- a/meta/classes/module.bbclass
+++ b/meta/classes/module.bbclass
@@ -1,6 +1,6 @@
 inherit module-base kernel-module-split pkgconfig

-addtask make_scripts after do_prepare_recipe_sysroot before do_compile
+addtask make_scripts after do_prepare_recipe_sysroot before do_configure
 do_make_scripts[lockfiles] = "${TMPDIR}/kernel-scripts.lock"
 do_make_scripts[depends] += "virtual/kernel:do_shared_workdir"

--
2.9.4

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][PATCH 1/1] modules: move creation of some module related tools

[Slater, Joseph]

Below, is the error and a heavily edited log file.  For those in Wind River, 
the issue is LIN10-858.  Btw, there is duplicate script building code in my 
patch because I forgot to take it out of do_compile_kernelmodules() which is 
where I first moved it to.

Joe



  LD 
/home/wrlbuild/builds/builds-c23c9015-5785-4a83-8075-2a2fa9401ba3/wrlinux-std-sato_intel-skylake-avx512-64_world_10/tmp/work/intel_skylake_avx512_64-wrs-linux/hello-mod/0.1-r0/built-in.o
   CC [M] 
/home/wrlbuild/builds/builds-c23c9015-5785-4a83-8075-2a2fa9401ba3/wrlinux-std-sato_intel-skylake-avx512-64_world_10/tmp/work/intel_skylake_avx512_64-wrs-linux/hello-mod/0.1-r0/hello.o
   Building modules, stage 2.
   MODPOST 1 modules
 /bin/sh: scripts/mod/modpost: Permission denied
 make
 [3]: *** 
[/home/wrlbuild/builds/builds-c23c9015-5785-4a83-8075-2a2fa9401ba3/wrlinux-std-sato_intel-skylake-avx512-64_world_10/tmp/work-shared/intel-skylake-avx512-64/kernel-source/scripts/Makefile.modpost:91:
 __modpost] Error 126
 make[2]: *** 
[/home/wrlbuild/builds/builds-c23c9015-5785-4a83-8075-2a2fa9401ba3/wrlinux-std-sato_intel-skylake-avx512-64_world_10/tmp/work-shared/intel-skylake-avx512-64/kernel-source/Makefile:1475:
 modules] Error 2

(modpost is under work-shared)





 [2017-07-13 21:02:39.512674040-07:00] NOTE: recipe hello-mod-0.1-r0: task 
do_make_scripts: Started

 [2017-07-13 21:02:39.648216523-07:00] NOTE: recipe 
module-debug-example-0.99-r0: task do_make_scripts: Started

 [2017-07-13 21:02:44.190642236-07:00] NOTE: recipe hello-mod-0.1-r0: task 
do_configure: Started

 [2017-07-13 21:02:44.308167085-07:00] NOTE: recipe hello-mod-0.1-r0: task 
do_configure: Succeeded

 [2017-07-13 21:02:45.074545820-07:00] NOTE: recipe 
module-debug-example-0.99-r0: task do_configure: Started

 [2017-07-13 21:02:45.077889943-07:00] NOTE: recipe 
module-debug-example-0.99-r0: task do_configure: Succeeded

 [2017-07-13 21:02:59.371609194-07:00] NOTE: recipe hello-mod-0.1-r0: task 
do_make_scripts: Succeeded

 [2017-07-13 21:03:00.149468691-07:00] NOTE: recipe hello-mod-0.1-r0: task 
do_compile: Started

 [2017-07-13 21:03:02.840652134-07:00] ERROR: hello-mod-0.1-r0 do_compile: 
oe_runmake failed
 [2017-07-13 21:03:04.406712693-07:00] ERROR: hello-mod-0.1-r0 do_compile: 
Function failed: do_compile (log file is located at 
/home/wrlbuild/builds/builds-c23c9015-5785-4a83-8075-2a2fa9401ba3/wrlinux-std-sato_intel-skylake-avx512-64_world_10/tmp/work/intel_skylake_avx512_64-wrs-linux/hello-mod/0.1-r0/temp/log.do_compile.110776)

 [2017-07-13 21:03:04.407703129-07:00] NOTE: recipe 
module-debug-example-0.99-r0: task do_make_scripts: Succeeded






From: Bruce Ashfield [mailto:bruce.ashfi...@gmail.com]
Sent: Friday, July 21, 2017 10:30 AM
To: Slater, Joseph
Cc: Patches and discussions about the oe-core layer
Subject: Re: [OE-core] [oe-core][PATCH 1/1] modules: move creation of some 
module related tools



On Fri, Jul 21, 2017 at 1:13 PM, Joe Slater 
<jsla...@windriver.com<mailto:jsla...@windriver.com>> wrote:
Move creation of tools needed by module building recipes into
kernel.bbclass but invoke the task only from the module recipes.
Without this change, one module recipe can fail trying to use the
tools while another is (re-)building them.

You are changing some core code that has been protecting our builds for
quite some time .. yet, you have no example of the errors that are being
seen, and no proof that this actually fixes the problem (and that it doesn't
introduce other issues).

i.e. how are the lock files no protecting this in whatever is breaking for you ?

Looking at the change, I'm not convinced it is the right thing to do.

i.e. putting something in kernel.bbclass that is only used by the modules
is less than ideal, without some sort of justification.

Bruce


Signed-off-by: Joe Slater <jsla...@windriver.com<mailto:jsla...@windriver.com>>
---
 meta/classes/kernel.bbclass  | 15 +++
 meta/classes/module-base.bbclass | 10 ++
 meta/classes/module.bbclass  |  4 
 3 files changed, 17 insertions(+), 12 deletions(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 7670c71..131387e 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -280,6 +280,11 @@ kernel_do_compile() {

 do_compile_kernelmodules() {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
+
+   # build modpost, etc
+   make CC="${KERNEL_CC}" LD="${KERNEL_LD}" AR="${KERNEL_AR}" \
+  -C ${STAGING_KERNEL_DIR} O=${STAGING_KERNEL_BUILDDIR} scripts
+
if (grep -q -i -e '^CONFIG_MODULES=y$' ${B}/.config); then
oe_runmake -C ${B} ${PARALLEL_MAKE} modules CC="${KERNEL_CC}" 
LD="${KERNEL_LD}" ${KERNEL_EXTRA_ARGS}

@@ -296,6 +301,16 @@ do_compile_kernelmodules() {
 }
 addtask compile_kernelmodules after do_compile before do_strip

+# Task to ensure the kernel scripts are created. Exp

Re: [OE-core] [oe-core][PATCH 1/1] ghostscript: move to version 9.21

[Slater, Joseph]

A couple of patches have been submitted moving ghostscript from 9.20 to 9.21.  
Should I submit a new one fixing the CUPSCONFIG issue, or is the one from Fan 
Xin being considered instead?

Joe


From: Slater, Joseph
Sent: Thursday, May 25, 2017 2:54 PM
To: Slater, Joseph; BURTON, ROSS
Cc: OE-core
Subject: RE: [OE-core] [oe-core][PATCH 1/1] ghostscript: move to version 9.21

Setting CUPSCONFIG as an argument to configure works.  I’ve filed a bug with 
ghostscript to
See if they confirm the issue.  I could modify my 9.21 patch to set CUPSCONFIG 
for target builds and
Things should be back to where they were.

Joe


From: 
openembedded-core-boun...@lists.openembedded.org<mailto:openembedded-core-boun...@lists.openembedded.org>
 [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Slater, 
Joseph
Sent: Thursday, May 25, 2017 12:44 PM
To: BURTON, ROSS
Cc: OE-core
Subject: Re: [OE-core] [oe-core][PATCH 1/1] ghostscript: move to version 9.21

I don’t know if it’s intentional, but it does seem to be a feature of 9.21 that 
cups support
Is never built even though configure finds cups.h and cups-config.

In trying to compare build logs, I see a new variable called BUILD_CUPSCONFIG 
which is
Set to what the old CUPSCONFIG variable was.  In the new log, CUPSCONFIG is 
null.

Joe

From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Thursday, May 25, 2017 5:50 AM
To: Slater, Joseph
Cc: OE-core
Subject: Re: [OE-core] [oe-core][PATCH 1/1] ghostscript: move to version 9.21


On 24 May 2017 at 18:39, Joe Slater 
<jsla...@windriver.com<mailto:jsla...@windriver.com>> wrote:
Eliminate CVE patches that are now in source.  Add CVE-2017-7975
patch.

packages/corei7-64-poky-linux/ghostscript/ghostscript: RDEPENDS: removed all 
items "cups-libimage (['>= 2.2.2']) cups-lib (['>= 2.2.2'])"

Is that intentional?

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][PATCH 1/1] ghostscript: move to version 9.21

[Slater, Joseph]

Setting CUPSCONFIG as an argument to configure works.  I’ve filed a bug with 
ghostscript to
See if they confirm the issue.  I could modify my 9.21 patch to set CUPSCONFIG 
for target builds and
Things should be back to where they were.

Joe


From: openembedded-core-boun...@lists.openembedded.org 
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Slater, 
Joseph
Sent: Thursday, May 25, 2017 12:44 PM
To: BURTON, ROSS
Cc: OE-core
Subject: Re: [OE-core] [oe-core][PATCH 1/1] ghostscript: move to version 9.21

I don’t know if it’s intentional, but it does seem to be a feature of 9.21 that 
cups support
Is never built even though configure finds cups.h and cups-config.

In trying to compare build logs, I see a new variable called BUILD_CUPSCONFIG 
which is
Set to what the old CUPSCONFIG variable was.  In the new log, CUPSCONFIG is 
null.

Joe

From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Thursday, May 25, 2017 5:50 AM
To: Slater, Joseph
Cc: OE-core
Subject: Re: [OE-core] [oe-core][PATCH 1/1] ghostscript: move to version 9.21


On 24 May 2017 at 18:39, Joe Slater 
<jsla...@windriver.com<mailto:jsla...@windriver.com>> wrote:
Eliminate CVE patches that are now in source.  Add CVE-2017-7975
patch.

packages/corei7-64-poky-linux/ghostscript/ghostscript: RDEPENDS: removed all 
items "cups-libimage (['>= 2.2.2']) cups-lib (['>= 2.2.2'])"

Is that intentional?

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][PATCH 1/1] ghostscript: move to version 9.21

[Slater, Joseph]

I don’t know if it’s intentional, but it does seem to be a feature of 9.21 that 
cups support
Is never built even though configure finds cups.h and cups-config.

In trying to compare build logs, I see a new variable called BUILD_CUPSCONFIG 
which is
Set to what the old CUPSCONFIG variable was.  In the new log, CUPSCONFIG is 
null.

Joe

From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Thursday, May 25, 2017 5:50 AM
To: Slater, Joseph
Cc: OE-core
Subject: Re: [OE-core] [oe-core][PATCH 1/1] ghostscript: move to version 9.21


On 24 May 2017 at 18:39, Joe Slater 
<jsla...@windriver.com<mailto:jsla...@windriver.com>> wrote:
Eliminate CVE patches that are now in source.  Add CVE-2017-7975
patch.

packages/corei7-64-poky-linux/ghostscript/ghostscript: RDEPENDS: removed all 
items "cups-libimage (['>= 2.2.2']) cups-lib (['>= 2.2.2'])"

Is that intentional?

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][v2][PATCH 1/1] build-compare: add date to PV

[Slater, Joseph]

> -Original Message-
> From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
> Sent: Thursday, March 16, 2017 3:14 PM
> To: Slater, Joseph; openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [oe-core][v2][PATCH 1/1] build-compare: add date to PV
> 
> On Thu, 2017-03-16 at 17:28 +, Slater, Joseph wrote:
> > Given that PV for *_git recipes should now be specified and
> > start with a version, it would be nice to shorten (or eliminate)
> > SRCPV.  At least get rid of the AUTOINC.  Perhaps shorten the
> > amount of SRCREV included.  The point is that as currently
> > computed, PV will be far longer than the useful information
> > it provides.
> 
> I thought we already did?
> 
> e.g. for the kernel you see packages like:
> 
> kernel-module-xt-u32-4.10.0-yocto-standard_4.10+git0+805ea440c7_b259a5d744-
> r0.30_qemux86_64.ipk
> 
> which has several shortened hashes in it.

I guess it matters where you look.  For things like rpm's you see 
"...+git0+...".  For things
like items generated by the archiver you see "...+gitAUTOINC+...".  In either 
case, the
characters appended to "git" do not seem to be useful.  And, since the 805... 
and b25...
hashes are just anecdotal because the -yocto determines version 
sequence, they could
be much shorter.

Joe

> 
> Cheers,
> 
> Richard
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][v2][PATCH 1/1] build-compare: add date to PV

[Slater, Joseph]

Given that PV for *_git recipes should now be specified and
start with a version, it would be nice to shorten (or eliminate)
SRCPV.  At least get rid of the AUTOINC.  Perhaps shorten the
amount of SRCREV included.  The point is that as currently
computed, PV will be far longer than the useful information
it provides.

Also, should PE be defined given that the form of PV has changed?
I know it hasn't been for any of the recipes modified so far.

Joe


> -Original Message-
> From: Joe Slater [mailto:jsla...@windriver.com]
> Sent: Thursday, March 16, 2017 10:19 AM
> To: openembedded-core@lists.openembedded.org
> Cc: Slater, Joseph
> Subject: [oe-core][v2][PATCH 1/1] build-compare: add date to PV
> 
> We want PV values to be easily ordered, so
> use the latest entry in build-compare.changes which
> will also match the date of SRCREV.
> 
> Signed-off-by: Joe Slater <jsla...@windriver.com>
> ---
>  .../build-compare/build-compare_git.bb |4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-devtools/build-compare/build-compare_git.bb 
> b/meta/recipes-
> devtools/build-compare/build-compare_git.bb
> index eb12e40..bdbad03 100644
> --- a/meta/recipes-devtools/build-compare/build-compare_git.bb
> +++ b/meta/recipes-devtools/build-compare/build-compare_git.bb
> @@ -17,8 +17,10 @@ SRC_URI = "git://github.com/openSUSE/build-compare.git \
> file://functions.sh-improve-deb-and-ipk-checking.patch \
> "
> 
> +# Date matches entry in build-compare.changes and date of SRCREV.
> +#
>  SRCREV = "c5352c054c6ef15735da31b76d6d88620f4aff0a"
> -PV = "git+${SRCPV}"
> +PV = "2015.02.10+git${SRCPV}"
> 
>  S = "${WORKDIR}/git"
> 
> --
> 1.7.9.5

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] SRCPV and git

[Slater, Joseph]

I believe that SRCPV for a git SRC_URI always contains the string AUTOINC.  
This could be considered
wrong, or just misleading, since SRCREV can be set to a sha.  I think I might 
have brought this up
in the past, but I cannot remember if there is some reason to retain the 
AUTOINC unconditionally.

Joe
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] oetest.py construction of pkgmanifest is probably wrong

[Slater, Joseph]

Hm, I see this whole thing is being re-written.  Maybe that will fix it.  
Joe

From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Tuesday, December 06, 2016 1:52 AM
To: Slater, Joseph
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] oetest.py construction of pkgmanifest is probably wrong


On 6 December 2016 at 02:24, Slater, Joseph 
<joe.sla...@windriver.com<mailto:joe.sla...@windriver.com>> wrote:
This variable is a dictionary with entries based on package, but for multillib 
a package might exist in only some variants.  Perhaps
each entry should be a dictionary of multilib variants?

Yeah, probably.  Got a patch? :)

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] oetest.py construction of pkgmanifest is probably wrong

[Slater, Joseph]

This variable is a dictionary with entries based on package, but for multillib 
a package might exist in only some variants.  Perhaps
each entry should be a dictionary of multilib variants?

Joe
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][PATCH 1/1] libwebp: do not assume armv7a has neon intrinsics

[Slater, Joseph]

> -Original Message-
> From: Andre McCurdy [mailto:armccu...@gmail.com]
> Sent: Tuesday, September 06, 2016 1:52 PM
> To: Slater, Joseph
> Cc: OE Core mailing list
> Subject: Re: [OE-core] [oe-core][PATCH 1/1] libwebp: do not assume armv7a has 
> neon
> intrinsics
> 
> On Tue, Sep 6, 2016 at 1:25 PM, Joe Slater <jsla...@windriver.com> wrote:
> > configure incorrectly thinks -mfpu=neon is in CC for armv7a,
> > so defeat automatic neon detection.
> >
> > Signed-off-by: Joe Slater <jsla...@windriver.com>
> > ---
> >  meta/recipes-multimedia/webp/libwebp_0.5.1.bb |3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/meta/recipes-multimedia/webp/libwebp_0.5.1.bb b/meta/recipes-
> multimedia/webp/libwebp_0.5.1.bb
> > index 222bd56..2d86b4a 100644
> > --- a/meta/recipes-multimedia/webp/libwebp_0.5.1.bb
> > +++ b/meta/recipes-multimedia/webp/libwebp_0.5.1.bb
> > @@ -26,6 +26,9 @@ EXTRA_OECONF = " \
> >  --enable-libwebpdemux \
> >  --enable-threading \
> >  "
> > +# configure incorrectly believes that armv7a has -mfpu=neon
> > +#
> > +EXTRA_OECONF_append_armv7a = " --disable-neon"
> 
> Unless you want to disable neon for all armv7a builds, perhaps
> something like this would be better:
> 
>   EXTRA_OECONF += "${@bb.utils.contains("TUNE_FEATURES", "neon", "",
> "--disable-neon" ,d)}"

That's a good idea, but I'd only do the check for arm.  Also, if we do have
neon, shouldn't the core be armv7a-neon, or something like that?  Can't we
rely on the overrides?

Joe


> 
> >  inherit autotools lib_package
> >
> > --
> > 1.7.9.5
> >
> > --
> > ___
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-commits] [openembedded-core] 01/02: systemd-compat-units: pkg_postinst() does not work

[Slater, Joseph]

At the cost of a little build time, I guess we could lose the inherit allarch.
As a practical matter, we could get rid of the RDEPEND (or make it a DEPEND?),
but that seems wrong, somehow.

Joe

> -Original Message-
> From: Martin Jansa [mailto:martin.ja...@gmail.com]
> Sent: Monday, August 22, 2016 7:21 AM
> To: openembedded-core@lists.openembedded.org; Slater, Joseph
> Cc: openembedded-comm...@lists.openembedded.org
> Subject: Re: [oe-commits] [openembedded-core] 01/02: systemd-compat-units: 
> pkg_postinst()
> does not work
> 
> On Thu, Aug 18, 2016 at 03:52:33PM +, g...@git.openembedded.org wrote:
> > rpurdie pushed a commit to branch master
> > in repository openembedded-core.
> >
> > commit 8183309080aee45746daaff46b0506b09b5bd269
> > Author: Joe Slater <jsla...@windriver.com>
> > AuthorDate: Mon Aug 15 16:04:53 2016 -0700
> >
> > systemd-compat-units: pkg_postinst() does not work
> >
> > The test for various files is wrong and will always be
> > true, even if init.d does not exist.
> >
> > Exit if init.d does not exist, and correctly test for
> > file existence otherwise.
> >
> > Signed-off-by: Joe Slater <jsla...@windriver.com>
> > Signed-off-by: Ross Burton <ross.bur...@intel.com>
> > ---
> >  meta/recipes-core/systemd/systemd-compat-units.bb | 17 ++---
> >  1 file changed, 10 insertions(+), 7 deletions(-)
> >
> > diff --git a/meta/recipes-core/systemd/systemd-compat-units.bb 
> > b/meta/recipes-
> core/systemd/systemd-compat-units.bb
> > index 0b8ff09..90811da 100644
> > --- a/meta/recipes-core/systemd/systemd-compat-units.bb
> > +++ b/meta/recipes-core/systemd/systemd-compat-units.bb
> > @@ -23,21 +23,24 @@ SYSTEMD_DISABLED_SYSV_SERVICES = " \
> >  "
> >
> >  pkg_postinst_${PN} () {
> > -   cd $D${sysconfdir}/init.d
> >
> > -   echo "Disabling the following sysv scripts: "
> > +   cd $D${sysconfdir}/init.d  ||  exit 0
> >
> > -   OPTS=""
> > +   echo "Disabling the following sysv scripts: "
> >
> > if [ -n "$D" ]; then
> > OPTS="--root=$D"
> > +   else
> > +   OPTS=""
> > fi
> >
> > for i in ${SYSTEMD_DISABLED_SYSV_SERVICES} ; do
> > -   if [ \( -e $i -o $i.sh \) -a ! \( -e 
> > $D${sysconfdir}/systemd/system/$i.service -
> o  -e $D${systemd_unitdir}/system/$i.service \) ] ; then
> > -   echo -n "$i: " ; systemctl ${OPTS} mask $i.service
> > +   if [ -e $i -o -e $i.sh ]  &&   ! [ -e 
> > $D${sysconfdir}/systemd/system/$i.service
> -o -e $D${systemd_unitdir}/system/$i.service ] ; then
> > +   echo -n "$i: "
> > +   systemctl $OPTS mask $i.service
> > fi
> > -   done ; echo
> > +   done
> > +   echo
> >  }
> >
> > -RDPEPENDS_${PN} = "systemd"
> > +RDEPENDS_${PN} = "systemd"
> 
> This is good typo fix, but also causes allarch systemd-compat-units to
> RDEPENDS on TUNE_PKGARCH systemd as reported in:
> http://lists.openembedded.org/pipermail/openembedded-core/2016-August/125483.html
> 
> So either please exclude it in layer.conf for drop this runtime
> dependency completely.
> 
> --
> Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] odd problem finding oe-gnome-terminal-phonehome

[Slater, Joseph]

I'm seeing strange behavior in terminal.py since the use of 
oe-gnome-terminal-phonehome was added.  If the script is on
my "base" path before starting a bitbake shell, everything is fine.  If it is 
under oe-core/scripts, terminal.py does not find it.  If I manually search PATH 
in terminal.py, I
will find it in oe-core/scripts and I can pass the full name when constructing 
sh_cmd.  That works fine, too.

I am wondering if something is not right with env as it is passed to 
XTerminal.__init__(self, sh_cmd, title, env, d), but that is just a wild guess.

Joe

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] recipes that inherit useradd delete users in do_configure

[Slater, Joseph]

This might or might not be a bug, but it does lead to unpleasant behavior if 
two recipes create the same user.  They probably should not, but who's stopping 
them?

I realize they are not in oe-core, but proftpd and vsftpd are an example of 
this.  We have seen failures when building world because proftpd creates "ftp",
then vsftpd deletes it, then proftpd tries to chown a directory to the now-gone 
"ftp".

Is this a recipe by recipe issue, or should something be changed in the 
behavior of useradd.bbclass?

Joe
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][PATCH 0/1] blacklist: add BPNBLACKLIST support

[Slater, Joseph]

I do not think I have seen any comments about Paul's suggestion, but I believe 
it
would be valuable to implement it.  World builds for multilib, or even manual 
builds
for a non-default lib type can get quite annoying when supposedly blacklisted 
recipes
are selected.  And, if these recipes do not fail, you are not building what you 
think
you are.

Joe


> -Original Message-
> From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
> Sent: Wednesday, June 22, 2016 7:30 PM
> To: openembedded-core@lists.openembedded.org
> Cc: Hatle, Mark; Slater, Joseph; Khem Raj
> Subject: Re: [OE-core] [oe-core][PATCH 0/1] blacklist: add BPNBLACKLIST 
> support
> 
> On Wed, 22 Jun 2016 17:45:55 Mark Hatle wrote:
> > On 6/22/16 5:35 PM, Khem Raj wrote:
> > > On Jun 22, 2016 2:59 PM, "Joe Slater" <jsla...@windriver.com
> > >
> > > <mailto:jsla...@windriver.com>> wrote:
> > >> We have encountered some issues with the use of PNBLACKLIST in recipes.
> > >> In particular, PNBLACKLIST[pkg] will not suppress building of lib32-pkg
> > >> or lib64-pkg so world builds can fail unexpectedly.
> > >>
> > >> One solution could be to implement BPNBLACKLIST[] which checks BPN
> > >> instead
> > >> of PN when a recipe is being parsed.  I have included a patch to do this.
> > >>
> > >> If this were adopted, there are many recipes under meta-openembedded that
> > >> should probably changed to use BPNBLACKLIST instead of PNBLACKLIST.
> > >
> > > Bpn will also mean native and nativesdk among others. I think its better
> > > to list multilibs explicitly.
> >
> > This is intentional.
> >
> > The problem with saying we have to list multilibs explicitly.  multilib
> > naming is arbitrary.  I can say that it probably fits the pattern of lib64,
> > lib32, libn32 and libx32 but it doesn't have to.
> >
> > But then I'd also need to blacklist native and nativesdk versions as well..
> > so for a simple recipe that for some reason I want blacklisted, it's easier
> > to hack the recipe to just blacklist itself -- then enter 7 or more
> > blacklists.
> >
> > Using the BPNBLACKLIST I can blacklist a single recipe with one command and
> > not worry about multilibs, class extensions, etc.
> >
> > (The patch leave PNBLACKLIST, specifically so that in the case where you
> > want only partial usage blacklisted you can.)
> 
> So blacklist.bbclass already has code to extend PNBLACKLIST with multilib
> variants - so we don't actually need this for multilib, right? It only helps
> cover multilib and native/nativesdk AFAICT.
> 
> If we are going to make changes here I do have an alternative suggestion -
> a while ago I wrote this patch but never got around to sending it because
> I wasn't quite sure if it's the right approach. It makes PNBLACKLIST work
> a bit more like other variables where you use overrides rather than
> varflags to make it specific to a recipe:
> 
>   http://git.yoctoproject.org/cgit/cgit.cgi/poky-
> contrib/commit/?h=paule/stuff3=7383419cbe69c4d62b9695e6ae65adc8b54741f7
> 
> Does anyone else see value in this?
> 
> Cheers,
> Paul
> 
> --
> 
> Paul Eggleton
> Intel Open Source Technology Centre
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][PATCH 0/1] blacklist: add BPNBLACKLIST support

[Slater, Joseph]

> -Original Message-
> From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
> Sent: Wednesday, June 22, 2016 7:30 PM
> To: openembedded-core@lists.openembedded.org
> Cc: Hatle, Mark; Slater, Joseph; Khem Raj
> Subject: Re: [OE-core] [oe-core][PATCH 0/1] blacklist: add BPNBLACKLIST 
> support
> 
> On Wed, 22 Jun 2016 17:45:55 Mark Hatle wrote:
> > On 6/22/16 5:35 PM, Khem Raj wrote:
> > > On Jun 22, 2016 2:59 PM, "Joe Slater" <jsla...@windriver.com
> > >
> > > <mailto:jsla...@windriver.com>> wrote:
> > >> We have encountered some issues with the use of PNBLACKLIST in recipes.
> > >> In particular, PNBLACKLIST[pkg] will not suppress building of lib32-pkg
> > >> or lib64-pkg so world builds can fail unexpectedly.
> > >>
> > >> One solution could be to implement BPNBLACKLIST[] which checks BPN
> > >> instead
> > >> of PN when a recipe is being parsed.  I have included a patch to do this.
> > >>
> > >> If this were adopted, there are many recipes under meta-openembedded that
> > >> should probably changed to use BPNBLACKLIST instead of PNBLACKLIST.
> > >
> > > Bpn will also mean native and nativesdk among others. I think its better
> > > to list multilibs explicitly.
> >
> > This is intentional.
> >
> > The problem with saying we have to list multilibs explicitly.  multilib
> > naming is arbitrary.  I can say that it probably fits the pattern of lib64,
> > lib32, libn32 and libx32 but it doesn't have to.
> >
> > But then I'd also need to blacklist native and nativesdk versions as well..
> > so for a simple recipe that for some reason I want blacklisted, it's easier
> > to hack the recipe to just blacklist itself -- then enter 7 or more
> > blacklists.
> >
> > Using the BPNBLACKLIST I can blacklist a single recipe with one command and
> > not worry about multilibs, class extensions, etc.
> >
> > (The patch leave PNBLACKLIST, specifically so that in the case where you
> > want only partial usage blacklisted you can.)
> 
> So blacklist.bbclass already has code to extend PNBLACKLIST with multilib
> variants - so we don't actually need this for multilib, right? It only helps
> cover multilib and native/nativesdk AFAICT.

But the original problem was that PNBLACKLIST[] does not create more varflags
for multilib when used in a recipe.  Anyway, I like your approach.  Of course, 
I also liked
introducing a variable named SELFBLACKLIST, too.  I guess, then,

PNBLACKLIST_class-target in a recipe would be the same as
PNBLACKLIST[pkg] in a conf file is today (if pkg is a "vanilla" name).

Maybe the old syntax could be deprecated and the eventhandler in the class 
ditched at some point?

Joe

> 
> If we are going to make changes here I do have an alternative suggestion -
> a while ago I wrote this patch but never got around to sending it because
> I wasn't quite sure if it's the right approach. It makes PNBLACKLIST work
> a bit more like other variables where you use overrides rather than
> varflags to make it specific to a recipe:
> 
>   http://git.yoctoproject.org/cgit/cgit.cgi/poky-
> contrib/commit/?h=paule/stuff3=7383419cbe69c4d62b9695e6ae65adc8b54741f7
> 
> Does anyone else see value in this?
> 
> Cheers,
> Paul
> 
> --
> 
> Paul Eggleton
> Intel Open Source Technology Centre
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] PIXBUFCACHE_SYSROOT_DEPS (librsvg)

[Slater, Joseph]

This variable is used by librsvg_2.40.10.bb, but I can't find anybody who 
processes it, at least not a bbclass.

Without adding an explicit do_populate_sysroot_setscene[depends] to the recipe, 
gdk-pixbuf-native
will install from sstate after librsvg-native and clobber the svg loader.  At 
least it does for my configuration.

Joe

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][PATCH 1/1] dpkg: put start-stop-daemon in its own package

[Slater, Joseph]

That's fine with me.  I'll rename the package and eliminate the comment.   Joe

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org 
> [mailto:openembedded-core-
> boun...@lists.openembedded.org] On Behalf Of Andreas Oberritter
> Sent: Tuesday, September 08, 2015 11:21 AM
> To: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [oe-core][PATCH 1/1] dpkg: put start-stop-daemon in 
> its own package
> 
> Hello Joe,
> 
> On 08.09.2015 18:20, Joe Slater wrote:
> > @@ -67,6 +73,18 @@ PROV_class-native = ""
> >
> >  PROVIDES += "${PROV}"
> >
> > +# split out start-stop-daemon to its own package
> > +#
> > +PACKAGES =+ "${PN}-start-stop"
> > +FILES_${PN}-start-stop = "${base_sbindir}/start-stop-daemon.dpkg"
> > +
> > +ALTERNATIVE_PRIORITY="100"
> > +ALTERNATIVE_${PN}-start-stop = "start-stop-daemon"
> > +ALTERNATIVE_LINK_NAME[start-stop-daemon]="${base_sbindir}/start-stop-daemon"
> > +
> > +RDEPENDS_${PN} += "${PN}-start-stop"
> > +#
> > +
> 
> I think you should omit the comment, because it only describes the obvious.
> 
> How about using ${PN}-start-stop-daemon?
> 
> Regards,
> Andreas
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][PATCH 1/1] busybox: more nails in the coffin

[Slater, Joseph]

> -Original Message-
> From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
> Sent: Friday, September 04, 2015 10:33 PM
> To: Slater, Joseph
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [oe-core][PATCH 1/1] busybox: more nails in the coffin
> 
> On Fri, 2015-09-04 at 19:18 -0700, Joe Slater wrote:
> > Create packagegroup-busybox and modify packagegroup-core-boot
> > to conditionally use it.
> 
> This says what it goes but not why. I'm also less than keen on the
> subject line :/.

Yes, the why should be there.  I kind of like the subject line, but
it won't be the same when I re-submit this.

> 
> > Signed-off-by: Joe Slater <jsla...@windriver.com>
> > ---
> >  .../packagegroups/packagegroup-busybox.bb  |   23 
> > 
> >  .../packagegroups/packagegroup-core-boot.bb|   17 ---
> >  2 files changed, 32 insertions(+), 8 deletions(-)
> >  create mode 100644 meta/recipes-core/packagegroups/packagegroup-busybox.bb
> >
> > diff --git a/meta/recipes-core/packagegroups/packagegroup-busybox.bb 
> > b/meta/recipes-
> core/packagegroups/packagegroup-busybox.bb
> > new file mode 100644
> > index 000..acf0791
> > --- /dev/null
> > +++ b/meta/recipes-core/packagegroups/packagegroup-busybox.bb
> > @@ -0,0 +1,23 @@
> > +#
> > +# Copyright (C) 2015 Wind River Inc.
> > +#
> > +
> > +SUMMARY = "Busybox related information"
> > +DESCRIPTION = "Busybox packages and variables"
> > +LICENSE = "MIT"
> > +
> > +PACKAGE_ARCH = "${MACHINE_ARCH}"
> > +
> > +inherit packagegroup
> > +
> > +# Do not ever, ever override LOCAL variables.
> > +#
> 
> Why?

The comment should not be there.  I'll remove it.  Maybe there is
a naming convention, but I'd like recipes to have truly local variables.

> 
> > +LOCAL_sysvinit = " \
> > +   ${@bb.utils.contains('MACHINE_FEATURES', 'rtc', 
> > 'busybox-hwclock',
> '', d)} \
> > +   "
> > +
> > +RDEPENDS_${PN} = "\
> > +busybox \
> > +${@bb.utils.contains("DISTRO_FEATURES", "sysvinit", 
> > "${LOCAL_sysvinit}", "", d)} \
> > +"
> > +
> > diff --git a/meta/recipes-core/packagegroups/packagegroup-core-boot.bb 
> > b/meta/recipes-
> core/packagegroups/packagegroup-core-boot.bb
> > index 09f5373..b2d0775 100644
> > --- a/meta/recipes-core/packagegroups/packagegroup-core-boot.bb
> > +++ b/meta/recipes-core/packagegroups/packagegroup-core-boot.bb
> > @@ -17,14 +17,17 @@ inherit packagegroup
> >  MACHINE_ESSENTIAL_EXTRA_RDEPENDS ?= ""
> >  MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS ?= ""
> >
> > -# Distro can override the following VIRTUAL-RUNTIME providers:
> > +# These can be overridden in any .conf file.
> > +#
> >  VIRTUAL-RUNTIME_dev_manager ?= "udev"
> > -VIRTUAL-RUNTIME_login_manager ?= "busybox"
> > -VIRTUAL-RUNTIME_init_manager ?= "sysvinit"
> >  VIRTUAL-RUNTIME_initscripts ?= "initscripts"
> >  VIRTUAL-RUNTIME_keymaps ?= "keymaps"
> > +VIRTUAL-RUNTIME_busybox ?= "packagegroup-busybox"
> 
> What about anyone who actually use these existing VIRTUAL-RUNTIME
> variables?

This could break things, but maybe not in a bad way.  
VIRTUAL-RUNTIME_init_manager
seems to conflict with the DISTRO_FEATURES sysvinit/systemd.  Maybe _busybox 
could
be eliminated and _login_manager be preserved and set to packagegroup-busybox.

Joe

> 
> Cheers,
> 
> Richard
> 

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][PATCH 1/2] ifupdown: import recipe

[Slater, Joseph]

> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org 
> [mailto:openembedded-core-
> boun...@lists.openembedded.org] On Behalf Of Richard Purdie
> Sent: Thursday, September 03, 2015 2:39 PM
> To: Khem Raj
> Cc: Patches and discussions about the oe-core layer; Slater, Joseph; Otavio 
> Salvador
> Subject: Re: [OE-core] [oe-core][PATCH 1/2] ifupdown: import recipe
> 
> On Thu, 2015-09-03 at 14:15 -0700, Khem Raj wrote:
> > > On Sep 3, 2015, at 1:27 PM, Richard Purdie 
> > > <richard.pur...@linuxfoundation.org> wrote:
> > >
> > > On Thu, 2015-09-03 at 13:22 -0700, Khem Raj wrote:
> > >> On Thu, Sep 3, 2015 at 5:20 AM, Bruce Ashfield 
> > >> <bruce.ashfi...@gmail.com> wrote:
> > >>>> To put this another way, I think it is probably reasonable that we
> > >>>> should be able to build an image from OE-Core with basic functionality
> > >>>> like networking without busybox?
> > >>>
> > >>> That's what I'd support. If everything you need for the functionality 
> > >>> with busy
> > >>> box is in oe-core, to me, it doesn't make sense to go outside core to 
> > >>> get that
> > >>> same functionality without busybox.
> > >>
> > >> irrespective of this change. I see yet another configuration with this
> > >> into OE-core, overall OE-Core should get smaller
> > >> and case does not sound convincing to me. You dont want to use busybox
> > >> in a fairly large image which has other GPLv2 software in
> > >> it. Thats fine but doesnt look like a common usecase to me
> > >
> > > Nobody mentioned GPLv2, that isn't relevant here.
> >
> > I assumed thats one reason to not include it. I am trying to understand 
> > reasoning to
> > not include busybox. Or is is just because its a poster child for 
> > litigations.
> 
> The litigation issues surrounding it certainly don't do it any favours,
> but the main issue is that if busybox is there, we're not seen as a
> "proper/full" linux.
> 
> > > I have heard OE being dismissed since it can't produce an image without
> > > busybox in it. The implication is we can't build "big" Linux, only small
> > > embedded things. The pieces we need busybox for are tiny and should be
> > > easy to replace (like this does).
> >
> > as we include other alternative providers, they get preference over busybox 
> > applets
> > even if busybox is part of it.
> 
> The problem is some people don't want any busybox.
> 
> > > So I can see a fairly compelling argument for OE-Core to be able to
> > > generate a busybox free image with standard functionality just from a PR
> > > perspective. From what I gather we have people willing to test and
> > > maintain it too…
> >
> > PR I see. I was searching for technical reasons.
> 
> Well, its technical but related to the image of the project too. Can
> OE-Core today produce a "standard linux desktop" type "full" featured
> filesystem? I cannot honestly say it can due to this reason, busybox has
> to be there. There are some people who do discount OE because of this.
> This isn't new, I remember Marcin amongst others working on this. We're
> close, but close doesn't mean we can answer "yes" to the question and I
> think it would be nice to be able to do so clearly.

I think if we are trying to allow removing busybox, the functionality needed
should be in oe-core.  Thus, we pull run-parts out of debianutils (this is now
in oe-core, master), pull start-stop-daemon from dpkg (I sent a patch, but I 
have not seen
any action), and we add ifupdown.  shadow is there, as is util-linux-blkid.

Me?  I kind of like busybox, but I also think we should provide images without 
it.

Joe

> 
> Cheers,
> 
> Richard
> 
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] NO_GENERIC_LICENSE

[Slater, Joseph]

I believe that if we specify NO_GENERIC_LICENSE[X] in a recipe that unless we 
name the license file generic_X, we will see a
QA warning when the fs is put together.

Perhaps we could take care of this by having the code which copies the special 
license also create a link to it named generic_X.
Or, maybe, the link could be special_X and we could search for generic or 
special cases in the QA code?

Of course, we could force conventional naming of license files, too...

Joe

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][PATCH 1/1] nss: advance to version 3.19.1

[Slater, Joseph]

ok.  I think I just sent a new version of the patch (but for some reason I did 
not get a copy). Joe

From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Tuesday, July 28, 2015 12:46 PM
To: Slater, Joseph
Cc: OE-core
Subject: Re: [OE-core] [oe-core][PATCH 1/1] nss: advance to version 3.19.1


On 28 July 2015 at 20:11, Joe Slater 
jsla...@windriver.commailto:jsla...@windriver.com wrote:
+# override value in nss.inc
+#
+LIC_FILES_CHKSUM = file://nss/COPYING;md5=3b1e88e1b9c0b5a4b2881d46cce06a18 \
+
file://nss/lib/freebl/mpi/doc/LICENSE;md5=491f158d09d948466afce85d6f1fe18f \
+
file://nss/lib/freebl/mpi/doc/LICENSE-MPL;md5=5d425c8f3157dbf212db2ec53d9e5132

Having a separate inc file really helps with clear recipes doesn't it...
gripe mode off

According to the layer index there's only one recipe for NSS, so how about we 
just ditch the nss.inc?

Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][PATCH 1/1] ltp: find all .debug directories

[Slater, Joseph]

 -Original Message-
 From: Khem Raj [mailto:raj.k...@gmail.com]
 Sent: Wednesday, March 18, 2015 4:37 PM
 To: Slater, Joseph
 Cc: Patches and discussions about the oe-core layer
 Subject: Re: [OE-core] [oe-core][PATCH 1/1] ltp: find all .debug directories
 
 On Wed, Mar 18, 2015 at 3:34 PM, Joe Slater jsla...@windriver.com wrote:
   INHIBIT_PACKAGE_STRIP = 1
  +# However, test_arch_stripped is already stripped, so...
  +INSANE_SKIP_${PN} += already-stripped
  +
 
 Can this be avoided in the component make system instead

Do you mean not strip it when we build it?  I hesitate to have some named 
_stripped
not be.  Since nobody seems upset by the current qa error, I guess we could 
also
just ignore it.

Joe

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][PATCH 1/1] package.bbclass: decouple splitting and stripping

[Slater, Joseph]

I just found out that this patch will break qa for ltp packaging.  The ltp 
recipe
inhibits stripping which used to inhibit splitting.  If splitting is enabled,
there are several .debug directories in places packages.bbclass doesn't look, so
they wind up in ltp, not ltp-dbg.

It's tempting just to inhibit splitting since that was never really done 
before, anyhow,
but I suppose that's not the right way to fix it.

Joe


 -Original Message-
 From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
 Sent: Tuesday, March 17, 2015 2:20 PM
 To: Bernhard Reutner-Fischer
 Cc: Slater, Joseph; openembedded-core@lists.openembedded.org
 Subject: Re: [OE-core] [oe-core][PATCH 1/1] package.bbclass: decouple 
 splitting and
 stripping
 
 On Fri, 2015-03-13 at 23:50 +0100, Bernhard Reutner-Fischer wrote:
  On March 13, 2015 10:57:53 PM GMT+01:00, Joe Slater jsla...@windriver.com 
  wrote:
  Fix logic in split_and_strip_files() to allow splitting or
  stripping independently.  We also return quickly from this
  function if we have nothing to do.  We seek the following behavior:
  
  Strip / Split Behavior
  yes   / yes   binaries stripped; debug info and source in -dbg
  no/ yes   debug info and source in -dbg
  yes   / nobinaries stripped; -dbg packages empty
  no/ no-dbg packages empty (not a very useful case)
  
  Currently, no/yes does not work and is the same as no/no.
  
  Signed-off-by: Joe Slater jsla...@windriver.com
  ---
  meta/classes/package.bbclass |  108
  ++
   1 file changed, 57 insertions(+), 51 deletions(-)
  
  diff --git a/meta/classes/package.bbclass
  b/meta/classes/package.bbclass
  index 9f64ed7..ad8771f 100644
  --- a/meta/classes/package.bbclass
  +++ b/meta/classes/package.bbclass
  @@ -812,6 +812,12 @@ python fixup_perms () {
   }
  
   python split_and_strip_files () {
 
  +for root, dirs, files in cpath.walk(dvar):
  +for f in files:
  +file = os.path.join(root, f)
  +if file.endswith(.ko) and file.find(/lib/modules/) !=
  -1:
  +kernmods.append(file)
  +continue
  
  +# Skip debug files
  +if debugappend and file.endswith(debugappend):
  +continue
  +if debugdir and debugdir in
  os.path.dirname(file[len(dvar):]):
  +continue
  +
 
  It's a pity to first construct the files just to throw them away right 
  afterwards.
  Maybe there are other cpath.walk spots that would benefit from 
  file_not_endswith and dir
 filters?
 
 FWIW cpath is actually a caching wrapper around os.path so there is some
 amount of caching going on here behind the scenes. The current code has
 been profiled and the worst hot spots worked around with the cache...
 
 Its not perfect and I don't doubt more could be done but these pieces do
 seem to help a lot. The best thing we did is avoid a lot of syscall
 overhead.
 
 Cheers,
 
 Richard

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [oe-core] SECURITY_CFLAGS _FORTIFY_SOURCE

[Slater, Joseph]

-D_FORTIFY_SOURCE=2 is usually set in SECURITY_CFLAGS which will cause lots of 
warnings, and possibly failures, if DEBUG_BUILD=1.

Since there are already lots of package overrides for SECURITY_CFLAGS, we could 
just add more for packages that won't build under
these conditions, or

we could not insert -D_FORTIFY_SOURCE=2 if DEBUG_BUILD=1, or

we could not modify TARGET_CFLAGS with any SECURITY_CFLAGS for debug builds.

Before submitting a patch, I'd like to know what people think the general 
approach (if any) should be in changing security_flags.inc.

Joe

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][PATCH 1/1] sysprof: add aarch64 support

[Slater, Joseph]

It is not runtime tested.  The intent is to allow world builds for aarch64.

Joe


 -Original Message-
 From: Khem Raj [mailto:raj.k...@gmail.com]
 Sent: Monday, September 15, 2014 11:10 PM
 To: Slater, Joseph
 Cc: Patches and discussions about the oe-core layer
 Subject: Re: [OE-core] [oe-core][PATCH 1/1] sysprof: add aarch64 support
 
 On Fri, Sep 12, 2014 at 2:03 PM, Joe Slater jsla...@windriver.com wrote:
  -+#ifdef __arm__
  ++#if defined(__arm__) || defined(__aarch64__)
   +/*
 
 This code defined memory barriers for 32bit, Are you sure it should be
 same for 64bit as well ?
 how was this tested ?
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [oe-core][PATCH 1/1] sysprof: add aarch64 support

[Slater, Joseph]

 -Original Message-
 From: Burton, Ross [mailto:ross.bur...@intel.com]
 Sent: Sunday, September 14, 2014 1:44 PM
 To: Slater, Joseph
 Cc: OE-core
 Subject: Re: [OE-core] [oe-core][PATCH 1/1] sysprof: add aarch64 support
 
 On 12 September 2014 22:03, Joe Slater jsla...@windriver.com wrote:
  +++ b/meta/recipes-kernel/sysprof/files/rmb-arm.patch
 
 This patch is missing a signed-off-by and upstream-status.

I am not creating this patch, just modifying it.  The existing patch does
have an upstream-status.  To avoid this issue, I will fold the change to
util.h into the new patch and not touch rmb-arm.patch.

Joe


 
 Ross
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] INCOMPATIBLE_LICENSE - native vs target

[Slater, Joseph]

Is there some way to specify incompatible licenses for native recipes?  An 
alternate mechanism might work,
but here is a case in which it would be valuable:

If I do not allow AGPL licenses, rpm builds with db-5.  rpm-native builds with 
db-6.  When you try
to run rpm on the target it gets very upset, apparently with the database.  In 
any event, it is happy
if both rpm and rpm-native use db-6.

In this particular case, there could be some way, although I don't know what, 
to force rpm-native to
use the same db version as the target, but that doesn't sound like a great idea.

Joe

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] libxslt populate_sysroot dependencies

[Slater, Joseph]

 -Original Message-
 From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
 Sent: Tuesday, April 08, 2014 9:58 AM
 To: Slater, Joseph
 Cc: openembedded-core@lists.openembedded.org
 Subject: Re: [OE-core] libxslt populate_sysroot dependencies
 
 On Mon, 2014-04-07 at 23:25 +, Slater, Joseph wrote:
  I have attached a patch that makes sure libxml2-native is available
  when both it and libxslt-native
  are taken from sstate.
 
  The patch parallels one from a few weeks ago for pixbufcache, but the
  underlying problem might
  have been fixed since then.  I looked for likely commits, and didn't
  see anything, so this patch might still be needed.
 
 This is an shlibs depends, right? sstate should handle those correctly.
 If not, I'd like to see logs from a build where this doesn't happen on
 master please?

The bitbake I was using is a bit out of date, so I cloned a poky repo today
and did several builds of vala-native pulling libxml2-native and libxslt-native
from sstate.

I've attached the logs (truncated and annotated).  I think out_of_order.log 
shows that libxslt-native is
put in sysroot before libraries from libxml2 that it needs.

The in_order.log shows what happens after applying the populate sysroot 
[depends] patch.

I've attached the patch, too.

Joe

 
 There are fixes in master such as:
 
 http://git.yoctoproject.org/cgit.cgi/poky/commit/bitbake?id=d67f25da2d1acb8f5c833dad7a2c1f
 c710261d6c
 
 which may help although there are others. What version of bitbake were
 you seeing issues with?
 
 Cheers,
 
 Richard
 



in_order.log
Description: in_order.log


out_of_order.log
Description: out_of_order.log


0001-libxslt-native-add-populate_sysroot-dependencies.patch
Description: 0001-libxslt-native-add-populate_sysroot-dependencies.patch
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] libxslt populate_sysroot dependencies

[Slater, Joseph]

I've attached extracts from a very long log of a failure.  Turns out, it's not 
quite what I was expecting, but it does show the libxml2-native did not get to 
into sysroot before we tried to run xsltproc during the build of vala.

These failures are extremely rare, so I'll have to wait for another one to see 
if it's the same.  I realize that the build for libxml2 seems to have hung, 
but I also think that letting libxslt put itself into sysroot before what it 
needs to run is in there is dangerous.

Anyway, there's no way in the world I could do the number of builds necessary 
to see if it's still an issue with the current bitbake, so I'll just watch for 
more failures here.

This has been kind of a waste of your time.  Thanks for looking at it.

Joe


 -Original Message-
 From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
 Sent: Tuesday, April 08, 2014 2:34 PM
 To: Slater, Joseph
 Cc: openembedded-core@lists.openembedded.org
 Subject: Re: [OE-core] libxslt populate_sysroot dependencies
 
 On Tue, 2014-04-08 at 21:21 +, Slater, Joseph wrote:
 
   -Original Message-
   From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
   Sent: Tuesday, April 08, 2014 9:58 AM
   To: Slater, Joseph
   Cc: openembedded-core@lists.openembedded.org
   Subject: Re: [OE-core] libxslt populate_sysroot dependencies
  
   On Mon, 2014-04-07 at 23:25 +, Slater, Joseph wrote:
I have attached a patch that makes sure libxml2-native is available
when both it and libxslt-native
are taken from sstate.
   
The patch parallels one from a few weeks ago for pixbufcache, but the
underlying problem might
have been fixed since then.  I looked for likely commits, and didn't
see anything, so this patch might still be needed.
  
   This is an shlibs depends, right? sstate should handle those correctly.
   If not, I'd like to see logs from a build where this doesn't happen on
   master please?
 
  The bitbake I was using is a bit out of date, so I cloned a poky repo today
  and did several builds of vala-native pulling libxml2-native and 
  libxslt-native
  from sstate.
 
  I've attached the logs (truncated and annotated).  I think out_of_order.log 
  shows that
 libxslt-native is
  put in sysroot before libraries from libxml2 that it needs.
 
  The in_order.log shows what happens after applying the populate sysroot 
  [depends] patch.
 
  I've attached the patch, too.
 
 Thanks, I think I've been staring at too many builds for too long and
 have too many things cross threaded so I may have things confused,
 however I'm going to have a go at explaining this.
 
 The setscene dependencies typically work backwards. The system does this
 deliberately since in general if you can install say bash
 do_package_write_ipk, we can skip the toolchain and other tools since we
 have the ipk we want. bitbake someimage -c rootfs is a good example
 of that in action, the -c build default tends to be a bit greedy.
 
 The only time this reversal would cause a problem is for native/cross
 binaries *if* we execute them at setscene time. I know of two problem
 cases:
 
 a) gdk-pixbuf does this to create a correct index file within the
sysroot.
 b) the adduser parts are used to setup user accounts before sstate
packages are extracted.
 
 Those two cases have explicit setscene dependencies for those reasons. I
 am not aware of xlstproc being run at setscene time by anything so it
 doesn't need these dependencies.
 
 Ok you say, what if it extracts libxslt-native but then fails to extract
 libxml2-native?
 
 Well, when the main build happens, nothing with a dependency on
 libxsltproc will run until libxml2-native has been built.
 
 So, your logs actually show what I would expect to happen, the question
 is what behaviour do you see which isn't correct?
 
 Cheers,
 
 Richard
 
 
 


+[2014-03-23 12:31:11.879332327-07:00] NOTE: recipe libxslt-native-1.1.28-r0: 
task do_populate_lic_setscene: Started

+[2014-03-23 12:31:11.908110347-07:00] NOTE: recipe libxslt-native-1.1.28-r0: 
task do_populate_lic_setscene: Succeeded

+[2014-03-23 12:31:38.540056686-07:00] NOTE: recipe vala-native-0.16.0-r1.1: 
task do_populate_lic_setscene: Started

+[2014-03-23 12:31:38.817743976-07:00] NOTE: recipe vala-native-0.16.0-r1.1: 
task do_populate_lic_setscene: Succeeded

+[2014-03-23 12:31:49.252010692-07:00] NOTE: recipe libxslt-native-1.1.28-r0: 
task do_populate_sysroot_setscene: Started

+[2014-03-23 12:31:50.012436528-07:00] NOTE: recipe libxslt-native-1.1.28-r0: 
task do_populate_sysroot_setscene: Succeeded

+[2014-03-23 12:31:52.536860119-07:00] NOTE: recipe libxml2-native-2.9.1-r0.1: 
task do_populate_lic_setscene: Started

+[2014-03-23 12:31:53.192502289-07:00] NOTE: recipe libxml2-native-2.9.1-r0.1: 
task do_populate_lic_setscene: Succeeded

+[2014-03-23 12:32:47.888294107-07:00] NOTE: recipe libxml2-native-2.9.1-r0.1: 
task do_fetch: Started

+[2014-03-23 12:32:49.982555145-07:00] NOTE: recipe

[OE-core] libxslt populate_sysroot dependencies

[Slater, Joseph]

I have attached a patch that makes sure libxml2-native is available when both 
it and libxslt-native
are taken from sstate.

The patch parallels one from a few weeks ago for pixbufcache, but the 
underlying problem might
have been fixed since then.  I looked for likely commits, and didn't see 
anything, so this patch
might still be needed.

Joe



0001-libxslt-native-add-populate_sysroot-dependencies.patch
Description: 0001-libxslt-native-add-populate_sysroot-dependencies.patch
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] linuxdoc-tools: add dependency on texinfo

[Slater, Joseph]

I believe we will use the host makeinfo, if that exists, so we
won't automatically build texinfo-native.  But, if we are building
it at the same time we are trying to run makeinfo, we might get
our version instead of the host's, and our version might not be
fully installed.  At least, that looks like what happened for the
build failure this patch attempts to fix.

Joe


 -Original Message-
 From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
 Sent: Tuesday, November 12, 2013 2:47 AM
 To: Slater, Joseph
 Cc: openembedded-core@lists.openembedded.org
 Subject: Re: [OE-core] [PATCH 1/1] linuxdoc-tools: add dependency on texinfo
 
 On Fri, 2013-11-08 at 13:49 -0800, Joe Slater wrote:
  We do run makeinfo, so we want to DEPEND on texinfo-native.
 
 makeinfo is checked for by the sanity tests so we require it be present?
 
 Cheers,
 
 Richard
 
  Signed-off-by: Joe Slater jsla...@windriver.com
  ---
   .../linuxdoc-tools/linuxdoc-tools-native_0.9.69.bb |2 +-
   1 files changed, 1 insertions(+), 1 deletions(-)
 
  diff --git 
  a/meta/recipes-devtools/linuxdoc-tools/linuxdoc-tools-native_0.9.69.bb
 b/meta/recipes-devtools/linuxdoc-tools/linuxdoc-tools-native_0.9.69.bb
  index ba9c72e..d8122e6 100644
  --- a/meta/recipes-devtools/linuxdoc-tools/linuxdoc-tools-native_0.9.69.bb
  +++ b/meta/recipes-devtools/linuxdoc-tools/linuxdoc-tools-native_0.9.69.bb
  @@ -4,7 +4,7 @@ HOMEPAGE = http://packages.debian.org/linuxdoc-tools;
   LICENSE = GPLv3+
   LIC_FILES_CHKSUM = file://COPYING;md5=077ef64ec3ac257fb0d786531cf26931
 
  -DEPENDS = groff-native openjade-native
  +DEPENDS = groff-native openjade-native texinfo-native
 
 
   SRC_URI = 
  ${DEBIAN_MIRROR}/main/l/linuxdoc-tools/linuxdoc-tools_${PV}.orig.tar.gz \
 

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] FW: [v2][PATCH 1/1] vala.bbclass: add dependency on vala

[Slater, Joseph]

I sent the following a while ago and haven't seen any comments,
but I think it parallels the suggestions made about v1.

The patch has not been put into oe-core master.

Joe


-Original Message-
From: Joe Slater [mailto:jsla...@windriver.com] 
Sent: Thursday, September 26, 2013 11:53 AM
To: openembedded-core@lists.openembedded.org
Cc: MacLeod, Randy; Slater, Joseph
Subject: [v2][PATCH 1/1] vala.bbclass: add dependency on vala

This class points the inheritor, if it is a target,
to directories in the target sysroot, so we want to
be sure the .vapi files are there.

Signed-off-by: Joe Slater jsla...@windriver.com
---
 meta/classes/vala.bbclass |8 +---
 1 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/meta/classes/vala.bbclass b/meta/classes/vala.bbclass
index c7db08c..3b70a04 100644
--- a/meta/classes/vala.bbclass
+++ b/meta/classes/vala.bbclass
@@ -1,9 +1,11 @@
 # Vala has problems with multiple concurrent invocations
 PARALLEL_MAKE = 
 
-# Vala needs vala-native
-DEPENDS += vala-native
-DEPENDS_virtclass-native += vala-native
+# Everyone needs vala-native and targets need vala, too,
+# because that is where target builds look for .vapi files.
+#
+VALADEPENDS_class-target = vala
+DEPENDS_append =  vala-native ${VALADEPENDS}
 
 # Our patched version of Vala looks in STAGING_DATADIR for .vapi files
 export STAGING_DATADIR
-- 
1.7.3.4

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] webkit-gtk: limit ld memory requirement

[Slater, Joseph]

 -Original Message-
 From: Burton, Ross [mailto:ross.bur...@intel.com]
 Sent: Tuesday, September 17, 2013 3:53 AM
 To: Martin Jansa
 Cc: Khem Raj; Slater, Joseph; Patches and discussions about the oe-core layer
 Subject: Re: [OE-core] [PATCH 1/1] webkit-gtk: limit ld memory requirement
 
 On 17 September 2013 11:30, Martin Jansa martin.ja...@gmail.com wrote:
  I think someone should measure it on machine with a lot of ram. If the
  test was executed on machine where it was linking mostly from swap,
  then it's not so surprising it was faster with the option enabled.
 
 My very rough test says no significant difference between the option
 being enabled or disabled (~23m +- 30s each way).  i7 with 16GB RAM.
 
 Anyone else want to add a data point?

I am the only user on the machine below.  I compiled twice, each way --

model name  : Intel(R) Xeon(R) CPU   X5560  @ 2.80GHz
model name  : Intel(R) Xeon(R) CPU   X5560  @ 2.80GHz
model name  : Intel(R) Xeon(R) CPU   X5560  @ 2.80GHz
model name  : Intel(R) Xeon(R) CPU   X5560  @ 2.80GHz
model name  : Intel(R) Xeon(R) CPU   X5560  @ 2.80GHz
model name  : Intel(R) Xeon(R) CPU   X5560  @ 2.80GHz
model name  : Intel(R) Xeon(R) CPU   X5560  @ 2.80GHz
model name  : Intel(R) Xeon(R) CPU   X5560  @ 2.80GHz

MemTotal:   12326492 kB


build - present recipe
--
real48m26.620s
user96m15.939s
sys 17m43.639s

compile - present recipe

real25m39.845s
user85m31.102s
sys 10m17.016s

real25m31.344s
user85m35.210s
sys 9m46.309s

compile - new recipe

real25m28.338s
user85m27.088s
sys 10m19.696s

real25m22.355s
user85m24.133s
sys 10m13.151s





 
 Ross
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] audit oe-core

[Slater, Joseph]

Hi,

Several packages in oe-core have PACKAGECONFIG[] info, or the equivalent, 
concerning
explicitly disabling audit support.

Some people believe that PACKAGECONFIG[] data concerning features not in oe-core
should not be in oe-core.  I do think it should be there unless the package 
requires special
patching to implement the feature support.

Is there an oe-core policy about this type of thing?

Joe

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] coreutils: allow for acl support

[Slater, Joseph]

 -Original Message-
 From: Saul Wold [mailto:s...@linux.intel.com]
 Sent: Tuesday, August 13, 2013 2:48 PM
 To: Slater, Joseph
 Cc: openembedded-core@lists.openembedded.org
 Subject: Re: [OE-core] [PATCH 1/1] coreutils: allow for acl support
 
 On 08/13/2013 02:20 PM, Joe Slater wrote:
  CQID: 430353
 
  Define PACKAGECONFIG info for acl assuming it
  might be a DISTRO_FEATURE.
 
 
 Thanks for the Patch!
 
 Will you be doing the same for the GPLv2 version?

I guess I should.

 
 I guess this means we should be expecting a set of patches to enable
 other recipes that have --disable-acl by default?

Yeah, but I might not know whether some recipes really never, ever,
want acl support enabled.

Joe

 
 
 Thanks
 Sau!
  Signed-off-by: Joe Slater jsla...@windriver.com
  ---
meta/recipes-core/coreutils/coreutils_8.21.bb |   14 +++---
1 files changed, 11 insertions(+), 3 deletions(-)
 
  diff --git a/meta/recipes-core/coreutils/coreutils_8.21.bb b/meta/recipes-
 core/coreutils/coreutils_8.21.bb
  index 26ada48..e784329 100644
  --- a/meta/recipes-core/coreutils/coreutils_8.21.bb
  +++ b/meta/recipes-core/coreutils/coreutils_8.21.bb
  @@ -7,7 +7,7 @@ BUGTRACKER = http://debbugs.gnu.org/coreutils;
LICENSE = GPLv3+
LIC_FILES_CHKSUM = file://COPYING;md5=d32239bcb673463ab874e80d47fae504\
 
 file://src/ls.c;beginline=5;endline=16;md5=38b79785ca88537b75871782a2a3c6b8
  -PR = r0
  +PR = r1
DEPENDS = gmp libcap
DEPENDS_class-native = 
 
  @@ -22,8 +22,16 @@ SRC_URI = ${GNU_MIRROR}/coreutils/${BP}.tar.xz \
SRC_URI[md5sum] = 065ba41828644eca5dd8163446de5d64
SRC_URI[sha256sum] =
 adaa44bdab3fa5eb352e80d8a31fdbf957b78653d0c2cd30d63e161444288e18
 
  -EXTRA_OECONF = --disable-acl
  -EXTRA_OECONF_class-native = --disable-acl --without-gmp
  +EXTRA_OECONF_class-native = --without-gmp
  +
  +# acl is not a default feature
  +#
  +PACKAGECONFIG_class-target ??= ${@base_contains('DISTRO_FEATURES', 'acl', 
  'acl', '',
 d)}
  +PACKAGECONFIG_class-native ??= 
  +
  +# with, without, depends, rdepends
  +#
  +PACKAGECONFIG[acl] = --enable-acl,--disable-acl,acl,
 
# [ df mktemp base64 gets a special treatment and is not included in this
bindir_progs = basename chcon cksum comm csplit cut dir dircolors 
  dirname du \
 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] qt keyboard problem

[Slater, Joseph]

 -Original Message-
 From: Yi Qingliang [mailto:niqingliang2...@gmail.com]
 Sent: Thursday, May 16, 2013 5:46 PM
 To: Slater, Joseph
 Cc: openembedded-core@lists.openembedded.org oe-core layer
 Subject: Re: [OE-core] qt keyboard problem
 
 On Thursday, May 16, 2013 04:51:04 PM Slater, Joseph wrote:
   -Original Message-
   From: openembedded-core-boun...@lists.openembedded.org
   [mailto:openembedded-core- boun...@lists.openembedded.org] On Behalf Of
   Yi Qingliang
   Sent: Tuesday, May 14, 2013 11:19 PM
   To: openembedded-core@lists.openembedded.org oe-core layer
   Subject: [OE-core] qt keyboard problem
  
   Hello, all.
  
   I'm running qt application on yocto's qt image. cpu is s3c2442, like
   mini2440.
  
   the problem is:
  
   key event issued by pressing gpio-key eat by 'getty' (from busybox),
   my application can't receive input event,
   if I remove respawn 'getty' for tty1 in /etc/inittab, everything ok.
 
  This could be the same thing I have seen in a slightly different context.
  If so, you can keep the getty's attached to VT's.  Just move the line in
  inittab that starts runlevel 5 to the very end of inittab.  As long as the
  getty's start first, you'll be okay.
 
 you mean: move 'id:5:initdefault:' as the last line of the file, right?

No, the line is l5:5:wait:/etc/init.d/rc 5.

Joe


 
 
 
 
 
 
 
 # /etc/inittab: init(8) configuration.
 # $Id: inittab,v 1.91 2002/01/25 13:35:21 miquels Exp $
 
 # The default runlevel.
 id:5:initdefault:
 
 # Boot-time system configuration/initialization script.
 # This is run first except when booting in emergency (-b) mode.
 si::sysinit:/etc/init.d/rcS
 
 # What to do in single-user mode.
 ~~:S:wait:/sbin/sulogin
 
 # /etc/init.d executes the S and K scripts upon change
 # of runlevel.
 #
 # Runlevel 0 is halt.
 # Runlevel 1 is single-user.
 # Runlevels 2-5 are multi-user.
 # Runlevel 6 is reboot.
 
 l0:0:wait:/etc/init.d/rc 0
 l1:1:wait:/etc/init.d/rc 1
 l2:2:wait:/etc/init.d/rc 2
 l3:3:wait:/etc/init.d/rc 3
 l4:4:wait:/etc/init.d/rc 4
 l5:5:wait:/etc/init.d/rc 5
 l6:6:wait:/etc/init.d/rc 6
 # Normally not reached, but fallthrough in case of emergency.
 z6:6:respawn:/sbin/sulogin
 S:2345:respawn:/sbin/getty 115200 ttySAC0
 # /sbin/getty invocations for the runlevels.
 #
 # The id field MUST be the same as the last
 # characters of the device (after tty).
 #
 # Format:
 #  id:runlevels:action:process
 #
 
 1:2345:respawn:/sbin/getty 38400 tty1
 
 
 
 
  Joe
 
   any idea?
  
  
   --
   Nanjing Jilong
   Yi Qingliang
   niqingliang2...@gmail.com
  
   ___
   Openembedded-core mailing list
   Openembedded-core@lists.openembedded.org
   http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
 --
 Nanjing Jilong
 Yi Qingliang
 niqingliang2...@gmail.com

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] qt keyboard problem

[Slater, Joseph]

 -Original Message-
 From: openembedded-core-boun...@lists.openembedded.org 
 [mailto:openembedded-core-
 boun...@lists.openembedded.org] On Behalf Of Yi Qingliang
 Sent: Tuesday, May 14, 2013 11:19 PM
 To: openembedded-core@lists.openembedded.org oe-core layer
 Subject: [OE-core] qt keyboard problem
 
 Hello, all.
 
 I'm running qt application on yocto's qt image. cpu is s3c2442, like mini2440.
 
 the problem is:
 
 key event issued by pressing gpio-key eat by 'getty' (from busybox),
 my application can't receive input event,
 if I remove respawn 'getty' for tty1 in /etc/inittab, everything ok.

This could be the same thing I have seen in a slightly different context.
If so, you can keep the getty's attached to VT's.  Just move the line in
inittab that starts runlevel 5 to the very end of inittab.  As long as the
getty's start first, you'll be okay.

Joe


 
 any idea?
 
 
 --
 Nanjing Jilong
 Yi Qingliang
 niqingliang2...@gmail.com
 
 ___
 Openembedded-core mailing list
 Openembedded-core@lists.openembedded.org
 http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] zlib: put shared libraries in base_libdir

[Slater, Joseph]

 -Original Message-
 From: openembedded-core-boun...@lists.openembedded.org 
 [mailto:openembedded-core-
 boun...@lists.openembedded.org] On Behalf Of Mark Hatle
 Sent: Wednesday, May 15, 2013 6:08 AM
 To: openembedded-core@lists.openembedded.org
 Subject: Re: [OE-core] [PATCH 1/1] zlib: put shared libraries in base_libdir
 
 On 5/15/13 4:54 AM, Phil Blundell wrote:
  On Tue, 2013-05-14 at 16:35 -0700, Joe Slater wrote:
  We put the shared libraries in base_libdir because at least
  one library under base_libdir, pam_cracklib.so, needs them
  and will cause a qa warning when it is built.
 
  Which warning are you getting?  From the description it sounds like
  unsafe-references-in-binaries but that one has been disabled since
  2fb58da56e8e7044de21fd10fe9164d204587236.
 
 We have that enabled in our builds.  We do so because we have customers who
 still want the root, /usr split.

Yes, this is it:

WARNING: QA Issue: libpam: /lib64/security/pam_cracklib.so, installed in the 
base_prefix,
requires a shared library under exec_prefix
(/usr): libz.so.1 = /usr/lib64/libz.so.1 (0xdead5000)

Joe

 
 --Mark
 
  p.
 
 
 
  ___
  Openembedded-core mailing list
  Openembedded-core@lists.openembedded.org
  http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
 
 
 
 ___
 Openembedded-core mailing list
 Openembedded-core@lists.openembedded.org
 http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] zlib: put shared libraries in base_libdir

[Slater, Joseph]

 -Original Message-
 From: Phil Blundell [mailto:p...@pbcl.net]
 Sent: Wednesday, May 15, 2013 1:45 PM
 To: Slater, Joseph
 Cc: Hatle, Mark; openembedded-core@lists.openembedded.org
 Subject: Re: [OE-core] [PATCH 1/1] zlib: put shared libraries in base_libdir
 
 On Wed, 2013-05-15 at 19:50 +, Slater, Joseph wrote:
  Yes, this is it:
 
  WARNING: QA Issue: libpam: /lib64/security/pam_cracklib.so, installed in the
 base_prefix,
  requires a shared library under exec_prefix
  (/usr): libz.so.1 = /usr/lib64/libz.so.1 (0xdead5000)
 
 Presumably pam_cracklib.so can't go in /usr due to reasons, right?

Maybe it could, but all of its buddies are in /lib64/security and it might
get lonely.  At least we know that moving libz.so.* does not cause any
new problems because that's how we've been building for a long time.

Joe


 
 p.
 

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] distrodata.bbclass

[Slater, Joseph]

Hi,

I see this class for generating a report of package data, but I don't see it 
ever
being used.  Is there info about how to use it?

Joe

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] QEMU_UI_OPTIONS

[Slater, Joseph]

I notice that, by default, we pretend we have a touchscreen instead of a
mouse (-usbdevice wacom-tablet option) for the qemu bsp's.  Is there
some reason for this?

I have experimented  some and, with other adjustments, have found
it possible to not specify it, but I do admit interaction with the target
graphics window does seem cleaner if we do use it.

Joe

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] QEMU_UI_OPTIONS

[Slater, Joseph]

 -Original Message-
 From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
 Sent: Thursday, March 28, 2013 3:40 PM
 To: Bruce Ashfield
 Cc: Slater, Joseph; openembedded-core@lists.openembedded.org
 Subject: Re: [OE-core] QEMU_UI_OPTIONS
 
 On Thu, 2013-03-28 at 16:53 -0400, Bruce Ashfield wrote:
  On Thu, Mar 28, 2013 at 4:29 PM, Slater, Joseph
  joe.sla...@windriver.com wrote:
   I notice that, by default, we pretend we have a touchscreen instead of a
  
   mouse (-usbdevice wacom-tablet option) for the qemu bsp's.  Is there
  
   some reason for this?
 
  Avoiding screen grab is the best reason (and all that I need) to use
  the tablet options.
 
 Exactly. A mouse only gives relative position data so it has to grab,
 the touchscreen can do absolute position and hence doesn't need a grab.

That does seem cleaner.  I do see, also, that if there is a 
/dev/input/touchscreen0,
host mouse movements, etc, also appear on /dev/input/mice.  Might that be
confusing?  Is there some way for qemu to emulate a touchscreen while 
suppressing
the mouse?

Joe


 
 Cheers,
 
 Richard

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] dosfstools: really compile supporting large files [ Fix: 409915 ]

[Slater, Joseph]

 -Original Message-
 From: kerg...@gmail.com [mailto:kerg...@gmail.com] On Behalf Of Chris Larson
 Sent: Monday, March 25, 2013 2:16 PM
 To: Slater, Joseph
 Cc: Patches and discussions about the oe-core layer
 Subject: Re: [OE-core] [PATCH 1/1] dosfstools: really compile supporting 
 large files [
 Fix: 409915 ]
 
 
 On Mon, Mar 25, 2013 at 1:49 PM, Joe Slater jsla...@windriver.com wrote:
 
 
   CQID: 409915
 
   Makefile in the package tries to set _FILE_OFFSET_BITS=64,
   but we clobber that with our CFLAGS, so we add it in
   the recipe.
 
   Signed-off-by: Joe Slater jsla...@windriver.com
 
 
 Afaik there is a largefile distro feature, should this use that, through 
 packageconfig?

This is really aimed at dosfstools-native, but I noticed, just by chance, that 
bzip2
unconditionally sets this, apparently without ill effect.

Joe


 --
 Christopher Larson
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH [v3] 1/1] tzcode tzdata: update to 2013b versions

[Slater, Joseph]

 -Original Message-
 From: otavio.salva...@gmail.com [mailto:otavio.salva...@gmail.com] On Behalf 
 Of Otavio
 Salvador
 Sent: Monday, March 18, 2013 2:06 PM
 To: Slater, Joseph
 Cc: Patches and discussions about the oe-core layer
 Subject: Re: [OE-core] [PATCH [v3] 1/1] tzcode  tzdata: update to 2013b 
 versions
 
 On Mon, Mar 18, 2013 at 5:46 PM, Joe Slater jsla...@windriver.com wrote:
  Rename and modifying existing recipes to use 2013b
  versions of time zone.
 
  Signed-off-by: Joe Slater jsla...@windriver.com
 
 It seems a good timming to drop PR.

Do we not use PR anymore?   Joe

 
 --
 Otavio Salvador O.S. Systems
 E-mail: ota...@ossystems.com.br  http://www.ossystems.com.br
 Mobile: +55 53 9981-7854  http://projetos.ossystems.com.br

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] acpid: modify CFLAGS

[Slater, Joseph]

Thanks for looking at this so quickly.

If I set the optimization to DEBUG_OPTIMIZATION, I see -O0
in CFLAGS, but I see -O2 in log.do_compile.  In Makefile, itself,
I see

CFLAGS = -W -Wall -Werror -Wundef -Wshadow -D_GNU_SOURCE -O2 -g $(DEFS)

and rather than patch that, I thought it would be easier to just override it.

I am using the acpid recipe from openembedded-core master branch.

Joe


From: Saul Wold [s...@linux.intel.com]
Sent: Thursday, February 14, 2013 12:24 PM
To: Slater, Joseph
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH] acpid: modify CFLAGS

On 02/14/2013 09:09 AM, Joe Slater wrote:
 Override the hard-coded CFLAGS used in Makefile
 to reference our CFLAGS.


Can you be clearer about this?

I just checked the output of the compile log and these flags are set
correctly. I also looked at the make -n output via a devshell.

This seems to be hardcoding the CFLAGS into this recipe.

Sounds like something else is going on.

Thanks
Sau!


 Upstream-Status:  Pending

 Signed-off-by: Joe Slater jsla...@windriver.com
 ---
   meta/recipes-bsp/acpid/acpid.inc |4 +++-
   1 files changed, 3 insertions(+), 1 deletions(-)

 diff --git a/meta/recipes-bsp/acpid/acpid.inc 
 b/meta/recipes-bsp/acpid/acpid.inc
 index 3c0219f..1ffe6ff 100644
 --- a/meta/recipes-bsp/acpid/acpid.inc
 +++ b/meta/recipes-bsp/acpid/acpid.inc
 @@ -13,7 +13,9 @@ inherit update-rc.d
   INITSCRIPT_NAME = acpid
   INITSCRIPT_PARAMS = defaults

 -EXTRA_OEMAKE = 
 +# Makefile ignores our CFLAGS, so override it.
 +#
 +EXTRA_OEMAKE = CFLAGS='-W -Wall -Werror -Wundef -Wshadow ${CFLAGS} $(DEFS)'

   do_compile () {
   oe_runmake 'CC=${CC} -D_GNU_SOURCE' 'CROSS=${HOST_PREFIX}'

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] cmake.bbclass: modify construction of compiler flags

[Slater, Joseph]

 -Original Message-
 From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
 Sent: Wednesday, September 26, 2012 1:48 AM
 To: Slater, Joseph
 Cc: openembedded-core@lists.openembedded.org
 Subject: Re: [OE-core] [PATCH] cmake.bbclass: modify construction of compiler 
 flags
 
 On Tue, 2012-09-25 at 14:37 -0700, Joe Slater wrote:
  Use CFLAGS instead of CPPFLAGS for C_FLAGS variants.
  Also remove duplicate flags from _RELEASE variants.
 
  Signed-off-by: Joe Slater jsla...@windriver.com
 
  *** Note - this can break things that have never really
  ***been compiled with -O2 optimization
 
 This change says what you're doing but not really why. How are things
 broken and why is this an improvement?

The specific problem is that, since CFLAGS are ignored, there is no difference
between debug (-O0) and production (-O2) builds.  It also seems 
counter-intuitive
that CXX_FLAGS are based on CXXFLAGS, but C_FLAGS are not based on CFLAGS.

Joe

 
 Cheers,
 
 Richard
 
  ---
   meta/classes/cmake.bbclass |6 +++---
   1 files changed, 3 insertions(+), 3 deletions(-)
 
  diff --git a/meta/classes/cmake.bbclass b/meta/classes/cmake.bbclass
  index dcd974a..ac5c048 100644
  --- a/meta/classes/cmake.bbclass
  +++ b/meta/classes/cmake.bbclass
  @@ -19,10 +19,10 @@ OECMAKE_C_COMPILER ?= `echo ${CC} | sed 's/^\([^ 
  ]*\).*/\1/'`
   OECMAKE_CXX_COMPILER ?= `echo ${CXX} | sed 's/^\([^ ]*\).*/\1/'`
 
   # Compiler flags
  -OECMAKE_C_FLAGS ?= ${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS} ${CPPFLAGS}
  +OECMAKE_C_FLAGS ?= ${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS} ${CFLAGS}
   OECMAKE_CXX_FLAGS ?= ${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS} ${CXXFLAGS} 
  -fpermissive
  -OECMAKE_C_FLAGS_RELEASE ?= ${SELECTED_OPTIMIZATION} ${CPPFLAGS} -DNDEBUG
  -OECMAKE_CXX_FLAGS_RELEASE ?= ${SELECTED_OPTIMIZATION} ${CXXFLAGS} 
  -DNDEBUG
  +OECMAKE_C_FLAGS_RELEASE ?= ${CFLAGS} -DNDEBUG
  +OECMAKE_CXX_FLAGS_RELEASE ?= ${CXXFLAGS} -DNDEBUG
 
   OECMAKE_RPATH ?= 
   OECMAKE_PERLNATIVE_DIR ??= 
 

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] can't login??

[Slater, Joseph]

I don't know your issue, but the attached recipe should work.  You could
try it and then starting ripping things out.

Joe


 -Original Message-
 From: openembedded-core-boun...@lists.openembedded.org 
 [mailto:openembedded-core-
 boun...@lists.openembedded.org] On Behalf Of Elvis Dowson
 Sent: Monday, August 20, 2012 8:43 AM
 To: Paul Eggleton
 Cc: openembedded-core@lists.openembedded.org
 Subject: Re: [OE-core] can't login??
 
 Hi,
 
 On Aug 20, 2012, at 2:34 PM, Paul Eggleton wrote:
 
 
   Is debug-tweaks in IMAGE_FEATURES?
 
 
 
 
 I too have the same problem, I've got debug-tweaks in IMAGE_FEATURES, but it 
 doesn't allow
 me to login.  If I type root as the username, it does nothing and brings up 
 the login
 prompt again.
 
 Starting syslogd/klogd:
 Yocto (Built by Poky 7.0) 1.2+snapshot-20120820 (none) ttyS0
 
 
 (none) login: root
 
 
 Yocto (Built by Poky 7.0) 1.2+snapshot-20120820 (none) ttyS0
 
 
 (none) login:
 Yocto (Built by Poky 7.0) 1.2+snapshot-20120820 (none) ttyS0
 
 
 (none) login:
 Yocto (Built by Poky 7.0) 1.2+snapshot-20120820 (none) ttyS0
 
 
 (none) login:
 
 
 Elvis Dowson


small.bb
Description: small.bb
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] Best way to determine is building for target?

[Slater, Joseph]

To change the installation for popt but not popt-native, I said

do_install_append_pn-popt {
  ...
}

which seems to work, but is there a better way, like some 
${@building_for_host(yes text,no text,d)}
construct?

Joe

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] opkg-nogpg

[Slater, Joseph]

It looks like opkg already uses --disable-gpg, so opkg-nogpg builds the same
and the packaging conflicts with opkg, so perhaps it could be eliminated?

Joe

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] EXCLUDE_FROM_WORLD

[Slater, Joseph]

Hi all,

Could somebody clarify excluding things from world?  I see EXCLUDE_FROM_WORLD = 
1 in
many places, including libx11.inc, and I'm sure there's plenty of libx11 stuff 
in world.

I also see package specific exclusions in world-broken.inc.

If one wants to exclude items for a particular bsp, would it be best to put 
exclusions
in a conf file for the bsp, or to put exclusions in another conf file in the 
form of

EXCLUDE_FROM_WORLD_pn-whatever_bsp-name = 1

Oh, and is it necessary to exclude things on a recipe-by-recipe basis?

Thanks,

Joe

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] EXCLUDE_FROM_WORLD

[Slater, Joseph]

 -Original Message-
 From: openembedded-core-boun...@lists.openembedded.org 
 [mailto:openembedded-core-
 boun...@lists.openembedded.org] On Behalf Of Richard Purdie
 Sent: Thursday, July 26, 2012 12:07 PM
 To: Patches and discussions about the oe-core layer
 Subject: Re: [OE-core] EXCLUDE_FROM_WORLD
 
 On Thu, 2012-07-26 at 18:45 +, Slater, Joseph wrote:
  Could somebody clarify excluding things from world?  I see
  EXCLUDE_FROM_WORLD = 1 in
 
  many places, including libx11.inc, and I'm sure there's plenty of
  libx11 stuff in world.
 
 The issue is that there are multiple providers of libx11 and when you
 bitbake world, we don't want them all to build. For that reason it gets
 excluded and then the correct version will get built as needed.
 
 There are plans afoot to merge those different libx11 recipes at which
 point the exclude from world will get dropped.
 
  I also see package specific exclusions in world-broken.inc.
 
 This was originally a list of known problematic packages and used to be
 quite large. Looking at the list:
 
 gobject-introspection: Totally broken recipe, I'm tempted to delete it.
 eds-tools: Again, I'm tempted to delete the recipe
 clutter-box2d: This should build, not sure why its on the broken list.

Thanks for the clarifications.  I would think that there would be packages
that you'd want to exclude conditionally.  Like i-only-build-for-x86.bb would
not be part of world for ppc builds.  Maybe such packages just cannot ever
be in world, or maybe we do something where EXCLUDE_FROM_WORLD gets computed
from, say, MACHINE_FEATURES?

Joe

 
 Chris replied about the other bits...
 
 Cheers,
 
 Richard
 
 
 
 ___
 Openembedded-core mailing list
 Openembedded-core@lists.openembedded.org
 http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [OE-core] modifying inittab (for example)

[Slater, Joseph]

 -Original Message-
 From: openembedded-core-boun...@lists.openembedded.org 
 [mailto:openembedded-core-
 boun...@lists.openembedded.org] On Behalf Of Martin Jansa
 Sent: Wednesday, July 18, 2012 10:26 PM
 To: Patches and discussions about the oe-core layer
 Subject: Re: [OE-core] modifying inittab (for example)
 
 On Wed, Jul 18, 2012 at 11:29:43PM +, Slater, Joseph wrote:
  Suppose we want to boot to different runlevels for different images.  We 
  could modify
 the default inittab
  to reflect that.  We could modify it in various ways, but I don't think the 
  exact
 mechanism much matters.
 
  What is an interesting question is WHEN we modify it.
 
  One way would be to  have a small piece of code and invoke it during image 
  creation
 using
  something like
 
  ROOTFS_POSTPROCESS_COMMAND += sato_image_pp ; 
 
  in our sato-image.bb recipe.  This doesn't require creating any new 
  features.
 
 This doesn't work very well for images with package management, when user
 upgrades installed packages, he can get new sysvinit-inittab which will
 reset runlevel in all types of images to same value.

In this particular case, I found there is a CONFFILES set in the recipe that 
prohibits
updating inittab when updating the package using package management (if you're 
lucky).

I have to admit that there are more of these variables lying around than a 
simple mind
would imagine.

Joe

 
  But, we could also do it when we build sysvinit-inittab.  I think, if we 
  did that, we
 would need a feature,
  probably a DISTRO_FEATURE, that was set in some conf file.
 
 This doesn't work too, if you have just one sysvinit-inittab recipe then
 it's used for all images - so again same runlevel in all.
 
  Is there a preference for one way or the other?
 
 You can create different inittab recipes for each runlevel you want and
 then make sure that only right inittab package is pulled to each image.
 
 Cheers,
 
 --
 Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[OE-core] modifying inittab (for example)

[Slater, Joseph]

Suppose we want to boot to different runlevels for different images.  We could 
modify the default inittab
to reflect that.  We could modify it in various ways, but I don't think the 
exact mechanism much matters.

What is an interesting question is WHEN we modify it.

One way would be to  have a small piece of code and invoke it during image 
creation using
something like

ROOTFS_POSTPROCESS_COMMAND += sato_image_pp ; 

in our sato-image.bb recipe.  This doesn't require creating any new features.

But, we could also do it when we build sysvinit-inittab.  I think, if we did 
that, we would need a feature,
probably a DISTRO_FEATURE, that was set in some conf file.

Is there a preference for one way or the other?

Joe Slater

___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core