Re: [yocto] Doubt regarding python-elementtree rpm
On 11/20/19 9:05 AM, Varun A wrote: Hi Had a doubt. While building python3 rpms using python 3.4.3 bit bake file, I am noticing that python-elementtree rpm is missing. It used to be available in package feeds in python 2.7 case. Has it been merged with another RPM? If so which one. Regards Varun It was merged into python-xml: python: merge python-elementtree into python-xml https://git.openembedded.org/openembedded-core/commit/?id=5f7206eba3953b7f29148ecfb791995773ee5fc7 -- # Randy MacLeod # Wind River Linux -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Review request 0/13: Contribute meta-tensorflow to Yocto
On 11/20/19 11:56 AM, Mauro Ziliani wrote: Is it possible to compile tensorflow against python2.7? I doubt that it's easy/supported but Hongxu, who lives in China, will reply later today to explain. Btw, Krogoth has python3, why not use it? ../Randy Il 20/11/19 16:40, Mauro Ziliani ha scritto: I forked the repository and I'm tryng to port the layer for Krogoth M Il 20/11/19 15:37, Mauro Ziliani ha scritto: Hi all. There a port for meta-tensorflow for Krogoth or Sumo? Mayabe I need to use it on this distribution Thaks M Il 21/02/19 12:37, Hongxu Jia ha scritto: Hi RP and Yocto folks, Currently AI on IoT edge becomes more and more popular, but there is no machine learning framework in Yocto/OE. With the support of Eric , Robert and Randy, after two months effort, I've integrated TensorFlow to Yocto. Now, I contribute the patches to Yocto for review, and apply for creating a layer named `meta-tensorflow' on Yocto. For test convenient, there is a fork on github: https://github.com/hongxu-jia/meta-tensorflow BTW, I have contributed other 11 fundamental recipes to meta-openembedded and all of them have been merged to master branch. Please no hesitate to share your suggestion. //Hongxu Testing Commands: - See README Testing, Expected Results: -- See README -- # Randy MacLeod # Wind River Linux -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Install native recipe into filesystem
On 11/19/19 4:15 PM, Jeff Kaisner wrote: We have several executables that can run on the target (ARM64) but also on the host system (x86). I added the BBCLASSEXTEND = "native" and can build all the recipes in native mode. What do you mean here by 'in native mode'? I'd expect that you mean: $ bitbake somepackage-native Right? A few explanations related to your question are here: https://wiki.yoctoproject.org/wiki/Technical_FAQ#What_does_.22native.22_mean.3F and here: https://wiki.yoctoproject.org/wiki/Technical_FAQ#Why_are_all_of_these_-native_items_being_built_when_my_host_distro_has_some_of_these_available.3F > Once done, I would like to be > able to install them on the host system, but don’t see a package for > them (or understand that part of the process). You don't add -native package to the target system; they are for the build (host) system to help build object files for the target machine. You can either edit the conf/local.conf file then build a standard image or define your own image. For the former: https://wiki.yoctoproject.org/wiki/Cookbook:Example:Adding_packages_to_your_OS_image Additional details are in the YP Mega Manual: https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html Good luck and welcome to the Yocto Project, ../Randy Any help would be appreciated. Regards, Jeff -- # Randy MacLeod # Wind River Linux -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Error Building Valgrind_3.15 for yocto
On 11/11/19 9:33 PM, Sheraz Ali wrote: Hi Sir, I want to add valgrind to my yocto i am using valgrind version (3.15.0-r0 ) i have attached the valgrind source and error log for your reference. This is the Build Configuration for which i am trying to build valgrind Build Configuration: BB_VERSION = "1.22.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "Ubuntu-14.04" TARGET_SYS = "arm-poky-linux-gnueabi" MACHINE = "iwg22m" DISTRO = "poky" DISTRO_VERSION = "1.6.1" That's a very old release and is not supported officially by Yocto or even by the community: https://wiki.yoctoproject.org/wiki/Releases Do you have a vendor who supports this collection of layers? If not, there are many companies who are likley able to do so. TUNE_FEATURES = "armv7a vfp neon callconvention-hard cortexa7" TARGET_FPU = "vfp-neon" meta meta-yocto meta-yocto-bsp = "tmp:c4f1f0f491f988901bfd6965f7d10f60cb94a76f" meta-renesas meta-rzg1 = "tmp:19bf1ed97d04009722bb88a780268822ee60ff83" meta-oe meta-multimedia = "tmp:dca466c074c9a35bc0133e7e0d65cca0731e2acf" meta-linaro-toolchain = "tmp:8a0601723c06fdb75e62aa0f0cf15fc9d7d90167" meta-networking = "tmp:dca466c074c9a35bc0133e7e0d65cca0731e2acf" I am getting the following error can you suggest me what to do /*arm-poky-linux-gnueabi-gcc: error: unrecognized argument in option '-march=armv7ve'*/ /*arm-poky-linux-gnueabi-gcc: note: valid arguments to '-march=' are: armv2 armv2a armv3 armv3m armv4 armv4t armv5 armv5e armv5t armv5te armv6 armv6-m armv6j armv6k armv6s-m armv6t2 armv6z armv6zk armv7 armv7-a armv7-m armv7-r armv7e-m armv8-a armv8-a+crc iwmmxt iwmmxt2 native*/ It looks like your BSP layer/vendor (meta-rzg1 perhaps), or perhaps the toolchain supplier hasn't added support for this arch. I can understand that you might not be able to upgrade to a supported Yocto release but if not, it's unlikely that anyone can help. If you can reproduce the problem on a supported branch with just poky or with just fewer layers, then you could open a defect against valgrind or the toolchain: https://bugzilla.yoctoproject.org/ Sorry that I can't be of more assistance., ../Randy make[5]: *** [intdiv-intdiv.o] Error 1 make[5]: Leaving directory `/home/sarjoodeen/Project/2018/Nippon/YOCTO/iwG22M-release-bsp/build/tmp/work/cortexa7hf-vfp-neon-poky-linux-gnueabi/valgrind/3.15.0-r0/build/none/tests/arm' make[4]: *** [check-am] Error 2 make[4]: Leaving directory `/home/sarjoodeen/Project/2018/Nippon/YOCTO/iwG22M-release-bsp/build/tmp/work/cortexa7hf-vfp-neon-poky-linux-gnueabi/valgrind/3.15.0-r0/build/none/tests/arm' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/home/sarjoodeen/Project/2018/Nippon/YOCTO/iwG22M-release-bsp/build/tmp/work/cortexa7hf-vfp-neon-poky-linux-gnueabi/valgrind/3.15.0-r0/build/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/home/sarjoodeen/Project/2018/Nippon/YOCTO/iwG22M-release-bsp/build/tmp/work/cortexa7hf-vfp-neon-poky-linux-gnueabi/valgrind/3.15.0-r0/build/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/home/sarjoodeen/Project/2018/Nippon/YOCTO/iwG22M-release-bsp/build/tmp/work/cortexa7hf-vfp-neon-poky-linux-gnueabi/valgrind/3.15.0-r0/build' make: *** [check] Error 2 make: Leaving directory `/home/sarjoodeen/Project/2018/Nippon/YOCTO/iwG22M-release-bsp/build/tmp/work/cortexa7hf-vfp-neon-poky-linux-gnueabi/valgrind/3.15.0-r0/build' ERROR: oe_runmake failed WARNING: exit code 1 from a shell command. ERROR: Function failed: do_compile_ptest_base (log file is located at /home/sarjoodeen/Project/2018/Nippon/YOCTO/iwG22M-release-bsp/build/tmp/work/cortexa7hf-vfp-neon-poky-linux-gnueabi/valgrind/3.15.0-r0/temp/log.do_compile_ptest_base.29480) Thanks and Regards Sheraz Ali Shah -- Thanks and Regards Sheraz Ali Shah -- # Randy MacLeod # Wind River Linux -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] NooB: applying new patches to older files, where do I find the older files?
On 10/31/19 6:36 AM, R wrote: On 31-10-2019 01:52, Randy MacLeod wrote: On 10/30/19 8:16 AM, R wrote: Hello List, First I'm working on a unsupported distro (Manjaro) and try to get an older version (2.7.1) of poky working. I have ask a question before and Ross Burton pointed me in the direction of a patch. Now I'm trying to apply that patch, however the patch is for a newer version of the original files, so I need to make my own patch for the older version of these files. (reason: WARNING: Some of the context lines in patches were ignored. This can lead to incorrectly applied patches.) The patch says: the file to be patch is e.g. /linux-user/syscall.c My question is where can I find the original syscall.c before any patches are applied to it? Hi Robert, This file and the patch are for the qemu package. You can run: $ bitbake -c patch qemu-native <--- host build or $ bitbake -c patch qemu <--- target build to get all the patches that are listed in the qemu recipe in poky: meta/recipes-devtools/qemu/qemu_3.1.1.1.bb and meta/recipes-devtools/qemu/qemu.inc applied to unpacked source. The patched source will be in (this is on master branch): /tmp-glibc/work/x86_64-linux/qemu-native/4.1.0-r0/qemu-4.1.0/linux-user/syscall.c poky might just be /tmp/ instead of /tmp-glibc/ In my case the log of the patching is in: tmp-glibc/work/x86_64-linux/qemu-native/4.1.0-r0/temp/log.do_patch Just to be complete: I have tried the latest warrior branch and that worked fine. My objective is not just to get it working be also to get a grip on how the system works :-) Super. Have you looked at: https://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html and perhaps: https://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#finding-the-temporary-source-code will be useful now. Manipulating patches by hand can be tedious. There's a tool called wiggle: https://linux.die.net/man/1/wiggle which can help but may be too much for you to deal with initially. Actually, I suggest that you build on a supported distro initially to understand the basic workflow and then decide if you want to figure out how to make Arch/Manjaro work. ../Randy Thanks, Robert. Thanks Randy, Very helpful, especially the trigger to look into the development manual. I know starting with a supported distro would be the smarter choice. But then it would just work and I would probably make tiny steps in changes, this way I'm pulled right into the belly of the "beast" and I will learn much faster how it works :-) Disadvantage is that I maybe overwhelmed, so I will ask a question like this one, occasionally. Robert Makes sense I suppose, good luck, questioned welcomed. There are also people on freenode IRC #oe if you are interested. A few Yocto devs have used ArchLinux so you're not breaking completely new ground, FYI. ../Randy -- # Randy MacLeod # Wind River Linux -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] NooB: applying new patches to older files, where do I find the older files?
On 10/30/19 8:16 AM, R wrote: Hello List, First I'm working on a unsupported distro (Manjaro) and try to get an older version (2.7.1) of poky working. I have ask a question before and Ross Burton pointed me in the direction of a patch. Now I'm trying to apply that patch, however the patch is for a newer version of the original files, so I need to make my own patch for the older version of these files. (reason: WARNING: Some of the context lines in patches were ignored. This can lead to incorrectly applied patches.) The patch says: the file to be patch is e.g. /linux-user/syscall.c My question is where can I find the original syscall.c before any patches are applied to it? Hi Robert, This file and the patch are for the qemu package. You can run: $ bitbake -c patch qemu-native <--- host build or $ bitbake -c patch qemu <--- target build to get all the patches that are listed in the qemu recipe in poky: meta/recipes-devtools/qemu/qemu_3.1.1.1.bb and meta/recipes-devtools/qemu/qemu.inc applied to unpacked source. The patched source will be in (this is on master branch): /tmp-glibc/work/x86_64-linux/qemu-native/4.1.0-r0/qemu-4.1.0/linux-user/syscall.c poky might just be /tmp/ instead of /tmp-glibc/ In my case the log of the patching is in: tmp-glibc/work/x86_64-linux/qemu-native/4.1.0-r0/temp/log.do_patch Just to be complete: I have tried the latest warrior branch and that worked fine. My objective is not just to get it working be also to get a grip on how the system works :-) Super. Have you looked at: https://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html and perhaps: https://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#finding-the-temporary-source-code will be useful now. Manipulating patches by hand can be tedious. There's a tool called wiggle: https://linux.die.net/man/1/wiggle which can help but may be too much for you to deal with initially. Actually, I suggest that you build on a supported distro initially to understand the basic workflow and then decide if you want to figure out how to make Arch/Manjaro work. ../Randy Thanks, Robert. -- # Randy MacLeod # Wind River Linux -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] TFS Urls with Git in Recipes
Hello Christian,
Thanks for reporting the problem. Comments and questions below.
On 10/23/19 3:36 AM, Lohr, Christian [ext] wrote:
Hello,
I‘m using the following:
Yocto Release 2.4 (Rocko), and Bitbake 1.9.x
Can you check if the problem is still present on the master branch?
My problem is the following url (actually the “%20” is the problem in
bitbake):
ssh://tfs-my-company.org:22/tfs/OWN_Projects/FooBar%20500/_git/DummyApplicationForYocto
I can do a “git clone ” without any problems. Now I wanted to
create a Yocto recipe similar to this:
--
SUMMARY = "A demo application"
DESCRIPTION = "This application is just for demo purpose and should be
seen as Hello World"
LICENSE = "CLOSED"
#LIC_FILES_CHKSUM = ""
PROJECT_URL = "tfs-my-company.org:22/tfs/OWN_Projects"
PROJECT_NAME = "FooBar%20500"
It's possible that:
PROJECT_NAME = "FooBar 500"
or
PROJECT_NAME = "FooBar\ 500"
would work. Have you tried that already? I haven't worked on the
bitbake fetcher code so I may be making naive suggestions.
Also, I expect that you are working around the issue by just
removing the space in the path, right?
SRC_URI =
"git://${PROJECT_URL}/${PROJECT_NAME}/_git/DummyApplicationForYocto;protocol=ssh"
SRCREV = "${AUTOREV}"
PV = "1.0+git${SRCPV}"
DEPENDS = "qtbase"
The „%20“ sign will be replaced with a space “ “ in some cases:
When I try to run “bitbake dummyapp”, the following happens:
“FooBar%20500” will be transformed to “FooBar 500”
git -c core.fsyncobjectfiles=0 ls-remote
ssh://tfs-my-company.org:22/tfs/OWN_Projects/FooBar
500/_git/DummyApplicationForYocto failed with exit code 128, output:
remote: Command git-upload-pack '/tfs/OWN_Projects/FooBar' is not in
expected format.
fatal: Could not read from remote repository.
Is it possible to prevent this because if it would leave the “%20” the
command would work.
The YP does have problems dealing with spaces in path names as you
have seen. I think this prevents the MacOS port for example.
Could you open a defect in the Yocto bugzilla?
https://bugzilla.yoctoproject.org/
https://wiki.yoctoproject.org/wiki/Bug_reporting_and_Information_levels
Ideally, it would be great if you could submit a patch but I understand
that you may not have the time, interest or the expertise to do so.
If you are not able to do that then the defect will be triaged during
the weekly review (next week's meeting is actually cancelled do to the
Embedded Linux Conference - Europe) and someone will work on the defect
based on it's importance and their interest and workload.
If you want a fix sooner than that, there are companies and consultants
listed on the yocto project homepage:
https://www.yoctoproject.org/ecosystem/members/
https://www.yoctoproject.org/community/consultants/
Thanks again for the report and
I'm sorry that I'm not able to be of more help immediately.
../Randy
Kind regards,
Christian Lohr
--
# Randy MacLeod
# Wind River Linux
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] newcomers
On 10/3/19 12:38 PM, Maciej Pijanowski wrote: On 03.10.2019 18:33, Steve Scott wrote: How would a newcomer get started? Welcome to the Yocto Project Steve! Ideally, everything should be linked from: https://www.yoctoproject.org/ and there is, in fact a 'Get started here' link there: https://www.yoctoproject.org/software-overview/ which ends with a numbered list of documents for new devs/users in the "New to the Yocto Project" section. Is there an FAQ or Wiki that gives a developer overview of the project, The first link used to be called 'Getting Started' but now it's called quick build: https://www.yoctoproject.org/docs/2.7.1/brief-yoctoprojectqs/brief-yoctoprojectqs.html Oh and the Wikipedia page links to Yoctoproject.org too so that's good. Do you think we need to simplify the landing page? patch submission process, etc.? This one is pretty accurate when it comes to patch submission process: https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded It’s hard to jump on to the moving train… Yes, there's lots to learn. When I start new developers, I get them to clone poky and build core-image-minimal which is prety much what: https://www.yoctoproject.org/docs/current/brief-yoctoprojectqs/brief-yoctoprojectqs.html does except it uses core-image-sato. The docs are quite verbose and some people prefer to learn by doing. Do you think the, "Yocto Project Quick Build" is suitable for that path? ../Randy *From:*yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] *On Behalf Of *Stephen K Jolley *Sent:* Monday, September 30, 2019 8:50 AM *To:* openembedded-c...@lists.openembedded.org; yocto@yoctoproject.org *Subject:* [yocto] (no subject) All, The triage team is starting to try and collect up and classify bugs which a newcomer to the project would be able to work on in a way which means people can find them. They're being listed on the triage page under the appropriate heading: https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs The idea is these bugs should be straight forward for a person to help work on who doesn't have deep experience with the project. If anyone can help, please take ownership of the bug and send patches! If anyone needs help/advice there are people on irc who can likely do so, or some of the more experienced contributors will likely be happy to help too. Also, the triage team meets weekly and does its best to handle the bugs reported into the Bugzilla. The number of people attending that meeting has fallen, as have the number of people available to help fix bugs. One of the things we hear users report is they don't know how to help. We (the triage team) are therefore going to start reporting out the currently 309 unassigned or newcomer bugs. We're hoping people may be able to spare some time now and again to help out with these. Bugs are split into two types, "true bugs" where things don't work as they should and "enhancements" which are features we'd want to add to the system. There are also roughly four different "priority" classes right now, “2.8”, “2.9’, "2.99" and "Future", the more pressing/urgent issues being in "2.8" and then “2.9”. Please review this link and if a bug is something you would be able to help with either take ownership of the bug, or send me (sjolley.yp...@gmail.com <mailto:sjolley.yp...@gmail.com>) an e-mail with the bug number you would like and I will assign it to you (please make sure you have a Bugzilla account). The list is at: https://wiki.yoctoproject.org/wiki/Bug_Triage#Unassigned_or_Newcomer_Bugs -- Thanks, */Stephen K. Jolley/* *Yocto Project Program Manager* *7867 SW Bayberry Dr., Beaverton, OR 97007* (*Cell*: (208) 244-4460 * *Email*:_s <mailto:stephen.k.jol...@intel.com>jolley.yp...@gmail.com <mailto:jolley.yp...@gmail.com>_ -- Maciej Pijanowski Embedded Systems Engineer https://3mdeb.com | @3mdeb_com -- # Randy MacLeod # Wind River Linux -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Awkward line wrapping in bash
On 10/3/19 6:54 AM, phodina wrote: Hi, so I managed to minimize the build image and run it in QEMU. Now I build only poky, open-embedded and our own layer, containing minimal recipes. The problem with the awkward line wrapping is still present. Sometimes it doesn't come up until I change the size of terminal window. Is that on the master branch? More interesting is that if I run `busybox sh` the issue is not present and the line wraps correctly. The issue happens with ssh as well as serial. Interesting. I tried to install the `xterm` pkg which has `resize` binary for changing the terminal window size, but without any luck. Why not? I know that the meta-overc devs added xterm to get resize: https://github.com/OverC/meta-overc/commit/729f50aef024db293986ff320713ddf46bcb300b Kind regards Petr Thanks for simplifying and testing again. If you want to continue to debug that would be great but you can also open a YP bugzilla defect. Include as much info as you can and perhaps a screenshot/image. ../Randy Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Thursday, September 19, 2019 8:45 PM, Randy MacLeod wrote: On 9/19/19 11:43 AM, phodina wrote: Hi, based on André recommendation I commented out the PS1 variable and now I get `-sh-4.4#` for the prompt. I also checked and nothing is overwriting the variable. But I tried to change the size of the shell by using `stty cols 100 rows 40` as well as different sizes (smaller and bigger than 80 columns), but the amount of characters I get on the line stays at 81 followed by carrige return. However if I record the session with `script` I get the correct amount of characters per line. If you are able to reproduce this problem on the master, or a stable (1) branch with one of the supported qemu or HW BSPs (2), please open a defect in: https://bugzilla.yoctoproject.org/ Please report the branch, what layers you are using (hopefully you can reproduce it with just oe-core/poky + a HW layer) and with a standard image. ../Randy (1) https://wiki.yoctoproject.org/wiki/Releases (2): The list here is a good start, I'm not sure about the FSL support and I suspect that minnow board is no longer relevant. https://bugzilla.yoctoproject.org/describecomponents.cgi?product=BSPs If your hardware isn't listed, and you can't reproduce the issue in qemu or supported HW, you should contact your HW supplier. -- Randy MacLeod == Wind River Linux = -- # Randy MacLeod # Wind River Linux -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] FYI: [RFC][PATCH 0/3] Move Rust support from meta-rust to oe-core
I'd like to make people aware of a discussion on the oe-core email list about adding Rust support to the oe-core layer. If you are interested in helping to define requirements and better still to work on adapting the meta-rust code so that it's suitable for inclusion in oe-core, reply of this thread: http://lists.openembedded.org/pipermail/openembedded-core/2019-September/287185.html If you don't subscribe to oe-core, we can discuss issues on this list since most people who subscribe to oe-core also subscribe to this list. -- # Randy MacLeod # Wind River Linux -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] Xilinx/meta-jupyter layer
On 9/27/19 4:12 PM, Chandana Kalluri wrote: Hello all, https://github.com/Xilinx/meta-jupyter is a meta-jupyter layer containing recipes for jupyter notebook. The initial recipes are based of Dmitry Kargin's meta-jupyter layer https://layers.openembedded.org/layerindex/branch/master/layer/meta-jupyter/. This layer has not been updated for a while. The Xilinx/meta-jupyter layer also adds recipes for python3 based notebooks apart from existing python2 based notebooks. This layer has been tested using Yocto thud layer and by running jupyter notebooks on Ultra96 community boards. We would like to maintain Xilinx/meta-jupyter layer actively and welcome contributions to this layer either through pull requests or via patches sent to meta-xilinx mailing list until a mailing list for meta-jupyter is in place. In the next cycle we will deprecate python2 recipes. A question to community, - Would you recommend maintaining this layer separately in the current github.com/Xilinx location or be included under meta- openembedded layers. I suppose a seperate layer since jupyter isn't typically used but I don't have a strong opinion either way. - Would you suggest having a separate mailing list ? Using the Yocto email list would be my preference. That way, I'd keep on eye on Jupyter from time to time whereas if it's a separate list, I likely would not subscribe. I'm assuming that there will be less than few 100 emails per year. ../Randy Thanks, Chandana -- # Randy MacLeod # Wind River Linux -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Awkward line wrapping in bash
On 9/19/19 11:43 AM, phodina wrote: Hi, based on André recommendation I commented out the PS1 variable and now I get `-sh-4.4#` for the prompt. I also checked and nothing is overwriting the variable. But I tried to change the size of the shell by using `stty cols 100 rows 40` as well as different sizes (smaller and bigger than 80 columns), but the amount of characters I get on the line stays at 81 followed by carrige return. However if I record the session with `script` I get the correct amount of characters per line. If you are able to reproduce this proble on the master, or a stable (1) branch with one of the supported qemu or HW BSPs (2), please open a defect in: https://bugzilla.yoctoproject.org/ Please report the branch, what layers you are using (hopefully you can reproduce it with just oe-core/poky + a HW layer) and with a standard image. ../Randy (1) https://wiki.yoctoproject.org/wiki/Releases (2): The list here is a good start, I'm not sure about the FSL support and I suspect that minnow board is no longer relevant. https://bugzilla.yoctoproject.org/describecomponents.cgi?product=BSPs If your hardware isn't listed, and you can't reproduce the issue in qemu or supported HW, you should contact your HW supplier. -- # Randy MacLeod # Wind River Linux -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] gitlab-runner
On 9/19/19 2:56 AM, Robert ber...@yocto.user wrote: Hi, Does someone happen to have a BitBake recipe for gitlab-runner?[1] [1] https://gitlab.com/gitlab-org/gitlab-runner A quick search did not show up anything;) There's nothing in the layer index: https://layers.openembedded.org/layerindex/branch/master/recipes/?q=runner (It wasn't clear if you knew about the index.) I did find: https://gitlab.cern.ch/Caribou/meta-caribou/tree/master/misc/gitlab-ci that mentions gitlab-runner but it doesn't seem like that layer provides a recipe but you might want to check it out anyway and let us know if it works for you. Also I CCed Simon who is the most recent active committer to meta-caribou. Simon, Do you want to add this layer to the index? See: https://layers.openembedded.org/layerindex/branch/master/layers/ and click the "Submit layer" button. ,./Randy Regards, Robert -- # Randy MacLeod # Wind River Linux -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] warrior with recipes AUTOREV, issues (and hangs bitbake on Centos )
On 9/18/19 3:46 AM, lluis.cam...@northern.tech wrote: Hello, While updating our layers and build system for warrior, we are facing the exact same issue reported by Richard C Allen back in June [1]. In our case, we are using Ubuntu 16.04 for as build host. Since then, a new release of yocto was tagged, 2.7.1, but the issue seems to be still present. Any update on it? Is there more people affected by it? Hi Lluís, I don't see an open issue in the bugzilla but it's possible the problem has been fixed. Can you try to reproduce it on master? If it's broken on master and you have a reproducer then open a defect: https://bugzilla.yoctoproject.org/ there's a much higher chance of getting a fix. Bugs are reviewed every Thursday. If it's working on master but not warrior/2.7.1 then take a look through the commit logs for oe-core and bitbake. If you can automate the detection (and clean-up), then you could use poky and git bisect to find the fix. Thanks, ../Randy Thanks! [1] https://lists.yoctoproject.org/pipermail/yocto/2019-June/045738.html Lluís Campos Northern.Tech -- # Randy MacLeod # Wind River Linux -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] wic create - bad ownership of directories inside image
On 8/22/19 11:23 AM, Behnke, Jochen wrote: Hello Randy, thanks for your reponse and sorry for my late reaction. In order to test, if the problem can be reproduced reliably, I performed a clean rebuild as follows $ source oe-init-build-env build-tca5-32 $ rm -rf tmp $ rm -rf sstate-cache $ bitbake core-image-minimal $ wic create mkefidisk -e core-image-minmal I then mounted the resulting image file "mkefidisk-201908221701-sda.direct" using a loopback device (losetup) Inside the Image all directories have UID/GID 1000/1000, which corresponds to my host user. Files however have UID/GID 0/0. Hi Jochen, I'm not able to reproduce the error, see below (1). What version of oe-core/bitbake are you using? I'm using the latest master branches: oe-core: 64f9fd2a1e quilt: added less to RDEPENDS list bitbake: 28b3f0d8 runqueue: Optimise build_taskdepdata slightly So the answer to your question is "yes I can reproduce the behavior". One sidenote - I am using an appended core-image-minimal not the default What is the bbappend? Is it publicly clonable? What happens if you drop that addition? ../Randy (1) I followed your steps above and mounted my image as follows: $ fdisk -l mkefidisk-201908230902-sda.direct Disk mkefidisk-201908230902-sda.direct: 94.4 MiB, 98956288 bytes, 193274 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 1E5F9B4E-ED8A-4677-82CD-7B146807C145 Device Start End Sectors Size Type mkefidisk-201908230902-sda.direct1 2048 51433 49386 24.1M Microsoft basic data mkefidisk-201908230902-sda.direct2 53248 103127 49880 24.4M Linux filesystem mkefidisk-201908230902-sda.direct3 103128 193239 90112 44M Linux swap # 53248*512 = 27262976 $ sudo mount -o loop,offset=27262976 ./mkefidisk-201908230902-sda.direct /mnt/loop $ ls -l /mnt/loop/bin/busybox.nosuid -rwxr-xr-x 1 root root 625296 Aug 23 11:45 /mnt/loop/bin/busybox.nosuid $ ls -l /mnt/loop/usr | head -3 total 10 drwxr-xr-x 2 root root 3072 Aug 23 11:52 bin drwxr-xr-x 2 root root 1024 Aug 23 11:29 games ../Randy - In my other image I am using qt5 (v5.12) Regards Jochen On 8/12/19 5:11 AM, Behnke, Jochen wrote: > Hello, > > I am using poky 2.6.1 (thud) and create images using the wic utility. > > Recently I noticed that all directories contained in the created image > are owned by UID 1000 and not by root. The files inside the image > however are owned by root. > > The UID 1000 refers to my unprivileged user on the host system. > > Here is the command I use to create the image > > “wic create mkefidisk –e core-image-minimal” > > The images created by bitbake directly (.tar.bz2, .hddimg) are correct > so this seems to be a wic related problem. > > Does anybody have a solution for this? Hi Jochen, No and I've never seen this particular extreme symptom. There is a known, generally rare bug: Bug 12434 - pseudo: Incorrect UID/GID in packaged files https://bugzilla.yoctoproject.org/show_bug.cgi?id=12434 but that usually shows up when building. You could check you build logs for the generic stings from: glibc-locale-2.26: glibc-locale: /glibc-binary-localedata-en-gb/usr/lib/locale/en_GB/LC_MEASUREMENT is owned by uid 3004, which is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated] Is your issue 100% reproducible? ../Randy > > Many thanks in advance, any hint is appreciated. > > Regards > > Jochen > > > > > __ > *SCHMIDT Technology GmbH* > Feldbergstrasse 1 > 78112 St. Georgen/Germany > Telefon +49 (0) 77 24 / 89 90 > Fax +49 (0) 77 24 / 89 91 01 > i...@schmidttechnology.de <mailto:i...@schmidttechnology.de> > http://www.schmidttechnology.de > > USt-Id Nr. DE 811725105 · Registergericht Freiburg HRB 600 755 > Geschaeftsfuehrung: Oliver Schmidt, Stephan Schmidt > > > > > -- # Randy MacLeod # Wind River Linux -- # Randy MacLeod # Wind River Linux -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Segmentation fault | bitbake machine-image.bb | core dumped
sr/share/apport/apport %p %s %c %d %P" > /proc/sys/kernel/core_pattern # rm /root/old-core-pattern # exit Other useful info: Core file generation: https://stackoverflow.com/questions/2065912/core-dumped-but-core-file-is-not-in-the-current-directory I hope that helps. If you can reproduce the issue on a supported YP branch , then you should open a defect in: https://bugzilla.yoctoproject.org/ with the exact steps you use to assemble you layers, and build a project. If the bug is not in oe-core or bitbake, then you should consult the toplevel README for whatever layer is involved and follow-up in that way. If you'd like additional support for the older release, consultants are available to hire: https://www.yoctoproject.org/community/consultants/ and certain YP members (such as Wind River) provide YP-based Linux distros that are supported for years and years. See: https://www.yoctoproject.org/ecosystem/members/ ../Randy On 16-08-2019 07:11 PM, Randy MacLeod wrote: On 8/16/19 12:40 AM, jaymin.da...@vivaldi.net wrote: Hi Randy, Thanks for your information regarding Yocto Jethro branch. Yes, this core dumped issue is reproducible. When I add python3-pip package in local.conf file and build complete image, this core dumped is happening. Randy, it would be much helpful if you explain me how to adjust core file limits using ulimit, and how get the backtrace? Via google: https://jvns.ca/blog/2018/04/28/debugging-a-segfault-on-linux/ ../Randy I have added python3-pip package in local.conf file, this is the one change only I did in local.conf. Yes, I am able to generate the image successfully after reverting this one change. Please let me know if more information require. On 15-08-2019 07:30 AM, Randy MacLeod wrote: On 8/12/19 10:42 AM, jaymin.da...@vivaldi.net wrote: Hello All, Facing segmentation fault (core dumped) while doing bitbake. I am using Yocto Jethro branch. Jethro isn't officially supported by the Yocto Project. The support cycle is ~ 1 year. https://wiki.yoctoproject.org/wiki/Releases Can you reproduce the issue on master or a newer supported branch? If so you could file a bug in: https://wiki.yoctoproject.org/wiki/Releases Also, see below for some tips. When I added python3-pip recipe (in local.conf) and started building image, segmentation fault occurred. Although, I am able to bitbake python3-pip individually (i.e. bitbake python3-pip). As per log my assumption is, core dumped is occurring at make_ext4fs execution. Following are the error logs: ERROR: Function failed: do_makesystem (log file is located at poky/build/tmp-glibc/work/apq8053-oe-linux/machine-image/1.0-r0/temp/log.do_makesystem.15059) ERROR: Logfile of failure stored in: poky/build/tmp-glibc/work/apq8053-oe-linux/machine-image/1.0-r0/temp/log.do_makesystem.15059 Log data follows: | DEBUG: Executing shell function do_makesystem | poky/build/tmp-glibc/work/apq8053-oe-linux/machine-image/1.0-r0/temp/run.do_makesystem.15059: line 105: 15073 Segmentation fault (core dumped) make_ext4fs -J -b 1024 -s -a / -S Odd, I've never see that happen before. Is it reproducible? Can you adjust the core file limits using 'ulimit', generate a core file and get a backtrace? poky/build/tmp-glibc/work/apq8053-oe-linux/machine-image/1.0-r0/rootfs/etc/selinux/mls/contexts/files/file_contexts -l 76800 poky/build/tmp-glibc/deploy/images/apq8053-perf/apq8053-sysfs.ext4 poky/build/tmp-glibc/work/apq8053-oe-linux/machine-image/1.0-r0/rootfs | WARNING: poky/build/tmp-glibc/work/apq8053-oe-linux/machine-image/1.0-r0/temp/run.do_makesystem.15059:1 exit 139 from | make_ext4fs -J -b 1024 -s -a / -S poky/build/tmp-glibc/work/apq8053-oe-linux/machine-image/1.0-r0/rootfs/etc/selinux/mls/contexts/files/file_contexts -l 76800 poky/build/tmp-glibc/deploy/images/apq8053-perf/apq8053-sysfs.ext4 poky/build/tmp-glibc/work/apq8053-oe-linux/machine-image/1.0-r0/rootfs | ERROR: Function failed: do_makesystem (log file is located at poky/build/tmp-glibc/work/apq8053-oe-linux/machine-image/1.0-r0/temp/log.do_makesystem.15059) ERROR: Task 11 ( poky/meta-qti-bsp/recipes-products/images/machine-image.bb, do_makesystem) failed with exit code '1' Whether python3-pip recipe is creating an issue or something else? (attached the python3-pip recipe file) What did you change in your conf/local.conf file? If you revert that change, then you are able to generate the image again? ../Randy Please let me know. Any suggestions are welcome. Regards, Jaymin -- # Randy MacLeod # Wind River Linux -- # Randy MacLeod # Wind River Linux -- # Randy MacLeod # Wind River Linux -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Segmentation fault | bitbake machine-image.bb | core dumped
On 8/16/19 12:40 AM, jaymin.da...@vivaldi.net wrote: Hi Randy, Thanks for your information regarding Yocto Jethro branch. Yes, this core dumped issue is reproducible. When I add python3-pip package in local.conf file and build complete image, this core dumped is happening. Randy, it would be much helpful if you explain me how to adjust core file limits using ulimit, and how get the backtrace? Via google: https://jvns.ca/blog/2018/04/28/debugging-a-segfault-on-linux/ ../Randy I have added python3-pip package in local.conf file, this is the one change only I did in local.conf. Yes, I am able to generate the image successfully after reverting this one change. Please let me know if more information require. On 15-08-2019 07:30 AM, Randy MacLeod wrote: On 8/12/19 10:42 AM, jaymin.da...@vivaldi.net wrote: Hello All, Facing segmentation fault (core dumped) while doing bitbake. I am using Yocto Jethro branch. Jethro isn't officially supported by the Yocto Project. The support cycle is ~ 1 year. https://wiki.yoctoproject.org/wiki/Releases Can you reproduce the issue on master or a newer supported branch? If so you could file a bug in: https://wiki.yoctoproject.org/wiki/Releases Also, see below for some tips. When I added python3-pip recipe (in local.conf) and started building image, segmentation fault occurred. Although, I am able to bitbake python3-pip individually (i.e. bitbake python3-pip). As per log my assumption is, core dumped is occurring at make_ext4fs execution. Following are the error logs: ERROR: Function failed: do_makesystem (log file is located at poky/build/tmp-glibc/work/apq8053-oe-linux/machine-image/1.0-r0/temp/log.do_makesystem.15059) ERROR: Logfile of failure stored in: poky/build/tmp-glibc/work/apq8053-oe-linux/machine-image/1.0-r0/temp/log.do_makesystem.15059 Log data follows: | DEBUG: Executing shell function do_makesystem | poky/build/tmp-glibc/work/apq8053-oe-linux/machine-image/1.0-r0/temp/run.do_makesystem.15059: line 105: 15073 Segmentation fault (core dumped) make_ext4fs -J -b 1024 -s -a / -S Odd, I've never see that happen before. Is it reproducible? Can you adjust the core file limits using 'ulimit', generate a core file and get a backtrace? poky/build/tmp-glibc/work/apq8053-oe-linux/machine-image/1.0-r0/rootfs/etc/selinux/mls/contexts/files/file_contexts -l 76800 poky/build/tmp-glibc/deploy/images/apq8053-perf/apq8053-sysfs.ext4 poky/build/tmp-glibc/work/apq8053-oe-linux/machine-image/1.0-r0/rootfs | WARNING: poky/build/tmp-glibc/work/apq8053-oe-linux/machine-image/1.0-r0/temp/run.do_makesystem.15059:1 exit 139 from | make_ext4fs -J -b 1024 -s -a / -S poky/build/tmp-glibc/work/apq8053-oe-linux/machine-image/1.0-r0/rootfs/etc/selinux/mls/contexts/files/file_contexts -l 76800 poky/build/tmp-glibc/deploy/images/apq8053-perf/apq8053-sysfs.ext4 poky/build/tmp-glibc/work/apq8053-oe-linux/machine-image/1.0-r0/rootfs | ERROR: Function failed: do_makesystem (log file is located at poky/build/tmp-glibc/work/apq8053-oe-linux/machine-image/1.0-r0/temp/log.do_makesystem.15059) ERROR: Task 11 ( poky/meta-qti-bsp/recipes-products/images/machine-image.bb, do_makesystem) failed with exit code '1' Whether python3-pip recipe is creating an issue or something else? (attached the python3-pip recipe file) What did you change in your conf/local.conf file? If you revert that change, then you are able to generate the image again? ../Randy Please let me know. Any suggestions are welcome. Regards, Jaymin -- # Randy MacLeod # Wind River Linux -- # Randy MacLeod # Wind River Linux -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] please help on compiling my kernel
On 8/13/19 5:59 AM, Tg, Harish wrote: Hi Guys, I am facing a strange issue which was working/compiling earlier. I did a clean and retried. Now I am getting this error with the command “bitbake -c compile -f linux-ti-staging”: WARNING: linux-ti-staging-4.4.45+gitAUTOINC+89944627d5-r1a.arago5 do_fetch: Failed to fetch URL git://git.omapzoom.org/kernel/omap;protocol=git;branch=p-ti-lsk-linux-4.4.y-next, attempting MIRRORS if available ERROR: linux-ti-staging-4.4.45+gitAUTOINC+89944627d5-r1a.arago5 do_fetch: Fetcher failure: Fetch command failed with exit code 128, output: fatal: Not a git repository (or any parent up to mount point /mnt/yocto) Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set). ERROR: linux-ti-staging-4.4.45+gitAUTOINC+89944627d5-r1a.arago5 do_fetch: Function failed: Fetcher failure for URL: 'git://git.omapzoom.org/kernel/omap;protocol=git;branch=p-ti-lsk-linux-4.4.y-next'. Unable to fetch URL from any source. ERROR: Logfile of failure stored in: /mnt/yocto/yocto_repo/build/arago-tmp-external-linaro-toolchain/work/delphi_jlr_isp_proto-linux-gnueabi/linux-ti-staging/4.4.45+gitAUTOINC+89944627d5-r1a.arago5/temp/log.do_fetch.102021 ERROR: Task 2 (/mnt/yocto/yocto_repo/sources/meta-ti/recipes-kernel/linux/linux-ti-staging_4.4.bb, do_fetch) failed with exit code '1' Kindly help with this. Thanks. Likely the server was just down for a while. Both the web site: http://git.omapzoom.org/?p=kernel/omap.git;a=summary and: $ git clone -b p-ti-lsk-linux-4.4.y-next git://git.omapzoom.org/kernel/omap.git omap.git Cloning into 'omap.git'... remote: Counting objects: 6410683, done. remote: Compressing objects: 100% (1028266/1028266), done. Receiving objects: 100% (6410683/6410683), 1.54 GiB | 2.62 MiB/s, done. remote: Total 6410683 (delta 5337468), reused 6409647 (delta 5336439) Resolving deltas: 100% (5337468/5337468), done. Checking out files: 100% (52679/52679), done. rmacleod@ala-lpggp2$echo $? 0 work for me now. Do you have a firewall blocking your internet access? I don't have this problems thankfully but if you do, it looks like there are some good recommendations here: https://stackoverflow.com/questions/4891527/git-protocol-blocked-by-company-how-can-i-get-around-that Of course you should abide by your corporate download policies. Oh and some vendors provide full copies of all source when you install their Yocto-based products. ../Randy Regards, Harish. -- # Randy MacLeod # Wind River Linux -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] wic create - bad ownership of directories inside image
On 8/12/19 5:11 AM, Behnke, Jochen wrote: Hello, I am using poky 2.6.1 (thud) and create images using the wic utility. Recently I noticed that all directories contained in the created image are owned by UID 1000 and not by root. The files inside the image however are owned by root. The UID 1000 refers to my unprivileged user on the host system. Here is the command I use to create the image “wic create mkefidisk –e core-image-minimal” The images created by bitbake directly (.tar.bz2, .hddimg) are correct so this seems to be a wic related problem. Does anybody have a solution for this? Hi Jochen, No and I've never seen this particular extreme symptom. There is a known, generally rare bug: Bug 12434 - pseudo: Incorrect UID/GID in packaged files https://bugzilla.yoctoproject.org/show_bug.cgi?id=12434 but that usually shows up when building. You could check you build logs for the generic stings from: glibc-locale-2.26: glibc-locale: /glibc-binary-localedata-en-gb/usr/lib/locale/en_GB/LC_MEASUREMENT is owned by uid 3004, which is the same as the user running bitbake. This may be due to host contamination [host-user-contaminated] Is your issue 100% reproducible? ../Randy Many thanks in advance, any hint is appreciated. Regards Jochen __ *SCHMIDT Technology GmbH* Feldbergstrasse 1 78112 St. Georgen/Germany Telefon +49 (0) 77 24 / 89 90 Fax +49 (0) 77 24 / 89 91 01 i...@schmidttechnology.de <mailto:i...@schmidttechnology.de> http://www.schmidttechnology.de USt-Id Nr. DE 811725105 · Registergericht Freiburg HRB 600 755 Geschaeftsfuehrung: Oliver Schmidt, Stephan Schmidt -- # Randy MacLeod # Wind River Linux -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Segmentation fault | bitbake machine-image.bb | core dumped
On 8/12/19 10:42 AM, jaymin.da...@vivaldi.net wrote: Hello All, Facing segmentation fault (core dumped) while doing bitbake. I am using Yocto Jethro branch. Jethro isn't officially supported by the Yocto Project. The support cycle is ~ 1 year. https://wiki.yoctoproject.org/wiki/Releases Can you reproduce the issue on master or a newer supported branch? If so you could file a bug in: https://wiki.yoctoproject.org/wiki/Releases Also, see below for some tips. When I added python3-pip recipe (in local.conf) and started building image, segmentation fault occurred. Although, I am able to bitbake python3-pip individually (i.e. bitbake python3-pip). As per log my assumption is, core dumped is occurring at make_ext4fs execution. Following are the error logs: ERROR: Function failed: do_makesystem (log file is located at poky/build/tmp-glibc/work/apq8053-oe-linux/machine-image/1.0-r0/temp/log.do_makesystem.15059) ERROR: Logfile of failure stored in: poky/build/tmp-glibc/work/apq8053-oe-linux/machine-image/1.0-r0/temp/log.do_makesystem.15059 Log data follows: | DEBUG: Executing shell function do_makesystem | poky/build/tmp-glibc/work/apq8053-oe-linux/machine-image/1.0-r0/temp/run.do_makesystem.15059: line 105: 15073 Segmentation fault (core dumped) make_ext4fs -J -b 1024 -s -a / -S Odd, I've never see that happen before. Is it reproducible? Can you adjust the core file limits using 'ulimit', generate a core file and get a backtrace? poky/build/tmp-glibc/work/apq8053-oe-linux/machine-image/1.0-r0/rootfs/etc/selinux/mls/contexts/files/file_contexts -l 76800 poky/build/tmp-glibc/deploy/images/apq8053-perf/apq8053-sysfs.ext4 poky/build/tmp-glibc/work/apq8053-oe-linux/machine-image/1.0-r0/rootfs | WARNING: poky/build/tmp-glibc/work/apq8053-oe-linux/machine-image/1.0-r0/temp/run.do_makesystem.15059:1 exit 139 from | make_ext4fs -J -b 1024 -s -a / -S poky/build/tmp-glibc/work/apq8053-oe-linux/machine-image/1.0-r0/rootfs/etc/selinux/mls/contexts/files/file_contexts -l 76800 poky/build/tmp-glibc/deploy/images/apq8053-perf/apq8053-sysfs.ext4 poky/build/tmp-glibc/work/apq8053-oe-linux/machine-image/1.0-r0/rootfs | ERROR: Function failed: do_makesystem (log file is located at poky/build/tmp-glibc/work/apq8053-oe-linux/machine-image/1.0-r0/temp/log.do_makesystem.15059) ERROR: Task 11 ( poky/meta-qti-bsp/recipes-products/images/machine-image.bb, do_makesystem) failed with exit code '1' Whether python3-pip recipe is creating an issue or something else? (attached the python3-pip recipe file) What did you change in your conf/local.conf file? If you revert that change, then you are able to generate the image again? ../Randy Please let me know. Any suggestions are welcome. Regards, Jaymin -- # Randy MacLeod # Wind River Linux -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Init stops working on second boot cycle
On 8/13/19 6:21 AM, Andy Pont wrote: I’ve got a strange issue and I don’t know whether it is a Yocto related issue, a kernel issue or something else completely… I have an image that is built with thud (2.6.2) using meta-atmel for the SAMA5D2-Xplained reference board. I deploy the resulting .wic file to an SD card and boot the reference board and all is OK. I can log into the terminal, upload files, etc. and again all seems to be well. If I press the reset button on the hardware platform, on the next boot cycle it always stops with the following being last messages being displayed: Freeing unused kernel memory: 1024K Run /sbin/init as init process INIT: version 2.88 booting The system hasn’t completely hung as the occasional kernel message appears but the user space init process (sysvinit) doesn’t seem to be What sort of occasional kernel message and do they eventually stop? working at all. If I put the SD card into a Linux desktop machine the file system on it is still valid and the changes that I have made are still present. Anyone got any ideas as to what is screwing it up? No but here are some generic debugging tips. In no particular order, have you tried: 1) setting kernel boot options such as: init=/bin/bash Does that reboot consistently when you press reset? 2) getting sysvinit to start an emergency shell? https://manpages.debian.org/testing/sysvinit-core/init.8.en.html I don't know how you'd do that for your board but is should be possible. 3) single user mode: https://wiki.gentoo.org/wiki/Sysvinit#Single_user_mode 4) Does the problem happen if you run 'shutdown -r now' rather than pressing the reset button? Good luck, -- # Randy MacLeod # Wind River Linux -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Anyone tried to build and to use QUIC?
On 7/31/19 7:06 AM, JH wrote: Hi, I searched recipes for supporting QUIC, but could not find it. Has anyone tried to build and to use QUIC? Thank you. Kind regards, - JH Hi, I presume that you mean QUIC (Quick UDP Internet Connections) as in: https://github.com/conght/quic I also couldn't find an existing recipe using: https://layers.openembedded.org/layerindex/branch/master/recipes/?q=QUIC or by a general web search. Do you have a specific implementation in mind? Care to write a recipe and send it in? FYI: http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded Alternatively contractors and companies are available if you want to go that route. -- # Randy MacLeod # Wind River Linux -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [ptest-runner][PATCH 4/4] Fix additional warnings when using clang
On 8/1/19 2:19 PM, Anibal Limon wrote: Hi Randy, Just push your clang fixes to master and created v2.3.2 tag, feel free to send a recipe upgrade. Regards, Anibal Hi Anibal, Excellent! I will send a recipe update. Thanks, -- # Randy MacLeod # Wind River Linux -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] how to stop applying patches in yocto project
On 7/25/19 7:19 AM, Tg, Harish wrote: Hi, I have requirement that I shall not apply patches to the yocto project and then build u-boot, kernel and the images. Can u please help me? Basically I need to revert back to PSDKLA-3.02 Release and without patches. Please guide me. PSDKLA-3.02 seems to be a TI distro that is apparently based on oe-core: http://processors.wiki.ti.com/index.php/Category:Processor_SDK_Linux_Automotive You should contact who ever your vendor or support organization is. If you can formulated and explain your question in fairly generic oe-core/yocto terms ideally with links to public git repos, then perhaps someone will help you out here. Good luck, ../Randy Thanks, Harish. -- # Randy MacLeod # Wind River Linux -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [ptest-runner][PATCH 3/4] tests: fix clang warnings.
Make tests build using: clang -Weverything
There are a few warnings that remain that are not
variable casting or macro fixes.
Signed-off-by: Randy MacLeod
---
tests/main.c | 5 +
tests/utils.c | 19 +--
2 files changed, 10 insertions(+), 14 deletions(-)
diff --git a/tests/main.c b/tests/main.c
index c3b4da5..e1a8b69 100644
--- a/tests/main.c
+++ b/tests/main.c
@@ -62,13 +62,10 @@ main(int argc, char *argv[])
opts_directory = strdup(optarg);
break;
case 'h':
- print_usage(stdout, argv[0]);
- exit(0);
- break;
+ /* fall though !! */
default:
print_usage(stdout, argv[0]);
exit(1);
- break;
}
}
diff --git a/tests/utils.c b/tests/utils.c
index 3ba64d6..571d488 100644
--- a/tests/utils.c
+++ b/tests/utils.c
@@ -33,7 +33,6 @@
#include "utils.h"
#define PRINT_PTEST_BUF_SIZE 8192
-#define PRINT_PTEST_MAX_LINE 512
extern char *opts_directory;
@@ -247,15 +246,15 @@ END_TEST
static int
filecmp(FILE *fp1, FILE *fp2)
{
-char f1, f2;
-while (1) {
- int end = 0;
-if ((f1 = getc(fp1)) == EOF) end++;
-if ((f2 = getc(fp2)) == EOF) end++;
-
- if (end == 2) return 0;
- if (end == 1) return 1;
-if (f1 != f2) return 2;
+ int f1, f2;
+ while (1) {
+ int end = 0;
+ if ((f1 = getc(fp1)) == EOF) end++;
+ if ((f2 = getc(fp2)) == EOF) end++;
+
+ if (end == 2) return 0;
+ if (end == 1) return 1;
+ if (f1 != f2) return 2;
}
}
--
2.17.0
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [ptest-runner][PATCH 4/4] Fix additional warnings when using clang
Drop unused function parameters in wait_child().
The remaining warning in the top dir code is:
utils.c:25:9: warning: macro name is a reserved identifier
[-Wreserved-id-macro]
#define _GNU_SOURCE
and it's not clear how to deal with that in a portable manner.
Drop unused variable in analizer code.
Rename analizer to analyzer.
Avoid program scope global by adding a set function for
the opts directory variable.
Free strdup()ed memory before exit.
Signed-off-by: Randy MacLeod
---
tests/main.c | 13 -
tests/ptest_list.c | 2 ++
tests/utils.c | 22 ++
utils.c| 6 ++
utils.h| 2 ++
5 files changed, 28 insertions(+), 17 deletions(-)
diff --git a/tests/main.c b/tests/main.c
index e1a8b69..1344bc0 100644
--- a/tests/main.c
+++ b/tests/main.c
@@ -38,14 +38,14 @@ static SuiteFunction *suites[] = {
NULL,
};
+extern void set_opts_dir(char *);
+
static inline void
print_usage(FILE *stream, char *progname)
{
fprintf(stream, "Usage: %s <-d directory>\n", progname);
}
-char *opts_directory;
-
int
main(int argc, char *argv[])
{
@@ -54,12 +54,12 @@ main(int argc, char *argv[])
int number_failed;
SuiteFunction *sf;
- opts_directory = NULL;
+ char *opts_dir = NULL;
while ((opt = getopt(argc, argv, "d:t:h")) != -1) {
switch (opt) {
case 'd':
- opts_directory = strdup(optarg);
+ opts_dir = strdup(optarg);
break;
case 'h':
/* fall though !! */
@@ -69,10 +69,11 @@ main(int argc, char *argv[])
}
}
- if (opts_directory == NULL) {
+ if (opts_dir == NULL) {
print_usage(stdout, argv[0]);
exit(1);
}
+ set_opts_dir(opts_dir);
i = 0;
number_failed = 0;
@@ -88,6 +89,8 @@ main(int argc, char *argv[])
i++;
sf = suites[i];
}
+ set_opts_dir(NULL);
+ free(opts_dir);
return number_failed;
}
diff --git a/tests/ptest_list.c b/tests/ptest_list.c
index e0ec276..081f027 100644
--- a/tests/ptest_list.c
+++ b/tests/ptest_list.c
@@ -29,6 +29,8 @@
#include "ptest_list.h"
+extern Suite *ptest_list_suite(void);
+
static int ptests_num = 6;
static char *ptest_names[] = {
"python",
diff --git a/tests/utils.c b/tests/utils.c
index 571d488..4fa4609 100644
--- a/tests/utils.c
+++ b/tests/utils.c
@@ -32,9 +32,15 @@
#include "ptest_list.h"
#include "utils.h"
+Suite *utils_suite(void);
+
#define PRINT_PTEST_BUF_SIZE 8192
-extern char *opts_directory;
+static char *opts_directory = NULL;
+
+void set_opts_dir(char * od) {
+ opts_directory = od;
+}
static char *ptests_found[] = {
"bash",
@@ -68,7 +74,7 @@ find_word(int *found, const char *line, const char *word)
}
static void test_ptest_expected_failure(struct ptest_list *, const int, char *,
- void (*h_analizer)(const int, FILE *, FILE *));
+ void (*h_analyzer)(const int, FILE *));
START_TEST(test_get_available_ptests)
{
@@ -189,7 +195,7 @@ START_TEST(test_run_ptests)
END_TEST
static void
-search_for_timeout_and_duration(const int rp, FILE *fp_stdout, FILE *fp_stderr)
+search_for_timeout_and_duration(const int rp, FILE *fp_stdout)
{
const char *timeout_str = "TIMEOUT";
const char *duration_str = "DURATION";
@@ -218,7 +224,7 @@ START_TEST(test_run_timeout_duration_ptest)
END_TEST
static void
-search_for_fail(const int rp, FILE *fp_stdout, FILE *fp_stderr)
+search_for_fail(const int rp, FILE *fp_stdout)
{
const char *fail_str = "ERROR: Exit status is";
char line_buf[PRINT_PTEST_BUF_SIZE];
@@ -284,7 +290,7 @@ START_TEST(test_xml_fail)
END_TEST
Suite *
-utils_suite()
+utils_suite(void)
{
Suite *s;
TCase *tc_core;
@@ -308,7 +314,7 @@ utils_suite()
static void
test_ptest_expected_failure(struct ptest_list *head, const int timeout, char
*progname,
- void (*h_analizer)(const int, FILE *, FILE *))
+ void (*h_analyzer)(const int, FILE *))
{
char *buf_stdout;
size_t size_stdout = PRINT_PTEST_BUF_SIZE;
@@ -329,9 +335,9 @@ test_ptest_expected_failure(struct ptest_list *head, const
int timeout, char *pr
struct ptest_options opts = EmptyOpts;
opts.timeout = timeout;
- h_analizer(
+ h_analyzer(
run_ptests(filtered, opts, progname, fp_stdout,
fp_stderr),
- fp_stdout, fp_stderr
+ fp_stdout
);
PTEST_LIST_FREE_ALL_CLEAN(filtered);
diff --git a/utils.c b/utils.c
index 92654bf..a8ba190 100644
--- a/utils
[yocto] [ptest-runner][PATCH 2/4] main code: fix clang warnings
Fix basic errors found when building with the clang compiler
with the option -Weverything. There are a few warnings that remain
that are not variable casting, macro fixes, or similarily simple
changes.
Makefile: add -lutil for 'check' builds for clang/gcc
builds.
Signed-off-by: Randy MacLeod
---
Makefile | 4 +++-
main.c | 9 -
ptest_list.c | 17 +++--
ptest_list.h | 29 ++---
utils.c | 38 +-
utils.h | 4 ++--
6 files changed, 67 insertions(+), 34 deletions(-)
diff --git a/Makefile b/Makefile
index 439eb79..c92261b 100644
--- a/Makefile
+++ b/Makefile
@@ -3,6 +3,8 @@ MEMCHECK=$(shell echo $$MEMCHECK)
CC=cc
CFLAGS=-std=gnu99 -pedantic -Wall -Werror -I .
+# CC=clang
+# CFLAGS=-std=gnu99 -Weverything -I .
ifeq ($(RELEASE), 1)
CFLAGS+= -O2 -DRELEASE
else
@@ -22,7 +24,7 @@ TEST_SOURCES=tests/main.c tests/ptest_list.c tests/utils.c
$(BASE_SOURCES)
TEST_OBJECTS=$(TEST_SOURCES:.c=.o)
TEST_EXECUTABLE=ptest-runner-test
TEST_LDFLAGS=-lm -lrt -lpthread
-TEST_LIBSTATIC=-lcheck -lsubunit
+TEST_LIBSTATIC=-lcheck -lsubunit -lutil
TEST_DATA=$(shell echo `pwd`/tests/data)
diff --git a/main.c b/main.c
index 83cd8f2..01d60f7 100644
--- a/main.c
+++ b/main.c
@@ -93,7 +93,7 @@ main(int argc, char *argv[])
}
- opts.exclude = malloc(ptest_exclude_num *
sizeof(char));
+ opts.exclude = malloc((size_t)ptest_exclude_num
* sizeof(char));
CHECK_ALLOCATION(opts.exclude, 1, 1);
i = 0;
@@ -116,7 +116,7 @@ main(int argc, char *argv[])
case 'h':
print_usage(stdout, argv[0]);
exit(0);
- break;
+ /* break; not needed, not reachable after exit() */
case 'x':
free(opts.xml_filename);
opts.xml_filename = strdup(optarg);
@@ -125,13 +125,12 @@ main(int argc, char *argv[])
default:
print_usage(stdout, argv[0]);
exit(1);
- break;
}
}
ptest_num = argc - optind;
if (ptest_num > 0) {
- size_t size = ptest_num * sizeof(char *);
+ size_t size = sizeof(char *) * (unsigned int) ptest_num;
opts.ptests = calloc(1, size);
CHECK_ALLOCATION(opts.ptests, size, 1);
@@ -163,7 +162,7 @@ main(int argc, char *argv[])
}
run = filter_ptests(head, opts.ptests, ptest_num);
- CHECK_ALLOCATION(run, ptest_num, 1);
+ CHECK_ALLOCATION(run, (size_t) ptest_num, 1);
ptest_list_free_all(head);
}
diff --git a/ptest_list.c b/ptest_list.c
index d48349f..a5632f8 100644
--- a/ptest_list.c
+++ b/ptest_list.c
@@ -29,8 +29,21 @@
#include "utils.h"
#include "ptest_list.h"
-#define VALIDATE_PTR_RINT(ptr) if (ptr == NULL) { errno = EINVAL; return -1; }
-#define VALIDATE_PTR_RNULL(ptr) if (ptr == NULL) { errno = EINVAL; return
NULL; }
+#define VALIDATE_PTR_RINT(ptr) \
+ do { \
+ if (ptr == NULL) { \
+ errno = EINVAL; \
+ return -1; \
+ } \
+ } while (0)
+
+#define VALIDATE_PTR_RNULL(ptr) \
+ do { \
+ if (ptr == NULL) { \
+ errno = EINVAL; \
+ return NULL; \
+ } \
+ } while (0)
struct ptest_list *
ptest_list_alloc()
diff --git a/ptest_list.h b/ptest_list.h
index b4b1ac6..e1caffc 100644
--- a/ptest_list.h
+++ b/ptest_list.h
@@ -21,13 +21,28 @@
* Aníbal Limón
*/
-#ifndef _PTEST_RUNNER_LIST_H_
-#define _PTEST_RUNNER_LIST_H_
+#ifndef PTEST_RUNNER_LIST_H
+#define PTEST_RUNNER_LIST_H
-#define PTEST_LIST_FREE_CLEAN(x) { ptest_list_free(x); x = NULL; }
-#define PTEST_LIST_FREE_ALL_CLEAN(x) { ptest_list_free_all(x); x = NULL; }
+#define FLUSH_PRINTF(...) \
+do { \
+printf(__VA_ARGS__); \
+fflush(stdout); \
+} while (0)
-#define PTEST_LIST_ITERATE_START(head, p) for (p = head->next; p != NULL; p =
p->next) {
+#define PTEST_LIST_FREE_CLEAN(x) \
+ do { \
+ ptest_list_free(x); \
+ x = NULL; \
+ } while (0)
+
+#define PTEST_LIST_FREE_ALL_CLEAN(x) \
+ do { \
+ ptest_list_free_all(x); \
+ x = NULL; \
+ } while (0)
+
+#define PTEST_LIST_ITERATE_START(head, p) for (p = head->next; p != NULL; p =
p->next) {
#define PTEST_LIST_ITERATE_END }
#include
@@ -40,7 +55,7 @@ struct ptest_list {
struct ptest_list *prev;
};
-extern struct ptest_list *ptest_list_alloc();
+extern
[yocto] [ptest-runner][PATCH 1/4] utils: ensure child can be session leader
When running the run-execscript bash ptest as a user rather than root, a
warning:
bash: cannot set terminal process group (16036): Inappropriate ioctl for
device
bash: no job control in this shell
contaminates the bash log files causing the test to fail. This happens only
when run under ptest-runner and not when interactively testing!
The changes made to fix this include:
1. Get the process group id (pgid) before forking,
2. Set the pgid in both the parent and child to avoid a race,
3. Find, open and set permission on the child tty, and
4. Allow the child to attach to controlling tty.
Also add '-lutil' to Makefile. This lib is from libc and provides openpty.
Upstream-Status: Submitted [yocto@yoctoproject.org]
Signed-off-by: Sakib Sajal
Signed-off-by: Randy MacLeod
---
Makefile | 2 +-
utils.c | 102 +--
2 files changed, 92 insertions(+), 12 deletions(-)
diff --git a/Makefile b/Makefile
index 1bde7be..439eb79 100644
--- a/Makefile
+++ b/Makefile
@@ -29,7 +29,7 @@ TEST_DATA=$(shell echo `pwd`/tests/data)
all: $(SOURCES) $(EXECUTABLE)
$(EXECUTABLE): $(OBJECTS)
- $(CC) $(LDFLAGS) $(OBJECTS) -o $@
+ $(CC) $(LDFLAGS) $(OBJECTS) -lutil -o $@
tests: $(TEST_SOURCES) $(TEST_EXECUTABLE)
diff --git a/utils.c b/utils.c
index ad737c2..f11ce39 100644
--- a/utils.c
+++ b/utils.c
@@ -1,5 +1,6 @@
/**
* Copyright (c) 2016 Intel Corporation
+ * Copyright (C) 2019 Wind River Systems, Inc.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
@@ -22,23 +23,27 @@
*/
#define _GNU_SOURCE
+
#include
+#include
+#include
+#include
+#include
#include
-#include
#include
-#include
+#include
+#include
+#include
+#include
#include
-#include
+#include
+
+#include
#include
+#include
#include
#include
-#include
-#include
-#include
-#include
-
-#include
#include "ptest_list.h"
#include "utils.h"
@@ -346,6 +351,53 @@ wait_child(const char *ptest_dir, const char *run_ptest,
pid_t pid,
return status;
}
+/* Returns an integer file descriptor.
+ * If it returns < 0, an error has occurred.
+ * Otherwise, it has returned the slave pty file descriptor.
+ * fp should be writable, likely stdout/err.
+ */
+static int
+setup_slave_pty(FILE *fp) {
+ int pty_master = -1;
+ int pty_slave = -1;
+ char pty_name[256];
+ struct group *gptr;
+ gid_t gid;
+ int slave = -1;
+
+ if (openpty(_master, _slave, pty_name, NULL, NULL) < 0) {
+ fprintf(fp, "ERROR: openpty() failed with: %s.\n",
strerror(errno));
+ return -1;
+ }
+
+ if ((gptr = getgrnam(pty_name)) != 0) {
+ gid = gptr->gr_gid;
+ } else {
+ /* If the tty group does not exist, don't change the
+* group on the slave pty, only the owner
+*/
+ gid = -1;
+ }
+
+ /* chown/chmod the corresponding pty, if possible.
+* This will only work if the process has root permissions.
+*/
+ if (chown(pty_name, getuid(), gid) != 0) {
+ fprintf(fp, "ERROR; chown() failed with: %s.\n",
strerror(errno));
+ }
+
+ /* Makes the slave read/writeable for the user. */
+ if (chmod(pty_name, S_IRUSR|S_IWUSR) != 0) {
+ fprintf(fp, "ERROR: chmod() failed with: %s.\n",
strerror(errno));
+ }
+
+ if ((slave = open(pty_name, O_RDWR)) == -1) {
+ fprintf(fp, "ERROR: open() failed with: %s.\n",
strerror(errno));
+ }
+ return (slave);
+}
+
+
int
run_ptests(struct ptest_list *head, const struct ptest_options opts,
const char *progname, FILE *fp, FILE *fp_stderr)
@@ -362,6 +414,8 @@ run_ptests(struct ptest_list *head, const struct
ptest_options opts,
int timeouted;
time_t sttime, entime;
int duration;
+ int slave;
+ int pgid = -1;
if (opts.xml_filename) {
xh = xml_create(ptest_list_length(head), opts.xml_filename);
@@ -379,7 +433,6 @@ run_ptests(struct ptest_list *head, const struct
ptest_options opts,
close(pipefd_stdout[1]);
break;
}
-
fprintf(fp, "START: %s\n", progname);
PTEST_LIST_ITERATE_START(head, p);
char *ptest_dir = strdup(p->run_ptest);
@@ -388,6 +441,13 @@ run_ptests(struct ptest_list *head, const struct
ptest_options opts,
break;
}
dirname(ptest_dir);
+ if (ioctl(0, TIOCNOTTY) == -1) {
+ fprintf(fp, "ERROR: Unable to detach from
controlling tty, %s\n", strerror(errno));
+ }
+
+
Re: [yocto] [ptest-runner][PATCH v2 4/4] utils: ensure child can be session leader
On 6/25/19 9:51 PM, Anibal Limon wrote: On Wed, 19 Jun 2019 at 12:50, Randy MacLeod <mailto:randy.macl...@windriver.com>> wrote: On 6/14/19 10:48 AM, Randy MacLeod wrote: > When running the run-execscript bash ptest as a user rather than root, a warning: > bash: cannot set terminal process group (16036): Inappropriate ioctl for device > bash: no job control in this shell > contaminates the bash log files causing the test to fail. This happens only > when run under ptest-runner and not when interactively testing! > > The changes made to fix this include: > 1. Get the process group id (pgid) before forking, > 2. Set the pgid in both the parent and child to avoid a race, > 3. Find, open and set permission on the child tty, and > 4. Allow the child to attach to controlling tty. > > Also add '-lutil' to Makefile. This lib is from libc and provides openpty. Hmmm, I was making the code compile cleanly under clang using -Weverything when I noticed: 1. the 'make check' tests. They still work fine. 2. The './ptest-runner -d tests/data -t 1' tests which now generate loads of error like: ERROR: Unable to detach from controlling tty, Inappropriate ioctl for device so while this change fixed the bash-ptest, the ptest-runner self-test it did something wrong Ah, I'm calling: ioctl(0, TIOCNOTTY) == -1) repeatedly in the parent so that's what's generating the extra logs. Fixed locally and I'll send a patch but it's not urgent. Phew! :) Anibal, If you could reply to explain your plans for Richard's patches that would help me figure out when to send the clang warning clean-ups commits and what commit to base my work on. Hi, I plan to take the Richard patches, He added in the recipe to have real testing and looks like there aren't problems related to, Richard can you confirm it?, Regarding the openpty include, I see some linkage problem when running make check, proposed fix: Yes, I had noticed that and fixed it as well. I'll send my latest patch series once you have merged Richard's changes into master. Hopefully that will be today... :) I decided to compile with: clang -Weverything to see if there were any problems and there were quite a few things to fix. Now, for the most part, neither clang nor gcc complain about the code. ../Randy ... --- a/Makefile +++ b/Makefile @@ -22,19 +22,20 @@ TEST_SOURCES=tests/main.c tests/ptest_list.c tests/utils.c $(BASE_SOURCES) TEST_OBJECTS=$(TEST_SOURCES:.c=.o) TEST_EXECUTABLE=ptest-runner-test TEST_LDFLAGS=-lm -lrt -lpthread -TEST_LIBSTATIC=-lcheck -lsubunit +TEST_LIBSTATIC=-lutil +TEST_LIBSTATIC_TEST=$(TEST_LIBSTATIC) -lcheck -lsubunit TEST_DATA=$(shell echo `pwd`/tests/data) all: $(SOURCES) $(EXECUTABLE) $(EXECUTABLE): $(OBJECTS) - $(CC) $(LDFLAGS) $(OBJECTS) -lutil -o $@ + $(CC) $(LDFLAGS) $(OBJECTS) -o $@ $(TEST_LIBSTATIC) tests: $(TEST_SOURCES) $(TEST_EXECUTABLE) $(TEST_EXECUTABLE): $(TEST_OBJECTS) - $(CC) $(LDFLAGS) $(TEST_LDFLAGS) $(TEST_OBJECTS) -o $@ $(TEST_LIBSTATIC) + $(CC) $(LDFLAGS) $(TEST_LDFLAGS) $(TEST_OBJECTS) -o $@ $(TEST_LIBSTATIC_TEST) check: $(TEST_EXECUTABLE) ./$(TEST_EXECUTABLE) -d $(TEST_DATA) ... Best regards, Anibal ../Randy > > Signed-off-by: Sakib Sajal mailto:sakib.sa...@windriver.com>> > Signed-off-by: Randy MacLeod mailto:randy.macl...@windriver.com>> > --- > Makefile | 2 +- > utils.c | 102 +-- > 2 files changed, 92 insertions(+), 12 deletions(-) > > diff --git a/Makefile b/Makefile > index 1bde7be..439eb79 100644 > --- a/Makefile > +++ b/Makefile > @@ -29,7 +29,7 @@ TEST_DATA=$(shell echo `pwd`/tests/data) > all: $(SOURCES) $(EXECUTABLE) > > $(EXECUTABLE): $(OBJECTS) > - $(CC) $(LDFLAGS) $(OBJECTS) -o $@ > + $(CC) $(LDFLAGS) $(OBJECTS) -lutil -o $@ > > tests: $(TEST_SOURCES) $(TEST_EXECUTABLE) > > diff --git a/utils.c b/utils.c > index ad737c2..f11ce39 100644 > --- a/utils.c > +++ b/utils.c > @@ -1,5 +1,6 @@ > /** > * Copyright (c) 2016 Intel Corporation > + * Copyright (C) 2019 Wind River Systems, Inc. > * > * This program is free software; you can redistribute it and/or > * modify it under the terms of the GNU General Public License > @@ -22,23 +23,27 @@ > */ > > #define _GNU_SOURCE > + > #include > > +#include > +#include > +#include > +#include >
Re: [yocto] [ptest-runner][PATCH v2 4/4] utils: ensure child can be session leader
On 6/19/19 3:24 PM, richard.pur...@linuxfoundation.org wrote: On Wed, 2019-06-19 at 13:49 -0400, Randy MacLeod wrote: On 6/14/19 10:48 AM, Randy MacLeod wrote: When running the run-execscript bash ptest as a user rather than root, a warning: bash: cannot set terminal process group (16036): Inappropriate ioctl for device bash: no job control in this shell contaminates the bash log files causing the test to fail. This happens only when run under ptest-runner and not when interactively testing! The changes made to fix this include: 1. Get the process group id (pgid) before forking, 2. Set the pgid in both the parent and child to avoid a race, 3. Find, open and set permission on the child tty, and 4. Allow the child to attach to controlling tty. Also add '-lutil' to Makefile. This lib is from libc and provides openpty. Hmmm, I was making the code compile cleanly under clang using -Weverything when I noticed: 1. the 'make check' tests. They still work fine. 2. The './ptest-runner -d tests/data -t 1' tests which now generate loads of error like: ERROR: Unable to detach from controlling tty, Inappropriate ioctl for device Aha. Does this mean you get to own: https://bugzilla.yoctoproject.org/show_bug.cgi?id=13409 :) Yes, that's likely my fault. I've taken the defect. ../Randy 'belt and suspenders' MacLeod so while this change fixed the bash-ptest, the ptest-runner self-test it did something wrong Ah, I'm calling: ioctl(0, TIOCNOTTY) == -1) repeatedly in the parent so that's what's generating the extra logs. Fixed locally and I'll send a patch but it's not urgent. Phew! :) Anibal, If you could reply to explain your plans for Richard's patches that would help me figure out when to send the clang warning clean- ups commits and what commit to base my work on. I think he believed some of them unnecessary, they were a bit belt and brances but I'm not sure that is a bad thing. Cheers, Richard -- # Randy MacLeod # Wind River Linux -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [ptest-runner][PATCH v2 4/4] utils: ensure child can be session leader
On 6/14/19 10:48 AM, Randy MacLeod wrote:
When running the run-execscript bash ptest as a user rather than root, a
warning:
bash: cannot set terminal process group (16036): Inappropriate ioctl for
device
bash: no job control in this shell
contaminates the bash log files causing the test to fail. This happens only
when run under ptest-runner and not when interactively testing!
The changes made to fix this include:
1. Get the process group id (pgid) before forking,
2. Set the pgid in both the parent and child to avoid a race,
3. Find, open and set permission on the child tty, and
4. Allow the child to attach to controlling tty.
Also add '-lutil' to Makefile. This lib is from libc and provides openpty.
Hmmm, I was making the code compile cleanly under clang using
-Weverything
when I noticed:
1. the 'make check' tests. They still work fine.
2. The './ptest-runner -d tests/data -t 1' tests
which now generate loads of error like:
ERROR: Unable to detach from controlling tty, Inappropriate ioctl
for device
so while this change fixed the bash-ptest, the ptest-runner self-test
it did something wrong Ah, I'm calling:
ioctl(0, TIOCNOTTY) == -1)
repeatedly in the parent so that's what's generating the extra logs.
Fixed locally and I'll send a patch but it's not urgent. Phew! :)
Anibal,
If you could reply to explain your plans for Richard's patches
that would help me figure out when to send the clang warning clean-ups
commits and what commit to base my work on.
../Randy
Signed-off-by: Sakib Sajal
Signed-off-by: Randy MacLeod
---
Makefile | 2 +-
utils.c | 102 +--
2 files changed, 92 insertions(+), 12 deletions(-)
diff --git a/Makefile b/Makefile
index 1bde7be..439eb79 100644
--- a/Makefile
+++ b/Makefile
@@ -29,7 +29,7 @@ TEST_DATA=$(shell echo `pwd`/tests/data)
all: $(SOURCES) $(EXECUTABLE)
$(EXECUTABLE): $(OBJECTS)
- $(CC) $(LDFLAGS) $(OBJECTS) -o $@
+ $(CC) $(LDFLAGS) $(OBJECTS) -lutil -o $@
tests: $(TEST_SOURCES) $(TEST_EXECUTABLE)
diff --git a/utils.c b/utils.c
index ad737c2..f11ce39 100644
--- a/utils.c
+++ b/utils.c
@@ -1,5 +1,6 @@
/**
* Copyright (c) 2016 Intel Corporation
+ * Copyright (C) 2019 Wind River Systems, Inc.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
@@ -22,23 +23,27 @@
*/
#define _GNU_SOURCE
+
#include
+#include
+#include
+#include
+#include
#include
-#include
#include
-#include
+#include
+#include
+#include
+#include
#include
-#include
+#include
+
+#include
#include
+#include
#include
#include
-#include
-#include
-#include
-#include
-
-#include
#include "ptest_list.h"
#include "utils.h"
@@ -346,6 +351,53 @@ wait_child(const char *ptest_dir, const char *run_ptest,
pid_t pid,
return status;
}
+/* Returns an integer file descriptor.
+ * If it returns < 0, an error has occurred.
+ * Otherwise, it has returned the slave pty file descriptor.
+ * fp should be writable, likely stdout/err.
+ */
+static int
+setup_slave_pty(FILE *fp) {
+ int pty_master = -1;
+ int pty_slave = -1;
+ char pty_name[256];
+ struct group *gptr;
+ gid_t gid;
+ int slave = -1;
+
+ if (openpty(_master, _slave, pty_name, NULL, NULL) < 0) {
+ fprintf(fp, "ERROR: openpty() failed with: %s.\n",
strerror(errno));
+ return -1;
+ }
+
+ if ((gptr = getgrnam(pty_name)) != 0) {
+ gid = gptr->gr_gid;
+ } else {
+ /* If the tty group does not exist, don't change the
+* group on the slave pty, only the owner
+*/
+ gid = -1;
+ }
+
+ /* chown/chmod the corresponding pty, if possible.
+* This will only work if the process has root permissions.
+*/
+ if (chown(pty_name, getuid(), gid) != 0) {
+ fprintf(fp, "ERROR; chown() failed with: %s.\n",
strerror(errno));
+ }
+
+ /* Makes the slave read/writeable for the user. */
+ if (chmod(pty_name, S_IRUSR|S_IWUSR) != 0) {
+ fprintf(fp, "ERROR: chmod() failed with: %s.\n",
strerror(errno));
+ }
+
+ if ((slave = open(pty_name, O_RDWR)) == -1) {
+ fprintf(fp, "ERROR: open() failed with: %s.\n",
strerror(errno));
+ }
+ return (slave);
+}
+
+
int
run_ptests(struct ptest_list *head, const struct ptest_options opts,
const char *progname, FILE *fp, FILE *fp_stderr)
@@ -362,6 +414,8 @@ run_ptests(struct ptest_list *head, const struct
ptest_options opts,
int timeouted;
time_t sttime, entime;
int duration;
+ int slave;
+ int pgid = -1;
if (opts.xml_filename) {
xh = xml_create(ptest_
[yocto] [ptest-runner][PATCH v2 3/4] utils: Ensure pipes are read after exit
From: Richard Purdie
There was a race in the code where the pipes may not be read after the process
has exited
and data may be left behind in them. This change to ordering ensures the pipes
are read
after the exit code has been read meaning no data can be left behind and the
logs should
be complete.
Signed-off-by: Richard Purdie
Upstream-Status: Pending [code being tested]
---
utils.c | 29 -
1 file changed, 16 insertions(+), 13 deletions(-)
diff --git a/utils.c b/utils.c
index 86dcdad..ad737c2 100644
--- a/utils.c
+++ b/utils.c
@@ -285,6 +285,7 @@ wait_child(const char *ptest_dir, const char *run_ptest,
pid_t pid,
struct pollfd pfds[2];
struct timespec sentinel;
clockid_t clock = CLOCK_MONOTONIC;
+ int looping = 1;
int r;
int status;
@@ -302,9 +303,23 @@ wait_child(const char *ptest_dir, const char *run_ptest,
pid_t pid,
*timeouted = 0;
- while (1) {
+ while (looping) {
waitflags = WNOHANG;
+ if (timeout >= 0) {
+ struct timespec time;
+
+ clock_gettime(clock, );
+ if ((time.tv_sec - sentinel.tv_sec) > timeout) {
+ *timeouted = 1;
+ kill(-pid, SIGKILL);
+ waitflags = 0;
+ }
+ }
+
+ if (waitpid(pid, , waitflags) == pid)
+ looping = 0;
+
r = poll(pfds, 2, WAIT_CHILD_POLL_TIMEOUT_MS);
if (r > 0) {
char buf[WAIT_CHILD_BUF_MAX_SIZE];
@@ -324,19 +339,7 @@ wait_child(const char *ptest_dir, const char *run_ptest,
pid_t pid,
}
clock_gettime(clock, );
- } else if (timeout >= 0) {
- struct timespec time;
-
- clock_gettime(clock, );
- if ((time.tv_sec - sentinel.tv_sec) > timeout) {
- *timeouted = 1;
- kill(-pid, SIGKILL);
- waitflags = 0;
- }
}
-
- if (waitpid(pid, , waitflags) == pid)
- break;
}
fflush(fps[0]);
--
2.17.0
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [ptest-runner][PATCH v2 4/4] utils: ensure child can be session leader
When running the run-execscript bash ptest as a user rather than root, a
warning:
bash: cannot set terminal process group (16036): Inappropriate ioctl for
device
bash: no job control in this shell
contaminates the bash log files causing the test to fail. This happens only
when run under ptest-runner and not when interactively testing!
The changes made to fix this include:
1. Get the process group id (pgid) before forking,
2. Set the pgid in both the parent and child to avoid a race,
3. Find, open and set permission on the child tty, and
4. Allow the child to attach to controlling tty.
Also add '-lutil' to Makefile. This lib is from libc and provides openpty.
Signed-off-by: Sakib Sajal
Signed-off-by: Randy MacLeod
---
Makefile | 2 +-
utils.c | 102 +--
2 files changed, 92 insertions(+), 12 deletions(-)
diff --git a/Makefile b/Makefile
index 1bde7be..439eb79 100644
--- a/Makefile
+++ b/Makefile
@@ -29,7 +29,7 @@ TEST_DATA=$(shell echo `pwd`/tests/data)
all: $(SOURCES) $(EXECUTABLE)
$(EXECUTABLE): $(OBJECTS)
- $(CC) $(LDFLAGS) $(OBJECTS) -o $@
+ $(CC) $(LDFLAGS) $(OBJECTS) -lutil -o $@
tests: $(TEST_SOURCES) $(TEST_EXECUTABLE)
diff --git a/utils.c b/utils.c
index ad737c2..f11ce39 100644
--- a/utils.c
+++ b/utils.c
@@ -1,5 +1,6 @@
/**
* Copyright (c) 2016 Intel Corporation
+ * Copyright (C) 2019 Wind River Systems, Inc.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
@@ -22,23 +23,27 @@
*/
#define _GNU_SOURCE
+
#include
+#include
+#include
+#include
+#include
#include
-#include
#include
-#include
+#include
+#include
+#include
+#include
#include
-#include
+#include
+
+#include
#include
+#include
#include
#include
-#include
-#include
-#include
-#include
-
-#include
#include "ptest_list.h"
#include "utils.h"
@@ -346,6 +351,53 @@ wait_child(const char *ptest_dir, const char *run_ptest,
pid_t pid,
return status;
}
+/* Returns an integer file descriptor.
+ * If it returns < 0, an error has occurred.
+ * Otherwise, it has returned the slave pty file descriptor.
+ * fp should be writable, likely stdout/err.
+ */
+static int
+setup_slave_pty(FILE *fp) {
+ int pty_master = -1;
+ int pty_slave = -1;
+ char pty_name[256];
+ struct group *gptr;
+ gid_t gid;
+ int slave = -1;
+
+ if (openpty(_master, _slave, pty_name, NULL, NULL) < 0) {
+ fprintf(fp, "ERROR: openpty() failed with: %s.\n",
strerror(errno));
+ return -1;
+ }
+
+ if ((gptr = getgrnam(pty_name)) != 0) {
+ gid = gptr->gr_gid;
+ } else {
+ /* If the tty group does not exist, don't change the
+* group on the slave pty, only the owner
+*/
+ gid = -1;
+ }
+
+ /* chown/chmod the corresponding pty, if possible.
+* This will only work if the process has root permissions.
+*/
+ if (chown(pty_name, getuid(), gid) != 0) {
+ fprintf(fp, "ERROR; chown() failed with: %s.\n",
strerror(errno));
+ }
+
+ /* Makes the slave read/writeable for the user. */
+ if (chmod(pty_name, S_IRUSR|S_IWUSR) != 0) {
+ fprintf(fp, "ERROR: chmod() failed with: %s.\n",
strerror(errno));
+ }
+
+ if ((slave = open(pty_name, O_RDWR)) == -1) {
+ fprintf(fp, "ERROR: open() failed with: %s.\n",
strerror(errno));
+ }
+ return (slave);
+}
+
+
int
run_ptests(struct ptest_list *head, const struct ptest_options opts,
const char *progname, FILE *fp, FILE *fp_stderr)
@@ -362,6 +414,8 @@ run_ptests(struct ptest_list *head, const struct
ptest_options opts,
int timeouted;
time_t sttime, entime;
int duration;
+ int slave;
+ int pgid = -1;
if (opts.xml_filename) {
xh = xml_create(ptest_list_length(head), opts.xml_filename);
@@ -379,7 +433,6 @@ run_ptests(struct ptest_list *head, const struct
ptest_options opts,
close(pipefd_stdout[1]);
break;
}
-
fprintf(fp, "START: %s\n", progname);
PTEST_LIST_ITERATE_START(head, p);
char *ptest_dir = strdup(p->run_ptest);
@@ -388,6 +441,13 @@ run_ptests(struct ptest_list *head, const struct
ptest_options opts,
break;
}
dirname(ptest_dir);
+ if (ioctl(0, TIOCNOTTY) == -1) {
+ fprintf(fp, "ERROR: Unable to detach from
controlling tty, %s\n", strerror(errno));
+ }
+
+ if ((pgid = getpgid(0)) == -1) {
[yocto] [ptest-runner][PATCH v2] 3 old patches + utils: ensure child can be session leader
My patch needs Richards previous 3 patches so I've added them here. I've cleaned up the patch a bit since v1; mostly it's indentation and other cosmetic changes. I have added a bit more error handling and I've renamed get_slave_pty to setup_slave_pty to more accurately reflect what the function does. Also I've cleaned up the code to only use open_pty() to get the tty name. Care to release an update now that oe-core 2.8-M1 is in QA? ../Randy -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [ptest-runner][PATCH v2 2/4] use process groups when spawning
From: Richard Purdie
Rather than just killing the process we've swawned, set the process group
for spawned children and then kill the group of processes.
Signed-off-by: Richard Purdie
Upstream-Status: Pending [code being tested]
---
utils.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/utils.c b/utils.c
index 9fab6f2..86dcdad 100644
--- a/utils.c
+++ b/utils.c
@@ -330,7 +330,7 @@ wait_child(const char *ptest_dir, const char *run_ptest,
pid_t pid,
clock_gettime(clock, );
if ((time.tv_sec - sentinel.tv_sec) > timeout) {
*timeouted = 1;
- kill(pid, SIGKILL);
+ kill(-pid, SIGKILL);
waitflags = 0;
}
}
@@ -392,6 +392,7 @@ run_ptests(struct ptest_list *head, const struct
ptest_options opts,
rc = -1;
break;
} else if (child == 0) {
+ setsid();
run_child(p->run_ptest, pipefd_stdout[1],
pipefd_stderr[1]);
} else {
int status;
--
2.17.0
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [ptest-runner][PATCH v2 1/4] utils: Ensure stdout/stderr are flushed
From: Richard Purdie
There is no guarantee that the data written with fwrite will be flushed to the
buffer. If stdout and stderr are the same thing, this could lead to interleaved
writes. The common case is stdout output so flush the output pipes when writing
to
stderr. Also flush stdout before the function returns.
Signed-off-by: Richard Purdie
Upstream-Status: Pending [code being tested]
---
utils.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/utils.c b/utils.c
index 6e453a1..9fab6f2 100644
--- a/utils.c
+++ b/utils.c
@@ -316,8 +316,11 @@ wait_child(const char *ptest_dir, const char *run_ptest,
pid_t pid,
}
if (pfds[1].revents != 0) {
- while ((n = read(fds[1], buf,
WAIT_CHILD_BUF_MAX_SIZE)) > 0)
+ while ((n = read(fds[1], buf,
WAIT_CHILD_BUF_MAX_SIZE)) > 0) {
+ fflush(fps[0]);
fwrite(buf, n, 1, fps[1]);
+ fflush(fps[1]);
+ }
}
clock_gettime(clock, );
@@ -336,7 +339,7 @@ wait_child(const char *ptest_dir, const char *run_ptest,
pid_t pid,
break;
}
-
+ fflush(fps[0]);
return status;
}
--
2.17.0
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [ptest-runner][PATCH] utils: ensure child can be session leader
On 6/13/19 6:39 PM, Randy MacLeod wrote: From: Sakib Sajal Oops. Sakib started on this and then had to work on something else so I finished it up. If needed, I'll send a v2 with me as the author, since "finishing up" was most of the work. We're both down as SOBs so whatever works. -- # Randy MacLeod # Wind River Linux -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [ptest-runner][PATCH] utils: ensure child can be session leader
From: Sakib Sajal
When running the run-execscript bash ptest as a user rather than root, a
warning:
bash: cannot set terminal process group (16036): Inappropriate ioctl for
device
bash: no job control in this shell
contaminates the bash log files causing the test to fail. This happens only
when run under ptest-runner and not when interactively testing!
The changes made to fix this include:
1. Get the process group id (pgid) before forking,
2. Set the pgid in both the parent and child to avoid a race,
3. Find, open and set permission on the child tty, and
4. Allow the child to attach to controlling tty.
Also add '-lutil' to Makefile. This lib is from libc and provides openpty.
Signed-off-by: Sakib Sajal
Signed-off-by: Randy MacLeod
---
Makefile | 2 +-
utils.c | 100 +--
2 files changed, 91 insertions(+), 11 deletions(-)
diff --git a/Makefile b/Makefile
index 1bde7be..439eb79 100644
--- a/Makefile
+++ b/Makefile
@@ -29,7 +29,7 @@ TEST_DATA=$(shell echo `pwd`/tests/data)
all: $(SOURCES) $(EXECUTABLE)
$(EXECUTABLE): $(OBJECTS)
- $(CC) $(LDFLAGS) $(OBJECTS) -o $@
+ $(CC) $(LDFLAGS) $(OBJECTS) -lutil -o $@
tests: $(TEST_SOURCES) $(TEST_EXECUTABLE)
diff --git a/utils.c b/utils.c
index ad737c2..d8977c6 100644
--- a/utils.c
+++ b/utils.c
@@ -1,5 +1,6 @@
/**
* Copyright (c) 2016 Intel Corporation
+ * Copyright (C) 2019 Wind River Systems, Inc.
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
@@ -22,23 +23,29 @@
*/
#define _GNU_SOURCE
+
#include
+#include
+#include
+#include
+#include
#include
-#include
#include
-#include
+#include
+#include
+#include
+#include
#include
-#include
+#include
+
+
+#include
#include
+#include
#include
#include
-#include
-#include
-#include
-#include
-#include
#include "ptest_list.h"
#include "utils.h"
@@ -346,6 +353,51 @@ wait_child(const char *ptest_dir, const char *run_ptest,
pid_t pid,
return status;
}
+/* get_slave_pty() returns an integer file descriptor.
+ * If it returns < 0, an error has occurred.
+ * Otherwise, it has returned the slave file descriptor.
+ * fp should be writable, likely stdout/err.
+ */
+static int
+setup_slave_pty(FILE *fp) {
+ int pty_master = -1;
+ int pty_slave = -1;
+ char pty_name[256];
+ struct group *gptr;
+ gid_t gid;
+ int slave = -1;
+
+ if (openpty(_master, _slave, pty_name, NULL, NULL) < 0) {
+ fprintf(fp, "ERROR: openpty() failed with: %s.\n",
strerror(errno));
+ return -1;
+ }
+
+ if ((gptr = getgrnam(pty_name)) != 0) {
+ gid = gptr->gr_gid;
+ } else {
+ /* If the tty group does not exist, don't change the
+* group on the slave pty, only the owner
+*/
+ gid = -1;
+ }
+
+ /* chown/chmod the corresponding pty, if possible.
+* This will only work if the process has root permissions.
+*/
+ if (chown(pty_name, getuid(), gid) != 0) {
+ fprintf(fp, "ERROR; chown() failed with: %s.\n",
strerror(errno));
+ }
+
+ /* Makes the slave read/writeable for the user. */
+ if (chmod(pty_name, S_IRUSR|S_IWUSR) != 0) {
+ fprintf(fp, "ERROR: chmod() failed with: %s.\n",
strerror(errno));
+ }
+
+ slave = open(pty_name, O_RDWR);
+ return (slave);
+}
+
+
int
run_ptests(struct ptest_list *head, const struct ptest_options opts,
const char *progname, FILE *fp, FILE *fp_stderr)
@@ -362,6 +414,8 @@ run_ptests(struct ptest_list *head, const struct
ptest_options opts,
int timeouted;
time_t sttime, entime;
int duration;
+ int slave;
+ int pgid = -1;
if (opts.xml_filename) {
xh = xml_create(ptest_list_length(head), opts.xml_filename);
@@ -379,7 +433,6 @@ run_ptests(struct ptest_list *head, const struct
ptest_options opts,
close(pipefd_stdout[1]);
break;
}
-
fprintf(fp, "START: %s\n", progname);
PTEST_LIST_ITERATE_START(head, p);
char *ptest_dir = strdup(p->run_ptest);
@@ -388,6 +441,13 @@ run_ptests(struct ptest_list *head, const struct
ptest_options opts,
break;
}
dirname(ptest_dir);
+ if (ioctl(0, TIOCNOTTY) == -1) {
+ fprintf(fp, "ERROR: Unable to detach from
controlling tty, %s\n", strerror(errno));
+ }
+
+ if ((pgid = getpgid(0)) == -1) {
+ fprintf(fp, "ERROR: getpgid() failed, %s\
Re: [yocto] [meta-oe][PATCH] utils.c: close all file descriptors after completing a ptest
Thanks Sakib.
Next time please use --prefix to add the ptest-runner tag:
so you'll have a subject line like:
[meta-oe][ptest-runner] utils.c: close all file descriptors after
completing a ptest
The subject line is wrongg since we are closing the fds
*before* the tests. Resend with something like:
utils.c: close all fds in child for each ptest
Wait to see if Anibal has any comment then send a v2
with a 'v2' prefix in the subject like:
[yocto] [ptest-runner][PATCHv2 1/3] Makefile: libcheck now requires
to link subunit
Thanks,
../Randy
On 5/31/19 1:44 PM, Sakib Sajal wrote:
vredir ptest fails since too many file descriptors were open.
From the failed ptest log:
run-vredir
87,88c87,88
< ./vredir6.sub: line 10: /dev/null: Too many open files
< ./vredir6.sub: line 13: /dev/null: Too many open files
FAIL: run-vredir
Added function to close file descriptors before starting a new process.
Signed-off-by: Sakib Sajal
Signed-off-by: Randy Macleod
---
utils.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/utils.c b/utils.c
index 504df0b..05c2bfe 100644
--- a/utils.c
+++ b/utils.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -240,6 +241,23 @@ filter_ptests(struct ptest_list *head, char **ptests, int
ptest_num)
return head_new;
}
+/* Close all fds from 3 up to 'ulimit -n'
+ * i.e. do not close STDIN, STDOUT, STDERR.
+ * Typically called in in a child process after forking
+ * but before exec as a good policy especially for security.
+ */
+static void
+close_fds(void)
+{
+ struct rlimit curr_lim;
+ getrlimit(RLIMIT_NOFILE, _lim);
+
+ int fd;
+ for (fd=3; fd < curr_lim.rlim_cur; fd++) {
+ (void) close(fd);
+ }
+}
+
static inline void
run_child(char *run_ptest, int fd_stdout, int fd_stderr)
{
@@ -252,6 +270,7 @@ run_child(char *run_ptest, int fd_stdout, int fd_stderr)
dup2(fd_stdout, STDOUT_FILENO);
// XXX: Redirect stderr to stdout to avoid buffer ordering problems.
dup2(fd_stdout, STDERR_FILENO);
+ close_fds();
execv(run_ptest, argv);
exit(1);
--
# Randy MacLeod
# Wind River Linux
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Incorporating Xilinx DNNDK into Yocto
On 5/3/19 7:36 PM, Khem Raj wrote: On Fri, May 3, 2019 at 2:09 PM Emily S wrote: Hi all - Xilinx has the Deep Neural Network Development Kit (DNNDK) that they just released the source code for in the last month or so. They have the code written nicely in the form of yocto recipes but it doesn't appear to be an actual layer: https://github.com/Xilinx/Edge-AI-Platform-Tutorials/tree/master/docs/DPU-Integration/reference-files/files . Is there a possibility of creating a layer for it? Or should I look into other options, like adding it as a submodule to my custom layer meta-l1calo: https://github.com/kratsg/meta-l1calo? Or if anyone has additional options, suggestions are appreciated! I think we need meta-ai or add to: https://github.com/nnsuite/meta-neural-network Is most of the code Xilinx HW specific? If so then a general layer may not be appropriate. ../Randy Thanks for the help! Emily -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- # Randy MacLeod # Wind River Linux -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH V2 0/2] update-rc.d: support enable/disable function
Add Ross and Phil who have been committers for update-rc.d. The changes seem sensible to me but the commit logs need some polish to be more clear. I'll help Sandy with that later if needed. ../Randy On 1/21/19 4:09 AM, changqing...@windriver.com wrote: These three patches are for support disable/enable function for update-rc.d change in V2: add some comments and fix commit message change in V1: * change of script update-rc.d is for support disable/enable of init script link * update-rc.d.bbclass remove preinst to make disable/enable can work after upgrade * fix the doc manual Changqing Li (2): update-rc.d.bbclass: remove preinst and remove -f for postinst ref-variables.xml: update manual page for update-rc.d documentation/ref-manual/ref-variables.xml | 2 +- meta/classes/update-rc.d.bbclass | 28 2 files changed, 5 insertions(+), 25 deletions(-) -- # Randy MacLeod # Wind River Linux -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Removing busybox
On 2/27/19 9:19 PM, Adrian Bunk wrote: On Wed, Feb 27, 2019 at 11:59:42PM +, Burton, Ross wrote: On Wed, 27 Feb 2019 at 23:55, Tom Rini wrote: My current incomplete list is: bind-utils \ bridge-utils \ coreutils \ dnsmasq \ e2fsprogs \ e2fsprogs-resize2fs \ e2fsprogs-tune2fs \ findutils \ gawk \ grep \ inetutils-ping \ inetutils-ping6 \ inetutils-traceroute \ iproute2 \ less \ net-tools \ parted \ pciutils \ procps \ sed \ util-linux \ vim \ which \ And it's also incomplete as there's more stuff under inetutils I don't need (but others may), and I set aside patch/diff/ed and some other stuff I don't need. And since some of that stuff comes from meta-openembedded, it's indeed really not clear how/where a packagegroup would reside as we need things out of meta-networking. That's a good start. For a oe-core packagegroup Rather than just a single list per layer, we could do something similar to: https://github.com/WindRiver-Labs/wrlinux/blob/WRLINUX_10_17_BASE/wrlinux-distro/recipes-base/images/wrlinux-image-glibc-core.bb where we defined an image called 'glibc-core' that tries to be a close to a minimal set of discrete apps needed to boot to a command line. Then we provide 10+ package groups that added a (mostly!) logical set of packages that provide groups of functionality. The groups and not perfect of course but the ones that we came up with 5+ years ago are: https://github.com/WindRiver-Labs/wrlinux/tree/WRLINUX_10_18_BASE/wrlinux-distro/recipes-base/packagegroups For qemux86-64, our images (years old data) vary from: Image NameSize (MB)Comment ====== glibc-tiny 6+Trimmed down glibc/busybox/minimal init glibc-small 50 A standard busybox with sysvint, rsyslog glibc-core 65 A minimal non-busybox image with sysvinit, rsyslog glibc-std 350 A more complete non-busybox image with packages that are present for historical reasons. We also have a WR specific template scheme that lets users add blocks of functionality (single or multiple packages, kernel configs) to the images above. I think MarkH has explained that to people before. Anyway, I'm certainly not suggesting that Yocto would want to adopt any of this directly but rather I'm just trying to give an impression of what we use and find useful when contructing non-busybox based images. I could revisit the Wind River image definitions and see if the lists we came up with years ago could be tweaked, renamed and added to oe-core and meta-oe to share this approach with other Yocto developers and users for the an upcoming release, maybe even for 2.8 if people are interested. I guess the question is if we want to spend time coming to an agreement on, testing and maintain these package groups and if they would really be useful to users since, historically at least, people who create images tend to be domain experts who can easily write their own packagegroup file. ../Randy I do not think a core-only packagegroup makes sense when the goal is to completely replace busybox (and not just most apps while keeping a few busybox apps installed). I'd suggest dropping dnsmasq bridgeutils bindutils to keep it lean. The stated usecases are not "lean" but "replace all busybox commands with the full versions". For that you need bind-utils (in oe-core) for DNS lookup. ... Also swap vim for something in core obviously. It is not obvious how to do that. What other vi implementation is in core? Is there even any good non-busybox non-GUI editor in core? Replacing busybox vi with ed would be a bad fit for the stated usecases. There has to be some vi implementation installed, and the "desktop command" implementation is vim. Ross cu Adrian -- # Randy MacLeod # Wind River Linux -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Opusenc e shout2
On 2/14/19 7:43 AM, Leonardo Jose Duarte MendesJunior wrote: Good morning, I'm compiling the gstreamer1.0 and its plugins, but the plugins: opusenc Seems to be a PACKAGECONIFG: $ grep opus meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-*bb meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.14.4.bb:# the opus encoder/decoder elements are now in the -base package, meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.14.4.bb:# but the opus parser remains in -bad meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-bad_1.14.4.bb:PACKAGECONFIG[opusparse] = "--enable-opus,--disable-opus,libopus" meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.14.4.bb:PACKAGECONFIG[opus] = "--enable-opus,--disable-opus,libopus" and shout2send That's disabled: $ grep shout meta/recipes-multimedia/gstreamer/gstreamer1.0-plugins-good_1.14.4.bb --disable-shout2 \ You'll have to work on understanding why it was disabled and send a patch to fix it. ../Randy are not found in the image. Any idea what can it be?How can I solve this? Thanks. -- # Randy MacLeod # Wind River Linux -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Using SDK/ESDK to build images
On 2/12/19 6:55 AM, Kristupas Savickas wrote: Hi, we're looking into providing our customers with SDK/ESDK packages to develop custom solutions on our boards. We don't want to provide the whole project itself as it would leak our intellectual property, so precompiled packages are a must. Looking around, it seems like both SDK and ESDK are suited to build single packages, rather than complete images. Am I correct about this? Yes. Is there some kind of method to allow images be built using SDK packages? No, or none that I'm aware of at least. My assumption has been that you either: 1. enable package management in the image and then add the app developed with the eSDK using dnf/rpm or other pkgs mgmt tools or 2. you develop the app using the eSDK then bring it into the build system as a released/tagged entity (tarball/git) and build your image. I suppose you could create another mechanism where you apply the app on top of the image or in another partition. Maybe someone here has done that or has more experience with your situation. Oh, an obvious mechanism would be as an app container using for example OverC: https://github.com/OverC/meta-overc https://github.com/OverC/meta-overc/blob/master/docs/README.c3_app_container -- # Randy MacLeod # Wind River Linux -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] DEVTOOL doesn't upgrade glibc as expected
Adding the list back. On 1/31/19 12:56 PM, Dhanush K.S wrote: Hi Randy, (back from vacation). No. Not actually, as we upgraded to Sumo recently and would probably jump straight to Warrior if need be. Warrior is still in development so keep that in mind. Wanted to get the time_t functionality for 32 bit arch due to the current Y2038 bug. But it seems like GNU has postponed it to future release. As you can see be reading the Jan 2019 article: https://lwn.net/Articles/776435/ the Linux Y2038 work is ongoing. Even once it's 'finished', it's unlikely that you won't have to upgrade your deployed systems to fix one or two defects so I'm confused about why you seem need/want this right now rather than in months or a year or more. Yeah! Would agree with having a combo that no one probably would be having. But what I don't get is why the incompatibility with of v2.28 with Yocto 2.5? Is it inherent with all yocto releases or something to do just with sumo? I don't work on the glibc upgrades so I'm not sure. There's nothing unique going on in Yocto but rather changing glibc versions is often lots of work that requires both broad and deep OS knowledge. ../Randy Look forward to your views on this. Thanks! On Wed, 30 Jan 2019 at 21:10, Randy MacLeod <mailto:randy.macl...@windriver.com>> wrote: On 1/30/19 8:42 AM, Burton, Ross wrote: > No doubt devtool should handle this better, but upgrading glibc is > *not easy*. If you can't do it manually then I wouldn't recommend > doing it at all. > > A better start would be to copy the recipes from git for the version > you want, and then you'll be able to pick up all of the patches to > other recipes that you'll also need. Have you seriously considered upgrading to Thud/2.6.x? What feature(s) do you want that makes you feel that an upgrade it to v2.28 is worth the effort? If you put the work in to do the update, you'll have a YP-based combo that no one else is using. While that may get you exactly what you want, there will be costs involved in maintaining it so I'm curious about your motivation and thoughts about maintenance. ../Randy > > Ross > > On Wed, 30 Jan 2019 at 13:35, Dhanush K.S mailto:dhanush...@gmail.com>> wrote: >> >> Hi, >> >> I'm currently using Yocto Sumo 2.5 release with the glibc version 2.27 and would like to upgrade it to v2.28. >> Using the devtool upgrade glibc -V 2.28 -S 044c96f0d5595aeb0bb4e79355081c5a7f4faca5 doesn't work as expected. >> In turn it creates the workspace/recipes/glibc_2.28.bb <http://glibc_2.28.bb> recipe with the contents and SRC_URI of v2.27. >> >> devtool upgrade glibc -S 044c96f0d5595aeb0bb4e79355081c5a7f4faca5 >> NOTE: Starting bitbake server... >> NOTE: Creating workspace layer in /source/yocto/build_arm-cortex-a8/workspace >> >> NOTE: Extracting current version source... >> NOTE: Resolving any missing task queue dependencies >> >> Build Configuration: >> BB_VERSION = "1.37.0" >> BUILD_SYS = "x86_64-linux" >> NATIVELSBSTRING = "universal-4.8" >> TARGET_SYS = "arm-poky-linux-gnueabi" >> MACHINE = "arm-cortex-a8" >> DISTRO = "poky" >> DISTRO_VERSION = "2.5" >> TUNE_FEATURES = "arm armv7a vfp neon callconvention-hard cortexa8" >> TARGET_FPU = "hard" >> meta >> meta-poky >> meta-yocto-bsp >> meta-oe = "master:45ee3c0e98bd3ed81419aaeae1e7324e486161a2" >> workspace = ":" >> >> NOTE: Executing RunQueue Tasks >> NOTE: Tasks Summary: Attempted 3 tasks of which 0 didn't need to be rerun and all succeeded. >> NOTE: Writing buildhistory >> NOTE: Adding local source files to srctree... >> NOTE: Extracting upgraded version source... >> WARNING: Command 'git rebase 044c96f0d5595aeb0bb4e79355081c5a7f4faca5' failed: >> First, rewinding head to replay your work on top of it... >> Applying: sparc: Check PIC instead of SHARED in start.S [BZ #22638] >> error: Failed to merge in the changes. >> Using index info to reconstruct a base tree... >> M ChangeLog >> M sysdeps/sparc/sparc32/start.S >> M sysdeps/sparc/sparc64/start.S >> Falling back to patching base and 3-way merge... >> Auto-merging ChangeLog >> CONFLICT (content): Mer
Re: [yocto] DEVTOOL doesn't upgrade glibc as expected
On 1/30/19 8:42 AM, Burton, Ross wrote:
No doubt devtool should handle this better, but upgrading glibc is
*not easy*. If you can't do it manually then I wouldn't recommend
doing it at all.
A better start would be to copy the recipes from git for the version
you want, and then you'll be able to pick up all of the patches to
other recipes that you'll also need.
Have you seriously considered upgrading to Thud/2.6.x?
What feature(s) do you want that makes you feel that an
upgrade it to v2.28 is worth the effort? If you put the
work in to do the update, you'll have a YP-based combo that
no one else is using. While that may get you exactly what you want,
there will be costs involved in maintaining it so I'm curious
about your motivation and thoughts about maintenance.
../Randy
Ross
On Wed, 30 Jan 2019 at 13:35, Dhanush K.S wrote:
Hi,
I'm currently using Yocto Sumo 2.5 release with the glibc version 2.27 and
would like to upgrade it to v2.28.
Using the devtool upgrade glibc -V 2.28 -S
044c96f0d5595aeb0bb4e79355081c5a7f4faca5 doesn't work as expected.
In turn it creates the workspace/recipes/glibc_2.28.bb recipe with the contents
and SRC_URI of v2.27.
devtool upgrade glibc -S 044c96f0d5595aeb0bb4e79355081c5a7f4faca5
NOTE: Starting bitbake server...
NOTE: Creating workspace layer in /source/yocto/build_arm-cortex-a8/workspace
NOTE: Extracting current version source...
NOTE: Resolving any missing task queue dependencies
Build Configuration:
BB_VERSION = "1.37.0"
BUILD_SYS= "x86_64-linux"
NATIVELSBSTRING = "universal-4.8"
TARGET_SYS = "arm-poky-linux-gnueabi"
MACHINE = "arm-cortex-a8"
DISTRO = "poky"
DISTRO_VERSION = "2.5"
TUNE_FEATURES= "arm armv7a vfp neon callconvention-hard cortexa8"
TARGET_FPU = "hard"
meta
meta-poky
meta-yocto-bsp
meta-oe = "master:45ee3c0e98bd3ed81419aaeae1e7324e486161a2"
workspace= ":"
NOTE: Executing RunQueue Tasks
NOTE: Tasks Summary: Attempted 3 tasks of which 0 didn't need to be rerun and
all succeeded.
NOTE: Writing buildhistory
NOTE: Adding local source files to srctree...
NOTE: Extracting upgraded version source...
WARNING: Command 'git rebase 044c96f0d5595aeb0bb4e79355081c5a7f4faca5' failed:
First, rewinding head to replay your work on top of it...
Applying: sparc: Check PIC instead of SHARED in start.S [BZ #22638]
error: Failed to merge in the changes.
Using index info to reconstruct a base tree...
M ChangeLog
M sysdeps/sparc/sparc32/start.S
M sysdeps/sparc/sparc64/start.S
Falling back to patching base and 3-way merge...
Auto-merging ChangeLog
CONFLICT (content): Merge conflict in ChangeLog
Patch failed at 0001 sparc: Check PIC instead of SHARED in start.S [BZ #22638]
The copy of the patch that failed is found in: .git/rebase-apply/patch
Resolve all conflicts manually, mark them as resolved with
"git add/rm ", then run "git rebase --continue".
You can instead skip this commit: run "git rebase --skip".
To abort and get back to the state before "git rebase", run "git rebase
--abort".
You will need to resolve conflicts in order to complete the upgrade.
Traceback (most recent call last):
File "/source/yocto/poky-sumo-19.0.0/scripts/devtool", line 344, in
ret = main()
File "/source/yocto/poky-sumo-19.0.0/scripts/devtool", line 331, in main
ret = args.func(args, config, basepath, workspace)
File "/source/yocto/poky-sumo-19.0.0/scripts/lib/devtool/upgrade.py", line
559, in upgrade
rf, copied = _create_new_recipe(args.version, md5, sha256, args.srcrev,
srcbranch, srcsubdir1, srcsubdir2, config.workspace_path, tinfoil, rd,
license_diff, new_licenses)
File "/source/yocto/poky-sumo-19.0.0/scripts/lib/devtool/upgrade.py", line
344, in _create_new_recipe
scheme, network, path, user, passwd, params = bb.fetch2.decodeurl(entry)
File "/source/yocto/poky-sumo-19.0.0/bitbake/lib/bb/fetch2/__init__.py",
line 368, in decodeurl
raise MalformedUrl(url)
bb.fetch2.MalformedUrl: The URL:
'${GLIBC_GIT_URI};branch=${SRCBRANCH};name=glibc' is invalid and cannot be
interpreted.
Need help with this one.
Thanks,
Dhanush
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
--
# Randy MacLeod
# Wind River Linux
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH V2] patchwork: Add a dockerfile for deploy patchwork and patchtest
opt/patchwork' + +(cd $pw_dir; ./manage.py createsuperuser) diff --git a/scripts/pw_getmail.sh b/scripts/pw_getmail.sh new file mode 100755 index 000..fadf7c9 --- /dev/null +++ b/scripts/pw_getmail.sh @@ -0,0 +1,11 @@ +#!/bin/bash + +sudo /etc/init.d/cron start +echo "*/5 * * * * sudo getmail --getmaildir=/opt/getmail/ --idle INBOX >> /opt/pw-test-cron/getmail.log 2>&1" > /opt/pw-test-cron/cron-getmail +sudo crontab -u wrlbuild /opt/pw-test-cron/cron-getmail + +while true +do + : +done + diff --git a/scripts/pw_migrate.sh b/scripts/pw_migrate.sh new file mode 100755 index 000..e54b2f4 --- /dev/null +++ b/scripts/pw_migrate.sh @@ -0,0 +1,5 @@ +#!/bin/bash + +pw_dir="/opt/patchwork" + +(cd $pw_dir; ./manage.py migrate; ./manage.py collectstatic; ./manage.py loaddata default_tags default_states default_events) diff --git a/scripts/pw_runwebserver.sh b/scripts/pw_runwebserver.sh new file mode 100755 index 000..4233b1a --- /dev/null +++ b/scripts/pw_runwebserver.sh @@ -0,0 +1,12 @@ +#!/bin/bash + +export LANG="en_US.UTF-8" +export LC_ALL="en_US.UTF-8" + +#open crontab to do test +/etc/init.d/cron start +crontab -u pwtest /opt/pw-test-cron/crontab + +pw_dir="/opt/patchwork" + +(cd $pw_dir; ./manage.py runserver 0.0.0.0:8080) -- # Randy MacLeod # Wind River Linux -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto Project support for Numeric/Scientific Python
On 1/23/19 4:28 PM, Randy MacLeod wrote: It a reasonable list for general discussion. If you get to a point where patches are being submitted, it should probably go to another list such as: oops... such as the meta-openembedded list: openembedded-de...@lists.openembedded.org or whatever list the package(s) land in. -- # Randy MacLeod # Wind River Linux -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto Project support for Numeric/Scientific Python
On 1/23/19 2:54 PM, Smith, Virgil (US) wrote: Is there a current or relatively recent recipe for SciPy and related libraries? People have worked on it at least once before but found some problems with blas and atlas: https://lists.yoctoproject.org/pipermail/yocto/2018-March/thread.html#40348 I'd say that there is interest. I CCed Peter who started one of the threads and BCCed 5 other people who seemed to be interested since I didn't want to drag them all into the thread. Further and more importantly, is having a maintainer for (recipes for) those libraries a priority for the active members of the Project? (i.e. does interest rise above the general welcoming of participants to periodically asking “Hey has anyone put out a call to fill this slot?” if/when the slot is vacant). It's always nice to have a maintainer but community members sometimes keep recipes up to date even if they aren't direct users. BTW: If this is the wrong list for this query, please let me know. It a reasonable list for general discussion. If you get to a point where patches are being submitted, it should probably go to another list such as: Why? We are trying to gauge community interest before making long term plans. We would like to know if this horse is at all likely to have healthcare before betting on it (without sacrificing other patients to obtain the proper veterinary degree and keep up practice to treat it ourselves). heh. Thanks! ../Randy NOTE: I see from the RRS emails that Derek Straka is currently maintaining the python-numpy recipe. THANK YOU! Notice to recipient: This email is meant for only the intended recipient of the transmission, and may be a communication privileged by law, subject to export control restrictions or that otherwise contains proprietary information. If you receive this email by mistake, please notify us immediately by replying to this message and then destroy it and do not review, disclose, copy or distribute it. Thank you in advance for your cooperation. -- # Randy MacLeod # Wind River Linux -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Boost recipe compilation failure in Yocto 2.6 with GCC 8.2
On 1/17/19 7:42 AM, Amol Lad wrote:
Hi,
Boost recipe compilation fails with below error. Build is okay if
“GCCVERSION = “7.%”. Please advise what might be wrong?
{standard input}: Assembler messages:
{standard input}:7896: Warning: end of file not at end of a line;
newline inserted
{standard input}:9139: Error: unknown pseudo-op: `.cfi_r'
{standard input}: Error: open CFI at the end of file; missing
.cfi_endproc directive
arm-next-linux-gnueabi-g++: fatal error: Killed signal terminated
program cc1plus
compilation terminated.
Details:
Build Configuration:
BB_VERSION = "1.40.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "universal"
TARGET_SYS = "arm-next-linux-gnueabi"
MACHINE = "clearfog"
DISTRO = "next"
DISTRO_VERSION = "1.0"
TUNE_FEATURES = "arm armv7a vfp neon callconvention-hard"
TARGET_FPU = "hard"
meta
meta-poky
meta-yocto-bsp =
"my-yocto-2.6:84eecb017ef92ef36b4df730908828e54aeff85c"
meta-oe
..
Detailed log:
"arm-next-linux-gnueabi-g++" "-march=armv7-a" "-mfpu=neon"
"-mfloat-abi=hard" "-Wl,-O1" "-Wl,--hash-style=gnu" "-Wl,--as-needed"
"--sysroot=/home/alad/yocto/poky/build/tmp/work/armv7ahf-neon-next-linux-gnueabi/boost/1.68.0-r0/recipe-sysroot"
-O2 -pipe -g -feliminate-unused-debug-types
-fdebug-prefix-map=/home/alad/yocto/poky/build/tmp/work/armv7ahf-neon-next-linux-gnueabi/boost/1.68.0-r0=/usr/src/debug/boost/1.68.0-r0
-fdebug-prefix-map=/home/alad/yocto/poky/build/tmp/work/armv7ahf-neon-next-linux-gnueabi/boost/1.68.0-r0/recipe-sysroot=
-fdebug-prefix-map=/home/alad/yocto/poky/build/tmp/work/armv7ahf-neon-next-linux-gnueabi/boost/1.68.0-r0/recipe-sysroot-native=
-fvisibility-inlines-hidden -pthread -O3 -finline-functions -Wno-inline
-Wall -fno-strict-aliasing -ftemplate-depth-1024 -fvisibility=hidden
-DBOOST_ALL_NO_LIB=1 -DBOOST_ATOMIC_STATIC_LINK=1
-DBOOST_CHRONO_STATIC_LINK=1 -DBOOST_FILESYSTEM_STATIC_LINK=1
-DBOOST_LOG_BUILDING_THE_LIB=1 -DBOOST_LOG_HAS_PTHREAD_MUTEX_ROBUST
-DBOOST_LOG_USE_NATIVE_SYSLOG -DBOOST_LOG_WITHOUT_DEBUG_OUTPUT
-DBOOST_LOG_WITHOUT_EVENT_LOG -DBOOST_SPIRIT_USE_PHOENIX_V3=1
-DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_SYSTEM_STATIC_LINK=1
-DBOOST_THREAD_BUILD_LIB=1 -DBOOST_THREAD_DONT_USE_CHRONO=1
-DBOOST_THREAD_POSIX -DBOOST_THREAD_USE_LIB=1 -DDATE_TIME_INLINE
-DNDEBUG -D_XOPEN_SOURCE=600 -D__STDC_CONSTANT_MACROS -I"."
-I"libs/log/src" -c -o
"/home/alad/yocto/poky/build/tmp/work/armv7ahf-neon-next-linux-gnueabi/boost/1.68.0-r0/boost_1_68_0/arm-next-linux-gnueabi/boost/bin.v2/libs/log/build/581af9cf1e4e5052d9f06634cc376f39/core.o"
"libs/log/src/core.cpp"
{standard input}: Assembler messages:
{standard input}:7896: Warning: end of file not at end of a line;
newline inserted
{standard input}:9139: Error: unknown pseudo-op: `.cfi_r'
{standard input}: Error: open CFI at the end of file; missing
.cfi_endproc directive
arm-next-linux-gnueabi-g++: fatal error: Killed signal terminated
program cc1plus
compilation terminated.
It almost looks like an internal compiler error but not quite
since at least until recently, any time the compiler
died, it would produce and log that included the
"internal compiler error"
string like this one:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57872
and I don't see that here... hmmm.
Are you able to reproduce it consistently?
How about on another computer?
I checked out your poky commit and built boost for
qemuarm:
TUNE_FEATURES = "arm armv7a vfp neon callconvention-hard cortexa8"
and it build without error.
If it's reproducible, can you try to reduce the code that
causes the problem?
https://www.gnu.org/software/gcc/bugs/minimize.html
../Randy
gcc.compile.c++
/home/alad/yocto/poky/build/tmp/work/armv7ahf-neon-next-linux-gnueabi/boost/1.68.0-r0/boost_1_68_0/arm-next-linux-gnueabi/boost/bin.v2/libs/log/build/581af9cf1e4e5052d9f06634cc376f39/process_name.o
--
# Randy MacLeod
# Wind River Linux
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Firewalld failing to build
On 1/16/19 12:47 AM, Sam Zeter wrote: Hello all, I've been attempting to build firewalld by adding it through 'devtool add ' and then 'devtool build firewalld'. However, I am stuck with the following errors. I have no idea what could be causing this. Could someone please help? xsltproc -o ../html/firewall-cmd.html --nonet --xinclude transform-html.xsl firewall-cmd.xml | xsltproc -o ../html/firewalld.dbus.html --nonet --xinclude transform-html.xsl ../../../../../../../../workspace/sources/firewalld/doc/xml/firewalld.dbus.xml | xsltproc -o ../html/firewalld.conf.html --nonet --xinclude transform-html.xsl ../../../../../../../../workspace/sources/firewalld/doc/xml/firewalld.conf.xml | xsltproc -o ../html/firewalld.html --nonet --xinclude transform-html.xsl firewalld.xml | 134 translated messages, 281 untranslated messages. | bn_IN: 293 translated messages, 122 untranslated messages. | ca: 415 translated messages. | cs: 415 translated messages. | da: warning: failed to load external entity "authors.xml" | firewall-cmd.xml:36: parser error : Failure to process entity authors | | ^ | firewall-cmd.xml:36: parser error : Entity 'authors' not defined | | ^ | warning: failed to load external entity "seealso.xml" | firewall-cmd.xml:2297: parser error : Failure to process entity seealso | | ^ | firewall-cmd.xml:2297: parser error : Entity 'seealso' not defined | Thanks Sam. Hi Sam, Can you post your recipe? Do you have all the dependencies listed on: https://github.com/firewalld/firewalld What branch & commit are you based on? When we looked at adding a firewalld recipe 3+ years ago it didn't work out since the package wasn't cross-compile friendly but things have changed since then so I'm looking forward to see what can be achieved. -- # Randy MacLeod # Wind River Linux -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Qemu Launch Issue:
On 1/15/19 5:54 AM, sadu A wrote: Hi Team, I'm new to yocto environment, I need clarification on this: Launching Qemu default and launching by using "-nographic" option makes any difference. Please clarify this. Using: $ runqemu nographic is useful when you have logged into a server and you don't want to allow X11 forwarding to your workstation/laptop. See: google: qemu nographic for example: https://serverfault.com/questions/471719/how-to-start-qemu-directly-in-the-console-not-in-curses-or-sdl for details. ../Randy Regards, Kumar -- # Randy MacLeod # Wind River Linux -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto distribution license
On 1/14/19 5:42 AM, Burton, Ross wrote: The license is the sum of the parts. Ross +1 It would be possible that the build system would attempt to restrict usage but bitbake is GPLv2 licensed and oe-core classes and recipes are mostly under MIT as explained here: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/LICENSE ../Randy On Mon, 14 Jan 2019 at 06:35, Edward Wingate <mailto:edwinga...@gmail.com>> wrote: I understand that a Linux distribution created with Yocto is composed of various packages, each with their own license, and the obligations of the licenses must be met. But are there any restrictions/obligations on the distribution itself when created with Yocto? Or is the license of a Linux distribution created by Yocto determined by whoever created it? -- ___ yocto mailing list yocto@yoctoproject.org <mailto:yocto@yoctoproject.org> https://lists.yoctoproject.org/listinfo/yocto -- # Randy MacLeod # Wind River Linux -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Notes: Yocto Project Technical Team Meeting @ Tue Jan 8, 2019 8am - 8:30am (PST)
On 1/8/19 1:03 PM, Manjukumar Harthikote Matha wrote: Hi -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Jolley, Stephen K Sent: Tuesday, January 08, 2019 8:29 AM To: yocto@yoctoproject.org Subject: [yocto] Notes: Yocto Project Technical Team Meeting @ Tue Jan 8, 2019 8am - 8:30am (PST) Attendees: Stephen, Armin, Alex, Richard G., Joshua W., Richard. P., Randy, Ross, Trevor, Jon, Lewis, Jesse, Tim, Matt, Tracey, YP Status: See - https://wiki.yoctoproject.org/wiki/Weekly_Status <https://wiki.yoctoproject.org/wiki/Weekly_Status> * YP 2.7 M1 is out of QA and being prepared for release. * YP 2.5.2 was released on Jan. 4, 2019. * YP 2.6.1 should build soon. * YP 2.7 M2 is targeted for build Jan. 21, 2019. Richard and Stephen discussed QA status and plans for YP 2.6.1. We will still do some manual QA work in Q1’19 but plan to automate QA before the end of Q1’19. Joshua discussed the hash work on sstate. It has merged for M2. Discussed how build history use of hashes needs some updates to improve reproducibility. Trevor asked about the Weekly status report meetings. These are where the weekly status report is written and while all are welcome to attend, no one but Stephen and Richard are required. Trevor discussed that YP is dropping support for some old ARM targets, since they are being dropped from gcc. Richard asked about incremental image packaging. Randy commented that WRS is using this feature for RPM. This is something that we are looking for, can you provide more details on the current implementation? Hongxu implemented it: http://git.openembedded.org/openembedded-core/commit/?id=b3eeb0edf3f so maybe he or Mark can comment. ../Randy Thanks, Manju -- # Randy MacLeod # Wind River Linux -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] QA cycle report for 2.6 M4 RC1
On 11/10/18 11:25 AM, richard.pur...@linuxfoundation.org wrote: On Fri, 2018-11-09 at 09:24 +, Jain, Sangeeta wrote: This is the full report for 2.6 M4 RC1: https://wiki.yoctoproject.org/wiki/WW44_-_2018-10-30_-_Full_Test_Cycle_2.6_M4_RC1 Thanks Sangeeta and team! Now we have the QA report for YP 2.6 M4 rc1 (Final 2.6) we need to make a release go or nogo decision. To do this we have the following: QA Report: https://wiki.yoctoproject.org/wiki/WW44_-_2018-10-30_-_Full_Test_Cycle_2.6_M4_RC1 Release Criteria: https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.6_Status#Milestone_4.2FFinal_-_Target_Oct._26.2C_2018 We'd be happy to take representations from members and the community to help reach that decision. My personal view is that whilst there are a number of issues present in rc1, we should release it, collect up fixes on the thud branch (aleady happening) and plan on a 2.6.1 as soon as it looks like we have enough critical mass behind those as opposed to an rc2 and further delays to the release. Despite the fact that there are a few release criteria that are not in the 'Done' state yet, I approve of releasing YP-2.6M4 on the condition that the Docs and Web site criteria are taken care of before release. I have reviewed the open bugs. Several are resolved or will be soon and the ones that remain appear to be either limited in impact such as 12974/systemtap or are likely due to builder problems such as 12991/webkitgtk on the build appliance. Build time tests have crept up somewhat for the rootfs and eSDK tests but not so dramatically that I would suggest blocking GA. We haven't had anyone investigate the root cause yet AFAIK but that can happen post-release and noted in the release notes. The package update status is unknown due to the tracker being down but in M3 we were at 81% done so we're still in a good albeit unquantified state. What are the plans for the Documentation checks and Wiki/Web site update? That needs to be 'Done' but I expect it will be taken care of in the coming days. ../Randy Cheers, Richard -- # Randy MacLeod # Wind River Linux -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to request a certain version of a recipes for an image?
On 11/4/18 11:55 AM, Patrick Boettcher wrote: Hi list, I'm using the morty-release for my device. My sources consists of different layers. Some application specific-layers (which contains a image-recipe), our BSP-provider and tooling-layers. It now happens that in there is package (dt-utils) which has recipes in two different layers, with different versions. In my image-file I request the package via IMAGE_INSTALL += "dt-utils" How do I force the version of dt-utils for this image? By default it selects the wrong one. Here's what I tried, by adding to the image-recipe: DEPENDS += "dt-utils (>= 2017.03.0)" and RDEPENDS += "dt-utils (>= 2017.03.0)" seems to have no effect. Adding the version-logic to the IMAGE_INSTALL-line fails to build. What works is to add PREFERRED_VERSION to local.conf. But this is not committable, so I'd like to avoid it. Can't you use PREFERRED_VERSION and commit that in one of the layers that you control? eg: $ cd .../meta-virtualization.git $ grep -r PREFERRED_VERSION .| head -1 ./conf/distro/include/meta-virt-default-versions.inc:PREFERRED_VERSION_python-blinker = "1.3" ../Randy Thanks. best regards, -- Patrick. -- # Randy MacLeod # Wind River Linux -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] layers.openembedded.org upgraded
On 09/28/2018 03:22 PM, Randy MacLeod wrote:
On 09/27/2018 08:01 PM, Randy MacLeod wrote:
On 09/27/2018 07:33 PM, Paul Eggleton wrote:
Hi Randy
On Friday, 28 September 2018 11:22:29 AM NZST Randy MacLeod wrote:
On 09/27/2018 05:28 PM, Nicolas Dechesne wrote:
On Thu, Sep 27, 2018 at 10:43 PM Paul
Eggleton wrote:
I'm very happy to announce that we've finally been able to upgrade
the layer
index athttp://layers.openembedded.org to the latest revision on
master,
incorporating quite a bit of work that's been going on for the
past few
months. Improvements now visible:
Nice new features, thanks!
The "Branch:" and "Filter layers" selection menus don't work
for me when using Firefox 62.0 (64-bit) on Ubuntu-18.04.
Google Chrome Version 69.0.3497.100 (Official Build) (64-bit)
works fine.
Hmm, I do my development with Firefox and I just checked - with Firefox
62.0 (64-bit) here on Fedora 28 both work. Do you perhaps have an add-on
enabled that might prevent these from working? I believe they both
rely on
javascript (the filter dropdown definitely does).
Does anyone else see this problem?
I've also asked on IRC.
I did have Firefox Lightbeam (disabled) and Quiick Java but I removed
them both,
re-started FF and still no joy/menus.
One co-worker said that it works for him using
Firefox 62.0 (64-bit) on Ubuntu-18.04
he has uBlock and Ghostery
and another has no problems with the new code when using:
Firefox 52.8.0 (32-bit)
( 32 bit!! yikes! :) )
I've restarted FF again, cut back on the crazy number of tabs
and the problem persists. Let me know if you know of any other
sites that use this JS code and I'd be happy to test with my
setup. I'll likey also reboot (sigh) and if needed try using a
test account on the laptop.
It works for me now but it's not clear why. It seems that
it was a problem with my firefox profile.
Work log below in case it might help someone else.
../Randy
I rebooted:
- still no menu.
I logged out and then into another account on the same laptop:
- it worked.
I created another firefox profile in my usual account:
- it worked.
I deleted that profile and used my default profile:
- still no menu.
While visiting layers.openembedded.org, I opened the firefox
console using Shift+Control+K
- I re-loaded the site.
- it worked!
I closed the console:
- it worked!
I restarted firefox:
- it still works!
Hmmm, oh well.
../Randy
According my read of the traceback, the failing code is in:
view-source:https://layers.openembedded.org/static/js/jquery-3.3.1.js
...
Sizzle.matchesSelector = function( elem, expr ) {
// Set document vars if needed
if ( ( elem.ownerDocument || elem ) !== document ) {
setDocument( elem );
}
// Make sure that attribute selectors are quoted
expr = expr.replace( rattributeQuotes, "='$1']" );
if ( support.matchesSelector && documentIsHTML &&
!compilerCache[ expr + " " ] &&
( !rbuggyMatches || !rbuggyMatches.test( expr ) ) &&
( !rbuggyQSA || !rbuggyQSA.test( expr ) ) ) {
try {
var ret = matches.call( elem, expr );
// IE 9's matchesSelector returns false on disconnected nodes
if ( ret || support.disconnectedMatch ||
// As well, disconnected nodes are said to be in a
document
// fragment in IE 9
elem.document && elem.document.nodeType !== 11 ) {
return ret;
}
} catch (e) {}
}
return Sizzle( expr, document, null, [ elem ] ).length > 0;
};
I don't see any relevant issues here:
https://github.com/jquery/sizzle/issues/
but I don't speak javascript.
../Randy
Looking at:
Menu->Web Developer -> Browser Console ( Control+Shift+J )
I see:
Error: Syntax error, unrecognized expression: # jquery-3.3.1.js:1541:8
<https://layers.openembedded.org/static/js/jquery-3.3.1.js>
Sizzlehttps://layers.openembedded.org/static/js/jquery-3.3.1.js:1541:8
Sizzlehttps://layers.openembedded.org/static/js/jquery-3.3.1.js:2193:4
Sizzlehttps://layers.openembedded.org/static/js/jquery-3.3.1.js:2620:20
Sizzle https://layers.openembedded.org/static/js/jquery-3.3.1.js:845:9
find https://layers.openembedded.org/static/js/jquery-3.3.1.js:2873:4
jQuery.fn.init
https://layers.openembedded.org/static/js/jquery-3.3.1.js:2983:14
jQuery
https://layers.openembedded.org/static/js/jquery-3.3.1.js:139:10
getParent
https://layers.openembedded.org/static/js/bootstrap.js:754:27
clearMenus/<
https://layers.openembedded.org/static/js/bootstrap.js:741:7 each
https://layers.openembedded.org/static/js/jquery-3.3.1.js:354:10 each
https://layers.openembedded.org/static/js/jquery-3.3.1.js:189:10
clearMenus
https://layers.openembedded.org/static/js/bootstrap.js:740:5 dispatch
https://layers.openembedded.org/static/js/jquery-3.3.1.js:518
Re: [yocto] [OE-core] layers.openembedded.org upgraded
On 09/27/2018 08:01 PM, Randy MacLeod wrote:
On 09/27/2018 07:33 PM, Paul Eggleton wrote:
Hi Randy
On Friday, 28 September 2018 11:22:29 AM NZST Randy MacLeod wrote:
On 09/27/2018 05:28 PM, Nicolas Dechesne wrote:
On Thu, Sep 27, 2018 at 10:43 PM Paul Eggleton wrote:
I'm very happy to announce that we've finally been able to upgrade the layer
index athttp://layers.openembedded.org to the latest revision on master,
incorporating quite a bit of work that's been going on for the past few
months. Improvements now visible:
Nice new features, thanks!
The "Branch:" and "Filter layers" selection menus don't work
for me when using Firefox 62.0 (64-bit) on Ubuntu-18.04.
Google Chrome Version 69.0.3497.100 (Official Build) (64-bit)
works fine.
Hmm, I do my development with Firefox and I just checked - with Firefox
62.0 (64-bit) here on Fedora 28 both work. Do you perhaps have an add-on
enabled that might prevent these from working? I believe they both rely on
javascript (the filter dropdown definitely does).
Does anyone else see this problem?
I've also asked on IRC.
I did have Firefox Lightbeam (disabled) and Quiick Java but I removed
them both,
re-started FF and still no joy/menus.
One co-worker said that it works for him using
Firefox 62.0 (64-bit) on Ubuntu-18.04
he has uBlock and Ghostery
and another has no problems with the new code when using:
Firefox 52.8.0 (32-bit)
( 32 bit!! yikes! :) )
I've restarted FF again, cut back on the crazy number of tabs
and the problem persists. Let me know if you know of any other
sites that use this JS code and I'd be happy to test with my
setup. I'll likey also reboot (sigh) and if needed try using a
test account on the laptop.
According my read of the traceback, the failing code is in:
view-source:https://layers.openembedded.org/static/js/jquery-3.3.1.js
...
Sizzle.matchesSelector = function( elem, expr ) {
// Set document vars if needed
if ( ( elem.ownerDocument || elem ) !== document ) {
setDocument( elem );
}
// Make sure that attribute selectors are quoted
expr = expr.replace( rattributeQuotes, "='$1']" );
if ( support.matchesSelector && documentIsHTML &&
!compilerCache[ expr + " " ] &&
( !rbuggyMatches || !rbuggyMatches.test( expr ) ) &&
( !rbuggyQSA || !rbuggyQSA.test( expr ) ) ) {
try {
var ret = matches.call( elem, expr );
// IE 9's matchesSelector returns false on disconnected
nodes
if ( ret || support.disconnectedMatch ||
// As well, disconnected nodes are said
to be in a document
// fragment in IE 9
elem.document && elem.document.nodeType
!== 11 ) {
return ret;
}
} catch (e) {}
}
return Sizzle( expr, document, null, [ elem ] ).length > 0;
};
I don't see any relevant issues here:
https://github.com/jquery/sizzle/issues/
but I don't speak javascript.
../Randy
Looking at:
Menu->Web Developer -> Browser Console ( Control+Shift+J )
I see:
Error: Syntax error, unrecognized expression: # jquery-3.3.1.js:1541:8
<https://layers.openembedded.org/static/js/jquery-3.3.1.js>
Sizzlehttps://layers.openembedded.org/static/js/jquery-3.3.1.js:1541:8
Sizzlehttps://layers.openembedded.org/static/js/jquery-3.3.1.js:2193:4
Sizzlehttps://layers.openembedded.org/static/js/jquery-3.3.1.js:2620:20 Sizzle
https://layers.openembedded.org/static/js/jquery-3.3.1.js:845:9 find
https://layers.openembedded.org/static/js/jquery-3.3.1.js:2873:4
jQuery.fn.init
https://layers.openembedded.org/static/js/jquery-3.3.1.js:2983:14 jQuery
https://layers.openembedded.org/static/js/jquery-3.3.1.js:139:10
getParent https://layers.openembedded.org/static/js/bootstrap.js:754:27
clearMenus/<
https://layers.openembedded.org/static/js/bootstrap.js:741:7 each
https://layers.openembedded.org/static/js/jquery-3.3.1.js:354:10 each
https://layers.openembedded.org/static/js/jquery-3.3.1.js:189:10
clearMenus https://layers.openembedded.org/static/js/bootstrap.js:740:5
dispatch
https://layers.openembedded.org/static/js/jquery-3.3.1.js:5182:16
add/elemData.handle
https://layers.openembedded.org/static/js/jquery-3.3.1.js:4991:6
Does that help at all?
../Randy
Cheers,
Paul
--
# Randy MacLeod
# Wind River Linux
--
# Randy MacLeod
# Wind River Linux
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] layers.openembedded.org upgraded
On 09/27/2018 07:33 PM, Paul Eggleton wrote: Hi Randy On Friday, 28 September 2018 11:22:29 AM NZST Randy MacLeod wrote: On 09/27/2018 05:28 PM, Nicolas Dechesne wrote: On Thu, Sep 27, 2018 at 10:43 PM Paul Eggleton wrote: I'm very happy to announce that we've finally been able to upgrade the layer index at http://layers.openembedded.org to the latest revision on master, incorporating quite a bit of work that's been going on for the past few months. Improvements now visible: Nice new features, thanks! The "Branch:" and "Filter layers" selection menus don't work for me when using Firefox 62.0 (64-bit) on Ubuntu-18.04. Google Chrome Version 69.0.3497.100 (Official Build) (64-bit) works fine. Hmm, I do my development with Firefox and I just checked - with Firefox 62.0 (64-bit) here on Fedora 28 both work. Do you perhaps have an add-on enabled that might prevent these from working? I believe they both rely on javascript (the filter dropdown definitely does). Does anyone else see this problem? I've also asked on IRC. I did have Firefox Lightbeam (disabled) and Quiick Java but I removed them both, re-stared FF and still no joy/menus. Looking at: Menu->Web Developer -> Browser Console ( Control+Shift+J ) I see: Error: Syntax error, unrecognized expression: # jquery-3.3.1.js:1541:8 <https://layers.openembedded.org/static/js/jquery-3.3.1.js> Sizzlehttps://layers.openembedded.org/static/js/jquery-3.3.1.js:1541:8 Sizzlehttps://layers.openembedded.org/static/js/jquery-3.3.1.js:2193:4 Sizzlehttps://layers.openembedded.org/static/js/jquery-3.3.1.js:2620:20 Sizzle https://layers.openembedded.org/static/js/jquery-3.3.1.js:845:9 find https://layers.openembedded.org/static/js/jquery-3.3.1.js:2873:4 jQuery.fn.init https://layers.openembedded.org/static/js/jquery-3.3.1.js:2983:14 jQuery https://layers.openembedded.org/static/js/jquery-3.3.1.js:139:10 getParent https://layers.openembedded.org/static/js/bootstrap.js:754:27 clearMenus/< https://layers.openembedded.org/static/js/bootstrap.js:741:7 each https://layers.openembedded.org/static/js/jquery-3.3.1.js:354:10 each https://layers.openembedded.org/static/js/jquery-3.3.1.js:189:10 clearMenus https://layers.openembedded.org/static/js/bootstrap.js:740:5 dispatch https://layers.openembedded.org/static/js/jquery-3.3.1.js:5182:16 add/elemData.handle https://layers.openembedded.org/static/js/jquery-3.3.1.js:4991:6 Does that help at all? ../Randy Cheers, Paul -- # Randy MacLeod # Wind River Linux -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] layers.openembedded.org upgraded
On 09/27/2018 05:28 PM, Nicolas Dechesne wrote: On Thu, Sep 27, 2018 at 10:43 PM Paul Eggleton wrote: Hi all, >> I'm very happy to announce that we've finally been able to upgrade the layer index at http://layers.openembedded.org to the latest revision on master, incorporating quite a bit of work that's been going on for the past few months. Improvements now visible: Nice new features, thanks! The "Branch:" and "Filter layers" selection menus don't work for me when using Firefox 62.0 (64-bit) on Ubuntu-18.04. Google Chrome Version 69.0.3497.100 (Official Build) (64-bit) works fine. ../Randy * Patch tracking - each recipe detail page now lists any patches being applied by the recipe along with upstream status for each - see attached screenshot. You can click through to view/download the actual patch, and any URLs in the supplemental status text are also made into clickable links. * Source tracking - remote entries in SRC_URI are now listed on the recipe detail page and made into clickable links where possible - see attached screenshot * Link to inc files - there is now a link in the recipe detail page to any inc files that a recipe includes as long as they are in the same directory, as a shortcut to see the rest of the definitions for the recipe. * Recipe list CSV export - there is now an "Export CSV" button at the top of the recipe list on the layer detail page. This currently includes the recipe name and version - we could look at extending this, but note that the REST API provides access to all of the information programmatically and may be better suited for many applications that need this data. * Site-wide notice support - admins can now add notifications to appear at the top of the page across the entire site. This is useful in the case where there is some problem with the update process or maintenance is going on as happens from time to time. * Bootstrap 3 - the UI has been updated to use Bootstrap 3 from version 2 that we were using previously. This has made a fairly minor difference to the UI (padding/spacing/fonts have changed a little) but has allowed us to tidy up a few things in the code. * The "Base" layer type is no longer selectable for layer submissions. I noticed people sometimes selected this erroneously; it's only applicable for openembedded-core and meta-oe basically so that they show up at the top of the layer list. Only admins can now select this type for a layer. * Numerous other bugfixes, robustness improvements and code cleanups. Thanks very much to everyone who has contributed to the layer index code up to now (and to BitBake / tinfoil, which we rely upon to extract the information from the metadata), but I'd like to give particular thanks to Michael Halstead, Yi Zhao, Konrad Scherer, Robert Yang and Aníbal Limón for making this upgrade possible. Paul, and everyone above, many thanks for your contributions to the Layer Index which is definitely a great tool for our community! It encourages and simplifies reuse and sharing of all recipes! The update looks really good, and as Andreas says, the top #3 features will make a big difference. Also integrated were the Recipe Reporting System (RRS) which powers http://recipes.yoctoproject.org and other distro comparison support, but these will take a bit more time to properly enable so I'll send out a separate email with further details when they are ready. As always, please let me know if you have any comments or notice any issues. (I've already seen a few minor problems in the update logs so I'll be looking into those.) Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre-- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- # Randy MacLeod # Wind River Linux -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] liblzma: memory allocation failed
On 09/16/2018 04:40 PM, Peter Bergin wrote:
Hi,
during the task do_package_write_rpm I get the error "liblzma: Memory
allocation failed". It happens during packaging of binary RPM packages.
The root cause seems to be the host environment that is used in our
project. We run our builds on a big server with 32 cores and 256GB of
physical RAM but each user has a limit of virtual memory usage to 32GB
(ulimit -v). The packaging in rpm-native has been parallelized in the
commit
http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta/recipes-devtools/rpm?id=84e0bb8d936f1b9094c9d5a92825e9d22e1bc7e3.
What seems to happen is that rpm-native put up 32 parallel tasks with
'#pragma omp', each task is using liblzma that also put up 32 tasks for
#pragma omp
Tha'ts OpenMP, right? I haven't played with that at all but
it looks like you can limit the number of threads using an
environment variable:
OMP_NUM_THREADS num
https://www.openmp.org/wp-content/uploads/OpenMP3.0-SummarySpec.pdf
Doing that would be a little ugly but for now at least, there doesn't
seem to be that many packages using such a pragma.
Does that work for your case?
the compression work. The memory calculations in liblzma is based on the
amount of physical RAM but as the user is limited by 'ulimit -v' we get
into a OOM situation in liblzma.
Here is the code snippet from rpm-native/build/pack.c where it happens:
#pragma omp parallel
#pragma omp single
// re-declaring task variable is necessary, or older gcc versions
will produce code that segfaults
for (struct binaryPackageTaskData *task = tasks; task != NULL; task
= task->next) {
if (task != tasks)
#pragma omp task
{
task->result = packageBinary(spec, task->pkg, cookie,
cheating, &(task->filename), buildTime, buildHost);
rpmlog(RPMLOG_NOTICE, _("Finished binary package job,
result %d, filename %s\n"), task->result, task->filename);
}
}
Steps to reproduce is to set 'ulimit -v' in your shell to, for example,
1/8 of the amount of physical RAM and then build for example
glibc-locale. I have tested this with rocko. If the '#pragma omp'
statements in code snippet above is removed the problem is solved. But
that not good as the parallel processing speed up the process.
Is the host environment used here with restricted virtual memory
supported by Yocto? If it is, someone that have any suggestion for a
solution on this issue?
This is a little tricky.
From bitbake's point of view, it's almost like you are building
on a 32 core, 32 GB box and runing out of RAM/swap.
Clearly we would not fix a build that OOMs in that case
(it does seem odd that 32 GB isn't enough ...)
Are you sure that there isn't something else going on?
I have a 24 core machine with 64 GB RAM that never comes
close to such a problem (so I haven't paid attention to RAM usage).
../Randy
Best regards,
/Peter
--
# Randy MacLeod
# Wind River Linux
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Using Dropbear - Core Image Sato
On 09/06/2018 07:58 AM, Ayman Hassan wrote: Hello, I am part of a team based in Cairo, Egypt – working on a project and we’re still discovering Linux Features, I am currently running core-image-sato on a virtual box, Welcome to yocto. If you have access to IRC, you can join #oe on Freenode to ask for help as well. and trying to connect to SSH server using Dropbear – but it’s not working – I get connection refused message. I couldn’t find tutorials to know how I can fix the problem. Did you build your image for qemux86-64 instead and try to use runqemu? As shown on: https://www.yoctoproject.org/docs/current/brief-yoctoprojectqs/brief-yoctoprojectqs.html That's a more common use case than VirtualBox in the Yocto community. If you are determined to use VB: Did you manage to ssh into an ubuntu image as a test? If not, then you'll need VB docs not YP docs. If ubuntu in VB works for you, then what's your build environment, ssh client, and branch of yocto: https://wiki.yoctoproject.org/wiki/Releases ? ../Randy I would really much appreciate your help. Thank you, Ayman ABDELHAMID -- # Randy MacLeod # Wind River Linux -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Using Dropbear - Core Image Sato
On 09/06/2018 07:58 AM, Ayman Hassan wrote: Hello, I am part of a team based in Cairo, Egypt – working on a project and we’re still discovering Linux Features, I am currently running core-image-sato on a virtual box, Welcome to yocto. If you have access to IRC, you can join #oe on Freenode to ask for help as well. and trying to connect to SSH server using Dropbear – but it’s not working – I get connection refused message. I couldn’t find tutorials to know how I can fix the problem. Did you build your image for qemux86-64 instead and try to use runqemu? As shown on: https://www.yoctoproject.org/docs/current/brief-yoctoprojectqs/brief-yoctoprojectqs.html That's a more common use case than VirtualBox in the Yocto community. If you are determined to use VB: Did you manage to ssh into say and ubuntu image running there? If not, then you'll need VB docs not YP docs. If ubuntu works for you, then what's your build environment, ssh client, and branch of yocto: https://wiki.yoctoproject.org/wiki/Releases ? ../Randy I would really much appreciate your help. Thank you, Ayman ABDELHAMID -- # Randy MacLeod # Wind River Linux -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Using Dropbear - Core Image Sato
On 09/06/2018 07:58 AM, Ayman Hassan wrote: Hello, I am part of a team based in Cairo, Egypt – working on a project and we’re still discovering Linux Features, I am currently running core-image-sato on a virtual box, Welcome to yocto. If you have access to IRC, you can join #oe on Freenode to ask for help as well. and trying to connect to SSH server using Dropbear – but it’s not working – I get connection refused message. I couldn’t find tutorials to know how I can fix the problem. Did you build your image for qemux86-64 instead and try to use runqemu? As shown on: https://www.yoctoproject.org/docs/current/brief-yoctoprojectqs/brief-yoctoprojectqs.html That's a more common use case than VirtualBox in the Yocto community. If you are determined to use VB: Did you manage to ssh into say and ubuntu image running there? If not, then you'll need VB docs not YP docs. If ubuntu works for you, then what's your build environment, ssh client, and branch of yocto: https://wiki.yoctoproject.org/wiki/Releases ? ../Randy I would really much appreciate your help. Thank you, Ayman ABDELHAMID -- # Randy MacLeod # Wind River Linux -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Notes: Yocto Project Weekly Triage Meeting
On 09/13/2018 11:17 AM, Jolley, Stephen K wrote: Attendees: Stephen, Armin, Joshua, Amanda, Richard, Ross, Randy, Anuj, Wiki: _https://wiki.yoctoproject.org/wiki/Bug_Triage_ AR: Ross - Update _12921_ <https://bugzilla.yoctoproject.org/show_bug.cgi?id=12921> to NEEDINFO and add comment. AR: Armin – Create selftest bug for _12921_ <https://bugzilla.yoctoproject.org/show_bug.cgi?id=12921>. Discussed that we should expect M3 sometime next week. AR: Amanda – Check _12332_ <https://bugzilla.yoctoproject.org/show_bug.cgi?id=12332> to see if it can be closed. AR: Randy – Check _12774_ <https://bugzilla.yoctoproject.org/show_bug.cgi?id=12774> to see if it can be closed. AR: Stephen – Check with David if _12785_ <https://bugzilla.yoctoproject.org/show_bug.cgi?id=12785> and _12891_ <https://bugzilla.yoctoproject.org/show_bug.cgi?id=12891> will be closed in M3. Thanks, */Stephen K. Jolley/* *Yocto Project Program Manager* *INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124 * (*Cell*: (208) 244-4460 * *Email*: _stephen.k.jolley@intel.com_ This missed my email filters since I wasn't on the TO/CC list. I added people with an AR to the To: list since they may be in the same flooding even with filters email boat. Stephen, Can you please explicitly address anyone who has an AR next time? Thanks, -- # Randy MacLeod # Wind River Linux -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [yocto-builds] Newbe first build failure
t/projects/yacto/poky/build/tmp/work/all-poky-linux/iso-codes/3.77-r0/temp/log.do_fetch.19288 ERROR: Task (/home/scott/projects/yacto/poky/meta/recipes-support/iso-codes/iso-codes_3.77.bb:do_fetch) failed with exit code '1' NOTE: Tasks Summary: Attempted 1403 tasks of which 0 didn't need to be rerun and 1 failed. Summary: 1 task failed: /home/scott/projects/yacto/poky/meta/recipes-support/iso-codes/iso-codes_3.77.bb:do_fetch Summary: There were 6 WARNING messages shown. Summary: There were 3 ERROR messages shown, returning a non-zero exit code. -- # Randy MacLeod # Wind River Linux -- ___ 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
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
Re: [yocto] yocto jethro failed on gettext-native
On 2018-04-25 03:50 PM, Burton, Ross wrote: Jethro doesn't support Yocto 16.* because it is very old (released Err, Jethro doesn't support _Ubuntu_ 16.* (Yocto 16.* is a ways off! :) ) 2015, it's been unmaintained for six months now). If you want to use Jethro despite the known serious security problems then you'll need to dig out the relevant fixes from the newer releases. Can you use a later release of Yocto such as 2.4 or 2.5 aka rocko/sumo? If you need to use an older release there are companies, such as Wind River [1], that can provide commercial support for 5+ years after the Yocto release date. Send me an email off-list and I'll help you contact our sales people! :) ../Randy [1] https://www.yoctoproject.org/ecosystem/yocto-project-compatible-product-showcase/ This list is a bit out of date, we release WR Linux 10: LTS last fall. It's based on YP-2.4/rocko Ross On 25 April 2018 at 20:36, Oliver Graute <oliver.gra...@gmail.com> wrote: On 25/04/18, Zoran Stojsavljevic wrote: I try to compile yocto jethro environment which is working on a Ubuntu 14.04 installation. But not on a Kubuntu 16.04 . What would be the benefit for the successful compiling of YOCTO Jethro on Kubuntu 16.04 over Ubuntu 14.04??? I tried to get my Yocto compiled on a PC of a colleague and his installation was a Kubuntu 16.04. I've made the experience that often only additional packages needs to be installed to step over these compile issues. Sometimes its clear from the debug output but in this case I have no Idea which packages is missing. On my develop PC and our Buildserver with Ubuntu 14.04 everything is fine. But I'am afraid that I can get similar trouble if I update to a newer ubuntu release there too. Best regards, Oliver -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- # Randy MacLeod # Wind River Linux -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] scipy recipe
On 2018-03-15 01:56 PM, Peter Balazovic wrote: Hello all, I wonder if there is scipy recipe available? Not yet: https://layers.openembedded.org/layerindex/branch/master/recipes/?q=scipy It appears to be blocked by: https://github.com/scipy/scipy/issues/8226 but apparently that's a bitbake issue, not a spip one. Care to take a look? Thanks. -- # Randy MacLeod. WR Linux # Wind River an Intel Company -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-virtualization] Yocto Recipe for LibRXE.
On 2018-02-16 11:49 AM, Vish (Vishwanath) Maram wrote: Ross, Can you point me to what devtool you are talking about to generate the recipe? I am in process of learning tools on FPGA, not sure on how to generate as well? -Vish See: http://www.yoctoproject.org/docs/2.5/sdk-manual/sdk-manual.html#using-devtool-in-your-sdk-workflow but you can also just copy a similar recipe and make changes as needed. Give it a try! -- # Randy MacLeod. WR Linux # Wind River an Intel Company -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] single or authoritative home for sbsigntool?
+Megha -l...@lists.01.org since you have to be a member to send to the list. ../Randy On 2018-01-19 04:07 PM, Randy MacLeod wrote: In chasing down a rare ccan configuration bug that sbsigntool-native trips over, I noticed that there are several sbsigntool-native recipes, all alike but not identical. We have a few in the layer index: https://layers.openembedded.org/layerindex/branch/master/recipes/?q=sbsigntool and more elsewhere: https://www.google.ca/search?q=sbsigntool-native and even: https://www.google.ca/search?q=meta-secure-core The meta-intel and meta-secure-core versions were somewhat different but that seems to be due to lack of co-operation rather than different requirements. Does it make sense to have a single version of the recipe in a signing-key layer with the actual keys kept elsewhere I'd expect. If so, what layer would make the most sense? How about picking: https://layers.openembedded.org/layerindex/branch/master/layer/meta-signing-key/ There is likely other recipe duplication in secure boot layers but it's not something that I work on directly so I'm only mentioning sbsigntool. Feel free to reduce more duplication! Thanks, -- # Randy MacLeod. WR Linux # Wind River an Intel Company -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] single or authoritative home for sbsigntool?
In chasing down a rare ccan configuration bug that sbsigntool-native trips over, I noticed that there are several sbsigntool-native recipes, all alike but not identical. We have a few in the layer index: https://layers.openembedded.org/layerindex/branch/master/recipes/?q=sbsigntool and more elsewhere: https://www.google.ca/search?q=sbsigntool-native and even: https://www.google.ca/search?q=meta-secure-core The meta-intel and meta-secure-core versions were somewhat different but that seems to be due to lack of co-operation rather than different requirements. Does it make sense to have a single version of the recipe in a signing-key layer with the actual keys kept elsewhere I'd expect. If so, what layer would make the most sense? How about picking: https://layers.openembedded.org/layerindex/branch/master/layer/meta-signing-key/ There is likely other recipe duplication in secure boot layers but it's not something that I work on directly so I'm only mentioning sbsigntool. Feel free to reduce more duplication! Thanks, -- # Randy MacLeod. WR Linux # Wind River an Intel Company -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Enabling_gcc
On 2017-10-23 01:17 PM, Khem Raj wrote: On Mon, Oct 23, 2017 at 4:52 AM, vishal ashapur <vishalasha...@gmail.com> wrote: Hi I'm building a Linux kernel from yocto, on which I have to enable gcc. Can u please tell me how to enable gcc. And also usb_modeswitch package it uses gcc, I think you need to clarify your question a bit so someone can provide you help. Do you mean that you want the compiler in the target image? If so, add: IMAGE_INSTALL += "packagegroup-core-buildessential" to your conf/local.conf file. ../Randy FYI, I looked-up that up in WR's distro feature: https://github.com/WindRiver-OpenSourceLabs/wr-base/blob/LB21_7.0_RCPL0002/templates/feature/target-toolchain/image.inc since I know it well. :) I didn't quickly find it in the YP manual: http://www.yoctoproject.org/docs/2.2/mega-manual/mega-manual.html but it should be there. -- # Randy MacLeod. WR Linux # Wind River an Intel Company -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-security][PATCH] keynote: update the SRC_URI
On 2017-09-29 09:55 PM, Dengke Du wrote:
The old URL can't be available, give the new URL to keynote.
The project already moved to:
https://sourceforge.net/projects/keynote-2-3/
Signed-off-by: Dengke Du <dengke...@windriver.com>
---
recipes-security/keynote/keynote_2.3.bb | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/recipes-security/keynote/keynote_2.3.bb
b/recipes-security/keynote/keynote_2.3.bb
index b1df880..23e75e4 100644
--- a/recipes-security/keynote/keynote_2.3.bb
+++ b/recipes-security/keynote/keynote_2.3.bb
@@ -9,16 +9,19 @@ SECTION = "security"
LICENSE = "ISC"
LIC_FILES_CHKSUM = "file://LICENSE;md5=3a265095c549c1808686a676f2699c98"
-SRC_URI = "http://www.cs.columbia.edu/~angelos/Code/${BPN}.tar.gz \
+MAIN_ID = "${@d.getVar('PV').split('.')[0]}"
+MINOR_ID = "${@d.getVar('PV').split('.')[1]}"
+SRC_URI =
"${SOURCEFORGE_MIRROR}/project/${PN}-${MAIN_ID}-${MINOR_ID}/${PN}_${PV}.tar.gz \
file://configure-remove-hardcode-path.patch \
file://makefile-add-ldflags.patch \
file://run-ptest \
"
+S = "${WORKDIR}/${PN}-${PV}+dfsg.orig"
inherit autotools-brokensep ptest
-SRC_URI[md5sum] = "ba58a0297c421dc6aa671e6b753ef695"
-SRC_URI[sha256sum] =
"62f7a9d57ceb6bcdd47b604b637a7ac8ed337cef0ab02f1fa28b7e61c9b15821"
+SRC_URI[md5sum] = "a14553e6ad921b5c85026ce5bec3afe7"
+SRC_URI[sha256sum] =
"38d2acfa1c3630a07adcb5c8fe92d2aef7f0e6d242b8998b2bbb1c6e4c408d46"
Denke tells me that the source is identical but docs were added
so the checksums have changed.
../Randy
DEPENDS = "flex openssl"
--
# Randy MacLeod. WR Linux
# Wind River an Intel Company
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] want to execute a script having sudo : sudo cryptsetup
On 2017-09-27 01:28 PM, John Finley wrote: pseudo can't do some of the cryptsetup functions that really require root, or at least I could not convince it to. Using sudo is not so good, but I don't think there's an easy way around it for the cryptsetup stuff. If you can narrow down what's missing, and open an enhancement request for oe-core-2.5 that would be helpful. Please take a quick look to see if your ER is it already in this list: https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=pseudo_id=601276 Sorting by the product column will help. ../Randy On Wed, Sep 27, 2017 at 10:22 AM, Khem Raj <raj.k...@gmail.com <mailto:raj.k...@gmail.com>> wrote: On Wed, Sep 27, 2017 at 9:21 AM John Finley <john.fin...@gmail.com <mailto:john.fin...@gmail.com>> wrote: Try making it so the user doing the build is not prompted for a password when they do "sudo". I have this in my vm: I think you can leverage pseudo tool to emulate the root user during build john@vbox-ubuntu-16$ cat /etc/sudoers.d/john john ALL=(ALL) NOPASSWD: ALL john@vbox-ubuntu-16$ I don't know if that's all that's needed; I have to google it every time. On Mon, Sep 25, 2017 at 2:48 AM, Kumar, Shrawan <shrawan.ku...@harman.com <mailto:shrawan.ku...@harman.com>> wrote: Hello Team , __ __ I am trying to achieve below from yocto , do we have a way ? __ __ __ __ dd if=/dev/zero of=hello.enc bs=4k count=$400 mknod /dev/loop_dev_0 losetup /dev/loop_dev_0 hello.enc *_sudo_* cryptsetup --type=plain open /dev/loop_dev_0 plainMap < $2 __ __ __ __ __ __ __ __ Thanks and Regards Shrawan -- # Randy MacLeod. WR Linux # Wind River an Intel Company -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] rootfs encryption support
On 2017-09-26 01:25 AM, Kumar, Shrawan wrote: Hello Team , Is it possible to get encrypted rootfs during image build ? Currently , I am running “*cryptsetup*” (as sudo) *manually* after the final image(rootfs.ext4) is produced . The idea is to get this done within yocto environment without sudo problem . Thanks and Regards Shrawan I'm not working on it but I think people are trying to focus such work in this layer: https://layers.openembedded.org/layerindex/branch/master/layer/meta-encrypted-storage/ https://github.com/jiazhang0/meta-secure-core -- # Randy MacLeod. WR Linux # Wind River an Intel Company -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Mpich and yocto ?
On 2017-07-27 09:22 PM, Riko Ho wrote: /usr/bin/install: cannot create regular file '/usr/local/lib/libicecc.la': Permission denied Riko, http://lmgtfy.com/?q=%2Fusr%2Fbin%2Finstall%3A+cannot+create+regular+file+%27%2Fusr%2Flocal%2Flib%2Flibicecc.la%27%3A+Permission+denied :) I assume you have to be root to install under /usr/local on your system. We're happy to help with Yocto specific questions here but general introductory linux questions should go to google/baidu or some other forum; perhaps this link will help: https://www.reddit.com/r/linux/comments/1hzz03/what_is_the_best_irc_channel_for_discussing/ I'd be happy to answer one or two question offline to get you started. Good luck. -- # Randy MacLeod. SMTS, Linux, Wind River Direct: 613.963.1350 | 350 Terry Fox Drive, Suite 200, Ottawa, ON, Canada, K2K 2W5 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Mpich and yocto ?
On 2017-07-26 08:08 PM, Riko Ho wrote: Dear Yocto Team Member, The cluster is using Ubuntu. I haven't checked all the packages on the other computer. I will. My goal is getting more hardrive space and compiling speed. How can I relate bitbake with mpicc or other compilers needed by yocto (arm-linux-gcc, gcc, etc)? Do you mean that you want to do part of the build using each node in the cluster? That's possible now using distcc/icecream (https://github.com/icecc/icecream ) but I haven't done it in years as explained below. Oh, there's a Stack Overflow entry for YP+distcc/icecream: https://stackoverflow.com/questions/14472175/distributed-compile-with-bitbake and distcc is mentioned in the docs: http://www.yoctoproject.org/docs/2.3/dev-manual/dev-manual.html Anyway, this just distributes the compilation so: - build management, - recipe download, unpack, patch, configuring and packaging, - linking, etc are still done centrally. There are plans to improve the bitbake task manager so that, with the recipe specific sysroot work that has been done in 2.2, we'd be able to farm out all of the stages of a package's build to individual nodes in a cluster: https://bugzilla.yoctoproject.org/show_bug.cgi?id=10684 I don't know if that work is a priority for the fall 2.4 release. Note that depending on your workload, inter-recipe dependencies and the long time taken to run configure for autotools-based packages is the bottleneck. Therefore, buying a high-end ( >= 16+16 core ) system with lots (64GB+) RAM and a good IO sub-system results in core-image-minimal building quickly, certainly under 40 minutes. https://wiki.yoctoproject.org/wiki/Build_Performance Also for repeated builds by one or more developers, sstate-cache is a huge speed-up with some cost in scripts and people to manage it. I've wondered if anyone has played with bitbake on an OS that is known as a single-system image: https://en.wikipedia.org/wiki/Single_system_image On these systems, jobs are transparently moved from the master-node to idle nodes in the cluster by the operating system. That would be an interesting academic exercise but it wouldn't be useful in practice since such OSs are not generally used as far as I know at least. I look forward to hearing what your goals and plans are. ../Randy I have tested a small code with mpicc and the cluster do the job. Thanks for the attention. On Jul 27, 2017 3:23 AM, "Randy MacLeod" <randy.macl...@windriver.com <mailto:randy.macl...@windriver.com>> wrote: > > On 2017-07-26 02:09 AM, Riko Ho wrote: >> >> How can we do that ? >> >> bitbake in which node ? I don't understand ? >> >> >> On 26/07/17 13:57, Josef Holzmayr wrote: >>> >>> Hi >>> >>> On 26.07.2017 05:12, Riko Ho wrote: >>>> >>>> Does anyone know on how to run poky on mpich cluster ? > > > That's a rather ambiguous question. > > What OS/Distro is the mpich cluster running? > Have you installed the packages that are required on the host: >see: "The Build Host Packages" here: > > http://www.yoctoproject.org/docs/2.3/yocto-project-qs/yocto-project-qs.html > > What do you hope to achieve using bitbake? > > >>> >>> As far as I can see, MPICH is a userland library, basically. So it would be the other way round, you could probably run a mpich application on a number of nodes that run some OE/Poky thing. >>> >>> Greetz > > > There is an mpich recipe here: > http://layers.openembedded.org/layerindex/recipe/33348/ > > but again, it's not clear what your ultimate goal is. > > ../Randy > >> >> -- >> * >> >> >> /***/ >> Sent by Ubuntu LTS 16.04, >> Kind regards, >> Riko Ho >> /***/ >> >> * >> >> > > > -- > # Randy MacLeod. SMTS, Linux, Wind River > Direct: 613.963.1350 | 350 Terry Fox Drive, Suite 200, Ottawa, ON, Canada, K2K 2W5 -- # Randy MacLeod. SMTS, Linux, Wind River Direct: 613.963.1350 | 350 Terry Fox Drive, Suite 200, Ottawa, ON, Canada, K2K 2W5 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Mpich and yocto ?
On 2017-07-26 02:09 AM, Riko Ho wrote: How can we do that ? bitbake in which node ? I don't understand ? On 26/07/17 13:57, Josef Holzmayr wrote: Hi On 26.07.2017 05:12, Riko Ho wrote: Does anyone know on how to run poky on mpich cluster ? That's a rather ambiguous question. What OS/Distro is the mpich cluster running? Have you installed the packages that are required on the host: see: "The Build Host Packages" here: http://www.yoctoproject.org/docs/2.3/yocto-project-qs/yocto-project-qs.html What do you hope to achieve using bitbake? As far as I can see, MPICH is a userland library, basically. So it would be the other way round, you could probably run a mpich application on a number of nodes that run some OE/Poky thing. Greetz There is an mpich recipe here: http://layers.openembedded.org/layerindex/recipe/33348/ but again, it's not clear what your ultimate goal is. ../Randy -- * /***/ Sent by Ubuntu LTS 16.04, Kind regards, Riko Ho /***/ * -- # Randy MacLeod. SMTS, Linux, Wind River Direct: 613.963.1350 | 350 Terry Fox Drive, Suite 200, Ottawa, ON, Canada, K2K 2W5 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] do_compile errors.
, Jul 19, 2017 at 3:58 PM, Joseph Ngigi <jngi...@gmail.com <mailto:jngi...@gmail.com>> wrote: I seem to be having a lot of do_compile failure errors, building core-image-sato for cubieboard2 using poky pyro. I do not understand whether it is a gcc compiler issue or any other problem. Any assistance will be highly appreciated. Below is my logfile. DEBUG: Executing shell function do_compile NOTE: make -j 8 ERROR: oe_runmake failed cd lib; make all make[1]: Entering directory '/home/ngigijoe/src/git/pyro/poky/cubieboard2/tmp/work/x86_64-linux/gperf-native/3.0.4-r0/build/lib' make[1]: Nothing to be done for 'all'. make[1]: Leaving directory '/home/ngigijoe/src/git/pyro/poky/cubieboard2/tmp/work/x86_64-linux/gperf-native/3.0.4-r0/build/lib' cd src; make all make[1]: Entering directory '/home/ngigijoe/src/git/pyro/poky/cubieboard2/tmp/work/x86_64-linux/gperf-native/3.0.4-r0/build/src' g++ -isystem/home/ngigijoe/src/git/pyro/poky/cubieboard2/tmp/work/x86_64-linux/gperf-native/3.0.4-r0/recipe-sysroot-native/usr/include -O2 -pipe -D_GLIBCXX_USE_CXX11_ABI=0 -L/home/ngigijoe/src/git/pyro/poky/cubieboard2/tmp/work/x86_64-linux/gperf-native/3.0.4-r0/recipe-sysroot-native/usr/lib -L/home/ngigijoe/src/git/pyro/poky/cubieboard2/tmp/work/x86_64-linux/gperf-native/3.0.4-r0/recipe-sysroot-native/lib -Wl,-rpath-link,/home/ngigijoe/src/git/pyro/poky/cubieboard2/tmp/work/x86_64-linux/gperf-native/3.0.4-r0/recipe-sysroot-native/usr/lib -Wl,-rpath-link,/home/ngigijoe/src/git/pyro/poky/cubieboard2/tmp/work/x86_64-linux/gperf-native/3.0.4-r0/recipe-sysroot-native/lib -Wl,-rpath,/home/ngigijoe/src/git/pyro/poky/cubieboard2/tmp/work/x86_64-linux/gperf-native/3.0.4-r0/recipe-sysroot-native/usr/lib -Wl,-rpath,/home/ngigijoe/src/git/pyro/poky/cubieboard2/tmp/work/x86_64-linux/gperf-native/3.0.4-r0/recipe-sysroot-native/lib -Wl,-O1 -o gperf version.o positions.o options.o keyword.o keyword-list.o input.o bool-array.o hash-table.o search.o output.o main.o ../lib/libgp.a -lm g++: error: version.o: No such file or directory g++: error: positions.o: No such file or directory g++: error: options.o: No such file or directory g++: error: keyword.o: No such file or directory g++: error: keyword-list.o: No such file or directory g++: error: input.o: No such file or directory g++: error: bool-array.o: No such file or directory g++: error: hash-table.o: No such file or directory g++: error: output.o: No such file or directory g++: error: main.o: No such file or directory g++: error: ../lib/libgp.a: No such file or directory Makefile:74: recipe for target 'gperf' failed make[1]: *** [gperf] Error 1 make[1]: Leaving directory '/home/ngigijoe/src/git/pyro/poky/cubieboard2/tmp/work/x86_64-linux/gperf-native/3.0.4-r0/build/src' Makefile:33: recipe for target 'all' failed make: *** [all] Error 2 ERROR: Function failed: do_compile (log file is located at /home/ngigijoe/src/git/pyro/poky/cubieboard2/tmp/work/x86_64-linux/gperf-native/3.0.4-r0/temp/log.do_compile.600) -- J.W.Ngigi -- J.W.Ngigi That's odd, is it still a problem? If so: What's your builder's distro? Have your run: apt-get/dnf/... as per: http://www.yoctoproject.org/docs/2.3/yocto-project-qs/yocto-project-qs.html Can you compile gperf outside of bitbake on your builder? Also to quote Ross: Is this a totally clean pyro build? Anything special in the local.conf? Tried without the BSP layer, using MACHINE=qemuarm? $ MACHINE=qemuarm bitbake core-image-sato or -minimal -- # Randy MacLeod. SMTS, Linux, Wind River Direct: 613.963.1350 | 350 Terry Fox Drive, Suite 200, Ottawa, ON, Canada, K2K 2W5 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Automating imaging building and testing, what aproach to use!?
On 2016-08-30 04:18 PM, Daniel. wrote: Hey everybody! While writing software we're used to delivery packages, libraries and stacks. There are out there a lot of continuos integration solutions to automatically build and test these kinds of software. But when dealing to images the thing is more tricky. I can't run the tests at the same machine that build the image because crosscompilation take place on 99% of the cases. What is approach that you guys are using to automate and increase the quality of your images? We have a custom automated build system running 100s of configs/day Some people I work with have started using LAVA [1] to do automated testing for both Qemu and hardware targets. Let me know if you are interested and I'll ask them to summarize what they think of it so far. ../Randy [1] http://www.linaro.org/initiatives/lava/ Automating the build is the easy part my concert is about automating the runtime tests that need the target board to run. In my case I depend on hardware to fully test the image features. Is there any reliable way to automate image installation and boot!? Best regards to everybody! -- # Randy MacLeod. SMTS, Linux, Wind River Direct: 613.963.1350 | 350 Terry Fox Drive, Suite 200, Ottawa, ON, Canada, K2K 2W5 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-selinux] How about remove libcap-ng from meta-selinux?
On 2015-08-14 02:41 AM, wenzong fan wrote: On 08/12/2015 09:05 PM, Joe MacDonald wrote: [[yocto] [meta-selinux] How about remove libcap-ng from meta-selinux?] On 15.08.12 (Wed 17:08) wenzong fan wrote: Hi All, There's a libcap-ng in meta-oe layer, it has been updated to 0.7.7 and the one in meta-selinux is 0.7.3. How about removing the one in meta-selinux and get this layer depends on meta-oe? Any suggestions? The last time we had this discussion my sense was that most users of meta-selinux wanted to continue with it only depending on oe-core. That's my preference as well. I'm happy to merge an updated version of libcap-ng (or maybe I'll get to it myself, since I've known about it since Armin removed it from meta-security, that was the time of the last discussion, I think). All I'm saying right now is that this isn't a case of accidental duplication of recipes in multiple layers, it's the result of a conscious decision. It's totally worthwhile re-visiting that decision, though to make sure the reasons are still valid. Thanks for clarifying this, just send out an update patch for libcap-ng. I still think it belongs in oe-core. Wenzong, Can you try to build up a case for that? If I look at the dependencies on Ubuntu-15.04: Reverse Depends: qemu-system-common,libcap-ng0 libvirt0,libcap-ng0 libvirt-bin,libcap-ng0 libcap-ng0:i386,libcap-ng0 0.7.4-2 libcap-ng0:i386,libcap-ng0 0.7.4-2 suricata,libcap-ng0 libcap-ng-utils,libcap-ng0 0.7.4-2 ladvd,libcap-ng0 heimdal-kdc,libcap-ng0 audispd-plugins,libcap-ng0 smartmontools,libcap-ng0 qemu-system-common,libcap-ng0 libvirt0,libcap-ng0 libvirt-bin,libcap-ng0 libcap-ng-dev,libcap-ng0 0.7.4-2 irqbalance,libcap-ng0 gnome-keyring,libcap-ng0 dbus-1-dbg,libcap-ng0 dbus,libcap-ng0 note that pkgs in: meta-virtualization: irqbalance, libvirt, more? meta-selinux: audit meta-security-framework: audit could drop the local versions of libcap-ng and use the oe-core libcap-ng. Please check on the actual source/configure options so that we(I!!) get a better understanding of where libcap vs libcap-ng is used. In fact, since meta-security-framework isn't using selinux, I'd say that both audit and libcap-ng should both move to oe-core. Thanks, ../Randy Wenzong -- # Randy MacLeod. SMTS, Linux, Wind River Direct: 613.963.1350 | 350 Terry Fox Drive, Suite 200, Ottawa, ON, Canada, K2K 2W5 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [oe] [meta-selinux] Re: meta-selinux updates for oe-core-1.9 -- resend to right list.
Resending to the right list. (yocto@yoctoproject.org rather than openembedded-de...@lists.openembedded.org ) Radzy will be working on meta-selinux and I've suggested that the start with a package uprev or two once the upstream selinux release intentions are known. ../Randy --- Going on-list like I should have originally. On 2015-07-31 01:33 PM, Joe MacDonald wrote: Hey Randy, Good to hear from you. [meta-selinux updates for oe-core-1.9] On 15.07.31 (Fri 01:05) Randy MacLeod wrote: What's the plan for meta-selinux in the next 2 months? Roy dug up the current meta-selinux, upstream versions: swig 2.0.103.0.6 python-ipy 0.81 0.83 audit 2.3.22.4.3 refpolicy-mls 2.201403112.20141203 libcap-ng 0.7.30.7.7 setools 3.3.83.3.8 sepolgengit1.2.2 libsemanage git 2.4 checkpolicy 2.3 2.4 policycoreutils git 2.4 selinux-config 0.1 0.1 libsepolgit 2.4 libsemanage 2.3 2.4 sepolgen 1.2.11.2.2 libsepol2.3 2.4 libselinux git 2.4 policycoreutils 2.3 2.4 libselinux 2.3 2.4 ustr 1.0.41.0.4 There's a backlog of meta-selinux patches to integrate that have been in my merge queue for rather a long time now. I expect to clear that out, which will include an update to the most recent (not the current, any longer, I don't think) refpolicy and a new recipe that will build from the refpolicy git repository rather than release tarballs. I think this'll be a significant benefit to everyone in that it'll make it much easier to migrate patches and to try out a new release without waiting for a full update. Those are the big things on the horizon. The other one is the filesystem labelling work being done by the community. It looks quite good and as soon as I get a few minutes to try it out a bit more on some oddball configurations to ensure we aren't bringing in any new dependencies (after having just scrubbed a bunch of bashisms and hidden deps), it'll likely get merged. There's nothing on the radar in the short term that hasn't already been discussed on the mailing list, though, AFAIK. -J. So when Radzy is back in a week from being OOO, hopefully Joe's backlog will be cleared and we all can update pkgs as needed. We can split up that work however it makes sense; just tell the list if you start working on a package. My quick review of git logs and my memory of selinux releases tells me that there tends to be an late fall release. I looked at the Changelog for a few of the components of: https://github.com/SELinuxProject/selinux and things seem to be moving along more quickly than usual so that pattern might not hold. Is anyone subscribed to the list: https://www.nsa.gov/research/selinux/list.shtml if so is there talk of an approximate release date that would help us decide if we went to update now or in a month or so? Oh and is selinux happy under gcc-5.2+? ../Randy Roy can you summarize the state of each recipe? i.e. current version and upstream version? I'd like to make sure that we're up to date when oe-core-1.9 is released. -- # Randy MacLeod. SMTS, Linux, Wind River Direct: 613.963.1350 | 350 Terry Fox Drive, Suite 200, Ottawa, ON, Canada, K2K 2W5 -- ___ Openembedded-devel mailing list openembedded-de...@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] how to set LICENSE for llvm in .bb file
On 14-04-03 04:54 AM, Guo, Yejun wrote: Thank you Ross, what I actually need is llvm+clang, it is a very good reference for me to resolve the license issue, and the SYSROOT_PREPROCESS_FUNCS knowledge to resolve llvm-config issue. Thanks Yejun Yejun, Did you ever produce a recipe to build clang? Are you also trying to build all of YP with it? A student that worked with me did some work to use clang to build yocto packages: http://lists.openembedded.org/pipermail/openembedded-core/2013-November/086275.html so I'd be interested in hearing about your work. ../Randy -Original Message- From: Burton, Ross [mailto:ross.bur...@intel.com] Sent: Thursday, April 03, 2014 2:01 PM To: Guo, Yejun Cc: yocto@yoctoproject.org Subject: Re: [yocto] how to set LICENSE for llvm in .bb file On 3 April 2014 03:16, Guo, Yejun yejun@intel.com wrote: I'm adding package llvm which has its own license: University of Illinois/NCSA Open Source License, see at http://llvm.org/releases/3.4/LICENSE.TXT . I tried something for LICENSE in .bb file, but is not recognized by the system. Could you please let me know how to set this value? Thanks a lot! LLVM is already packaged outside of oe-core: http://layers.openembedded.org/layerindex/branch/master/recipes/?q=llvm Ross -- # Randy MacLeod. SMTS, Linux, Wind River Direct: 613.963.1350 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH] Use BPN in SRC_URI to enable multilib builds
Signed-off-by: Randy MacLeod randy.macl...@windriver.com
---
recipes-security/libcap-ng/libcap-ng_0.7.3.bb | 2 +-
recipes-security/libseccomp/libseccomp_2.1.1.bb | 2 +-
recipes-security/nikto/nikto_2.1.5.bb | 2 +-
recipes-security/nmap/nmap_6.25.bb | 2 +-
recipes-security/pinentry/pinentry_0.8.3.bb | 2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/recipes-security/libcap-ng/libcap-ng_0.7.3.bb
b/recipes-security/libcap-ng/libcap-ng_0.7.3.bb
index ef70207..91ee58b 100644
--- a/recipes-security/libcap-ng/libcap-ng_0.7.3.bb
+++ b/recipes-security/libcap-ng/libcap-ng_0.7.3.bb
@@ -3,7 +3,7 @@ HOMEPAGE =
http://people.redhat.com/sgrubb/libcap-ng/index.html;
LICENSE = GPL-2.0
LIC_FILES_CHKSUM = file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f
-SRC_URI = http://people.redhat.com/sgrubb/libcap-ng/${PN}-${PV}.tar.gz;
+SRC_URI = http://people.redhat.com/sgrubb/libcap-ng/${BPN}-${PV}.tar.gz;
SRC_URI[md5sum] = 610afb774f80a8032b711281df126283
SRC_URI[sha256sum] =
5ca441c8d3a1e4cfe8a8151907977662679457311ccaa7eaac91447c33a35bb1
diff --git a/recipes-security/libseccomp/libseccomp_2.1.1.bb
b/recipes-security/libseccomp/libseccomp_2.1.1.bb
index 27fa259..bd97a87 100644
--- a/recipes-security/libseccomp/libseccomp_2.1.1.bb
+++ b/recipes-security/libseccomp/libseccomp_2.1.1.bb
@@ -4,7 +4,7 @@ SECTION = security
LICENSE = GPL-2.0
LIC_FILES_CHKSUM =
file://${COMMON_LICENSE_DIR}/GPL-2.0;md5=801f80980d171dd6425610833a22dbe6
-SRC_URI = http://sourceforge.net/projects/libseccomp/files/${PN}-${PV}.tar.gz
\
+SRC_URI =
http://sourceforge.net/projects/libseccomp/files/${BPN}-${PV}.tar.gz \
file://compiler.patch \
file://0001-tests-create-install-tests-target.patch \
file://0002-tests-install-python-tests-if-appropriate.patch \
diff --git a/recipes-security/nikto/nikto_2.1.5.bb
b/recipes-security/nikto/nikto_2.1.5.bb
index 4609717..b78a65c 100644
--- a/recipes-security/nikto/nikto_2.1.5.bb
+++ b/recipes-security/nikto/nikto_2.1.5.bb
@@ -6,7 +6,7 @@ LICENSE = GPLv2
LIC_FILES_CHKSUM =
file://${COMMON_LICENSE_DIR}/GPL-2.0;md5=801f80980d171dd6425610833a22dbe6
RDEPENDS_${PN} = perl libnet-ssleay-perl perl-module-getopt-long
perl-module-time-local perl-module-io-socket nikto-doc
-SRC_URI = http://cirt.net/nikto/${PN}-${PV}.tar.gz \
+SRC_URI = http://cirt.net/nikto/${BPN}-${PV}.tar.gz \
file://location.patch
SRC_URI[md5sum] = efcc98a918becb77471ee9a5df0a7b1e
diff --git a/recipes-security/nmap/nmap_6.25.bb
b/recipes-security/nmap/nmap_6.25.bb
index aff5c63..db5f9b9 100644
--- a/recipes-security/nmap/nmap_6.25.bb
+++ b/recipes-security/nmap/nmap_6.25.bb
@@ -5,7 +5,7 @@ LICENSE = GPL-2.0
LIC_FILES_CHKSUM =
file://${COMMON_LICENSE_DIR}/GPL-2.0;md5=801f80980d171dd6425610833a22dbe6
FILES_${PN} += ${target_datadir}/ncat
-SRC_URI = http://nmap.org/dist/${PN}-${PV}.tar.bz2 \
+SRC_URI = http://nmap.org/dist/${BPN}-${PV}.tar.bz2 \
file://lua.patch
SRC_URI[md5sum] = fcc80f94ff3adcb11eedf91092ea6f5e
diff --git a/recipes-security/pinentry/pinentry_0.8.3.bb
b/recipes-security/pinentry/pinentry_0.8.3.bb
index 0043c23..d681a6c 100644
--- a/recipes-security/pinentry/pinentry_0.8.3.bb
+++ b/recipes-security/pinentry/pinentry_0.8.3.bb
@@ -4,7 +4,7 @@ LICENSE = GPL-2.0
LIC_FILES_CHKSUM =
file://${COMMON_LICENSE_DIR}/GPL-2.0;md5=801f80980d171dd6425610833a22dbe6
DEPENDS = glib-2.0 ncurses
-SRC_URI = ftp://ftp.gnupg.org/gcrypt/pinentry/${PN}-${PV}.tar.bz2;
+SRC_URI = ftp://ftp.gnupg.org/gcrypt/pinentry/${BPN}-${PV}.tar.bz2;
SRC_URI[md5sum] = 2ae681cbca0d9fb774b2c90b11ebf56c
SRC_URI[sha256sum] =
568b0b09b50b2388a4f94d704d5bcb28718ecd4654ed1acc43ab1f97d921a0ad
--
1.8.4.1
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Python3 ptest and unittest
On 14-02-22 08:07 PM, Paul Barker wrote: On 21 February 2014 16:08, Randy MacLeod randy.macl...@windriver.com wrote: On 14-02-18 04:27 PM, Paul Barker wrote: I've just thrown together a couple of things which may be useful. They're currently slightly hackish but I could improve them and share them/submit them as patches if wanted: 1) I've wrote a custom python test runner which runs test suites and outputs the format expected by ptest natively instead of needing the sed magic in openembedded-core/meta/recipes-devtools/python/python/run-ptest. I'm using it in my own project, might move the opkg test suite over to it if I have time, and it might be useful for any other python test suites. It's 50 lines of python :) 2) I've wrote a script which patches this test runner into python3's own testsuite then runs the suite. You don't even to patch the Makefile from the python source tree and install it (as in the python recipe in openembedded-core). It should run on anything with python3 installed with the python standard library (as the standard library already includes all the tests). This may be a good option for adding ptest support to the python3 recipe - it'd just be a single 50-line 'run-ptest' script written in python. Does that sound interesting to anyone else? Yes, this seems to be very useful. Can you send a patch for review? I've never worked with the ptest system before but I'm giving it a go... I'm mostly relying on https://wiki.yoctoproject.org/wiki/Ptest for info. It does look like the python3 test suite crashes with out-of-memory errors on qemux86 with the default configuration of 256 MB RAM. I've bumped it up to 1 GB and it seems to be working. I've seen similar problems and dealt with it the same way. Some tests deliberately try to cause an OOM and I assert that they don't belong in ptest runs. Is there any way to note this in the ptest system so that this test suite is skipped if there isn't enough memory? Not that I'm aware of. Add to docs? Also, I'm getting several failures within the testsuite which I'm not seeing when I run it on my desktop. Do we keep data on whether each ptest package is expected to pass or has known failures? Not that I know of. We should. That's something that I've been meaning to do but I won't get to it for until another project is done so don't wait for me. :) ../Randy Cheers, -- # Randy MacLeod. SMTS, Linux, Wind River Direct: 613.963.1350 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Python3 ptest and unittest
On 14-02-18 04:27 PM, Paul Barker wrote: I've just thrown together a couple of things which may be useful. They're currently slightly hackish but I could improve them and share them/submit them as patches if wanted: 1) I've wrote a custom python test runner which runs test suites and outputs the format expected by ptest natively instead of needing the sed magic in openembedded-core/meta/recipes-devtools/python/python/run-ptest. I'm using it in my own project, might move the opkg test suite over to it if I have time, and it might be useful for any other python test suites. It's 50 lines of python :) 2) I've wrote a script which patches this test runner into python3's own testsuite then runs the suite. You don't even to patch the Makefile from the python source tree and install it (as in the python recipe in openembedded-core). It should run on anything with python3 installed with the python standard library (as the standard library already includes all the tests). This may be a good option for adding ptest support to the python3 recipe - it'd just be a single 50-line 'run-ptest' script written in python. Does that sound interesting to anyone else? Yes, this seems to be very useful. Can you send a patch for review? -- # Randy MacLeod. SMTS, Linux, Wind River Direct: 613.963.1350 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-selinux][PATCH 0/4] Begin mingrating bbappends to use wildcards in place of version numbers.
On 14-02-11 09:54 PM, Philip Tricca wrote: On 02/11/2014 08:15 PM, Joe MacDonald wrote: [Re: [yocto] [meta-selinux][PATCH 0/4] Begin mingrating bbappends to use wildcards in place of version numbers.] On 14.02.11 (Tue 15:11) Randy MacLeod wrote: On 14-02-06 10:09 PM, Philip Tricca wrote: The current trend in OE recipes seems to use a wildcard in place of version numbers for bbappends. AFAIK this is a relatively new feature but a welcome one. This is a sort of RFC in that I think it's probably best for meta-selinux to use this mechanism to keep from having to rename bbappends everytime something in oe-core changes. I guess the right way to implement this is to change the bbappends in meta-selinux when the version numbers change upstream. I'm convinced that we should give this a try. If there are cases where the wildcard bbappend doesn't work, we can always use explicit versions and add a comment explaining why the wildcard isn't used. ../ Randy Hi Philip, This might work out but I'm somewhat attached to the manual process. It's a change I'd been advocating for quite some time now. (Actually, it was something I was somewhat surprised wasn't possible when I first came to bitbake in general, so at least to me this change seems pretty sensible.) The risks you outline are real, but historically this hasn't shown itself to be a significant problem so far. The types of things this'll hit on are characterized well in Phil's RFC set. Stuff like sudo and libcgroup which require bbappends but the contents haven't had any meaningful change since the stone age. :-) I think this is actually a win for meta-selinux in terms of reducing the number of commits like f0adb425. I've already staged the proposed change in my tree and it seems happy, so I'm inclined to merge it, FWIW. I appreciate both sides of this being represented. I agree with Joe that it's an obvious fit for simple bbappends that require little more than --(enable|with)-selinux. The more involved bbappends may be better suited to manual version number changes. If any of the recipes from this set fall into the later category I won't object to dropping them and favoring the process manual. But as Joe points out, I think this approach is a given for the likes of sudo, libcgroup etc. Thanks, Philip -J. Manual matching shows that someone is: - paying attention, - fixed the bbappend version number, - gotten someone else to review, - hopefully built the software for at least one arch, - hopefully tested run-time for at least one arch. With a wildcard matching rule, there will be times when the underlying package has changed and then the recipe changes and perhaps code patches still apply but are to some extent broken. Have people accepted this as a possible outcome that they believe will be rare? Have you tried your approach with a few different oe-core baselines such as dora, random, master? I'm not agaist this change but I'm trying to be sure that people agree that it's a good approach and that we've tested the idea with some historical changes. Thanks, ../Randy Philip Tricca (4): busybox: Use wildcard for version number in busybox bbappend. libcgroup: Use wildcard for version number in libcgroup bbappend. sudo: Use wildcard for version number in sudo bbappend. libxcb: Use wildcard for version number in libxcb bbappend. recipes-core/busybox/busybox_%.bbappend| 87 recipes-core/busybox/busybox_1.21.1.bbappend | 87 recipes-core/libcgroup/libcgroup_%.bbappend| 12 recipes-core/libcgroup/libcgroup_0.38.bbappend | 12 recipes-extended/sudo/sudo_%.bbappend |3 + recipes-extended/sudo/sudo_1.8.8.bbappend |3 - recipes-graphics/xcb/libxcb_%.bbappend |8 +++ recipes-graphics/xcb/libxcb_1.9.3.bbappend |8 --- 8 files changed, 110 insertions(+), 110 deletions(-) create mode 100644 recipes-core/busybox/busybox_%.bbappend delete mode 100644 recipes-core/busybox/busybox_1.21.1.bbappend create mode 100644 recipes-core/libcgroup/libcgroup_%.bbappend delete mode 100644 recipes-core/libcgroup/libcgroup_0.38.bbappend create mode 100644 recipes-extended/sudo/sudo_%.bbappend delete mode 100644 recipes-extended/sudo/sudo_1.8.8.bbappend create mode 100644 recipes-graphics/xcb/libxcb_%.bbappend delete mode 100644 recipes-graphics/xcb/libxcb_1.9.3.bbappend -- # Randy MacLeod. SMTS, Linux, Wind River Direct: 613.963.1350 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-selinux][PATCH 0/4] Begin mingrating bbappends to use wildcards in place of version numbers.
On 14-02-06 10:09 PM, Philip Tricca wrote: The current trend in OE recipes seems to use a wildcard in place of version numbers for bbappends. AFAIK this is a relatively new feature but a welcome one. This is a sort of RFC in that I think it's probably best for meta-selinux to use this mechanism to keep from having to rename bbappends everytime something in oe-core changes. I guess the right way to implement this is to change the bbappends in meta-selinux when the version numbers change upstream. Hi Philip, This might work out but I'm somewhat attached to the manual process. Manual matching shows that someone is: - paying attention, - fixed the bbappend version number, - gotten someone else to review, - hopefully built the software for at least one arch, - hopefully tested run-time for at least one arch. With a wildcard matching rule, there will be times when the underlying package has changed and then the recipe changes and perhaps code patches still apply but are to some extent broken. Have people accepted this as a possible outcome that they believe will be rare? Have you tried your approach with a few different oe-core baselines such as dora, random, master? I'm not agaist this change but I'm trying to be sure that people agree that it's a good approach and that we've tested the idea with some historical changes. Thanks, ../Randy Philip Tricca (4): busybox: Use wildcard for version number in busybox bbappend. libcgroup: Use wildcard for version number in libcgroup bbappend. sudo: Use wildcard for version number in sudo bbappend. libxcb: Use wildcard for version number in libxcb bbappend. recipes-core/busybox/busybox_%.bbappend| 87 recipes-core/busybox/busybox_1.21.1.bbappend | 87 recipes-core/libcgroup/libcgroup_%.bbappend| 12 recipes-core/libcgroup/libcgroup_0.38.bbappend | 12 recipes-extended/sudo/sudo_%.bbappend |3 + recipes-extended/sudo/sudo_1.8.8.bbappend |3 - recipes-graphics/xcb/libxcb_%.bbappend |8 +++ recipes-graphics/xcb/libxcb_1.9.3.bbappend |8 --- 8 files changed, 110 insertions(+), 110 deletions(-) create mode 100644 recipes-core/busybox/busybox_%.bbappend delete mode 100644 recipes-core/busybox/busybox_1.21.1.bbappend create mode 100644 recipes-core/libcgroup/libcgroup_%.bbappend delete mode 100644 recipes-core/libcgroup/libcgroup_0.38.bbappend create mode 100644 recipes-extended/sudo/sudo_%.bbappend delete mode 100644 recipes-extended/sudo/sudo_1.8.8.bbappend create mode 100644 recipes-graphics/xcb/libxcb_%.bbappend delete mode 100644 recipes-graphics/xcb/libxcb_1.9.3.bbappend -- # Randy MacLeod. SMTS, Linux, Wind River Direct: 613.963.1350 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH] libsemanage: drop flag: -Wno-unused-but-set-variable
On 13-05-01 12:12 AM, Khem Raj wrote:
On Apr 30, 2013, at 8:15 PM, Randy MacLeod randy.macl...@windriver.com wrote:
The flag: -Wno-unused-but-set-variable isn't supported on older
versions of gcc such as gcc-4.1.2 which is the native compiler for
RHEL-5.9. Drop this warning flag for both the native and target builds.
why drop from target build ?
I thought I'd have to create a separate -native recipe and
that didn't seem to be worthwhile for this warning flag.
On the other hand, the recipe is tiny so I could fix it up
if you think it's important. Oh and I should fix the _git
version of libselinux too.
// Randy
Signed-off-by: Randy MacLeod randy.macl...@windriver.com
---
...semanage-drop-Wno-unused-but-set-variable.patch | 17 +
recipes-security/selinux/libsemanage_2.1.9.bb |6 --
recipes-security/selinux/libsemanage_git.bb|6 --
3 files changed, 25 insertions(+), 4 deletions(-)
create mode 100644
recipes-security/selinux/libsemanage/libsemanage-drop-Wno-unused-but-set-variable.patch
diff --git
a/recipes-security/selinux/libsemanage/libsemanage-drop-Wno-unused-but-set-variable.patch
b/recipes-security/selinux/libsemanage/libsemanage-drop-Wno-unused-but-set-variable.patch
new file mode 100644
index 000..faf8fc5
--- /dev/null
+++
b/recipes-security/selinux/libsemanage/libsemanage-drop-Wno-unused-but-set-variable.patch
@@ -0,0 +1,17 @@
+Subject: libselinux: drop flag: -Wno-unused-but-set-variable
+
+Upstream status: inappropriate (older compilers only).
+
+Signed-off-by: Randy MacLeod randy.macl...@windriver.com
+
+--- libsemanage-2.1.9.orig/src/Makefile
libsemanage-2.1.9/src/Makefile
+@@ -57,7 +57,7 @@
+ LOBJS= $(patsubst %.c,%.lo,$(SRCS)) conf-scan.lo conf-parse.lo
+ CFLAGS ?= -Werror -Wall -W -Wundef -Wshadow -Wmissing-noreturn
-Wmissing-format-attribute
+
+-SWIG_CFLAGS += -Wno-error -Wno-unused-but-set-variable -Wno-unused-variable
-Wno-shadow \
++SWIG_CFLAGS += -Wno-error -Wno-unused-variable -Wno-shadow \
+ -Wno-unused-parameter
+
+ override CFLAGS += -I../include -I$(INCLUDEDIR) -D_GNU_SOURCE
diff --git a/recipes-security/selinux/libsemanage_2.1.9.bb
b/recipes-security/selinux/libsemanage_2.1.9.bb
index 0e0bc41..3b1d8db 100644
--- a/recipes-security/selinux/libsemanage_2.1.9.bb
+++ b/recipes-security/selinux/libsemanage_2.1.9.bb
@@ -1,4 +1,4 @@
-PR = r0
+PR = r1
include selinux_20120924.inc
include ${BPN}.inc
@@ -11,4 +11,6 @@ SRC_URI[sha256sum] =
6f01d17f9751412f7b76e6e7daafeb2faf301b9bfeea83506160c81bec
SRC_URI += \
file://libsemanage-Fix-execve-segfaults-on-Ubuntu.patch \
file://libsemanage-fix-path-len-limit.patch \
- file://libsemanage-fix-path-nologin.patch
+ file://libsemanage-fix-path-nologin.patch \
+ file://libsemanage-drop-Wno-unused-but-set-variable.patch \
+
diff --git a/recipes-security/selinux/libsemanage_git.bb
b/recipes-security/selinux/libsemanage_git.bb
index 562512c..b3819a0 100644
--- a/recipes-security/selinux/libsemanage_git.bb
+++ b/recipes-security/selinux/libsemanage_git.bb
@@ -1,4 +1,4 @@
-PR = r4
+PR = r5
PV = 2.1.6+git${SRCPV}
include selinux_git.inc
@@ -10,4 +10,6 @@ SRC_URI += file://Fix-segfault-for-standard-policy.patch \
file://libsemanage-Fix-execve-segfaults-on-Ubuntu.patch \
file://libsemanage-semanage.conf-for-cross-compile.patch \
file://libsemanage-fix-path-len-limit.patch \
- file://libsemanage-fix-path-nologin.patch
+ file://libsemanage-fix-path-nologin.patch \
+ file://libsemanage-drop-Wno-unused-but-set-variable.patch \
+
--
1.7.4.1
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
--
# Randy MacLeod. SMTS, Linux, Wind River
Direct: 613.963.1350
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH] libsemanage: drop flag: -Wno-unused-but-set-variable
The flag: -Wno-unused-but-set-variable isn't supported on older
versions of gcc such as gcc-4.1.2 which is the native compiler for
RHEL-5.9. Drop this warning flag for both the native and target builds.
Signed-off-by: Randy MacLeod randy.macl...@windriver.com
---
...semanage-drop-Wno-unused-but-set-variable.patch | 17 +
recipes-security/selinux/libsemanage_2.1.9.bb |6 --
recipes-security/selinux/libsemanage_git.bb|6 --
3 files changed, 25 insertions(+), 4 deletions(-)
create mode 100644
recipes-security/selinux/libsemanage/libsemanage-drop-Wno-unused-but-set-variable.patch
diff --git
a/recipes-security/selinux/libsemanage/libsemanage-drop-Wno-unused-but-set-variable.patch
b/recipes-security/selinux/libsemanage/libsemanage-drop-Wno-unused-but-set-variable.patch
new file mode 100644
index 000..faf8fc5
--- /dev/null
+++
b/recipes-security/selinux/libsemanage/libsemanage-drop-Wno-unused-but-set-variable.patch
@@ -0,0 +1,17 @@
+Subject: libselinux: drop flag: -Wno-unused-but-set-variable
+
+Upstream status: inappropriate (older compilers only).
+
+Signed-off-by: Randy MacLeod randy.macl...@windriver.com
+
+--- libsemanage-2.1.9.orig/src/Makefile
libsemanage-2.1.9/src/Makefile
+@@ -57,7 +57,7 @@
+ LOBJS= $(patsubst %.c,%.lo,$(SRCS)) conf-scan.lo conf-parse.lo
+ CFLAGS ?= -Werror -Wall -W -Wundef -Wshadow -Wmissing-noreturn
-Wmissing-format-attribute
+
+-SWIG_CFLAGS += -Wno-error -Wno-unused-but-set-variable -Wno-unused-variable
-Wno-shadow \
++SWIG_CFLAGS += -Wno-error -Wno-unused-variable -Wno-shadow \
+ -Wno-unused-parameter
+
+ override CFLAGS += -I../include -I$(INCLUDEDIR) -D_GNU_SOURCE
diff --git a/recipes-security/selinux/libsemanage_2.1.9.bb
b/recipes-security/selinux/libsemanage_2.1.9.bb
index 0e0bc41..3b1d8db 100644
--- a/recipes-security/selinux/libsemanage_2.1.9.bb
+++ b/recipes-security/selinux/libsemanage_2.1.9.bb
@@ -1,4 +1,4 @@
-PR = r0
+PR = r1
include selinux_20120924.inc
include ${BPN}.inc
@@ -11,4 +11,6 @@ SRC_URI[sha256sum] =
6f01d17f9751412f7b76e6e7daafeb2faf301b9bfeea83506160c81bec
SRC_URI += \
file://libsemanage-Fix-execve-segfaults-on-Ubuntu.patch \
file://libsemanage-fix-path-len-limit.patch \
- file://libsemanage-fix-path-nologin.patch
+ file://libsemanage-fix-path-nologin.patch \
+ file://libsemanage-drop-Wno-unused-but-set-variable.patch \
+
diff --git a/recipes-security/selinux/libsemanage_git.bb
b/recipes-security/selinux/libsemanage_git.bb
index 562512c..b3819a0 100644
--- a/recipes-security/selinux/libsemanage_git.bb
+++ b/recipes-security/selinux/libsemanage_git.bb
@@ -1,4 +1,4 @@
-PR = r4
+PR = r5
PV = 2.1.6+git${SRCPV}
include selinux_git.inc
@@ -10,4 +10,6 @@ SRC_URI += file://Fix-segfault-for-standard-policy.patch \
file://libsemanage-Fix-execve-segfaults-on-Ubuntu.patch \
file://libsemanage-semanage.conf-for-cross-compile.patch \
file://libsemanage-fix-path-len-limit.patch \
- file://libsemanage-fix-path-nologin.patch
+ file://libsemanage-fix-path-nologin.patch \
+ file://libsemanage-drop-Wno-unused-but-set-variable.patch \
+
--
1.7.4.1
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
