[yocto] Kernel configuration problems

2018-07-27 Thread Greg Wilson-Lindberg 
I'm trying to add a couple of drivers to the kernel in a Raspberry pi3 build.



I've got the passing of the config options working, but I'm getting warnings 
from the kernel build that the options are not being applied:





WARNING: linux-raspberrypi-1_4.4.50+gitAUTOINC+04c8e47067-r0 
do_kernel_configcheck: [kernel config]: specified values did not make it into 
the kernel's final configuration:

-- CONFIG_SND_SOC_MAX9768 -
Config: CONFIG_SND_SOC_MAX9768
From: 
/home/gwilson/Qt/Qt-5.9.6/Yocto-build-RPi3/build-raspberrypi3/tmp/work-shared/raspberrypi3/kernel-source/.kernel-meta/configs/Scribe.cfg
Requested value:  CONFIG_SND_SOC_MAX9768=y
Actual value:

Config 'SND_SOC_MAX9768' has the following conditionals:

Dependency values are:


-- CONFIG_MAX1363 -
Config: CONFIG_MAX1363
From: 
/home/gwilson/Qt/Qt-5.9.6/Yocto-build-RPi3/build-raspberrypi3/tmp/work-shared/raspberrypi3/kernel-source/.kernel-meta/configs/Scribe.cfg
Requested value:  CONFIG_MAX1363=m
Actual value: # CONFIG_MAX1363 is not set

Config 'MAX1363' has the following conditionals:
  I2C (value: "y")
Dependency values are:
  I2C [y]


My problem is that I don't understand why the options are not being applied.

For the MAX_9768, it depends on I2C=y which is true. I've run the linux kernel 
menu config and when I get to the Sound SOC support none of the drivers that 
require I2C support (i.e. 'select SND_SOC_MAX9768 if I2C') are displayed. I 
don't see anything else that would disable them, the other drivers in the SOC 
Kconfig that don't depend on I2C or that depend on SPI_MASTER are displayed.

The MAX1363 can be set in the menuconfig to 'm', but still won't set from the 
scc, cfg files.



Any insight into what's going on here would be greatly appreciated.

Regards,




Greg Wilson-Lindberg


Principal Firmware Engineer | Sakura Finetek USA, Inc.





1750 W 214th Street | Torrance, CA 90501 | U.S.A.


T: +1 310 783 5075


F: +1 310 618 6902 | E: gwil...@sakuraus.com


www.sakuraus.com





[cid:image002.png@01D35D7D.179A7510]


[cid:image003.png@01D35D7D.179A7510]






Confidentiality Notice: This e-mail transmission may contain confidential or 
legally privileged information that is intended only for the individual or 
entity named in the e-mail address. If you are not the intended recipient, you 
are hereby notified that any disclosure, copying, distribution, or reliance 
upon the contents of this e-mail is strictly prohibited. If you have received 
this e-mail transmission in error, please reply to the sender, so that Sakura 
Finetek USA, Inc. can arrange for proper delivery, and then please delete the 
message from your inbox. Thank you.





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

Re: [yocto] Removing syslogd form busybox

2018-07-27 Thread 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

[yocto] Removing syslogd form busybox

2018-07-27 Thread Simon Chamlian 
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  neon
callconvention-hardcortexa7"
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?

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

Re: [yocto] [oe] [meta-openembedded] Original ltrace_git.bb SRCREV commit used is now unavailable in git tarball from ltrace.org

2018-07-27 Thread Randy MacLeod 

On 07/27/2018 06:34 AM, Aditya Tayade wrote:

Hi,


Me too facing same issue. Any advice on this.


Archived versions to fix previous releases may be here:
   https://alioth-archive.debian.org/git/collab-maint/

for master, a commit to pull from ltrace.org makes sense
to me but someone who follows debian development might
be able to help locate the git repo. All I found was:
   https://alioth-archive.debian.org/git/collab-maint/
and a maze of twisty little hyperlinks.

Aditya, Nisha,

Will you send a patch? See:
   https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded

../Randy






Regards,

Aditya Tayade


From: Nisha Parrakat
Sent: Tuesday, July 24, 2018 4:08:12 PM
To: openembedded-iss...@lists.openembedded.org; 
openembedded-de...@lists.openembedded.org
Cc: yocto@yoctoproject.org
Subject: [meta-openembedded] Original ltrace_git.bb SRCREV commit used is now 
unavailable in git tarball from ltrace.org


Hi all,


ltrace recipe is pointing to a fetch url 
(git://anonscm.debian.org/collab-maint/ltrace.git;branch=master) that is 
discontinued now.

No ltrace found in alternate salsa.debian.org.

Tarball for ltrace is present in ltrace.org but the SRCREV in the mentioned in 
the original recipe is not found any more but we do see the same commit with 
another sha but a different git history.


Please advice if we should modify the SRCREV to reflect the new git source from 
ltrace.org?


original SRCREV in recipe c22d3594...

corresponding SRCREV coming from the git tarball is ea8928da...


Please advice .




Regards,
Ms Nisha Parrakat
KPIT Technologies Ltd, Pune, INDIA


This message contains information that may be privileged or confidential and is 
the property of the KPIT Technologies Ltd. It is intended only for the person 
to whom it is addressed. If you are not the intended recipient, you are not 
authorized to read, print, retain copy, disseminate, distribute, or use this 
message or any part thereof. If you receive this message in error, please 
notify the sender immediately and delete all copies of this message. KPIT 
Technologies Ltd. does not accept any liability for virus infected mails.




--
# Randy MacLeod
# Wind River Linux
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[linux-yocto] v4.12.x - stable updates comprising v4.12.27

2018-07-27 Thread Paul Gortmaker 
Bruce, Yocto kernel folks:

Here is another 4.12.x stable update "extension" primarily created for
the Yocto project, continuing on top of the previous v4.12.26 kernel.

Hopefully people using 4.12.x are already getting their plans in place
to moving to a newer kernel in the near future, as the number of
additional 4.12.x releases that I do will probably be limited to a
couple more over the next month or so.

This is the second release in a row with the normal "one issue -- one
commit" type of stable content, which is nice.  There are about 125
commits here, based on commits chosen from what was used in existing
4.14.x stable releases.

I've put this 4.12.x queue through the usual testing that I figured made
sense, which is in line with that listed explicitly in previous release
announcements.

I did the signed tag just as per the previously released 4.12.x versions.

Please find a signed v4.12.27 tag using this key:

http://pgp.mit.edu/pks/lookup?op=vindex=0xEBCE84042C07D1D6

in the repo in the kernel.org directory here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/linux-4.12.y.git/
   git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux-4.12.y.git

for merge to standard/base in linux-yocto-4.12 and then out from there
into the other base and BSP branches.

For those who are interested, the evolution of the commits is here:

   https://git.kernel.org/cgit/linux/kernel/git/paulg/longterm-queue-4.12.git/

This repo isn't needed for anything; it just exists for transparency and
so people can see the evolution of the raw commits that were originally
selected to create this 4.12.x release.

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

Re: [yocto] custom linux kernel recipe fails

2018-07-27 Thread Steve Pavao 
On Jul 26, 2018, at 12:56 PM, Steve Pavao  wrote:
> 
> I’m trying to build using a custom 64-bit kernel at head of sumo, but I get 
> an error.  It seems that SRCPV cannot be resolved.Please send any ideas 
> you may have about how I may adapt my recipe to get it to work.

[snip portion of recipe]

> SRC_URI = 
> "http://gitlab.denx.de/Xenomai/ipipe-arm64;protocol=http;branch=master;nocheckout=1
>  
> "
> SRCREV = "133bbf97672ff6e72fc21784b8ae44b194b76626"



I was able to avoid the error by using the following line for the SRC_URI 
instead:

SRC_URI = "git://gitlab.denx.de/Xenomai/ipipe-arm64;protocol=http 
”

- Steve

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

Re: [yocto] [meta-raspberrypi] - X11 EGLSV2 Chromium

2018-07-27 Thread Gillani, Karim CITZ:EX 
Sure, I have tried various builds from Rocko, Sumo and Master.

Here is one with Master, and I am rebuilding with Sumo as long term, that is 
what I would like to use.


Build Configuration:

BB_VERSION   = "1.39.0"

BUILD_SYS= "x86_64-linux"

NATIVELSBSTRING  = "universal"

TARGET_SYS   = "arm-poky-linux-gnueabi"

MACHINE  = "raspberrypi3"

DISTRO   = "poky"

DISTRO_VERSION   = "2.5+snapshot-20180717"

TUNE_FEATURES= "arm armv7ve vfp thumb neon vfpv4 callconvention-hard 
cortexa7"

TARGET_FPU   = "hard"

meta

meta-poky

meta-yocto-bsp   = "master:05c32d2de1ee4681cc78cb107a158e9ab22c9619"

meta-oe

meta-python  = "master:6a0efef15cd625d4fb4f60e2235450de0222c357"

meta-raspberrypi = "master:6888a49ae84445136d138087290efcf6793c4149"

meta-networking

meta-multimedia  = "master:6a0efef15cd625d4fb4f60e2235450de0222c357"

meta-browser = "master:d807b901b0b68b478093964bd60a77b9376b3f12"

meta-sbc = ":"

Note meta-sbc, is my custom layer to add wifi, ufw, and (long term – mender).

Also, here is the Sumo I am building with right now (using the same local.conf)


Build Configuration:

BB_VERSION   = "1.38.0"

BUILD_SYS= "x86_64-linux"

NATIVELSBSTRING  = "ubuntu-16.04"

TARGET_SYS   = "arm-poky-linux-gnueabi"

MACHINE  = "raspberrypi3"

DISTRO   = "poky"

DISTRO_VERSION   = "2.5"

TUNE_FEATURES= "arm armv7ve vfp thumb neon vfpv4 callconvention-hard 
cortexa7"

TARGET_FPU   = "hard"

meta

meta-poky

meta-yocto-bsp   = "sumo:96fbd39ba32362416c18d90bb7a81eb6a76912e0"

meta-oe

meta-python

meta-multimedia

meta-networking  = "sumo:b0950aeff5b630256bb5e25ca15f4d59c115e7c1"

meta-raspberrypi = "sumo:cdb2dad529ba102feabeac4e4f58a09fe76edfd1"

meta-browser = "master:d807b901b0b68b478093964bd60a77b9376b3f12"


Thanks


From: Trevor Woerner [mailto:twoer...@gmail.com]
Sent: Sunday, July 22, 2018 5:48 PM
To: Gillani, Karim CITZ:EX 
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] [meta-raspberrypi] - X11 EGLSV2 Chromium

