Re: [yocto] [Yocto][multilib] No Manifest file generated from: lib32-alsa-lib

Adding PACKAGE_EXTRA_ARCHS = "${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}} armv7ahf-neon-mx8mm" to my machine config solved my problem but I am not sure if it belongs there or not. BR Den ons 5 juni 2019 kl 14:44 skrev Måns Zigher : > > So it looks like I should include armv7a

Re: [yocto] How to set PACKAGE_EXTRA_ARCHS

Adding PACKAGE_EXTRA_ARCHS = "${PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE}} armv7ahf-neon-mx8mm" To my machine config solved my problem but I am not sure if it belongs here or not. BR Den tors 6 juni 2019 kl 10:02 skrev Måns Zigher : > > Hi, > > I am facing an issue

[yocto] How to set PACKAGE_EXTRA_ARCHS

= "${PACKAGE_EXTRA_ARCHS_tune-armv7atb} armv7ab-neon armv7at2b-neon" How can I make sure to get armv7ahf-neon-mx8mm added to the PACKAGE_EXTRA_ARCHS variable and where should it be set local.conf, machine configuration? BR Måns Zigher -- ___ yocto mailing

Re: [yocto] [Yocto][multilib] No Manifest file generated from: lib32-alsa-lib

So it looks like I should include armv7ahf-neon-mx8mm to PACKAGE_EXTRA_ARCHS but I am unsure how to do that any ideas? /Måns Den ons 5 juni 2019 kl 14:05 skrev Måns Zigher : > > Looking in the env dump I can see that meta-freescale is overwriting > the PACKAGE_ARCH in a alsa-lib_%

Re: [yocto] [Yocto][multilib] No Manifest file generated from: lib32-alsa-lib

Looking in the env dump I can see that meta-freescale is overwriting the PACKAGE_ARCH in a alsa-lib_%.bbappend PACKAGE_ARCH_imx = "${MACHINE_SOCARCH}" /Måns Den ons 5 juni 2019 kl 14:04 skrev Måns Zigher : > > So running bitbake -e lib32-alsa-lib I can see the following > >

Re: [yocto] [Yocto][multilib] No Manifest file generated from: lib32-alsa-lib

pand("${SDK_ARCH}_${PACKAGE_ARCH}")) elif bb.data.inherits_class('allarch', d) and d.getVar("PACKAGE_ARCH") == "all": d.setVar('SSTATE_PKGARCH', "allarch") else: d.setVar('SSTATE_MANMACH', d.expand("

Re: [yocto] [Yocto][multilib] No Manifest file generated from: lib32-alsa-lib

neon-lib32-alsa-lib.package_write_rpm manifest-armv7ahf-neon-lib32-alsa-lib.package_write_rpm I am not sure why the mx8mm is added to the lib32-alsa-lib manifest file since this is not added to any other package when building it for lib32. /Måns Den ons 5 juni 2019 kl 13:00 skrev Måns Zigher : &

Re: [yocto] [Yocto][multilib] No Manifest file generated from: lib32-alsa-lib

I think this looks wrong "manifest-x86_64_x86_64-nativesdk-lib32-alsa-lib.package_write_rpm" I have not intentionally added lib32-alsa-lib to the nativesdk part so I am not sure why it expects to find that? /Måns Den ons 5 juni 2019 kl 12:46 skrev Måns Zigher : > > When checki

Re: [yocto] [Yocto][multilib] No Manifest file generated from: lib32-alsa-lib

why is there no rpm for this package? I would have thought that that should be the case? /Måns Den ons 5 juni 2019 kl 11:06 skrev Måns Zigher : > > Hi, > > I am trying to build an SDK where I have multilib enabled in my > local.conf but I am encountering this error message > &g

Re: [yocto] fitImage kernel compression type

Have you looked at https://git.yoctoproject.org/cgit.cgi/poky/plain/meta/classes/kernel-fitimage.bbclass? I cannot see that there is an option for determining the compression. It appears as if it looks specifically for bin-file. I am no expert regarding fitimage format so I cannot say what the best

[yocto] [Yocto][multilib] No Manifest file generated from: lib32-alsa-lib

hould look to understand this issue is appreciated. BR Måns Zigher -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Using the SDK and CMAKE GNUInstallDirs for multilib target

OLCHAIN_FILE=${WORKDIR}/toolchain.cmake \ -DCMAKE_NO_SYSTEM_FROM_IMPORTED=1 \ ${EXTRA_OECMAKE} \ -Wno-dev so it looks all CMAKE_INSTALL paths are actually managed by cmake class. /Måns Den tis 28 maj 2019 kl 18:47 skrev Måns Zigher : > > Hi, > > Not really a Yocto que

[yocto] Using the SDK and CMAKE GNUInstallDirs for multilib target

works as expected and GNUInstallDirs will detect that it is a multilib dir and install it under /usr/lib64. Could anyone point me to how we manage this in poky/OE so I could potentially copy that to our SDK build? BR Måns Zigher -- ___ yocto mailing list

[yocto] How to prevent dnf to check for dependencies during do_rootfs task

ty to supply something usable? BR Måns Zigher -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] dnf fail in do_rootfs cannot find shared library

/to/xmedia/1.0-r43/pkgdata/shlibs2 and I noticed that in xmedia.lst file actually did not include the libx_media_1.0.so but libx_media_1.0_wtf.so. Thanks for your efforts. BR Måns Zigher Den ons 23 jan. 2019 kl 13:01 skrev Måns Zigher : > Hi, > > Yes I noticed it so I tried that out bu

Re: [yocto] dnf fail in do_rootfs cannot find shared library

Hi, Yes I noticed it so I tried that out but without any success but I will investigate that also to see if change it can in another result. BR Måns Zigher Den ons 23 jan. 2019 kl 12:33 skrev Einar Vading : > This is a longshot but I am currently investigating an issue we have >

Re: [yocto] dnf fail in do_rootfs cannot find shared library

Hi, I am sorry but I cannot locate the .spec file. I tried searching for .spec in the tmp/work but I could not find any .spec file. Do I have to build with a flag to get this .spec file? BR Måns Zigher Den ons 23 jan. 2019 kl 12:07 skrev Alexander Kanavin < alex.kana...@gmail.com>: >

Re: [yocto] dnf fail in do_rootfs cannot find shared library

ature because the binaries that I am packaging is actually built using another toolchain but it is for the same arch can dnf detect that? BR Måns Zigher Den tis 22 jan. 2019 kl 17:59 skrev Måns Zigher : > Hi, > > I am struggling with a recipe which more or less just downloads binaries &g

Re: [yocto] dnf fail in do_rootfs cannot find shared library

Hi, I have verified that the so-lib file is part of the rpm package and I am using INSANE_SKIP where I have added dev-so but I am willing to try anything right now so thanks. The so-files is not something I have control of it is something that is delivered to us. BR Måns Zigher Den ons 23 jan

[yocto] dnf fail in do_rootfs cannot find shared library

LF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, stripped I have also verified that the library is part of the produced rpm so that is not the issue. Dose anyone have any suggestion on how to debug this problem? Because I am out of ideas BR Måns Z

Re: [yocto] [SDK] including kernel devsrc to the SDK failes

he rpm build. This is a "bug" only when using rpm ipk will not detect it as a problem. BR Måns Zigher Den tors 25 okt. 2018 kl 13:19 skrev Måns Zigher : > Hi, > > I am trying to add the kernel devsrc to the SDK but I am getting the > following error > > Problem: conflic

[yocto] [SDK] including kernel devsrc to the SDK failes

and resulting dnf from failing when running the task do_populate_sdk. Any suggestion on how to get forward on this error. I would like to run dnf manually to check any dependency of the kernel-devsrc rpm package but cannot figure out how. BR Måns Zigher

[yocto] [qemu] How to use qemu in your testing cycle

would like to be able to supply our application developer a way to start a qemu instance and test out our application without having them using bitbake. I assume this should be possible but not sure exactly how to accomplish this? Any input would be appreciated so I can get started. BR Måns Zigher

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

KIP_${PN} while "dev-so" can be disabled per-package basis." BR Måns Zigher Den ons 17 okt. 2018 kl 06:39 skrev Måns Zigher : > Thank you for the clarification that helps > > BR > Måns Zigher > > Den ons 17 okt. 2018 kl 00:36 skrev Andre McCurdy : > >>

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

Thank you for the clarification that helps BR Måns Zigher Den ons 17 okt. 2018 kl 00:36 skrev Andre McCurdy : > On Tue, Oct 16, 2018 at 6:47 AM, Burton, Ross > wrote: > > It's only already-stripped that needs to be on PN, because the > > stripping happens before p

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

. Anyway thanks for the help I ended up creating a new recipe for the already-stripped so-files. But is all the INSANE_SKIP flags only supported for PN? I think I have seen dev-so used on an package level? BR Måns Zigher Den mån 15 okt. 2018 kl 22:23 skrev Burton, Ross : > Ah yes, of cou

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

. So is it supposed to work because I don't understand the code in the package.bbclass since it looks like it is only checking for already-stripped in ${PN} and not ${PN}-package1? BR Måns Zigher Den fre 12 okt. 2018 kl 16:30 skrev Burton, Ross : > On Thu, 11 Oct 2018 at 18:14, Måns Zigher

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

r "").split(): Is this really the way it should work. I mean dev-so can be set per package in a recipe but is it not supported to set already-stripped per package? I am running rocko but could not set that this have be updated in sumo. The documentation doesn't des

Re: [yocto] [Question]: do_configure fail if cmake project is making use of ExternalProject

Hi, Thanks for your reply. A colleague found OECMAKE_FIND_ROOT_PATH_MODE_PROGRAM = "BOTH" and it seems to work. Do you have any comment using this? Br Måns Zigher On Thu, Sep 6, 2018, 13:52 Alexander Kanavin wrote: > Sadly, Yocto is not well equippped to deal with projects

[yocto] [Question]: do_configure fail if cmake project is making use of ExternalProject

part the sysroot is that git-native is included in ASSUME_PROVIDED which prevent me from getting it into the sysroot and when running do_configure it will only look for it in the sysroot and not on the host if I am not mistaken? What would the best way be to proceed to solve this problem? BR Måns

Re: [yocto] busybox: adding task to run before do_configure

s as the before/after statements will > insert the task in the right place. > > Ross > > On 25 June 2018 at 18:59, Måns Zigher wrote: > > Hi, > > > > I have created this simple class file > > > > python do_busybox_foo() { > > bb.warn("BUSYB

[yocto] busybox: adding task to run before do_configure

OR: Task (/home/user/workdir/layers/poky/meta/recipes-core/busybox/busybox_1.24.1.bb:do_install) failed with exit code '1' I have tried to debug this because I cannot understand why it affects the staging in the install task. By removing the do_busybox_foo[deptask] I prevent this error. An

Re: [yocto] rocko cmake buld cstdlib:75:15: fatal error: stdlib.h: No such file or directory

tbake -e on the recepie to see if I get any clear if the cmake_do_configure is part of it or not. Thanks for your time I appreciate it. Br Mans Zigher On Wed, Apr 18, 2018, 22:47 Dennis Menschel wrote: > Hi Mans, > > Am 18.04.2018 um 06:56 schrieb Måns Zigher: > > Hi Dennis, >

Re: [yocto] rocko cmake buld cstdlib:75:15: fatal error: stdlib.h: No such file or directory

correct? BR Mans Zigher 2018-04-17 20:31 GMT+02:00 Måns Zigher : > Hi, > > I actually managed to locate the problem to the cmake project where it > added include_directories(SYSTEM which then is translated into -isystem > this call was not included when building in the SDK so that expla

Re: [yocto] rocko cmake buld cstdlib:75:15: fatal error: stdlib.h: No such file or directory

will try it out and see what "cmake_do_configure()" can offer. Br Mans Zigher On Tue, Apr 17, 2018, 19:57 Dennis Menschel wrote: > Hi Mans, > > Am 17.04.2018 um 13:15 schrieb Måns Zigher: > > Hi all, > > > > Have anyone experienced this error message before

[yocto] rocko cmake buld cstdlib:75:15: fatal error: stdlib.h: No such file or directory

Hi all, Have anyone experienced this error message before? c++/7.3.0/cstdlib:75:15: fatal error: stdlib.h: No such file or directory > > | #include_next > > > > |^~ > > I am not seeing this error when cross compiling using the sdk. I can see in the output that the -isy

Re: [yocto] Is the a reason for adding the + to SRCPV?

ot; wrote: There is no "dbus codegen". dbus-glib has a code generator but that doesn't write include guards like that, so it must be something else. gdbus-codegen appears to be doing the right thing to unless it breaks if you pass it an absolute path? Ross On 11 April 2018 at 10:12

Re: [yocto] Is the a reason for adding the + to SRCPV?

I believe dbus codegen is the tools generating the code. Br Mans Zigher On Tue, Apr 10, 2018, 14:44 Burton, Ross wrote: > What tool is generating the code? It probably shouldn't be using the > full path of the header... > > Ross > > On 10 April 2018 at 09:29, Mån

[yocto] Is the a reason for adding the + to SRCPV?

Hi, I am having some problems with one of my recipes when using the SRCPV the get_srcrev is returning "AUTOINC+" + rev. This will cause problem in my compile because I am using dbus codegen and it looks like the auto-generated code cannot handle the + sign in the paths. Is there a reason for this

[yocto] [Yocto] What is the preferred way to add build data to os-release

Hi, I see a lot of systems making use of the /etc/os-release where they put in build information like sha, build numbers and version numbers. When doing that you will encounter basehash errors and taskhash errors from bitbake in my experience (or I might be doing something wrong). To remove these

Re: [yocto] [Yocto][meta-raspberrypi] raspberrypi3 model B+ not booting

Hi, I can help out on testing if needed. I will try and do a clean build only using the layers required. BR Mans Zigher 2018-03-28 15:40 GMT+02:00 Paul Barker : > On Wed, Mar 28, 2018 at 1:41 PM, Måns Zigher > wrote: > > Hi, > > > > Thanks I will do that. But I have

Re: [yocto] [Yocto][meta-raspberrypi] raspberrypi3 model B+ not booting

Sherif Omran : > Please use Morty, it works fine. > > On Wed, Mar 28, 2018 at 11:41 AM, Måns Zigher > wrote: > >> Hi, >> >> I am using the meta-raspberrypi layer in my build currently on the rocko >> branch. When powering on the rpi3 Model B+ the power led

[yocto] [Yocto][meta-raspberrypi] raspberrypi3 model B+ not booting

Hi, I am using the meta-raspberrypi layer in my build currently on the rocko branch. When powering on the rpi3 Model B+ the power led turns red then when the green led is turned on the red is turned off and nothing is booting the green continues to flash sporadically. My build works fine on rpi 3

Re: [yocto] how to add pulseaudio

I am no expert but basically the DISTRO_FEATURES is normally used to inform recipes about what kind of feature you would like to have. A recipe based on the DISTRO_FEATURES can then include take action on certain DISTRO_FEATURES. In the yocto ref manual you can read "In most cases, the presence or

[yocto] question on how to include package to the SDK

Hi, I have package that require protobuf and the compiler protoc. I have included the following DEPENDS += " protobuf protobuf-native" and RDEPENDS_${PN} += " protobuf" The build works as intended the problem now is that the protoc is not included in the SDK. In the Yocto ref manual I found th

[yocto] do_compile, the basehash value changed from...

Hi, I am seeing the following error os-release.bb.do_compile, the basehash value changed from b66b4812ebcc321e17478af74dc47349 to 5a21625fe0f3f42b68a1b06498b804a9. The metadata is not deterministic and this needs to be fixed. It appears from nowhere and I need to clean the sstate and tmp to get