Re: [OE-core] [PATCHv2 1/4] recipetool: create: disable PREMIRRORS and MIRRORS by default

[Chang, Rebecca Swee Fun]

Sure, no problem, rebase is in progress now.

Rebecca

From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Friday, July 21, 2017 9:50 PM
To: Chang, Rebecca Swee Fun 
Cc: OpenEmbedded Core Mailing List 
Subject: Re: [OE-core] [PATCHv2 1/4] recipetool: create: disable PREMIRRORS and 
MIRRORS by default

Sorry, we're conflicting again.  Too many people working on the same bit of 
code!  Can you rebase this onto origin/master-next?

Ross

On 20 July 2017 at 11:31, Chang Rebecca Swee Fun 
> 
wrote:
When creating new recipes, we are almost certainly fetching a new
source rather that something that has already been fetched. I have
disable PREMIRRORS and MIRRORS settings from datastore while leaving
an option for users to enable them manually if needed.

Signed-off-by: Chang Rebecca Swee Fun 
>
---
 scripts/lib/recipetool/create.py | 9 +
 1 file changed, 9 insertions(+)

diff --git a/scripts/lib/recipetool/create.py b/scripts/lib/recipetool/create.py
index 8e63580..1015d02 100644
--- a/scripts/lib/recipetool/create.py
+++ b/scripts/lib/recipetool/create.py
@@ -422,6 +422,7 @@ def create_recipe(args):
 source = args.source
 srcsubdir = ''
 srcrev = '${AUTOREV}'
+mirrors = args.mirrors

 if os.path.isfile(source):
 source = 'file://%s' % os.path.abspath(source)
@@ -442,6 +443,13 @@ def create_recipe(args):
 tempsrc = tempfile.mkdtemp(prefix='recipetool-')
 srctree = tempsrc
 d = bb.data.createCopy(tinfoil.config_data)
+if not mirrors:
+# We do not need PREMIRRORS since we are almost certainly
+# fetching new source rather than something that has already
+# been fetched. Hence, we disable them by default.
+# However, we provide an option for users to enable it.
+d.setVar('PREMIRRORS', '')
+d.setVar('MIRRORS', '')
 if fetchuri.startswith('npm://'):
 # Check if npm is available
 npm_bindir = check_npm(tinfoil, args.devtool)
@@ -1180,6 +1188,7 @@ def register_commands(subparsers):
 parser_create.add_argument('--keep-temp', action="store_true", help='Keep 
temporary directory (for debugging)')
 parser_create.add_argument('--fetch-dev', action="store_true", help='For 
npm, also fetch devDependencies')
 parser_create.add_argument('--devtool', action="store_true", 
help=argparse.SUPPRESS)
+parser_create.add_argument('--mirrors', action="store_true", help='Enable 
PREMIRRORS and MIRRORS for source tree fetching (disable by default).')
 # FIXME I really hate having to set parserecipes for this, but given we 
may need
 # to call into npm (and we don't know in advance if we will or not) and in 
order
 # to do so we need to know npm's recipe sysroot path, there's not much 
alternative
--
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

[OE-core] Update meta-qt5 to v5.9.1

[Yevhen Kyriukha]

Qt 5.
​9.1​
has been released. Please update meta-qt5 accordingly.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/1] expat: upgrade to 2.2.2

[Khem Raj]

On Sat, Jul 22, 2017 at 2:24 AM, Burton, Ross  wrote:
>
> On 18 July 2017 at 07:01, Dengke Du  wrote:
>>
>> using getrandom syscall on linux 3.17+, so when we compiling
>> expat-native
>> on the kernel older than 3.17, that would be failed.
>
>
> It's failing on Debian 8, which is kernel 4.9.0:
>
> | ../expat-2.2.2/lib/xmlparse.c:56:3: error: #error You do not have support
> for any sources of high quality entropy enabled. For end user security, that
> is probably not what you want. Your options include: * Linux + glibc >=2.25
> (getrandom): HAVE_GETRANDOM, * Linux + glibc <2.25 (syscall SYS_getrandom):
> HAVE_SYSCALL_GETRANDOM, * BSD / macOS (arc4random_buf): HAVE_ARC4RANDOM_BUF,
> * libbsd (arc4random_buf): HAVE_ARC4RANDOM_BUF + HAVE_LIBBSD, * Windows
> (RtlGenRandom): _WIN32. If insist on not using any of these, bypass this
> error by defining XML_POOR_ENTROPY; you have been warned. For CMake, one way
> to pass the define is: cmake -DCMAKE_C_FLAGS="-pipe -O2
> -DHAVE_SYSCALL_GETRANDOM" . If you have reasons to patch this detection code
> away or need changes to the build system, please open a bug. Thank you!
>
> (https://autobuilder.yocto.io/builders/nightly-ppc/builds/379/steps/BuildImages/logs/stdio)
>
> I suspect the detection code is well and truly broken.
>

I posted another patch doing this upgrade. I wonder if it has same
issue. it works on my 3.12 kernel based host.

> Ross
>
> --
> ___
> 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] [PATCH V2] tclibc-musl.inc: fix bfd "cannot make copy relocation for protected symbol" issues

[liu . ming50]

From: Ming Liu 

Quite a few such compiling issues were found when I was building with
following configs:
...
MACHINE = "beaglebone"
TCLIBC = "musl"
DISTRO_FEATURES_append = " ld-is-gold"
...

fixed by adding bfd binding now ldflags.

Signed-off-by: Ming Liu 
---
 meta/conf/distro/include/tclibc-musl.inc | 4 
 1 file changed, 4 insertions(+)

diff --git a/meta/conf/distro/include/tclibc-musl.inc 
b/meta/conf/distro/include/tclibc-musl.inc
index 3d3f6ac..99d52a1 100644
--- a/meta/conf/distro/include/tclibc-musl.inc
+++ b/meta/conf/distro/include/tclibc-musl.inc
@@ -18,6 +18,10 @@ PREFERRED_PROVIDER_virtual/nativesdk-libiconv ?= 
"nativesdk-glibc"
 
 CXXFLAGS += "-fvisibility-inlines-hidden"
 
+# Workaround for musl libc does not support bfd lazy binding well
+# Refer to: https://bugzilla.yoctoproject.org/show_bug.cgi?id=11679
+LDFLAGS += "${@bb.utils.contains('DISTRO_FEATURES', 'ld-is-gold', 
'-Wl,-z,relro,-z,now -fuse-ld=bfd', '', d)}"
+
 IMAGE_LINGUAS = ""
 
 LIBC_DEPENDENCIES = "\
-- 
2.7.4

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

