Re: [yocto] How to request a certain version of a recipes for an image?

[Andre McCurdy]

On Sun, Nov 4, 2018 at 2:30 PM Patrick Boettcher
 wrote:
>
> Hi list,
>
> I'm using the morty-release for my device.
>
> My sources consists of different layers. Some application
> specific-layers (which contains a image-recipe), our
> BSP-provider and tooling-layers.
>
> It now happens that in there is package (dt-utils) which has recipes in
> two different layers, with different versions.
>
> In my image-file I request the package via
>
> IMAGE_INSTALL += "dt-utils"
>
> How do I force the version of dt-utils for this image? By default it
> selects the wrong one.
>
> Here's what I tried, by adding to the image-recipe:
>
> DEPENDS += "dt-utils (>= 2017.03.0)"
>
> and
>
> RDEPENDS += "dt-utils (>= 2017.03.0)"
>
> seems to have no effect. Adding the version-logic to the
> IMAGE_INSTALL-line fails to build.
>
> What works is to add PREFERRED_VERSION to local.conf. But this is not
> committable, so I'd like to avoid it.

You can't directly influence the build of one recipe (ie dt-utils) by
making a change in another recipe (ie the image recipe), so the
DEPENDS and RDEPENDS style changes you have tried will not work.
Variables in the image recipe are not visible when the dt-utils recipe
is built.

Setting PREFERRED_VERSION from a global config file is a valid
solution. In that case it's up to you to decide which global config to
use - adding to local.conf, the machine config, the distro config, a
meta layer config file will all work. Using either the distro or
machine config would be the most typical approach - depending on
whether you want to version preference to apply to one build
configuration (ie one machine) or to all your builds (ie your distro).

An alternative solution would to be to change the priority of the
recipes in the meta layer(s) which contains the dt-utils recipes. e.g.
increasing BBFILE_PRIORITY_xxx in the layer.conf in the meta layer
with the dt-utils recipe you want to use.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] busybox build failure

[Andre McCurdy]

On Tue, Oct 30, 2018 at 5:49 AM Matthew Singer  wrote:
>
> I turned on syslog in busybox via its menu config and the build now fails 
> with the following error

The correct way to turn on syslog in busybox is to ensure that
"file://syslog.cfg" is included in SRC_URI.

However, it looks like it's included by default so in your case you
may need to find and disable a custom local .bbappend etc which is
removing it?

In general, if a busybox config fragment exists for a particular
feature then it should be used (added or removed from SRC_URI) to
enable or disable that feature. Manually editing the busybox config
should be reserved for features which don't have their own config
fragment.

> ERROR: busybox-1.24.1-r0 do_package: QA Issue: busybox: Files/directories 
> were installed but not shipped in any package:
>   /lib
>   /lib/systemd
>   /lib/systemd/system
>   /lib/systemd/system/busybox-syslog.service
> Please set FILES such that these items are packaged. Alternatively if they 
> are unneeded, avoid installing them or delete them within do_install.
> busybox: 4 installed and not shipped files. [installed-vs-shipped]
> ERROR: busybox-1.24.1-r0 do_package: Fatal QA errors found, failing task.
> ERROR: busybox-1.24.1-r0 do_package: Function failed: do_package
> ERROR: Logfile of failure stored in: 
> /home/keyw/projects/phytec/yocto/build/tmp/work/cortexa9hf-neon-phytec-linux-gnueabi/busybox/1.24.1-r0/temp/log.do_package.15516
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Busybox_1.23.2 fails at do_compile on Poky-Sumo

[Andre McCurdy]

On Tue, Oct 23, 2018 at 2:58 AM, Dhanush K.S  wrote:
> Hello Yocto,
>
> I'm currently building an image with the busybox_1.23.2.bb recipe included,
> using Yocto Sumo 2.5 with the Bitbake version 1.37.0. It is running on a
> CentOS host building images for the target ARM cortexa8. This busybox recipe
> is placed in another custom layer. Though this recipe compiles without
> errors in Poky-Fido, in Poky-Sumo I get compilation errors due to missing
> header files. Please take a look at the link below for the log.do_compile
> output.
>
> https://pastebin.com/yYXJnC2e

From the log of the failing command, the cross compiler is being
called without a --sysroot option, which usually means the CC value
set by the build environment is being ignored or over-ridden.

I guess your custom busybox recipe is missing the following update:

  
http://git.openembedded.org/openembedded-core/commit/?id=b7c265e1edd5c82126c1f3915ba5ca9efef57c00

Which is required in order to work correctly with versions of OE
containing the following change:

  
http://git.openembedded.org/openembedded-core/commit/?id=aeb653861a0ec39ea7a014c0622980edcbf653fa

> Both limits.h and byteswap.h don't exist in Poky-Fido as well, but compiles
> without problems, unlike on Sumo. Does this have to do with the wrong
> Toolchains used or due to glibc (FYI: glibc_2.27 is been used)? If it has to
> do with the Toolchains, which one should I be using and how do I go about
> it? Could someone please point me in the right direction?

Generally you should not expect a third party layer originally created
for fido to "just work" with sumo.

Perhaps ask whoever maintains your custom layers and recipes whether
they have a version which has been tested with sumo.

> Here is the Build Config:
>
> Build Configuration:
> BB_VERSION   = "1.37.0"
> BUILD_SYS= "x86_64-linux"
> NATIVELSBSTRING  = "universal-4.8"
> TARGET_SYS   = "arm-poky-linux-gnueabi"
> MACHINE  = "arm-cortex-a8"
> DISTRO   = "poky"
> DISTRO_VERSION   = "2.5"
> TUNE_FEATURES= "arm armv7a vfp neon callconvention-hard cortexa8"
> TARGET_FPU   = "hard"
> meta-networking
> meta-python  = "master:45ee3c0e98bd3ed81419aaeae1e7324e486161a2"
> meta-userbsp-ti
> meta
> meta-poky
> meta-yocto-bsp
> meta-user-common  = ":"
> meta-oe  = "master:45ee3c0e98bd3ed81419aaeae1e7324e486161a2"
> workspace= ":"
>
> Thanks in advance!
> Regards,
> Mit freundlichen Grüßen / Best Regards,
> Dhanush
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] SUSE SLES target OS

[Andre McCurdy]

On Fri, Oct 19, 2018 at 2:17 PM, Joe Flowers  wrote:
> Hello everyone,
>
> I need to get started on a Yocto set that will build a minimal core for a
> target OS of SUSE Linux Enterprise Server on x64 target hardware like a
> MinnowBoard.

The Yocto project supports building distros based on OpenEmbedded. You
can't use Yocto to build SUSE.

(You can use Yocto to build an OpenEmbedded based distro on a SUSE
host... but if I understand correctly, that's not what you're asking,
right?).

> I have scoured the web, SUSE, and this list's (Yocto Project) archives, but
> have run into no pointers.  My guess is that it is right under my nose that
> can be seen with more experience rather than being hidden behind private
> walls.
>
> Will someone please get me started on the pointers and downloads I need to
> get started?
>
> I have already run through a tutorial on creating a core OS using Yocto for
> a WandBoard target hardware.
>
>
> Thank you !
>
> Joe
> --
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Bitbake Build Configurations

[Andre McCurdy]

On Wed, Oct 17, 2018 at 5:12 AM, Dhanush K.S  wrote:
> Hi Yocto,
>
> I have my bitbake environment set up on the host system CentOS 7 and
> building images for the target ARM cortex A8 with the following BUILD
> CONFIGURATION,
>
> Build Configuration:
> BB_VERSION   = "1.37.0"
> BUILD_SYS= "x86_64-linux"
> NATIVELSBSTRING  = "universal-4.8"
> TARGET_SYS   = "arm-poky-linux-gnueabi"
> MACHINE  = "arm-cortex-a8"
> DISTRO   = "poky"
> DISTRO_VERSION   = "2.5"
> TUNE_FEATURES= "arm armv7a vfp neon callconvention-hard cortexa8"
> TARGET_FPU   = "hard"
> meta-networking
> meta-python  = "master:45ee3c0e98bd3ed81419aaeae1e7324e486161a2"
> meta-userbsp-ti
> meta
> meta-poky
> meta-yocto-bsp
> meta-user-common  = ":"
> meta-oe  = "master:45ee3c0e98bd3ed81419aaeae1e7324e486161a2"
>
> What I don't understand is how exactly are these Variables set?
> For the NATIVELSBSTRING which should actually be displaying the HOST OS
> according to the Yocto Manual, isn't doing that. What could be the reason
> for that? (Earlier, with Poky Fido, this wasn't the case. It displays
> "CentOS-Linux-7.1.1503".)

The documentation for NATIVELSBSTRING perhaps hasn't caught up with
recent changes in it's definition and usage. If you see "universal" it
means native recipes are being compiled against a version of glibc
distributed by the Yocto project rather than the version of glibc
provided by your host distro. It's the default approach in recent
versions of poky and has the advantage that native recipes are always
built against a known and up to date version of glibc. It also allows
sstate for native recipes to be shared between hosts with different
versions of glibc (which wasn't previously possible).

> Also how is the TARGET_FPU variable set?

The answer to the question "how is variable XXX set" is always the
same... "bitbake -e" will tell you :-)

The reason this variable changed compared to older versions of poky is
likely to be that your machine config uses the default value of
DEFAULTTUNE set by tune-cortexa8.inc. That's the recommended approach,
but it does mean your builds will follow any change in the default
value. ie you are seeing the result of:

  
http://git.openembedded.org/openembedded-core/commit/?id=2b3ae58f5eaecc8474761c543ff5347aa0e3c4c8

If you don't like the new default and need to compile for softfloat
then your machine config should explicitly set DEFAULTTUNE.

> Could someone please shed some light on this.
>
> Thanks!
>
> Mit freundlichen Grüßen / Best Regards,
> Dhanush Keshava Reddy Soppahalli
> Mob: +4915216144064
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [Yocto][poky][meta] already-stripped ignore if set for any other package then INSANE_SKIP_${PN}

[Andre McCurdy]

On Tue, Oct 16, 2018 at 6:47 AM, Burton, Ross  wrote:
> It's only already-stripped that needs to be on PN, because the
> stripping happens before packaging.  When already-stripped files,
> there are no packages yet.
>
> Ross
> On Tue, 16 Oct 2018 at 14:22, Måns Zigher  wrote:
>>
>> Ok so it is not supported to have the already-stripped on a package level? I 
>> cannot set it on PN because I have some so-files that is already stripped 
>> and others that is not so that was why I wanted to create a package for the 
>> already-stripped so-files and use the already-stripped on that package. 
>> Anyway thanks for the help I ended up creating a new recipe for the 
>> already-stripped so-files. But is all the INSANE_SKIP flags only supported 
>> for PN? I think I have seen dev-so used on an package level?

The key point is when the QA test is run. In the case of
"already-stripped", the test is run as part of split_and_strip_files()
in package.bbclass, ie as part of the normal stripping process. As
Ross mentions, it's therefore run before the build output is split
into packages.

The "dev-so" QA test is run as part of do_package_qa() in
insane.bbclass and can be disabled on a per-package basis.

As far as I know, there's no documentation to say which QA tests can
be disabled on a per-package basis and which can not. If you want to
be sure you need to read the source. Start by grepping for the QA test
you are interested in and also for "package_qa_handle_error" (which is
the function which is called when a QA test fails). Those two together
should help locate the place where the QA test is run... and from that
you can inspect the code to see if/how INSANE_SKIP is applied. For
example, in the case of "already-stripped", the test is run from
split_and_strip_files() and only INSANE_SKIP_${PN} is checked:

  
http://git.openembedded.org/openembedded-core/tree/meta/classes/package.bbclass?h=sumo#n1010

(In this case, the code could perhaps be even clearer if checking
whether "already-stripped" is found in INSANE_SKIP_${PN} was done once
at the start of the function, rather than being determining again and
again for each file inside the "for every elf file" loop).

>> BR
>> Måns Zigher
>>
>> Den mån 15 okt. 2018 kl 22:23 skrev Burton, Ross :
>>>
>>> Ah yes, of course.  Stripping happens *before* package splitting, so
>>> it doesn't make sense to have it set on PN-package1.  Just set it on
>>> PN and it should work.
>>>
>>> Ross
>>> On Mon, 15 Oct 2018 at 08:18, Måns Zigher  wrote:
>>> >
>>> > Hi,
>>> >
>>> > Sorry I see now that there is a typo. What I mean is that in the default 
>>> > package I am not suing INSANE_SKIP but for packag1 I need already-stripped
>>> >
>>> > INSANE_SKIP_${PN}-package1 = " \
>>> > dev-so \
>>> > already-stripped \
>>> > "
>>> >
>>> > But I continuously get the error that they are already-stripped. So is it 
>>> > supposed to work because I don't understand  the code in the 
>>> > package.bbclass since it looks like it is only checking for 
>>> > already-stripped in ${PN} and not ${PN}-package1?
>>> >
>>> > BR
>>> > Måns Zigher
>>> >
>>> >
>>> >
>>> > Den fre 12 okt. 2018 kl 16:30 skrev Burton, Ross :
>>> >>
>>> >> On Thu, 11 Oct 2018 at 18:14, Måns Zigher  wrote:
>>> >> > I have been struggling with a problem where I need to create a package 
>>> >> > in a recipe and set already-stripped for that package. The package in 
>>> >> > question is not the the default one so I am trying to set it by using
>>> >> >
>>> >> > INSANE_SKIP_${PN} += " \
>>> >> > dev-so \
>>> >> > already-stripped \
>>> >> > "
>>> >>
>>> >> You say no the default one, but PN is "the default" one, so that's
>>> >> probably why that doesn't work.
>>> >>
>>> >> Ross
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-gplv2] gnutls: use https mirror for SRC_URI instead of ftp

[Andre McCurdy]

On Wed, Oct 3, 2018 at 9:16 AM, Oleksandr Kravchuk
 wrote:
> Signed-off-by: Oleksandr Kravchuk 
> ---
>  recipes-support/gnutls/gnutls.inc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/recipes-support/gnutls/gnutls.inc 
> b/recipes-support/gnutls/gnutls.inc
> index 4cf375f..0e2c0b7 100644
> --- a/recipes-support/gnutls/gnutls.inc
> +++ b/recipes-support/gnutls/gnutls.inc
> @@ -16,7 +16,7 @@ DEPENDS_append_libc-musl = " argp-standalone"
>
>  SHRT_VER = 
> "${@d.getVar('PV').split('.')[0]}.${@d.getVar('PV').split('.')[1]}"
>
> -SRC_URI = 
> "ftp://ftp.gnutls.org/gcrypt/gnutls/v${SHRT_VER}/gnutls-${PV}.tar.xz;
> +SRC_URI = 
> "https://www.gnupg.org/ftp/gcrypt/gnutls/vv${SHRT_VER}/gnutls-${PV}.tar.xz;

Is the double v really required?

>  inherit autotools texinfo binconfig pkgconfig gettext lib_package gtk-doc
>
> --
> 2.17.1
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] inheriting native.bbclass explicitly

[Andre McCurdy]

On Fri, Sep 14, 2018 at 1:20 AM, Dudziak Krzysztof
 wrote:
> Thanks for feedback from you.
>
>> If you use BBCLASSEXTEND (ie "the second method") then that recipe naming 
>> rule doesn't apply.
> Looks like section's 6.83 current structure wouldn't reflect this fact well. 
> Warning is placed directly below
> one-sentence and indented text describing to BBCLASSEXTEND-case

Yes, I agree. That part of the documentation could certainly be improved.

> krzysiek
>
> -----Original Message-
> From: Andre McCurdy [mailto:armccu...@gmail.com]
> Sent: Friday, 14. September 2018 01:05
> To: Dudziak Krzysztof 
> Cc: Burton, Ross ; yocto@yoctoproject.org
> Subject: Re: [yocto] inheriting native.bbclass explicitly
>
> On Thu, Sep 13, 2018 at 6:05 AM, Dudziak Krzysztof 
>  wrote:
>> Current release's reference manual issues in native.bbclass chapter a 
>> warning:
>> "When creating a recipe, you must follow this naming convention:  
>> native-myrecipe.bb
>> Not doing so can lead to subtle problems because code exists that depends on 
>> the naming convention."
>
> Looks like a mistake in the documentation. Native only recipes (ie recipes 
> which use "inherit native" rather than BBCLASSEXTEND) should have "-native" 
> as a suffix, not "native-" as a prefix.
>
>> Jethro release manual does not point it out.
>> Is this warning really out of relevance for certain past releases e.g. 
>> Jethro?
>>
>> Abstracting from question raised above how following two fit all together:
>> "When creating a recipe, you must follow this naming convention:  
>> native-myrecipe.bb"
>> and
>> " The advantage of the second method is that you do not need to have
>> two separate recipes " (2.5.1 Release Reference Manual)
>
> If you use BBCLASSEXTEND (ie "the second method") then that recipe naming 
> rule doesn't apply. ie a recipe using BBCLASSEXTEND should not have a 
> "-native" suffix.
>
>> krzysiek
>>
>> -Original Message-
>> From: Burton, Ross [mailto:ross.bur...@intel.com]
>> Sent: Thursday, 13. September 2018 14:00
>> To: Dudziak Krzysztof 
>> Cc: yocto@yoctoproject.org
>> Subject: Re: [yocto] inheriting native.bbclass explicitly
>>
>> On 13 September 2018 at 12:39, Dudziak Krzysztof
>>  wrote:
>>> Thanks for hints.
>>> I don't want to have this package on target system.
>>> You sound like inheriting explicitly had some major drawback of wide scope.
>>
>> It won't be included in the image unless you add it to the image.
>>
>> Ross
>> 
>>  This message and any attachments are intended solely for the addressees and 
>> may contain confidential information. Any unauthorized use or disclosure, 
>> either whole or partial, is prohibited.
>> E-mails are susceptible to alteration. Our company shall not be liable for 
>> the message if altered, changed or falsified. If you are not the intended 
>> recipient of this message, please delete it and notify the sender.
>> Although all reasonable efforts have been made to keep this transmission 
>> free from viruses, the sender will not be liable for damages caused by a 
>> transmitted virus.
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flis
>> ts.yoctoproject.org%2Flistinfo%2Fyoctodata=02%7C01%7CKrzysztof.Du
>> dziak%40gemalto.com%7Ced60588df01e4484015c08d619cd5ee6%7C37d0a9db7c464
>> 096bfe31add5b495d6d%7C1%7C0%7C636724767194372674sdata=8GXUXT5abR3
>> BHWxhzbCf0bbYxYqpU7x6r0ZXbQt7clw%3Dreserved=0
> 
>  This message and any attachments are intended solely for the addressees and 
> may contain confidential information. Any unauthorized use or disclosure, 
> either whole or partial, is prohibited.
> E-mails are susceptible to alteration. Our company shall not be liable for 
> the message if altered, changed or falsified. If you are not the intended 
> recipient of this message, please delete it and notify the sender.
> Although all reasonable efforts have been made to keep this transmission free 
> from viruses, the sender will not be liable for damages caused by a 
> transmitted virus.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] inheriting native.bbclass explicitly

[Andre McCurdy]

On Thu, Sep 13, 2018 at 6:05 AM, Dudziak Krzysztof
 wrote:
> Current release's reference manual issues in native.bbclass chapter a warning:
> "When creating a recipe, you must follow this naming convention:  
> native-myrecipe.bb
> Not doing so can lead to subtle problems because code exists that depends on 
> the naming convention."

Looks like a mistake in the documentation. Native only recipes (ie
recipes which use "inherit native" rather than BBCLASSEXTEND) should
have "-native" as a suffix, not "native-" as a prefix.

> Jethro release manual does not point it out.
> Is this warning really out of relevance for certain past releases e.g. Jethro?
>
> Abstracting from question raised above how following two fit all together:
> "When creating a recipe, you must follow this naming convention:  
> native-myrecipe.bb"
> and
> " The advantage of the second method is that you do not need to have two 
> separate recipes " (2.5.1 Release Reference Manual)

If you use BBCLASSEXTEND (ie "the second method") then that recipe
naming rule doesn't apply. ie a recipe using BBCLASSEXTEND should not
have a "-native" suffix.

> krzysiek
>
> -Original Message-
> From: Burton, Ross [mailto:ross.bur...@intel.com]
> Sent: Thursday, 13. September 2018 14:00
> To: Dudziak Krzysztof 
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] inheriting native.bbclass explicitly
>
> On 13 September 2018 at 12:39, Dudziak Krzysztof
>  wrote:
>> Thanks for hints.
>> I don't want to have this package on target system.
>> You sound like inheriting explicitly had some major drawback of wide scope.
>
> It won't be included in the image unless you add it to the image.
>
> Ross
> 
>  This message and any attachments are intended solely for the addressees and 
> may contain confidential information. Any unauthorized use or disclosure, 
> either whole or partial, is prohibited.
> E-mails are susceptible to alteration. Our company shall not be liable for 
> the message if altered, changed or falsified. If you are not the intended 
> recipient of this message, please delete it and notify the sender.
> Although all reasonable efforts have been made to keep this transmission free 
> from viruses, the sender will not be liable for damages caused by a 
> transmitted virus.
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Whitelist gdbserver

[Andre McCurdy]

On Thu, Sep 13, 2018 at 8:42 AM, Jeremy Overesch
 wrote:
> HI all,
>
> I’m attempting to whitelist gdbserver just for SDK purposes, while keeping
> all other GPLv3 code as incompatible (therefore unbuilt).  However,
> everything I’ve tried still results in gdbserver being removed from my SDK
> and therefore failing to build.
>
> In my local.conf, I have the following line:
>
> INCOMPATIBLE_LICENSE = "GPLv3 LGPLv3 AGPLv3"
>
> Through the yocto documentation
> (https://www.yoctoproject.org/docs/2.4/mega-manual/mega-manual.html#license-flag-matching),
> it appears that adding the following *should* work, yet it doesn’t:

I think you are mixing up "LICENSE" and "LICENSE_FLAGS". The two don't
really work together. It's partly explained in:

  
https://www.yoctoproject.org/docs/2.4/mega-manual/mega-manual.html#var-LICENSE_FLAGS

See the LICENSE_FLAGS comment which says "This value is independent of
LICENSE and is typically used to mark recipes that might require
additional licenses in order to be used in a commercial product. For
more information, see the "Enabling Commercially Licensed Recipes"
section."

To whitelist a recipe which is being excluded due to
INCOMPATIBLE_LICENSE, use WHITELIST_GPL-3.0. For example for
gdbserver, try the following:

  WHITELIST_GPL-3.0 += "gdbserver"
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] curl package config

[Andre McCurdy]

On Thu, Sep 6, 2018 at 12:10 PM, Erik Botö  wrote:
> Hi,
>
> On Thu, Sep 6, 2018 at 8:01 PM Antonio Santagiuliana
>  wrote:
>>
>> Hello
>> I am trying to enable the SMB protocol when building curl library by Yocto
>> the original recipe is under meta/recipes-support/curl
>>
>> in my image's local.conf I have
>> IMAGE_INSTALL_append += "curl-dev"
>>
>> curl is built correctly, but SMB is disabled
>>
>> So I tried to add a .bbappend file with same name as the recipe's name,
>> with this line only :
>> PACKAGECONFIG = "--enable-smb"

This is just the wrong syntax. PACKAGECONFIG is not a list of
configure options. It's a list of "features" to enable, which are then
translated into appropriate configure options (and dependencies) based
on rules defined in the recipe. Maybe look through some existing
recipes in oe-core to get some idea of how the process works.

>> but I still have SMB disaabled on curl.
>>
>> Which is the right way to enable it with PACKAGECONFIG?
>> or another way ?
>
>
> You just want to add "smb" to the variable PACKAGECONFIG in the bbappend.
> But since the original recipe uses ??= to assign the default PACKAGECONFIG
> value you probably want to either redefine the whole variable as the
> original recipe, but adding "smb"
> PACKAGECONFIG = "${@bb.utils.filter('DISTRO_FEATURES', 'ipv6', d)} gnutls
> libidn proxy threaded-resolver verbose zlib smb"
>
> I think it could work if you use _append as well, since I think that's added
> after the ??= operator is evaluated. So you can also try (note the space
> before smb):
> PACKAGECONFIG_append = " smb"

Using _append like this to add values to PACKAGECONFIG is the
recommended way (ie don't try to use +=) for the reasons mentioned.

Redefining the entire variable isn't necessary or recommended (it
requires more maintenance to keep the .bbappend value in sync with any
changes in the base recipe).
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Cleaning out build without re-downloading sources

[Andre McCurdy]

On Tue, Aug 21, 2018 at 3:52 PM, Paul Sheer  wrote:
> Hi,
>
> I am trying to do a clean out all packages within my build due to a
> change in my GCC environment.
>
> I updated my GCC so, for assurance reasons, I want a rebuild of everything.
>
> However I want to avoid re-downloading gigs of source packages.
>
> I am hoping there is a way, say, to restart all packages build from
> the "unpack" step without doing the download step?
>
> This seems like a common use case.  Is it supported?
>
> The only help I could find is to run commands like,
>
> bitback -C xyz abc
> bitback -c xyz abc
>
> Nothing I have tried forces a complete clean out of all builds (nor
> the other options -- a restart from the unpack step).
>
> rm -rf ./tmp   works, but it also forces a download of every package :-(

It shouldn't - at least not unless you've over-ridden the default
location of the downloads directory and placed it under tmp?

The default locations are:

  DL_DIR ?= "${TOPDIR}/downloads"
  SSTATE_DIR ?= "${TOPDIR}/sstate-cache"
  TMPDIR = "${TOPDIR}/tmp"

so removing tmp should not affect either downloads or sstate-cache.

> Thanks
>
> Paul
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] how to understand the "PACKAGECONFIG_class-nativesdk " and "PACKAGECONFIG_class-target" ?

[Andre McCurdy]

On Tue, Aug 21, 2018 at 3:00 AM, tugouxp <13824125...@163.com> wrote:
> how to understand the two:
> "PACKAGECONFIG_class_target
> PACKAGECONFIG_class-nativesdk "
> semantics in bb files? i did not found any explanation on the official
> document,  so, please help me ,thanks !

They are conditional over-rides of the value of PACKAGECONFIG. The
first over-ride takes effect when building the recipe for the target
(ie the "normal" way to build a recipe, where the sources are cross
compiled to run on the target), invoked with "bitbake ".
The second over-ride takes effect when building the recipe for the SDK
(a special way to build a recipe so that the resulting binaries can
run on the host but are only linked with libraries which are shipped
with the SDK), invoked with "bitbake nativesdk-".

Using these class specific over-rides to set PACKAGECONFIG differently
when building for the target, for native (ie over-ride _class-native)
or for the SDK allows the build to be configured differently in each
case. Often the native and SDK specific builds will enable fewer
features than the target builds.

Note that in your example the target specific over-ride is wrong - it
should be _class-target rather than _class_target.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] BITBAKE ADD-LAYER | HELP!!

[Andre McCurdy]

On Thu, Aug 16, 2018 at 12:52 AM, Dhanush K.S  wrote:
> Hello MailingList,
>
> I just upgraded yocto to the latest release (Sumo 19.0 /Yocto 2.5.1).
> Currently i am trying to add the meta-openembedded layer to my
> conf/bblayers.conf using the command "bitbake-layers add-layer
> DIRECTORY_PATH/LAYER".
>
> But I am getting parseError at times.
>
> Is it absolutely necessary to checkout the meta-openembedded layer to the
> same Branch as that of the Yocto Version?

Yes, it is. Do your errors go away if you do that?

> or is it alright to stay in the
> master Branch?
> I can add the meta-oe sub-layer while on master but i get parseError when on
> the Sumo branch.
> I am not able to add the meta-python and meta-networking sub-layers of
> meta-openembedded to the conf/bblayers.conf file without getting parse
> errors. (meta-networking sub-layer depends on meta-python, so until I
> resolve that I cannot add this)
>
>  [ac500v3@localhost build-2.5]$ bitbake-layers add-layer
> /opt/ac500/yocto/trunk/yocto/next/meta-openembedded/meta-python/
> NOTE: Starting bitbake server...
> Loading cache: 100%
> ||
> Time: 0:00:00
> Loaded 499 entries from dependency cache.
> ERROR: ParseError at
> /opt/ac500/yocto/trunk/yocto/next/meta-openembedded/meta-python/recipes-devtools/python/python-pbr_4.2.0.bb:3:
> Could not include required file recipes-devtools/python/python-pbr.inc
> | ETA:  --:--:--
>
> Summary: There was 1 ERROR message shown, returning a non-zero exit code.
> ERROR: Parse failure with the specified layer added
>
> What and where am I going wrong?
>
>
> Mit freundlichen Grüßen / Best Regards,
> Dhanush Keshava Reddy Soppahalli
> Mob: +4915216144064
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi] core-image-minimal for raspberrypi3-64 manifest/sdimg contains no kernel modules

[Andre McCurdy]

On Wed, Aug 15, 2018 at 12:08 PM, Max Krummenacher  wrote:
> Hi
>
> Am Mittwoch, den 15.08.2018, 02:47 -0400 schrieb Steve Pavao:
>> There seems to be a problem with the core-image-minimal bitbake for 
>> raspberrypi3-64 target at head
>> of sumo in all repos.  I wonder if it’s also a problem for the raspberrypi3 
>> target.
>>
>> No kernel modules appear in the .manifest, and no kernel modules are put 
>> into the sdimg.  It’s
>> hard to believe it’s true, but that’s what I'm seeing.
>>
>> The problem does NOT occur for the rpi-hwup-image bitbake, which is actually 
>> deprecated in poky
>> 2.5/sumo.
>>
>> Before you retire the rpi-hwup-image bitbake target, will you please make 
>> sure that the kernel
>> modules from the core-image-minimal build make it into the .manifest and 
>> therefore into the sdimg?
>>
>> Please let me know where to log this issue, so I can send you the .manifest 
>> diffs, some ls command
>> output showing the large size difference between the core-image-minimal and 
>> rpi-hwup-image sdimg
>> files for identical builds, and perhaps some file listings to show that one 
>> of the builds contains
>> kernel modules (rpi-hwup-image) and the other does not (core-image-minimal).
>>
>> Steve Pavao
>> Korg R
>>
>
> Note that the 'kernel-modules' package is one of the packages built by a 
> kernel recipe.
> It is a meta package which RDEPENDS on all kernel module packages built by 
> your kernel
> configuration. So adding that package to your image should do the trick.

To understand what's happening it's worth also reading the SUMMARY for
core-image-minimal:

  SUMMARY = "A small image just capable of allowing a device to boot"

and comparing to core-image-base:

  SUMMARY = "A console-only image that fully supports the target
device hardware"

ie the fact that core-image-minimal doesn't contain any kernel modules
is a feature, not a bug.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Creating multiple filesystem images

[Andre McCurdy]

On Mon, Aug 13, 2018 at 8:23 AM, Amol Lad  wrote:
> Hi,
>
> Currently when we build say core-image-minimal, we get a root file system
> image (say ext4) after the build. However, I also need to create an ext4
> image for /boot partition (which contains zImage and dtb). I do not want wic
> image. How I can do this? i.e. I want two ext4 images after build: one root
> file system and another with content of /boot folder. Please advise

This isn't supported directly. However, if you look in
meta/classes/image_types.bbclass -> oe_mkext234fs() you will find the
commands which are run for the ext4 image type.

By copying and extending that code, you can define your own custom
image type (e.g. "ext4-split") which creates two ext4 images from the
rootfs instead of one.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto userbase in numbers?

[Andre McCurdy]

On Thu, Aug 9, 2018 at 2:42 PM, akuster808  wrote:
> On 08/09/2018 10:19 AM, Frazer, Will wrote:
>
> I was asked recently what a ballpark figure for the number of systems
> running distributions built with yocto might be and I could not find
> anything.
>
> I realise it’s almost impossible to tell since technically everyone builds a
> different distro, but I don’t suppose anyone has come across any estimates
> anywhere ?
>
> The Yocto Project does not have the ability to track which distributions are
> created from the OpenEmbedded build framework nor who uses Poky as a
> starting point.

Actually poky users probably do leave quite a detailed trail each time
they build anything due to the default PREMIRRORS in the poky distro
config. The downloads.yoctoproject.org logs could probably reveal a
lot...
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-gplv2][PATCH] gnutls: update 3.3.29 -> 3.3.30

[Andre McCurdy]

* Version 3.3.30 (released 2018-07-16)

** libgnutls: Corrected infinite loop when an incorrect PIN was provided
   via pin-value or pin-source.

** gnutls-cli: backported the --sni-hostname option. This allows overriding the
   hostname advertised to the peer.

** Improved counter-measures for TLS CBC record padding. Kenny Paterson, Eyal 
Ronen
   and Adi Shamir reported that the existing counter-measures had certain 
issues and
   were insufficient when the attacker has additional access to the CPU cache 
and
   performs a chosen-plaintext attack. This affected the legacy CBC 
ciphersuites. [CVSS: medium]

** The ciphers utilizing HMAC-SHA384 and SHA256 have been removed from the 
default
   priority strings. They are not necessary for compatibility or other purpose 
and
   provide no advantage over their SHA1 counter-parts, as they all depend on 
the legacy
   TLS CBC block mode.

** API and ABI modifications:
No changes since last version.

Signed-off-by: Andre McCurdy 
---
 recipes-support/gnutls/gnutls_3.3.29.bb | 8 
 recipes-support/gnutls/gnutls_3.3.30.bb | 8 
 2 files changed, 8 insertions(+), 8 deletions(-)
 delete mode 100644 recipes-support/gnutls/gnutls_3.3.29.bb
 create mode 100644 recipes-support/gnutls/gnutls_3.3.30.bb

diff --git a/recipes-support/gnutls/gnutls_3.3.29.bb 
b/recipes-support/gnutls/gnutls_3.3.29.bb
deleted file mode 100644
index 21099eb..000
--- a/recipes-support/gnutls/gnutls_3.3.29.bb
+++ /dev/null
@@ -1,8 +0,0 @@
-require gnutls.inc
-
-SRC_URI += " \
-file://configure.ac-fix-sed-command.patch \
-file://use-pkg-config-to-locate-zlib.patch \
-"
-SRC_URI[md5sum] = "de7a58232d42b1d71baf38a06dc34412"
-SRC_URI[sha256sum] = 
"fa9d13f1bc35b81fac85152906b8d4950f4f5a90d76d5b406c1167728770c94a"
diff --git a/recipes-support/gnutls/gnutls_3.3.30.bb 
b/recipes-support/gnutls/gnutls_3.3.30.bb
new file mode 100644
index 000..6e9f026
--- /dev/null
+++ b/recipes-support/gnutls/gnutls_3.3.30.bb
@@ -0,0 +1,8 @@
+require gnutls.inc
+
+SRC_URI += " \
+file://configure.ac-fix-sed-command.patch \
+file://use-pkg-config-to-locate-zlib.patch \
+"
+SRC_URI[md5sum] = "748f4c194a51ca9f2c02d9b7735262c2"
+SRC_URI[sha256sum] = 
"41d70107ead3de2f12390909a05eefc9a88def6cd1f0d90ea82a7dac8b8effee"
-- 
1.9.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Removing syslogd form busybox

[Andre McCurdy]

On Mon, Jul 30, 2018 at 10:53 AM, Simon Chamlian  wrote:
> So what you are saying is I need to update busybox to be able to remove
> syslog from it?

Depends on what you mean by "update". Backporting a patch is generally
considered updating, but I guess you could argue either way.

What I'm saying is that upstream oe-core contains a change to the
busybox recipe which makes it easier to disable busybox syslog. It's
up to you whether you try to backport that change or whether you come
up with your own solution. Both ways can be made to work.

> Also I noticed 2 syslogd:
> /sbin/syslogd
> /usr/lib/opkg/alternatives/syslogd
>
> /sbin/syslogd is a link to busybox.
>
> What is /usr/lib/opkg/alternatives/syslogd   ?
>
>
>
> On Fri, Jul 27, 2018 at 4:47 PM, Andre McCurdy  wrote:
>>
>> On Fri, Jul 27, 2018 at 1:07 PM, Simon Chamlian 
>> wrote:
>> > Hi,
>> >
>> > When I removing syslogd from busybox, I can compile with no error
>> >
>> > $ bitbake -c compile busybox
>> > Loading cache: 100% || Time: 0:00:01
>> > Loaded 3082 entries from dependency cache.
>> > WARNING: No bb files matched BBFILE_PATTERN_phytec
>> > '^/opt/PHYTEC_BSPs/yocto_imx7/sources/meta-phytec/common/'
>> > NOTE: Resolving any missing task queue dependencies
>> >
>> > Build Configuration:
>> > BB_VERSION= "1.32.0"
>> > BUILD_SYS = "x86_64-linux"
>> > NATIVELSBSTRING   = "Ubuntu-16.04"
>> > TARGET_SYS= "arm-poky-linux-gnueabi"
>> > MACHINE   = "imx7d-phyboard-zeta-001"
>> > DISTRO= "fsl-imx-x11"
>> > DISTRO_VERSION= "4.9.11-1.0.0"
>> > TUNE_FEATURES = "arm armv7ve vfp  neoncallconvention-hard
>> > cortexa7"
>> > TARGET_FPU= "hard"
>> > meta
>> > meta-poky = "HEAD:78890ea22750804e3e9113e76f7ca3d7234c8342"
>> > meta-oe
>> > meta-multimedia
>> > meta-webserver= "HEAD:fe5c83312de11e80b85680ef237f8acb04b4b26e"
>> > meta-freescale= "HEAD:a398b50b7fc084a9e68cc3000c218d5028522a25"
>> > meta-freescale-3rdparty =
>> > "HEAD:68314612e236cab1da82d72a0da62635a3523f84"
>> > meta-freescale-distro = "HEAD:cd5c7a2539f40004f74126e9fdf08254fd9a6390"
>> > meta-bsp
>> > meta-sdk  = "HEAD:daba3340ecd8b358e0c6c415baeee0fcae95c525"
>> > meta-browser  = "HEAD:10f6e3778d823ee1be106c126216c6f941088fbf"
>> > meta-gnome
>> > meta-networking
>> > meta-python
>> > meta-filesystems  = "HEAD:fe5c83312de11e80b85680ef237f8acb04b4b26e"
>> > meta-qt5  = "HEAD:ff073f04109900fc07bf81e2f1df63c626caf342"
>> > meta-phytec
>> > meta-phytec-fsl   = "HEAD:f9897a4e06f43184a71d315cec4a412a28baa59b"
>> >
>> > WARNING:
>> >
>> > /opt/PHYTEC_BSPs/yocto_imx7/sources/poky/meta/recipes-core/busybox/busybox_1.24.1.bb.do_compile
>> > is tainted from a forced run
>> > | ETA:  0:00:01
>> > Initialising tasks: 100%
>> >
>> > |###|
>> > Time: 0:00:01
>> > NOTE: Executing SetScene Tasks
>> > NOTE: Executing RunQueue Tasks
>> > NOTE: Tasks Summary: Attempted 234 tasks of which 232 didn't need to be
>> > rerun and all succeeded.
>> >
>> > Summary: There were 2 WARNING messages shown.
>> >
>> >
>> > When I build my image for my machine, I am getting the following error:
>> >
>> >
>> > WARNING: busybox-1.24.1-r0 do_package: busybox: alternative target
>> > (/etc/syslog.conf or /etc/syslog.conf.busybox) does not exist,
>> > skipping...
>> > WARNING: busybox-1.24.1-r0 do_package: busybox: NOT adding alternative
>> > provide /etc/syslog.conf: /etc/syslog.conf.busybox does not exist
>> > ERROR: busybox-1.24.1-r0 do_package: SYSTEMD_SERVICE_busybox-syslog
>> > value
>> > busybox-syslog.service does not exist
>> > ERROR: busybox-1.24.1-r0 do_package: Function failed:
>> > systemd_populate_packages
>> > ERROR: Logfile of failure stored in:
>> >
>> > /opt/PHYTEC_BSPs/yocto_imx7/build/tmp/work/cortexa7hf-neon-poky-linux-gnueabi/busybox/1.24.1-r0/temp/log.do_package.30442
>> > ERROR: Task
>> >
>> > (/opt/PHYTEC_BSPs/yocto_imx7/sources/poky/meta/recipes-core/busybox/busybox_1.24.1.bb:do_package)
>> > failed with exit code '1'
>> >
>> > Any hints?
>>
>> It looks like you're using morty, which pre-dates busybox syslog
>> "officially" being made optional:
>>
>>
>> http://git.openembedded.org/openembedded-core/commit/?id=9732a2ba2edf2607e61ae4fe0d65a02b7918cfe7
>>
>> If you can't update to a newer release you could try backporting the
>> above commit.
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Removing syslogd form busybox

[Andre McCurdy]

On Fri, Jul 27, 2018 at 1:07 PM, Simon Chamlian  wrote:
> Hi,
>
> When I removing syslogd from busybox, I can compile with no error
>
> $ bitbake -c compile busybox
> Loading cache: 100% || Time: 0:00:01
> Loaded 3082 entries from dependency cache.
> WARNING: No bb files matched BBFILE_PATTERN_phytec
> '^/opt/PHYTEC_BSPs/yocto_imx7/sources/meta-phytec/common/'
> NOTE: Resolving any missing task queue dependencies
>
> Build Configuration:
> BB_VERSION= "1.32.0"
> BUILD_SYS = "x86_64-linux"
> NATIVELSBSTRING   = "Ubuntu-16.04"
> TARGET_SYS= "arm-poky-linux-gnueabi"
> MACHINE   = "imx7d-phyboard-zeta-001"
> DISTRO= "fsl-imx-x11"
> DISTRO_VERSION= "4.9.11-1.0.0"
> TUNE_FEATURES = "arm armv7ve vfp  neoncallconvention-hard
> cortexa7"
> TARGET_FPU= "hard"
> meta
> meta-poky = "HEAD:78890ea22750804e3e9113e76f7ca3d7234c8342"
> meta-oe
> meta-multimedia
> meta-webserver= "HEAD:fe5c83312de11e80b85680ef237f8acb04b4b26e"
> meta-freescale= "HEAD:a398b50b7fc084a9e68cc3000c218d5028522a25"
> meta-freescale-3rdparty = "HEAD:68314612e236cab1da82d72a0da62635a3523f84"
> meta-freescale-distro = "HEAD:cd5c7a2539f40004f74126e9fdf08254fd9a6390"
> meta-bsp
> meta-sdk  = "HEAD:daba3340ecd8b358e0c6c415baeee0fcae95c525"
> meta-browser  = "HEAD:10f6e3778d823ee1be106c126216c6f941088fbf"
> meta-gnome
> meta-networking
> meta-python
> meta-filesystems  = "HEAD:fe5c83312de11e80b85680ef237f8acb04b4b26e"
> meta-qt5  = "HEAD:ff073f04109900fc07bf81e2f1df63c626caf342"
> meta-phytec
> meta-phytec-fsl   = "HEAD:f9897a4e06f43184a71d315cec4a412a28baa59b"
>
> WARNING:
> /opt/PHYTEC_BSPs/yocto_imx7/sources/poky/meta/recipes-core/busybox/busybox_1.24.1.bb.do_compile
> is tainted from a forced run
> | ETA:  0:00:01
> Initialising tasks: 100%
> |###|
> Time: 0:00:01
> NOTE: Executing SetScene Tasks
> NOTE: Executing RunQueue Tasks
> NOTE: Tasks Summary: Attempted 234 tasks of which 232 didn't need to be
> rerun and all succeeded.
>
> Summary: There were 2 WARNING messages shown.
>
>
> When I build my image for my machine, I am getting the following error:
>
>
> WARNING: busybox-1.24.1-r0 do_package: busybox: alternative target
> (/etc/syslog.conf or /etc/syslog.conf.busybox) does not exist, skipping...
> WARNING: busybox-1.24.1-r0 do_package: busybox: NOT adding alternative
> provide /etc/syslog.conf: /etc/syslog.conf.busybox does not exist
> ERROR: busybox-1.24.1-r0 do_package: SYSTEMD_SERVICE_busybox-syslog value
> busybox-syslog.service does not exist
> ERROR: busybox-1.24.1-r0 do_package: Function failed:
> systemd_populate_packages
> ERROR: Logfile of failure stored in:
> /opt/PHYTEC_BSPs/yocto_imx7/build/tmp/work/cortexa7hf-neon-poky-linux-gnueabi/busybox/1.24.1-r0/temp/log.do_package.30442
> ERROR: Task
> (/opt/PHYTEC_BSPs/yocto_imx7/sources/poky/meta/recipes-core/busybox/busybox_1.24.1.bb:do_package)
> failed with exit code '1'
>
> Any hints?

It looks like you're using morty, which pre-dates busybox syslog
"officially" being made optional:

  
http://git.openembedded.org/openembedded-core/commit/?id=9732a2ba2edf2607e61ae4fe0d65a02b7918cfe7

If you can't update to a newer release you could try backporting the
above commit.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to enable http2 for Apache?

[Andre McCurdy]

On Wed, Jul 25, 2018 at 12:45 PM, Simon Chamlian  wrote:
> Trial and errors.
>
> Is there another way of enabling http2  ?
>
> In general, if we wish to add flags to a compilation of a package, what is
> the proper way of doing it?

Start by reading the recipe and see what variables or PACKAGECONFIG
options it uses to derive the configure options.

If there's no PACKAGECONFIG option to control the feature then
(assuming it's an autotools recipe - which again you need to read the
recipe to determine) you can add additional options to EXTRA_OECONF.

> Changing the local.conf or the recipe of a given package?

Once you know what variable you are trying to change (e.g. appending
to PACKAGECONFIG, EXTRA_OECONF, etc) then there are many ways you can
do so. Editing the recipe, creating a .bbappend for the recipe or
setting via local.conf (which case you'll need to use a recipe
specific over-ride since local.conf is a global config file and you
only want your change to apply to one particular recipe) would all
work.

The basic advice though is to try to understand the change you need to
make a how to make it by reading documentation or existing recipes etc
and trying to figure out how and why they work. Trial and error is not
a good way to try to learn OE.

>
> On Wed, Jul 25, 2018 at 3:26 PM, Andre McCurdy  wrote:
>>
>> On Wed, Jul 25, 2018 at 11:17 AM, Simon Chamlian 
>> wrote:
>> > Hi,
>> >
>> > What is the best way to enable http2 for Apache?
>> >
>> > Do I add
>> >
>> > COMMON_EXTRA_OECONF_append_pn-apache2 = "--enable-http2"
>> >
>> > in local.conf ?
>>
>> No.
>>
>> Wondering what process you went through to arrive at that?
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to enable http2 for Apache?

[Andre McCurdy]

On Wed, Jul 25, 2018 at 11:17 AM, Simon Chamlian  wrote:
> Hi,
>
> What is the best way to enable http2 for Apache?
>
> Do I add
>
> COMMON_EXTRA_OECONF_append_pn-apache2 = "--enable-http2"
>
> in local.conf ?

No.

Wondering what process you went through to arrive at that?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Can't get *.a's into SDK sysroot

[Andre McCurdy]

On Wed, Jul 25, 2018 at 1:23 AM, Zoran Stojsavljevic
 wrote:
> Hello Andre,
>
>> RDEPENDS_${PN}-dev += "${PN}-staticdev"
>
> I also read this email, and decided to investigate myself. Since I
> wrote meta-mylayer with cannelloni recipe in it.
>
> To find out if the recipe works correctly, and it is incorporated
> (upfront) in ROOTFS, I did the following:
> [1] Did the compilation of the clean tree;
> [2] After that, I did: bitbake -s | grep cannelloni -> yes, the build
> system sees it;
> [3] Changed to ${TMPDIR}/work and issued the command: find . -name cannelloni
>
> To my surprise, the search produced empty results.
>
> Then I added your line to the cannelloni recipe: RDEPENDS_${PN}-dev +=
> "${PN}-staticdev"
>
> Again, bitbake -c cleanall cannelloni, then bitbake cannelloni, and
> step [3] produced visible results.
>
> Now I see it in the .../tmp/work/...
>
> But, there were NOT any changes in: .../tmp/deploy/images/beaglebone/
> directory (in ${build} directory, I guess)???
>
> So, what I need to do to see build components changed (since I assume,
> cannelloni still did not make it in ROOTFS)???

I'm not sure that I understand the question.

If you are asking why you sometimes don't see build artefacts under
${TMPDIR}/work then remember that the goal of building a normal recipe
is to create a set of installable packages under ${TMPDIR}/deploy. The
files in the work directory are just side effects of the intermediate
steps to achieve that... and bitbake will try hard to skip those
intermediate steps if they can be avoided (ie if outputs can be
recreated from sstate).

If you are asking why building your image from a completely clean tree
doesn't result in building your recipe (or changing your recipe
doesn't result in the image being rebuilt) then yes it suggests that
your image doesn't include and packages created by your recipe.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Can't get *.a's into SDK sysroot

[Andre McCurdy]

On Tue, Jul 24, 2018 at 4:53 PM, Greg Wilson-Lindberg 
wrote:

> I've created a recipe for Canfestival (a CAN bus CANOpen support library).
> I have had it building for a while, but I had the configuration set up to
> build all parts of it as .so's. I need to change it so that parts of the
> library are .a's. My problem is that I can't get the .a's to copy to the
> SDK sysroot /usr/lib directory. The .a's are in the canfestival
> image/usr/lib & sysroot-destdir/usr/lib directories, but nothing that I've
> tried has gotten them to the SDK sysroot.
>
>
>
> Here is the canfestival_3-asc.bb file that I'm using:
>
>
>
> SUMMARY = "Independent CANOpen® stack"
>
> DESCRIPTION = "CanFestival focuses on providing an ANSI-C platform 
> independent \
>
>CANOpen® stack that can be built as master or slave nodes on 
> PCs, \
>
>Real-time IPCs, and Microcontrollers."
>
>
>
> HOMEPAGE = "http://www(dot)canfestival(dot)org/ 
> " // obfuscated to get past 
> our email system
>
>
>
> SRCREV = "895:8973dd8be7e8"
>
>
>
> SRC_URI = "hg://bitbucket.org/Mongo;protocol=https;module=canfestival-3-asc \
>
>file://canfestival_3-asc-configure.patch \
>
>file://canfestival_3-asc-makefile.in.patch \
>
>file://canfestival_3-asc-src_makefile.in.patch \
>
>\
>
>file://sdo.c.patch \
>
>file://def.h.patch \
>
>"
>
> PR = 'r01'
>
>
>
> LICENSE = "LGPLv2"
>
> LIC_FILES_CHKSUM = "file://COPYING;md5=46ec399d3928b6c91e3634ab7263af44 \
>
> file://LICENCE;md5=085e7fb76fb3fa8ba9e9ed0ce95a43f9"
>
>
>
> TARGET_CC_ARCH += "${LDFLAGS}"
>
>
>
>
>
>
>
> do_configure() {
>
> bbplain "Starting Configure"
>
> #bbplain "rootfs: ${D}"
>
> ./configure --target=unix --prefix=${D}/usr/ --can=socket --timers=unix  
> --SDO_MAX_SIMULTANEOUS_TRANSFERS=30 --SDO_MAX_LENGTH_TRANSFER=4096 
> --MAX_NB_TIMER=128 --SDO_TIMEOUT_MS=3000 --debug="WAR"
>
>
>
> bbplain "Configure Done"
>
> }
>
>
>
> do_compile() {
>
> oe_runmake canfestival
>
> }
>
>
>
> do_install() {
>
> bbplain "Starting Install"
>
> #bbplain "rootfs: ${D}"
>
> oe_runmake install PREFIX=${D}/usr/
>
>
>
> bbplain "Install Done"
>
> }
>
>
>
> FILES_${PN}-dbg = "/usr/src/debug/canfestival"
>
> FILES_${PN}-dev = "/usr/lib/libcanfestival*.a /usr/include/canfestival/*.h"
>
> FILES_${PN} = "/usr/lib/libcanfestival*.a /usr/lib/libcanfestival*.so"
>
>
>
> #PACKAGE_BEFORE_PN = "${PN}-info"
>
> #FILES_${PN}-info = "usr/lib/pkgconfig"
>
>
>
> I've fiddled with the various FILES lines, but nothing that I do gets the
> .a files copied to the SDK sysroot /usr/lib directory.
>
>
>
> Any insight into what is going wrong would be greatly appreciated.
>

Assuming the static libs are being built and installed correctly they
should be packaged correctly by the default packaging rules. ie you
shouldn't need to tweak any FILES_xxx values.

However you will need to ensure that the -staticdev package gets included
in the SDK. Assuming you always want the static libs for this particular
recipe to be available then you can try adding the following to the recipe:

  RDEPENDS_${PN}-dev += "${PN}-staticdev"
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] To remove packages from busybox

[Andre McCurdy]

On Mon, Jul 23, 2018 at 1:29 PM, Simon Chamlian  wrote:
> Hi,
>
> In order to remove package from busybox, I used:
>
> $ bitbake  -c menuconfig busybox
>
> Under 'System Logging Itilities -->' I unchecked syslogd
>
> Then ran
> $ bitbake   busybox
>
> and I get the following error:
>
> WARNING: busybox-1.24.1-r0 do_package: busybox: alternative target
> (/etc/syslog.conf or /etc/syslog.conf.busybox) does not exist, skipping...
> WARNING: busybox-1.24.1-r0 do_package: busybox: NOT adding alternative
> provide /etc/syslog.conf: /etc/syslog.conf.busybox does not exist
>
> ERROR: busybox-1.24.1-r0 do_package: SYSTEMD_SERVICE_busybox-syslog value
> busybox-syslog.service does not exist
>
>
> ERROR: busybox-1.24.1-r0 do_package: Function failed:
> systemd_populate_packages
>
>
> ERROR: Logfile of failure stored in:
> /opt/PHYTEC_BSPs/yocto_imx7/build/tmp/work/cortexa7hf-neon-poky-linux-gnueabi/busybox/1.24.1-r0/temp/log.do_package.30881
>
> ERROR: Task
> (/opt/PHYTEC_BSPs/yocto_imx7/sources/poky/meta/recipes-core/busybox/busybox_1.24.1.bb:do_package)
> failed with exit code '1'
>
> NOTE: Tasks Summary: Attempted 711 tasks of which 705 didn't need to be
> rerun and 1 failed.
>
> What am I doing wrong?

The "correct" way to disable syslog support in busybox would probably
be to create a .bbappend which contains:

  SRC_URI_remove = "file://syslog.conf"

ie you would remove the config fragment which enables syslog from SRC_URI.

However, customising busybox like that gets almost no testing, so
there could certainly still be bugs.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] bitbake is corrupting my files during unpacking

[Andre McCurdy]

On Sat, Jul 21, 2018 at 12:55 AM, MOHAMMAD RASIM
 wrote:
> well apparently this is caused by the unzip binary that is compiled by the
> openembedded unzip recipe.
> If I unzip the same zip file with the unzip binary that is shipped with my
> system(manjaro) then the files are not corrupted but when I use the unzip
> binary compiled by the openembedded recipe I get error and file corruptions.
> These are some of the errors I get when unzipping with the openembedded
> unzip:
> ...
> symlink error: File name too long
>
> This error happens to multiple files where the file is symlinked to the
> content of the file and not to a path !
> Where should I report this bug ? openembedded ? unzip upstream ?

If you google the "symlink error" you should find multiple hits, which
all indicate a known bug in upstream unzip 6.0.

So, it should be reported upstream. However, given that the last unzip
release is now over 9 years old and there doesn't appear to be a
public upstream development branch, the chances of getting a timely
response don't look too good.

We should probably add the fix to the unzip recipe in oe-core:

  https://bugzilla.redhat.com/show_bug.cgi?id=972427
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [Chicken and Egg problem] Defining RDEPENDS of the package itself!

[Andre McCurdy]

On Wed, Jul 18, 2018 at 7:04 AM, Zoran Stojsavljevic
 wrote:
> Yep. Did it. Some symlink is missing (I guess, symlink to
> /usr/local/lib/libcannelloni-common.so???
>
> Initialising tasks: 100%
> |#|
> Time: 0:00:00
> NOTE: Executing SetScene Tasks
> NOTE: Executing RunQueue Tasks
> ERROR: cannelloni-1.0-r0 do_package_qa: QA Issue: cannelloni rdepends on
> cannelloni-dev [dev-deps]
> ERROR: cannelloni-1.0-r0 do_package_qa: QA Issue: -dev package contains
> non-symlink .so: cannelloni-dev path
> '/work/cortexa8hf-neon-poky-linux-gnueabi/cannelloni/1.0-r0/packages-split/cannelloni-dev/usr/lib/libcannelloni-common.so'
> [dev-elf]
> ERROR: cannelloni-1.0-r0 do_package_qa: QA run found fatal errors. Please
> consider fixing them.
> ERROR: cannelloni-1.0-r0 do_package_qa: Function failed: do_package_qa
> ERROR: Logfile of failure stored in:
> /home/netmodule.intranet/stojsavljevic/projects/beaglebone-black/yocto-rocko/poky/build/tmp/work/cortexa8hf-neon-poky-linux-gnueabi/cannelloni/1.0-r0/temp/log.do_package_qa.7896
> ERROR: Task
> (/home/netmodule.intranet/stojsavljevic/projects/beaglebone-black/yocto-rocko/poky/meta-test-layer/recipes-canapp/cannelloni/cannelloni.bb:do_package_qa)
> failed with exit code '1'
> NOTE: Tasks Summary: Attempted 539 tasks of which 532 didn't need to be
> rerun and 1 failed.
>
> Summary: 1 task failed:
>
> /home/netmodule.intranet/stojsavljevic/projects/beaglebone-black/yocto-rocko/poky/meta-test-layer/recipes-canapp/cannelloni/cannelloni.bb:do_package_qa
> Summary: There were 2 WARNING messages shown.
> Summary: There were 4 ERROR messages shown, returning a non-zero exit code.
>
> How I can add this symlink (!) to this recipe?

The error says "-dev package contains non-symlink .so".

Simply adding a symlink somewhere will not help. The fix is to ensure
that libcannelloni-common.so gets packaged in the main run-time
package (and not in the -dev package).

Reading the section about non-versioned shared libraries here might help:

  https://wiki.yoctoproject.org/wiki/TipsAndTricks/Packaging_Prebuilt_Libraries
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to split rootfs image?

[Andre McCurdy]

On Wed, Jul 11, 2018 at 12:16 PM, Lukasz Zemla
 wrote:
> Dear All,
>
> Because of some formal reasons, we would like to split our rootfs image into
> 2 parts:
>
> 1. base system - to be reused between different project variants, typical
> rootfs content.
>
> 2. application/data - less critical application, configuration, data, logs.
>
> How to generate in Yocto application/data image(2)?
>
> It is about generation of empty image containing only requested packages,
> like Package-A, Package-B...
>
> We tried following:
>
> inherit image
>
> IMAGE_FEATURES = ""
>
> DISTRO_FEATURES = ""
>
> IMAGE_INSTALL = " \
>Package-A \
>Package-B \
>"
>
> IMAGE_FSTYPES = "ubi tar.gz"
>
> But it produces classical rootfs image with (unwanted): bin, boot, etc,
> lib... We'd prefer to have it built in an efficient way, so we'd like to
> avoid generating full image and then removing files by hand in postprocess
> command.

Yes it's harder than you might expect to create an image which
contains only the specific packages you define, without any of their
normal dependencies.

If your goal is just to split a single rootfs into two image files
instead of one, then a possible approach could be to define your own
custom image type (ubisplit, or whatever) which separates the rootfs
into two temp directories and then creates separate image files for
each one.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Writing a recipe that allows for extra depends, depending on the extra_oemake configurations

[Andre McCurdy]

On Thu, Jul 12, 2018 at 3:12 PM, Giordon Stark  wrote:
> Hi Ross,
>
> Thanks. I saw that but the documentation doesn't explicitly mentioned
> EXTRA_OEMAKE. Is that the same as EXTRA_OECONF?

No, EXTRA_OEMAKE and EXTRA_OECONF are different.

Config options derived from PACKAGECONFIG are automatically appended
to EXTRA_OECONF (by autotools.bbclass), EXTRA_OECMAKE (by
cmake.bbclass) and EXTRA_OEMESON (by meson.bbclass) but never
automatically appended to EXTRA_OEMAKE. If you want to add
PACKAGECONFIG derived options to EXTRA_OEMAKE then you can manually
add PACKAGECONFIG_CONFARGS to EXTRA_OEMAKE from within a recipe, for
example see:

  
http://git.openembedded.org/openembedded-core/tree/meta/recipes-graphics/glew/glew_2.1.0.bb

Note that your original example was based around EXTRA_OECMAKE though,
not EXTRA_OEMAKE.

> On Thu, Jul 12, 2018 at 5:08 PM Burton, Ross  wrote:
>>
>> > I'm wondering how I can make it so that I can have a user allow for
>> > additional configuration to enable crypto/krb5 which requires extra
>> > depends
>> > and changing the oemake flags. Is this something Yocto can do, or is it
>> > better to have users provide a bbappend file to update this recipe?
>>
>> Yes, PACKAGECONFIG is exactly what you want.
>>
>> https://www.yoctoproject.org/docs/2.4.2/ref-manual/ref-manual.html#var-PACKAGECONFIG
>>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Which bb is chosen when several versions are available

[Andre McCurdy]

On Wed, Jul 11, 2018 at 12:30 PM, Rudolf J Streif
 wrote:
> The one with the higher version number unless explicitly overridden with
> PREFERRED_VERSION_php.
>
> However, if there is also a recipe with _git.bb then that one will be
> chosen as git indicates the latest.

Selection between multiple recipes in the same layer will be made
based on their PV variable. By default PV will follow the version
defined by the recipe name, but there's nothing to stop a recipe
explicitly setting something else... and it's the final PV value which
is used to select between multiple recipes, not the recipe name.
There's nothing special about _git recipes. If a _git recipe sets a
higher PV value then it will be selected, if it sets a lower PV value
then it wont.

> On 07/11/2018 12:28 PM, Simon Chamlian wrote:
>
> Hi,
>
> In the BSP yocto image, I have 2 recipes:
>
> /sources/meta-openembedded/meta-oe/recipes-devtools/php
>
> drwxrwxr-x 2 jay jay  4096 Jun 28 09:48 php
> -rw-rw-r-- 1 jay jay   232 Jun 28 09:48 php_5.5.38.bb
> drwxrwxr-x 2 jay jay  4096 Jun 28 09:48 php-5.6.26
> -rw-rw-r-- 1 jay jay   291 Jun 28 09:48 php_5.6.26.bb
> -rw-rw-r-- 1 jay jay 11980 Jun 28 09:48 php.inc
>
>
> If I add in my image recipe:
> CORE_IMAGE_EXTRA_INSTALL += " \
> php \
> "
>
> which version will be included?
>
> Thanks,
> S
>
>
>
>
> --
> Rudolf J Streif
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Including a header from an external kernel module

[Andre McCurdy]

On Tue, Jul 10, 2018 at 12:11 AM, Michael Allwright
 wrote:
> Am I correct in expecting that, if I do everything correctly, my header file
> from module-a should end up in
> ~/poky/build/tmp/work-shared/machine/kernel-source/include/linux/mfd

No, the kernel-source directory is for the kernel recipe and other
recipes can't generally add anything too it (if you want a header to
show up in the kernel source directory then you could patch the kernel
sources though).

Other (ie non-kernel) recipes share headers etc via sysroot, which
with OE 2.3 and above is created for each recipe in the
"recipe-sysroot" subdirectory in the recipe's WORKDIR.

>From what you've said so far, I guess module-a's header file is in
module-b's sysroot directory under /usr/include, but when module-b is
compiled the include path isn't setup to find it.

Since /usr/include in sysroot contains headers for user space it's
quite correct that it shouldn't be in the include path when building a
kernel module (e.g. to prevent accidentally including user space
string.h instead of the kernel version, etc, etc). When the kbuild
Makefiles call the compiler they will not pass a --sysroot option etc.

If module-a is sharing a header in a subdirectory of sysroot, you will
need to somehow manually add that directory as an extra include path
when module-b is compiled (don't try to add the whole of sysroot
/usr/include - just the specific subdirectory you need).

A possible alternative approach might be to create one recipe which
builds all your kernel modules. That would make the build self more
contained as each module can find headers from other modules somewhere
in ${S}.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Including a header from an external kernel module

[Andre McCurdy]

On Mon, Jul 9, 2018 at 3:07 PM, Michael Allwright
 wrote:
> Yes, it ended up in the development package in the do_install_append
> attempt

How did you confirm that (ie that the header ended up in the
module-a-dev package) ?

> , but I couldn't #include it in the second module (file didn't exist
> in the include search paths).

Did you add:

  DEPENDS = "module-a"

to the module-b recipe?

> I would point out though, that I am interested in what is the correct way to
> do this, and not just in finding some workaround / hack so that it works...

That's good to hear.

> On Mon., 9 Jul. 2018, 19:47 Andre McCurdy,  wrote:
>>
>> On Mon, Jul 9, 2018 at 8:27 AM, Michael Allwright
>>  wrote:
>> > Hello,
>> >
>> > I think it would be useful to extend the hello-mod recipe in
>> > meta-skeleton
>> > to demonstrate some slightly more complicated scenarios. For example, I
>> > am
>> > trying to find out how to have two external kernel modules A and B,
>> > where
>> > module B #includes a header file provided by module A.
>> >
>> > I have made module B depend on module A, however, I believe I am still
>> > missing one or two steps in my recipe for module A such that the header
>> > file
>> > is copied into the shared kernel staging directory where module B can
>> > find
>> > it.
>> >
>> > So far I have tried the following:
>> >
>> > FILES_${PN}-dev += "/usr/include/linux/mfd/module-a.h"
>> >
>> > FILES_kernel-headers += "${includedir}/linux/mfd/module-a.h"
>> >
>> > do_install_append () {
>> >install -d ${D}${includedir}/linux/mfd
>> >install -m 644 ${S}/module-a ${D}${includedir}/linux/mfd/module-a.h
>> > }
>>
>> And what happened after you tried the above? Did the header not end up
>> in the -dev package for module A? Did the module A recipe not create a
>> -dev package? Something else?
>>
>> > In module B, I want to be able to:
>> >
>> > #include 
>> >
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Including a header from an external kernel module

[Andre McCurdy]

On Mon, Jul 9, 2018 at 8:27 AM, Michael Allwright
 wrote:
> Hello,
>
> I think it would be useful to extend the hello-mod recipe in meta-skeleton
> to demonstrate some slightly more complicated scenarios. For example, I am
> trying to find out how to have two external kernel modules A and B, where
> module B #includes a header file provided by module A.
>
> I have made module B depend on module A, however, I believe I am still
> missing one or two steps in my recipe for module A such that the header file
> is copied into the shared kernel staging directory where module B can find
> it.
>
> So far I have tried the following:
>
> FILES_${PN}-dev += "/usr/include/linux/mfd/module-a.h"
>
> FILES_kernel-headers += "${includedir}/linux/mfd/module-a.h"
>
> do_install_append () {
>install -d ${D}${includedir}/linux/mfd
>install -m 644 ${S}/module-a ${D}${includedir}/linux/mfd/module-a.h
> }

And what happened after you tried the above? Did the header not end up
in the -dev package for module A? Did the module A recipe not create a
-dev package? Something else?

> In module B, I want to be able to:
>
> #include 
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to remove openssl from sysroots

[Andre McCurdy]

On Sun, Jul 8, 2018 at 7:04 PM, Philip Balister  wrote:
> On 07/06/2018 03:06 PM, Raymond Yeung wrote:
>> I've changed the subject heading to make it more specific to our problem.  
>> Hopefully this generates some responses.
>>
>> It has been blocking us for close to one week now.  We want to use our 3rd 
>> party vendor openssl, not the one that comes with the source.  Apparently, 
>> even with "minimal" instead of "base" or "sato" cannot exclude it.
>>
>> Any idea [e.g. how do we systematically find out how it's included now, and 
>> possibly what other packages/recipes we may also need to remove due to 
>> dependency]?
>
> I tend to use the ouput of the buildhistory class when I have these
> questions.

An alternative quick and dirty approach is to make the recipe
unbuildable. If the recipe is unbuildable but needed by something then
the bitbake error message will give the dependency chain. You can make
a recipe unbuildable for the target by adding the following to the
recipe:

  COMPATIBLE_HOST_class-target = 'null'

Note that there are two openssl recipes in recent oe-core (v1.0.x and
v1.1.x). For this experiment you will need to make BOTH of them
unbuildable.

This seems like a somewhat pointless path to be going down though. If
you remove all packages which depend on openssl from the target rootfs
then you won't need to add in your 3rd party vendor openssl any
more... since nothing is going to use it.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Understanding "dev package contains non-symlink"

[Andre McCurdy]

On Fri, Jul 6, 2018 at 2:10 PM, Giordon Stark  wrote:
> Hi,
>
> So the good news is that this is at least the source code itself appears to
> be written in a packaged-up-manner which makes some things easier to deal
> with. It seems that all of the plugins are here:
> https://github.com/xrootd/xrootd/blob/dad82068ae99859ebf40f65d95fe7c44f7db057e/src/XrdPlugins.cmake
>
> where it seems to install to
>
> install(
>   TARGETS ${LIB_XRD_PSS} ${LIB_XRD_BWM} ${LIB_XRD_GPFS} ${LIB_XRD_ZCRC32}
> ${LIB_XRD_THROTTLE} ${LIB_XRD_N2NO2P}
>   LIBRARY DESTINATION ${CMAKE_INSTALL_LIBDIR} )
>
> While all other "non-plugins" also install to the same
> "CMAKE_INSTALL_LIBDIR". I suppose it might be possible to patch this one
> particular file to get the installs in a separate location? This seems like
> potentially a short patch given that all plug-ins, from a cursory glance,
> are installed with the same CMake instruction...
>
> If not, I would be ok with adding
>
> INSANE_SKIP_${PN} += "dev-so"
>
> to my recipe along with the other two lines I've added (one to erase the
> so-libs pattern for ${PN}-dev, and one to force all the *.so libs into
> ${PN}).
>
> Would a third option be to just manually write out my ${PN} and ${PN}-dev
> files to split up which are symlinks and which are not -- given that I'm
> writing this recipe for a given version/configuration?

Yes, that should be OK.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] (still) struggling with initramfs

[Andre McCurdy]

On Fri, Jul 6, 2018 at 1:22 PM, Tim Hammer  wrote:
>
> Thanks for the responses to my first email. I was able to get a working
> initramfs in my kernel image that allowed me to do the initial evaluation of
> my solution.

What was the issue? What was the fix?

> Now I am working to get all of the proper content into the filesystem, but
> am seeing some strangeness that I cannot comprehend. I have updated the
> image recipe that my linux.bbappend is calling out as the INITRAMFS_IMAGE,
> but the bitbake linux command did not see anything as changed so ran no
> tasks.

The kernel's bundle_initramfs task depends on
${INITRAMFS_IMAGE}:do_image_complete, so if the new value you set for
INITRAMFS_IMAGE is an image which had previously been built the
kernel's bundle_initramfs might not get triggered again?

Perhaps try running "bitbake -c cleansstate" for your image and then
"bitbake linux" again.

> As a simplistic attempt, I commented out the INITRAMFS_IMAGE line in
> the recipe and this time it rebuilt a lot, but ended up with the "old"
> initramfs (not an empty one as I kind of expected). I then re-enabled the
> INITRAMFS_IMAGE line and this time got a much smaller Linux image which
> failed to boot (Unable to mount root fs- more what I expected from the last
> build).

A kernel image without the bundled initramfs is always going to be
built as part of the normal build process for the kernel (it's built
by the kernel's compile task - the version with the bundled initramfs
is built by the bundle_initramfs task).

Normally you should be able to tell the difference between the two
kernel images by the .initramfs suffix, however the bug you saw
originally was in the bundle_initramfs code to do that renaming, so
depending on how you resolved the original issue, maybe your kernel
images are still getting mixed up?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Understanding "dev package contains non-symlink"

[Andre McCurdy]

On Fri, Jul 6, 2018 at 1:28 PM, Giordon Stark  wrote:
> Hi,
>
> Been struggling to understand the differences here. This is what the
> directory looks like
>
> kratsg@dc:/local/d4/gstark/poky/build$ ls
> tmp/work/aarch64-poky-linux/xrootd/4.8.3-r0/packages-split/xrootd/usr/lib/
> total 4.3M
> drwxr-xr-x 2 kratsg atlas 4.0K Jun 28 16:13 .
> drwxr-xr-x 5 kratsg atlas 4.0K Jun 28 16:13 ..
> lrwxrwxrwx 1 kratsg atlas   19 Jun 28 16:13 libXrdAppUtils.so ->
> libXrdAppUtils.so.1
> lrwxrwxrwx 1 kratsg atlas   23 Jun 28 16:13 libXrdAppUtils.so.1 ->
> libXrdAppUtils.so.1.0.0
> -rwxr-xr-x 2 kratsg atlas  44K Jun 28 16:13 libXrdAppUtils.so.1.0.0
> -rwxr-xr-x 2 kratsg atlas  15K Jun 28 16:13 libXrdBlacklistDecision-4.so
> -rwxr-xr-x 2 kratsg atlas  59K Jun 28 16:13 libXrdBwm-4.so
> -rwxr-xr-x 2 kratsg atlas  11K Jun 28 16:13 libXrdCksCalczcrc32-4.so
> lrwxrwxrwx 1 kratsg atlas   13 Jun 28 16:13 libXrdCl.so -> libXrdCl.so.2
> -rwxr-xr-x 2 kratsg atlas  27K Jun 28 16:13 libXrdClProxyPlugin-4.so
> lrwxrwxrwx 1 kratsg atlas   17 Jun 28 16:13 libXrdClient.so ->
> libXrdClient.so.2
> lrwxrwxrwx 1 kratsg atlas   21 Jun 28 16:13 libXrdClient.so.2 ->
> libXrdClient.so.2.0.0
> -rwxr-xr-x 2 kratsg atlas 554K Jun 28 16:13 libXrdClient.so.2.0.0
> lrwxrwxrwx 1 kratsg atlas   17 Jun 28 16:13 libXrdCl.so.2 ->
> libXrdCl.so.2.0.0
> -rwxr-xr-x 2 kratsg atlas 937K Jun 28 16:13 libXrdCl.so.2.0.0
> lrwxrwxrwx 1 kratsg atlas   17 Jun 28 16:13 libXrdCrypto.so ->
> libXrdCrypto.so.1
> lrwxrwxrwx 1 kratsg atlas   21 Jun 28 16:13 libXrdCryptoLite.so ->
> libXrdCryptoLite.so.1
> lrwxrwxrwx 1 kratsg atlas   25 Jun 28 16:13 libXrdCryptoLite.so.1 ->
> libXrdCryptoLite.so.1.0.0
> -rwxr-xr-x 2 kratsg atlas 5.9K Jun 28 16:13 libXrdCryptoLite.so.1.0.0
> lrwxrwxrwx 1 kratsg atlas   21 Jun 28 16:13 libXrdCrypto.so.1 ->
> libXrdCrypto.so.1.0.0
> -rwxr-xr-x 2 kratsg atlas  95K Jun 28 16:13 libXrdCrypto.so.1.0.0
> lrwxrwxrwx 1 kratsg atlas   14 Jun 28 16:13 libXrdFfs.so -> libXrdFfs.so.2
> lrwxrwxrwx 1 kratsg atlas   18 Jun 28 16:13 libXrdFfs.so.2 ->
> libXrdFfs.so.2.0.0
> -rwxr-xr-x 2 kratsg atlas  47K Jun 28 16:13 libXrdFfs.so.2.0.0
> -rwxr-xr-x 2 kratsg atlas 156K Jun 28 16:13 libXrdFileCache-4.so
> -rwxr-xr-x 2 kratsg atlas  15K Jun 28 16:13 libXrdN2No2p-4.so
> -rwxr-xr-x 2 kratsg atlas  11K Jun 28 16:13 libXrdOssSIgpfsT-4.so
> lrwxrwxrwx 1 kratsg atlas   16 Jun 28 16:13 libXrdPosix.so ->
> libXrdPosix.so.2
> lrwxrwxrwx 1 kratsg atlas   23 Jun 28 16:13 libXrdPosixPreload.so ->
> libXrdPosixPreload.so.1
> lrwxrwxrwx 1 kratsg atlas   27 Jun 28 16:13 libXrdPosixPreload.so.1 ->
> libXrdPosixPreload.so.1.0.0
> -rwxr-xr-x 2 kratsg atlas  67K Jun 28 16:13 libXrdPosixPreload.so.1.0.0
> lrwxrwxrwx 1 kratsg atlas   20 Jun 28 16:13 libXrdPosix.so.2 ->
> libXrdPosix.so.2.0.0
> -rwxr-xr-x 2 kratsg atlas 128K Jun 28 16:13 libXrdPosix.so.2.0.0
> -rwxr-xr-x 2 kratsg atlas  56K Jun 28 16:13 libXrdPss-4.so
> -rwxr-xr-x 2 kratsg atlas  19K Jun 28 16:13 libXrdSecProt-4.so
> -rwxr-xr-x 2 kratsg atlas 112K Jun 28 16:13 libXrdSecpwd-4.so
> -rwxr-xr-x 2 kratsg atlas  35K Jun 28 16:13 libXrdSecsss-4.so
> -rwxr-xr-x 2 kratsg atlas  15K Jun 28 16:13 libXrdSecunix-4.so
> -rwxr-xr-x 2 kratsg atlas  52K Jun 28 16:13 libXrdSec-4.so
> lrwxrwxrwx 1 kratsg atlas   17 Jun 28 16:13 libXrdServer.so ->
> libXrdServer.so.2
> lrwxrwxrwx 1 kratsg atlas   21 Jun 28 16:13 libXrdServer.so.2 ->
> libXrdServer.so.2.0.0
> -rwxr-xr-x 2 kratsg atlas 764K Jun 28 16:13 libXrdServer.so.2.0.0
> lrwxrwxrwx 1 kratsg atlas   17 Jun 28 16:13 libXrdSsiLib.so ->
> libXrdSsiLib.so.1
> lrwxrwxrwx 1 kratsg atlas   21 Jun 28 16:13 libXrdSsiLib.so.1 ->
> libXrdSsiLib.so.1.0.0
> -rwxr-xr-x 2 kratsg atlas 108K Jun 28 16:13 libXrdSsiLib.so.1.0.0
> -rwxr-xr-x 2 kratsg atlas  15K Jun 28 16:13 libXrdSsiLog-4.so
> lrwxrwxrwx 1 kratsg atlas   19 Jun 28 16:13 libXrdSsiShMap.so ->
> libXrdSsiShMap.so.1
> lrwxrwxrwx 1 kratsg atlas   23 Jun 28 16:13 libXrdSsiShMap.so.1 ->
> libXrdSsiShMap.so.1.0.0
> -rwxr-xr-x 2 kratsg atlas  31K Jun 28 16:13 libXrdSsiShMap.so.1.0.0
> -rwxr-xr-x 2 kratsg atlas 100K Jun 28 16:13 libXrdSsi-4.so
> -rwxr-xr-x 2 kratsg atlas  47K Jun 28 16:13 libXrdThrottle-4.so
> lrwxrwxrwx 1 kratsg atlas   16 Jun 28 16:13 libXrdUtils.so ->
> libXrdUtils.so.2
> lrwxrwxrwx 1 kratsg atlas   20 Jun 28 16:13 libXrdUtils.so.2 ->
> libXrdUtils.so.2.0.0
> -rwxr-xr-x 2 kratsg atlas 589K Jun 28 16:13 libXrdUtils.so.2.0.0
> lrwxrwxrwx 1 kratsg atlas   14 Jun 28 16:13 libXrdXml.so -> libXrdXml.so.2
> lrwxrwxrwx 1 kratsg atlas   18 Jun 28 16:13 libXrdXml.so.2 ->
> libXrdXml.so.2.0.0
> -rwxr-xr-x 2 kratsg atlas  88K Jun 28 16:13 libXrdXml.so.2.0.0
> -rwxr-xr-x 2 kratsg atlas  11K Jun 28 16:13 libXrdXrootd-4.so
>
>
> According to the docs, there is a CMAKE_INSTALL_PREFIX I can configure:
>
>   * CMAKE_INSTALL_PREFIX - indicates where the XRootD files should be
> installed,
>(default: /usr)
>
> and this might let me set the install prefix to something custom, move those
> files into the package, and 

Re: [yocto] struggling with initramfs

[Andre McCurdy]

On Wed, Jul 4, 2018 at 11:23 PM, Zoran Stojsavljevic
 wrote:
> Hello to all,
>
> I have my own YOCTO recipe how I do the initramfs.
>
> Usually, some of these are missing in kernel .config file:
>
> CONFIG_BLK_DEV_INITRD=y
> CONFIG_RD_GZIP=y
> CONFIG_RD_BZIP2=y
> CONFIG_RD_LZMA=y
> CONFIG_RD_XZ=y
> CONFIG_RD_LZO=y
> CONFIG_RD_LZ4=y
>
> Please, check (they should be on) the CONFIG_DECOMPRESS_* options and if
> not, please, turn them on.
>
> To do this, please, for YOCTO use the following (to reconfigure kernel
> .config):
> bitbake -c menuconfig virtual/kernel
>
> Also, in the local.conf I have the following set:
>
> DISTRO_FEATURES_append = " ram"

There is no standard distro feature called "ram". Perhaps this is
something specific to your BSP layer?

> IMAGE_FSTYPES_append = " cpio.xz"
>
> Then I do: bitbake -k core-image-minimal, and from:
> .../build/tmp/tmp/deploy/images/
>
> Take my .cpio.xz as initramfs. Also, I take accordingly
> zImage and .dtb files as well.
>
> I prepend to initramfs.cpio.xz u-boot header:
> mkimage -n 'Ramdisk Image'  -A arm -O linux -T ramdisk -C gzip -d
> initramfs.cpio.xz initramfs.cpio.xz.uboot
>
> And then write tiny U-Boot ash script to tftp (from host) all three files to
> the target platform.

This advice and these instructions are all fine. However, just for the
record, creating a standalone cpio archive and arranging for the
bootloader to load the kernel and cpio archive into DRAM as separate
images before booting the kernel is not solving the same problem as
embedding a cpio archive inside the kernel image via OE's
INITRAMFS_IMAGE_BUNDLE option.

> On Wed, Jul 4, 2018 at 8:57 PM, Ferry Toth  wrote:
>>
>> Tim Hammer wrote:
>>
>> > Can anyone point me to a step-by-step tutorial or simple how-to on
>> > creating and using an initramfs with my kernel for ARM aarch64?
>> >
>> >
>> > I have tried creating my own:
>> >  - boot-image.bb file with IMAGE_FSTYPES = "cpio.gz".
>> >  - local.conf has INITRAMFS_IMAGE_BUNDLE = "1"
>> >  - linux.bbappend has INITRAMFS_IMAGE = "boot-image"
>> >
>> > This all seems to be "correct" to the extent that bitbake linux tries to
>> > do the right thing.
>> >
>> > However, I get a failure in do_bundle_initramfs- "mv: cannot stat
>> > 'arch/arm64/boot/Image': No such file or directory".
>> >
>> > To the best of my (limited) debugging abilities with Yocto, it seems
>> > like
>> > the kernel image backup has already been run when it gets to this point
>> > and the Image file in that directory has already been moved to
>> > Image.bak.
>> > If I comment out the mv statement in kernel.bbclass causing the failure,
>> > the process continues, but the initramfs does not seem to get populated
>> > or
>> > perhaps installed into my kernel image as I get kernel panics that I
>> > have
>> > been unable to get past.
>> >
>> >
>> > I decided to take a different approach and try using the
>> > core-image-minimal-initramfs recipe as INITRAMFS_IMAGE. By commenting
>> > out
>> > the COMPATIBLE_HOST entry I am able to build a kernel for ARM aarch64. I
>> > can even seem to boot into this initramfs- it counts down waiting for
>> > removable media; seems to find my primary rootfs on sda3, but there is
>> > no
>> > rootfs.img file there so says it is dropping to a shell (although I
>> > never
>> > get a prompt...).
>>
>> We have taken this approach here
>>
>> https://github.com/edison-fw/meta-intel-edison/tree/master/meta-intel-edison-distro/recipes-core
>>
>> There are 2 images, the rootfs and the initramfs. And we overload the
>> init-live.sh
>> to load certain kernel modules and acpi-tables then switchroot to the
>> rootfs.
>>
>> > Thinking I could start with that recipe and work to get rid of the live
>> > stuff and just get to a busybox prompt before trying to run my unique
>> > init
>> > commands, I copied  core-image-minimal-initramfs.bb to my-
>> > core-image-minimal-initramfs.bb in my layer and changed INITRAMFS_IMAGE
>> > to
>> > "my- core-image-minimal-initramfs".
>> > However, I obviously missed something in the configuration as I get an
>> > error in go_bundle_initramfs again:
>> >  kernel-source/scripts/gen_initramfs_list.sh:
>> >  Cannot open
>> >
>> > '/.../linux-qoriq/4.14-r0/build/usr/my-core-image-minimal-initramfs-{machine}.cpio'
>> >
>> > Any help would be greatly appreciated.
>> > Thank you!
>>
>>
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] struggling with initramfs

[Andre McCurdy]

On Tue, Jul 3, 2018 at 11:02 AM, Tim Hammer  wrote:
>
> Can anyone point me to a step-by-step tutorial or simple how-to on creating
> and using an initramfs with my kernel for ARM aarch64?
>
> I have tried creating my own:
>  - boot-image.bb file with IMAGE_FSTYPES = "cpio.gz".

Note that the approach taken by kernel.bbclass is that the cpio image
is included uncompressed in the kernel and then (if you build a
compressed kernel image type) the kernel and cpio are compressed
together. What you've done is OK, but just be aware that
copy_initramfs() will uncompress the cpio image for you before it's
included in the kernel.

(If you want a compressed cpio image inside an uncompressed kernel
then kernel.bbclass would need some patching).

>  - local.conf has INITRAMFS_IMAGE_BUNDLE = "1"
>  - linux.bbappend has INITRAMFS_IMAGE = "boot-image"

Is your kernel recipe called linux? If not then the .bbappend might
not be applied when your actual kernel recipe is built. It doesn't
look like that's your issue as the error below from
do_bundle_initramfs() suggests that you got past the check that both
INITRAMFS_IMAGE and INITRAMFS_IMAGE_BUNDLE are as expected, but In
general it's probably safest to keep INITRAMFS_IMAGE_BUNDLE and
INITRAMFS_IMAGE together in a global config file (e.g. local.conf)
rather than making either of them recipe specific.

> This all seems to be "correct" to the extent that bitbake linux tries to do
> the right thing.
>
> However, I get a failure in do_bundle_initramfs- "mv: cannot stat
> 'arch/arm64/boot/Image': No such file or directory".

You don't mention what version of OE you are using? The
do_bundle_initramfs() code has historically been quite fragile,
especially around the time support for multiple kernel image types was
merged a year or two back. Everything should be OK now and fixes
should have been backported to releases, but if you're using an older
release there could be a fix which didn't make it.

Are you manually over-riding KERNEL_OUTPUT_DIR? How are you setting
KERNEL_IMAGETYPE, KERNEL_ALT_IMAGETYPE, KERNEL_IMAGETYPES and
KERNEL_IMAGETYPE_FOR_MAKE?

Note that setting a kernel image type of "Image.gz" didn't work until
relatively recently. I'm not sure how far that fix got backported (if
at all).

> To the best of my (limited) debugging abilities with Yocto, it seems like
> the kernel image backup has already been run when it gets to this point and
> the Image file in that directory has already been moved to Image.bak. If I
> comment out the mv statement in kernel.bbclass causing the failure, the
> process continues, but the initramfs does not seem to get populated or
> perhaps installed into my kernel image as I get kernel panics that I have
> been unable to get past.

The error is odd as the mv commands in do_bundle_initramfs() are only
run to backup kernel images (or symlinks to images) as
do_bundle_initramfs() finds them, or to rename a kernel image after a
call to kernel_do_compile() to create it.

You don't mention specifically which mv command in
do_bundle_initramfs() is failing. If it's after the call to
kernel_do_compile() then it suggests that kernel_do_compile() isn't
creating the expected kernel image (or isn't creating it in the
expected directory).

If you add a few "ls" commands to do_bundle_initramfs() it should be
fairly easy to see where files are (and whether or not they are
symlinks) before and after the call to kernel_do_compile() from the
do_bundle_initramfs() log.

> I decided to take a different approach and try using the
> core-image-minimal-initramfs recipe as INITRAMFS_IMAGE. By commenting out
> the COMPATIBLE_HOST entry I am able to build a kernel for ARM aarch64. I can
> even seem to boot into this initramfs- it counts down waiting for removable
> media; seems to find my primary rootfs on sda3, but there is no rootfs.img
> file there so says it is dropping to a shell (although I never get a
> prompt...).
>
> Thinking I could start with that recipe and work to get rid of the live
> stuff and just get to a busybox prompt before trying to run my unique init
> commands, I copied  core-image-minimal-initramfs.bb to my-
> core-image-minimal-initramfs.bb in my layer and changed INITRAMFS_IMAGE to
> "my- core-image-minimal-initramfs".
> However, I obviously missed something in the configuration as I get an error
> in go_bundle_initramfs again:
>  kernel-source/scripts/gen_initramfs_list.sh:
>  Cannot open
> '/.../linux-qoriq/4.14-r0/build/usr/my-core-image-minimal-initramfs-{machine}.cpio'
>
> Any help would be greatly appreciated.
> Thank you!
> --
>
> .Tim
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Understanding "dev package contains non-symlink"

[Andre McCurdy]

On Thu, Jun 28, 2018 at 3:53 PM, Burton, Ross  wrote:
> Hi Giordan,
>
> https://wiki.yoctoproject.org/wiki/TipsAndTricks/Packaging_Prebuilt_Libraries
> might be helpful to you.
>
> One useful thing would be to show us exactly what files are being
> installed (and what files are symlinks).  It sounds like xrootd is
> messing up library installation...

Based on the logs, it looks like xrootd is installing both versioned
shared libraries (e.g. "libXrdXml.so" is presumably a symlink to a
real library named libXrdXml.so. ?) and it's ALSO
installing a set of plug-ins (e.g. "libXrdThrottle-4.so").

If so, then the real problem seems to be that the plug-ins are being
installed in /usr/lib. To avoid tripping up the default packaging
rules and QA tests, plug-ins should ideally be installed somewhere
other than ${base_libdir} or ${libdir}.

If you can fix the build so that the plug-ins (just the plug-ins, not
the versioned shared libraries) get installed to a different directory
then I guess you will be able remove the packaging rules over-rides
and the QA errors will go away.

If you can't fix the build to install the plug-ins in another
directory, then you could keep the packaging rules over-rides that you
have already and just ignore the "dev-so" QA test (unlike the
"dev-elf" QA test, which you should never ignore, the consequences of
ignoring the "dev-so" QA test are fairly benign - you will end up with
.so symlinks in the run-time package, which doesn't do any real harm).

> On 28 June 2018 at 22:19, Giordon Stark  wrote:
>> Hi,
>>
>> I've read the emails in this mailing list. I'm mostly struggling to
>> understand the situation for which "-dev package contains non-symlink .so"
>> occurs. I understand that normally, one expects "*.so" files installed as
>> part of the package, with symlinks to these versions in the "-dev" package.
>> What I don't understand is the fix, and why this problem occurs in the first
>> place.
>>
>> The recipe I'm working on in question is here: xrootd_4.8.3.bb (if this link
>> doesn't work in the future, it's probably because I've merged this to
>> master). This recipe is to install this piece of code:
>> https://github.com/xrootd/xrootd.
>>
>> Here's an example of the errors:
>>
>> ERROR: xrootd-4.8.3-r0 do_package_qa: QA Issue: -dev package contains
>> non-symlink .so: xrootd-dev path
>> '/work/aarch64-poky-linux/xrootd/4.8.3-r0/packages-split/xrootd-dev/usr/lib/libXrdThrottle-4.so'
>> -dev package contains non-symlink .so: xrootd-dev path
>> '/work/aarch64-poky-linux/xrootd/4.8.3-r0/packages-split/xrootd-dev/usr/lib/libXrdSecsss-4.so'
>> -dev package contains non-symlink .so: xrootd-dev path
>> '/work/aarch64-poky-linux/xrootd/4.8.3-r0/packages-split/xrootd-dev/usr/lib/libXrdSecunix-4.so'
>> -dev package contains non-symlink .so: xrootd-dev path
>> '/work/aarch64-poky-linux/xrootd/4.8.3-r0/packages-split/xrootd-dev/usr/lib/libXrdSecpwd-4.so'
>> -dev package contains non-symlink .so: xrootd-dev path
>> '/work/aarch64-poky-linux/xrootd/4.8.3-r0/packages-split/xrootd-dev/usr/lib/libXrdN2No2p-4.so'
>> -dev package contains non-symlink .so: xrootd-dev path
>> '/work/aarch64-poky-linux/xrootd/4.8.3-r0/packages-split/xrootd-dev/usr/lib/libXrdSec-4.so'
>> -dev package contains non-symlink .so: xrootd-dev path
>> '/work/aarch64-poky-linux/xrootd/4.8.3-r0/packages-split/xrootd-dev/usr/lib/libXrdFileCache-4.so'
>> -dev package contains non-symlink .so: xrootd-dev path
>> '/work/aarch64-poky-linux/xrootd/4.8.3-r0/packages-split/xrootd-dev/usr/lib/libXrdSsiLog-4.so'
>> -dev package contains non-symlink .so: xrootd-dev path
>> '/work/aarch64-poky-linux/xrootd/4.8.3-r0/packages-split/xrootd-dev/usr/lib/libXrdCksCalczcrc32-4.so'
>> -dev package contains non-symlink .so: xrootd-dev path
>> '/work/aarch64-poky-linux/xrootd/4.8.3-r0/packages-split/xrootd-dev/usr/lib/libXrdBwm-4.so'
>> -dev package contains non-symlink .so: xrootd-dev path
>> '/work/aarch64-poky-linux/xrootd/4.8.3-r0/packages-split/xrootd-dev/usr/lib/libXrdBlacklistDecision-4.so'
>> -dev package contains non-symlink .so: xrootd-dev path
>> '/work/aarch64-poky-linux/xrootd/4.8.3-r0/packages-split/xrootd-dev/usr/lib/libXrdClProxyPlugin-4.so'
>> -dev package contains non-symlink .so: xrootd-dev path
>> '/work/aarch64-poky-linux/xrootd/4.8.3-r0/packages-split/xrootd-dev/usr/lib/libXrdSecProt-4.so'
>> -dev package contains non-symlink .so: xrootd-dev path
>> '/work/aarch64-poky-linux/xrootd/4.8.3-r0/packages-split/xrootd-dev/usr/lib/libXrdOssSIgpfsT-4.so'
>> -dev package contains non-symlink .so: xrootd-dev path
>> '/work/aarch64-poky-linux/xrootd/4.8.3-r0/packages-split/xrootd-dev/usr/lib/libXrdSsi-4.so'
>> -dev package contains non-symlink .so: xrootd-dev path
>> '/work/aarch64-poky-linux/xrootd/4.8.3-r0/packages-split/xrootd-dev/usr/lib/libXrdPss-4.so'
>> -dev package contains non-symlink .so: xrootd-dev path
>> '/work/aarch64-poky-linux/xrootd/4.8.3-r0/packages-split/xrootd-dev/usr/lib/libXrdXrootd-4.so'
>> [dev-elf]
>> ERROR: 

Re: [yocto] Yocto not fetching unzip

[Andre McCurdy]

On Mon, Jun 11, 2018 at 6:33 AM, Maas, Jonas  wrote:
> Hello everyone,
>
> I am experiencing an issue with yocto-2.1.2:
>
> I am trying to prefetch all needed sources for a certain image, let’s say
> “my-image”, by calling:
>
> $ bitbake -c fetchall my-image
>
> Next I am archiving the whole Yocto system (including the downloads
> directory) to a tar.gz file and unpack it on another system.
>
> Now when I set BB_NO_NETWORK=”1” in the local.conf and try to build using
>
> $ bitbake my-image
>
> the package “unzip” is missing. I can fetch it manually by temporarily
> switching to online build an calling
>
> $ bitbake -c fetch unzip
>
> However I want to be able to build completely from the generated tar.gz.
>
> Is this a bug in Yocto or intended behavior? If it is intended: Is there a
> proper setting to solve this or do I have to fetch unzip manually bevor
> packing the archive?

You don't mention how you are using unzip.

If you are including unzip in your image then failing to download it
during fetchall is unexpected and sounds like a bug.

If you're not including unzip in your image but instead your build
actually depends on unzip-native (ie a tool to run on the host and
needed as a build dependency if a recipe you build contains .zip or
.jar files in SRC_URI) then I'm not sure what the expectation is. If
fetchall doesn't download these indirect -native dependencies then it
might just be the way it is. If so, then manually running "bitbake -c
fetch unzip-native" might be an appropriate solution.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How handle files needing updates in read-only filesystem

[Andre McCurdy]

On Wed, Jun 13, 2018 at 9:28 AM, Ulf Samuelsson  wrote:
> Thanks, is it more efficient than symlinking?

Efficient in what way?

Have you looked at the volatile-binds recipe in oe-core? Its job is to
setup enough bind mounts to enable systemd to run from a readonly
rootfs. Although it's currently systemd specific (it only provides a
systemd service file, no init script) it might give you some clues
about how to setup bind mounts at boot time.

> Best Regards,
> Ulf Samuelsson
>
>> 13 juni 2018 kl. 15:20 skrev Anders Darander :
>>
>> * Ulf Samuelsson  [180612 22:01]:
>>
>>> We want most of /etc to be read-only for security reasons,
>>> and the overlayfs will make the whole of /etc writeable.
>>
>>> I tried mount —bind /etc/timezone /persistent/etc/timezone, and it
>>> complained that they were not directories. Bind mounting /etc again
>>> will make all of /etc writeable.
>>
>> Try to use: mount —o bind /etc/timezone /persistent/etc/timezone
>>
>> I'm using that heavily, either manually or by the volatile-binds recipe.
>> It works perfectly fine with files.
>>
>>> Symlinking to /persistent is fine, so the question is what an
>>> acceptable method is to have a simple way of ensuring that a certain
>>> file is converted to that symlink.
>>
>> This is normally done by a manual inspection / addition of bbappend
>> file.
>>
>> Cheers,
>> Anders
>> --
>> Anders Darander, Senior System Architect
>> ChargeStorm AB / eStorm AB
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] sysroot not being populated

[Andre McCurdy]

On Fri, Jun 8, 2018 at 2:42 AM, Patrick Vacek  wrote:
> On 08.06.2018 10:26, Khem Raj wrote:
>> On 6/8/18 12:27 AM, Patrick Vacek wrote:
>>> On 07.06.2018 19:06, Khem Raj wrote:
 Hi Patrick

 On Mon, Jun 4, 2018 at 2:01 AM, Patrick Vacek
  wrote:
> Hello all,
>
> I have a recipe (aktualizr-hsm-prov) that depends on another
> (aktualizr)
> to provide an executable and a config file. The former recipe includes
> `DEPENDS = "aktualizr-native"`, and my do_install() for
> aktualizr-hsm-prov has a line something like this:
>
> aktualizr -i ${STAGING_DIR_NATIVE}${libdir}/sota.conf
>
> The binary executable (aktualizr) runs, which tells me that the recipe
> can find that. (Although to be honest, I'm not sure which version
> it is
> running.) However, it doesn't find the config file, and sure enough,
> ${STAGING_DIR_NATIVE}${libdir} does not have the config file I
> expect. I
> can see that aktualizr-native is populating its sysroot-destdir,
> but it
> isn't getting copied to the sysroot for aktualizr-hsm-prov.
>
> I see this problem in sumo and master, although previously this logic
> has worked just fine in morty/pyro/rocko.
>
> Switching to depending on aktualizr (instead of aktualizr-native) and
> using STAGING_DIR_HOST or STAGING_DIR_TARGET does not help, and in
> fact
> makes it worse, as it can't even find the aktualizr executable in
> that case.
>
> What am I doing wrong? What changed between rocko and sumo?
 is aktualizr recipe installing this .conf file when building native
 version. If not may be
 add it to do_install

 install -D -m 0644  ${D}${libdir}/sota.conf
>>>
>>> Hello Khem,
>>>
>>> I believe so. The aktualizr recipe includes the following (edited for
>>> simplicity):
>>>
>>> BBCLASSEXTEND =+ "native"
>>>
>>> do_install_append () {
>>>  install -m 0644 ${S}/config/sota.conf ${D}/${libdir}/sota.conf
>>> }
>>>
>>> PACKAGES =+ " ${PN}-host-tools "
>>>
>>> FILES_${PN}-host-tools = " ${libdir}/sota.conf "
>>>
>>
>> Can you check location of sota.conf in the build tree for
>> aktualizr-native in directory called package/
> Oddly, I do not see a package subdirectory inside the aktualizr-native
> directory in the build tree. I do see it inside the aktualizr directory,
> though, and it contains everything that I would expect. Is there some
> sort of configuration of the packaging system for a native recipe that I
> haven't done correctly?

No, what you see is expected - there's no packaging for -native recipes.

Back to the original problem, I think you should consider the
aktualizr executable and the sota.conf file as two separate things.
The host executable should always be provided by aktualizr-native.
It's less clear what should provide sota.conf - it depends whether
it's just required for building other recipes (ie like a header file)
or whether it needs to be present in the final rootfs? If it's only
required for building other packages, then it should be in the -dev
package for aktualizr. If it needs to be present in the final rootfs
then it should be in the default package for aktualizr. Either way,
recipes which need to find sota.conf in sysroot would then depend on
"aktualizr". Therefore recipes which need both the host executable and
sota.conf in sysroot should depend on both aktualizr and
aktualizr-native.

> For the record, here is the actual recipe:
> https://github.com/advancedtelematic/meta-updater/blob/master/recipes-sota/aktualizr/aktualizr_git.bb
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Where to make image dependent kernel changes while hardware stays same

[Andre McCurdy]

On Wed, Jun 6, 2018 at 9:03 AM, Jakob Hasse  wrote:
> Hello,
>
> we would like to have different images with different kernel configs/device
> trees. E.g., we would like to have systemA with uart2 and systemB without
> uart2 but spi1 instead, with all the different configurations and device
> trees. The hardware does not change in this case.
>
> How can I make such kernel changes depending on the currently used image?

You can't. The kernel build can be influenced by global config files
such as the distro config, the machine config, local.conf, etc, but
it's not influenced by the image you choose to build.

> My first trail was  to make different machine configs anyway although
> technically the hardware doesn't change.

That's OK. There's no rule that says machine config files can only
contain HW related options. You can think of the machine config files
as just being a place to put global build configuration which is one
level below the distro configuration.

> Then I can append different kernel
> configs in the kernel recipe like this:
> SRC_URI_append_systemA = " file://defconfig"
> SRC_URI_append_systemB = " file://defconfig"
> ...with the corresponding defconfigs in their machine specific subdir.

Putting the machine specific defconfig files into machine specific
subdirectories is enough - you don't need to use machine specific
appends to SRC_URI. For reference, see "log.do_patch" in the kernel
working directory to see the file search paths. The machine specific
paths will be checked first for every file in SRC_URI automatically.

> But maybe there is a better way to reflect these kind of changes?

There are other ways, but the way you have chosen is a good one.

>
> All the Best,
> Jakob
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] [RFT] GCC 8.1

[Andre McCurdy]

On Thu, May 10, 2018 at 6:16 PM, Khem Raj <raj.k...@gmail.com> wrote:
> On Thu, May 10, 2018 at 6:11 PM, Andre McCurdy <armccu...@gmail.com> wrote:
>> On Thu, May 10, 2018 at 6:06 PM, Khem Raj <raj.k...@gmail.com> wrote:
>>> On Thu, May 10, 2018 at 6:00 PM, Andre McCurdy <armccu...@gmail.com> wrote:
>>>> On Thu, May 10, 2018 at 5:55 PM, Khem Raj <raj.k...@gmail.com> wrote:
>>>>> On Thu, May 10, 2018 at 4:11 PM, Andre McCurdy <armccu...@gmail.com> 
>>>>> wrote:
>>>>>> On Thu, May 10, 2018 at 3:50 PM, Martin Jansa <martin.ja...@gmail.com> 
>>>>>> wrote:
>>>>>>> On Thu, May 10, 2018 at 03:40:53PM -0700, Andre McCurdy wrote:
>>>>>>>> On Thu, May 10, 2018 at 3:38 PM, Martin Jansa <martin.ja...@gmail.com> 
>>>>>>>> wrote:
>>>>>>>> > see
>>>>>>>> > http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html
>>>>>>>>
>>>>>>>> Removing -fno-omit-frame-pointer isn't the same as adding
>>>>>>>> -fomit-frame-pointer. Frame pointers may get enabled depending on the
>>>>>>>> optimisation level etc (ie not only by -fno-omit-frame-pointer).
>>>>>>>
>>>>>>> Should I send v2 adding -fomit-frame-pointer instead of removing
>>>>>>> -fno-omit-frame-pointer?
>>>>>>>
>>>>>>> The v1 fixes the issue for me with default config + DEBUG_BUILD.
>>>>>>
>>>>>> The v1 patch isn't wrong, it's just incomplete (the problem could come
>>>>>> back if someone changes optimisation level or switches gcc to clang,
>>>>>> etc).
>>>>>>
>>>>>> My choice would be a v2 patch which adds -fomit-frame-pointer to
>>>>>> CFLAGS unconditionally for all ARM builds when Thumb is enabled. That
>>>>>> should fix the problem for all optimisation levels etc and avoids
>>>>>> building the main strace binary differently depending on whether or
>>>>>> not ptest is enabled.
>>>>>
>>>>> explicitly adding this option is a poor choice especially for debug
>>>>> builds where we should
>>>>> let the -On level decide and not explicitly ask for either
>>>>> enable/disable frame-pointers
>>>>> that will also make it compiler proof.
>>>>
>>>> Of course, we should let the compiler decide whenever it's possible to do 
>>>> so.
>>>>
>>>> Unfortunately there are cases like this one where frame pointers clash
>>>> with inline assembler and we need to over-rule the compiler's choice.
>>>
>>> Here we are adding -fno-omit-frame-pointer via global opt flags that
>>> is the issue
>>> where we have fallouts from default O options I agree we should teach
>>> this to build
>>> system and help the compiler
>>
>> Since there's NO situation where enabling frame pointers is going to
>> work for this code + ARM + Thumb, I don't see the advantage of leaving
>> anything up to chance. Just explicitly disabling frame pointers is the
>> safest and cleanest option.
>
> In that case what we are saying is that strace has wrong assumptions
> I would think its best to change strace build system to demand this
> option override instead of injecting it externally.

There are many possible / better fixes if we want to patch the strace
sources or Makefiles. I'm not sure if Martin was signing up for that
though :-)
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] [RFT] GCC 8.1

[Andre McCurdy]

On Thu, May 10, 2018 at 6:06 PM, Khem Raj <raj.k...@gmail.com> wrote:
> On Thu, May 10, 2018 at 6:00 PM, Andre McCurdy <armccu...@gmail.com> wrote:
>> On Thu, May 10, 2018 at 5:55 PM, Khem Raj <raj.k...@gmail.com> wrote:
>>> On Thu, May 10, 2018 at 4:11 PM, Andre McCurdy <armccu...@gmail.com> wrote:
>>>> On Thu, May 10, 2018 at 3:50 PM, Martin Jansa <martin.ja...@gmail.com> 
>>>> wrote:
>>>>> On Thu, May 10, 2018 at 03:40:53PM -0700, Andre McCurdy wrote:
>>>>>> On Thu, May 10, 2018 at 3:38 PM, Martin Jansa <martin.ja...@gmail.com> 
>>>>>> wrote:
>>>>>> > see
>>>>>> > http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html
>>>>>>
>>>>>> Removing -fno-omit-frame-pointer isn't the same as adding
>>>>>> -fomit-frame-pointer. Frame pointers may get enabled depending on the
>>>>>> optimisation level etc (ie not only by -fno-omit-frame-pointer).
>>>>>
>>>>> Should I send v2 adding -fomit-frame-pointer instead of removing
>>>>> -fno-omit-frame-pointer?
>>>>>
>>>>> The v1 fixes the issue for me with default config + DEBUG_BUILD.
>>>>
>>>> The v1 patch isn't wrong, it's just incomplete (the problem could come
>>>> back if someone changes optimisation level or switches gcc to clang,
>>>> etc).
>>>>
>>>> My choice would be a v2 patch which adds -fomit-frame-pointer to
>>>> CFLAGS unconditionally for all ARM builds when Thumb is enabled. That
>>>> should fix the problem for all optimisation levels etc and avoids
>>>> building the main strace binary differently depending on whether or
>>>> not ptest is enabled.
>>>
>>> explicitly adding this option is a poor choice especially for debug
>>> builds where we should
>>> let the -On level decide and not explicitly ask for either
>>> enable/disable frame-pointers
>>> that will also make it compiler proof.
>>
>> Of course, we should let the compiler decide whenever it's possible to do so.
>>
>> Unfortunately there are cases like this one where frame pointers clash
>> with inline assembler and we need to over-rule the compiler's choice.
>
> Here we are adding -fno-omit-frame-pointer via global opt flags that
> is the issue
> where we have fallouts from default O options I agree we should teach
> this to build
> system and help the compiler

Since there's NO situation where enabling frame pointers is going to
work for this code + ARM + Thumb, I don't see the advantage of leaving
anything up to chance. Just explicitly disabling frame pointers is the
safest and cleanest option.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] [RFT] GCC 8.1

[Andre McCurdy]

On Thu, May 10, 2018 at 5:55 PM, Khem Raj <raj.k...@gmail.com> wrote:
> On Thu, May 10, 2018 at 4:11 PM, Andre McCurdy <armccu...@gmail.com> wrote:
>> On Thu, May 10, 2018 at 3:50 PM, Martin Jansa <martin.ja...@gmail.com> wrote:
>>> On Thu, May 10, 2018 at 03:40:53PM -0700, Andre McCurdy wrote:
>>>> On Thu, May 10, 2018 at 3:38 PM, Martin Jansa <martin.ja...@gmail.com> 
>>>> wrote:
>>>> > see
>>>> > http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html
>>>>
>>>> Removing -fno-omit-frame-pointer isn't the same as adding
>>>> -fomit-frame-pointer. Frame pointers may get enabled depending on the
>>>> optimisation level etc (ie not only by -fno-omit-frame-pointer).
>>>
>>> Should I send v2 adding -fomit-frame-pointer instead of removing
>>> -fno-omit-frame-pointer?
>>>
>>> The v1 fixes the issue for me with default config + DEBUG_BUILD.
>>
>> The v1 patch isn't wrong, it's just incomplete (the problem could come
>> back if someone changes optimisation level or switches gcc to clang,
>> etc).
>>
>> My choice would be a v2 patch which adds -fomit-frame-pointer to
>> CFLAGS unconditionally for all ARM builds when Thumb is enabled. That
>> should fix the problem for all optimisation levels etc and avoids
>> building the main strace binary differently depending on whether or
>> not ptest is enabled.
>
> explicitly adding this option is a poor choice especially for debug
> builds where we should
> let the -On level decide and not explicitly ask for either
> enable/disable frame-pointers
> that will also make it compiler proof.

Of course, we should let the compiler decide whenever it's possible to do so.

Unfortunately there are cases like this one where frame pointers clash
with inline assembler and we need to over-rule the compiler's choice.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] [RFT] GCC 8.1

[Andre McCurdy]

On Thu, May 10, 2018 at 4:32 PM, Martin Jansa <martin.ja...@gmail.com> wrote:
> On Thu, May 10, 2018 at 04:11:00PM -0700, Andre McCurdy wrote:
>> On Thu, May 10, 2018 at 3:50 PM, Martin Jansa <martin.ja...@gmail.com> wrote:
>> > On Thu, May 10, 2018 at 03:40:53PM -0700, Andre McCurdy wrote:
>> >> On Thu, May 10, 2018 at 3:38 PM, Martin Jansa <martin.ja...@gmail.com> 
>> >> wrote:
>> >> > see
>> >> > http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html
>> >>
>> >> Removing -fno-omit-frame-pointer isn't the same as adding
>> >> -fomit-frame-pointer. Frame pointers may get enabled depending on the
>> >> optimisation level etc (ie not only by -fno-omit-frame-pointer).
>> >
>> > Should I send v2 adding -fomit-frame-pointer instead of removing
>> > -fno-omit-frame-pointer?
>> >
>> > The v1 fixes the issue for me with default config + DEBUG_BUILD.
>>
>> The v1 patch isn't wrong, it's just incomplete (the problem could come
>> back if someone changes optimisation level or switches gcc to clang,
>> etc).
>>
>> My choice would be a v2 patch which adds -fomit-frame-pointer to
>> CFLAGS unconditionally for all ARM builds when Thumb is enabled. That
>> should fix the problem for all optimisation levels etc and avoids
>> building the main strace binary differently depending on whether or
>> not ptest is enabled.
>
> Only for thumb? makes me a bit sad that thumb override was dropped by
> you in
> 351443d71eb246a946b41f12b54d57b36fe1574e

No need for a thumb over-ride. You can copy and paste from the musl recipe:

CFLAGS_append_arm = " ${@bb.utils.contains('TUNE_CCARGS', '-mthumb',
'-fomit-frame-pointer', '', d)}"
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] [RFT] GCC 8.1

[Andre McCurdy]

On Thu, May 10, 2018 at 3:50 PM, Martin Jansa <martin.ja...@gmail.com> wrote:
> On Thu, May 10, 2018 at 03:40:53PM -0700, Andre McCurdy wrote:
>> On Thu, May 10, 2018 at 3:38 PM, Martin Jansa <martin.ja...@gmail.com> wrote:
>> > see
>> > http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html
>>
>> Removing -fno-omit-frame-pointer isn't the same as adding
>> -fomit-frame-pointer. Frame pointers may get enabled depending on the
>> optimisation level etc (ie not only by -fno-omit-frame-pointer).
>
> Should I send v2 adding -fomit-frame-pointer instead of removing
> -fno-omit-frame-pointer?
>
> The v1 fixes the issue for me with default config + DEBUG_BUILD.

The v1 patch isn't wrong, it's just incomplete (the problem could come
back if someone changes optimisation level or switches gcc to clang,
etc).

My choice would be a v2 patch which adds -fomit-frame-pointer to
CFLAGS unconditionally for all ARM builds when Thumb is enabled. That
should fix the problem for all optimisation levels etc and avoids
building the main strace binary differently depending on whether or
not ptest is enabled.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] [RFT] GCC 8.1

[Andre McCurdy]

On Thu, May 10, 2018 at 3:38 PM, Martin Jansa <martin.ja...@gmail.com> wrote:
> see
> http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html

Removing -fno-omit-frame-pointer isn't the same as adding
-fomit-frame-pointer. Frame pointers may get enabled depending on the
optimisation level etc (ie not only by -fno-omit-frame-pointer).

> On Fri, May 11, 2018 at 12:38 AM Andre McCurdy <armccu...@gmail.com> wrote:
>>
>> On Thu, May 10, 2018 at 3:07 PM, Martin Jansa <martin.ja...@gmail.com>
>> wrote:
>> > On Thu, May 10, 2018 at 11:43:25PM +0200, Martin Jansa wrote:
>> >> On Thu, May 10, 2018 at 12:27:50PM -0700, Andre McCurdy wrote:
>> >> > On Thu, May 10, 2018 at 12:11 PM, Martin Jansa
>> >> > <martin.ja...@gmail.com> wrote:
>> >> > > On Thu, May 10, 2018 at 11:50:02AM -0700, Khem Raj wrote:
>> >> > >> Hi Martin
>> >> > >>
>> >> > >> Thanks for testing and reporting back
>> >> > >>
>> >> > >> On 5/9/18 2:38 AM, Martin Jansa wrote:
>> >> > >> > My initial tests show couple issues, but usually caused by other
>> >> > >> > changes
>> >> > >> > in that branch, not the gcc-8 itself.
>> >> > >> >
>> >> > >> > 1) strace-4.22 from
>> >> > >> >
>> >> > >> > http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8=af33a8b721cc9caebd3f5226b4c5903f666ab654
>> >> > >> > fails to build with ptest enabled (it builds with 4.20 version
>> >> > >> > if I
>> >> > >> > revert this change)
>> >> > >> > ../../strace-4.22/tests/inject-nf.c: In function 'main':
>> >> > >> > ../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be
>> >> > >> > used in
>> >> > >> > asm here
>> >> > >> >   }
>> >> > >> >   ^
>> >> > >>
>> >> > >> are you targeting thumb1 ? how can I reproduce it ?
>> >> > >
>> >> > > I'm trying to find out what's different in the builds where it was
>> >> > > failing, will provide more info later.
>> >> >
>> >> > This is probably due to making an inline syscall from Thumb (doesn't
>> >> > a
>> >> > matter Thumb1 or Thumb2) with frame pointers enabled.
>> >> >
>> >> > Does adding -fomit-frame-pointer to CFLAGS fix it?
>> >>
>> >> It was with raspberrypi3, thumb (Thumb2) enabled in DISTRO, there is
>> >> already -fno-omit-frame-pointer in the default command line for it,
>> >> adding -fomit-frame-pointer at the end fixes it:
>> >>
>> >> docker-lge @
>> >> ~/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/build/tests
>> >> $ arm-webos-linux-gnueabi-gcc  -march=armv7ve -mthumb -mfpu=neon-vfpv4
>> >> -mfloat-abi=hard -mcpu=cortex-a7
>> >> --sysroot=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot
>> >> -DHAVE_CONFIG_H-I. -I../linux/arm -I../../strace-4.22/linux/arm
>> >> -I../linux -I../../strace-4.22/linux -I.. -I../../strace-4.22
>> >> -DTESTS_SIZEOF_KERNEL_LONG_T=4 -DTESTS_SIZEOF_LONG=4  -Wall -Wempty-body
>> >> -Wformat-security -Wignored-qualifiers -Wimplicit-fallthrough=5 
>> >> -Winit-self
>> >> -Wlogical-op -Wmissing-parameter-type -Wnested-externs
>> >> -Wold-style-declaration -Wold-style-definition -Wsign-compare 
>> >> -Wtype-limits
>> >> -Wwrite-strings -O -fno-omit-frame-pointer -g 
>> >> -feliminate-unused-debug-types
>> >> -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0=/usr/src/debug/strace/4.22-r0
>> >> -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot=
>> >> -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot-native=
>> >> -pipe  -c -o inject-nf.o ../../strace-4.22/tests/inject-nf.c
>> >> -fomit-frame-pointer
>> >>
>> >> This might come from:
>> >> meta/conf/bitbake.conf:DEBUG_OPTIMIZATION = "-O -fno-omit-frame-pointer
>> >> ${DEBUG_FLAGS} -pipe"
>> >> because in this build I had DEBUG_BUILD enabled.
>> >>
>> >> Will retest with 4.20 version + DEBUG_BUILD to see if it fails there as
>> >> well now.
>> >
>> > 4.20 doesn't fail with DEBUG_BUILD, because inject-nf.c test is new in
>> > 4.22:
>> >
>> >
>> > https://github.com/strace/strace/commit/58598cd7f6e23e531d71bfe5a4e35f898a4f3b2d#diff-dc01d20c1e55f8adf7536cb46d4481e1
>> >
>> > What is preferred fix for this? Is adding -fomit-frame-pointer to CFLAGS
>> > when ptest is in DISTRO_FEATURES acceptable solution?
>>
>> I would say unconditionally adding -fomit-frame-pointer to CFLAGS for
>> all builds is OK (strace is a debug tool - not something that
>> generally needs to be debugged and frame pointers aren't essential for
>> debugging anyway).
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] [RFT] GCC 8.1

[Andre McCurdy]

On Thu, May 10, 2018 at 3:07 PM, Martin Jansa <martin.ja...@gmail.com> wrote:
> On Thu, May 10, 2018 at 11:43:25PM +0200, Martin Jansa wrote:
>> On Thu, May 10, 2018 at 12:27:50PM -0700, Andre McCurdy wrote:
>> > On Thu, May 10, 2018 at 12:11 PM, Martin Jansa <martin.ja...@gmail.com> 
>> > wrote:
>> > > On Thu, May 10, 2018 at 11:50:02AM -0700, Khem Raj wrote:
>> > >> Hi Martin
>> > >>
>> > >> Thanks for testing and reporting back
>> > >>
>> > >> On 5/9/18 2:38 AM, Martin Jansa wrote:
>> > >> > My initial tests show couple issues, but usually caused by other 
>> > >> > changes
>> > >> > in that branch, not the gcc-8 itself.
>> > >> >
>> > >> > 1) strace-4.22 from
>> > >> > http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8=af33a8b721cc9caebd3f5226b4c5903f666ab654
>> > >> > fails to build with ptest enabled (it builds with 4.20 version if I
>> > >> > revert this change)
>> > >> > ../../strace-4.22/tests/inject-nf.c: In function 'main':
>> > >> > ../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be used in
>> > >> > asm here
>> > >> >   }
>> > >> >   ^
>> > >>
>> > >> are you targeting thumb1 ? how can I reproduce it ?
>> > >
>> > > I'm trying to find out what's different in the builds where it was
>> > > failing, will provide more info later.
>> >
>> > This is probably due to making an inline syscall from Thumb (doesn't a
>> > matter Thumb1 or Thumb2) with frame pointers enabled.
>> >
>> > Does adding -fomit-frame-pointer to CFLAGS fix it?
>>
>> It was with raspberrypi3, thumb (Thumb2) enabled in DISTRO, there is
>> already -fno-omit-frame-pointer in the default command line for it,
>> adding -fomit-frame-pointer at the end fixes it:
>>
>> docker-lge @ 
>> ~/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/build/tests
>>  $ arm-webos-linux-gnueabi-gcc  -march=armv7ve -mthumb -mfpu=neon-vfpv4 
>> -mfloat-abi=hard -mcpu=cortex-a7 
>> --sysroot=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot
>>  -DHAVE_CONFIG_H-I. -I../linux/arm -I../../strace-4.22/linux/arm 
>> -I../linux -I../../strace-4.22/linux -I.. -I../../strace-4.22 
>> -DTESTS_SIZEOF_KERNEL_LONG_T=4 -DTESTS_SIZEOF_LONG=4  -Wall -Wempty-body 
>> -Wformat-security -Wignored-qualifiers -Wimplicit-fallthrough=5 -Winit-self 
>> -Wlogical-op -Wmissing-parameter-type -Wnested-externs 
>> -Wold-style-declaration -Wold-style-definition -Wsign-compare -Wtype-limits 
>> -Wwrite-strings -O -fno-omit-frame-pointer -g -feliminate-unused-debug-types 
>> -fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0=/usr/src/debug/strace/4.22-r0
>>  -fdebug-prefix-map=/OE/
 
webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot=
 
-fdebug-prefix-map=/OE/webos/build/build-webos-master/BUILD/work/raspberrypi3-webos-linux-gnueabi/strace/4.22-r0/recipe-sysroot-native=
  -pipe  -c -o inject-nf.o ../../strace-4.22/tests/inject-nf.c 
-fomit-frame-pointer
>>
>> This might come from:
>> meta/conf/bitbake.conf:DEBUG_OPTIMIZATION = "-O -fno-omit-frame-pointer 
>> ${DEBUG_FLAGS} -pipe"
>> because in this build I had DEBUG_BUILD enabled.
>>
>> Will retest with 4.20 version + DEBUG_BUILD to see if it fails there as well 
>> now.
>
> 4.20 doesn't fail with DEBUG_BUILD, because inject-nf.c test is new in
> 4.22:
>
> https://github.com/strace/strace/commit/58598cd7f6e23e531d71bfe5a4e35f898a4f3b2d#diff-dc01d20c1e55f8adf7536cb46d4481e1
>
> What is preferred fix for this? Is adding -fomit-frame-pointer to CFLAGS
> when ptest is in DISTRO_FEATURES acceptable solution?

I would say unconditionally adding -fomit-frame-pointer to CFLAGS for
all builds is OK (strace is a debug tool - not something that
generally needs to be debugged and frame pointers aren't essential for
debugging anyway).
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] [RFT] GCC 8.1

[Andre McCurdy]

On Thu, May 10, 2018 at 12:11 PM, Martin Jansa  wrote:
> On Thu, May 10, 2018 at 11:50:02AM -0700, Khem Raj wrote:
>> Hi Martin
>>
>> Thanks for testing and reporting back
>>
>> On 5/9/18 2:38 AM, Martin Jansa wrote:
>> > My initial tests show couple issues, but usually caused by other changes
>> > in that branch, not the gcc-8 itself.
>> >
>> > 1) strace-4.22 from
>> > http://git.openembedded.org/openembedded-core-contrib/commit/?h=kraj/gcc-8=af33a8b721cc9caebd3f5226b4c5903f666ab654
>> > fails to build with ptest enabled (it builds with 4.20 version if I
>> > revert this change)
>> > ../../strace-4.22/tests/inject-nf.c: In function 'main':
>> > ../../strace-4.22/tests/inject-nf.c:86:1: error: r7 cannot be used in
>> > asm here
>> >   }
>> >   ^
>>
>> are you targeting thumb1 ? how can I reproduce it ?
>
> I'm trying to find out what's different in the builds where it was
> failing, will provide more info later.

This is probably due to making an inline syscall from Thumb (doesn't a
matter Thumb1 or Thumb2) with frame pointers enabled.

Does adding -fomit-frame-pointer to CFLAGS fix it?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to create a build for ARM Cortex-A8, S5PV210

[Andre McCurdy]

On Tue, May 8, 2018 at 1:38 PM, Denis  wrote:
> Hi. I'm new to yocto. So I have followed a tutorial and now I have crewated
> my first yocto distro for i386.
>
> Now I need to create a build for my device. It is a Samsung S5PV210 device,
> Cortex A8.
>
> Here there is a description
>
> http://www.friendlyarm.net/products/mini210
>
> Can someone suggest me how to setup the yocto build for this target?

Start by creating a machine config. That could initially be very
minimal, for example, just:

  require conf/machine/include/tune-cortexa8.inc

might be enough to build a toolchain and a minimal rootfs image with
command line tools which will run on your board (if the board comes
with a pre-built kernel then you may be able to use the pre-built
kernel to run the OE rootfs - just for an initial test).

Next step would be to create a kernel recipe, so that you can create a
complete kernel + rootfs with OE.

After that, add recipes for any components which are machine specific
but are not part of the kernel (e.g. out of tree kernel driver
modules, etc).
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH] bitbake: fetch2/gitsm: avoid live submodule fetching during unpack()

[Andre McCurdy]

On Wed, May 9, 2018 at 5:40 PM, Matt Hoosier <matt.hoos...@gmail.com> wrote:
> On Wed, May 9, 2018 at 6:27 PM, Andre McCurdy <armccu...@gmail.com> wrote:
>>
>> On Wed, May 9, 2018 at 2:48 PM, Matt Hoosier <matt.hoos...@gmail.com>
>> wrote:
>> > From: Matt Hoosier <matt.hoos...@garmin.com>
>> >
>> > Although the submodules' histories have been fetched during the
>> > do_fetch() phase, the mechanics used to clone the workdir copy
>> > of the repo haven't been transferring the actual .git/modules
>> > directory from the repo fetched into downloads/ during the
>> > fetch task.
>> >
>> > Fix that, and for good measure also explicitly tell Git to avoid
>> > hitting the network during do_unpack() of the submodules.
>> >
>> > Ref:
>> > https://bugzilla.yoctoproject.org/show_bug.cgi?id=12739
>>
>> Patches for bitbake should be sent to the bitbake-devel mailing list:
>>
>>   http://lists.openembedded.org/mailman/listinfo/bitbake-devel
>
> Right, okay. How's that meant to work for stuff developed in-tree with poky?
> Do you manually want the 'bitbake/' leading directory stripped off before
> emailing the patch?

Yes, patches for bitbake should apply directly to a clone of the bitbake repo.

Manually editing a patch created from poky is certainly do-able, but
applying the patch to a genuine bikebake repo (with "git am -p2 ...")
and re-generating the patch from there may be safer. Whichever you
prefer.

>> > ---
>> >  bitbake/lib/bb/fetch2/gitsm.py | 12 +++-
>> >  1 file changed, 11 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/bitbake/lib/bb/fetch2/gitsm.py
>> > b/bitbake/lib/bb/fetch2/gitsm.py
>> > index 0aff1008e5..1f3fc44352 100644
>> > --- a/bitbake/lib/bb/fetch2/gitsm.py
>> > +++ b/bitbake/lib/bb/fetch2/gitsm.py
>> > @@ -132,4 +132,14 @@ class GitSM(Git):
>> >
>> >  if self.uses_submodules(ud, d, ud.destdir):
>> >  runfetchcmd(ud.basecmd + " checkout " +
>> > ud.revisions[ud.names[0]], d, workdir=ud.destdir)
>> > -runfetchcmd(ud.basecmd + " submodule update --init
>> > --recursive", d, workdir=ud.destdir)
>> > +
>> > +# Copy over the submodules' fetched histories too.
>> > +if ud.bareclone:
>> > +repo_conf = ud.destdir
>> > +else:
>> > +repo_conf = os.path.join(ud.destdir, '.git')
>> > +runfetchcmd("cp -pr %s %s" % (os.path.join(ud.clonedir,
>> > 'modules'), repo_conf), d)
>> > +
>> > +# Careful not to hit the network during unpacking; all
>> > history should already
>> > +# be fetched.
>> > +runfetchcmd(ud.basecmd + " submodule update --init
>> > --recursive --no-fetch", d, workdir=ud.destdir)
>> > --
>> > 2.13.6
>> >
>> > --
>> > ___
>> > yocto mailing list
>> > yocto@yoctoproject.org
>> > https://lists.yoctoproject.org/listinfo/yocto
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH] bitbake: fetch2/gitsm: avoid live submodule fetching during unpack()

[Andre McCurdy]

On Wed, May 9, 2018 at 2:48 PM, Matt Hoosier  wrote:
> From: Matt Hoosier 
>
> Although the submodules' histories have been fetched during the
> do_fetch() phase, the mechanics used to clone the workdir copy
> of the repo haven't been transferring the actual .git/modules
> directory from the repo fetched into downloads/ during the
> fetch task.
>
> Fix that, and for good measure also explicitly tell Git to avoid
> hitting the network during do_unpack() of the submodules.
>
> Ref:
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=12739

Patches for bitbake should be sent to the bitbake-devel mailing list:

  http://lists.openembedded.org/mailman/listinfo/bitbake-devel

> ---
>  bitbake/lib/bb/fetch2/gitsm.py | 12 +++-
>  1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/bitbake/lib/bb/fetch2/gitsm.py b/bitbake/lib/bb/fetch2/gitsm.py
> index 0aff1008e5..1f3fc44352 100644
> --- a/bitbake/lib/bb/fetch2/gitsm.py
> +++ b/bitbake/lib/bb/fetch2/gitsm.py
> @@ -132,4 +132,14 @@ class GitSM(Git):
>
>  if self.uses_submodules(ud, d, ud.destdir):
>  runfetchcmd(ud.basecmd + " checkout " + 
> ud.revisions[ud.names[0]], d, workdir=ud.destdir)
> -runfetchcmd(ud.basecmd + " submodule update --init --recursive", 
> d, workdir=ud.destdir)
> +
> +# Copy over the submodules' fetched histories too.
> +if ud.bareclone:
> +repo_conf = ud.destdir
> +else:
> +repo_conf = os.path.join(ud.destdir, '.git')
> +runfetchcmd("cp -pr %s %s" % (os.path.join(ud.clonedir, 
> 'modules'), repo_conf), d)
> +
> +# Careful not to hit the network during unpacking; all history 
> should already
> +# be fetched.
> +runfetchcmd(ud.basecmd + " submodule update --init --recursive 
> --no-fetch", d, workdir=ud.destdir)
> --
> 2.13.6
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Avoiding both GPLv3 and meta-gplv2 ?

[Andre McCurdy]

On Tue, May 1, 2018 at 4:59 PM, Paul Eggleton
<paul.eggle...@linux.intel.com> wrote:
> On Wednesday, 2 May 2018 11:54:00 AM NZST Andre McCurdy wrote:
>> On Tue, May 1, 2018 at 3:10 PM, Paul Eggleton
>> <paul.eggle...@linux.intel.com> wrote:
>> > On Wednesday, 2 May 2018 12:07:42 AM NZST Burton, Ross wrote:
>> >> The make dependencies come from the ptest packages, so if you disable
>> >> ptest in your DISTRO_FEATURES then those should disappear.
>> >>
>> >> Essentially doing a full build without any GPLv3 software *and* not
>> >> using old releases which are still GPLv2 is tricky.  I can only
>> >> suggest you don't use the meta-gpl2 layer (as you don't want the
>> >> recipes to be used) and use bbappends to disable pieces where
>> >> required.
>> >
>> > We probably need some sort of whitepaper on how to do that, it doesn't
>> > look like our manuals cover it in sufficient detail. Any volunteers ? ;)
>>
>> Does "Blacklist GPLv3, don't use meta-gplv2, fix any issues you may
>> run into" need a whitepaper? Or is there more to it than that?
>
> Apart from "disable ptest" as Ross pointed out, I would assume that's all
> there is to it - but right now aside from asking here there's really no way
> for someone to know that that's the best available way of handling it, so I
> think it's worth documenting somewhere.

Yes, OK. I hadn't realised ptest is enabled by default in poky (!?!).

  
http://git.yoctoproject.org/cgit.cgi/meta-yocto/commit/?id=9381b2d2bddf9f67cf57b0718cf99e45805125fa
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Avoiding both GPLv3 and meta-gplv2 ?

[Andre McCurdy]

On Tue, May 1, 2018 at 3:10 PM, Paul Eggleton
 wrote:
> On Wednesday, 2 May 2018 12:07:42 AM NZST Burton, Ross wrote:
>> The make dependencies come from the ptest packages, so if you disable
>> ptest in your DISTRO_FEATURES then those should disappear.
>>
>> Essentially doing a full build without any GPLv3 software *and* not
>> using old releases which are still GPLv2 is tricky.  I can only
>> suggest you don't use the meta-gpl2 layer (as you don't want the
>> recipes to be used) and use bbappends to disable pieces where
>> required.
>
> We probably need some sort of whitepaper on how to do that, it doesn't look
> like our manuals cover it in sufficient detail. Any volunteers ? ;)

Does "Blacklist GPLv3, don't use meta-gplv2, fix any issues you may
run into" need a whitepaper? Or is there more to it than that?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] LINUX_VERSION issue in recipe

[Andre McCurdy]

On Fri, Apr 27, 2018 at 3:44 AM, Damien LEFEVRE  wrote:
> Hi,
>
> This must be a stupid basic question. I have the following recipe append:
>
> keymaps_1.0.bbappend
> -
> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> SRC_URI_append = " file://keymaps.service \
>file://keymap.sh \
> "
>
> do_install_append() {
> install -d ${D}${sysconfdir}
> ln -sf /usr/share/keymaps/i386/qwerty/fi.map.gz
> ${D}${sysconfdir}/keymap-${LINUX_VERSION}.map.gz
>
> install -d ${D}${systemd_system_unitdir}
> install -m 0644 ${WORKDIR}/keymaps.service ${D}${systemd_system_unitdir}
> }
>
> FILES_${PN} += " ${sysconfdir}/* \
>  ${systemd_system_unitdir}/* \
> "
>
> inherit systemd
> SYSTEMD_SERVICE_${PN} = "${PN}.service"
> -
>
> The LINUX_VERSION is not expanded and the final symlink name becomes
> /etc/keymap-.map.gz.
>
> What's correct way to get the linux version in the recipe files?

In general, there isn't a correct way to do that. The LINUX_VERSION
variable is defined within the kernel recipe and other recipes won't
have access to it.

A core concept in OE is that recipes build independently of each
other. In this case, since the keymaps recipe has no direct dependency
on the kernel, you should not expect the keymaps recipe to be rebuilt
(or affected in any way) when the kernel or kernel version changes.

The keymaps init script ( meta/recipes-bsp/keymaps/files/keymap.sh )
detects the kernel version dynamically at runtime. If you need a
kernel version specific symlink in your target rootfs, maybe you could
create it at runtime from your keymaps service file?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] New Recipe Integration Issue

[Andre McCurdy]

On Thu, Apr 26, 2018 at 11:36 AM, Shakthi Pradeep (tpradeep)
<tprad...@cisco.com> wrote:
> Thanks for the info Andre. What you are suggesting it to be done while 
> building an application over these libraries right?

No. The soname needs to be set when the library is linked.

> Any idea why the packaging is failing?

I don't think packaging is failing.

> Regards,
> Shakthi
>
> On 27/04/18, 12:00 AM, "Andre McCurdy" <armccu...@gmail.com> wrote:
>
> On Thu, Apr 26, 2018 at 11:03 AM, Shakthi Pradeep (tpradeep)
> <tprad...@cisco.com> wrote:
> > Hello Folks,
> >
> > I am trying to integrate an SDK which is very simple and small. 
> Building the
> > SDK generates an executable and few .so libraries.
> >
> > “bitbake sdk” command goes through fine but when I run “bitbake
> > wrlinux-image-glibc-std” to generate an ISO with SDK packages I am get
> > following error
> >
> > ...
> >
> > install -m 0755 ${S}/lib/libmvudrv.so
> > ${D}/${libdir}/libmvudrv.so.1.0.1
> >
> > ln -sf libmvudrv.so.1.0.1 ${D}/${libdir}/libmvudrv.so
>
> Unfortunately, creating versioned libraries requires more than just
> renaming and creating a symlink.
>
> If the library is going to be renamed during installation, then the
> soname (which is set within the library when the library is linked)
> needs to match a name which will exist in the target rootfs at
> runtime.
>
> In this case, since "libmvudrv.so.1.0.1" is the name which will be
> present at runtime, when the build creates libmvudrv.so, it needs to
> set the soname to "libmvudrv.so.1.0.1". ie add the following to the
> linker commandline:
>
>   -Wl,-soname,libmvudrv.so.1.0.1
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] New Recipe Integration Issue

[Andre McCurdy]

On Thu, Apr 26, 2018 at 11:03 AM, Shakthi Pradeep (tpradeep)
 wrote:
> Hello Folks,
>
> I am trying to integrate an SDK which is very simple and small. Building the
> SDK generates an executable and few .so libraries.
>
> “bitbake sdk” command goes through fine but when I run “bitbake
> wrlinux-image-glibc-std” to generate an ISO with SDK packages I am get
> following error
>
> ...
>
> install -m 0755 ${S}/lib/libmvudrv.so
> ${D}/${libdir}/libmvudrv.so.1.0.1
>
> ln -sf libmvudrv.so.1.0.1 ${D}/${libdir}/libmvudrv.so

Unfortunately, creating versioned libraries requires more than just
renaming and creating a symlink.

If the library is going to be renamed during installation, then the
soname (which is set within the library when the library is linked)
needs to match a name which will exist in the target rootfs at
runtime.

In this case, since "libmvudrv.so.1.0.1" is the name which will be
present at runtime, when the build creates libmvudrv.so, it needs to
set the soname to "libmvudrv.so.1.0.1". ie add the following to the
linker commandline:

  -Wl,-soname,libmvudrv.so.1.0.1
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] yocto jethro failed on gettext-native

[Andre McCurdy]

On Wed, Apr 25, 2018 at 8:03 AM, Oliver Graute  wrote:
> Hello list,
>
> I try to compile yocto jethro environment which is working
> on a Ubuntu 14.04 installation. But not on a Kubuntu 16.04.
>
> The compilations stops on gettext-native.
>
> bitbake -k fsl-image-mfgtool-initramfs
>
>  make[5]: Entering directory 
> '/home/us/build-imx6ulevk-mfgtool/tmp/work/x86_64-linux/gettext-native/0.19.4-r0/build/gettext-tools/src'
> | ../x86_64-linux-libtool  --tag=CC   --mode=link gcc   
> -isystem/home/us/build-imx6ulevk-mfgtool/tmp/sysroots/x86_64-linux/usr/include
>  -O2 -pipe -release 0.19.4 ../gnulib-lib/libgettextlib.la  -lc -no-undefined  
> -L/home/us/build-imx6ulevk-mfgtool/tmp/sysroots/x86_64-linux/usr/lib 
> -L/home/us/build-imx6ulevk-mfgtool/tmp/sysroots/x86_64-linux/lib 
> -Wl,-rpath-link,/home/us/build-imx6ulevk-mfgtool/tmp/sysroots/x86_64-linux/usr/lib
>  
> -Wl,-rpath-link,/home/us/build-imx6ulevk-mfgtool/tmp/sysroots/x86_64-linux/lib
>  
> -Wl,-rpath,/home/us/build-imx6ulevk-mfgtool/tmp/sysroots/x86_64-linux/usr/lib 
> -Wl,-rpath,/home/us/build-imx6ulevk-mfgtool/tmp/sysroots/x86_64-linux/lib 
> -Wl,-O1 -o libgettextsrc.la -rpath 
> /home/us/build-imx6ulevk-mfgtool/tmp/sysroots/x86_64-linux/usr/lib 
> libgettextsrc_la-message.lo libgettextsrc_la-po-error.lo 
> libgettextsrc_la-po-xerror.lo libgettextsrc_la-read-catalog-abstract.lo 
> libgettextsrc_la-po-lex.lo libgettextsrc_la-po-gram-gen.lo 
> libgettextsrc_la-po-charset.lo libgett
 ex
>  tsrc_la-read-po.lo libgettextsrc_la-read-properties.lo 
> libgettextsrc_la-read-stringtable.lo libgettextsrc_la-open-catalog.lo 
> libgettextsrc_la-dir-list.lo libgettextsrc_la-str-list.lo 
> libgettextsrc_la-read-catalog.lo libgettextsrc_la-color.lo 
> libgettextsrc_la-write-catalog.lo libgettextsrc_la-write-properties.lo 
> libgettextsrc_la-write-stringtable.lo libgettextsrc_la-write-po.lo 
> libgettextsrc_la-msgl-ascii.lo libgettextsrc_la-msgl-iconv.lo 
> libgettextsrc_la-msgl-equal.lo libgettextsrc_la-msgl-cat.lo 
> libgettextsrc_la-msgl-header.lo libgettextsrc_la-msgl-english.lo 
> libgettextsrc_la-msgl-check.lo libgettextsrc_la-file-list.lo 
> libgettextsrc_la-msgl-charset.lo libgettextsrc_la-po-time.lo 
> libgettextsrc_la-plural-exp.lo libgettextsrc_la-plural-eval.lo 
> libgettextsrc_la-plural-table.lo libgettextsrc_la-format.lo 
> libgettextsrc_la-format-c.lo libgettextsrc_la-format-sh.lo 
> libgettextsrc_la-format-python.lo libgettextsrc_la-format-python-brace.lo 
> libgettextsrc_la-format-lisp.lo libgettext
 sr
>  c_la-format-elisp.lo libgettextsrc_la-format-librep.lo 
> libgettextsrc_la-format-scheme.lo libgettextsrc_la-format-java.lo 
> libgettextsrc_la-format-csharp.lo libgettextsrc_la-format-awk.lo 
> libgettextsrc_la-format-pascal.lo libgettextsrc_la-format-ycp.lo 
> libgettextsrc_la-format-tcl.lo libgettextsrc_la-format-perl.lo 
> libgettextsrc_la-format-perl-brace.lo libgettextsrc_la-format-php.lo 
> libgettextsrc_la-format-gcc-internal.lo 
> libgettextsrc_la-format-gfc-internal.lo libgettextsrc_la-format-qt.lo 
> libgettextsrc_la-format-qt-plural.lo libgettextsrc_la-format-kde.lo 
> libgettextsrc_la-format-boost.lo libgettextsrc_la-format-lua.lo 
> libgettextsrc_la-format-javascript.lo libgettextsrc_la-read-desktop.lo
> | x86_64-linux-libtool:   error: 'libgettextsrc_la-message.lo' is not a valid 
> libtool object

libgettextsrc_la-message.lo should be a short text file. Could you
find it in your build tree and post a copy?

> | Makefile:2285: recipe for target 'libgettextsrc.la' failed
> | make[5]: *** [libgettextsrc.la] Error 1
> | make[5]: Leaving directory 
> '/home/us/build-imx6ulevk-mfgtool/tmp/work/x86_64-linux/gettext-native/0.19.4-r0/build/gettext-tools/src'
> | Makefile:2206: recipe for target 'all' failed
> | make[4]: *** [all] Error 2
> | make[4]: Leaving directory 
> '/home/us/build-imx6ulevk-mfgtool/tmp/work/x86_64-linux/gettext-native/0.19.4-r0/build/gettext-tools/src'
> | Makefile:1698: recipe for target 'all-recursive' failed
> | make[3]: *** [all-recursive] Error 1
> | make[3]: Leaving directory 
> '/home/us/build-imx6ulevk-mfgtool/tmp/work/x86_64-linux/gettext-native/0.19.4-r0/build/gettext-tools'
> | Makefile:1564: recipe for target 'all' failed
> | make[2]: *** [all] Error 2
> | make[2]: Leaving directory 
> '/home/us/build-imx6ulevk-mfgtool/tmp/work/x86_64-linux/gettext-native/0.19.4-r0/build/gettext-tools'
> | Makefile:380: recipe for target 'all-recursive' failed
> | make[1]: *** [all-recursive] Error 1
> | make[1]: Leaving directory 
> '/home/us/build-imx6ulevk-mfgtool/tmp/work/x86_64-linux/gettext-native/0.19.4-r0/build'
> | Makefile:336: recipe for target 'all' failed
> | make: *** [all] Error 2
> | ERROR: oe_runmake failed
> | ERROR: Function failed: do_compile (log file is located at 
> /home/us/build-imx6ulevk-mfgtool/tmp/work/x86_64-linux/gettext-native/0.19.4-r0/temp/log.do_compile.5336)
> ERROR: Task 531 
> 

Re: [yocto] pyro: missing ldconfig

[Andre McCurdy]

On Thu, Apr 5, 2018 at 11:53 PM, Florian Doersch
 wrote:
>
> I recently updated from pyro 2.3.3 to latest pyro branch for my raspberry3
> and ran into the following problem
> ...
> The problem does not occur when using the latest pyro tag (yocto-2.3.3)

Unless someone else has a better answer, you might need to bisect
between 2.3.3 and the latest pyro version to find out which particular
commit caused your issue.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to set SRC_URI in local.conf / how to set any variable of a specific recipe in local.conf

[Andre McCurdy]

On Sat, Apr 7, 2018 at 8:04 AM, Jakob Hasse  wrote:
>
> how can I set a another branch, i.e., the SRC_URI variable for a specific
> recipe in conf/local.conf? Or more general: how can I change the variable of
> any recipe in local.conf temporarily? I tried something like this already:
> SRC_ = "..."
> SRC- = "..."
> SRC_pn- = "..."
>
> I would like to switch a recipe to a testing branch temporarily via
> local.conf without playing around in the actual recipes.

For your own temporary testing, modifying the actual recipes would be fine.

However, if you need to make the change via local.conf, then the
procedure would be something like:

1) Capture output of "bitbake -e recipe-name" into a file

2) From the bitbake environment for recipe-name, check what the
original value of SRC_URI is. For example, it may be something like:

  SRC_URI="git://git.project.com/foo file://fixes.patch"

3) Also from the bitbake environment for recipe-name, check which
over-rides are active. For example, it maybe something like:

  
OVERRIDES="linux:i586:build-linux:pn-recipe-name:x86:qemuall:qemux86:spooky:class-target:forcevariable:libc-glibc"

4) Pick an over-ride. Since you want to use a global config file to
make a recipe specific change, you need to use the recipe specific
over-ride, ie "pn-recipe-name".

5) Update the SRC_URI from step 2 as you want and then define it in
local.conf using the over-ride you found in step 3. For example:

  SRC_URI_pn-recipe-name = "git://git.project.com/foo2 file://fixes.patch"
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] binutils 2.29.1 ARM Thumb kernel problem

[Andre McCurdy]

On Thu, Apr 5, 2018 at 12:17 PM, Khem Raj  wrote:
> On Thu, Apr 5, 2018 at 12:16 PM Khem Raj  wrote:
>> On Thu, Apr 5, 2018 at 11:53 AM Chris Elledge 
>> wrote:
>>>
>>> Unfortunately, removing the "+1" doesn't work. That results in a kernel
>>> which claims to start, but doesn't progress.
>>>
>>> Changing it to an "|1" also doesn't work due to this error:
>>> arch/arm/kernel/entry-common.S:117: Error: invalid operands (.text and
>>> *ABS* sections) for `|'
>>>
>>> Doing this to the badr macro:
>>>  #ifdef CONFIG_THUMB2_KERNEL
>>>   adr\c \rd, \sym
>>>   orr\c \rd, \rd, #1
>
> Sent too soon I mean remove ORR completely

There's a lot more description of the problem here:

  https://patchwork.kernel.org/patch/10072625/

The kernel patch proposed in that thread is basically the same as
adding the extra ORR instruction, but formatted in a slightly
different way. No variant of the patch appears to have been merged
upstream yet.

The binutils 2.29 change in behaviour was the root cause of the issue
that was found and fixed in openssl a few months ago:

  https://github.com/openssl/openssl/pull/4673
  
http://git.openembedded.org/openembedded-core/commit/?id=977db3843b629112539d3eb766c845127c0de497
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] binutils 2.29.1 ARM Thumb kernel problem

[Andre McCurdy]

On Wed, Apr 4, 2018 at 9:14 AM, Andre McCurdy <armccu...@gmail.com> wrote:
> On Wed, Apr 4, 2018 at 8:06 AM, Chris Elledge
> <celle...@digitallumens.com> wrote:
>> Thanks for the feedback. I rolled back binutils to 2.28.0 by copying the
>> yocto-2.3.3 binutils recipe directory into my custom layer. That has
>> resolved the issue.
>>
>> I can confirm that binutils 2.29.0 also has the problem. I went from
>> yocto-2.3 to 2.4.2 so I hadn't tried binutils 2.29.0 previously. There are
>> also reports that openssl and libavcodec are broken when targeting an ARM
>> Thumb2 platform with binutils 2.29.*
>
> Yes, that makes sense. The binutils change is in both 2.29.0 and
> 2.29.1 (and also in 2.30.0).
>
> The next useful experiment would be to stay with binutils 2.29.1 and
> apply a patch to revert the one particular commit which caused the
> change in behaviour:
>
>   
> https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=e645cf40b111daef4518a58547de577eb9379ccb

The experiment of patching the kernel would also be useful, since I
would guess that the final solution from upstream will involve a
change to the kernel rather than reverting the change to binutils.

Changing "+ 1" to "| 1" in the badr macro would be a universal
solution for all versions of binutils, but for a quick test with
binutils 2.29.1 you could simply remove the "+ 1" from the
CONFIG_THUMB2_KERNEL case (ie make the ARM and Thumb2 versions of the
macro identical).

  
https://github.com/torvalds/linux/blob/master/arch/arm/include/asm/assembler.h#L197
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] binutils 2.29.1 ARM Thumb kernel problem

[Andre McCurdy]

On Wed, Apr 4, 2018 at 8:06 AM, Chris Elledge
 wrote:
> Thanks for the feedback. I rolled back binutils to 2.28.0 by copying the
> yocto-2.3.3 binutils recipe directory into my custom layer. That has
> resolved the issue.
>
> I can confirm that binutils 2.29.0 also has the problem. I went from
> yocto-2.3 to 2.4.2 so I hadn't tried binutils 2.29.0 previously. There are
> also reports that openssl and libavcodec are broken when targeting an ARM
> Thumb2 platform with binutils 2.29.*

Yes, that makes sense. The binutils change is in both 2.29.0 and
2.29.1 (and also in 2.30.0).

The next useful experiment would be to stay with binutils 2.29.1 and
apply a patch to revert the one particular commit which caused the
change in behaviour:

  
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=e645cf40b111daef4518a58547de577eb9379ccb
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] binutils 2.29.1 ARM Thumb kernel problem

[Andre McCurdy]

On Mon, Apr 2, 2018 at 3:49 PM, akuster808  wrote:
> On 04/02/2018 01:15 PM, Chris Elledge wrote:
>
> I recently upgraded my Yocto based project to Yocto 2.4.2, and I encountered
> a problem when building my custom kernel for an AT91 SAMA5D3X platform. I've
> been using an ARM Thumb2 kernel for a while successfully until this release.
> It appears that the issue stems from the change to binutils version 2.29.1.
>
> Here's a good description of the problem:
> https://patchwork.kernel.org/patch/10072695/
>
> I will take a look. Can you provide a reproducer? ie qemuarm tweak??

Reproducing with qemuarm would require both changing qemuarm to use a
CPU with supports Thumb2 and then changing the kernel config to build
a Thumb2 kernel. It's not going to be a trivial tweak.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] binutils 2.29.1 ARM Thumb kernel problem

[Andre McCurdy]

On Mon, Apr 2, 2018 at 1:15 PM, Chris Elledge
 wrote:
> I recently upgraded my Yocto based project to Yocto 2.4.2, and I encountered
> a problem when building my custom kernel for an AT91 SAMA5D3X platform. I've
> been using an ARM Thumb2 kernel for a while successfully until this release.
> It appears that the issue stems from the change to binutils version 2.29.1.
>
> Here's a good description of the problem:
> https://patchwork.kernel.org/patch/10072695/
>
> I tried out their test script, and it flagged the arm-poky-linux-gnueabi-
> toolchain built by Yocto 2.4.2 as being buggy. Has anyone else encountered
> this problem and figured out a way around it without disabling Thumb
> compilation of the kernel?

Thanks for bringing up this issue. Reading through the various bug
reports etc it not clear what the fix should be. Upstream binutils has
not reverted the change and the upstream kernel still appears to rely
on the pre-2.29.1 binutils behaviour.

The simplest solution for OE 2.4 would seem to be to revert the change
in binutils (rev e645cf4, which was added very close to the 2.29.1
release).

Longer term, it looks like the kernel will have to be updated to work
with the most recent versions of binutils. A possible approach for
that is hinted at in the kernel patch you provided a link for, ie
update the "badr" macro in arch/arm/include/asm/assembler.h to OR the
sym address with 1 instead of adding 1. e.g. something like changing:

  #ifdef CONFIG_THUMB2_KERNEL
  adr\c \rd, \sym + 1
  #else

to

  #ifdef CONFIG_THUMB2_KERNEL
  adr\c \rd, \sym
  orr\c \rd, \rd, #1
  #else

The fact that it doesn't seem to have been fixed that way in the
upstream kernel suggests that the kernel developers may be hoping to
find a better solution though (ie one which avoids adding an extra
instruction in the syscall fast path).

So, without some more guidance from either upstream project, the best
solution isn't clear. Perhaps you could try reverting the binutils
change to get you up and running again in the short term and then ask
on the ARM kernel mailing lists what the solution for Thumb2 with
binutils >= 2.29.1 is expected to be?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] CPU Load

[Andre McCurdy]

On Tue, Mar 27, 2018 at 4:44 AM, Ryan Meulenkamp
 wrote:
> Hi y'all,
>
> I have some questions about CPU load and performance, but first some
> background information.
>
> We have small embedded system running an openembedded classic (Angström)
> distro. Now to get ourselves up-to-date we started working on a new
> iteration of the OS based on openembedded core and Yocto. It is nearly
> finished now, if it weren't for one problem: The CPU load (/proc/loadavg) of
> the core/yocto based OS is more than double that of the classic/Angström OS.
>
> So the way I see it this could be caused by a number of factors:
>
>  - loadavg's calculation changed
>  - certain newer versions of applications run heavier
>  - The kernel itself is heavier (we upgraded from 2.6.35.14+ to 4.9.28+)
>   - Possibly caused by some configs
>  - ...
>
> My question: is there something that changed since OE-classic that you know
> could be the cause of this? If not, how would I go about finding the cause?
> I don't think the top command is sufficient for this, because it's precision
> is such that many processes' CPU usage just become 0%.

You don't say what the CPU doubled from or too. 1% to 2%, or 50% to
100% ? Unless the absolute increase is very small, you can probably
ignore the processes which top reports as 0%.

Does the new build have any significant processes running which
weren't there in the old build? Or is it the same basic set of apps
running in each?

> Also, both top and
> htop cause huge cpu loads themselves.
>
> Any tips and tricks would be welcome!
>
> Thanks in advance!
>
> Ryan
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] ARM CPU version question

[Andre McCurdy]

On Mon, Mar 19, 2018 at 4:35 PM, Steve Pavao  wrote:
>
> I think I may have discovered a specific situation which is causing the
> problem to occur for me.  It seems it occurs because I am trying to build a
> kernel module under the recipes-kernel directory in my custom layer.   A
> colleague pointed out to me that meta/classes/module.bbclass explicitly
> unsets CFLAGS and a bunch of other macros in this situation.

OK, but note that the kernel (and kernel modules) are quite different
to user space in the way that CFLAGS and -mcpu etc are setup. For code
which runs in user space, these options are set by the OE build
environment, based on the machine config. For code which runs in
kernel space, these options come from the kernel build system, based
on the kernel config.

ie it's quite correct for module.bbclass to unset CFLAGS etc - it
prevents OE's flags for user space contaminating or conflicting with
the flags set by the kernel build system.

> Maybe I need to put in some custom shell syntax in my recipe, to export
> __ARM_ARCH_6__ or to directly define the compiler macro when needed, based
> on the value of the TARGET variable.  I wonder if there is a better
> recommended solution than this, though.

__ARM_ARCH_6__ is one of the macros normally set internally by gcc, so
you shouldn't be trying to set it manually.

Instead, you should probably either:

1) Update your code to test for defined(__ARM_ARCH_6__) ||
defined(__ARM_ARCH_6K__), since according to:

  https://github.com/torvalds/linux/blob/master/arch/arm/Makefile#L65

the kernel will either pass -march=armv6 or -march=armv6k for ARMv6
targets (depending on whether or not your kernel config enables
CONFIG_CPU_32v6K).

2) Update your code to test the generic ARMv6 macro set by the kernel
build system, ie (__LINUX_ARM_ARCH__ == 6), which should catch all
ARMv6 targets.


> BTW, my kernel module contains conditionally-compiled code for initializing
> the ARM PMU correctly for each CPU case.
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] ARM CPU version question

[Andre McCurdy]

On Mon, Mar 19, 2018 at 9:49 AM, Steve Pavao  wrote:
> What’s the recommended way to be able to propogate target-specific 
> compile-time CPU tune information to affect the build of a source file in my 
> own custom layer?
>
> For example, if I’m building for an arm6-based target, I’d like to be able to 
> have the __ARM_ARCH_6__ symbol be available when the Yocto system builds my 
> custom layer.  The BSP for such a target obviously defines this symbol when 
> building its files for such a target.  Is there an easy way to propagate this 
> information to my own custom layer, to affect my own sources?  Maybe my 
> recipe needs to include certain conf files from other layers such as meta or 
> the BSP layer?

This kind of macro is typically defined internally by gcc, depending
on the -mcpu etc options passed on the gcc command line, ie options
which are included in the ${CC} definition setup by OE.

Therefore all you normally need to do is ensure that the Makefiles etc
for the components in your custom layer all correctly respect OE's
definition of ${CC}.

A typical bug in handcrafted Makefiles is to force CC to (e.g. CC =
"$(CROSS_COMPILE)gcc") and lose the original value passed via the
environment.

> Currently, I notice that architecture-level symbols are available to my 
> custom layer at compile time, such as __aarch64_ and __arm__, but not CPU 
> tune information, such as __ARM_ARCH_6__.

The exact set of macros defined by gcc will vary depending on exactly
which ARMv6 CPU you are targeting (and to some extent, which version
of gcc you are using). If you have code which needs to be enabled for
any ARMv6 target then you may have to test multiple macros. For
example see the way in which openssl defines __ARM_ARCH__

  https://github.com/openssl/openssl/blob/master/crypto/arm_arch.h

> - Steve Pavao
> Korg R
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How and where does yocto find lighttpd-module-fastcgi?

[Andre McCurdy]

On Fri, Mar 9, 2018 at 6:18 AM, Wayne Witzke  wrote:

> Thank you for the reply!
>
> When I wasn't adding lighttpd-module-fastcgi, it definitely was not
> including it in the build.
>

The lighttpd-module-fastcgi package is created (unconditionally) when the
lighttpd recipe is built (you can verify by checking the installable
packages under tmp/deploy/ after building lighttpd).

However, since nothing in the default images has a runtime dependency on
lighttpd-module-fastcgi, that package will only be included in the rootfs
if you manually add it (e.g. by adding to CORE_IMAGE_EXTRA_INSTALL, as you
have done).

ie you need to make the distinction between "is this package being built"
and "is this package being included in the rootfs when the image is built".

I have the lighttpd.conf file set up use mod_fastcgi, and without
> lighttpd-module-fastcgi in my local.conf file, lighttpd would fail to start
> on the embedded build, complaining that it could not find the fastcgi
> module. In fact, the same thing happens with php-cgi. I can't find anyplace
> in any of the layers that I'm using that actually references php-cgi as a
> package or option, but unless I add it to local.conf using
> EXTRA_CORE_IMAGES_INSTALL, it doesn't get included in the build.
>

It's a similar story with the php-cgi package. It's created
(unconditionally) when the php recipe is built, but will not be installed
in the rootfs unless you add it to your image.

The reason you don't find a direct reference to the string "php-cgi"
anywhere is because the php recipe defines it's list of packages in terms
of the "${PN}" variable. So the php recipe contains references to
"${PN}-cgi" but rather than "php-cgi".
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How and where does yocto find lighttpd-module-fastcgi?

[Andre McCurdy]

On Thu, Mar 8, 2018 at 1:52 PM, Wayne Witzke  wrote:
>
> However, now I am attempting to determine if mod_openssl is installed on my
> server, and using "CORE_EXTRA_IMAGES_INSTALL += 'lighttpd-module-openssl'"
> to simply add it does NOT magically work like it did with
> lighttpd-module-fastcgi. My original guess was that adding
> "CORE_EXTRA_IMAGES_INSTALL += 'lighttpd-module-fastcgi'" caused a
> configuration option to be matched in the lighttpd.bb file so that the
> appropriate build option was used when building lighttpd.

No, that's not how it works. A very key point to understand with OE is
that options associated with one recipe can never affect the build of
another recipe (in this case, the image recipe can't affect the build
of the lighttpd recipe).

If adding lighttpd-module-fastcgi to your image worked, it's because
the lighttpd recipe was already creating that package.

> However, fastcgi
> doesn't actually show up in that file at all, and openssl does, so that
> clearly isn't the option . . . furthermore, mod_fastcgi doesn't appear in
> *any* of the layers I'm using to build, except in the lighttpd.conf portion
> of the recipe-extended/lighttpd directory structure.

If lighttpd doesn't have a configure option to control building of the
fastcgi module, then there won't be a PACKAGECONFIG option for it in
the recipe - it will just always be built.

(Even if lighttpd does have a configure option for the fastcgi module,
there's no guarantee that the recipe will allow it to be controlled -
it's common for PACKAGECONFIG options in recipes to only reflect the
configure options which people care about the most).

> So, my question is, how does bitbake know what to do when I add
> lighttpd-module-fastcgi,

The build for lighttpd isn't affected by whether or not you add
lighttpd-module-fastcgi to your image.

ie running "bitbake lighttpd", should always result in a package for
lighttpd-module-fastcgi being placed in tmp/deploy/ipk/i586/ (or
whatever your packaging format / architecture combination is). It
doesn't matter what image you may choose to build later, or what
packages you choose to include in it.

> and where in the world does it find the source for
> mod_fastcgi?

The source which gets compiled into lighttpd-module-fastcgi must be
coming from lighttpd.

> Thank you in advance for your help :)
>
> Wayne
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Bitbake recipe using CMake that requires python-six as part of compiling?

[Andre McCurdy]

On Tue, Mar 6, 2018 at 2:24 PM, Giordon Stark  wrote:
> Is there a good recipe to follow where the normal rules apply for packaging
> and such? I had a hard time finding one that wasn't a rabbit-hole of *.inc
> files.

Start with the default packaging rules in meta/conf/bitbake.conf

Any packaging rules you find in a recipe are by definition workarounds
for oddly installed files or custom rules to handle packaging
requirements which don't fit the standard model - so not an ideal
reference when trying to understand the basics.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Bitbake recipe using CMake that requires python-six as part of compiling?

[Andre McCurdy]

On Tue, Mar 6, 2018 at 2:12 PM, Giordon Stark  wrote:
> Hi Andre,
>
> I tried without
>
> FILES_${PN}_append = "${includedir}/open62541.h"
>
> and got a QA error about a file installed that was not added to a
> package I don't understand the ${PN}-dev here, and I'm not sure how
> packaging works in this context - since it's not clear to me which files get
> installed and which don't... except for when a recipe that depends on this
> breaks because it can't find the header file.

So you seem to have got yourself into a situation where the normal
rules don't apply. Good luck!
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Bitbake recipe using CMake that requires python-six as part of compiling?

[Andre McCurdy]

On Tue, Mar 6, 2018 at 1:03 PM, Giordon Stark  wrote:
> Yes. The CMakeLists file definitely doesn't install that (annoyingly).
> Playing around a bit, I created a test recipe, added these lines in my
> open62541.inc file (original recipe here)
>
> do_install_append() {
>   install -d ${D}${includedir}
>   install -m 644 ${B}/open62541.h ${D}${includedir}
> }
>
> FILES_${PN}_append = "${includedir}/open62541.h"

This is trying to put the header in the runtime package (ie the
package containing files which typically end up in the target rootfs).
Header files should be in the ${PN}-dev package instead.

Since the default packaging rules already cover header files, you
don't actually need to add anything here in order to have the header
packaged correctly - just remove that line.

Note that you also tried to use _append without a leading space -
which is wrong in this context (it's wrong in almost every context).

> and it looks like the test recipe can pick up that header file correctly. So
> I think this is correct-er (at least for code that uses #include
> ).
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-gplv2][PATCH] gnutls: update 3.3.28 -> 3.3.29

[Andre McCurdy]

* Version 3.3.29 (released 2018-02-16)

** libgnutls: Fixed issue which caused 1-byte handshake fragments to be refused.
   Reported by Balázs Kéri.

** libgnutls: Fixed interoperability issue with openssl when safe renegotiation 
was
   used. Resolves gitlab issue #259.

** libgnutls: Use readdir() instead of readdir_r internally. The latter
   is deprecated and on our use we don't need readdir() to be thread safe
   (which it is in most common platforms).

** libgnutls: require strict DER encoding for certificates, OCSP requests, 
private
   keys, CRLs and certificate requests.  This backports the already default 
behavior
   from the 3.5.x branch, in order to reduce issues due to the complexity of 
BER rules.

** libgnutls: Addressed issue in the AES-CBC acceleration under ssse3 (patch by
   Vitezslav Cizek).

** libgnutls: Addressed issue in the accelerated code which may affect 
interoperability
   with versions of nettle > 3.4.

** p11tool: Fixed issue preventing the deletion of objects in batch mode.

** p11tool: Mark all generated objects as sensitive by default.

** API and ABI modifications:
No changes since last version.

Signed-off-by: Andre McCurdy <armccu...@gmail.com>
---
 recipes-support/gnutls/gnutls_3.3.28.bb | 8 
 recipes-support/gnutls/gnutls_3.3.29.bb | 8 
 2 files changed, 8 insertions(+), 8 deletions(-)
 delete mode 100644 recipes-support/gnutls/gnutls_3.3.28.bb
 create mode 100644 recipes-support/gnutls/gnutls_3.3.29.bb

diff --git a/recipes-support/gnutls/gnutls_3.3.28.bb 
b/recipes-support/gnutls/gnutls_3.3.28.bb
deleted file mode 100644
index 1b23369..000
--- a/recipes-support/gnutls/gnutls_3.3.28.bb
+++ /dev/null
@@ -1,8 +0,0 @@
-require gnutls.inc
-
-SRC_URI += " \
-file://configure.ac-fix-sed-command.patch \
-file://use-pkg-config-to-locate-zlib.patch \
-"
-SRC_URI[md5sum] = "e19718d97cee5279edf3f3b9318f926c"
-SRC_URI[sha256sum] = 
"608f63441abc209c5bd5f61e35f2b6128c22e06fa2ad6248a08d8a643feeb807"
diff --git a/recipes-support/gnutls/gnutls_3.3.29.bb 
b/recipes-support/gnutls/gnutls_3.3.29.bb
new file mode 100644
index 000..21099eb
--- /dev/null
+++ b/recipes-support/gnutls/gnutls_3.3.29.bb
@@ -0,0 +1,8 @@
+require gnutls.inc
+
+SRC_URI += " \
+file://configure.ac-fix-sed-command.patch \
+file://use-pkg-config-to-locate-zlib.patch \
+"
+SRC_URI[md5sum] = "de7a58232d42b1d71baf38a06dc34412"
+SRC_URI[sha256sum] = 
"fa9d13f1bc35b81fac85152906b8d4950f4f5a90d76d5b406c1167728770c94a"
-- 
1.9.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] behind corporate proxy

[Andre McCurdy]

On Wed, Feb 21, 2018 at 5:11 AM, Staffa, Christian AVL/DE
 wrote:
> Hi all
>
> I have got a problem with proxy settings and the yocto build system.
>
> I already read the ‘Behind a Proxy Guide’ and generally it works.
>
> But when it comes to build the linux-yocto package the buildsystem tries to
> clone a repo with the git:// scheme.
>
> This results in connecting to git.yoctoproject.org:9418 but this port is
> blocked by the corporate proxy and causes the build to fail.
>
> Had anyone the same problem? Is there a way to fetch the repo via http(s)?

Yes, many people have the same problem.

If you can update to OE 2.3 or above then this commit should provide a
fallback to fetch the repo using https:

  
http://git.openembedded.org/openembedded-core/commit/?id=abb8895d5b42a5dc171360a261a2652acd14ee7e

If you can't update, that patch should be an easy backport to older releases.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Error do_compile libepoxy

[Andre McCurdy]

On Thu, Jan 18, 2018 at 5:49 AM, Alexander Kanavin
 wrote:
> On 01/18/2018 03:41 PM, Andrea Galbusera wrote:
>>
>> Yes, this is coherent with what Alexander's commit message says. We
>> started building stuff in test/ while switching to meson...
>> If we can't easily fix the upstream ourself and/or reproduce outside
>> of OE to ask for help from upstream devels, IMO we should temporarily
>> prevent meson from building the tests.
>
> Note that this same test does build fine in poky, so disabling the tests is
> not a good fix. You should figure out what is about the non-poky EGL headers
> that is causing the failure, and whether you need to configure the provider
> of those headers differently, or add missing dependencies etc.

Upstream documents that the test suite relies on X11:

  https://github.com/anholt/libepoxy/blob/1.4.3/README.md#building

So disabling the test suite for targets without X11 seems like a
perfectly reasonable approach.

> Alex
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [poky] Fwd: How to make the os-release package work with local walltime instead of GMT?

[Andre McCurdy]

On Mon, Jan 15, 2018 at 9:20 PM, Trevor Woerner  wrote:
> On Thu, Jan 11, 2018 at 12:26 AM, Robert Yang 
> wrote:
>>
>> BUILD_ID = "${@time.strftime('%Y-%m-%d %H:%M:%S',time.localtime())}"
>
> Brilliant! Why isn't this the default?

Using localtime could cause confusion for teams which span different time zones.

Even if everyone is in the same time zone, it can also give unexpected
results when entering or leaving daylight savings time.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] PROVIDES problem building u-boot variants

[Andre McCurdy]

On Mon, Jan 15, 2018 at 7:12 AM,   wrote:
> Let's see if I can explain this well...
>
> I created a recipe to build a u-boot variant (for prod'n programming) -
> "u-boot-PLATFORM-mfg-sec.bb" - which has :
>
> require u-boot-PLATFORM.inc
> UBOOT_MACHINE = "tx6s-8035_mfg_sec_config"
> SRC_URI += "file://tx6s-8035_mfg_sec_defconfig"
>
> And 'bitbake u-boot-PLATFORM-mfg-sec' works ok with this.
>
> Now I want to split this out into two different variants, for different
> cpu's.
>
> So I begin by renaming the recipe to "u-boot-PLATFORM_tx6s-mfg-sec.bb",
> But 'bitbake u-boot-PLATFORM_tx6s-mfg-sec'  throws:
>"Nothing PROVIDES 'u-boot- PLATFORM_tx6s-mfg-sec'"
>
> Can't spot why this simple renaming is breaking things...?

You tried to use an underscore in the recipe name.

u-boot-PLATFORM_tx6s-mfg-sec.bb will be treated as version
"tx6s-mfg-sec" of the "u-boot-PLATFORM" recipe.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Some trivial question about git update-ref refs/heads/rocko ...

[Andre McCurdy]

On Wed, Dec 20, 2017 at 8:32 AM, Zoran Stojsavljevic
 wrote:
> I am trying to upgrade my poky distro with current HEAD:
> 65d23bd7986615fdfb0f1717b615534a2a14ab80
>
> It is ~ one month old.
>
> And to the latest HEAD:370483fce1c2429c81b19dcf8a36394dc3fc3d92
> http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=370483fce1c2429c81b19dcf8a36394dc3fc3d92
>
> The transcript what I do is below:
> [user@localhost poky]$ pwd
> /home/user/YOCTO/oe_core_embedded/poky
> [user@localhost poky]$ git update-ref refs/heads/rocko
> 370483fce1c2429c81b19dcf8a36394dc3fc3d92
> fatal: update_ref failed for ref 'refs/heads/rocko': cannot update ref
> 'refs/heads/rocko': trying to write ref 'refs/heads/rocko' with nonexistent
> object 370483fce1c2429c81b19dcf8a36394dc3fc3d92
> [user@localhost poky]$ git update-ref refs/heads/rocko HEAD
> 370483fce1c2429c81b19dcf8a36394dc3fc3d92
> fatal: update_ref failed for ref 'refs/heads/rocko': cannot lock ref
> 'refs/heads/rocko': is at 65d23bd7986615fdfb0f1717b615534a2a14ab80 but
> expected 370483fce1c2429c81b19dcf8a36394dc3fc3d92
> [user@localhost poky]$
>
> What I am doing wrong?!

To switch from rocko to master, try:

  git fetch origin
  git checkout -B master origin/master
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-gplv2][PATCH 3/3] gettext: fix compilation with securityflags enabled

[Andre McCurdy]

From: Phong Tran 

Signed-off-by: Phong Tran 
---
 ...grep-fix-compile-error-Werror-format-secu.patch | 88 ++
 recipes-core/gettext/gettext_0.16.1.bb |  1 +
 2 files changed, 89 insertions(+)
 create mode 100644 
recipes-core/gettext/gettext-0.16.1/0001-gettext-libgrep-fix-compile-error-Werror-format-secu.patch

diff --git 
a/recipes-core/gettext/gettext-0.16.1/0001-gettext-libgrep-fix-compile-error-Werror-format-secu.patch
 
b/recipes-core/gettext/gettext-0.16.1/0001-gettext-libgrep-fix-compile-error-Werror-format-secu.patch
new file mode 100644
index 000..d51513d
--- /dev/null
+++ 
b/recipes-core/gettext/gettext-0.16.1/0001-gettext-libgrep-fix-compile-error-Werror-format-secu.patch
@@ -0,0 +1,88 @@
+From b0e57fc44ee102c668f13a324360fb2f27ee7538 Mon Sep 17 00:00:00 2001
+From: Phong Tran 
+Date: Fri, 8 Dec 2017 07:56:58 +0700
+Subject: [PATCH] gettext libgrep fix compile error -Werror=format-security
+
+---
+ gettext-tools/libgrep/m-fgrep.c |  4 ++--
+ gettext-tools/libgrep/m-regex.c | 12 ++--
+ 2 files changed, 8 insertions(+), 8 deletions(-)
+
+diff --git a/gettext-tools/libgrep/m-fgrep.c b/gettext-tools/libgrep/m-fgrep.c
+index 28f900c..2e49a74 100644
+--- a/gettext-tools/libgrep/m-fgrep.c
 b/gettext-tools/libgrep/m-fgrep.c
+@@ -55,7 +55,7 @@ Fcompile (const char *pattern, size_t pattern_size,
+   for (lim = beg; lim < pattern + pattern_size && *lim != '\n'; ++lim)
+   ;
+   if ((err = kwsincr (ckwset->kwset, beg, lim - beg)) != NULL)
+-  error (exit_failure, 0, err);
++  error (exit_failure, 0, "%s", err);
+   if (lim < pattern + pattern_size)
+   ++lim;
+   beg = lim;
+@@ -63,7 +63,7 @@ Fcompile (const char *pattern, size_t pattern_size,
+   while (beg < pattern + pattern_size);
+ 
+   if ((err = kwsprep (ckwset->kwset)) != NULL)
+-error (exit_failure, 0, err);
++error (exit_failure, 0, "%s", err);
+   return ckwset;
+ }
+ 
+diff --git a/gettext-tools/libgrep/m-regex.c b/gettext-tools/libgrep/m-regex.c
+index 6f7aae3..70f04b3 100644
+--- a/gettext-tools/libgrep/m-regex.c
 b/gettext-tools/libgrep/m-regex.c
+@@ -73,7 +73,7 @@ struct compiled_regex {
+ void
+ dfaerror (const char *mesg)
+ {
+-  error (exit_failure, 0, mesg);
++  error (exit_failure, 0, "%s", mesg);
+ }
+ 
+ /* If the DFA turns out to have some set of fixed strings one of
+@@ -99,7 +99,7 @@ kwsmusts (struct compiled_regex *cregex,
+   continue;
+ cregex->kwset_exact_matches++;
+ if ((err = kwsincr (cregex->ckwset.kwset, dm->must, strlen 
(dm->must))) != NULL)
+-  error (exit_failure, 0, err);
++  error (exit_failure, 0, "%s", err);
+   }
+   /* Now, we compile the substrings that will require
+the use of the regexp matcher.  */
+@@ -108,10 +108,10 @@ kwsmusts (struct compiled_regex *cregex,
+ if (dm->exact)
+   continue;
+ if ((err = kwsincr (cregex->ckwset.kwset, dm->must, strlen 
(dm->must))) != NULL)
+-  error (exit_failure, 0, err);
++  error (exit_failure, 0, "%s", err);
+   }
+   if ((err = kwsprep (cregex->ckwset.kwset)) != NULL)
+-  error (exit_failure, 0, err);
++  error (exit_failure, 0, "%s", err);
+ }
+ }
+ 
+@@ -161,7 +161,7 @@ Gcompile (const char *pattern, size_t pattern_size,
+ 
+   if ((err = re_compile_pattern (motif, len,
+
&(cregex->patterns[cregex->pcount].regexbuf))) != NULL)
+-  error (exit_failure, 0, err);
++  error (exit_failure, 0, "%s", err);
+   cregex->pcount++;
+ 
+   motif = sep;
+@@ -247,7 +247,7 @@ compile (const char *pattern, size_t pattern_size,
+ 
+   if ((err = re_compile_pattern (motif, len,
+
&(cregex->patterns[cregex->pcount].regexbuf))) != NULL)
+-  error (exit_failure, 0, err);
++  error (exit_failure, 0, "%s", err);
+   cregex->pcount++;
+ 
+   motif = sep;
+-- 
+2.7.4
+
diff --git a/recipes-core/gettext/gettext_0.16.1.bb 
b/recipes-core/gettext/gettext_0.16.1.bb
index e79f4da..dacdfd3 100644
--- a/recipes-core/gettext/gettext_0.16.1.bb
+++ b/recipes-core/gettext/gettext_0.16.1.bb
@@ -19,6 +19,7 @@ SRC_URI = "${GNU_MIRROR}/gettext/gettext-${PV}.tar.gz \
file://fix_aclocal_version.patch \
file://fix_gnu_source_circular.patch \
file://hardcode_macro_version.patch \
+   
file://0001-gettext-libgrep-fix-compile-error-Werror-format-secu.patch \
   "
 
 SRC_URI[md5sum] = "3d9ad24301c6d6b17ec30704a13fe127"
-- 
1.9.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-gplv2][PATCH 2/3] elfutils_0.148: musl build fixes

[Andre McCurdy]

Signed-off-by: Andre McCurdy <armccu...@gmail.com>
---
 .../musl-support-for-elfutils-0.148.patch  | 133 +
 recipes-devtools/elfutils/elfutils_0.148.bb|   9 +-
 2 files changed, 140 insertions(+), 2 deletions(-)
 create mode 100644 
recipes-devtools/elfutils/elfutils-0.148/musl-support-for-elfutils-0.148.patch

diff --git 
a/recipes-devtools/elfutils/elfutils-0.148/musl-support-for-elfutils-0.148.patch
 
b/recipes-devtools/elfutils/elfutils-0.148/musl-support-for-elfutils-0.148.patch
new file mode 100644
index 000..5a52d6d
--- /dev/null
+++ 
b/recipes-devtools/elfutils/elfutils-0.148/musl-support-for-elfutils-0.148.patch
@@ -0,0 +1,133 @@
+From 8a6cefcd35fb0ba6e12afc6611cfeb600865ca17 Mon Sep 17 00:00:00 2001
+From: Andre McCurdy <armccu...@gmail.com>
+Date: Wed, 27 Sep 2017 21:32:27 -0700
+Subject: [PATCH] musl build fixes
+
+Upstream-Status: Inappropriate [legacy version]
+
+Signed-off-by: Andre McCurdy <armccu...@gmail.com>
+---
+ lib/fixedsizehash.h   |  4 ++--
+ lib/system.h  | 11 +++
+ libelf/elf.h  |  8 ++--
+ libelf/elf_begin.c|  4 ++--
+ libelf/elf_getarsym.c |  2 +-
+ libelf/libelf.h   |  1 +
+ 6 files changed, 23 insertions(+), 7 deletions(-)
+
+diff --git a/lib/fixedsizehash.h b/lib/fixedsizehash.h
+index a686051..3118954 100644
+--- a/lib/fixedsizehash.h
 b/lib/fixedsizehash.h
+@@ -51,12 +51,12 @@
+ #include 
+ #include 
+ #include 
+-#include 
+ #include 
+ 
+ #include 
+ 
+-#define CONCAT(t1,t2) __CONCAT (t1,t2)
++#define CONCAT1(x,y) x##y
++#define CONCAT(x,y) CONCAT1(x,y)
+ 
+ /* Before including this file the following macros must be defined:
+ 
+diff --git a/lib/system.h b/lib/system.h
+index 10b4734..a9cb35e 100644
+--- a/lib/system.h
 b/lib/system.h
+@@ -52,6 +52,17 @@
+ #include 
+ #include 
+ 
++#ifndef TEMP_FAILURE_RETRY
++#define TEMP_FAILURE_RETRY(expression)\
++  (__extension__  \
++({ long int __result; \
++   do __result = (long int) (expression); \
++   while (__result == -1L && errno == EINTR); \
++   __result; }))
++#endif
++
++#define error(status, errno, ...) err(status, __VA_ARGS__)
++
+ extern void *xmalloc (size_t) __attribute__ ((__malloc__));
+ extern void *xcalloc (size_t, size_t) __attribute__ ((__malloc__));
+ extern void *xrealloc (void *, size_t) __attribute__ ((__malloc__));
+diff --git a/libelf/elf.h b/libelf/elf.h
+index 4158764..6d9af96 100644
+--- a/libelf/elf.h
 b/libelf/elf.h
+@@ -23,7 +23,9 @@
+ 
+ #include 
+ 
+-__BEGIN_DECLS
++#ifdef __cplusplus
++extern "C" {
++#endif
+ 
+ /* Standard ELF types.  */
+ 
+@@ -2909,6 +2911,8 @@ typedef Elf32_Addr Elf32_Conflict;
+ #define R_M32R_NUM256 /* Keep this the last entry. */
+ 
+ 
+-__END_DECLS
++#ifdef __cplusplus
++}
++#endif
+ 
+ #endif/* elf.h */
+diff --git a/libelf/elf_begin.c b/libelf/elf_begin.c
+index 0b38991..9083736 100644
+--- a/libelf/elf_begin.c
 b/libelf/elf_begin.c
+@@ -819,7 +819,7 @@ __libelf_next_arhdr_wrlock (elf)
+ }
+ 
+   /* Copy the raw name over to a NUL terminated buffer.  */
+-  *((char *) __mempcpy (elf->state.ar.raw_name, ar_hdr->ar_name, 16)) = '\0';
++  *((char *) mempcpy (elf->state.ar.raw_name, ar_hdr->ar_name, 16)) = '\0';
+ 
+   elf_ar_hdr = >state.ar.elf_ar_hdr;
+ 
+@@ -911,7 +911,7 @@ __libelf_next_arhdr_wrlock (elf)
+   const char *string = ar_hdr->FIELD;   \
+   if (ar_hdr->FIELD[sizeof (ar_hdr->FIELD) - 1] != ' ') \
+   { \
+-*((char *) __mempcpy (buf, ar_hdr->FIELD, sizeof (ar_hdr->FIELD)))  \
++*((char *) mempcpy (buf, ar_hdr->FIELD, sizeof (ar_hdr->FIELD)))\
+   = '\0';   \
+ string = buf;   \
+   } \
+diff --git a/libelf/elf_getarsym.c b/libelf/elf_getarsym.c
+index 9ff7f29..74339ce 100644
+--- a/libelf/elf_getarsym.c
 b/libelf/elf_getarsym.c
+@@ -257,7 +257,7 @@ elf_getarsym (elf, ptr)
+ else
+   arsym[cnt].as_off = file_data[cnt];
+ arsym[cnt].as_hash = _dl_elf_hash (str_data);
+-str_data = rawmemchr (str_data, '\0') + 1;
++str_data = memchr (str_data, '\0', SIZE_MAX) + 1;
+   }
+ /* At the end a special entry.  */
+ arsym[n].as_name = NULL;
+diff --git a/libelf/libelf.h b/libelf/libelf.h
+index b0b3a8d..ec15c43 100644
+--- a/libelf/libelf.h
 b/libelf/libelf.h
+@@ -50,6 +50,7 @@
+ #ifndef _LIBELF_H
+ #define _LIBELF_H 1
+ 
++#include 
+ #include 
+ 
+ /* Get the ELF types.  */
+-- 
+1.9.1
+
diff --git a/recipes-devtools/elfutils/elfuti

[yocto] [meta-gplv2][PATCH 1/3] gnutls: update 3.3.27 -> 3.3.28

[Andre McCurdy]

* Version 3.3.28 (released 2017-07-04)

** libgnutls: Fixed issue when rehandshaking without a client certificate in
   a session which initially used one. Reported by Frantisek Sumsal.

** libgnutls: fix issue in RSA-PSK client callback which resulted in no username
   being sent to the peer. Patch by Nicolas Dufresne.

** libgnutls: no longer parse the ResponseID field of the status response
   TLS extension. The field is not used by GnuTLS nor is made available to
   calling applications. That addresses a null pointer dereference on server
   side caused by packets containing the ResponseID field. Reported
   by Hubert Kario. [GNUTLS-SA-2017-4]

** libgnutls: Handle specially HSMs which request explicit authentication.
   There are HSMs which return CKR_USER_NOT_LOGGED_IN on the first private key
   operation. Detect that state and try to login.

** libgnutls: the GNUTLS_PKCS11_OBJ_FLAG_LOGIN will force a login on HSMs.
   That is, even in tokens which do not have a CKF_LOGIN_REQUIRED flag
   a login will be forced. This improves operation on certain Safenet HSMs.

** libgnutls: do not set leading zeros when copying integers on HSMs.
   PKCS#11 defines integers as unsigned having most significant byte
   first, e.g., 32768 = 0x80 0x00. This is interpreted literraly by
   some HSMs which do not accept an integer with a leading zero. This
   improves operation with certain Atos HSMs.

** libgnutls: Backported PKCS#11 key generation functionality for DSA keys.

** libgnutls: Improve check for /dev/urandom uniqueness. Ensure that when
   gnutls_global_init() is called for a second time that /dev/urandom is
   re-opened when the inode or device ID has changed.

** API and ABI modifications:
No changes since last version.

Signed-off-by: Andre McCurdy <armccu...@gmail.com>
---
 recipes-support/gnutls/gnutls.inc   |  9 -
 recipes-support/gnutls/gnutls_3.3.27.bb | 17 -
 recipes-support/gnutls/gnutls_3.3.28.bb |  8 
 3 files changed, 12 insertions(+), 22 deletions(-)
 delete mode 100644 recipes-support/gnutls/gnutls_3.3.27.bb
 create mode 100644 recipes-support/gnutls/gnutls_3.3.28.bb

diff --git a/recipes-support/gnutls/gnutls.inc 
b/recipes-support/gnutls/gnutls.inc
index 4a5c3df..4cf375f 100644
--- a/recipes-support/gnutls/gnutls.inc
+++ b/recipes-support/gnutls/gnutls.inc
@@ -8,9 +8,8 @@ LICENSE_${PN}-xx = "LGPLv2.1+"
 LICENSE_${PN}-bin = "GPLv3+"
 LICENSE_${PN}-openssl = "GPLv3+"
 
-LIC_FILES_CHKSUM = "file://LICENSE;md5=71391c8e0c1cfe68077e7fce3b586283 \
-file://doc/COPYING;md5=d32239bcb673463ab874e80d47fae504 \
-
file://doc/COPYING.LESSER;md5=a6f89e2100d9b6cdffcea4f398e37343"
+LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504 \
+file://COPYING.LESSER;md5=a6f89e2100d9b6cdffcea4f398e37343"
 
 DEPENDS = "nettle gmp virtual/libiconv"
 DEPENDS_append_libc-musl = " argp-standalone"
@@ -21,9 +20,8 @@ SRC_URI = 
"ftp://ftp.gnutls.org/gcrypt/gnutls/v${SHRT_VER}/gnutls-${PV}.tar.xz;
 
 inherit autotools texinfo binconfig pkgconfig gettext lib_package gtk-doc
 
-PACKAGECONFIG ??= "libidn zlib"
+PACKAGECONFIG ??= "zlib"
 
-PACKAGECONFIG[libidn] = "--with-idn,--without-idn,libidn"
 PACKAGECONFIG[libtasn1] = 
"--with-included-libtasn1=no,--with-included-libtasn1,libtasn1"
 PACKAGECONFIG[p11-kit] = "--with-p11-kit,--without-p11-kit,p11-kit"
 PACKAGECONFIG[tpm] = "--with-tpm,--without-tpm,trousers"
@@ -31,6 +29,7 @@ PACKAGECONFIG[zlib] = "--with-zlib,--without-zlib,zlib"
 
 EXTRA_OECONF = " \
 --enable-doc \
+--disable-crywrap \
 --disable-libdane \
 --disable-guile \
 --disable-rpath \
diff --git a/recipes-support/gnutls/gnutls_3.3.27.bb 
b/recipes-support/gnutls/gnutls_3.3.27.bb
deleted file mode 100644
index a1dcdb5..000
--- a/recipes-support/gnutls/gnutls_3.3.27.bb
+++ /dev/null
@@ -1,17 +0,0 @@
-require gnutls.inc
-
-LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504 \
-file://COPYING.LESSER;md5=a6f89e2100d9b6cdffcea4f398e37343"
-
-SRC_URI += " \
-file://configure.ac-fix-sed-command.patch \
-file://use-pkg-config-to-locate-zlib.patch \
-"
-SRC_URI[md5sum] = "8ee8cebd7f7575b11f232766a21c31d3"
-SRC_URI[sha256sum] = 
"8dfda16c158ef5c134010d51d1a91d02aa5d43b8cb711b1572650a7ffb56b17f"
-
-# This version doesn't support this option added in newer gnutls
-# ERROR: gnutls-3.3.27-r0 do_configure: QA Issue: gnutls: configure was passed 
unrecognised options: --with-idn [unknown-configure-option]
-PACKAGECONFIG[libidn] = ""
-# but it still has the libidn dependency, without this option
-EXTRA_OECONF += "--disable-crywrap"
diff --git a/recipes-support/gnutls/gnutls_3.3.28.bb 
b/recipes-support/gnutls/gnutls_3.3.28.bb
new file m

[yocto] [meta-gplv2][PATCH 0/3] Consolidated re-send of previously submitted patches

[Andre McCurdy]

Andre McCurdy (2):
  gnutls: update 3.3.27 -> 3.3.28
  elfutils_0.148: musl build fixes

Phong Tran (1):
  gettext: fix compilation with securityflags enabled

 ...grep-fix-compile-error-Werror-format-secu.patch |  88 ++
 recipes-core/gettext/gettext_0.16.1.bb |   1 +
 .../musl-support-for-elfutils-0.148.patch  | 133 +
 recipes-devtools/elfutils/elfutils_0.148.bb|   9 +-
 recipes-support/gnutls/gnutls.inc  |   9 +-
 recipes-support/gnutls/gnutls_3.3.27.bb|  17 ---
 recipes-support/gnutls/gnutls_3.3.28.bb|   8 ++
 7 files changed, 241 insertions(+), 24 deletions(-)
 create mode 100644 
recipes-core/gettext/gettext-0.16.1/0001-gettext-libgrep-fix-compile-error-Werror-format-secu.patch
 create mode 100644 
recipes-devtools/elfutils/elfutils-0.148/musl-support-for-elfutils-0.148.patch
 delete mode 100644 recipes-support/gnutls/gnutls_3.3.27.bb
 create mode 100644 recipes-support/gnutls/gnutls_3.3.28.bb

-- 
1.9.1

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi] error executing python function in linux-raspberrypi-dev

[Andre McCurdy]

On Fri, Dec 15, 2017 at 11:24 AM, Sherif Omran
 wrote:
>
> note that i am not mixing branches

Yes you are.

You have somehow setup a rocko build (path ~/yocto-rocko/...), which
is using recipes from the morty branch of meta-oe
(/home/sherif/yocto/poky/meta-openembedded/meta-networking/recipes-support/nis/ypbind-mt_1.38.bb).
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] How to disable a linux virtual terminal...

[Andre McCurdy]

On Thu, Dec 14, 2017 at 1:51 PM, Greer, Charles (ext)
 wrote:
> Hi all,
>
> Would anyone know how to disable the virtual terminals in linux?  I am using
> Yocto, Morty version on an i.MX6 processor.

Try adding:

  USE_VT = "0"

to your machine config file.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] recipe to clean up files from rootfs

[Andre McCurdy]

On Wed, Dec 13, 2017 at 11:06 PM, Sherif Omran
 wrote:
> Here is my recipe, it runs suceeds but does not delete the files
>
> mypostprocesfunction() {
> rm -r ${IMAGE_ROOTFS}/etc/init.d/psplash.sh
> rm -r ${IMAGE_ROOTFS}/usr/bin/psplash*
> }
>
> ROOTFS_POSTPROCESS_COMMAND += "mypostprocessfunction; "
>

I think you are fundamentally misunderstanding how recipes work. At a
very high level, recipes are used to compile sources into installable
packages (e.g. ipk or rpm files) and then (as a separate step) an
image recipe creates the rootfs by unpacking a set of installable
packages.

One recipe can depend on the output of another (e.g. an image recipe
depends on the installable packages created by other recipes) but each
recipe has it's own execution environment. You can't expect to write a
recipe which changes the behaviour of another recipe, so writing a new
recipe to remove some files from the rootfs created by the image
recipe is fundamentally wrong. It's never going to work, even if you
fix every typo.

As suggested already, the normal and recommended way to remove files
from the rootfs is:

  1) Remove the package which provides the file(s) from the image you
are building (ie don't install the files in the rootfs at all).

If the file(s) you want to remove don't match the granularity of the
installable packages (ie you want to keep some files provided by a
package but remove others) then you have two basic options:

  2) Spilt the installable package into multiple smaller installable
packages (ie modify the packaging rules in the recipe which creates
the installable package).

  3) Postprocess the rootfs. For that to work, you need to add the
postprocessing function ** TO THE IMAGE RECIPE **.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-gplv2][PATCH] elfutils_0.148: musl build fixes

[Andre McCurdy]

Signed-off-by: Andre McCurdy <armccu...@gmail.com>
---
 .../musl-support-for-elfutils-0.148.patch  | 133 +
 recipes-devtools/elfutils/elfutils_0.148.bb|   9 +-
 2 files changed, 140 insertions(+), 2 deletions(-)
 create mode 100644 
recipes-devtools/elfutils/elfutils-0.148/musl-support-for-elfutils-0.148.patch

diff --git 
a/recipes-devtools/elfutils/elfutils-0.148/musl-support-for-elfutils-0.148.patch
 
b/recipes-devtools/elfutils/elfutils-0.148/musl-support-for-elfutils-0.148.patch
new file mode 100644
index 000..5a52d6d
--- /dev/null
+++ 
b/recipes-devtools/elfutils/elfutils-0.148/musl-support-for-elfutils-0.148.patch
@@ -0,0 +1,133 @@
+From 8a6cefcd35fb0ba6e12afc6611cfeb600865ca17 Mon Sep 17 00:00:00 2001
+From: Andre McCurdy <armccu...@gmail.com>
+Date: Wed, 27 Sep 2017 21:32:27 -0700
+Subject: [PATCH] musl build fixes
+
+Upstream-Status: Inappropriate [legacy version]
+
+Signed-off-by: Andre McCurdy <armccu...@gmail.com>
+---
+ lib/fixedsizehash.h   |  4 ++--
+ lib/system.h  | 11 +++
+ libelf/elf.h  |  8 ++--
+ libelf/elf_begin.c|  4 ++--
+ libelf/elf_getarsym.c |  2 +-
+ libelf/libelf.h   |  1 +
+ 6 files changed, 23 insertions(+), 7 deletions(-)
+
+diff --git a/lib/fixedsizehash.h b/lib/fixedsizehash.h
+index a686051..3118954 100644
+--- a/lib/fixedsizehash.h
 b/lib/fixedsizehash.h
+@@ -51,12 +51,12 @@
+ #include 
+ #include 
+ #include 
+-#include 
+ #include 
+ 
+ #include 
+ 
+-#define CONCAT(t1,t2) __CONCAT (t1,t2)
++#define CONCAT1(x,y) x##y
++#define CONCAT(x,y) CONCAT1(x,y)
+ 
+ /* Before including this file the following macros must be defined:
+ 
+diff --git a/lib/system.h b/lib/system.h
+index 10b4734..a9cb35e 100644
+--- a/lib/system.h
 b/lib/system.h
+@@ -52,6 +52,17 @@
+ #include 
+ #include 
+ 
++#ifndef TEMP_FAILURE_RETRY
++#define TEMP_FAILURE_RETRY(expression)\
++  (__extension__  \
++({ long int __result; \
++   do __result = (long int) (expression); \
++   while (__result == -1L && errno == EINTR); \
++   __result; }))
++#endif
++
++#define error(status, errno, ...) err(status, __VA_ARGS__)
++
+ extern void *xmalloc (size_t) __attribute__ ((__malloc__));
+ extern void *xcalloc (size_t, size_t) __attribute__ ((__malloc__));
+ extern void *xrealloc (void *, size_t) __attribute__ ((__malloc__));
+diff --git a/libelf/elf.h b/libelf/elf.h
+index 4158764..6d9af96 100644
+--- a/libelf/elf.h
 b/libelf/elf.h
+@@ -23,7 +23,9 @@
+ 
+ #include 
+ 
+-__BEGIN_DECLS
++#ifdef __cplusplus
++extern "C" {
++#endif
+ 
+ /* Standard ELF types.  */
+ 
+@@ -2909,6 +2911,8 @@ typedef Elf32_Addr Elf32_Conflict;
+ #define R_M32R_NUM256 /* Keep this the last entry. */
+ 
+ 
+-__END_DECLS
++#ifdef __cplusplus
++}
++#endif
+ 
+ #endif/* elf.h */
+diff --git a/libelf/elf_begin.c b/libelf/elf_begin.c
+index 0b38991..9083736 100644
+--- a/libelf/elf_begin.c
 b/libelf/elf_begin.c
+@@ -819,7 +819,7 @@ __libelf_next_arhdr_wrlock (elf)
+ }
+ 
+   /* Copy the raw name over to a NUL terminated buffer.  */
+-  *((char *) __mempcpy (elf->state.ar.raw_name, ar_hdr->ar_name, 16)) = '\0';
++  *((char *) mempcpy (elf->state.ar.raw_name, ar_hdr->ar_name, 16)) = '\0';
+ 
+   elf_ar_hdr = >state.ar.elf_ar_hdr;
+ 
+@@ -911,7 +911,7 @@ __libelf_next_arhdr_wrlock (elf)
+   const char *string = ar_hdr->FIELD;   \
+   if (ar_hdr->FIELD[sizeof (ar_hdr->FIELD) - 1] != ' ') \
+   { \
+-*((char *) __mempcpy (buf, ar_hdr->FIELD, sizeof (ar_hdr->FIELD)))  \
++*((char *) mempcpy (buf, ar_hdr->FIELD, sizeof (ar_hdr->FIELD)))\
+   = '\0';   \
+ string = buf;   \
+   } \
+diff --git a/libelf/elf_getarsym.c b/libelf/elf_getarsym.c
+index 9ff7f29..74339ce 100644
+--- a/libelf/elf_getarsym.c
 b/libelf/elf_getarsym.c
+@@ -257,7 +257,7 @@ elf_getarsym (elf, ptr)
+ else
+   arsym[cnt].as_off = file_data[cnt];
+ arsym[cnt].as_hash = _dl_elf_hash (str_data);
+-str_data = rawmemchr (str_data, '\0') + 1;
++str_data = memchr (str_data, '\0', SIZE_MAX) + 1;
+   }
+ /* At the end a special entry.  */
+ arsym[n].as_name = NULL;
+diff --git a/libelf/libelf.h b/libelf/libelf.h
+index b0b3a8d..ec15c43 100644
+--- a/libelf/libelf.h
 b/libelf/libelf.h
+@@ -50,6 +50,7 @@
+ #ifndef _LIBELF_H
+ #define _LIBELF_H 1
+ 
++#include 
+ #include 
+ 
+ /* Get the ELF types.  */
+-- 
+1.9.1
+
diff --git a/recipes-devtools/elfutils/elfuti

Re: [yocto] Security upgrade stategy

[Andre McCurdy]

On Wed, Nov 29, 2017 at 11:24 AM, Khem Raj  wrote:
> On Wed, Nov 29, 2017 at 11:06 AM, Brian Smucker  wrote:
>> Hello,
>>
>> I have an older yocto-based image built with Danny.
>>
>> We have a need to update two components, php and dropbear, to the most
>> modern versions for security purposes.
>>
>> What is the preferred way to do this without moving the whole image to the
>> latest version of poky/yocto? That would be a big job, which would
>> necessitate migrating my linux dev environment to something newer, in
>> addition to other things.
>>
>> Or is there  a preferred way? How do people handle this?
>
> We usually backport the needed fixes back into release branches.
> Version upgrades
> are usually not the norm. However, in your case where are on danny which might
> have stopped to receive any security fixes already

To avoid and doubt, danny has definitely stopped receiving any security fixes!

>, it might be
> something you can
> undertake in your distro to upgrade the versions. Take the new version
> from latest
> release or master and retrofit it into the release you are on then
> fix/integrate it into
> rest of your distro. However here you have forked and can keep
> following the same
> procedure for subsequent upgrades for these packages. Obviously, you might see
> integration issues but thats expected.
>
>> Thanks,
>>
>> Brian
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-gplv2][PATCH] gnutls: update 3.3.27 -> 3.3.28

[Andre McCurdy]

On Wed, Nov 8, 2017 at 7:45 PM, Andre McCurdy <armccu...@gmail.com> wrote:
> * Version 3.3.28 (released 2017-07-04)
>
> ** libgnutls: Fixed issue when rehandshaking without a client certificate in
>a session which initially used one. Reported by Frantisek Sumsal.
>
> ** libgnutls: fix issue in RSA-PSK client callback which resulted in no 
> username
>being sent to the peer. Patch by Nicolas Dufresne.
>
> ** libgnutls: no longer parse the ResponseID field of the status response
>TLS extension. The field is not used by GnuTLS nor is made available to
>calling applications. That addresses a null pointer dereference on server
>side caused by packets containing the ResponseID field. Reported
>by Hubert Kario. [GNUTLS-SA-2017-4]
>
> ** libgnutls: Handle specially HSMs which request explicit authentication.
>There are HSMs which return CKR_USER_NOT_LOGGED_IN on the first private key
>operation. Detect that state and try to login.
>
> ** libgnutls: the GNUTLS_PKCS11_OBJ_FLAG_LOGIN will force a login on HSMs.
>That is, even in tokens which do not have a CKF_LOGIN_REQUIRED flag
>a login will be forced. This improves operation on certain Safenet HSMs.
>
> ** libgnutls: do not set leading zeros when copying integers on HSMs.
>PKCS#11 defines integers as unsigned having most significant byte
>first, e.g., 32768 = 0x80 0x00. This is interpreted literraly by
>some HSMs which do not accept an integer with a leading zero. This
>improves operation with certain Atos HSMs.
>
> ** libgnutls: Backported PKCS#11 key generation functionality for DSA keys.
>
> ** libgnutls: Improve check for /dev/urandom uniqueness. Ensure that when
>gnutls_global_init() is called for a second time that /dev/urandom is
>re-opened when the inode or device ID has changed.
>
> ** API and ABI modifications:
> No changes since last version.

Ping. CCing Ross.

> Signed-off-by: Andre McCurdy <armccu...@gmail.com>
> ---
>  recipes-support/gnutls/gnutls.inc   |  9 -
>  recipes-support/gnutls/gnutls_3.3.27.bb | 17 -
>  recipes-support/gnutls/gnutls_3.3.28.bb |  8 
>  3 files changed, 12 insertions(+), 22 deletions(-)
>  delete mode 100644 recipes-support/gnutls/gnutls_3.3.27.bb
>  create mode 100644 recipes-support/gnutls/gnutls_3.3.28.bb
>
> diff --git a/recipes-support/gnutls/gnutls.inc 
> b/recipes-support/gnutls/gnutls.inc
> index 4a5c3df..4cf375f 100644
> --- a/recipes-support/gnutls/gnutls.inc
> +++ b/recipes-support/gnutls/gnutls.inc
> @@ -8,9 +8,8 @@ LICENSE_${PN}-xx = "LGPLv2.1+"
>  LICENSE_${PN}-bin = "GPLv3+"
>  LICENSE_${PN}-openssl = "GPLv3+"
>
> -LIC_FILES_CHKSUM = "file://LICENSE;md5=71391c8e0c1cfe68077e7fce3b586283 \
> -file://doc/COPYING;md5=d32239bcb673463ab874e80d47fae504 \
> -
> file://doc/COPYING.LESSER;md5=a6f89e2100d9b6cdffcea4f398e37343"
> +LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504 \
> +
> file://COPYING.LESSER;md5=a6f89e2100d9b6cdffcea4f398e37343"
>
>  DEPENDS = "nettle gmp virtual/libiconv"
>  DEPENDS_append_libc-musl = " argp-standalone"
> @@ -21,9 +20,8 @@ SRC_URI = 
> "ftp://ftp.gnutls.org/gcrypt/gnutls/v${SHRT_VER}/gnutls-${PV}.tar.xz;
>
>  inherit autotools texinfo binconfig pkgconfig gettext lib_package gtk-doc
>
> -PACKAGECONFIG ??= "libidn zlib"
> +PACKAGECONFIG ??= "zlib"
>
> -PACKAGECONFIG[libidn] = "--with-idn,--without-idn,libidn"
>  PACKAGECONFIG[libtasn1] = 
> "--with-included-libtasn1=no,--with-included-libtasn1,libtasn1"
>  PACKAGECONFIG[p11-kit] = "--with-p11-kit,--without-p11-kit,p11-kit"
>  PACKAGECONFIG[tpm] = "--with-tpm,--without-tpm,trousers"
> @@ -31,6 +29,7 @@ PACKAGECONFIG[zlib] = "--with-zlib,--without-zlib,zlib"
>
>  EXTRA_OECONF = " \
>  --enable-doc \
> +--disable-crywrap \
>  --disable-libdane \
>  --disable-guile \
>  --disable-rpath \
> diff --git a/recipes-support/gnutls/gnutls_3.3.27.bb 
> b/recipes-support/gnutls/gnutls_3.3.27.bb
> deleted file mode 100644
> index a1dcdb5..000
> --- a/recipes-support/gnutls/gnutls_3.3.27.bb
> +++ /dev/null
> @@ -1,17 +0,0 @@
> -require gnutls.inc
> -
> -LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504 \
> -
> file://COPYING.LESSER;md5=a6f89e2100d9b6cdffcea4f398e37343"
> -
> -SRC_URI += " \
> -file://configure.ac-fix-sed-command.patch \
> -file://use-pkg-config-to-locate-zlib.patch \
> -"
> -SRC_URI[md5sum] = "8e

[yocto] [meta-gplv2][PATCH] gnutls: update 3.3.27 -> 3.3.28

[Andre McCurdy]

* Version 3.3.28 (released 2017-07-04)

** libgnutls: Fixed issue when rehandshaking without a client certificate in
   a session which initially used one. Reported by Frantisek Sumsal.

** libgnutls: fix issue in RSA-PSK client callback which resulted in no username
   being sent to the peer. Patch by Nicolas Dufresne.

** libgnutls: no longer parse the ResponseID field of the status response
   TLS extension. The field is not used by GnuTLS nor is made available to
   calling applications. That addresses a null pointer dereference on server
   side caused by packets containing the ResponseID field. Reported
   by Hubert Kario. [GNUTLS-SA-2017-4]

** libgnutls: Handle specially HSMs which request explicit authentication.
   There are HSMs which return CKR_USER_NOT_LOGGED_IN on the first private key
   operation. Detect that state and try to login.

** libgnutls: the GNUTLS_PKCS11_OBJ_FLAG_LOGIN will force a login on HSMs.
   That is, even in tokens which do not have a CKF_LOGIN_REQUIRED flag
   a login will be forced. This improves operation on certain Safenet HSMs.

** libgnutls: do not set leading zeros when copying integers on HSMs.
   PKCS#11 defines integers as unsigned having most significant byte
   first, e.g., 32768 = 0x80 0x00. This is interpreted literraly by
   some HSMs which do not accept an integer with a leading zero. This
   improves operation with certain Atos HSMs.

** libgnutls: Backported PKCS#11 key generation functionality for DSA keys.

** libgnutls: Improve check for /dev/urandom uniqueness. Ensure that when
   gnutls_global_init() is called for a second time that /dev/urandom is
   re-opened when the inode or device ID has changed.

** API and ABI modifications:
No changes since last version.

Signed-off-by: Andre McCurdy <armccu...@gmail.com>
---
 recipes-support/gnutls/gnutls.inc   |  9 -
 recipes-support/gnutls/gnutls_3.3.27.bb | 17 -
 recipes-support/gnutls/gnutls_3.3.28.bb |  8 
 3 files changed, 12 insertions(+), 22 deletions(-)
 delete mode 100644 recipes-support/gnutls/gnutls_3.3.27.bb
 create mode 100644 recipes-support/gnutls/gnutls_3.3.28.bb

diff --git a/recipes-support/gnutls/gnutls.inc 
b/recipes-support/gnutls/gnutls.inc
index 4a5c3df..4cf375f 100644
--- a/recipes-support/gnutls/gnutls.inc
+++ b/recipes-support/gnutls/gnutls.inc
@@ -8,9 +8,8 @@ LICENSE_${PN}-xx = "LGPLv2.1+"
 LICENSE_${PN}-bin = "GPLv3+"
 LICENSE_${PN}-openssl = "GPLv3+"
 
-LIC_FILES_CHKSUM = "file://LICENSE;md5=71391c8e0c1cfe68077e7fce3b586283 \
-file://doc/COPYING;md5=d32239bcb673463ab874e80d47fae504 \
-
file://doc/COPYING.LESSER;md5=a6f89e2100d9b6cdffcea4f398e37343"
+LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504 \
+file://COPYING.LESSER;md5=a6f89e2100d9b6cdffcea4f398e37343"
 
 DEPENDS = "nettle gmp virtual/libiconv"
 DEPENDS_append_libc-musl = " argp-standalone"
@@ -21,9 +20,8 @@ SRC_URI = 
"ftp://ftp.gnutls.org/gcrypt/gnutls/v${SHRT_VER}/gnutls-${PV}.tar.xz;
 
 inherit autotools texinfo binconfig pkgconfig gettext lib_package gtk-doc
 
-PACKAGECONFIG ??= "libidn zlib"
+PACKAGECONFIG ??= "zlib"
 
-PACKAGECONFIG[libidn] = "--with-idn,--without-idn,libidn"
 PACKAGECONFIG[libtasn1] = 
"--with-included-libtasn1=no,--with-included-libtasn1,libtasn1"
 PACKAGECONFIG[p11-kit] = "--with-p11-kit,--without-p11-kit,p11-kit"
 PACKAGECONFIG[tpm] = "--with-tpm,--without-tpm,trousers"
@@ -31,6 +29,7 @@ PACKAGECONFIG[zlib] = "--with-zlib,--without-zlib,zlib"
 
 EXTRA_OECONF = " \
 --enable-doc \
+--disable-crywrap \
 --disable-libdane \
 --disable-guile \
 --disable-rpath \
diff --git a/recipes-support/gnutls/gnutls_3.3.27.bb 
b/recipes-support/gnutls/gnutls_3.3.27.bb
deleted file mode 100644
index a1dcdb5..000
--- a/recipes-support/gnutls/gnutls_3.3.27.bb
+++ /dev/null
@@ -1,17 +0,0 @@
-require gnutls.inc
-
-LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504 \
-file://COPYING.LESSER;md5=a6f89e2100d9b6cdffcea4f398e37343"
-
-SRC_URI += " \
-file://configure.ac-fix-sed-command.patch \
-file://use-pkg-config-to-locate-zlib.patch \
-"
-SRC_URI[md5sum] = "8ee8cebd7f7575b11f232766a21c31d3"
-SRC_URI[sha256sum] = 
"8dfda16c158ef5c134010d51d1a91d02aa5d43b8cb711b1572650a7ffb56b17f"
-
-# This version doesn't support this option added in newer gnutls
-# ERROR: gnutls-3.3.27-r0 do_configure: QA Issue: gnutls: configure was passed 
unrecognised options: --with-idn [unknown-configure-option]
-PACKAGECONFIG[libidn] = ""
-# but it still has the libidn dependency, without this option
-EXTRA_OECONF += "--disable-crywrap"
diff --git a/recipes-support/gnutls/gnutls_3.3.28.bb 
b/recipes-support/gnutls/gnutls_3.3.28.bb
new file m

Re: [yocto] [Yocto] Checking sstate mirror is hanging at 100%

[Andre McCurdy]

>>
>> It looks like the logic in the wget fetcher retries once, so if it's getting 
>> stuck
>> then that seems like a genuine bug.
>>
>> Vineeth, are you sure it's really continuously retrying?
> Yes, I see continuous retry of wget of same sstate files.

The fetcher explicitly tries to avoid that by retrying each file only
once. See retry logic in:

  
http://git.openembedded.org/bitbake/commit/?id=54b1961551511948e0cbd2ac39f19b39b9cee568

However, there is a later commit which may also be related:

  
http://git.openembedded.org/bitbake/commit/?id=6fa07752bbd3ac345cd8617da49a70e0b2dd565f

Does the version of bitbake which you are using contain both commits?
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [Yocto] Checking sstate mirror is hanging at 100%

[Andre McCurdy]

On Mon, Oct 30, 2017 at 2:37 AM, Alexander Kanavin
 wrote:
> On 10/30/2017 07:54 AM, Vineeth Karumanchi wrote:
>
>> In this case i would expect bitbake to "check for sstate mirrors" for some
>> time and rebuild from scratch. Is there any approach to over come this ?
>
> The approach is to fix your infrastructure so that fetching from network
> doesn't fail. We've gotten a similar request recently for enabling 'soft
> sstate cache failure', and RP is firmly against it:
>
> http://lists.openembedded.org/pipermail/openembedded-core/2017-August/141593.html

It looks like the logic in the wget fetcher retries once, so if it's
getting stuck then that seems like a genuine bug.

Vineeth, are you sure it's really continuously retrying? Or are you
just seeing timeouts for many fetches (which will eventually
complete)? Note that you can reduce the wget timeout by setting your
own value for "FETCHCMD_wget". See bitbake/lib/bb/fetch2/wget.py for
the default value - use that as a starting point for your
modification.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] image dependent pkg versions/pkg variations

[Andre McCurdy]

On Mon, Oct 16, 2017 at 2:10 AM, Robert Berger
 wrote:
>
> Anyhow, following this idea I was told that there is also something like
> this[1].
>
> So maybe something like this could work:
>
> bitbake \
> multiconfig:customerA:stable-image \
> multiconfig:customerA:bleeding-image \
> multiconfig:customerB:stable-image \
> multiconfig:customerB:bleeding-image
>
> where it would be the same MACHINE, but different images and package
> versions, which could be defined in the configs.
>
> [1]
> http://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#platdev-building-targets-with-multiple-configurations

Good luck!

> Regards,
>
> Robert
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] possible to append or patch existing machine .conf file?

[Andre McCurdy]

On Thu, Oct 12, 2017 at 3:32 AM, Bernd  wrote:
> Suppose I have the following bugfix patch for a 3rd party machine conf
> file I am using:
>
> diff --git a/conf/machine/colibri-vf.conf b/conf/machine/colibri-vf.conf
> index 3ddef79..ba47488 100644
> --- a/conf/machine/colibri-vf.conf
> +++ b/conf/machine/colibri-vf.conf
> @@ -35,6 +35,6 @@ MKUBIFS_ARGS = " -c 8112 -e 124KiB -m 2KiB -F"
>  UBINIZE_ARGS = " -p 128KiB -m 2048 -s 2048"
>  UBI_VOLNAME = "rootfs"
>
> -SERIAL_CONSOLE ?= "115200 ttyLP0"
> +SERIAL_CONSOLE = "115200 ttyLP0"
>
>  MACHINE_FEATURES += "usbgadget usbhost vfat alsa touchscreen"
>
> Is there a proper way to somehow temporarily add something to my layer
> to apply this patch until it makes its way upstream and into the
> branch I am using? Or should I make my own machine file, include the
> original one and then change the variable?

That would be one way. You could also over-ride from any other global
config file, e.g. local.conf or the distro config file (if you have
one).

> So far I have not found any elegant way to otherwise force this
> variable to its correct value in my image recipe

Right, the variable is not used by the image recipe, so setting it
there won't change anything. Variables in an image recipe generally
only relate to how the image is constructed (what packages it contains
and format of the final image - tar.gz, squashfs, etc).

>, the only way I have
> found to work around this bug is to .bbappend the inittab recipe where
> this variable is actually used and change the value of another
> variable (SERIAL_CONSOLES, note the S at the end) which is derived
> from SERIAL_CONSOLE right there in this bbappend file. This seems to
> help.

For variables which are specific to one recipe then over-riding in the
context of that recipe is OK. However, SERIAL_CONSOLES is used in a
few different recipes, so over-riding from a global config file would
necessary to be sure of changing it consistently wherever it's used.

> But while doing this I have also noticed a strange anomaly in the
> output of bitbake -e:
>
> * When I change the variable in my image recipe then bitbake -e will
> show another "set" access and both variables SERIAL_CONSOLE and
> SERIAL_CONSOLES will have the correct value as intended by me but the
> produced image will have the **wrong** entry in its inittab.

If you run bitbake -e for inittab and for the image recipe and compare
the two it should show that setting the variable from within the image
recipe has no effect on the inittab recipe. That's not a bug.

> * When I bbappend the inittab recipe to set SERIAL_CONSOLES right
> there where it is used then my final image will have a correct inittab
> and the serial console will work bit there is **no** mention of that
> variable change in the output of bitbake -e

Similar to above, bitbake -e will give different results for each recipe.

> * Only when I change the machine conf file iitself to set the variable
> then bitbake -e and the produced image both show the correct entry.
> Why does it behave that way?

Because the machine config is a global config file and any variables
it sets are seen by every recipe.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-cgl][PATCH 2/2] cgl-common.inc: append SRC_URI for poky-cgl only

[Andre McCurdy]

On Mon, Oct 9, 2017 at 8:30 PM,   wrote:
> From: Jackie Huang 
>
> Someone may want to add meta-cgl-common layer into their
> distro and only use some of the packages, but these kernel
> features will be also added by the bbappend and may cause
> unexpected issue, so change to append the SRC_URI for poky-cgl
> distro only.
>
> Signed-off-by: Jackie Huang 
> ---
>  meta-cgl-common/recipes-kernel/linux/cgl-common.inc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta-cgl-common/recipes-kernel/linux/cgl-common.inc 
> b/meta-cgl-common/recipes-kernel/linux/cgl-common.inc
> index 52cf773..362a7c4 100644
> --- a/meta-cgl-common/recipes-kernel/linux/cgl-common.inc
> +++ b/meta-cgl-common/recipes-kernel/linux/cgl-common.inc
> @@ -1,6 +1,6 @@
>  FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
>
> -SRC_URI += "file://cfg/1-systemtap.cfg \
> +SRC_URI_append_poky-cgl = "file://cfg/1-systemtap.cfg \

Needs a leading space.

>  file://cfg/2-oprofile.cfg \
>  file://cfg/3-lttng.cfg \
>  file://cfg/4-kgdb.cfg \
> --
> 2.11.0
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] image dependent pkg versions/pkg variations

[Andre McCurdy]

On Wed, Oct 11, 2017 at 11:24 AM, Robert Berger
 wrote:
> Hi,
>
> 3) Different package versions depending on the image recipe?
> Well actually I would like to have root file systems with different recipe
> versions inside
> e.g.
> Customer 1: prg1_1.1.bb, prg2_2.2.bb
> Customer 2: prg1_1.2.bb, prg2_2.1.bb
>
> 4) Different package variants (e.g. extra compile flags) depending on the
> image recipe? Again different content of rootfs.
> e.g.
> Customer 3: prg1_1.1.bb (default), prg2_2.2.bb with extra CFLAGS=-DUMMY)
> Customer 4: prg1_1.2.bb (default), prg2_2.1.bb(default)
>
> ===
>
> Is this possible at all?
>
> I could define per distro image versions, but the name of the distro e.g.
> "poky" seems to be part of the compiler prefix, which is not nice and I
> would need to build the same toolchain multiple times, which again is not
> nice.
>
> If the choice is based on e.g. the distro variable I could use it to
> distinguish in the recipes between different build variations, but again not
> nice.
>
> What would you suggest?

Create additional variants of the machine config to cover each case,
e.g. myboard.conf, myboard-debug.conf, myboard-dummy.conf, etc

The -debug, -dummy, etc variants can include the original base version
of the machine config file, so there doesn't need to be any
duplication.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Basic question: "core-image-minimal" v.s "core-image-base" ?

[Andre McCurdy]

On Fri, Oct 6, 2017 at 1:40 PM, Jerry Lian  wrote:
> Hi, all:
>
> I have a basic question: how to tell the difference between
> "core-image-minimal" and "core-image-base"?
> * If we look at file \poky\meta\recipes-core\images\core-image-base.bb
> ===
> SUMMARY = "A console-only image that fully supports the target device
> hardware."
>
> IMAGE_FEATURES += "splash"
>
> LICENSE = "MIT"
>
> inherit core-image
> ===
> * how can we tell that "core-image-base" will include "support for a variety
> of hardware such as WIFI, bluetooth...", as compare to "core-image-minimal"?
> * Do I miss any other document that I need to read?

core-image-base takes the default value of IMAGE_INSTALL from
meta/classes/core-image.bbclass, but core-image-minimal over-rides the
default value and effectively removes packagegroup-base-extended.

See meta/recipes-core/packagegroups/packagegroup-base.bb for more
details of what gets pulled in by packagegroup-base-extended.

> Thanks!
> Jerry
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto