|
Re: [ptest-runner][PATCH v2] Fix inappropriate ioctl when detaching tty
Anibal Limon
Applied, Thanks!. Anibal
On Fri, 10 Jul 2020 at 00:44, Tero Kinnunen <tero.kinnunen@...> wrote: Fixes error
|
|
|
|
Re: Linker error undefined reference to `_rtld_global_ro'
On 7/13/20 4:21 AM, Robert Varga wrote:
Hello,it seems static apps with glibc compiled with PIE related. Can you verfiy if you get same issue with aarch64 or mips ? I have sourced the SDK using following command:
|
|
|
|
On 7/13/20 2:04 AM, Bel Hadj Salem Talel wrote:
Hi all,perhaps you can see if commit [1] helps and if sumo already has it then there might be something else going on [1] https://git.openembedded.org/openembedded-core/commit/?id=3e3c5cc579482041f0233e3e03ace736b62fb364 Here is the log:
|
|
|
|
Updating to Zeus with zcu102
Emily
Hi all - I am in the process of attempting to update from rocko -> zeus, which is perhaps a bit ambitious considering I'm skipping quite a few releases. I have a custom layer here: and was able to build core-image-minimal with rocko as well as a custom image (core-image-gfex) for the xilinx zcu102 board. Unfortunately after switching all the repos to zeus I can't get core-image-minimal to build for the zcu102. I've attached the full log, but I seem to be getting an error with the u-boot and/or pmu build: Cannot read ../../../../../../pmutmp/deploy/images/zynqmp-pmu/pmu-firmware-zynqmp-pmu.bin And then also with the spl: /local/d6/easmith5/zeus_bitbake/poky/build/tmp/work/zcu102_zynqmp-poky-linux/u-boot-xlnx/v2019.01-xilinx-v2019.2+gitAUTOINC+dc61275b1d-r0/git/Makefile:1653: recipe for target 'spl/u-boot-spl' failed make[1]: *** [spl/u-boot-spl] Error 2 Am I missing something obvious in terms of building with an existing image and existing machine conf with zeus? Thanks, Emily Smith
|
|
|
|
Linker error undefined reference to `_rtld_global_ro'
Robert Varga
Hello,
I am new to the Yocto project and need some help in solving a linker issue when compiling/linking an application using the SDK. It seems, that the compilation is completed, but the linker could not resolve to "_rtld_global_ro". Here is the output of the last stage <snip> ... /opt/mydistro/1.0.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/8.3.0/real-ld: /opt/mydistro/1.0.0/sysroots/cortexa9t2hf-neon-poky-linux-gnueabi/usr/lib/libc.a(getcontext.o): in function `getcontext':
/usr/src/debug/glibc/2.29-r0/git/stdlib/../sysdeps/unix/sysv/linux/arm/getcontext.S:101: undefined reference to `_rtld_global_ro'
/opt/mydistro/1.0.0/sysroots/x86_64-pokysdk-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/8.3.0/real-ld: /opt/mydistro/1.0.0/sysroots/cortexa9t2hf-neon-poky-linux-gnueabi/usr/lib/libc.a(setcontext.o): in function `__startcontext':
/usr/src/debug/glibc/2.29-r0/git/stdlib/../sysdeps/unix/sysv/linux/arm/setcontext.S:100: undefined reference to `_rtld_global_ro'
collect2: error: ld returned 1 exit status
makefile:116: recipe for target 'ortable' failed
make: *** [ortable] Error 1
</snip>
What I can see from the output is, that both getcontext.S and setcontext.S are referencing to "_rtld_global_ro". What I do not understand is, why the glibc is located in the debug folder? Is this probably the issue? I have sourced the SDK using following command: source /opt/mydistro/1.0.0/environment-setup-cortexa9t2hf-neon-poky-linux-gnueabi Here's image bb file (which I have used for building the SDK using this command (bitbake my-image -c populate_sdk). require recipes-extended/images/core-image-full-cmdline.bb
IMAGE_INSTALL_append = " \
emmy-w1-driver-sdiosdio \
emmy-w1-systemd \
eth-systemd \
can-systemd \
can-utils \
lighttpd \
dnsmasq \
parted \
swupdate \
swupdate-www \
u-boot-fw-utils \
linux-firmware-imx-sdma-imx6q \
"
TOOLCHAIN_HOST_TASK_append = " nativesdk-perl-modules"
SDKIMAGE_FEATURES_append = " staticdev-pkgs"
Thanks. -- Rob
|
|
|
|
Bel Hadj Salem Talel <bhstalel@...>
Hi all,
I have a problem using python-setuptools with yocto when bitbaking any recipe that inherits setuptools , or even when I execute "bitbake setuptools" but there is no problem with setuptools3, but I need to use python2 for now. Here is the log: ------------------------------ ERROR: 176 unbuildable tasks were found. ########################################## | ETA: 0:00:00 These are usually caused by circular dependencies and any circular dependency chains found will be printed below. Increase the debug level to see a list of unbuildable tasks. Identifying dependency loops (this may take a short while)... ERROR: Dependency loop #1 found: Task virtual:native:/media/talel/data/sumo/sources/poky/meta/recipes-devtools/python/python-setuptools_40.0.0.bb:do_compile (dependent Tasks ['python-setuptools_40.0.0.bb:do_configure']) Task virtual:native:/media/talel/data/sumo/sources/poky/meta/recipes-devtools/python/python-setuptools_40.0.0.bb:do_install (dependent Tasks ['python-setuptools_40.0.0.bb:do_compile']) Task virtual:native:/media/talel/data/sumo/sources/poky/meta/recipes-devtools/python/python-setuptools_40.0.0.bb:do_populate_sysroot (dependent Tasks ['python-setuptools_40.0.0.bb:do_install']) Task virtual:native:/media/talel/data/sumo/sources/poky/meta/recipes-devtools/python/python-setuptools_40.0.0.bb:do_prepare_recipe_sysroot (dependent Tasks ['python-setuptools_40.0.0.bb:do_populate_sysroot', 'python-native_2.7.15.bb:do_populate_sysroot', 'python-setuptools_40.0.0.bb:do_fetch']) Task virtual:native:/media/talel/data/sumo/sources/poky/meta/recipes-devtools/python/python-setuptools_40.0.0.bb:do_configure (dependent Tasks ['python-setuptools_40.0.0.bb:do_prepare_recipe_sysroot', 'python-setuptools_40.0.0.bb:do_patch']) ERROR: Command execution failed: 1 ------------------------------ Thansk, Talel
|
|
|
|
How to add Percona Server for MySQL to poky 2.7.1
B.Sathish Kumar
Hi,
Does anyone have tried adding Percona Server for MySQL to poky 2.7.1 ? URL reference - https://www.percona.com/doc/percona-server/8.0/installation.html Any suggestion to (easily) include this package with its dependencies ? Thanks. ::DISCLAIMER:: ________________________________ The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. ________________________________
|
|
|
|
[meta-security][PATCH] bastille: Deleted redundant inherit to fix error when enable multilib.
zhengruoqin
There is no need to inherit module-base. Because this inherit will stop
bastille to build to lib32-bastille. Signed-off-by: Zheng Ruoqin <zhengrq.fnst@...> --- recipes-security/bastille/bastille_3.2.1.bb | 2 -- 1 file changed, 2 deletions(-) diff --git a/recipes-security/bastille/bastille_3.2.1.bb b/recipes-security/bastille/bastille_3.2.1.bb index e9accb5..0290cae 100644 --- a/recipes-security/bastille/bastille_3.2.1.bb +++ b/recipes-security/bastille/bastille_3.2.1.bb @@ -9,8 +9,6 @@ DEPENDS = "virtual/kernel" RDEPENDS_${PN} = "perl bash tcl perl-module-getopt-long perl-module-text-wrap lib-perl perl-module-file-path perl-module-mime-base64 perl-module-file-find perl-module-errno perl-module-file-glob perl-module-tie-hash-namedcapture perl-module-file-copy perl-module-english perl-module-exporter perl-module-cwd libcurses-perl coreutils" FILES_${PN} += "/run/lock/subsys/bastille" -inherit module-base - SRC_URI = "http://sourceforge.net/projects/bastille-linux/files/bastille-linux/3.2.1/Bastille-3.2.1.tar.bz2 \ file://AccountPermission.pm \ file://FileContent.pm \ -- 2.17.1
|
|
|
|
[ptest-runner][PATCH v2] Fix inappropriate ioctl when detaching tty
Tero Kinnunen
Fixes error
ERROR: Unable to detach from controlling tty, Inappropriate ioctl for device when running multiple ptests ptest-runner a b or when invoked over ssh single command, like $ ssh localhost ptest-runner For ssh case, fd 0 is not a tty. (isatty(0) is false). When running multiple ptests, deattach for parent needs to be done only once. Signed-off-by: Tero Kinnunen <tero.kinnunen@...> --- utils.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/utils.c b/utils.c index a8ba190..a4e190e 100644 --- a/utils.c +++ b/utils.c @@ -437,6 +437,9 @@ run_ptests(struct ptest_list *head, const struct ptest_options opts, break; } fprintf(fp, "START: %s\n", progname); + if (isatty(0) && ioctl(0, TIOCNOTTY) == -1) { + fprintf(fp, "ERROR: Unable to detach from controlling tty, %s\n", strerror(errno)); + } PTEST_LIST_ITERATE_START(head, p) char *ptest_dir = strdup(p->run_ptest); if (ptest_dir == NULL) { @@ -444,9 +447,6 @@ 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\n", strerror(errno)); -- 2.25.1
|
|
|
|
Upgrading a group of packages
aensminger@...
Hello! I'm new to yocto, and working in an inherited system, and a first time poster, so forgive any ignorance.
I'm looking for a way to group packages together, and specify the sub-package versions such that you can upgrade them all together. My approach so far has been to create a group package, let's say in a recipe called group-one_1.0.bb. This recipe has PR = "r1" defines RDEPENDS = "package-a (=1.0) package-b (=1.3)" as a way of making sure these are installed with the specified versions. We use opkg as the package manager, so I am expecting `opkg install group-one` to also install/upgrade package-a to 1.0 and package-b to 1.3, but it's not doing that. If package-b is already installed at 1.0, it stays at 1.0. Is there some built-in approach to this type of organization, or some best-practices around the way to go about it? Thanks much, Alex Ensminger
|
|
|
|
Re: Add application with library to target
On 7/8/20 2:37 AM, Kjeld Flarup via lists.yoctoproject.org wrote:
I have a functioning Yocto build today, but two of the recipes areI think eSDK might be good fit for your usecase. https://www.yoctoproject.org/docs/current/sdk-manual/sdk-manual.html#sdk-extensible
|
|
|
|
Re: [ptest-runner][PATCH] Fix inappropriate ioctl when detaching tty
Anibal Limon
On Wed, 8 Jul 2020 at 01:46, Tero Kinnunen <tero.kinnunen@...> wrote: On Tue, Jul 7, 2020 at 06:49 AM, Anibal Limon wrote: Agree, Add isatty(0) and move that validation outside the loop. Anibal
|
|
|
|
DNF package reinstallation
Hugh Boddington
I’ve got a fresh image, hot off the press with a clean install from dunfell (febbe2944c…). I deploy it to my target machine as a fresh install, overwriting the whole storage array. I’m using DNF as my package manager and I copy the packages from the build output to my web server. On the target machine, I run ‘dnf upgrade’ and it hits the package repo and tells me that there’s a number of packages that need to be ‘reinstalled’. No upgrades, conflicts etc – just reinstalled. The packages don’t appear to have much in common – some are packages from my layers, some are unmodified poky packages. I cannot figure out why dnf thinks they need to be reinstalled when it’s a fresh install and there’s only one version of everything. I also can’t figure out the magic incantation to get dnf to tell me how it arrived at this conclusion.
Can anyone shed any light on this problem? It’s driving me mad. If I allow it to reinstall the packages and re-run ‘dnf upgrade’ I just get the same reinstallation list.
|
|
|
|
Re: ERROR: iso-codes-4.4-r0
Mikko Rapeli <mikko.rapeli@...>
Hi,
On Wed, Jul 08, 2020 at 07:52:30AM -0700, Pankaj Vinadrao Joshi wrote: I am trying to build yocto image for RPI4 but i am getting following errorDebian developers changed branch names in their repository. Fixed in latest master and dunfell branches so either update or cherry-pick the changes: https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=dunfell&id=c253fd28ad26b4996666b0794dfee1d59c14e3ca https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=75e91b8e52ec77398e6b0fc09456e971662d9d7e Cheers, -Mikko
|
|
|
|
Re: ERROR: iso-codes-4.4-r0
Quentin Schulz
Hi Pankaj,
On Wed, Jul 08, 2020 at 07:52:30AM -0700, Pankaj Vinadrao Joshi wrote: I am trying to build yocto image for RPI4 but i am getting following errorUpdate your dunfell branch (should be at commit c253fd28ad26b4996666b0794dfee1d59c14e3ca) Quentin
|
|
|
|
ERROR: iso-codes-4.4-r0
Pankaj Vinadrao Joshi
I am trying to build yocto image for RPI4 but i am getting following error
pankaj@exaleap-Inspiron-3584:~/raspberrypi4_image$ bitbake core-image-sato Parsing recipes: 100% |######################################################################################################################################################################| Time: 0:09:59
Parsing of 2198 .bb files complete (0 cached, 2198 parsed). 3282 targets, 147 skipped, 0 masked, 0 errors.
NOTE: Resolving any missing task queue dependencies
Build Configuration:
BB_VERSION = "1.46.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "universal"
TARGET_SYS = "arm-poky-linux-gnueabi"
MACHINE = "raspberrypi4"
DISTRO = "poky"
DISTRO_VERSION = "3.1"
TUNE_FEATURES = "arm vfp cortexa7 neon vfpv4 thumb callconvention-hard"
TARGET_FPU = "hard"
meta
meta-poky
meta-yocto-bsp = "dunfell:9c8049068406532c3dd5d8906c595218b0fefd40"
meta-oe
meta-python
meta-networking
meta-multimedia = "dunfell:e413c1ef621688e69bb7830bb3151ed23b30b73e"
meta-raspberrypi = "master:5ac6f013339b0b1ab2d71f9f6af48a186e126c19"
Initialising tasks: 100% |###################################################################################################################################################################| Time: 0:00:18
Sstate summary: Wanted 1395 Found 0 Missed 1395 Current 1738 (0% match, 55% complete)
NOTE: Executing Tasks
WARNING: iso-codes-4.4-r0 do_fetch: Failed to fetch URL git://salsa.debian.org/iso-codes-team/iso-codes.git;protocol=http, attempting MIRRORS if available
ERROR: iso-codes-4.4-r0 do_fetch: Fetcher failure: Unable to find revision 38edb926592954b87eb527124da0ec68d2a748f3 in branch master even from upstream
ERROR: iso-codes-4.4-r0 do_fetch: Fetcher failure for URL: 'git://salsa.debian.org/iso-codes-team/iso-codes.git;protocol=http'. Unable to fetch URL from any source.
ERROR: Logfile of failure stored in: /home/pankaj/raspberrypi4_image/tmp/work/all-poky-linux/iso-codes/4.4-r0/temp/log.do_fetch.24501
ERROR: Task (/home/pankaj/Yocto-practice/poky/meta/recipes-support/iso-codes/iso-codes_4.4.bb:do_fetch) failed with exit code '1'
can someone help me how i can resolve this error?
|
|
|
|
Quentin Schulz
Hi Scott,
On Wed, Jul 08, 2020 at 07:15:17AM -0700, sdw@... wrote: Dear Yocto community,Up till there, this discussion would probably fit some kernel communities more than the Yocto one. A few things though: - Bear in mind that using bitbake -c menuconfig virtual/kernel, the changes aren't permanent. If there's a clean rebuild of the kernel for some reason, your changes will be overwritten, you need to create a patch for it (or take a defconfig) and add it to your kernel recipe (or fork the kernel repo and add your own defconfig), - Modules aren't shipped by default by Yocto, so you need either to add kernel-modules to IMAGE_INSTALL or probably smarter to have it in your machine configuration file in MACHINE_EXTRA_RRECOMMENDS, this will install **all** kernel modules created by yocto, or just add kernel-module-uio-pdrv-genirq (probably, don't know the exact name of it) the same way to only have uio, Quentin
|
|
|
|
sdw@...
Dear Yocto community,
I am hoping that you can provide advice on configuring UIO to handle a GPIO interrupt from user space. I found an excellent summary at https://yurovsky.github.io/2014/10/10/linux-uio-gpio-interrupt.html and have tried to follow it as well as I can, being a newcomer to Yocto and embedded Linux. We are using a Variscite DART-MX8M-MINI development kit, with the i.MX8M Mini processor on a System-on-Module. I have enabled spidev, which I am using to communicate with an ADS1299 EEG analog front end from TI. It generates a “data ready” interrupt DRDY# (active low). I’d like to be able to handle this falling-edge interrupt by connecting it to a GPIO (GPIO1_0) and either read() or poll() to wait for an interrupt, and can then read the acquired data using /dev/spidev0.0. In my device tree, I have added the following under my &ecspi1 node. I am not certain this is the correct place to add this information, or if I can simply add it within the device tree “root” node “/ {“. I would appreciate your advice on the best place add this information! // Added for DRDY# interrupt on GPIO1_0 from user space user_io@0 { compatible = "mydevice,generic-uio,ui_pdrv"; status = "okay"; interrupt-parent = <&gpio1>; interrupts = <0 IRQ_TYPE_EDGE_FALLING>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_user_io>; }; Under my dts &iomuxc node, the various pinctrl groups are defined. I added the following for GPIO1_0: // Added for DRDY# interrupt on GPIO1_0 from user space pinctrl_user_io: user_io-0 { fsl,pins = < MX8MM_IOMUXC_GPIO1_IO00_GPIO1_IO0 0x1c0 >; }; This should configure the pin to enable a pull-up. I have modified my kernel .config file via 'bitbake -c menuconfig virtual/kernel', and it contains the following entries: CONFIG_UIO=y CONFIG_UIO_PDRV_GENIRQ=m The “y” setting for CONFIG_UIO was evidently due to other dependencies in the provided configuration. I then built the SD card image using 'bitbake fsl-image-qt5', and programmed it onto my SD card. However, when I boot the board up, I cannot see /dev/uio0 or run the modprobe command as specified in the description at the link provided above: root@imx8mm-var-dart:~# ls /dev/u* /dev/ubi_ctrl /dev/udev_network_queue /dev/uhid /dev/uinput /dev/urandom root@imx8mm-var-dart:~# modprobe uio_pdrv_genirq of_id="mydevice,generic-uio,ui_pdrv" modprobe: FATAL: Module uio_pdrv_genirq not found in directory /lib/modules/4.19.35-imx8mm+ge6d3e3fefe4e I used grep to look for “uio” in the /lib/modules directory, and only found the following: root@imx8mm-var-dart:/lib/modules/4.19.35-imx8mm+ge6d3e3fefe4e# grep -RnI uio . ./modules.builtin:270:kernel/drivers/uio/uio.ko I am stumped, and think I must have something wrong in my .dts file, my .config file, or in the packages/libraries added to the Yocto image. Do you have any suggestions for how to diagnose/fix this problem? I can provide my .config file, .dts file, or any other information, but I am not sure how they should be added for access by the group. UIO apparently is a "preferred" way to handle writing simple device drivers from user space. Do I need to add something to Yocto to enable UIO and UIO_PDRV_GENIRQ? Thank you for your help, and kind regards, Scott
|
|
|
|
Re: Broken dunfell branch
Stefano Babic
Hi Guy,
On 08.07.20 15:15, Guy Morand wrote: Hallo Yocto deveopers!Do you have meta-swupdate in your layers, too, and are you using -master (see commit ece400ed5) ? Best regards, Stefano Babic Best regards, -- ===================================================================== DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic@... =====================================================================
|
|
|
|
Re: Broken dunfell branch
Martin Jansa
This 0001-mtd-utils-Fix-return-value-of-ubiformat.patch patch was recently backported to dunfell in check with "bitbake -e mtd-utils" to see which other layer in your build adds the same patch or changes SRCREV to newer commit which already contains the same change from upstream.
On Wed, Jul 8, 2020 at 3:15 PM Guy Morand <guy@...> wrote: Hallo Yocto deveopers!
|
|
|