Re: [OE-core] [PATCH 1/2] image-vm: Convert vmdk/vdi/qcow2/hdddirect images to IMAGE_CMD

[Patrick Ohly]

On Fri, 2017-07-21 at 16:52 -0400, Tom Rini wrote:
> On Fri, Jul 21, 2017 at 03:01:33PM +0200, Patrick Ohly wrote:
> > On Fri, 2017-07-21 at 07:21 -0400, Tom Rini wrote:
> > > On Fri, Jul 21, 2017 at 09:47:21AM +0200, Patrick Ohly wrote:
> > > > On Thu, 2017-07-20 at 18:43 -0400, Tom Rini wrote:
> > > > > The support for writing vmdk/vdi/qcow2 images has not been converted 
> > > > > to make
> > > > > use of the IMAGE_CMD infrastructure and instead relies on custom 
> > > > > logic for
> > > > > adding tasks in the right place.  Convert these images to making use 
> > > > > of
> > > > > IMAGE_CMD.
> > > > 
> > > > Thanks for working on this. I still have
> > > > https://bugzilla.yoctoproject.org/show_bug.cgi?id=10204 open for
> > > > enhancing vmdk/vdi/qcow2.
> > > > 
> > > > However, your patch doesn't go as far as described in that bug, does it?
> > > > Instead of allowing, for example, IMAGE_FSTYPES = "wic.vmdk", it merely
> > > > changes how IMAGE_FSTYPES = "vmdk" is implemented.
> > > > 
> > > > The current patch has its merits as it simplifies the implementation,
> > > > but I think it would be worthwhile to go all the way, even if it changes
> > > > how images are going to be named.
> > > 
> > > Ah, interesting.  I guess the first thing I would argue against is
> > > saying that hdddirect should be masked.  There are reasons to want to
> > > have a raw image created.
> > 
> > I'm not sure I understand what you mean with "hdddirect should be
> > masked" - it's been a while that I looked at the code.
> > 
> > > I will take a look into using CONVERSIONCMD for vmdk/qcow2/vdi to allow
> > > for wic.vmdk to work.  But we also must have vmdk.xz work (and fwiw with
> > > my series you can get arbitrary compression that we support done, I did
> > > vmdk.xz, qcow2.lzo and vdi.bz2 just for 'fun').
> > 
> > The same is true with CONVERSIONCMD. They can be chained multiple times.
> > 
> > > But I'm not 100% sure that I like changing the normal case from "vmdk"
> > > to "wic.vmdk" or "hdddirect.vmdk" just to get a disk image to throw at
> > > ${VM_TECHNOLOGY}.
> > 
> > Yes, that's the biggest user-visible change. Basically the internal
> > implementation (multiple conversions chained together) becomes visible
> > in the end-result.
> > 
> > That is a good and a bad thing. The good thing is that it is visible how
> > the .vmdk image was created. The bad thing is that some users might not
> > care and get confused.
> 
> So, Patrick, Ed and I talked on IRC a bit about this, and I think
> without putting too many words in their mouths, I think it can be
> summarized like this.
>
> We all agree that vmdk/qcow2/vdi are a type of conversion.  It would be
> quite handy to use these conversions on other things, such as wic.
> 
> And at least from my point of view, the contents of "hdddirect" doesn't
> matter so much as the overall functionality.
> 
> So that here's where I'm at now.  I've found out when Patrick's chaining
> compression code (so that you could do silly things like ext3.gz.bz2 or
> _useful_ things like wic.vmdk.xz) was broken, and I see the best way to
> fix that too.  So I'm going to v2 this series shortly which addresses
> the problem of chaining compression types, and then brings the VM stuff
> over to using that too.

Thanks for the good summary and working on this functionality.

I'd like to add that you pointed out that a "generic" vmdk type is what
some developers ask for when they don't care about the exact way how the
resulting image is created (hdddirect vs. wic, for example). We agreed
that this is useful.

I didn't get around to mentioning it on IRC, but what I would find it
useful is if someone (BSP and/or distro?) can define which kind of raw
image is used as input for the conversion to vmdk. Hard-coding that to
just hdddirect always felt wrong to me.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.



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

Re: [OE-core] [PATCH 1/1] expat: upgrade to 2.2.2

[Burton, Ross]

On 18 July 2017 at 07:01, Dengke Du  wrote:

> using getrandom syscall on linux 3.17+, so when we compiling expat
> -native
> on the kernel older than 3.17, that would be failed.
>

It's failing on Debian 8, which is kernel 4.9.0:

| ../expat-2.2.2/lib/xmlparse.c:56:3: error: #error You do not have support
for any sources of high quality entropy enabled. For end user security,
that is probably not what you want. Your options include: * Linux + glibc
>=2.25 (getrandom): HAVE_GETRANDOM, * Linux + glibc <2.25 (syscall
SYS_getrandom): HAVE_SYSCALL_GETRANDOM, * BSD / macOS (arc4random_buf):
HAVE_ARC4RANDOM_BUF, * libbsd (arc4random_buf): HAVE_ARC4RANDOM_BUF +
HAVE_LIBBSD, * Windows (RtlGenRandom): _WIN32. If insist on not using any
of these, bypass this error by defining XML_POOR_ENTROPY; you have been
warned. For CMake, one way to pass the define is: cmake
-DCMAKE_C_FLAGS="-pipe -O2 -DHAVE_SYSCALL_GETRANDOM" . If you have reasons
to patch this detection code away or need changes to the build system,
please open a bug. Thank you!

(
https://autobuilder.yocto.io/builders/nightly-ppc/builds/379/steps/BuildImages/logs/stdio
)

I suspect the detection code is well and truly broken.

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

Re: [OE-core] [PATCH 1/2] openssl: Support musl-x32 build

[Richard Purdie]

On Wed, 2017-07-19 at 13:29 -0700, swee.aun.k...@intel.com wrote:
> From: sweeaun 
> 
> Support musl-x32 build which to build openssl with 32 bits.
> 
> Signed-off-by: sweeaun 
> ---
>  meta/recipes-connectivity/openssl/openssl.inc | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/recipes-connectivity/openssl/openssl.inc
> b/meta/recipes-connectivity/openssl/openssl.inc
> index ce295e8..a56bd6e 100644
> --- a/meta/recipes-connectivity/openssl/openssl.inc
> +++ b/meta/recipes-connectivity/openssl/openssl.inc
> @@ -66,7 +66,8 @@ do_configure () {
>   case $os in
>   linux-gnueabi |\
>   linux-gnuspe |\
> - linux-musl*)
> + linux-musleabi |\
> + linux-muslspe)
>   os=linux
>   ;;
>   *)

I think there is a bug here if os=linux-musl which likely caused:

https://autobuilder.yocto.io/builders/nightly-musl/builds/364

Cheers,

Richard

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