[yocto] Issue cross-compiling Asterisk 13.16.0

[Chris Trobridge]

I am updating the asterisk recipe to 13.16.0 to fix some security advisories 
and hit an issue in the configuration script new to me:

config.log:
configure:17599: checking if we have usable eventfd support
configure:17602: error: in 
`/home/chris/yocto/build/tmp/work/core2-32-poky-linux/asterisk/13.16.0-r0/asterisk-13.16.0':
configure:17604: error: cannot run test program while cross compiling

configure:
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking if we have usable eventfd 
support" >&5
$as_echo_n "checking if we have usable eventfd support... " >&6; }
if test "$cross_compiling" = yes; then :
  { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
$as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
as_fn_error $? "cannot run test program while cross compiling
See \`config.log' for more details" "$LINENO" 5; }

configure.ac:
AC_MSG_CHECKING([if we have usable eventfd support])
AC_RUN_IFELSE(
  [AC_LANG_PROGRAM([#include ],
      [return eventfd(0, EFD_NONBLOCK | EFD_SEMAPHORE) == -1;])],
  AC_MSG_RESULT(yes)
  AC_DEFINE([HAVE_EVENTFD], 1, [Define to 1 if your system supports eventfd and 
the EFD_NONBLOCK and EFD_SEMAPHORE flags.]),
  AC_MSG_RESULT(no)
)

I can see how this follows through but it's not clear how to fix it.  Thus far 
I think to avoid the test I need to provide a suitable cached value in a site 
file.   A bit of searching found "CACHED_CONFIGUREVARS", which appears to do 
this, but what would the variable name be?

Is this a test I can bypass in this way?

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

[yocto] BB Equivalent for %config(noreplace)

[Chris Trobridge]

When applying rpm updates generated by yocto, configuration files/directories 
are overwritten with files from the rpm.

My spec file for generating equivalent native packages with rpmbuild specifies 
these files with %config(noreplace) so that this overwriting does no occur.

Is it possible to get this information into the rpm files generated by yocto?

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

Re: [yocto] Pre-compiling Python Byte Code

[Chris Trobridge]

Thanks Ross and Jussi,


python3native works in the short term and in the longer term I will look into 
distutils/setuptools.

Cheers,
Chris


From: Burton, Ross <ross.bur...@intel.com>
Sent: 05 May 2017 10:43
To: Chris Trobridge
Cc: Yocto List
Subject: Re: [yocto] Pre-compiling Python Byte Code


On 3 May 2017 at 19:50, Chris Trobridge 
<christrobri...@hotmail.com<mailto:christrobri...@hotmail.com>> wrote:

The following works, as it uses the native python3 compiled by bitbake but it 
feels a little contrived.  Is there a better way of specifying the native 
python3 interpreter, or a better way of getting my python byte code compiled 
prior to generating the packages?

If you inherit python3native then "python3" will be the native python3.

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

[yocto] Pre-compiling Python Byte Code

[Chris Trobridge]

To improve startup speed I have decided to pre-compile python3 byte code in my 
bb recipe.  This is done semi automatically with the rpm build for Fedora but 
I've not found anything similar for Yocto.


I initially tried to use compileall:


python3 -m compileall ${D}/opt/test_app/python


This almost worked but it uses the host python3 to failed with a slight 
difference in magic.


The following works, as it uses the native python3 compiled by bitbake but it 
feels a little contrived.  Is there a better way of specifying the native 
python3 interpreter, or a better way of getting my python byte code compiled 
prior to generating the packages?


${STAGING_BINDIR_NATIVE}/python3-native/python3 -m compileall 
${D}/opt/test_app/python

Cheers,

Chris

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

Re: [yocto] Customize live grub entries

[Chris Trobridge]

> From: yocto-boun...@yoctoproject.org  on 
> behalf of Alvaro Garcia > 
> Sent: 07 April 2017 11:59
> To: yocto@yoctoproject.org
> Subject: [yocto] Customize live grub entries
  

> Hi, I want an unattended installation (just boot from USB, install, and 
> remove USB). I am able to remove all questions during install but I cant 
> customize the grub entries of the live boot. By default is market the option 
> "boot" but I need the  "install" option.

> In the file poky/plain/meta/classes/grub-efi.bbclass I found that the 
> variable GRUB_CFG_LIVE = "${S}/grub_live.cfg" contains the file with this 
> configuration but I cannot find this file. Where the image is built (inside 
> tmp directory) this file exists. I tried  to override the variables 
> "LABELS_LIVE" without success (if I remove the boot option, it also 
> disappears from the installation and cannot boot later).

> Once the image is flashed to an USB memory, the file syslinux_live.cfg exists 
> in the boot partition and if I edit it it works as I want. But this is the 
> bad way, would be great if I can edit it inside yocto build process.

> Anyone knows what recipe should override?

> Thank you

I use:
LABELS_LIVE = "install"

Just before I inherit core-image in my custom image recipe.

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

Re: [yocto] Intermittent Kernel Boot Hang 4.8/Intel Z5 Atom

[Chris Trobridge]

Advice on how to proceed with this?

Current Yocto (morty) kernels include 4.1, 4.4 that work and 4.8 that doesn't.

Intermittent hang during power-on kernel boots before/without any diagnostic 
output.  Can I compile the kernel to output more than boot options allow?

I could fix this BSP to 4.4 (if that will hang around) and this is old hardware 
so it won't hang around for more than a few years.

I can't find anything that appears related to this on the web.  Not sure about 
going through intermediate kernel versions with yocto other than going back to 
older versions of poky for ones that are missing.  I thought about the Linux 
kernel site but nothing in bugzilla or archives and this may not be of 
sufficient interest without more information.

Thanks,
Chris

From: yocto-boun...@yoctoproject.org <yocto-boun...@yoctoproject.org> on behalf 
of Chris Trobridge <christrobri...@hotmail.com>
Sent: 24 February 2017 12:10
To: Yocto List
Subject: [yocto] Intermittent Kernel Boot Hang 4.8/Intel Z5 Atom
    
Since switching kernel to 4.8 (Morty) I have noticed that sometimes my Intel 
Atom hardware (Pokini) doesn't boot Linux.

Specifically, syslinux runs fine and starts the kernel but this then hangs 
immediately after displaying "Booting the kernel.", producing no further output.

This is typical output, with one of my attempts to produce more output from the 
kernel via serial:

> /vmlinuz initrd=/initrd LABEL=boot root=/dev/ram0  video=efifb:off 
> video=640x480 console=ttyS0,115200 verbose

Loading /vmlinuz... ok
Loading /initrd...ok

The issue seem to occur with some probability after powering the hardware but 
I've not seen it occur after a reboot.

4.1 and 4.4.36 are reliable and do not have any issues booting.

I've been looking through bugs/issue but not found anything relevant.  Does 
anyone know of issues that I might not have found that would apply?

I've also been looking at how to get more diagnostics out of the boot.  I've 
tried a few suggested kernel boot parameters but nothing has helped so far.   
It seems to go wrong too early.  Do I need to re-build the kernel to produce 
more output at the early  stage it fails?

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


yocto Info Page
lists.yoctoproject.org
Discussion of all things about the Yocto Project. Read our Community Guidelines 
or learn more about how to participate in other community discussions.


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

[yocto] Intermittent Kernel Boot Hang 4.8/Intel Z5 Atom

[Chris Trobridge]

Since switching kernel to 4.8 (Morty) I have noticed that sometimes my Intel 
Atom hardware (Pokini) doesn't boot Linux.

Specifically, syslinux runs fine and starts the kernel but this then hangs 
immediately after displaying "Booting the kernel.", producing no further output.

This is typical output, with one of my attempts to produce more output from the 
kernel via serial:

> /vmlinuz initrd=/initrd LABEL=boot root=/dev/ram0  video=efifb:off 
> video=640x480 console=ttyS0,115200 verbose

Loading /vmlinuz... ok
Loading /initrd...ok

The issue seem to occur with some probability after powering the hardware but 
I've not seen it occur after a reboot.

4.1 and 4.4.36 are reliable and do not have any issues booting.

I've been looking through bugs/issue but not found anything relevant.  Does 
anyone know of issues that I might not have found that would apply?

I've also been looking at how to get more diagnostics out of the boot.  I've 
tried a few suggested kernel boot parameters but nothing has helped so far.   
It seems to go wrong too early.  Do I need to re-build the kernel to produce 
more output at the early stage it fails?

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

Re: [yocto] Illegal Instruction Generate for Intel Atom

[Chris Trobridge]

Thanks Ross,


I came to that conclusion too, and changes to the asterisk build system was 
really always the most likely source of the problem.  On the plus side, I have 
learned a lot more about machine/processor configuration in the bsp layers 
pursuing that dead end.


I went back through the asterisk change notes and at some point in the past 
they decided to use -march=native as a means to produce the best optimised 
code, while still retaining the option to disable this.


There are some more notes from last summer about changing how this is 
configured, and it certainly defaults to enabled since then.  BUILD_NATIVE is 
an option in their 'menuselect' so I need to configure that, as the clean 
solution, rather than just patching their makeopts.


Regards,

Chris


From: Burton, Ross <ross.bur...@intel.com>
Sent: 16 January 2017 15:40
To: Chris Trobridge
Cc: Leon Woestenberg; Yocto List
Subject: Re: [yocto] Illegal Instruction Generate for Intel Atom


On 16 January 2017 at 14:47, Chris Trobridge 
<christrobri...@hotmail.com<mailto:christrobri...@hotmail.com>> wrote:

Managed to get the actual compiler lines and the initial args are "-m32 
-march=i586" but there is "-march=native" appended to the end of the line.

Looks like asterisk itself is adding -march=native, so you'll need to dig 
through it's makefiles and work out how to disable it (or just delete them).

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

Re: [yocto] Illegal Instruction Generate for Intel Atom

[Chris Trobridge]

Ok,


Rebuilt system the for i586 and asterisk is still the one program to fail, 
still with that illegal andn instruction.  So I can rule out the core2 tuning.


The compiler log is next to useless, as the asterisk build hides the command 
lines but the makeopts files has the following, which seems fair enough:


CC=i586-poky-linux-gcc  -m32 -march=i586 
--sysroot=/home/chris/yocto/build/tmp/sysroots/pokini
HOST_CC=cc
BUILD_CC=cc
CXX=i586-poky-linux-g++  -m32 -march=i586 
--sysroot=/home/chris/yocto/build/tmp/sysroots/pokini

Looking around the web, this illegal andn instruction has come up before - 
possibly to do with using 'native' tuning.  This is over a long period of time 
though, so not very helpful.


Managed to get the actual compiler lines and the initial args are "-m32 
-march=i586" but there is "-march=native" appended to the end of the line.


As noted previously , there have been various issues reported with 
march=native, for a very long time, so I will try to see how to get that 
removed from the build.


Chris



From: Leon Woestenberg <l...@sidebranch.com>
Sent: 16 January 2017 09:57
To: Chris Trobridge
Cc: Yocto List
Subject: Re: [yocto] Illegal Instruction Generate for Intel Atom

Hello Chris,

Probably unrelated, but yesterday my krogoth build failed on an Atom 
*host/build* system. I was just about to debug this when I saw your email.

The configure stage of gmp-native decided to choose -march=k8 and -mtune=k8 
-m64. I am debugging this currently.

Maybe check if the asterix recipe tries to be smart in a similar way? And 
verify the do_compile log for actual compiler options.

Regards,

Leon.



build/tmp-glibc/work/x86_64-linux/gmp-native/6.1.0-r0

configure:

checking compiler gcc  -O2 -pedantic -fomit-frame-pointer -m64 ... yes
checking compiler gcc  -O2 -pedantic -fomit-frame-pointer -m64  -mtune=k8... yes
checking compiler gcc  -O2 -pedantic -fomit-frame-pointer -m64 -mtune=k8  
-march=k8... yes

"-m64 -mtune=k8 -march=k8" on gcc 5.4.0:

x86_64-linux-libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../../gmp-6.1.0/cxx 
-I.. -D__GMP_WITHIN_GMPXX -I../../gmp-6.1.0 
-isystem/home/leon/build/tmp-glibc/sysroots/x86_64-linux/usr/include -O2 
-pedantic -fomit-frame-pointer -m64 -mtune=k8 -march=k8 
-isystem/home/leon/build/tmp-glibc/sysroots/x86_64-linux/usr/include -O2 -pipe 
-c ../../gmp-6.1.0/cxx/osmpq.cc  -fPIC -DPIC -o .libs/osmpq.o
../x86_64-linux-libtool  --tag=CXX   --mode=compile g++  -DHAVE_CONFIG_H -I. 
-I../../gmp-6.1.0/cxx -I..  -D__GMP_WITHIN_GMPXX -I../../gmp-6.1.0 
-isystem/home/leon/build/tmp-glibc/sysroots/x86_64-linux/usr/include  -O2 
-pedantic -fomit-frame-pointer -m64 -mtune=k8 -march=k8 
-isystem/home/leon/build/tmp-glibc/sysroots/x86_64-linux/usr/include -O2 -pipe 
-c -o osmpz.lo ../../gmp-6.1.0/cxx/osmpz.cc
make[2]: *** [osmpz.lo] Segmentation fault


On Mon, Jan 16, 2017 at 9:46 AM, Chris Trobridge 
<christrobri...@hotmail.com<mailto:christrobri...@hotmail.com>> wrote:

This arose building asterisk switching from 13.7 to 13.11+.


The executable core dumps immediately with an illegal instruction instruction, 
which gdb reported as 'andn'.  This is part of BMI1, which was introduced with 
Haswell.  I am targeting a (32-bit) Z5xx Atom processor, which predates this 
instruction.


I don't know what changed in the Asterisk build to cause this (the instruction 
is in some regular compiler generate code) but the compiler is still generating 
legal core2 code and tune-core2.inc is recommended for Atom processors:


"This tune is recommended for the Intel Core 2 CPU family, including Conroe, 
Merom and beyond, as well as the first Atom CPUs, Diamondville, and beyond."


I am still considering this output is down to some quirk in my configuration 
but I found that -mtune and -march options were added for Atom in GCC in 4.5, 
so this could be another line of attack, although I didn't find any explicit 
code for this in meta/meta-intel.


Any ideas?


My initial plan is to try to acoid the core2 tuning and then, if that helps, 
attempt to get atom tuning working, unless that's likely to be cause further 
breakages due to being unexpected.


Regards,

Chris



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


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

Re: [yocto] Illegal Instruction Generate for Intel Atom

[Chris Trobridge]

Thanks Leon,


I agree it is probably an unrelated coincidence.  I am also using morty.


I don't have the logs around any more but the logs had -march=core2 
-mtune-core2 -m32, which was correct for the build.  I did wonder whether the 
asterisk autoconf was too clever but I think in my case it may be more a case 
of the compiler using core2 instructions that are not valid for atom.

Regards,
Chris

From: Leon Woestenberg <l...@sidebranch.com>
Sent: 16 January 2017 09:57
To: Chris Trobridge
Cc: Yocto List
Subject: Re: [yocto] Illegal Instruction Generate for Intel Atom

Hello Chris,

Probably unrelated, but yesterday my krogoth build failed on an Atom 
*host/build* system. I was just about to debug this when I saw your email.

The configure stage of gmp-native decided to choose -march=k8 and -mtune=k8 
-m64. I am debugging this currently.

Maybe check if the asterix recipe tries to be smart in a similar way? And 
verify the do_compile log for actual compiler options.

Regards,

Leon.



build/tmp-glibc/work/x86_64-linux/gmp-native/6.1.0-r0

configure:

checking compiler gcc  -O2 -pedantic -fomit-frame-pointer -m64 ... yes
checking compiler gcc  -O2 -pedantic -fomit-frame-pointer -m64  -mtune=k8... yes
checking compiler gcc  -O2 -pedantic -fomit-frame-pointer -m64 -mtune=k8  
-march=k8... yes

"-m64 -mtune=k8 -march=k8" on gcc 5.4.0:

x86_64-linux-libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I../../gmp-6.1.0/cxx 
-I.. -D__GMP_WITHIN_GMPXX -I../../gmp-6.1.0 
-isystem/home/leon/build/tmp-glibc/sysroots/x86_64-linux/usr/include -O2 
-pedantic -fomit-frame-pointer -m64 -mtune=k8 -march=k8 
-isystem/home/leon/build/tmp-glibc/sysroots/x86_64-linux/usr/include -O2 -pipe 
-c ../../gmp-6.1.0/cxx/osmpq.cc  -fPIC -DPIC -o .libs/osmpq.o
../x86_64-linux-libtool  --tag=CXX   --mode=compile g++  -DHAVE_CONFIG_H -I. 
-I../../gmp-6.1.0/cxx -I..  -D__GMP_WITHIN_GMPXX -I../../gmp-6.1.0 
-isystem/home/leon/build/tmp-glibc/sysroots/x86_64-linux/usr/include  -O2 
-pedantic -fomit-frame-pointer -m64 -mtune=k8 -march=k8 
-isystem/home/leon/build/tmp-glibc/sysroots/x86_64-linux/usr/include -O2 -pipe 
-c -o osmpz.lo ../../gmp-6.1.0/cxx/osmpz.cc
make[2]: *** [osmpz.lo] Segmentation fault


On Mon, Jan 16, 2017 at 9:46 AM, Chris Trobridge 
<christrobri...@hotmail.com<mailto:christrobri...@hotmail.com>> wrote:

This arose building asterisk switching from 13.7 to 13.11+.


The executable core dumps immediately with an illegal instruction instruction, 
which gdb reported as 'andn'.  This is part of BMI1, which was introduced with 
Haswell.  I am targeting a (32-bit) Z5xx Atom processor, which predates this 
instruction.


I don't know what changed in the Asterisk build to cause this (the instruction 
is in some regular compiler generate code) but the compiler is still generating 
legal core2 code and tune-core2.inc is recommended for Atom processors:


"This tune is recommended for the Intel Core 2 CPU family, including Conroe, 
Merom and beyond, as well as the first Atom CPUs, Diamondville, and beyond."


I am still considering this output is down to some quirk in my configuration 
but I found that -mtune and -march options were added for Atom in GCC in 4.5, 
so this could be another line of attack, although I didn't find any explicit 
code for this in meta/meta-intel.


Any ideas?


My initial plan is to try to acoid the core2 tuning and then, if that helps, 
attempt to get atom tuning working, unless that's likely to be cause further 
breakages due to being unexpected.


Regards,

Chris



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


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

[yocto] Illegal Instruction Generate for Intel Atom

[Chris Trobridge]

This arose building asterisk switching from 13.7 to 13.11+.


The executable core dumps immediately with an illegal instruction instruction, 
which gdb reported as 'andn'.  This is part of BMI1, which was introduced with 
Haswell.  I am targeting a (32-bit) Z5xx Atom processor, which predates this 
instruction.


I don't know what changed in the Asterisk build to cause this (the instruction 
is in some regular compiler generate code) but the compiler is still generating 
legal core2 code and tune-core2.inc is recommended for Atom processors:


"This tune is recommended for the Intel Core 2 CPU family, including Conroe, 
Merom and beyond, as well as the first Atom CPUs, Diamondville, and beyond."


I am still considering this output is down to some quirk in my configuration 
but I found that -mtune and -march options were added for Atom in GCC in 4.5, 
so this could be another line of attack, although I didn't find any explicit 
code for this in meta/meta-intel.


Any ideas?


My initial plan is to try to acoid the core2 tuning and then, if that helps, 
attempt to get atom tuning working, unless that's likely to be cause further 
breakages due to being unexpected.


Regards,

Chris


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

Re: [yocto] Failure Inheriting rpm_sign

[Chris Trobridge]

On Mon, 2017-01-09 at 10:47 -0800, Khem Raj wrote:
> On Fri, Jan 6, 2017 at 3:52 AM, Chris Trobridge
> <christrobri...@hotmail.com> wrote:
> > I am getting "Exception: OSError: [Errno 7] Argument list too long"
> > for sign_rpm in the do_package_write_rpm tasks for the
> > linux-yocto and glibc-locale recipes.
> > 
> > This is building core-image-minimal (and also my own image) with
> > morty (5aa481d) on Fedora 25.
> > 
> > I have enabled the rpm signing with:
> > 
> > INHERIT += " sign_rpm"
> > RPM_GPG_NAME = "{name}"
> > RPM_GPG_PASSPHRASE = "{passphrase}"
> > IMAGE_INSTALL_append = " signing-keys-rpm"
> > 
> > The error message makes some sense in as much as these recipes
> > produce a lot of packages (for example, glibc-locale produces 1791
> > packages) and the command line in the log is pretty big, although
> > reading around I didn't find a consensus on what the max command
> > line should be.
> > 
> > The code to sign rpms is in meta/lib/oe/gpg_sign.py
> > b/meta/lib/oe/gpg_sign.py and it builds up one command line with
> > all the packages.
> > 
> > I changed the code (patch appended) to sign each rpm in a separate
> > command and the build completed successfully.  The signing
> > operations take a large amount of time so I think this might be a
> > reasonable change but you may have other concerns.
> 
> This certainly is useful, perhaps the signing bits can be moved to
> individual
> recipe packaging tasks that way it may be parallelized a bit
> 

Thanks Raj,

Something needs to be done as, unless I've messed up somewhere, you
cannot build even core-image-minimal with rpm signing enabled so the
sign_rpm class is effectively broken.

The change I made works, but it's true is less efficient than signing
rpms individually.  The expense of the signature generation meant it
wasn't inefficient to sign each package in a recipe with a separate
command.

However, looking in package_rpm.bbclass, the end of do_package_rpm()
has:

if d.getVar('RPM_SIGN_PACKAGES', True) == '1':
bb.build.exec_func("sign_rpm", d)

So, to avoid confusion, all the rpms in one recipe are packaged in
task, and then that task calls the function  sign all the packages.  I
don't know if there's a way for do_package_rpm() to spawn tasks to sign
each package individually.

I also found I needed 'IMAGE_INSTALL_append = " signing-keys-rpm"'
local.conf, to deploy the public key but in sign_rpms.bbclass there is:

do_package_index[depends] += "signing-keys:do_deploy"
do_rootfs[depends] += "signing-keys:do_populate_sysroot"

It may be this isn't quite what is required.

Regards,
Chris

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

[yocto] Failure Inheriting rpm_sign

[Chris Trobridge]

I am getting "Exception: OSError: [Errno 7] Argument list too long" for 
sign_rpm in the do_package_write_rpm tasks for the 
linux-yocto and glibc-locale recipes.

This is building core-image-minimal (and also my own image) with morty 
(5aa481d) on Fedora 25.

I have enabled the rpm signing with:

INHERIT += " sign_rpm"
RPM_GPG_NAME = "{name}"
RPM_GPG_PASSPHRASE = "{passphrase}"
IMAGE_INSTALL_append = " signing-keys-rpm"

The error message makes some sense in as much as these recipes produce a lot of 
packages (for example, glibc-locale produces 1791 packages) and the command 
line in the log is pretty big, although reading around I didn't find a 
consensus on what the max command line should be.

The code to sign rpms is in meta/lib/oe/gpg_sign.py b/meta/lib/oe/gpg_sign.py 
and it builds up one command line with all the packages.

I changed the code (patch appended) to sign each rpm in a separate command and 
the build completed successfully.  The signing operations take a large amount 
of time so I think this might be a reasonable change but you may have other 
concerns.

Regards,
Chris

diff --git a/meta/lib/oe/gpg_sign.py b/meta/lib/oe/gpg_sign.py
index 38eb0cb..a386b1f 100644
--- a/meta/lib/oe/gpg_sign.py
+++ b/meta/lib/oe/gpg_sign.py
@@ -29,17 +29,18 @@ class LocalSigner(object):
 def sign_rpms(self, files, keyid, passphrase):
 """Sign RPM files"""
 
-cmd = self.rpm_bin + " --addsign --define '_gpg_name %s'  " % keyid
-cmd += "--define '_gpg_passphrase %s' " % passphrase
-if self.gpg_bin:
-cmd += "--define '%%__gpg %s' " % self.gpg_bin
-if self.gpg_path:
-cmd += "--define '_gpg_path %s' " % self.gpg_path
-cmd += ' '.join(files)
-
-status, output = oe.utils.getstatusoutput(cmd)
-if status:
-raise bb.build.FuncFailed("Failed to sign RPM packages: %s" % 
output)
+for file in files:
+cmd = self.rpm_bin + " --addsign --define '_gpg_name %s'  " % keyid
+cmd += "--define '_gpg_passphrase %s' " % passphrase
+if self.gpg_bin:
+cmd += "--define '%%__gpg %s' " % self.gpg_bin
+if self.gpg_path:
+cmd += "--define '_gpg_path %s' " % self.gpg_path
+cmd += file
+
+status, output = oe.utils.getstatusoutput(cmd)
+if status:
+raise bb.build.FuncFailed("Failed to sign RPM packages: %s" % 
output)
 
 def detach_sign(self, input_file, keyid, passphrase_file, passphrase=None, 
armor=True):
 """Create a detached signature of a file"""
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Issues Updating Asterisk/Dahdi recipes from meta-telephony

[Chris Trobridge]

Hi,


I have got around to updating these recipes and found a few issues:


asterisk has a autoconf macro file for pjproject in ./third-party/pjproject/, 
which does not get picked up by autobuild.bbclass.


This uses find with a -maxdepth of 2 but but 3 would be needed.  I found a temp 
fix by copying the m4 file manually to ./m4 directory in configure_prepend but 
what would the best long term solution be?


/etc/init.d/functions stopped being installed for dahdi-tools and asterisk.


update-rc.d.bbclass adds a run-time dependency on initscripts-functions if the 
installed init.d script contains the literal string "/etc/init.d/functions" at 
the packet-split stage.


dahdi doesn't contain this literally but asterisk does so I am confused - but 
adding an explicit run-time dependency on initscripts-functions to dahdi-tools 
solved this.


Any ideas on why this isn't working be default?


asterisk also seems to have an issue locating neon but I have not started to 
investigate that yet.


Regards,

Chris


morty 5aa481d

asterisk 13.13.1

dahdi-tools 2.10.2

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

Re: [yocto] QA python3 runtime dependency

[Chris Trobridge]

> Subject: Re: [yocto] QA python3 runtime dependency
> To: christrobri...@hotmail.com; yocto@yoctoproject.org
> From: s.mueller-klie...@phytec.de
> Date: Fri, 16 Sep 2016 14:38:37 +0200
>
> On 16.09.2016 13:45, Chris Trobridge wrote:
>> My top-level python3 scripts have "#!/usr/bin/python3" and the recipe 
>> RDEDENDS on python3.
>
> I guess this is what you need:
>
> RDEPENDS_${PN} = "python3-core"
>
> As the interpreter is in the -core package.
>
> Regards, Stefan
>
>> There's no problem in the final system as python3 is present in /usr/bin as 
>> expected.
>> What I do not understand is why I am getting a QA warning : "requires 
>> /usr/bin/python3, but no providers found in RDEPENDS? [file-rdeps]".
>> Any ideas why this is happening?
>> Thanks,Chris

Thanks,

I was looking for the right package - that works.

What puzzles me a bit is that my project RDEPENDs python3 and python3 RDEPENDs 
python3-core, so I would have thought this 
would have propagated!

Regards,
Chris



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

[yocto] QA Host Contamination in autotools/pkconfig based recipe

[Chris Trobridge]

I raised this back in April but I am back on QA review and I did not manage to 
sort this at the time.

I have a recipe for pjproject that produces QA host contamination warnings for 
all the library files it installs:

pjproject: /pjproject/usr/lib/*.so.2 is owned by uid 1000, which is the same as 
the user running bitbake. This may be due to host contamination
pjproject: /pjproject-staticdev/usr/lib/*.a is owned by uid 1000, which is the 
same as the user running bitbake. This may be due to host contamination

The install line in the makefile is "cp -af $(APP_LIBXX_FILES) 
$(DESTDIR)$(libdir)/", so I am at a bit of a loss as this should preserve 
ownership.

I've included the recipe I am using.

Regards,
Chris

DESCRIPTION = "Open source SIP stack and media stack for presence, im/instant \
               messaging, and multimedia communication"
SECTION = "libs"
HOMEPAGE = "http://www.pjsip.org/;
LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"

DEPENDS = "alsa-lib openssl"
RDEPENDS_${PN} = "util-linux-libuuid"

PARALLEL_MAKE = ""

SRC_URI = "http://www.pjsip.org/release/${PV}/pjproject-${PV}.tar.bz2 "
SRC_URI[md5sum] = "183f7144b9aa238884243c0fc52ece36"

S = "${WORKDIR}/pjproject-${PV}"

EXTRA_OECONF += "--enable-shared"

DEBUG_FLAGS = "-g -feliminate-unused-debug-types"

inherit autotools pkgconfig

B = "${S}"

do_configure_prepend() {
    LD=$CC
}

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

[yocto] QA python3 runtime dependency

[Chris Trobridge]

My top-level python3 scripts have "#!/usr/bin/python3" and the recipe RDEDENDS 
on python3.
There's no problem in the final system as python3 is present in /usr/bin as 
expected.
What I do not understand is why I am getting a QA warning : "requires 
/usr/bin/python3, but no providers found in RDEPENDS? [file-rdeps]".
Any ideas why this is happening?
Thanks,Chris
  -- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Formulating Recipe for out-of-tree kernel module

[Chris Trobridge]

Thanks Joel,
I can build the module but I am trying to find out the best way to do this with 
yocto/bitbake.
The build process for the second module I have requires the location of the 
first and then does copy the Module.symvers and accesses the header files and 
".version" file.
The question was more about how it should find these.
What I have just tried out, is to copy the above files  (Module.symvers, 
.version and include/* to ${STAGING_KERNEL_BUILDDIR}/out-of-tree/${PN}, which 
is hence easily accessible by the second recipe.
This works but may not be the preferred way?  I suspect the preferred way is to 
build in the kernel.
Cheers,Chris

From: joel.espo...@honeywell.com
To: christrobri...@hotmail.com; yocto@yoctoproject.org
Subject: RE: [yocto] Formulating Recipe for out-of-tree kernel module
Date: Tue, 10 May 2016 13:29:30 +









Ok! I better understand your need now.
The fix solves the case where an out of tree module is dependent of a kernel 
module which is not built as a built-in module.

 
Just in case, did you have a look on these links?
http://stackoverflow.com/a/33718934/1729117
https://www.kernel.org/doc/Documentation/kbuild/modules.txt
 (Chapter 6.2 and 6.3)
 

Joël Esponde
Honeywell
| Sensing and Productivity Solutions

 



De : Chris Trobridge [mailto:christrobri...@hotmail.com]


Envoyé : mardi 10 mai 2016 13:28

À : Esponde, Joel; yocto@yoctoproject.org

Objet : RE: [yocto] Formulating Recipe for out-of-tree kernel module


 

Thanks Joel,

 


I am on Krogoth.


 


My reading of that patch is that it allows out-of-tree modules to depend on 
symbols from the kernel but I don't see how it would help with depending on 
another out-of-tree module?
  Those symbols are not added to the kernel Module.symvers.


 


I've been following some other usage I read that 'out-of-tree' means compiling 
outside/after the kernel build, which may not be 100% accurate?


 


Anyway, it suggests to me that copying the first module's Module.symvers to the 
shared kernel staging area and then referencing that from the second module is 
probably better than
 my current solution, provided I don't break any conventions on using the 
staging area.


 


Cheers,


Chris




From:
joel.espo...@honeywell.com

To: christrobri...@hotmail.com;
yocto@yoctoproject.org

Subject: RE: [yocto] Formulating Recipe for out-of-tree kernel module

Date: Tue, 10 May 2016 10:06:37 +

Hi,
 
There is a bitbake issue that prevents building an out-of-tree module that is 
dependent of another out-of-tree module.
This issue has been fixed recently:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=master-next=a9cc27e6916e5affe8b0cc431c3e89abd7681643
 
This fix has been released on yocto 2.1 (krogoth).
So if you are using an older Yocto project, you will have to fix two recipes 
manually.
 
I hope this will help!
 

Joël Esponde
Honeywell
| Sensing and Productivity Solutions

 



De :
yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org]
De la part de Chris Trobridge

Envoyé : mardi 10 mai 2016 08:59

À : yocto@yoctoproject.org

Objet : Re: [yocto] Formulating Recipe for out-of-tree kernel module


 


At the risk of answering my own question...


 

Splitting a driver package into a module recipe and a separate recipe for 
user-mode utilities works in that each recipe uses the appropriate build 
process and puts files in the
 appropriate subdirectory of /work/.

 


I still don't see a way to build one out-of-tree module against another.  I am 
interested in opinion on this.  Should I try to get these drivers built in 
tree?  They seem to be
 the only two out-of-tree drivers in the build at present.  There is also some 
facility to add extra modules to the dahdi linux build, although achieving this 
with bitbake could be challenging too.



Cheers,


Chris




From:
christrobri...@hotmail.com

To: yocto@yoctoproject.org

Date: Mon, 9 May 2016 12:15:26 +0100

Subject: [yocto] Formulating Recipe for out-of-tree kernel module

I am looking to produce a recipe for the amfeltec usb-fxs adaptor 
(http://amfeltec.com/products/piranha-usb-fxs-adapter/),
 with the intention of contributing this to the meta-telephony layer.

 


However, I have found a few obstacles to getting a clean recipe:




The makefile produces both a kernel module and a user utility, with the latter 
being hard-coded to build with g++.  I can produce a recipe to produce one or 
other of the components but not both.  Given
 the structure of the build directories, should this be be achievable, or 
should I be spitting up the recipe in two?
Dahdi header files and Modules.symvers are required.  A header file is used to 
deduce the version of Dahdi, Modules.symvers is required for the module build 
process.  Hence, requires the location of
 the Dahdi source/build directory.  This can be set relative to the amfeltec 
work directory but this feels wrong.



 



In more general terms my questions are:




Should I spli

Re: [yocto] Formulating Recipe for out-of-tree kernel module

[Chris Trobridge]

At the risk of answering my own question...
Splitting a driver package into a module recipe and a separate recipe for 
user-mode utilities works in that each recipe uses the appropriate build 
process and puts files in the appropriate subdirectory of /work/.
I still don't see a way to build one out-of-tree module against another.  I am 
interested in opinion on this.  Should I try to get these drivers built in 
tree?  They seem to be the only two out-of-tree drivers in the build at 
present.  There is also some facility to add extra modules to the dahdi linux 
build, although achieving this with bitbake could be challenging too.

Cheers,Chris

From: christrobri...@hotmail.com
To: yocto@yoctoproject.org
Date: Mon, 9 May 2016 12:15:26 +0100
Subject: [yocto] Formulating Recipe for out-of-tree kernel module




I am looking to produce a recipe for the amfeltec usb-fxs adaptor 
(http://amfeltec.com/products/piranha-usb-fxs-adapter/), with the intention of 
contributing this to the meta-telephony layer.
However, I have found a few obstacles to getting a clean recipe:The makefile 
produces both a kernel module and a user utility, with the latter being 
hard-coded to build with g++.  I can produce a recipe to produce one or other 
of the components but not both.  Given the structure of the build directories, 
should this be be achievable, or should I be spitting up the recipe in 
two?Dahdi header files and Modules.symvers are required.  A header file is used 
to deduce the version of Dahdi, Modules.symvers is required for the module 
build process.  Hence, requires the location of the Dahdi source/build 
directory.  This can be set relative to the amfeltec work directory but this 
feels wrong.
In more general terms my questions are:Should I split a recipe into kernel and 
non-kernel components?How should one out-of-tree recipe access the 
headers/Module.symvers from another (should that recipe be installing them in 
${STAGING_KERNEL_DIR} (or somewhere else)?)
Cheers,Chris
  

-- 
___
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] Formulating Recipe for out-of-tree kernel module

[Chris Trobridge]

I am looking to produce a recipe for the amfeltec usb-fxs adaptor 
(http://amfeltec.com/products/piranha-usb-fxs-adapter/), with the intention of 
contributing this to the meta-telephony layer.
However, I have found a few obstacles to getting a clean recipe:The makefile 
produces both a kernel module and a user utility, with the latter being 
hard-coded to build with g++.  I can produce a recipe to produce one or other 
of the components but not both.  Given the structure of the build directories, 
should this be be achievable, or should I be spitting up the recipe in 
two?Dahdi header files and Modules.symvers are required.  A header file is used 
to deduce the version of Dahdi, Modules.symvers is required for the module 
build process.  Hence, requires the location of the Dahdi source/build 
directory.  This can be set relative to the amfeltec work directory but this 
feels wrong.
In more general terms my questions are:Should I split a recipe into kernel and 
non-kernel components?How should one out-of-tree recipe access the 
headers/Module.symvers from another (should that recipe be installing them in 
${STAGING_KERNEL_DIR} (or somewhere else)?)
Cheers,Chris
  -- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [Fwd: gobject introspection release notes]

[Chris Trobridge]

> Subject: Re: [yocto] [Fwd: gobject introspection release notes]
> To: zhenhua@nxp.com; christrobri...@hotmail.com
> CC: yocto@yoctoproject.org
> From: alexander.kana...@linux.intel.com
> Date: Wed, 27 Apr 2016 15:38:01 +0300
> 
> On 04/26/2016 11:05 AM, Zhenhua Luo wrote:
> > Any ideas as to why "qemu-ppc64 crashes out immediately"?
> >
> > I can confirm the build ends in a segfault when I tried building
> > gobject-introspection for the t1042d4rdb-64b machine.
> >
> > */[Luo Zhenhua-B19537] This is a gobject-introspection support issue of
> > QEMU PPC64, the fix is not available now, you can use the following
> > workaround to bypass the issue. /*
> >
> > */http://git.yoctoproject.org/cgit.cgi/meta-fsl-ppc/tree/README#n18/*
> 
> I'm afraid disabling introspection data is not an acceptable solution 
> for Chris, because he does want to have that data.
> 
> Also, I'll send a fix to disable building of introspection data on all 
> ppc64 machines for now.
> 
> Alex

Thanks Alex.
This is not urgent and with this processor there is the option of using 32-bit 
mode.  So if the new commit fixes the 32-bit machine then that would be an 
acceptable alternative for now.
I like to fix things so I am curious about the qemu-ppc64 crash but realise I 
can't afford to spend much time on it!
Regards,Chris
  -- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Build Errors with new recipe for pjproject (autotools/pkgconfig)

[Chris Trobridge]

Regarding:
"Can you shine any light on the "-fdebug-prefix-map" related fatal QA errors?  
(leaking host paths) I've found some discussion in openembedded that suggests 
this should be fixed in the compiler but again I am curious why this (very 
simple) recipe has this issue but others don't."
So DEBUG_FLAGS was changed recently but setting back to  "-g 
-feliminate-unused-debug-types" avoids this issue.
Regards,Chris
  -- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Build Errors with new recipe for pjproject (autotools/pkgconfig)

[Chris Trobridge]

Thanks Ross,
I have added "EXTRA_OECONF += "--enable-shared", as asterisk needs shared 
libraries: these don't get the suffix and asterisk builds fine.
I am still getting a whole slew of host contamination warnings, eg "pjproject: 
/pjproject-staticdev/usr/lib/libpjsua-x86_64-poky-linux-gnu.a is owned by uid 
1000, which is the same as the user running bitbake. This may be due to host 
contamination".  I can find some references to this happening in release tests 
but not how it was fixed.
Can you shine any light on the "-fdebug-prefix-map" related fatal QA errors?  
(leaking host paths) I've found some discussion in openembedded that suggests 
this should be fixed in the compiler but again I am curious why this (very 
simple) recipe has this issue but others don't.
The only 'odd' thing I've need to do is add "do_configure_prepend() { LD=$CXX }
If I get these recipes (asterisk/pjproject) to an acceptable level I could 
propose them (back) into openembedded?
pjproject hasn't been touched for 6 years and has some custom steps I don't 
understand 
(https://github.com/openembedded/openembedded/tree/master/recipes/pjproject).
asterisk 
(https://github.com/openembedded/openembedded/tree/master/recipes/asterisk) is 
simarly out of date on openembedded, although there is also asterisk in 
meta-telephony 
(https://github.com/sysmocom/meta-telephony/tree/master/recipes-asterisk/asterisk)
 that is referenced.
'My' asterisk recipe is based on the one from meta-telephony so I should get in 
touch with the authors.
Regards,Chris
From: ross.bur...@intel.com
Date: Wed, 27 Apr 2016 08:41:14 +0100
Subject: Re: [yocto] Build Errors with new recipe for pjproject 
(autotools/pkgconfig)
To: christrobri...@hotmail.com
CC: yocto@yoctoproject.org


On 27 April 2016 at 07:27, Chris Trobridge <christrobri...@hotmail.com> wrote:
Aside from the issues I mentioned previously, pjproject is detecting 
cross-compilation and this causes it to append '-x86_64-poky-linux-gnu' to all 
its library names.
This is then breaking autotools configuration in other recipes that are testing 
for the base name.
Is it common for a build process to differentiate cross compiled libraries like 
this?  Is there a preferred way to deal with it?
No, that's rather unusual.  Typically you'd just have a different libdir per 
architecture.
Ross  -- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Build Errors with new recipe for pjproject (autotools/pkgconfig)

[Chris Trobridge]

Aside from the issues I mentioned previously, pjproject is detecting 
cross-compilation and this causes it to append '-x86_64-poky-linux-gnu' to all 
its library names.
This is then breaking autotools configuration in other recipes that are testing 
for the base name.
Is it common for a build process to differentiate cross compiled libraries like 
this?  Is there a preferred way to deal with it?
I'm not confident about changing the pjproject build but I can link the base 
name to the extended name in do_install_append() so both names are present. 
pkgconfig picks up the extended names so these are also used in other recipes 
too (both forms of name in the same command line...).
Regards,Chris

From: christrobri...@hotmail.com
To: yocto@yoctoproject.org
Date: Tue, 26 Apr 2016 10:15:34 +0100
Subject: [yocto] Build Errors with new recipe for pjproject 
(autotools/pkgconfig)




I have been trying to formulate a new recipe for pjproject (pjsip) - there was 
one but it seems too old and isn't part of any layer now.
The library seems to require a fairly straightforward autotools/pkgconfig 
recipe but I get two errors, both of which I can see have come up before but 
haven't been answered satisfactorily.
The first is that the link stage fails with "x86_64-poky-linux-ld: unrecognized 
option '-Wl,-O1'".
I've found this answered as "tools being too old" but '-Wl,' is a gcc prefix to 
pass an option to the linker but the linker is being invoked directly and so 
this is really a configuration mismatch.  I can fix this with "LD=$CXX" in 
do_configure_prepend() but I am puzzled as to why autotools would get confused 
this way in the first place?
The second problem is possibly more recent: ERROR: pjproject-2.4.5-r0 
do_populate_sysroot: QA Issue: libpjproject.pc failed sanity test (tmpdir) in 
path 
/home/chris/yocto/build/tmp/work/corei7-64-poky-linux/pjproject/2.4.5-r0/sysroot-destdir/usr/lib/pkgconfig
 [pkgconfig]
I think this is benign other than leaking my dev environment but there was an 
oe gcc patch earlier this year that addressed this 
(http://lists.openembedded.org/pipermail/openembedded-core/2016-January/116468.html).
Apparently there was QA change the broke a lot of recipes but it's not clear 
how to fix this recipe - from what I could tell the fix should have applied to 
all recipes.  Adding '-gno-record-debug-prefix-map' should fix this but the 
compiler option is not recognised.
Any ideas on how to solve the QA error?
I am using the poky commit for 2.1_M4.rc1.
Thanks,Chris
  

-- 
___
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] Customize login prompt text in Yocto

[Chris Trobridge]

Hi Andreas,
In general, you should not add your changes to poky directly, or any of the 
other provided layers.
In this case the 'permanent' way to do this is to produce your own distribution 
layer but the quick alternative is to set the variable in conf/local.conf.
Regards,Chris 

From: andreas.enba...@gasera.fi
To: rudolf.str...@gmail.com
Date: Tue, 26 Apr 2016 13:08:13 +0300
CC: yocto@yoctoproject.org
Subject: Re: [yocto] Customize login prompt text in Yocto

Hello, What is the correct way to override poky.conf? I tried adding a new file 
custom-poky.conf into meta-yocto/conf/distro, including the poky.conf file and 
overriding e.g., DISTRO_VERSION. Is this the correct approach, or is some other 
changes required as well? Best regards,Andreas Enbacka From: Rudolf Streif 
[mailto:rudolf.str...@gmail.com] 
Sent: 25. huhtikuutata 2016 0:07
To: Peter Bergin 
Cc: Andreas Enbacka ; yocto@yoctoproject.org
Subject: Re: [yocto] Customize login prompt text in Yocto the information shown 
is from the file /etc/issue. You can for example do post-processing on this 
file and change the information. You can add this to your image recipe.

update_issue() {
echo "Your text" > ${IMAGE_ROOTFS}/etc/issue
}

ROOTFS_POSTPROCESS_COMMAND += " update issue; "  The more "yoctonic" way of 
setting this is to modify the DISTRO_NAME variable, which is set in the distro 
configuration file e.g. poky.conf. If you are building your own distro it you 
may want to derive your own distro configuration file from the ones that Poky 
provides. There you can also set other variables such as DISTRO_VERSION, 
MAINTAINER, etc. Cheers,Rudi
-- 
___
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] Build Errors with new recipe for pjproject (autotools/pkgconfig)

[Chris Trobridge]

I have been trying to formulate a new recipe for pjproject (pjsip) - there was 
one but it seems too old and isn't part of any layer now.
The library seems to require a fairly straightforward autotools/pkgconfig 
recipe but I get two errors, both of which I can see have come up before but 
haven't been answered satisfactorily.
The first is that the link stage fails with "x86_64-poky-linux-ld: unrecognized 
option '-Wl,-O1'".
I've found this answered as "tools being too old" but '-Wl,' is a gcc prefix to 
pass an option to the linker but the linker is being invoked directly and so 
this is really a configuration mismatch.  I can fix this with "LD=$CXX" in 
do_configure_prepend() but I am puzzled as to why autotools would get confused 
this way in the first place?
The second problem is possibly more recent: ERROR: pjproject-2.4.5-r0 
do_populate_sysroot: QA Issue: libpjproject.pc failed sanity test (tmpdir) in 
path 
/home/chris/yocto/build/tmp/work/corei7-64-poky-linux/pjproject/2.4.5-r0/sysroot-destdir/usr/lib/pkgconfig
 [pkgconfig]
I think this is benign other than leaking my dev environment but there was an 
oe gcc patch earlier this year that addressed this 
(http://lists.openembedded.org/pipermail/openembedded-core/2016-January/116468.html).
Apparently there was QA change the broke a lot of recipes but it's not clear 
how to fix this recipe - from what I could tell the fix should have applied to 
all recipes.  Adding '-gno-record-debug-prefix-map' should fix this but the 
compiler option is not recognised.
Any ideas on how to solve the QA error?
I am using the poky commit for 2.1_M4.rc1.
Thanks,Chris
  -- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [Fwd: gobject introspection release notes]

[Chris Trobridge]

Any ideas as to why "qemu-ppc64 crashes out immediately"?
I can confirm the build ends in a segfault when I tried building 
gobject-introspection for the t1042d4rdb-64b machine.  
I did get one qemu crash recorded by Fedora but the actual crash dumps 
(appended) are for a PowerPC.  That said, given the dump, either the processor 
got nowhere or they are likely corrupt.  The invalid access reported is roughly 
to the stack but with the upper 32-bits zeroed.
If I configure bitbake for a 32-bit build (t1042d4rdb) then the build fails 
with  "Unable to find CPU definition" (cpu e5500) so a 32-bit build is out of 
the question too.
The command line from the wrapper is:PSEUDO_UNLOAD=1 qemu-ppc -r 2.6.32  -cpu 
e5500 -L /home/chris/yocto/build/tmp/sysroots/t1042d4rdb -E 
LD_LIBRARY_PATH=$GIR_EXTRA_LIBS_PATH:.libs:/home/chris/yocto/build/tmp/sysroots/t1042d4rdb//usr/lib:/home/chris/yocto/build/tmp/sysroots/t1042d4rdb//lib
  "$@"
The cpu is supported by the fedora qemu-ppc64, but not qemu-ppc - ie it's a 
64-bit processor that's not supported in 32-bit mode.
This is not massively urgent for me but it may be important in the future and I 
am curious as to whether the problem is in the qemu emulation or in the 
emulated code.
Regards,Chris 

| Invalid data memory access: 0x007fe8f0| NIP 0040008046c8   LR 
 CTR  XER  CPU#0| MSR 
80006000 HID0   HF 6000 idx 0| TB 00025634 
110100571322161| GPR00  0040007fe970 004000848e00 
0040007fe970| GPR04    
| GPR08    
| GPR12    
| GPR16    
| GPR20    
| GPR24    
| GPR28    
| CR   [ -  -  -  -  -  -  -  -  ] RES 
| FPR00    
| FPR04    
| FPR08    
| FPR12    
| FPR16    
| FPR20    
| FPR24    
| FPR28    
| FPSCR | Invalid segfault errno (4200)| 
NIP 0040008046c8   LR  CTR  XER 
 CPU#0| MSR 80006000 HID0   HF 
6000 idx 0| TB 00025634 110100578368626| GPR00  
0040007fe970 004000848e00 0040007fe970| GPR04  
  | GPR08  
  | GPR12  
  | GPR16  
  | GPR20  
  | GPR24  
  | GPR28  
  | CR   [ -  -  -  -  
-  -  -  -  ] RES | FPR00  
  | FPR04  
  | FPR08  
  | FPR12  
  | FPR16  
  | FPR20  
  | FPR24  
  | FPR28  
  | FPSCR | 
qemu: uncaught target signal 11 (Segmentation fault) - core dumped
  -- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Using Yocto with NXP QorIQ Processors

[Chris Trobridge]

Thanks Zhenhua,
That sounds more positive.
One think that has been pointed out to me is that there are community layers 
that are support outside of NXP that sit between Yocto and NXP 
(http://freescale.github.io/#) that track issues etc more actively.  These does 
not appear to involve the ppc processors so are the arm processors more 
actively supported? (I presume this just depends on the community support.)
We use the original pcc qoriq processors and so would be interested in ppc 
support but that's still more of a future project.  Relative support arm vs ppc 
would be a consideration but the meta-fsl-layer in yocto is reassuring (I 
didn't manage to find it before!).
Regards,Chris
From: zhenhua@nxp.com
To: christrobri...@hotmail.com
CC: yocto@yoctoproject.org
Subject: RE: [yocto] Using Yocto with NXP QorIQ Processors
Date: Tue, 19 Apr 2016 03:16:16 +









Hi Chris,

 
The QorIQ SDK uses recent Yocto version, e.g. the SDK 2.0  is based on Yocto 
2.0(Jethro).  When the SDK is formally released in Q2/2016, the SDK recipes will
 be upstreamed to master of community layers.
 
You can use either SDK ISOs available in NXP official website(www.nxp.com) or 
the BSP layers in Yocto website (http://git.yoctoproject.org/cgit.cgi/).


·
QorIQ ARM targets: meta-fsl-arm

·
QorIQ PPC targets: meta-fsl-ppc

 
 
Best Regards,
 
Zhenhua

 



From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org]
On Behalf Of Chris Trobridge

Sent: Monday, April 18, 2016 9:58 PM

To: yocto@yoctoproject.org

Subject: [yocto] Using Yocto with NXP QorIQ Processors


 

Has anyone attempted to use the Qoriq BSP layers with them main Yocto release 
rather than the NXP (ex Freescale) SDK they come bundled in?

 


I ask because the NXP SDK is somewhat behind the main Yocto release schedule.


 


It should be easier to port the BSP to the current Yocto but I have no idea 
what issues I am likely to hit.


 


I will try this at some point when I have enough free time but for planning 
purposes I would interested in how anyone else has got on attempting this.


 


Are Qoriq users restricted to the official SDK or would they get third-party 
support?


 


Regards,


Chris


 



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

[yocto] Using Yocto with NXP QorIQ Processors

[Chris Trobridge]

Has anyone attempted to use the Qoriq BSP layers with them main Yocto release 
rather than the NXP (ex Freescale) SDK they come bundled in?
I ask because the NXP SDK is somewhat behind the main Yocto release schedule.
It should be easier to port the BSP to the current Yocto but I have no idea 
what issues I am likely to hit.
I will try this at some point when I have enough free time but for planning 
purposes I would interested in how anyone else has got on attempting this.
Are Qoriq users restricted to the official SDK or would they get third-party 
support?
Regards,Chris
  -- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Python GObject Errors on yocto-2.1_M3.rc2

[Chris Trobridge]

> To: yocto@yoctoproject.org
> From: alexander.kana...@linux.intel.com
> Date: Thu, 7 Apr 2016 16:40:30 +0300
> Subject: Re: [yocto] Python GObject Errors on yocto-2.1_M3.rc2
> 
> On 04/07/2016 04:35 PM, Burton, Ross wrote:
> 
> > Yeah, that. :)  Annoyingly it's not just a PACKAGECONFIG due to how
> > python-native works.
> 
> Yeah, the annoying side effect is that every python thingy needs to be 
> packaged twice - not so visible in oe-core, but very visible in 
> meta-oe's meta-python:
> 
> http://cgit.openembedded.org/meta-openembedded/tree/meta-python/recipes-devtools/python
> 
> Will be fixed by deprecating python 2, of course.
> 
> Alex

Is there a  shorter term solution that's generally applicable, like a separate 
python3-gobject recipe?
I've done something similar before but it had issues (produces duplicate 
output) that are hard to deal with satisfactorily.
At least this explains why my code stopped working.
Chris
  -- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Python GObject Errors on yocto-2.1_M3.rc2

[Chris Trobridge]

> From: ross.bur...@intel.com
> Date: Wed, 6 Apr 2016 12:22:39 +0100
> Subject: Re: [yocto] Python GObject Errors on yocto-2.1_M3.rc2
> To: christrobri...@hotmail.com
> CC: yocto@yoctoproject.org
>
>
> On 6 April 2016 at 12:19, Chris Trobridge
> <christrobri...@hotmail.com<mailto:christrobri...@hotmail.com>> wrote:
> This did the trick for python 2.7, and "from gi.repository import
> GObject" works too.
>
> Can you send a patch to add this dependency to the pygobject package?
>
> Ross

I will try to sort that out tomorrow (p...@yoctoproject.org, right?).

Regarding python3, whenever I change the "--with-python" option to something 
other than "python2.7" then I get an error.

If I specify python3.5 then the error is that the build cannot find python3.5.  
If I set it to python3.4 (which is installed on the host) then I get an error 
about system directory poisoning.

This suggests to me that the recipe seems to need both host and target python 
for this to work.  It worked before so I will look tomorrow at the experimental 
branch and see what's different, if anything.  I've deleted that branch here 
and it is gone from git.

Regards,
Chris

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

Re: [yocto] Python GObject Errors on yocto-2.1_M3.rc2

[Chris Trobridge]

Thanks Ross,
This did the trick for python 2.7, and "from gi.repository import GObject" 
works too.
It's still not installed for python 3.5.  I will see if I did anything specific 
to make that happen but it's odd that it worked before.
Regards,Chris

From: ross.bur...@intel.com
Date: Wed, 6 Apr 2016 11:57:10 +0100
Subject: Re: [yocto] Python GObject Errors on yocto-2.1_M3.rc2
To: christrobri...@hotmail.com
CC: yocto@yoctoproject.org


On 6 April 2016 at 11:53, Chris Trobridge <christrobri...@hotmail.com> wrote:
ImportError: No module named importlib
Looks like python-gobject needs to depend on python-importlib.  Not sure why 
that isn't in -core to be honest.
Can you add python-importlib to your image and see if it then works, or if 
other modules are missing?
Ross  -- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Python GObject Errors on yocto-2.1_M3.rc2

[Chris Trobridge]

I have a code base using gobject introspection that has been running fine on 
Alex's gobject-introspection-experimental branch on poky-contrib but is broken 
on 2.1 M3.
I am using it with python3 (3.5) but it isn't accessible with python27 either.  
It appears it may be partially installed for 2.7 but not at all for 3.5.
To simplify things, I have built core-image-full-cmdline on genericx86-64 and 
this gives the same result as my image:
=Poky (Yocto Project Reference Distro) 2.0+snapshot-20160406 
genericx86-64 console
genericx86-64 login: rootroot@genericx86-64:~# pythonPython 2.7.11 (default, 
Apr  6 2016, 10:05:21) [GCC 5.3.0] on linux2Type "help", "copyright", "credits" 
or "license" for more information.>>> import giTraceback (most recent call 
last):  File "", line 1, in   File 
"/usr/lib/python2.7/site-packages/gi/__init__.py", line 29, in 
import importlibImportError: No module named importlib>>> =
Is there something else I need to change to get gobject introspection to work 
with the RC or does this indicate a bug/omission?
Cheers,Chris
  -- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Disabling ipv6

[Chris Trobridge]

I hit this issue experimenting with disabling ipv6, as Todd did originally, 
with an odd error about not being able to build the native sdk.
It's not a problem for me but is there a recommended way for disabling a libc 
distro feature like ipv6 without creating a whole new distro?  Does libc really 
require ipv6?  I can see it's the features in DISTRO_FEATURES_LIBC that are 
critical.
For the purposes of this experiment I added to local.conf to get it 
working:DISTRO_FEATURES_remove = "ipv6"DISTRO_FEATURES_LIBC_remove = "ipv6"
But I expect I will create a new distro at some point.
Cheers,Chris
On Tuesday 27 October 2015 08:45:26 Burton, Ross wrote:> On 26 October 2015 at 
20:16, Todd Efflam  wrote:> > Thanks for the tip.  We 
tried adding this to the local.conf file but> > it failed with the following 
error:> > ERROR: Nothing PROVIDES 'glibc'> > ERROR: glibc was skipped: missing 
required distro feature 'ipv6' (not> > in DISTRO_FEATURES)> > Ouch.  That's 
surely not right.> > The commit that introduced this was:> > commit 
97899bc908a421295d814801ff86edeb9304d2fd> Author: Chen Qi > Date:   Thu Jul 3 11:23:42 2014 +0800> > eglibc: check for 
required distro features> > If users accidently override the 
DISTRO_FEATURES in local.conf,> then build failures occur for lack of libc 
functions.> > All features in DISTRO_FEATURES_LIBC should be in 
DISTRO_FEATURES.> That's why this patch let the recipe inherit 
distro_features_check> class and set REQUIRED_DISTRO_FEATURES to 
"${DISTRO_FEATURES_LIBC}".> > [YOCTO #6381]> > But the entire point of the 
logic in glibc-options is to make these> options, well, optional.> > It looks 
like the required_distro_features use in eglibc is misguided.  Can> you comment 
out the REQUIRED_DISTRO_FEATURES assignment in glibc.inc and> verify that it 
then builds fine without ipv6 enabled?
Ah yes, I meant to get back to this at some point as I didn't really like how 
this was fixed previously either (see 
https://bugzilla.yoctoproject.org/show_bug.cgi?id=6381 for details of the 
problem). It seems to me that we should:
1) Fix the glibc recipes so that they handle an empty libc configuration or 
error out much earlier with a sensible message if that's not possible
2) Properly detect when DISTRO_FEATURES has been "zapped" via += in local.conf 
or elsewhere and show an error/warning about that.
Cheers,Paul
-- 
Paul EggletonIntel Open Source Technology Centre
  -- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Signed RPMs

[Chris Trobridge]

Hi,
I have been testing out the facility for generating signed RPMs.
It's currently failing to find 
'build/tmp/sysroots/x86_64-linux/etc/RPM-GPG-PUBKEY', log listed at end.
I couldn't find a lot of documentation but from what I could find, I added the 
following to local.conf:
INHERIT += " sign_rpm"RPM_GPG_NAME = "chris"RPM_GPG_PUBKEY = 
"/home/chris/mykey.pub"RPM_GPG_PASSPHRASE_FILE = "/home/chris/mypassphrase"
It needed 'python-pexpect' installing (fedora 22) to run at all but after that 
it worked to an extent as I had to correct the stored passphrase to correct 
other errors.
At this stage of the build there is very little in 
'build/tmp/sysroots/x86_64-linux/etc/' (just quilt related) but I also find it 
curious that it is looking for the variable name rather than it value.
Now I was following the the Aug patch notes "'RPM_GPG_PUBKEY = 
"" in bitbake config pointing to the public key (in "armor" 
format).".
Since then there was a patch "Automatically export public keys used for 
package(feed) signing" that obsoletes RPM_GPG_PUBKEY (and overwrites it) but 
I'm still not clear how/where to put the public key so it will end up in the 
staging directory.  Also, 'package_manager.py' copies the file named by 
RPM_GPG_PUBKEY to the location os.path.join(self.deploy_dir, 'RPM-GPG-KEY-%s' % 
distro_version).  I presume this copies from the staging directory to the 
deployment directory.
So what I would like to know is where to put the RPM GPG public key so that it 
gets copied to the staging directory?
For the time being, I have copied it in by hand.
Thanks,Chris
Summary: 1 task failed:poky/meta/recipes-core/os-release/os-release.bb, 
do_compile
DEBUG: Executing python function do_compileERROR: Error executing a python 
function in /home/chris/yocto/poky/meta/recipes-core/os-release/os-release.bb:
The stack trace of python calls that resulted in this exception/failure 
was:File: '/home/chris/yocto/poky/meta/recipes-core/os-release/os-release.bb', 
lineno: 16, function:  0012:distro_version = 
d.getVar('DISTRO_VERSION', True) or "oe.0" 0013:
shutil.copy2(rpm_gpg_pubkey, 
d.expand('/home/chris/yocto/build/tmp/work/all-poky-linux/os-release/1.0-r0/os-release-1.0/rpm-gpg/RPM-GPG-KEY-%s'
 % distro_version)) 0014: 0015: *** 0016:do_compile(d) 0017:File: 
'/home/chris/yocto/poky/meta/recipes-core/os-release/os-release.bb', lineno: 
13, function: do_compile 0009:do_fetch[noexec] = "1" 
0010:do_unpack[noexec] = "1" 0011:do_patch[noexec] = "1" 
0012:do_configure[noexec] = "1" *** 0013: 0014:# Other valid fields: 
BUILD_ID ID_LIKE ANSI_COLOR CPE_NAME 0015:# HOME_URL 
SUPPORT_URL BUG_REPORT_URL 0016:OS_RELEASE_FIELDS = "ID ID_LIKE NAME 
VERSION VERSION_ID PRETTY_NAME" 0017:File: 
'/usr/lib64/python2.7/shutil.py', lineno: 130, function: copy2 0126: 
0127:""" 0128:if os.path.isdir(dst): 0129:dst = 
os.path.join(dst, os.path.basename(src)) *** 0130:copyfile(src, dst) 
0131:copystat(src, dst) 0132: 0133:def ignore_patterns(*patterns):  
   0134:"""Function that can be used as copytree() ignore parameter.File: 
'/usr/lib64/python2.7/shutil.py', lineno: 82, function: copyfile 0078:  
  # XXX What about other special files? (sockets, devices...) 0079: 
   if stat.S_ISFIFO(st.st_mode): 0080:raise 
SpecialFileError("`%s` is a named pipe" % fn) 0081: *** 0082:with 
open(src, 'rb') as fsrc: 0083:with open(dst, 'wb') as fdst: 
0084:copyfileobj(fsrc, fdst) 0085: 0086:def copymode(src, 
dst):Exception: IOError: [Errno 2] No such file or directory: 
'/home/chris/yocto/build/tmp/sysroots/x86_64-linux/etc/RPM-GPG-PUBKEY'
DEBUG: Python function do_compile finishedERROR: Function failed: do_compile
  -- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Handling Duplicate Files

[Chris Trobridge]

(I posted this to openembedded-core but it appears to have got lost in the 
noise!)

Hi,

I have been looking into producing a 'python3-dbus' recipe, based on the 
python-dbus recipe.

This recipe outputs a couple of files that are version independent but end up 
overlapping and causing the build to fail:
/usr/lib/pkgconfig/dbus-python.pc
/usr/include/dbus-1.0/dbus/dbus-python.h

These files are currently marked as python-version independent - the header 
file has #ifdefs for python3.

The immediate 'fix' was to follow the advice in the error text to add the file 
paths to SSTATE_DUPWHITELIST.

SSTATE_DUPWHITELIST is not mentioned much elsewhere and does not seem like a 
scalable solution.  Is there a preferred method to resolve the situation where 
two recipes install the same files?

Thanks,
Chris

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

[yocto] Live Image Behaviour

[Chris Trobridge]

I was testing out a new image this afternoon and all was well until I fdisk'd 
the partitions away on /dev/sda (with the live image booting from a usb stick 
on /dev/sdc).
After this the image stopped booting and started complaining about all sorts of 
FAT errors on /dev/sda and did not mount the root file system.
Nothing I could do to sort out this issue until I dd'd the live image onto 
/dev/sda, which then booted from /dev/sda1.
After this I could now also boot from /dev/sdc too but /media/realroot was 
mounted on /dev/sda1.
I renamed the root file system file on /dev/sda1, rebooted and now 
/media/realroot was mounted on /dev/sdc1.
All the time I was also able to boot the image fine in qemu.
Regarding the install option on the EFI boot, initially it was offering to 
install on /dev/sdb but this changed to /dev/sda once I'd renamed the root file 
system on /dev/sda.
Anyway this suggests to me that the live image will preferentially mount a root 
file system from /dev/sda in preference to the file on the boot device.  This 
wasn't an issue after I followed through the 'install' option as it lays out 
the installation over two partitions without using a loop-back device but the 
issue it had dealing with the 'corrupt' file system on /dev/sda may be 
significant.
Regards,Chris
  -- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto