[yocto] MACHINE .conf file
Some questions about MACHINE: 1. I'd customized MACHINE (="intel-corei7-64") variable in conf/local.conf under my build directory, as per document, and had successfully generated an image for my H/W. However, I don't seem to find "intel-corei7-64.conf" file in meta/conf/machine under poky source directory. Is this normal? 2. How many machine files are there per target machine, and should it be in meta/conf/machine under source directory (similar to #1, but just a confirmation for me)? 3. To install an "external" .ko in the root filesystem, my understanding is I need to add its name to MACHINE_XXX_RRECOMMENDS (or one of the other 3) in machine .conf file. If there's only 1 machine file, this is obvious. If not, where should I put it? Raymond -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] pyro: missing ldconfig
On Thu, Apr 5, 2018 at 11:53 PM, Florian Doersch wrote: > > I recently updated from pyro 2.3.3 to latest pyro branch for my raspberry3 > and ran into the following problem > ... > The problem does not occur when using the latest pyro tag (yocto-2.3.3) Unless someone else has a better answer, you might need to bisect between 2.3.3 and the latest pyro version to find out which particular commit caused your issue. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to set SRC_URI in local.conf / how to set any variable of a specific recipe in local.conf
On Sat, Apr 7, 2018 at 8:04 AM, Jakob Hasse wrote: > > how can I set a another branch, i.e., the SRC_URI variable for a specific > recipe in conf/local.conf? Or more general: how can I change the variable of > any recipe in local.conf temporarily? I tried something like this already: > SRC_ = "..." > SRC- = "..." > SRC_pn- = "..." > > I would like to switch a recipe to a testing branch temporarily via > local.conf without playing around in the actual recipes. For your own temporary testing, modifying the actual recipes would be fine. However, if you need to make the change via local.conf, then the procedure would be something like: 1) Capture output of "bitbake -e recipe-name" into a file 2) From the bitbake environment for recipe-name, check what the original value of SRC_URI is. For example, it may be something like: SRC_URI="git://git.project.com/foo file://fixes.patch" 3) Also from the bitbake environment for recipe-name, check which over-rides are active. For example, it maybe something like: OVERRIDES="linux:i586:build-linux:pn-recipe-name:x86:qemuall:qemux86:spooky:class-target:forcevariable:libc-glibc" 4) Pick an over-ride. Since you want to use a global config file to make a recipe specific change, you need to use the recipe specific over-ride, ie "pn-recipe-name". 5) Update the SRC_URI from step 2 as you want and then define it in local.conf using the over-ride you found in step 3. For example: SRC_URI_pn-recipe-name = "git://git.project.com/foo2 file://fixes.patch" -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto Project Status WW15’18
On 04/09/2018 08:13 AM, Jordan, Robin L wrote: > > Current Dev Position: YP 2.5 M4 final close out. > > Next Deadline: YP 2.5 M4 release is 4/27/18 > > > > SWAT Team Rotation: > > SWAT lead is currently: Paul. > > SWAT team rotation: Paul -> Tracy on April 13, 2018 > > SWAT team rotation: Tracy -> Stephano on April 20, 2018 > > https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team > > > > Key Status/Updates: > > * The M3 rc1 QA report has been completed: > > https://wiki.yoctoproject.org/wiki/WW15_-_2018-04-09-_Full_Test_Cycle_-_2.5_M3_rc1 > There are a number of selftest failures and a known SRCREV > related issue with the build-appliance. We will look into these, > but at this point we don’t foresee these blocking M3 and will aim > to start testing release candidates for the final 2.5 release this > week. > * A problem was spotted with fedora28 which has worryingly decided > to merge extra patches ahead of glibc and “break” ABI over the > split of libcrypt out of glibc into libxcrypt. Since we will have > to handle this, we have decided to change nativesdk-glibc for the > 2.5 release but keep on target as is until the situation with > upstream glibc becomes clearer. > * We realised late in the cycle that we needed to change the > LAYERSERIES_COMPAT variable in the core layers. We have also added > warnings to make this variable more obvious and required it for > Yocto Project Compatible v2 status. It seemed best to make these > changes for 2.5 rather than wait until 2.6. > * We are considering a final late change to 2.5 to allow poky to use > the Yocto Project sstate mirrors by default. Feedback welcome on > whether we should do this. It is late in the cycle but would make > a good speedup for users potentially. > I would not make it the default, but have the url info defined in the sample.local.conf Can the Yocto infrastructure handle the world pinging it for sstate? > * > * Armin fixed the SDK locale issues with morty, thanks! We are aware > of a related locale build regression on morty sadly. > I assume a bug was opened? > > * > > > * We were able to upgrade pseudo and have hopefully resolved our > fedora27/coreutils issues. Thanks to all who helped! > * Master-next has a number of recipe upgrades queued. We still want > to discourage people from sending recipe upgrades until we start > 2.6; however, there were simply too many patches to ignore. This > has meant various people and build resources have ended up > distracted from 2.5 work. > > > > Planned upcoming dot releases: > > YP 2.3.4 (Pyro) will be built after 2.5 M3 > Wont it be post Rocko point release? > > YP 2.2.4 (Morty) will be built after 2.5 M3 once the glibc 2.27 issue > is fixed > Wouldn't Morty be post Pyro point release? This will the the point release? > YP 2.4.3 (Rocko) is planned for post YP 2.5. > > > > Key YP 2.5 Dates are: > > YP 2.5 M3 is in QA. See status above. > > YP 2.5 M3 was scheduled for release 3/2/18 > > YP 2.5 M4 cut off of 4/2/18 > > YP 2.5 M4 release of 4/27/18 > > > > Tracking Metrics: > > WDD 2570 (last week 2594) > > (https://wiki.yoctoproject.org/charts/combo.html) > > > > Key Status Links for YP: > > https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.5_Status > > https://wiki.yoctoproject.org/wiki/Yocto_2.5_Schedule > > https://wiki.yoctoproject.org/wiki/Yocto_2.5_Features > > > > The Status reports are now stored on the wiki at: > https://wiki.yoctoproject.org/wiki/Weekly_Status > > > > [If anyone has suggestions for other information you’d like to see on > this weekly status update, let us know!] > > > > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Offline use of opkg
Hello everybody, in my setup opkg is used as the package manager and I use it to install / uninstall several software alternatives. I want this to work on deployed devices in an offline fashion, i.e. I want to do "opkg install " without internet access. might or might not be installed in the actual rootfs in the original image. I could really use some hints how this could be achieved without running into a dead end. My current idea is to deploy the ipks somehow into the rootfs und point opkg to the "local repository": 1. Make some kind of meta-recipe with a dependency of the do_install task on 's do_write_ipk task 2. Find somehow the filenames of all ipks generated by a selection of recipes (the ones creating ) 3. Install them to the rootfs, generate Packages.gz 4. Point opkg to this local repository For steps 1 and 2, I am not sure whether that is possible with a reasonable effort and I would be very thankful for any guidance. Regards Sebastian -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Yocto Project Status WW15’18
Current Dev Position: YP 2.5 M4 final close out. Next Deadline: YP 2.5 M4 release is 4/27/18 SWAT Team Rotation: SWAT lead is currently: Paul. SWAT team rotation: Paul -> Tracy on April 13, 2018 SWAT team rotation: Tracy -> Stephano on April 20, 2018 https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team Key Status/Updates: * The M3 rc1 QA report has been completed: https://wiki.yoctoproject.org/wiki/WW15_-_2018-04-09-_Full_Test_Cycle_-_2.5_M3_rc1 There are a number of selftest failures and a known SRCREV related issue with the build-appliance. We will look into these, but at this point we don’t foresee these blocking M3 and will aim to start testing release candidates for the final 2.5 release this week. * A problem was spotted with fedora28 which has worryingly decided to merge extra patches ahead of glibc and “break” ABI over the split of libcrypt out of glibc into libxcrypt. Since we will have to handle this, we have decided to change nativesdk-glibc for the 2.5 release but keep on target as is until the situation with upstream glibc becomes clearer. * We realised late in the cycle that we needed to change the LAYERSERIES_COMPAT variable in the core layers. We have also added warnings to make this variable more obvious and required it for Yocto Project Compatible v2 status. It seemed best to make these changes for 2.5 rather than wait until 2.6. * We are considering a final late change to 2.5 to allow poky to use the Yocto Project sstate mirrors by default. Feedback welcome on whether we should do this. It is late in the cycle but would make a good speedup for users potentially. * Armin fixed the SDK locale issues with morty, thanks! We are aware of a related locale build regression on morty sadly. * We were able to upgrade pseudo and have hopefully resolved our fedora27/coreutils issues. Thanks to all who helped! * Master-next has a number of recipe upgrades queued. We still want to discourage people from sending recipe upgrades until we start 2.6; however, there were simply too many patches to ignore. This has meant various people and build resources have ended up distracted from 2.5 work. Planned upcoming dot releases: YP 2.3.4 (Pyro) will be built after 2.5 M3 YP 2.2.4 (Morty) will be built after 2.5 M3 once the glibc 2.27 issue is fixed YP 2.4.3 (Rocko) is planned for post YP 2.5. Key YP 2.5 Dates are: YP 2.5 M3 is in QA. See status above. YP 2.5 M3 was scheduled for release 3/2/18 YP 2.5 M4 cut off of 4/2/18 YP 2.5 M4 release of 4/27/18 Tracking Metrics: WDD 2570 (last week 2594) (https://wiki.yoctoproject.org/charts/combo.html) Key Status Links for YP: https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.5_Status https://wiki.yoctoproject.org/wiki/Yocto_2.5_Schedule https://wiki.yoctoproject.org/wiki/Yocto_2.5_Features The Status reports are now stored on the wiki at: https://wiki.yoctoproject.org/wiki/Weekly_Status [If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!] -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-virtualization -> docker not packaged when using PACKAGE_CLASSES ?= "package_deb"
On 04/06/2018 09:13 AM, Mark Junghanns wrote: Hello, I encountered a funny behavior the other day. While trying to integrate Docker into my image using the openembedded meta-virtualization layer, I happened to not being able to get my image finalized. Usually I build with PACKAGE_CLASSES ?= "package_deb". I also added DISTRO_FEATURES_append = " virtualization" The build process aborts at some point within do_rootfs, stating something like that the package 'docker' could not be found. I tracked down the problem to docker's build/tmp/work//docker//deploy-debs/ directory. I found the following packages: docker-contrib_17.06.0+gite639a70fbe999d96354a5bcf560231b7b8aa935c-r0_amd64.deb docker-distribution-dev_v2.6.2-r0_amd64.deb docker-registry_v2.6.2-r0_amd64.deb docker-dbg_17.06.0+gite639a70fbe999d96354a5bcf560231b7b8aa935c-r0_amd64.deb docker-distribution-ptest_v2.6.2-r0_amd64.deb docker-distribution-dbg_v2.6.2-r0_amd64.deb docker-ptest_17.06.0+gite639a70fbe999d96354a5bcf560231b7b8aa935c-r0_amd64.deb The package that is actually missing, is the docker package itself. I suppose it would be named docker_17.06.0+gite639a70fbe999d96354a5bcf560231b7b8aa935c-r0_amd64.deb. There is not any single warning or error thrown whatsoever during the build of docker, it seems to just silently refusing to build the package. Yet, when change PACKAGE_CLASSES ?= "package_deb" to PACKAGE_CLASSES ?= "package_rpm" it would build all required docker RPM-Packages just fine. At the end of the day I way able to get a complete image with Docker integrated, which is fine for the moment. Unfortunately I need to stick with the DEB format for update reasons, so eventually I need to deal with this issue again. Has anyone seen this happening as well? Any idea, where and how to fix this? I've never seen this, but then again, I've also never used the .deb package backend. When you were building with .debs, and your image had "docker' in the image install .. was there any errors thrown due to the package not being created ? Bruce Thanks in advance for your help! Mark -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-java][PATCH 0/3] Java CA certificates updates
Hi, On Fri, Mar 30, 2018 at 09:40:16AM +0100, André Draszik wrote: > openjdk-8 and openjre-8 use a trustStore that has nothing to do with > the system trusted CA certificates as provided by the ca-certificates > package. > > These patches fix both to use the system CA certificates instead. > > The depend on oe-core patch >ca-certificates: use relative symlinks from $ETCCERTSDIR > > http://lists.openembedded.org/pipermail/openembedded-core/2018-March/149359.html > to be merged first. Merged to master-next now. Since "ca-certificates-java" relies on "PREFERRED_RPROVIDER_java2-runtime" set to "OpenJDK-8/OpenJRE-8", we should update the usage instructions in "README" to avoid confusion. Thanks and Regards, Maxin -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [yocot] bluez5 not included in image
Hi, bluetoothd generally get installed here: /usr/libexec/bluetooth/bluetoothd You should probably update the PATH or use absolute path to invoke bluetoothd. Best Regards, Maxin From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Sherif Omran Sent: Monday, April 9, 2018 3:38 PM To: Yocto discussion list Subject: [yocto] [yocot] bluez5 not included in image In local.conf i have DISTRO_FEATURES_append += " bluez5 bluetooth wifi" IMAGE_INSTALL_append += " linux-firmware-bcm43430 bluez5 bridge-utils wpa-supplicant python-smbus i2c-tools " and when i run bluetoothd -v it is not found it seems for some reason bluez5 is not included. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [yocot] bluez5 not included in image
In local.conf i have DISTRO_FEATURES_append += " bluez5 bluetooth wifi" IMAGE_INSTALL_append += " linux-firmware-bcm43430 bluez5 bridge-utils wpa-supplicant python-smbus i2c-tools " and when i run bluetoothd -v it is not found it seems for some reason bluez5 is not included. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] QA cycle report for 2.5 M3 RC1
Hello All, This is the full report for 2.5 M3 RC1: https://wiki.yoctoproject.org/wiki/WW15_-_2018-04-09-_Full_Test_Cycle_-_2.5_M3_rc1 === Summary The QA cycle for release 2.5 M3 RC1 was completed. Team had discovered 7 new bugs. There were 3 bugs related to runtime [4] [6] [7], where core-image-lsb-sdk unable to boot on Minnowboard Turbot, runtime tests failed on OpenSUSE42.3 host machine, & connect host with serial console failed to display login prompt for core-image-sato-sdk-genericx86-64 on Minnowboard Turbot. There were 3 bugs related to selftest [1] [2] and kernel development [5]. This QA cycle were executed with additional manual testing on the images/artifacts created by the new Autobuilder codebase (http://autobuilder.yoctoproject.org/pub/yocto-2.5_M3.rc1/), where the images/artifacts were downloaded and manually tested. There was 1 bug discovered from new Autobuilder codebase where Build Appliance failed [3] to build image. Testcase#202 (syslog) were skipped in multiple BSP automated runtime tests where it cannot run with sysklogd installed. Testcase#1550 (bitbake dependency explorer) was failing and it was still undergoing regression testing. Performance tests shown that build virtual/kernel time for this cycle increased by ~6% compared to 2.5 M2 RC1. This QA cycle had automated package management runtime tests as well as most of the meta-ide-support and SDK toolchain using both existing and new automated tests available. === QA-Hints No significant bugs were discovered. === New Bugs [1] Bug 12647 - [2.5 M3 rc1][OE-Core:Debian9] recipe xcursor-transport-theme went backwards, breaks package feeds [2] Bug 12655 - [2.5 M3 rc1][OE Core:Debian9] layerappend.LayerAppendTests.test_layer_appends - Testcase 1196: ERROR [3] Bug 12637 - [2.5 M3 RC1] Build appliance failed on glibc-initial do_configure when bitbake core-image-minimal [4] Bug 12633 - [2.5 M3 RC1] BSP-QEMU:core-image-lsb-sdk-x86.wic unable to boot on Minnowboard Turbot [5] Bug 12641 - [2.5 M3 RC1] Kernel Development Build external modules (hello-mod) test case: Function failed do_rootfs [6] Bug 12665 - [2.5 M3 rc1] OpenSUSE42.3 runtime test fail at runtime_test.TextExport, runtime_test.TestImage, runtime_test.TestImage and oe_runmake [7] Bug 12666 - [2.5 M3 RC1] BSP-QEMU:core-image-sato-sdk-genericx86-64.hddimg unable to connect to console with serial on Minnowboard Turbot Links = 1. https://bugzilla.yoctoproject.org/show_bug.cgi?id=12647 [1] 2. https://bugzilla.yoctoproject.org/show_bug.cgi?id=12655 [2] 3. https://bugzilla.yoctoproject.org/show_bug.cgi?id=12637 [3] 4. https://bugzilla.yoctoproject.org/show_bug.cgi?id=12633 [4] 5. https://bugzilla.yoctoproject.org/show_bug.cgi?id=12641 [5] 6. https://bugzilla.yoctoproject.org/show_bug.cgi?id=12665 [6] 7. https://bugzilla.yoctoproject.org/show_bug.cgi?id=12666 [7] Regards Ee Peng -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