Hi Karim,

Can you please also include the "Build Configuration" block that's printed at 
the start of the build? That way we know what layers you're using, and which 
branches/commits of those layers.

Best regards,
Trevor
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] custom linux kernel recipe fails

2018-07-27 Thread Steve Pavao 

> On Jul 26, 2018, at 9:57 PM, ChenQi  wrote:
> 
> On 07/27/2018 12:56 AM, Steve Pavao wrote:
>> Hello -
>> 
>> I’m trying to build using a custom 64-bit kernel at head of sumo, but I get 
>> an error.  It seems that SRCPV cannot be resolved.Please send any ideas 
>> you may have about how I may adapt my recipe to get it to work.
>> 
>> Normally, I use the default meta-raspberrypi kernel, but for this build, I 
>> am using PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-custom” in my 
>> local.conf
>> 
>> My simple kernel recipe is in linux-yocto-custom.bb.  (It is based on the 
>> example recipe).
>> 
>> inherit kernel
>> require recipes-kernel/linux/linux-yocto.inc
>> 
>> PV = "${LINUX_VERSION}+git${SRCPV}"
>> PR = "r0"
>> 
>> LINUX_VERSION ?= "4.14.4"
>> LINUX_VERSION_EXTENSION_append = "-xenomai-ipipe-arm64"
>> 
>> SRC_URI = 
>> "http://gitlab.denx.de/Xenomai/ipipe-arm64;protocol=http;branch=master;nocheckout=1;
>>  
>> 
>> SRCREV = "133bbf97672ff6e72fc21784b8ae44b194b76626"
> 
> Try:
> SRC_URI = 
> "http://gitlab.denx.de/Xenomai/ipipe-arm64;protocol=http;branch=master;nocheckout=1;name=machine;
>  
> 
> SRCREV_machine = "133bbf97672ff6e72fc21784b8ae44b194b76626"
> Best Regards,
> Chen Qi

Thanks for the idea, Chean Qui.  I tried it, but I still got the same WARNINGS 
and ERROR.

- Steve

> 
>> SRC_URI[md5sum] = "a5cb3babd85a94fda2905cc3db5e7825"
>> 
>> COMPATIBLE_MACHINE = "raspberrypi3-64"
>> 
>> the error:
>> 
>> WARNING: 
>> /data/development/lfs/yocto/poky/meta-korg-spark/recipes-kernel/linux/linux-yocto-custom.bb:
>>  Exception during build_dependencies for PKG_kernel-base
>> WARNING: 
>> /data/development/lfs/yocto/poky/meta-korg-spark/recipes-kernel/linux/linux-yocto-custom.bb:
>>  Error during finalise of 
>> /data/development/lfs/yocto/poky/meta-korg-spark/recipes-kernel/linux/linux-yocto-custom.bb
>> ERROR: ExpansionError during parsing 
>> /data/development/lfs/yocto/poky/meta-korg-spark/recipes-kernel/linux/linux-yocto-custom.bb
>> Traceback (most recent call last):
>> bb.data_smart.ExpansionError: Failure expanding variable PKG_kernel-base, 
>> expression was 
>> kernel-${@legitimize_package_name('${@get_kernelversion_headers('/data/development/lfs/yocto/build/spark/raspberrypi3-64/tmp/work/raspberrypi3_64-poky-linux/linux-yocto-custom/4.14.4+git${SRCPV}-r0/linux-raspberrypi3_64-standard-build')}')}
>>  which triggered exception SyntaxError: invalid syntax (PKG_kernel-base, 
>> line 1)
>> 
> 

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

Re: [yocto] Intel machine with 64 Bit kernel and 32 Bit user space

2018-07-27 Thread Martin Jansa 
Check with bitbake -g what's pulling gcc-runtime into the image, if your
whole userspace should be 32bit, then lib32-gcc-runtime will be enough.

My multilib builds contain only following 64bit builds:
defaultpkgname  depmodwrapper-cross  linux-yocto  lttng-modules
make-mod-scripts  qemuwrapper-cross  vboxguestdrivers
the rest is 32bit

On Fri, Jul 27, 2018 at 12:23 PM Ayoub Zaki 
wrote:

> Hello all,
>
> thanks for the suggestions: I tried the multilib concept of yocto but as
> Martin already wrote is not that simple, my build is breaking during wic
> image generation as follow:
>
> zaki@xps:/opt/build/poky/build$ MACHINE=nx bitbake  lib32-my-image
> Loading cache: 100%
> ||
> Time: 0:00:00
> Loaded 4968 entries from dependency cache.
> NOTE: Resolving any missing task queue dependencies
>
> Build Configuration:
> BB_VERSION   = "1.38.0"
> BUILD_SYS= "x86_64-linux"
> NATIVELSBSTRING  = "universal"
> TARGET_SYS   = "x86_64-poky-linux"
> MACHINE  = "nx"
> DISTRO   = "poky"
> DISTRO_VERSION   = "V00.00.00.00+20180727100935"
> TUNE_FEATURES= "m64 core2"
> TARGET_FPU   = ""
> meta
> meta-poky
> meta-yocto-bsp   = "sumo:90f7edb32ac2500d93bb7ca5045a9d048f551223"
> meta-intel   = "sumo:2430f73ee06f3315ebebe69899f1977f9a09e29f"
> meta-oe
> meta-networking
> meta-webserver
> meta-python  = "sumo:b0950aeff5b630256bb5e25ca15f4d59c115e7c1"
>
> Initialising tasks: 100%
> |###|
> Time: 0:00:02
> NOTE: Executing SetScene Tasks
> NOTE: Executing RunQueue Tasks
> WARNING: lib32-my-image-1.0-r0 do_rootfs: lib32-systemd.postinst returned
> 1, marking as unpacked only, configuration required on target.
> WARNING: lib32-my-image-1.0-r0 do_rootfs: Intentionally failing
> postinstall scriptlets of ['lib32-systemd'] to defer them to first boot is
> deprecated. Please place them into pkg_postinst_ontarget_${PN} ().
> If deferring to first boot wasn't the intent, then scriptlet failure may
> mean an issue in the recipe, or a regression elsewhere.
> Details of the failure are in
> /opt/build/poky/build/tmp/work/nx-pokymllib32-linux/lib32-my-image/1.0-r0/temp/log.do_rootfs.
> WARNING: lib32-my-image-1.0-r0 do_rootfs: [log_check] lib32-my-image:
> found 1 warning message in the logfile:
> [log_check] WARNING: Intentionally failing postinstall scriptlets of
> ['lib32-systemd'] to defer them to first boot is deprecated. Please place
> them into pkg_postinst_ontarget_${PN} ().
> ERROR: lib32-my-image-1.0-r0 do_image_wic: The file
> /usr/share/gcc-7.3.0/python/libstdcxx/__init__.py is installed by both
> lib32-gcc-runtime and gcc-runtime, aborting
> ERROR: lib32-my-image-1.0-r0 do_image_wic: Function failed:
> extend_recipe_sysroot
> ERROR: Logfile of failure stored in:
> /opt/build/poky/build/tmp/work/nx-pokymllib32-linux/lib32-my-image/1.0-r0/temp/log.do_image_wic.16922
> ERROR: Task
> (virtual:multilib:lib32:/opt/build/poky/meta-poky/recipes-core/images/my-image.bb:do_image_wic)
> failed with exit code '1'
> NOTE: Tasks Summary: Attempted 3460 tasks of which 3445 didn't need to be
> rerun and 1 failed.
>
> Summary: 1 task failed:
>
> virtual:multilib:lib32:/opt/build/poky/meta-poky/recipes-core/images/my-image.bb:
> do_image_wic
> Summary: There were 3 WARNING messages shown.
> Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
>
>
> The ERROR: lib32-my-image-1.0-r0 do_image_wic: The file
> /usr/share/gcc-7.3.0/python/libstdcxx/__init__.py is installed by both
> lib32-gcc-runtime and gcc-runtime, aborting is not self-explanatory!
>
> gcc-runtime is anyway not part of the image ?!
>
> any suggestions ?
>
>
> thank you
>
>
> Best regards
>
> On Thu, Jul 26, 2018 at 8:12 PM, Martin Jansa 
> wrote:
>
>> It's not as simple as that in some cases, there are some components which
>> are pulled in 64bit version even when building lib32-foo-image.
>>
>> Some are easy to override from the config e.g.:
>> ROOTFS_PKGMANAGE = "${LIB32_PREFIX}opkg"
>> SPLASH = "${LIB32_PREFIX}psplash"
>>
>> but to prevent building e.g. syslinux in 64bit version is a bit more
>> tricky.
>>
>> syslinux.bbclass was fixed long time ago:
>> commit c8dc421ea18bb7a810501ab6d07efa9c8f6d6eb9
>> Author: Ming Liu 
>> Date:   Thu Jun 19 16:42:58 2014 +0800
>>
>> syslinux.bbclass: Ensure MLPREFIX is applied to depends flag
>>
>> Add MLPREFIX to depends flag to ensure the correct syslinux is
>> dependended upon.
>>
>> -do_bootimg[depends] += "syslinux:do_populate_sysroot \
>> +do_bootimg[depends] += "${MLPREFIX}syslinux:do_populate_sysroot \
>>
>> but wic still depends on syslinux without MLPREFIX:
>>
>>

Re: [yocto] Intel machine with 64 Bit kernel and 32 Bit user space

2018-07-27 Thread Burton, Ross 
On 27 July 2018 at 11:23, Ayoub Zaki  wrote:
> The ERROR: lib32-my-image-1.0-r0 do_image_wic: The file
> /usr/share/gcc-7.3.0/python/libstdcxx/__init__.py is installed by both
> lib32-gcc-runtime and gcc-runtime, aborting is not self-explanatory!
>
> gcc-runtime is anyway not part of the image ?!

It will be as you'll need it to run many binaries built by gcc.

Those files should be in gcc-runtime-dbg though, so I suggest you look
at your local customisations and see why they're in that package.

See gcc-runtime.inc:

# include python debugging scripts
FILES_${PN}-dbg += "\
${libdir}/libstdc++.so.*-gdb.py \
${datadir}/gcc-${BINV}/python/libstdcxx \
"

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

Re: [yocto] [meta-openembedded] Original ltrace_git.bb SRCREV commit used is now unavailable in git tarball from ltrace.org

2018-07-27 Thread Aditya Tayade 
Hi,


Me too facing same issue. Any advice on this.



Regards,

Aditya Tayade


From: Nisha Parrakat
Sent: Tuesday, July 24, 2018 4:08:12 PM
To: openembedded-iss...@lists.openembedded.org; 
openembedded-de...@lists.openembedded.org
Cc: yocto@yoctoproject.org
Subject: [meta-openembedded] Original ltrace_git.bb SRCREV commit used is now 
unavailable in git tarball from ltrace.org


Hi all,


ltrace recipe is pointing to a fetch url 
(git://anonscm.debian.org/collab-maint/ltrace.git;branch=master) that is 
discontinued now.

No ltrace found in alternate salsa.debian.org.

Tarball for ltrace is present in ltrace.org but the SRCREV in the mentioned in 
the original recipe is not found any more but we do see the same commit with 
another sha but a different git history.


Please advice if we should modify the SRCREV to reflect the new git source from 
ltrace.org?


original SRCREV in recipe c22d3594...

corresponding SRCREV coming from the git tarball is ea8928da...


Please advice .




Regards,
Ms Nisha Parrakat
KPIT Technologies Ltd, Pune, INDIA


This message contains information that may be privileged or confidential and is 
the property of the KPIT Technologies Ltd. It is intended only for the person 
to whom it is addressed. If you are not the intended recipient, you are not 
authorized to read, print, retain copy, disseminate, distribute, or use this 
message or any part thereof. If you receive this message in error, please 
notify the sender immediately and delete all copies of this message. KPIT 
Technologies Ltd. does not accept any liability for virus infected mails.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Intel machine with 64 Bit kernel and 32 Bit user space

2018-07-27 Thread Ayoub Zaki 
Hello all,

thanks for the suggestions: I tried the multilib concept of yocto but as
Martin already wrote is not that simple, my build is breaking during wic
image generation as follow:

zaki@xps:/opt/build/poky/build$ MACHINE=nx bitbake  lib32-my-image
Loading cache: 100%
||
Time: 0:00:00
Loaded 4968 entries from dependency cache.
NOTE: Resolving any missing task queue dependencies

Build Configuration:
BB_VERSION   = "1.38.0"
BUILD_SYS= "x86_64-linux"
NATIVELSBSTRING  = "universal"
TARGET_SYS   = "x86_64-poky-linux"
MACHINE  = "nx"
DISTRO   = "poky"
DISTRO_VERSION   = "V00.00.00.00+20180727100935"
TUNE_FEATURES= "m64 core2"
TARGET_FPU   = ""
meta
meta-poky
meta-yocto-bsp   = "sumo:90f7edb32ac2500d93bb7ca5045a9d048f551223"
meta-intel   = "sumo:2430f73ee06f3315ebebe69899f1977f9a09e29f"
meta-oe
meta-networking
meta-webserver
meta-python  = "sumo:b0950aeff5b630256bb5e25ca15f4d59c115e7c1"

Initialising tasks: 100%
|###|
Time: 0:00:02
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
WARNING: lib32-my-image-1.0-r0 do_rootfs: lib32-systemd.postinst returned
1, marking as unpacked only, configuration required on target.
WARNING: lib32-my-image-1.0-r0 do_rootfs: Intentionally failing postinstall
scriptlets of ['lib32-systemd'] to defer them to first boot is deprecated.
Please place them into pkg_postinst_ontarget_${PN} ().
If deferring to first boot wasn't the intent, then scriptlet failure may
mean an issue in the recipe, or a regression elsewhere.
Details of the failure are in
/opt/build/poky/build/tmp/work/nx-pokymllib32-linux/lib32-my-image/1.0-r0/temp/log.do_rootfs.
WARNING: lib32-my-image-1.0-r0 do_rootfs: [log_check] lib32-my-image: found
1 warning message in the logfile:
[log_check] WARNING: Intentionally failing postinstall scriptlets of
['lib32-systemd'] to defer them to first boot is deprecated. Please place
them into pkg_postinst_ontarget_${PN} ().
ERROR: lib32-my-image-1.0-r0 do_image_wic: The file
/usr/share/gcc-7.3.0/python/libstdcxx/__init__.py is installed by both
lib32-gcc-runtime and gcc-runtime, aborting
ERROR: lib32-my-image-1.0-r0 do_image_wic: Function failed:
extend_recipe_sysroot
ERROR: Logfile of failure stored in:
/opt/build/poky/build/tmp/work/nx-pokymllib32-linux/lib32-my-image/1.0-r0/temp/log.do_image_wic.16922
ERROR: Task
(virtual:multilib:lib32:/opt/build/poky/meta-poky/recipes-core/images/my-image.bb:do_image_wic)
failed with exit code '1'
NOTE: Tasks Summary: Attempted 3460 tasks of which 3445 didn't need to be
rerun and 1 failed.

Summary: 1 task failed:

virtual:multilib:lib32:/opt/build/poky/meta-poky/recipes-core/images/my-image.bb:
do_image_wic
Summary: There were 3 WARNING messages shown.
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.


The ERROR: lib32-my-image-1.0-r0 do_image_wic: The file
/usr/share/gcc-7.3.0/python/libstdcxx/__init__.py is installed by both
lib32-gcc-runtime and gcc-runtime, aborting is not self-explanatory!

gcc-runtime is anyway not part of the image ?!

any suggestions ?


thank you


Best regards

On Thu, Jul 26, 2018 at 8:12 PM, Martin Jansa 
wrote:

> It's not as simple as that in some cases, there are some components which
> are pulled in 64bit version even when building lib32-foo-image.
>
> Some are easy to override from the config e.g.:
> ROOTFS_PKGMANAGE = "${LIB32_PREFIX}opkg"
> SPLASH = "${LIB32_PREFIX}psplash"
>
> but to prevent building e.g. syslinux in 64bit version is a bit more
> tricky.
>
> syslinux.bbclass was fixed long time ago:
> commit c8dc421ea18bb7a810501ab6d07efa9c8f6d6eb9
> Author: Ming Liu 
> Date:   Thu Jun 19 16:42:58 2014 +0800
>
> syslinux.bbclass: Ensure MLPREFIX is applied to depends flag
>
> Add MLPREFIX to depends flag to ensure the correct syslinux is
> dependended upon.
>
> -do_bootimg[depends] += "syslinux:do_populate_sysroot \
> +do_bootimg[depends] += "${MLPREFIX}syslinux:do_populate_sysroot \
>
> but wic still depends on syslinux without MLPREFIX:
>
> meta/conf/machine/qemux86-64.conf:do_image_wic[depends] +=
> "syslinux:do_populate_sysroot syslinux-native:do_populate_sysroot
> mtools-native:do_populate_sysroot dosfstools-nat...
> meta/conf/machine/qemux86.conf:do_image_wic[depends] +=
> "syslinux:do_populate_sysroot syslinux-native:do_populate_sysroot
> mtools-native:do_populate_sysroot dosfstools-native...
>
> similarly opkg-utils and some other components are pulled in the
> not-prefixed version even when building image with a prefix. I've
> eventually got it working with morty (that it was really building only
> couple

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

2018-07-27 Thread MOHAMMAD RASIM 

Can you send the patch yourself since you already know how to do it ?


On 07/27/2018 12:34 PM, Burton, Ross wrote:

We don't take patches via pull requests (that repo is a mirror for
convenience and should have PRs disabled), but patches on the
openembedded-core mailing list.

https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines has
details as to the required patch formatting.  Summary:

Commit message should be of the form 'recipe: summary'.  The patch
you're adding also needs a summary explaining what it does, an
Upstream-Status value (Pending I guess, as upstream is dead we can't
submit it) and your Signed-off-by.

Ross

On 27 July 2018 at 10:27, MOHAMMAD RASIM  wrote:

Yes I made a pull request to the master branch
https://github.com/openembedded/openembedded-core/pull/34

note that this issue can be replicated by unzipping any linux-kernel (I
think), I tested that it exist in the zip file of torvalds tree
https://github.com/torvalds/linux/archive/master.zip

so it's easy to replicate and test

Also, to anyone how face the same issue and find this message, I solved the
issue without patching unzip by using tar.gz file instead of unzip file
(thanks to github for providing that) so instead of
https://github.com/torvalds/linux/archive/master.zip use
https://github.com/torvalds/linux/archive/master.tar.gz


Thanks



On 07/23/2018 09:51 PM, Burton, Ross wrote:

Yes, please do.  Mohammad, as you can replicate this on demand, would
you be able to fix the unzip recipe with the patch in that bug and
send a patch?

Ross

On 23 July 2018 at 19:42, Andre McCurdy  wrote:

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




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

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

2018-07-27 Thread Burton, Ross 
We don't take patches via pull requests (that repo is a mirror for
convenience and should have PRs disabled), but patches on the
openembedded-core mailing list.

https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines has
details as to the required patch formatting.  Summary:

Commit message should be of the form 'recipe: summary'.  The patch
you're adding also needs a summary explaining what it does, an
Upstream-Status value (Pending I guess, as upstream is dead we can't
submit it) and your Signed-off-by.

Ross

On 27 July 2018 at 10:27, MOHAMMAD RASIM  wrote:
> Yes I made a pull request to the master branch
> https://github.com/openembedded/openembedded-core/pull/34
>
> note that this issue can be replicated by unzipping any linux-kernel (I
> think), I tested that it exist in the zip file of torvalds tree
> https://github.com/torvalds/linux/archive/master.zip
>
> so it's easy to replicate and test
>
> Also, to anyone how face the same issue and find this message, I solved the
> issue without patching unzip by using tar.gz file instead of unzip file
> (thanks to github for providing that) so instead of
> https://github.com/torvalds/linux/archive/master.zip use
> https://github.com/torvalds/linux/archive/master.tar.gz
>
>
> Thanks
>
>
>
> On 07/23/2018 09:51 PM, Burton, Ross wrote:
>>
>> Yes, please do.  Mohammad, as you can replicate this on demand, would
>> you be able to fix the unzip recipe with the patch in that bug and
>> send a patch?
>>
>> Ross
>>
>> On 23 July 2018 at 19:42, Andre McCurdy  wrote:
>>>
>>> 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
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

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

2018-07-27 Thread MOHAMMAD RASIM 
Yes I made a pull request to the master branch 
https://github.com/openembedded/openembedded-core/pull/34


note that this issue can be replicated by unzipping any linux-kernel (I 
think), I tested that it exist in the zip file of torvalds tree 
https://github.com/torvalds/linux/archive/master.zip


so it's easy to replicate and test

Also, to anyone how face the same issue and find this message, I solved 
the issue without patching unzip by using tar.gz file instead of unzip 
file (thanks to github for providing that) so instead of 
https://github.com/torvalds/linux/archive/master.zip use 
https://github.com/torvalds/linux/archive/master.tar.gz



Thanks


On 07/23/2018 09:51 PM, Burton, Ross wrote:

Yes, please do.  Mohammad, as you can replicate this on demand, would
you be able to fix the unzip recipe with the patch in that bug and
send a patch?

Ross

On 23 July 2018 at 19:42, Andre McCurdy  wrote:

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


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

Re: [yocto] How to force build of a blacklisted recipe?

2018-07-27 Thread MOHAMMAD RASIM 
Yeah I found the PNBLACKLIST line at the end of the recipe after Paul 
Eggleton message :-D, thanks for the tip anyway Max :-*



On 07/26/2018 10:45 PM, Max Krummenacher wrote:

Hi


I'm trying to build dvb-apps recipe which is blacklisted and was removed
from the newer openembedded releases, but it exist in the release I work
with

Now when I try to build the recipe I get this error:

  >ERROR:
/home/oealliancebuilder/openpli-oe-core/meta-openembedded/meta-multimedia/recipes-dvb/dvb-
apps/dvb-apps_1.1.1.bb
was skipped: Recipe is blacklisted: Fails to build with RSS
http://errors.yoctoproject.org/Errors/Details/130603/ - the recipe will
be removed on 2017-09-01 unless the issue is fixed

But I want to tell openembedded to override the blacklisting and build
the recipe anyway so I can investigate and hopefully fix the recipe. How
can I do that ?

You could overwrite the assignment to PNBLACKLIST in conf/local.conf:

PNBLACKLIST[dvb-apps] = ""

However, if you anyway want to work on the recipe you could simply delete
the PNBLACKLIST line in the dvb-apps recipe.

Max


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

[yocto] meta-ide-support broken in Sumo 2.5

2018-07-27 Thread Amol Lad 
Hi,

Sysroot which is generated by meta-ide-support for use in eclipse is missing 
header files. For example, expat.h is missing in recipe-sysroot folder and only 
present in recipe-sysroot-native folder.

alad@4rf-ind-yocto:~/yocto2.5/poky/build/tmp/work/clearfog-poky-linux-gnueabi/core-image-minimal/1.0-r0$
 find . -iname expat.h
./recipe-sysroot-native/usr/include/expat.h
alad@4rf-ind-yocto:~/yocto2.5/poky/build/tmp/work/clearfog-poky-linux-gnueabi/core-image-minimal/1.0-r0$

alad@4rf-ind-yocto:~/yocto2.5/poky/build/tmp/work/armv7ahf-neon-poky-linux-gnueabi/meta-ide-support/1.0-r3$
 find . -iname expat.h
./recipe-sysroot-native/usr/include/expat.h
alad@4rf-ind-yocto:~/yocto2.5/poky/build/tmp/work/armv7ahf-neon-poky-linux-gnueabi/meta-ide-support/1.0-r3$

As a result our eclipse projects are not compiling. This problem is not in 
krogoth and expat.h is present in target system.

Please advise if I'm looking at wrong place for sysroot generated by 
meta-ide-support. SDK is always an option but this was quite neat as we did not 
had to build SDK.

Thanks
Amol




The information in this email communication (inclusive of attachments) is 
confidential to 4RF Limited and the intended recipient(s). If you are not the 
intended recipient(s), please note that any use, disclosure, distribution or 
copying of this information or any part thereof is strictly prohibited and that 
the author accepts no liability for the consequences of any action taken on the 
basis of the information provided. If you have received this email in error, 
please notify the sender immediately by return email and then delete all 
instances of this email from your system. 4RF Limited will not accept 
responsibility for any consequences associated with the use of this email 
(including, but not limited to, damages sustained as a result of any viruses 
and/or any action or lack of action taken in reliance on it).
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto