Re: [yocto] How to fix SSH interfactive promotion for Yocto Linux embedded system
You're using busybox's scp, which is limited compared to openssh. If you want to use openssh's binaries install openssh-clients, otherwise adapt your options to work with busybox's scp. Ross On Thu, 25 Jul 2019 at 02:10, JH wrote: > > Hi, > > I am running busybox in imx6 using ssh and scp in shell scripts, but I > troubled to run the scripts to run ssh and scp, it did not have ssh > options stopped at following: > > scp -o ServerAliveInterval=60 -o ExitOnForwardFailure=yes -o > ServerAliveCountMax=3 -o StrictHostKeyChecking=no -o > UserKnownHostsFile=/dev/null ... > > ECDSA key fingerprint is SHA256:rAS+4gVqPJj7yfVDHlhG1g5bQP+VgMczooGifv+H9vk. > Are you sure you want to continue connecting (yes/no) > > cp: can't stat '-o': No such file or directory > cp: can't stat 'ServerAliveInterval=60': No such file or directory > cp: can't stat '-o': No such file or directory > cp: can't stat 'ExitOnForwardFailure=yes': No such file or directory > cp: can't stat '-o': No such file or directory > cp: can't stat 'ServerAliveCountMax=3': No such file or directory > cp: can't stat '-o': No such file or directory > cp: can't stat 'StrictHostKeyChecking=no': No such file or directory > cp: can't stat '-o': No such file or directory > cp: can't stat 'UserKnownHostsFile=/dev/null': No such file or directory > root@solar:/tmp# ssh-keyscan SaController >> /home/root/.ssh/known_hosts > > What will be effective and simple solution in Yocto? > > - Replace busybox by bash recipe. > > - Install openssh-client to run ssh-keyscan to write the target to > .ssh/known_hosts > > Appreciate your advice for Yocto Linux embedded system. > > Thank you. > > Kind regards, > > - jupiter > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] No GNU_HASH in the elf binary
On Mon, 22 Jul 2019 at 21:13, Madhu Krishnamurthy wrote: > INSANE_SKIP_mlc = "ldflags" > INSANE_SKIP_mlc-dev = "ldflags" > INHIBIT_PACKAGE_DEBUG_SPLIT = "1" > INHIBIT_PACKAGE_STRIP = "1" > > But after adding that I still get this error. > ERROR: mem-tst-0.1 do_package_qa: QA Issue: No GNU_HASH in the elf binary: > '/home/cluser/ac/z_cpu/build/tmp/work/corei7-64-poky-linux/mem/tst-0.1/packages-split/mem/usr/local/flex_pkgs/diags/mlc' > [ldflags] The _mlc part is the package name, which isn't mlc. Use INSANE_SKIP_mem-tst. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [OE-core] RFC: dropping official support for Debian 8 / Opensuse 42.3
On Thu, 18 Jul 2019 at 07:04, Adrian Bunk wrote: > > Now that both Debian 8 and OpenSuse 42.3 are end-of-life and no longer > > formally supported, we think it's time to drop them from the supported > > distribution list. > > Debian 8 is still LTS-supported for a year, unless there is urgency to > drop support for it the right time for dropping would be after 2.8 > (2.9 release and Debian 8 LTS EOL will both be in Q2 2020). I'm inclined to dropping 8 and just supporting 9 and 10. We don't *need* to exercise every distro. > Should OpenSuse be dropped, or just the version upgraded to 15.1? 42.3 dropped. 15.1 should be it's replacement, yes. This is already being exercised on the autobuilder. > Fedora 28 is also unsupported (but will be the basis of CentOS 8). Good point, and we also don't have Fedora 30 in the list. Again, this is already being exercised on the autobuilder. > CentOS 7 is based on Fedora 19 from 2013. > > This is the oldest currently supported distribution, and when to remove > support for it (replacing it with the not yet existing CentOS 8) should > IMHO be part of this discussion. Centos 7 support is, I believe, already patchy - I think we mandate the buildtools for that? Any idea what the support plan for Centos 7 will be once 8 is released, whenever that is? Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] RFC: dropping official support for Debian 8 / Opensuse 42.3
Hi, Now that both Debian 8 and OpenSuse 42.3 are end-of-life and no longer formally supported, we think it's time to drop them from the supported distribution list. Initially this involves removing them from the SANITY_TESTED_DISTROS list in Poky, at some point during this cycle we may remove those distributions from the Yocto Project autobuilder to add more workers for other supported distributions. It is expected that the next release will probably work on those two distributions, there are no plans to do new and exciting things dropping these unsupported distributions enables -- like increasing the minimum Python version to 3.5 until after the 2.8 release in October. Please, if this impacts you, speak up now. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Patching a file in $WORKDIR
On Tue, 16 Jul 2019 at 17:45, Siegel, Jeffrey (Nokia - US/Murray Hill) wrote: > I am trying to use a bbappend file to patch a file in $WORKDIR. To my > understanding, the native Yocto patching process only works for patching > files in $S. No, the default directory for patch application is $S (for obvious reasons). You can change the path that is patched by using the `patchdir` parameter: https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-SRC_URI Also as Gabriele said, only .patch and .diff files are applied automatically. Best to rename to inputrc.patch. > Using devshell, I have confirmed that the “patch” program being executed is > the one from the Yocto environment ($BUILDDIR/tmp-glibc/hosttools), not the > build host. Have a look at what hosttools/patch actually is: you'll see it's just a symlink to /usr/bin/patch. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] wpewebkit, cog and libgles2
On Tue, 16 Jul 2019 at 18:37, Andy Pont wrote: > ERROR: Nothing PROVIDES 'libepoxy' (but > /home/me/yocto/sources/meta-webkit/recipes-browser/wpewebkit/wpewebkit_2.24.2.bb > DEPENDS on or otherwise requires it) > libepoxy was skipped: missing required distro feature 'opengl' (not in > DISTRO_FEATURES) > > despite my local.conf containing: > > DISTRO_FEATURES_append = " opengl libepoxy” > > Can someone put me out of my misery? Remove libepoxy from there, DISTRO_FEATURES are abstract and libepoxy isn't a valid one. My best suggestion would be: $ bitbake -e libepoxy | less Search that until you find the DISTRO_FEATURES= and see if it it contains opengl. It presumably doesn't, and above the assignment it will tell you what removed it (or the absence of something adding it). Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Pre-installing node.js packages
The proper way would be to write a recipe for each package you wish to add. Ross On Tue, 16 Jul 2019 at 16:04, Andy Pont wrote: > > Hello, > > Is there a way to add node.js packages into a build? I’m trying to > avoid having to include npm and compiler into my target image. > > -Andy. > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] wpewebkit, cog and libgles2
On Tue, 16 Jul 2019 at 13:53, Andy Pont wrote: > I am building for a Microchip (Atmel) SAMA5D2 using meta-atmel. We don’t > need OpenGL or 3D support - hence one of the reasons for picking the SAMA5D2 > which doesn’t have a hardware GPU. > > The options appear to be to either add software OpenGL support to the > configuration to resolve the dependency or tell wpewebkit not to want OpenGL > support. Well the libwpe build script says this: find_package(EGL REQUIRED) (https://github.com/WebPlatformForEmbedded/libwpe/blob/master/CMakeLists.txt) Which suggests that you can't build it without EGL. You should investigate whether EGL is simply an option, or whether it's used as a fundamental part of the rendering. If it's optional then the Mesa recipe can build a software GL implementation, if the latter then you'll need a new browser as software GL is *terrible*. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-gplv2][PATCH] gnupg: Enable native build support
Merged.
Ross
On Tue, 2 Jul 2019 at 17:03, Joshua Watt wrote:
>
> Adds support for building gnupg as a -native recipe.
>
> Signed-off-by: Joshua Watt
> ---
> recipes-support/gnupg/gnupg_1.4.7.bb | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/recipes-support/gnupg/gnupg_1.4.7.bb
> b/recipes-support/gnupg/gnupg_1.4.7.bb
> index 85636ab..a7fbd11 100644
> --- a/recipes-support/gnupg/gnupg_1.4.7.bb
> +++ b/recipes-support/gnupg/gnupg_1.4.7.bb
> @@ -84,6 +84,7 @@ EXTRA_OECONF = "--disable-ldap \
> "
>
> # Force gcc's traditional handling of inline to avoid issues with gcc 5
> +BUILD_CFLAGS += "-fgnu89-inline"
> CFLAGS += "-fgnu89-inline"
>
> do_install () {
> @@ -95,6 +96,8 @@ do_install () {
>
> # split out gpgv from main package
> RDEPENDS_${PN} = "gpgv"
> +RDEPENDS_${PN}_class-native = ""
> +
> PACKAGES =+ "gpgv"
> FILES_gpgv = "${bindir}/gpgv"
>
> @@ -104,3 +107,5 @@ FILES_${PN} = "${bindir}/* ${datadir}/${BPN}
> ${libexecdir}/${BPN}/*"
> PACKAGECONFIG ??= ""
> PACKAGECONFIG[curl] =
> "--with-libcurl=${STAGING_LIBDIR},--without-libcurl,curl"
> PACKAGECONFIG[libusb] =
> "--with-libusb=${STAGING_LIBDIR},--without-libusb,libusb-compat"
> +
> +BBCLASSEXTEND += "native"
> --
> 2.21.0
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Can't boot to initramfs
On Fri, 12 Jul 2019 at 15:38, Moritz Porst wrote:
> If I use the .wic image, APPEND is ignored. You need to write your own
> kickstart file for this and include --append option. This usually means
> copy what you need from existing files (check license compliance) and
> add what you need. See the yocto manual on kickstart files:
> https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#ref-kickstart
This is a bug in the wic files, and if they're still broken in master
then please send a patch.
Notably this was the fix I did for the wic files in meta-intel:
--- a/wic/systemd-bootdisk-microcode.wks
+++ b/wic/systemd-bootdisk-microcode.wks.in
@@ -10,4 +10,4 @@ part / --source rootfs --ondisk sda --fstype=ext4
--label platform --align 1024
-bootloader --ptable gpt --timeout=5 --append="rootwait
rootfstype=ext4 console=ttyS0,115200 console=tty0"
+bootloader --ptable gpt --timeout=5 --append="rootfstype=ext4 ${APPEND}"
Easy! :)
Ross
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] dev_pkgs feature caused conflict
file /lib/firmware/ti-connectivity/wl18xx-fw-4.bin from install of linux-firmware-wl12xx-1:0.0+git0+d114732723-r0.noarch conflicts with file from package firmware-wireless-wilink8-1.0-r0.cortexa9hf_neon file /lib/firmware/brcm/brcmfmac4330-sdio.bin from install of linux-firmware-bcm4330-1:0.0+git0+d114732723-r0.noarch conflicts with file from package firmware-wireless-brcm-1.0-r0.cortexa9hf_neon Looks like your BSP is shipping its own firmware (firmware-wireless-*) that ships the same files as linux-firmware. Speak to your BSP provider to detemine what one of those needs to be removed. Ross On Fri, 5 Jul 2019 at 10:40, Onur Eser wrote: > > Hello everyone, > > I am trying to build a toolchain for my image. Added line > IMAGE_FEATURES += "dev-pkgs" > to my local.conf file and rebuilt everything from zero. > It gives two conflict errors. > > Check my error log: > https://paste.ee/p/HbC5r#zh4fQsZhX9vAQEXQiwIqc7c2VkK82i2d > > Note: If I exclude the line > IMAGE_FEATURES += "dev-pkgs" > image is being builded and booted successfully. > But I need it to cross compile if I am not wrong. > If I include this line, following error shows up. > > Note2: My base image is core-image-weston. > My device is SolidRun Humming Board 2 i.MX6 ARMv7 > > Cheers, > Onur > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Poky build errors, help is needed
On Wed, 3 Jul 2019 at 20:54, Chad Gong wrote: > I opened the log.do_fetch file, and it looks like a file > git2_github.com.thkukuk.libnsl.tar.gz was downloaded from the mirror site > http://downloads.yoctoproject.org/mirror/sources/git2_github.com.thkukuk.libnsl.tar.gz > .Then an error happened with tar, as shown below: > > tar -xzf > /home/chad/mybuild-coreimageminimal-270-2/downloads/git2_github.com.thkukuk.libnsl.tar.gz > failed with exit code 2, output: > > gzip: stdin: not in gzip format > tar: Child returned status 1 > tar: Error is not recoverable: exiting now $ wget http://downloads.yoctoproject.org/mirror/sources/git2_github.com.thkukuk.libnsl.tar.gz ... $ file git2_github.com.thkukuk.libnsl.tar.gz git2_github.com.thkukuk.libnsl.tar.gz: gzip compressed data, last modified: Tue Jul 31 07:59:20 2018, from Unix $ tar ztvf git2_github.com.thkukuk.libnsl.tar.gz drwxr-xr-x pokybuild/users 0 2018-07-31 08:46 ./ -rw-r--r-- pokybuild/users 955 2018-07-31 08:46 ./packed-refs drwxr-xr-x pokybuild/users 0 2018-07-31 08:46 ./objects/ Can you see what happened to your local file? Still looks like you've got network issues. Oh, and you can share DL_DIR between builds, so I'd move it out of your build directory. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Json-Glib failed to build during the building of Weston image
On Thu, 4 Jul 2019 at 10:43, Zoran Stojsavljevic wrote: > Why Weston protocol? Why not classical X11 Client Server in user > space? Which DeskTop are U using in Ur YOCTO build? Weston is arguably superior to X11 in most respects, and for new platforms which are not tied to a classic X server I entirely recommend Weston over X. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Json-Glib failed to build during the building of Weston image
On Thu, 4 Jul 2019 at 09:46, Onur Eser wrote: > Hello Yocto Community! > When I was trying to build core-image-weston with meta-qt5 and meta-fsl-arm > layer for my imx6 (Humming Board 2 - Armv7) board, it gave an error on > compilation of the "jason-glib". I would suprised if my image was builded > without errors. I never could have finished a Yocto or Qt-cross building in > my life... > > So, my error log is, > > Got pkgconfig variable girdir : > Program g-ir-scanner found: YES > (/home/closx/poky/build/tmp-glibc/work/cortexa9hf-neon-oe-linux-gnueabi/json-glib/1.4.2-r0/recipe-sysroot-native/usr/bin/g-ir-scanner) > Adding test "array". > Adding test "boxed". > Adding test "builder". > Adding test "generator". > Adding test "gvariant". > Adding test "invalid". > Adding test "node". > Adding test "object". > Adding test "parser". > Adding test "path". > Adding test "reader". > Adding test "serialize-simple". > Adding test "serialize-complex". > Adding test "serialize-full". > ERROR: meson failed > WARNING: exit code 1 from a shell command. > ERROR: Function failed: do_configure (log file is located at > /home/closx/poky/build/tmp-glibc/work/cortexa9hf-neon-oe-linux-gnueabi/json-glib/1.4.2-r0/temp/log.do_configure.1) Can you share the full log.do_configure? Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Poky build errors, help is needed
On Wed, 3 Jul 2019 at 14:21, Chad Gong wrote: > I re-ran another build of the same configuration. This time there is no fetch > error for the file that failed last time. I looks each time I build, I get > different fetch error randomly. But this time the failed URL is git shown > below, and I cannot even use wget to download it. > > ERROR: libnsl2-native-1.2.0+gitAUTOINC+37c5ffe303-r0 do_fetch: Fetcher > failure for URL: 'git://github.com/thkukuk/libnsl'. Unable to fetch URL from > any source. > > $ wget git://github.com/thkukuk/libnsl > git://github.com/thkukuk/libnsl: Unsupported scheme ‘git’. Yes, wget is a HTTP fetcher, not a git fetcher. Look at the log.do_fetch for libnsl2-native (tmp/work/*/libnsl2-native/1.2.0/temp/log.do_fetch. That will tell you what is failing. Maybe you've a firewall that isn't allowing git out? Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Poky build errors, help is needed
On Tue, 2 Jul 2019 at 19:22, Chad Gong wrote: > Thank you for the advice. Which folder contains the recipe? Which method is > used to calculate the checksum? Please remember to ensure the list is copied. $ find . -name opkg-util*bb ./meta/recipes-devtools/opkg-utils/opkg-utils_0.4.1.bb You're on a different version so the filename won't be the same. For the MD5 sum, use md5sum. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Poky build errors, help is needed
Check that the checksum of the file you grabbed matches the recipe. There's a MD5 in the recipe that it is comparing against. Ross On Tue, 2 Jul 2019 at 16:25, Chad Gong wrote: > > Ross, Gabriele, > > I switched to branch 2.7. Still have the same problem as shown below. > > ERROR: opkg-utils-0.4.0-r0 do_fetch: Checksum failure fetching > http://git.yoctoproject.org/cgit/cgit.cgi/opkg-utils/snapshot/opkg-utils-0.4.0.tar.gz > > > When using wget, the files can be downloaded as shown below. > > $ wget > http://git.yoctoproject.org/cgit/cgit.cgi/opkg-utils/snapshot/opkg-utils-0.4.0.tar.gz > --2019-07-01 20:11:01-- > http://git.yoctoproject.org/cgit/cgit.cgi/opkg-utils/snapshot/opkg-utils-0.4.0.tar.gz > Resolving git.yoctoproject.org (git.yoctoproject.org)... 140.211.169.56 > Connecting to git.yoctoproject.org > (git.yoctoproject.org)|140.211.169.56|:80... connected. > HTTP request sent, awaiting response... 200 OK > Length: unspecified [application/x-gzip] > Saving to: ‘opkg-utils-0.4.0.tar.gz’ > > opkg-utils-0.4.0.tar.gz [ <=> > ] 29.82K --.-KB/sin 0.005s > > 2019-07-01 20:11:02 (5.97 MB/s) - ‘opkg-utils-0.4.0.tar.gz’ saved [30536] > > > > > > Chad Gong > Electrical Engineer > > Trijicon, Inc. > > > | P.O. Box 930059 > Wixom, Michigan 48393 US > cg...@trijicon.com | > > -Original Message- > From: Burton, Ross > Sent: Tuesday, July 02, 2019 9:00 AM > To: Chad Gong > Cc: yocto@yoctoproject.org > Subject: Re: [yocto] Poky build errors, help is needed > > CAUTION: This email originated from outside your organization. Exercise > caution when opening attachments or clicking links, especially from unknown > senders. > > On Tue, 2 Jul 2019 at 13:53, Chad Gong wrote: > > WARNING: m4-native-1.4.18-r0 do_fetch: Failed to fetch URL > > http://ftp.gnu.org/gnu/m4/m4-1.4.18.tar.gz, attempting MIRRORS if > > available > > $ wget http://ftp.gnu.org/gnu/m4/m4-1.4.18.tar.gz > URL transformed to HTTPS due to an HSTS policy > --2019-07-02 13:59:34-- https://ftp.gnu.org/gnu/m4/m4-1.4.18.tar.gz > Resolving ftp.gnu.org (ftp.gnu.org)... 209.51.188.20, 2001:470:142:3::b > Connecting to ftp.gnu.org (ftp.gnu.org)|209.51.188.20|:443... connected. > HTTP request sent, awaiting response... 200 OK > Length: 2006643 (1.9M) [application/x-gzip] Saving to: ‘m4-1.4.18.tar.gz’ > > m4-1.4.18.tar.gz > 100%[===>] > 1.91M 1.38MB/sin 1.4s > > 2019-07-02 13:59:36 (1.38 MB/s) - ‘m4-1.4.18.tar.gz’ saved [2006643/2006643] > > Looks like you've got networking problems inside the virtual machine. > Verify using wget that you can download those files successfully. > > Ross > > > > This electronic message contains information that may be > confidential, privileged, proprietary, or subject to the export control laws > of > the United States, including the Arms Export Control Act (22 U.S.C. 2571 et > seq.), the International Traffic in Arms Regulations (22 C.F.R. Part 120 > et seq.), and/or the Export Administration Regulations (15 C.F.R. Part 730 et > seq.). This information is intended for the use of the addressee only, and > if you are not the intended recipient, any disclosure, copying, distribution, > printing, or any other use of, the contents of this message is prohibited. > Any transfer, retransfer, or disclosure of this data to a Foreign Person > without > United States Government authorization is also prohibited. If you have > received this message in error, please notify the sender and destroy the > original message. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Poky build errors, help is needed
On Tue, 2 Jul 2019 at 13:53, Chad Gong wrote: > WARNING: m4-native-1.4.18-r0 do_fetch: Failed to fetch URL > http://ftp.gnu.org/gnu/m4/m4-1.4.18.tar.gz, attempting MIRRORS if available $ wget http://ftp.gnu.org/gnu/m4/m4-1.4.18.tar.gz URL transformed to HTTPS due to an HSTS policy --2019-07-02 13:59:34-- https://ftp.gnu.org/gnu/m4/m4-1.4.18.tar.gz Resolving ftp.gnu.org (ftp.gnu.org)... 209.51.188.20, 2001:470:142:3::b Connecting to ftp.gnu.org (ftp.gnu.org)|209.51.188.20|:443... connected. HTTP request sent, awaiting response... 200 OK Length: 2006643 (1.9M) [application/x-gzip] Saving to: ‘m4-1.4.18.tar.gz’ m4-1.4.18.tar.gz 100%[===>] 1.91M 1.38MB/sin 1.4s 2019-07-02 13:59:36 (1.38 MB/s) - ‘m4-1.4.18.tar.gz’ saved [2006643/2006643] Looks like you've got networking problems inside the virtual machine. Verify using wget that you can download those files successfully. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] QA notification for completed autobuilder build (yocto-2.7.1.rc1)
On Tue, 2 Jul 2019 at 08:05, Zoran Stojsavljevic wrote: > >> Runtime auto test for following platforms: > >> 1. MinnowTurbot 32-bit (Appolo Lake?) > >> 2. Coffee Lake (14nm 4th tock in the row) > >> 3. NUC 7 > >> 4. NUC 6 > >> 5. Edgerouter > >> 6. MPC8315e-rdb > >> 7. BeagleboneHm... > > At least first four from the list are IA (INTEL Architecture)... Maybe > even fifth (Edgerouter). Nummer Sieben (number 7 - Beagle Bone) should > move at least to numero due (number 2). IMHO. ;-) Some points: 1) Consider that a bullet list, not an ordered list 2) Are you surprised that Intel QA is testing on Intel hardware? 3) Edgerouter is MIPS: $ grep tune meta-yocto-bsp/conf/machine/edgerouter.conf require conf/machine/include/tune-mips64.inc So that's a selection of IA, MIPS, PPC, ARM. At least one of all the primary supported architectures. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto stucks when building!
First, Fido/1.8 is very old: released in April 2015 and is now out of support, has no security fixes, etc. So I'd first suggest upgrading to a supported release. If you can't, then the easiest thing to do would be to look at the log.do_compile for that recipe in your build directory, or use ps in 'forest' mode to see what process is hanging and figure out why that is. Ross On Mon, 1 Jul 2019 at 08:40, Onur Eser wrote: > > Hello, > I am trying to build a yocto for i.MX6, with a QT5 layer, everything is okay, > but it freezes on 2666th task! When 4 tasks are running at the same time in > normal, when it comes to 2666th, it is only one task and takes forever! (I > made it wait for one night) > > Build Configuration: > BB_VERSION= "1.26.0" > BUILD_SYS = "x86_64-linux" > NATIVELSBSTRING = "Ubuntu-16.04" > TARGET_SYS= "i586-poky-linux" > MACHINE = "qemux86" > DISTRO= "poky" > DISTRO_VERSION= "1.8.2" > TUNE_FEATURES = "m32 i586" > TARGET_FPU= "" > meta = "fido:87631919819b6f85f23f57689cd1065c64d7fb03" > meta-qt5 = "fido:90919b9d86988e7da01fa2c0a07246b5b5600a5d" > meta-fsl-arm = "fido:c9f259a4bf8472dfa3ff75f1c3fcbe5e0ded7aaf" > meta-solidrun-arm-imx6 = "fido:3e496c0895b0abf8d2aaca2c622246c1f9f3ed75" > meta-yocto > meta-yocto-bsp= "fido:87631919819b6f85f23f57689cd1065c64d7fb03" > > NOTE: Preparing RunQueue > NOTE: Executing SetScene Tasks > NOTE: Executing RunQueue Tasks > Currently 1 running tasks (2666 of 5960): > 0: attr-native-2.4.47-r0 do_compile (pid 3485) > > How to solve this? > Thanks, > Onur > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Creating a file within a recipe
The bash parser does have some bugs, and I think you just found one.
Probably easier to have a template on disk in SRC_URI, and sed in the
value you want.
Ross
On Fri, 28 Jun 2019 at 19:35, Aaron Biver wrote:
>
> I'd like to be able to create a file using the cat command in a recipe. The
> sub-goal is to have the file created somewhere I can actually find it:
>
> do_create_tebf0808() {
> cat > tebf0808.bif < all:
> {
> ${LATEST_TEBF0808_FW}
> }
> EOF
> }
>
> This fails at the "EOF" line:
> ERROR: ParseError at ...firmware.bb:43: unparsed line: 'EOF'
> | ETA: --:--:--
>
> Maybe sed would work better?
>
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Recursions problem with pre-built versioned libraries and oe_soinstall
On Thu, 27 Jun 2019 at 17:58, John McCabe wrote: > Exception: OSError: [Errno 40] too much recursions while resolving > '/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds/usr/lib/libTAO_PI_Server.so.2.2a_p15'; > loop in > '/build/tmp/work/cortexa9hf-neon-xilinx-linux-gnueabi/opendds/1.0-r0/packages-split/opendds/usr/lib/libTAO_PI_Server.so.2.2a_p15' > lrwxrwxrwx 1 jmccabe jmccabe 28 Jun 27 17:38 libTAO_PI_Server.so.2.2a_p15 > -> libTAO_PI_Server.so.2.2a_p15 > You can't deny that this is a symlink loop. Note that these are all the users of oe_libinstall in oe-core: $ git grep -l oe_soinstall meta/classes/utils.bbclass So I'm not massively surprised that it's buggy. In this case, it looks like the library either has an incorrect soname, or the install function isn't handling the soname being the same: it assumes that it is being passed libfoo.so.1.2.3 which has a soname of libfoo.so.1 and will copy libfoo.so.1.2.3 and then create libfoo.so.1 and libfoo.so symlinks.My recommendations: 1) Write a proper recipe instead of building code outside of OE and trying to copy it in by hand. Or, 2) Determine what the correct structure is regarding sonames, and either fix oe_soinstall or just use install/ln directly. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] bitbak command: No recipe available for
Then ensure that the oe-core or poky or whatever provides your meta/ layer is at the same version as the meta-bbb expects. Basically this should all be in the meta-bbb instructions, and if it isn't then ask them. I've never used meta-bbb. Ross On Thu, 27 Jun 2019 at 08:53, danwe wrote: > > Hi. > Thank you. Could you tell me how I can ensure that these are on the same > branch? There is just one meta-bbb I can download... > > Am Do., 27. Juni 2019 um 09:37 Uhr schrieb Burton, Ross > : >> >> The problem is that oe-core and meta-bbb are different releases so the >> versions don't match up. Ensure that oe-core and meta-bbb are on the >> same branch. >> >> Ross >> >> On Thu, 27 Jun 2019 at 07:33, danwe wrote: >> > >> > while using the command: >> > daniel@daniel-VirtualBox:~/bbb$ MACHINE=beaglebone bitbake >> > core-immage-full cmdline I get the following ouput: >> > >> > >> > Loading cache: 100% || Time: >> > 0:00:03 >> > >> > Loaded 1358 entries from dependency cache. >> > >> > Parsing recipes: 100% |##| Time: >> > 0:00:12 >> > >> > Parsing of 832 .bb files complete (829 cached, 3 parsed). 1361 targets, 65 >> > skipped, 0 masked, 0 errors. >> > >> > ERROR: No recipes available for: >> > >> > /home/daniel/meta-bbb/recipes-connectivity/openssh/openssh_7.%.bbappend >> > >> > /home/daniel/meta-bbb/recipes-qt/qt5/qtbase_git.bbappend >> > >> > /home/daniel/meta-bbb/recipes-support/ntp/ntp_4.2.%.bbappend >> > >> > >> > >> > Summary: There was 1 ERROR message shown, returning a non-zero exit code. >> > >> > >> > >> > How can I solve this? >> > >> > Thanks. >> > >> > Daniel >> > -- >> > ___ >> > yocto mailing list >> > yocto@yoctoproject.org >> > https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] bitbak command: No recipe available for
The problem is that oe-core and meta-bbb are different releases so the versions don't match up. Ensure that oe-core and meta-bbb are on the same branch. Ross On Thu, 27 Jun 2019 at 07:33, danwe wrote: > > while using the command: > daniel@daniel-VirtualBox:~/bbb$ MACHINE=beaglebone bitbake core-immage-full > cmdline I get the following ouput: > > > Loading cache: 100% || Time: > 0:00:03 > > Loaded 1358 entries from dependency cache. > > Parsing recipes: 100% |##| Time: > 0:00:12 > > Parsing of 832 .bb files complete (829 cached, 3 parsed). 1361 targets, 65 > skipped, 0 masked, 0 errors. > > ERROR: No recipes available for: > > /home/daniel/meta-bbb/recipes-connectivity/openssh/openssh_7.%.bbappend > > /home/daniel/meta-bbb/recipes-qt/qt5/qtbase_git.bbappend > > /home/daniel/meta-bbb/recipes-support/ntp/ntp_4.2.%.bbappend > > > > Summary: There was 1 ERROR message shown, returning a non-zero exit code. > > > > How can I solve this? > > Thanks. > > Daniel > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] yocto recipe error
On Tue, 25 Jun 2019 at 17:47, Elliott, Alexander L CIV USN
NAVSURFWARCEN DAH VA (USA) wrote:
> RDEPENDS_${PN} = "libgcc_s.so.1"
You RDEPENDS on other package, not filenames.
RDEPENDS_${PN} = "libgcc"
Ross
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] build on CVE is failing
Yes, you're right, this is a bug in the new functionality.
The usual variables are in the data store, so you can get them with
e.g. d.getVar("http_proxy"), as you can clearly replicate the failure
would you be able to attempt a patch?
Ross
On Tue, 25 Jun 2019 at 11:14, Vignesh Rajendran (RBEI/ECF3)
wrote:
>
> Hi,
>
>
>
> I was trying to check the CVE feature on Yocto.
>
>
>
> I couldn’t succeed the build with CVE.
>
> https://pastebin.com/m7hNcNcm
>
>
>
> There seems like proxy environment doesn’t recognized inside
> do_populate_cve_db.
>
>
>
> ERROR: cve-update-db-1.0-r0 do_populate_cve_db:
> HTTPSConnectionPool(host='nvd.nist.gov', port=443):
>
> Max retries exceeded with url: /feeds/json/cve/1.0/nvdcve-1.0-2002.meta
> (Caused by NewConnectionError(' object at 0x7f787f1a8908>: Failed to establish a new connection: [Errno -2]
> Name or service not known',))
>
>
>
> I am using HEAD of poky master branch.
>
>
>
> Best regards,
>
> Rajendran Vignesh
> RBEI/ECF3
>
> Tel. +91 422 676-5103 | Threema Work: +914226765103
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Are native packages dependencies listed in license.manifest?
The image manifest lists what is being *distributed* so doesn't include native dependencies. Ross On Mon, 24 Jun 2019 at 19:50, wrote: > > Hi, > I’m currently working to remove all GPLv3 packages included in my image. > I was using the license manifest file to list the remaining GPLv3 packages to > remove. > While I was trying to remove gdbm, I ecountered some native dependencies. > When I looked at the license.manifest file, gdbm was still listed. > So I was asking myself if I still had packages that depends/includes gdbm > hidden somewhere or it’s because the license.manifest also list packages used > on the build host even if they are not included in the image. > For example, if curl-native is used in a recipe will curl be listed in > license.manifest even if curl is not in the image? > > So in other words, does license.manifest also includes native packages or it > only lists the packages that make up the image (included in the image)? > > Thanks for the support, > > PLB > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Remove include /usr/include/SDL2
The problem is that kivy is ignoring all of the attempts at telling it to build in a sysroot and *still* looking in /usr. This is a clear cut bug in the kivy build system, so you'll have to look at that and see how to fix it. Ross On Mon, 24 Jun 2019 at 18:32, Mauro Ziliani wrote: > > Hi all. > > I'm trying to compile kivy inside yocto for a 586 board. > > The compilation fails because the i586-cc uses /usr/include and > /usr/local/include paths as INCLUDEDIR (togheter with others paths) > > > How can avoid this? > > > I need /usr/include o /usr/local/include for other apps, but I don't > like the /usr/include is involved in yocto > > > MZ > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-gplv2][warrior][PATCH] bc: use u-a for bc as well
Whoops. Done :)
On Fri, 21 Jun 2019 at 14:18, Martin Jansa wrote:
>
> No problem, thanks for quick response.
>
> Looks like this patch wasn't merged in master as well (I thought it was), can
> you please push it as well.
>
> Thanks
>
> On Fri, Jun 21, 2019 at 2:59 PM Burton, Ross wrote:
>>
>> Done, sorry.
>>
>> Ross
>>
>> On Fri, 21 Jun 2019 at 13:53, Martin Jansa wrote:
>> >
>> > ping for warrior
>> >
>> > On Tue, Jun 11, 2019 at 9:08 AM Martin Jansa
>> > wrote:
>> >>
>> >> * bc can be provided by busybox as well (e.g. if you have your own
>> >> defconfig and forget to explicitly disable it:
>> >> ...
>> >> *
>> >> * Miscellaneous Utilities
>> >> *
>> >> adjtimex (4.7 kb) (ADJTIMEX) [N/y/?] n
>> >> bbconfig (9.7 kb) (BBCONFIG) [N/y/?] n
>> >> bc (45 kb) (BC) [Y/n/?] (NEW) dc (36 kb) (DC) [Y/n/?] y
>> >> Use bc code base for dc (larger, more features) (FEATURE_DC_BIG) [Y]
>> >> (NEW) y
>> >> Interactive mode (+4kb) (FEATURE_BC_INTERACTIVE) [Y/n/?] (NEW)
>> >> Enable bc/dc long options (FEATURE_BC_LONG_OPTIONS) [Y/n] (NEW) beep (2.4
>> >> kb) (BEEP) [N/y/?] n
>> >> chat (6.3 kb) (CHAT) [N/y/?] n
>> >> conspy (10 kb) (CONSPY) [N/y/?] n
>> >> ...
>> >> ), causing conflict in u-a:
>> >>
>> >> update-alternatives: Error: not linking /usr/bin/bc to
>> >> /bin/busybox.nosuid since /usr/bin/bc exists and is not a link
>> >>
>> >> and then whole do_rootfs or do_populate_sdk to fail because busybox
>> >> postinst is failing:
>> >>
>> >> do_populate_sdk: Postinstall scriptlets of ['busybox'] have failed. If
>> >> the intention is to defer them to first boot,
>> >> then please place them into pkg_postinst_ontarget_${PN} (). Deferring
>> >> to first boot via 'exit 1' is no longer supported.
>> >>
>> >> Signed-off-by: Martin Jansa
>> >> ---
>> >> recipes-extended/bc/bc_1.06.bb | 2 +-
>> >> 1 file changed, 1 insertion(+), 1 deletion(-)
>> >>
>> >> diff --git a/recipes-extended/bc/bc_1.06.bb
>> >> b/recipes-extended/bc/bc_1.06.bb
>> >> index d8c8a86..3de1b24 100644
>> >> --- a/recipes-extended/bc/bc_1.06.bb
>> >> +++ b/recipes-extended/bc/bc_1.06.bb
>> >> @@ -20,7 +20,7 @@ SRC_URI[sha256sum] =
>> >> "4ef6d9f17c3c0d92d8798e35666175ecd3d8efac4009d6457b5c99cea7
>> >>
>> >> inherit autotools texinfo update-alternatives
>> >>
>> >> -ALTERNATIVE_${PN} = "dc"
>> >> +ALTERNATIVE_${PN} = "bc dc"
>> >> ALTERNATIVE_PRIORITY = "100"
>> >>
>> >> BBCLASSEXTEND = "native"
>> >> --
>> >> 2.17.1
>> >>
>> > --
>> > ___
>> > yocto mailing list
>> > yocto@yoctoproject.org
>> > https://lists.yoctoproject.org/listinfo/yocto
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-gplv2][warrior][PATCH] bc: use u-a for bc as well
Done, sorry.
Ross
On Fri, 21 Jun 2019 at 13:53, Martin Jansa wrote:
>
> ping for warrior
>
> On Tue, Jun 11, 2019 at 9:08 AM Martin Jansa wrote:
>>
>> * bc can be provided by busybox as well (e.g. if you have your own
>> defconfig and forget to explicitly disable it:
>> ...
>> *
>> * Miscellaneous Utilities
>> *
>> adjtimex (4.7 kb) (ADJTIMEX) [N/y/?] n
>> bbconfig (9.7 kb) (BBCONFIG) [N/y/?] n
>> bc (45 kb) (BC) [Y/n/?] (NEW) dc (36 kb) (DC) [Y/n/?] y
>> Use bc code base for dc (larger, more features) (FEATURE_DC_BIG) [Y]
>> (NEW) y
>> Interactive mode (+4kb) (FEATURE_BC_INTERACTIVE) [Y/n/?] (NEW)
>> Enable bc/dc long options (FEATURE_BC_LONG_OPTIONS) [Y/n] (NEW) beep (2.4
>> kb) (BEEP) [N/y/?] n
>> chat (6.3 kb) (CHAT) [N/y/?] n
>> conspy (10 kb) (CONSPY) [N/y/?] n
>> ...
>> ), causing conflict in u-a:
>>
>> update-alternatives: Error: not linking /usr/bin/bc to /bin/busybox.nosuid
>> since /usr/bin/bc exists and is not a link
>>
>> and then whole do_rootfs or do_populate_sdk to fail because busybox
>> postinst is failing:
>>
>> do_populate_sdk: Postinstall scriptlets of ['busybox'] have failed. If the
>> intention is to defer them to first boot,
>> then please place them into pkg_postinst_ontarget_${PN} (). Deferring to
>> first boot via 'exit 1' is no longer supported.
>>
>> Signed-off-by: Martin Jansa
>> ---
>> recipes-extended/bc/bc_1.06.bb | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/recipes-extended/bc/bc_1.06.bb b/recipes-extended/bc/bc_1.06.bb
>> index d8c8a86..3de1b24 100644
>> --- a/recipes-extended/bc/bc_1.06.bb
>> +++ b/recipes-extended/bc/bc_1.06.bb
>> @@ -20,7 +20,7 @@ SRC_URI[sha256sum] =
>> "4ef6d9f17c3c0d92d8798e35666175ecd3d8efac4009d6457b5c99cea7
>>
>> inherit autotools texinfo update-alternatives
>>
>> -ALTERNATIVE_${PN} = "dc"
>> +ALTERNATIVE_${PN} = "bc dc"
>> ALTERNATIVE_PRIORITY = "100"
>>
>> BBCLASSEXTEND = "native"
>> --
>> 2.17.1
>>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Share SSTATE_DIR between instances
It's always a good idea to share sstate between builds. Ross On Mon, 17 Jun 2019 at 12:32, Gabriele Zampieri wrote: > > Hi all, > > is it a good idea to share the SSTATE_DIR between a docker container (used > with GitLab pipelines) and the local bitbake instance? They both work on the > same MACHINE. > > Gabriele > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Multiple MACHINEs and DISTROs: When to use own build dir, SSTATE_DIR, DL_DIR ?
On Sun, 9 Jun 2019 at 23:19, Ulf Samuelsson wrote: > When you have the same machine, and the recipes have variants > which are DISTRO dependent the SSTATE_DIR can be messed up > > We never digged deep enough to find the cause, > but when we separated the SSTATE to only have one DISTRO > in the same SSTATE, the problem disappeared. The recipes were actively broken then, because DISTRO is in the hash. If the DISTRO changes, the hash changes. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-security] AppArmor 2.11 no longer available on Ubuntu archive (sumo branch)
That is deliberate and by design, recipes shouldn't fetch from Debian/Ubuntu archives for this reason. http://git.yoctoproject.org/cgit/cgit.cgi/meta-security/commit/?id=462d76700a3c2748067d4685db8985c511b1b46c is a patch to master that needs to be backported to warrior/thud/sumo. Ross On Fri, 7 Jun 2019 at 11:07, Smith, Peter1 (GE Renewable Energy) wrote: > > We are building with meta-security (from sumo branch) which currently uses > v2.11 of AppArmor, it seems overnight that the source archive has been > removed from the Ubuntu archives. Does anyone know if this is a deliberate > action, or if not who to contact to get it put back. > > > > Peter Smith > > > > Senior Emerging Technologies Engineer > > Grid Solutions > > GE Renewable Energy > > > > -NON PUBLIC- > > > > > > > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Error in building new recipe for Jool network translator
Sounds like the makefiles are broken and can't handle out-of-tree
builds. Try replacing inherit autotools with inherit
autotools-brokensep (and if that fixes it, file a bug with jool as
their build is broken).
Ross
On Thu, 6 Jun 2019 at 17:27, Gokul Raj wrote:
>
> Hi All,
>
> I'm new to yocto and I'm trying to create recipe for Jool network translator
> package. Tried to compile this package in manually and I'm able to compile
> with following steps.
> Manual Steps:
>
> ./autogen.sh
> ./configure
> make
> make install
>
> Yocto Receipe:
>
> DESCRIPTION = "Jool is an Open Source IPv4/IPv6 Translator"
> SECTION = "networking"
> LICENSE = "GPLv2"
> LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
>
> SRCREV = "v4.0.1"
> SRC_URI = "git://github.com/NICMx/Jool.git;protocol=http"
>
> DEPENDS = "libnl iptables"
>
> S = "${WORKDIR}/git"
>
> inherit autotools module
>
> Getting following error message /bin/bash: line 20: cd: src/mod: No such file
> or directory But, the src/mod is present in the source directory. Help
> me resolve this issue.
>
> Yocto Build Error:
>
> ERROR: jool-4.0.1-r0 do_compile: oe_runmake failed
> ERROR: jool-4.0.1-r0 do_compile: Function failed: do_compile (log file is
> located at
> /home/graj/poky/build/tmp/work/qemuarm-enigma-linux-gnueabi/jool/4.0.1-r0/temp/log.do_compile.58423)
> ERROR: Logfile of failure stored in:
> /home/graj/poky/build/tmp/work/qemuarm-enigma-linux-gnueabi/jool/4.0.1-r0/temp/log.do_compile.58423
> Log data follows:
> | DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common', 'arm-32',
> 'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi', 'common']
> | DEBUG: Executing shell function do_compile
> | NOTE: make -j 6
> KERNEL_SRC=/home/graj/poky/build/tmp/work-shared/qemuarm/kernel-source
> KERNEL_PATH=/home/graj/poky/build/tmp/work-shared/qemuarm/kernel-source
> KERNEL_VERSION=5.0.7-yocto-standard CC=arm-enigma-linux-gnueabi-gcc
> -mno-thumb-interwork -marm -fuse-ld=bfd
> -fmacro-prefix-map=/home/graj/poky/build/tmp/work/qemuarm-enigma-linux-gnueabi/jool/4.0.1-r0=/usr/src/debug/jool/4.0.1-r0
>
> -fdebug-prefix-map=/home/graj/poky/build/tmp/work/qemuarm-enigma-linux-gnueabi/jool/4.0.1-r0=/usr/src/debug/jool/4.0.1-r0
>
> -fdebug-prefix-map=/home/graj/poky/build/tmp/work/qemuarm-enigma-linux-gnueabi/jool/4.0.1-r0/recipe-sysroot=
>
> -fdebug-prefix-map=/home/graj/poky/build/tmp/work/qemuarm-enigma-linux-gnueabi/jool/4.0.1-r0/recipe-sysroot-native=
>
> -fdebug-prefix-map=/home/graj/poky/build/tmp/work-shared/qemuarm/kernel-source=/usr/src/kernel
> LD=arm-enigma-linux-gnueabi-ld.bfd AR=arm-enigma-linux-gnueabi-ar
> O=/home/graj/poky/bui
ld/tmp/work-shared/qemuarm/kernel-build-artifacts KBUILD_EXTRA_SYMBOLS=
> | Making all in src/mod
> | /bin/bash: line 20: cd: src/mod: No such file or directory
> | Makefile:343: recipe for target 'all-recursive' failed
> | make: *** [all-recursive] Error 1
> | ERROR: oe_runmake failed
> | WARNING: exit code 1 from a shell command.
> | ERROR: Function failed: do_compile (log file is located at
> /home/graj/poky/build/tmp/work/qemuarm-enigma-linux-gnueabi/jool/4.0.1-r0/temp/log.do_compile.58423)
> ERROR: Task
> (/home/graj/poky/meta-enigma/recipes-example/jool/jool_4.0.1.bb:do_compile)
> failed with exit code '1'
> NOTE: Tasks Summary: Attempted 570 tasks of which 563 didn't need to be rerun
> and 1 failed.
>
> Summary: 1 task failed:
> /home/graj/poky/meta-enigma/recipes-example/jool/jool_4.0.1.bb:do_compile
> Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
>
> Source git link: https://github.com/NICMx/Jool
>
> Help me in fixing this issue.
>
> Regards,
> Gokul Raj K
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-gplv2][PATCH] elfutils: ignore new error from gcc-9
Pushed, thanks. Ross On Wed, 5 Jun 2019 at 08:56, Martin Jansa wrote: > > Signed-off-by: Martin Jansa > --- > recipes-devtools/elfutils/elfutils_0.148.bb | 4 > 1 file changed, 4 insertions(+) > > diff --git a/recipes-devtools/elfutils/elfutils_0.148.bb > b/recipes-devtools/elfutils/elfutils_0.148.bb > index a03b74e..1f07a28 100644 > --- a/recipes-devtools/elfutils/elfutils_0.148.bb > +++ b/recipes-devtools/elfutils/elfutils_0.148.bb > @@ -57,6 +57,10 @@ SRC_URI += "\ > " > inherit autotools gettext > > +# There is a fix in 0.175 version > (https://sourceware.org/bugzilla/show_bug.cgi?id=23884) > +# but 0.175 has different license, so to be safe don't backport the fix, > just ignore the issue > +CFLAGS += "-Wno-error=missing-attributes" > + > EXTRA_OECONF = "--program-prefix=eu- --without-lzma" > EXTRA_OECONF_append_class-native = " --without-bzlib" > EXTRA_OECONF_append_libc-uclibc = " --enable-uclibc" > -- > 2.17.1 > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] do_rootfs fails while attempting to install hostapd package
On Mon, 3 Jun 2019 at 15:06, Morné Lamprecht wrote: > I also have DISTRO_FEATURES_BACKFULL_CONSIDERED = > "sysvinit" in my config (also had it during the > failed builds), I thought it would prevent > sysvinit from being added/backfilled to the > DISTRO features ? So I'm not sure why > DISTRO_FEATURES_remove is also required in this > case ? The variable is DISTRO_FEATURES_BACKFILL_CONSIDERED, in case that wasn't a typo when writing the mail. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Python module not found when using autotools
On Thu, 30 May 2019 at 21:27, Serkan Türker wrote: > I understand the process of debugging build failures. I am just confused why > my approach doesn't work. > "python-soundcloud.bb" has the same format like other python module recipes > in meta-oe. > In tizonia.bb, I have added "python-soundcloud" to DEPENDS, so I assumed > bitbake would resolve the necessary path's, which are necessary for the build. > It is also not only my fault not being able to fix this, it is also largely > related to the fact, that there is not much documentation around how to start > developing with Yocto in general. *How* is it looking for the module. If as Alex said, it is running the *native* Python, then it won't be finding any *target* modules that you have DEPENDed on. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] PN is uppercase
The check was added in August 2017 and appeared first in Rocko, so it's possible that you stuck with an earlier release until recently. Ross On Fri, 24 May 2019 at 15:26, Ralf Spiwoks wrote: > > Hi guys, > > The warnings were definitely not on when I started using Yocto more than two > years ago. > I have not been using debian packages, and didn't notice. I thought I was > still not > using debian and that's why I am surprised about those warnings. But as I > wrote, if I > ignore the warnings, nothing bad happens ... > > And Tim, thank you for writing "Debian" and "OpenEmbedded" in that way ... it > reassured > me ;-) > > Have a good weekend. Cheers, > > Ralf. > > On 5/24/19 6:23 AM, Tim Orling wrote: > > > > > > On Thu, May 23, 2019 at 4:55 PM Khem Raj > <mailto:raj.k...@gmail.com>> wrote: > > > > > > > > On 5/21/19 12:50 AM, Ralf Spiwoks wrote: > > > Hi Ross, > > > > > > Thanks for your email. I am realising that I have not replied to your > > > email earlier. Sorry. I guess it was partly because your answer put > > > me slightly off. On the one hand, I thought that as a general > > approach, > > > Linux was case sensitive, unlike its big rival Windows, and I was not > > > aware of package managers which would explicitly forbid uppercase > > > package names. I find the approach of allowing only lowercase package > > > names quite limiting, and frankly a drawback for using Yocto > > > > > > On the other hand I have a few tens of packages to maintain, which > > > have uppercase letters in the package names and which did work with > > > Yocto in previous versions. So, because of a new convention we would > > > have to rework some of the packages or ignore the warning messages. > > > And until we find the effort for reworking those package recipes we > > > will stay with the latter option. > > > > The package name rules are not new, they have been with OE/YP forever > > so it should have failed always. Similar to debian see > > > > > > https://www.debian.org/doc/debian-policy/ch-controlfields.html#list-of-fields > > > > > > We had to pick a convention. Debian is well documented, conservative and > > well thought out. My first contributions to OpenEmbedded many years ago > > didn’t follow Debian naming, were rejected on V1 and I embarked on a new > > learning curve. I’ve embraced it and never looked back. > > > > > > > > > > Thanks for your patience and your explanations. Cheers, > > > > > > Ralf. > > > > > > On 4/2/19 1:54 PM, Burton, Ross wrote: > > >> On Tue, 2 Apr 2019 at 12:36, Ralf Spiwoks > <mailto:spiw...@cern.ch>> wrote: > > >>> TWO questions: > > >>> > > >>> 1) Are those two issues related? > > >> > > >> Probably not, unless you're trying to use a mixed-case override. > > >> > > >>> 2) What is the logic behind allowing only lower case package names? > > >>> This is to me > > >>> a serious restriction on the use of Yocto. > > >> > > >> Two reasons: some package managers forbid packages with uppercase > > >> names; and for performance reasons overrides are lowercase and as > > >> package names are often embedded in overrides this implies that > > >> package names need to be lowercase. > > >> > > >> What's the problem with using lowercase names? > > >> > > >> Ross > > >> > > -- > > ___ > > yocto mailing list > > yocto@yoctoproject.org <mailto:yocto@yoctoproject.org> > > https://lists.yoctoproject.org/listinfo/yocto > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Difference between DEPENDS and BUILD-DEPENDS
On Sat, 25 May 2019 at 14:28, Archana Polampalli wrote: > i am working on one open source project,for this i have to add some > debian packages as yocto recipies. > i am trying to add "audit" recipe,so iam trying to understand the audit > debian package ,i got struck between "depends" and "build-depends" Debian Build-Depends == OpenEmbedded DEPENDS Debian Depends == OpenEmbedded RDEPENDS Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Building single package as image, respecting dependencies
On Fri, 24 May 2019 at 07:30, Norman Stetter wrote: > For the OS image I use cpio.gz as file system. It gets booted as a > RAMdisk. Sorry, forgot to mention that. > Would you consider switching to a proper filesystem? The peril of using a cpio.gz is that every file you add slows the boot down: using a proper filesystem solves this. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Finding recipe for ATOM N450
The meta-intel BSP is the recommend BSP for all Intel platfoms. Ross On Fri, 24 May 2019 at 10:30, Ranran wrote: > > Hello, > > I searched for ATOM N450 recipe, but only found very old one: > https://old.yoctoproject.org/downloads/bsps/edison11/atom-pc > The problem is that we need newer gcc (above 4.8.2). > > Should it be better to just use generic x86 recipe ? > https://old.yoctoproject.org/downloads/bsps/rocko24/generic-x86 > > Thank you, > ranran > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] /usr/share/common-license package/recipeinfo contains GPLv3 info
On Thu, 23 May 2019 at 10:43, virendra kumar thakur
wrote:
> But I can see in
> rootfs/usr/share/common-license/package/libgcrypt-lic/recipeinfo
>
> LICENSE: GPLV2+ &LGPLV2.1+ &GPLV3+
> PR: r0
> PV : 1.8.4
At a guess, because the libgcrypt recipe is:
LICENSE = "GPLv2+ & LGPLv2.1+ & GPLv3+"
Whereas libgcrypt itself is:
LICENSE_${PN} = "LGPLv2.1+"
That's a bit of a meta-question: what license is a license package
that only contains license texts?
Ross
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Building single package as image, respecting dependencies
On Thu, 23 May 2019 at 13:46, Norman Stetter wrote: > That seems to be a misunderstanding. I want to keep the OS image as small > as possible to reduce boot time. We only use python for some test > scenarios, so it doesn’t have to be included in the OS image. I did some > measurements and including python3 in the OS image increased the boot time > by over 30%. So the idea is to have it separately, and only mount it, when > needed. > What filesystem are you using? I wasn't aware of any modern file systems where the number of files installed affected mount performance. Could you just build two images and have a 'normal' image and a 'test image'? This is basically what the tools-testapps image feature is for. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Building single package as image, respecting dependencies
On Wed, 22 May 2019 at 14:28, Norman Stetter wrote: > Is there a way to have dependencies between images? So I could have the > python-image build know which dependencies are already built into my OS > image and therefore not include them itself? > No. An image is a self-contained file system. About 50% of your image recipe isn't helping your goal of an image that contains a single package. I have to query your assumptions though: if you're going to have python3 in a filessytem that you mount when required, how are you saving space? Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] GPLv3 package present in rootfs
On Wed, 22 May 2019 at 06:26, virendra kumar thakur
wrote:
> still some package gnutls, libidn2, libassuan, are added into rootfs.
Randomly picking libassuan:
LICENSE_${PN} = "LGPLv2.1+"
The library itself is LGPL-2. Have you verified the *package*
licenses for what is actually going into the image?
Ross
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Debugging dev-deps
On Mon, 13 May 2019 at 09:54, Matthias Schoepfer wrote: > I am trying to write a recipe for a rather tricky component (that has > plugins and stuff). Anyhow, I cannot get bitbake not to complain that > rdepends on -dev. And if I INSANE_SKIP it, > the -dev package will get installed. But I cannot figure out which file > is responsible. I tried to ldd all installed files in , but > could not get any results. Any hints on how to debug this further?! The problem is probably that the plugins are being shipped as /usr/lib/libpluginfoo.so, and so have the same names as development library symlinks which get packaged into PN-dev automatically. Alternatively unversioned libraries will also have the same issue. Look at what files go into what package (using oe-pkgdata-util), and ensure that PN-dev only contains headers and the link-time symlinks. For example libfoo.so -> libfoo.so.1, libfoo.so should be in PN-dev and libfoo.so.1 should be in PN. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How do I include all packages under a layer ?
On Sat, 11 May 2019 at 21:32, Madhu Krishnamurthy wrote: > If I have to chose just one, will any one of them (say apt) work? I somehow > had come to believe that you can only use opkg in Yocto. The default is opkg but RPM and dpkg are supported. I'd pick either opkg or rpm though. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How do I include all packages under a layer ?
On Sat, 11 May 2019 at 00:54, Madhu Krishnamurthy wrote: > Do I have to specify every package or is there a way I can add all packages > inside a layer? > For example, how do I add all packages from inside poky/meta to my image? > Or at least how do I add all packages under poky/meta/recipes-devtools ? You need to list them explicitly. Some layers have packagegroups that pull in all the dependencies if that makes sense, but adding "all of oe-core/recipes-devtools" would be odd: you'd have three package managers for a start. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Multiple MACHINEs and DISTROs: When to use own build dir, SSTATE_DIR, DL_DIR ?
On Thu, 9 May 2019 at 10:47, Fabian Knapp wrote: > we have multiple MACHINEs and DISTROs and Im wondering for which > combinations I have to setup a dedicated build dir, SSTATE_DIR and DL_DIR. > > Information in the form of: > > Each (change of) MACHINE needs its dedicated SSTATE_DIR and build dir but > can share DL_DIR. > You can always share DL_DIR and SSTATE_DIR. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] yocto sumo - upgrading gcc from 7.3 to 8.3 fails - C compiler cannot create executables
On Mon, 6 May 2019 at 17:28, Eric Grunt wrote: > | configure: error: C compiler cannot create executables > | See `config.log' for more details I suggest reading config.log for more details. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto concept and support for dual version firmware upgrad and boot
On Fri, 3 May 2019 at 07:46, Jaquier Cyril wrote: > There are a few other solutions available for Yocto: > > https://wiki.yoctoproject.org/wiki/System_Update#Comparison That list needs updating as there's a few more available now such as Balena and UpdateHub, but both Mendor and swupdate are both still going strong and have supported integration. I've heard good things about swupdate, and it can be used to implement your design: https://sbabic.github.io/swupdate/overview.html#double-copy-with-fall-back Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Dependencies with third party binaries
Why don't you use the layer that comes with the Intel compiler?
Ross
On Thu, 2 May 2019 at 23:15, wrote:
>
> Hi,
>
> I'm currently working on repackaging the 2016 Intel compiler and I am
> stuck at the dependency resolution.
>
> I am basing my recipe on the AUR PKGBUILD [1], which extracts the RPMs
> from the parallel-studio-xe [2] archive and extracts the content of the
> RPMs to get the binaries. I already have the RPMs extracted from the
> tarball and stored in a git repo. Not the ideal solution, but good
> enough for now.
>
> The `bitbake` command for the recipe is passing after disabling a couple
> of QA errors (too much for my taste), but the recipe for the
> `core-image` fails at the dependency
> resolution. From what I understand, all of the binaries inside of the
> `FILES_${PN}` are checked, and one (or more) fails at the dependency
> check with the following message :
>
> ```
> Error:
> Problem: conflicting requests
>- nothing provides ld-linux-k1om.so.2()(64bit) needed by
> icc-2016+1-r0.corei7_64
> ```
>
> This shared library seems to be Intel related but I cannot find it in
> all of the RPMs contained in the initial tarball. It is also not needed
> to run the compiler, I was able to execute the `icc` and `icpc` (the c++
> compiler) binaries from the devshell.
>
> I know this is wrong and against every yocto principles, but is there a
> way to skip the dependenciey resolution for a specific recipe ? Or is
> there a recipe made by Intel that I missed ?
> I'm also open to any suggestions on how to tackle this task.
>
> Here's my recipe so far :
>
> ```
> LICENSE = "CLOSED"
> LIC_FILES_CHKSUM = ""
>
> DEPENDS += "libarchive-native"
>
> SRC_URI = # omitted
>
> PV = "2016-1"
> SRCREV = "${AUTOREV}"
>
> S = "${WORKDIR}/git"
>
> extract_rpms() {
> for rpm_file in ${S}/$1; do
> bsdtar -xf ${rpm_file} -C $2
> done
> }
>
> # Skip the unwanted steps
> do_configure[noexec] = "1"
> do_compile[noexec] = "1"
>
> do_install () {
> extract_rpms 'intel-icc*.rpm' ${D}
> extract_rpms 'intel-comp*.rpm' ${D}
> extract_rpms 'intel-ccomp*.rpm' ${D}
> extract_rpms 'intel-openmp*.rpm' ${D}
> }
>
> do_package_qa[noexec] = "1"
>
> ALLOW_EMPTY_${PN} = "1"
>
> FILES_SOLIBSDEV = ""
> FILES_${PN} += "/opt/intel/*"
>
> INSANE_SKIP_${PN} += "already-stripped ldflags arch staticdev file-rdeps
> build-deps"
>
> INHIBIT_PACKAGE_DEBUG_SPLIT = "1"
> INHIBIT_PACKAGE_STRIP = "1"
>
> ```
>
> Thanks,
>
> Simon Zeni
>
> [1]:
> https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=intel-parallel-studio-xe&id=d4e2871a3bf698c3a5f58ee2201df53fe7f5dce7
> [2]:
> http://registrationcenter-download.intel.com/akdlm/irc_nas/8365/parallel_studio_xe_2016_update1.tgz
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] "meta-intel" layer bad example of a "container layer"
Right, meta-intel isn't a container layer. It just has two MACHINES. Ross On Thu, 2 May 2019 at 13:54, Robert P. J. Day wrote: > > > catching up with all the YP stuff i've missed over the last while > and, in the BSP guide in the layers section: > > https://www.yoctoproject.org/docs/latest/bsp-guide/bsp-guide.html#bsp-layers > > one reads: > > "Some layers function as a layer to hold other BSP layers. These > layers are knows as "container layers". An example of this type of > layer is the meta-intel layer. This layer contains BSP layers for the > Intel-core2-32 Intel® Common Core (Intel-core2-32) and the > Intel-corei7-64 Intel® Common Core (Intel-corei7-64). the meta-intel > layer also contains the common/ directory, which contains common > content across those layers. " > > pretty sure meta-intel has been a regular BSP layer for a while now, > so another example should be used. off the top of my head, i'd suggest > meta-xilinx: > > http://git.yoctoproject.org/cgit/cgit.cgi/meta-xilinx/ > > unless anyone has strong objections, i can send in a patch. > > rday > > -- > > > Robert P. J. Day Ottawa, Ontario, CANADA > http://crashcourse.ca > > Twitter: http://twitter.com/rpjday > LinkedIn: http://ca.linkedin.com/in/rpjday > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Could not find glib.h
On Wed, 1 May 2019 at 23:33, JH wrote: > It was my program, it has been compiled for weeks without any issues > until I added an #include , despite the glib-2.0 was defined > in the recipe, the do_compile() stopped at following errors, I can see > glib-2.0 was built in build and image directory, I can see glib.h was > in build and image directory, is it a basic principle if a package > library was defined in DEPENDS, the bitback should automatically find > the header files and library links? Why it still complained no such > file? Because that's not how glib works. https://developer.gnome.org/glib/stable/glib-compiling.html Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] include own script - custon location
On Mon, 29 Apr 2019 at 10:48, Zolee K wrote:
> I guess something is wrong with the do-install function, I thought it would
> put the file in the image, but it doesn't. Please help me out on this.
Bitbake is literally telling you want to do:
> Please set FILES such that these items are packaged.
FILES_${PN} += "/usr/local/www"
Ross
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] What is the right SRC_URI syntax for g...@bitbucket.org?
On Wed, 24 Apr 2019 at 13:29, Erik Hoogeveen wrote:
> What I have is:
>
> SRCREV = "${AUTOREV}"
> PE = "1"
> PV = "0.0+git${SRCPV}"
>
> To make that work your recipe file name must have the format
> '_git.bb’
Some corrections.
If you're using a git URL then you need to set SRCREV to the sha you
want to fetch. Using ${AUTOREV} means "always fetch the latest SHA
for the branch I specify" is bad form unless you're actively
developing something because you'll be building untested commits.
Setting PE (epoch) is very unusual.
The recipe filename isn't relevant, foo_git.bb simply sets PV="git"
but then you override it in the recipe anyway.
Ross
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] .pc files are not avilable at build time
On Wed, 24 Apr 2019 at 12:50, Archana Polampalli wrote: > > Thank you for your responce > > whaile configuration time getting this error > checking for EXT2FS... no > INFO - | checking for EXT2FS... no > INFO - | configure: error: Package requirements (ext2fs) were not > met: > INFO - | > INFO - | No package 'ext2fs' found > INFO - | > INFO - | Consider adjusting the PKG_CONFIG_PATH > environment > variable if you installed software in a non-standardprefix. > INFO - | > INFO - | Alternatively, you may set the environment > variables > EXT2FS_CFLAGS and EXT2FS_LIBS to avoid the need to > call pkg- > config See the pkg-config man page for more details. > > ex2fs.pc is provided by e2fsprogs package.i have alredy installed it If I build btrfs-tools then I get this: checking for ext2fs... yes So you'll need to give a lot more detail and what you're doing with what versions. The config.log file in the btrfs-tools work directory will show why pkg-config was failing. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] WARNING message: Building library didn't pass LDFLAGS? [ldflags]
It means that the compile didn't respect LDFLAGS from the environment (which sets the ELF hashing type). Most usual build systems handle this for you, but if your recipe uses hand-coded Makefiles then you'll need to figure out what they're doing and how to make it respect $LDFLAGS. Ross On Tue, 23 Apr 2019 at 23:49, JH wrote: > > Hi, > > What is the following WARNING means, how can I fix it? > > yocto-sample-1.0.0-0 do_package_qa: QA Issue: No GNU_HASH in the ELF > binary my_library, didn't pass LDFLAGS? [ldflags] > > Thank you. > > Kind regards, > > - jupiter > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] .pc files are not avilable at build time
Works for me. What is the actual error you're seeing? On Tue, 23 Apr 2019 at 10:17, Archana Polampalli wrote: > > Hi all, > > I am trying to build btrfs-tools recipes.it needs the ex2fs.pc > pkgconfig file.i have alredy installed e2fsprogs recipe it created the > ex2fs.pc in image directory.but btrfstools unable to take the pkgconfig > file. > > plese any help me how to provide ex2fs.pc file for build btrfs-tools > > Regards > Archana > The information contained in this e-mail message and in any > attachments/annexure/appendices is confidential to the > recipient and may contain privileged information. > If you are not the intended recipient, please notify the > sender and delete the message along with any > attachments/annexure/appendices. You should not disclose, > copy or otherwise use the information contained in the > message or any annexure. Any views expressed in this e-mail > are those of the individual sender except where the sender > specifically states them to be the views of > Toshiba Software India Pvt. Ltd. (TSIP),Bangalore. > > Although this transmission and any attachments are believed to be > free of any virus or other defect that might affect any computer > system into which it is received and opened, it is the responsibility > of the recipient to ensure that it is virus free and no responsibility > is accepted by Toshiba Embedded Software India Pvt. Ltd, for any loss or > damage arising in any way from its use. > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] config.guess: unable to guess system type
The problem is that config.guess, last modified 2009-09-18, has failed to recognize the operating system you are using. It is advised that you download the most up to date version of the config scripts from http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD and http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD You're trying to build a piece of software that was released on 2013-08-17 using a config.guess from 2009, both of which predate aarch64 being actually available. There's a perfectly good recipe for libsdl in oe-core, or if you insist on building it on-target then you can either follow the instructions or install the gnu-config package into your image and copy the config.* files from /usr/share/gnu-config/. Ross On Tue, 23 Apr 2019 at 10:22, Peter Balazovic wrote: > > I am trying to compile on my Yocto system from source the SDL > http://www.libsdl.org/release/SDL-1.2.15.tar.gz and by running ./configure I > got error to configure the build > > checking build system type... ./build-scripts/config.guess: unable to guess > system type > > This script, last modified 2009-09-18, has failed to recognize > the operating system you are using. It is advised that you > download the most up to date version of the config scripts from > > > http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD > and > > http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD > > If the version you run (./build-scripts/config.guess) is already up to date, > please > send the following data and any information you think might be > pertinent to in order to provide the needed > information to handle your system. > > config.guess timestamp = 2009-09-18 > uname -m = aarch64 > uname -r = 4.14.78-imx_4.14.78_1.0.0_ga+g66620c3 > uname -s = Linux > uname -v = #1 SMP PREEMPT Fri Feb 1 09:09:25 UTC 2019 > > /usr/bin/uname -p = > /bin/uname -X = > > hostinfo = > /bin/universe = > /usr/bin/arch -k = > /bin/arch = > /usr/bin/oslevel = > /usr/convex/getsysinfo = > > UNAME_MACHINE = aarch64 > UNAME_RELEASE = 4.14.78-imx_4.14.78_1.0.0_ga+g66620c3 > UNAME_SYSTEM = Linux > UNAME_VERSION = #1 SMP PREEMPT Fri Feb 1 09:09:25 UTC 2019 > configure: error: cannot guess build type; you must specify one > > What would be causing the problem? > Thanks. > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Metadata is missing in some Python packages
An upgrade should just be a matter of taking the meta-python recipe and doing a version bump/checksum update. If you've written a recipe from scratch then you're probably missing some of the glue required. Ross On Tue, 9 Apr 2019 at 11:17, Guenther Meyer wrote: > > On Tue, 9 Apr 2019 11:11:04 +0100 > "Burton, Ross" wrote: > > > So for me they're in python3-twisted-core on target, and if you have > > the right DEPENDS then it should be there for build time. > > I will have a look at this, when I'm back in the office again. > The thing is, I needed a newer version of twisted, so I did my own > recipe. But obviously it is not enough to let setuptools do the work. > > > -- > Summer-Hack-Session 2.8 > http://session.pestilenz.org/session2/ > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] m4-mative: "Please port gnulib fseeko.c to your platform!"
On Tue, 9 Apr 2019 at 11:14, Robert P. J. Day wrote: > so, to confirm what i thought, this is a bug in gnulib which > suggests i should dig through the build configuration to see where i > can, say, set a PREFERRED_VERSION of a newer version of gnulib that > no longer has tat bug? or, barring that, just add the appropriate > local patch on my end. No, gnulib is a copy/paste library. The bug was fixed in gnulib, and new releases of m4 are fixed, but you'll need to cherry-pick the fix from oe-core master (we apply the patch to our m4 recipe) back to whatever stable branch you're using. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Metadata is missing in some Python packages
So for me they're in python3-twisted-core on target, and if you have the right DEPENDS then it should be there for build time. Ross On Tue, 9 Apr 2019 at 11:03, Guenther Meyer wrote: > > On Tue, 9 Apr 2019 10:55:38 +0100 > "Burton, Ross" wrote: > > > Specifically for twisted, do you mean these files: > > > > python3-twisted-core: > > > > /usr/lib/python3.7/site-packages/Twisted-18.4.0-py3.7.egg-info/PKG-INFO > > > > /usr/lib/python3.7/site-packages/Twisted-18.4.0-py3.7.egg-info/SOURCES.txt > > > > /usr/lib/python3.7/site-packages/Twisted-18.4.0-py3.7.egg-info/dependency_links.txt > > > > /usr/lib/python3.7/site-packages/Twisted-18.4.0-py3.7.egg-info/entry_points.txt > > > > /usr/lib/python3.7/site-packages/Twisted-18.4.0-py3.7.egg-info/not-zip-safe > > > > /usr/lib/python3.7/site-packages/Twisted-18.4.0-py3.7.egg-info/requires.txt > > yes, exactly. > > > -- > Summer-Hack-Session 2.8 > http://session.pestilenz.org/session2/ > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Metadata is missing in some Python packages
Specifically for twisted, do you mean these files: python3-twisted-core: /usr/lib/python3.7/site-packages/Twisted-18.4.0-py3.7.egg-info/PKG-INFO /usr/lib/python3.7/site-packages/Twisted-18.4.0-py3.7.egg-info/SOURCES.txt /usr/lib/python3.7/site-packages/Twisted-18.4.0-py3.7.egg-info/dependency_links.txt /usr/lib/python3.7/site-packages/Twisted-18.4.0-py3.7.egg-info/entry_points.txt /usr/lib/python3.7/site-packages/Twisted-18.4.0-py3.7.egg-info/not-zip-safe /usr/lib/python3.7/site-packages/Twisted-18.4.0-py3.7.egg-info/requires.txt Ross On Tue, 9 Apr 2019 at 08:49, Guenther Meyer wrote: > > On Fri, 5 Apr 2019 18:17:43 +0100 > "Burton, Ross" wrote: > > > What metadata in particular do you refer to? > > The *egg-info folders and everything contained in them, especially > the files PKG-INFO or METADATA. The recipes are basically identical. > > Some packages have it, some not: > > Django-2.1.7-py3.5.egg-info > EasyProcess-0.2.5-py3.5.egg-info > HelperSDT > HelperSDT-0.1.0-py3.5.egg-info > OpenSSL > PyHamcrest-1.9.0-py3.5.egg-info > PySocks-1.6.8-py3.5.egg-info > PyVirtualDisplay-0.2.1-py3.5.egg-info > Twisted-0.0.0-py3.5.egg-info > aioredis > aioredis-1.2.0-py3.5.egg-info > asgiref > asgiref-2.3.2-py3.5.egg-info > asn1crypto > asn1crypto-0.24.0-py3.5.egg-info > async_timeout > async_timeout-3.0.1-py3.5.egg-info > attr > attrs-18.1.0-py3.5.egg-info > autobahn > autobahn-19.1.1-py3.5.egg-info > behave > behave-1.2.6-py3.5.egg-info > can > certifi > certifi-2018.8.13-py3.5.egg-info > cffi > cffi-1.11.5-py3.5.egg-info > channels > channels-2.1.7-py3.5.egg-info > channels_redis > channels_redis-2.3.2-py3.5.egg-info > chardet > chardet-3.0.4-py3.5.egg-info > click > click-6.7-py3.5.egg-info > constantly > constantly-15.1.0-py3.5.egg-info > cryptography > cryptography-2.3-py3.5.egg-info > daphne > daphne-2.2.5-py3.5.egg-info > django > django_model_utils-3.1.2-py3.5.egg-info > easyprocess > hamcrest > hiredis > hiredis-1.0.0-py3.5.egg-info > idna > idna-2.7-py3.5.egg-info > incremental > incremental-17.5.0-py3.5.egg-info > model_utils > msgpack > msgpack_python-0.5.6-py3.5.egg-info > ndg > ndg_httpsclient-0.5.1-py3.5.egg-info > parse-1.8.4-py3.5.egg-info > parse_type > parse_type-0.4.2-py3.5.egg-info > ply > ply-3.11-py3.5.egg-info > psutil > psutil-5.4.6-py3.5.egg-info > psycopg2 > psycopg2-2.7.5-py3.5.egg-info > pyOpenSSL-18.0.0-py3.5.egg-info > pyasn1 > pyasn1-0.4.4-py3.5.egg-info > pycparser > pycparser-2.18-py3.5.egg-info > python_can-2.2.1-py3.5.egg-info > pytz > pytz-2018.5-py3.5.egg-info > pyvirtualdisplay > requests > requests-2.19.1-py3.5.egg-info > selenium > selenium-3.141.0-py3.5.egg-info > service_identity > service_identity-18.1.0-py3.5.egg-info > setuptools > setuptools-40.0.0-py3.5.egg-info > six-1.11.0-py3.5.egg-info > twisted > txaio > txaio-18.8.1-py3.5.egg-info > urllib3 > urllib3-1.23-py3.5.egg-info > websocket > websocket_client-0.54.0-py3.5.egg-info > wrapt > wrapt-1.10.11-py3.5.egg-info > zope > zope.interface-4.5.0-py3.5.egg-info > > > -- > Summer-Hack-Session 2.8 > http://session.pestilenz.org/session2/ > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] m4-mative: "Please port gnulib fseeko.c to your platform!"
Looks like that bug in gnulib that broke m4 (and others) when glibc changed. Fixed upstream https://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=4af4a4a718 and oe-core master/thud/possibly sumo also carry the relevant patch for m4. If you're using older releases against a newer release then 1) this is why we have supported host distros and 2) the patch is easy to backport. Ross On Mon, 8 Apr 2019 at 21:45, Robert P. J. Day wrote: > > > a few months ago, i ran into (and asked about) a failure building > m4-native that you can read here: > > https://yocto.yoctoproject.narkive.com/6KyM5UvS/m4-native-zedboard-please-port-gnulib-fseeko-c-to-your-platform > > first, i will admit i'm not sure where the fault lies -- is it m4, or > gnulib, or glibc, and whose responsibility is it to fix what. i'll be > honest -- i don't understand what the bug is or who should be > resolving it. > > i ask all this as i just had *exactly* the same error trying to > build agl-image-minimal with the AGL code base. what is the proper > solution to this? BTW, i'm trying this on fedora 30 branched, so this > is definitely not a supported build distro, but i'm still curious as > to what would be the proper fix. > > finally, it occurs to me that, if building a native package like > "m4" fails, would it be a reasonable workaround to simply say > > ASSUME_PROVIDED += "m4" > > for the time being, to avoid having to build it until i know what the > proper fix is? > > rday > > -- > > > Robert P. J. Day Ottawa, Ontario, CANADA > http://crashcourse.ca > > Twitter: http://twitter.com/rpjday > LinkedIn: http://ca.linkedin.com/in/rpjday > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Installation help
There must be if example.com can't be downloaded from... On Mon, 8 Apr 2019 at 19:49, Karshi Hasanov wrote: > > There is nothing wrong with my network network! > > For now the issue is resolved. > > Thanks any way. > > > On 2019-04-08 1:10 p.m., Burton, Ross wrote: > > The better fix is to fix your network. If you need a proxy, set it in > > local.conf. > > > > Ross > > > > On Mon, 8 Apr 2019 at 18:09, Nataliya Korovkina > > wrote: > >> Hello Karshi, > >> > >> I had the same message. I added: > >> > >> CONNECTIVITY_CHECK_URIS="" > >> > >> in conf/local.conf as a QUICK FIX. I hope someone has better solution, > >> please? > >> > >> Thanks, > >> Nataliya > >> > >> > >> On Mon, Apr 8, 2019 at 12:43 PM Karshi Hasanov > >> wrote: > >>> Hi all, > >>> > >>> I have followed the > >>> > >>> https://www.yoctoproject.org/docs/2.6.1/brief-yoctoprojectqs/brief-yoctoprojectqs.html > >>> > >>> when issue the "bitbake core-image-minimal" > >>> > >>> I am keep getting this error: > >>> > >>> ERROR: OE-core's config sanity checker detected a potential > >>> misconfiguration. > >>> Either fix the cause of this error or at your own risk disable the > >>> checker (see sanity.conf). > >>> Following is the list of potential problems / advisories: > >>> > >>> Fetcher failure for URL: 'https://www.example.com/'. URL > >>> https://www.example.com/ doesn't work. > >>> Please ensure your host's network is configured correctly, > >>> or set BB_NO_NETWORK = "1" to disable network access if > >>> all required sources are on local disk. > >>> > >>> -- > >>> ___ > >>> yocto mailing list > >>> yocto@yoctoproject.org > >>> https://lists.yoctoproject.org/listinfo/yocto > >> > >> > >> -- > >> > >> > >> Nataliya Korovkina > >> > >> -- > >> ___ > >> yocto mailing list > >> yocto@yoctoproject.org > >> https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Installation help
The better fix is to fix your network. If you need a proxy, set it in local.conf. Ross On Mon, 8 Apr 2019 at 18:09, Nataliya Korovkina wrote: > > Hello Karshi, > > I had the same message. I added: > > CONNECTIVITY_CHECK_URIS="" > > in conf/local.conf as a QUICK FIX. I hope someone has better solution, please? > > Thanks, > Nataliya > > > On Mon, Apr 8, 2019 at 12:43 PM Karshi Hasanov > wrote: >> >> Hi all, >> >> I have followed the >> >> https://www.yoctoproject.org/docs/2.6.1/brief-yoctoprojectqs/brief-yoctoprojectqs.html >> >> when issue the "bitbake core-image-minimal" >> >> I am keep getting this error: >> >> ERROR: OE-core's config sanity checker detected a potential >> misconfiguration. >> Either fix the cause of this error or at your own risk disable the >> checker (see sanity.conf). >> Following is the list of potential problems / advisories: >> >> Fetcher failure for URL: 'https://www.example.com/'. URL >> https://www.example.com/ doesn't work. >> Please ensure your host's network is configured correctly, >> or set BB_NO_NETWORK = "1" to disable network access if >> all required sources are on local disk. >> >> -- >> ___ >> yocto mailing list >> yocto@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/yocto > > > > -- > > > Nataliya Korovkina > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] FileExistsError: [Errorno 17] File Exists
On Mon, 8 Apr 2019 at 07:17, Pandey, Kamal wrote: > Hi I was trying to compile Weston-6.0 using yocto recipe. For this I > backported some of the packages from master branch of poky to my own layer. > During this process, there was one package xorgproto which was used in master > branch of poky but in rocko branch this package is not there. However a > similar package is there called xproto. Now there is a conflict between these > two packages for installing the same headers. I appended xorgproto recipe and > removed the installation of similar header files. But after this I am getting > this error. However If I continue to compile these errors are ignored. xproto != xorgproto. https://www.phoronix.com/scan.php?page=news_item&px=Xorgproto-Debut-Release All of the xorg-proto/*proto.bb recipes were replaced by xorgproto. As part of the backporting you can most likely just replace xorgproto with the name of the relevant proto recipe. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Metadata is missing in some Python packages
What metadata in particular do you refer to? Ross On Thu, 4 Apr 2019 at 11:04, Guenther Meyer wrote: > > Hi, > > I added some python recipes for my application, and now I have the > problem, that in some of the created packages the metadata is missing. > For example, the package I have for Twisted 18.7 is one of those. > When I use a python package like daphne, which is dependent on > Twisted >= 18.7, then it won't work, because daphne checks the version > before doing anything else. > I created a workaround by removing this check in the recipe, but that > doesn't feel right. > > Maybe there is something I missed in my recipes? > > > -- > Summer-Hack-Session 2.8 > http://session.pestilenz.org/session2/ > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Do you use ISO images generated by bitbake?
Hi, I'm looking for some users that use the ISO images generated by Bitbake (IMAGE_FSTYPE live or iso). Anyone out there? Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [oe] [OE-core] Git commit process question.
On Tue, 2 Apr 2019 at 20:46, Tom Rini wrote: > > The kernel does not have "upgrade foo to the latest upstream version" > > commits. > > > > With the Automatic Upgrade Helper this is a semi-automatic task, and > > most of the time there is no specific motivation other than upgrading > > to the latest upstream version. > > But since that's just filling in a template the body can also be a > template perhaps with useful AUH data (run at ... by ... ?) ? Apart from making the commit message longer what does this achieve? The commit already has a timestamp and author. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] PN is uppercase
On Tue, 2 Apr 2019 at 12:36, Ralf Spiwoks wrote: > TWO questions: > > 1) Are those two issues related? Probably not, unless you're trying to use a mixed-case override. > 2) What is the logic behind allowing only lower case package names? This is > to me > a serious restriction on the use of Yocto. Two reasons: some package managers forbid packages with uppercase names; and for performance reasons overrides are lowercase and as package names are often embedded in overrides this implies that package names need to be lowercase. What's the problem with using lowercase names? Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] pkg-config does not find "luajit" since upgrade to sumo
On Fri, 29 Mar 2019 at 12:49, Clemens Eisserer wrote:
> The issue was the _$PN appended to DEPENDS, when I removed it the build
> succeeded:
> changing DEPENDS_${PN} = "luajit" to DEPENDS = "luajit" did the trick.
Right, DEPENDS_${PN} isn't a variable that is used. You'll most
likely have got a warning from bitbake about that.
> However, I am still puzzled what happens here and why it worked before.
Because in the old days, every recipe shared a global sysroot. If
luajit was built at some point, it was in the sysroot. For the last
few releases (almost two years now?) the sysroot is per-recipe, so if
you don't have luajit in DEPENDS then it isn't in the sysroot.
Ross
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] pkg-config does not find "luajit" since upgrade to sumo
All I can say is stop digging around random paths and actually ask the system the questions you need answers to. - Does my recipe depend on luajit. Check that you have DEPENDS=luajit. - What files does luajit ship. $ oe-pkgdata-util list-pkg-files -p luajit Does that include a /usr/lib/pkgconfig/luajit.pc? Ross On Fri, 29 Mar 2019 at 00:55, Clemens Eisserer wrote: > > Hello Burton, > > > Check what luajit is shipping and compare that to what the pkgconfig > > is looking for. Calling pkgconfig directly in your recipe's devshell > > is useful for this. > > Thanks for the hint regarding the devshell. > > Indeed, pkgconfig can not find luajit in the devshell - the path > specified as PKG_CONFIG_PATH is: > build/tmp-angstrom-glibc/work/armv7at2hf-neon-angstrom-linux-gnueabi/xpcompiler/0.1-r0/recipe-sysroot/usr/lib/pkgconfig > - however the folder pkgconfig does not even exist in there. > > Inside work/armv7.../ there is also a luajit directory, and there I > was able to find the pc-file: > /2.0.5-r0/sysroot-destdir/usr/lib/pkgconfig/luajit.pc > > So i wonder, are there some extra steps required to make the luajit > sysroot-destdir visible to luajit's recipe-sysroot? > > Thanks & br, Clemens -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] pkg-config does not find "luajit" since upgrade to sumo
On Fri, 29 Mar 2019 at 00:06, Clemens Eisserer wrote:
> Hi Burton,
>
> > > RDEPENDS_${PN} = "luajit"
> > > inherit autotools pkgconfig
> >
> > Considering you're trying to use luajit at build time, it's probably
> > sensible to have it as a build dependency instead (DEPENDS).
>
> I've just tried it without success - it still fails stating luajit can
> not be found - despite the fact that "bitbake luajit" seems to work
> without any issues.
>
> I am not sure it makes a difference, I additionally use the
> meta-altera layer and I am running inside a debian chroot (in the same
> environment where the build with angstrom-v2016.06-yocto2 actually
> succeeds).
>
> Could it have something to do with pkg-config not beeing prefixed -
> like mentioned in the configure log?
>
> Best regard, Clemens
>
> checking for arm-angstrom-linux-gnueabi-pkg-config... no
> | checking for pkg-config...
> /home/ce/yocto_xposure2019/build/tmp-angstrom-glibc/work/armv7at2hf-neon-angstrom-linux-gnueabi/xpcompiler/0.1-r0/recipe-sysroot-native/usr/bin/pkg-config
> | configure: WARNING: using cross tools not prefixed with host triplet
Nope.
Check what luajit is shipping and compare that to what the pkgconfig
is looking for. Calling pkgconfig directly in your recipe's devshell
is useful for this.
Not having luajit in DEPENDS *is* a bug though, having it in RDEPENDS
alone means you've been lucky with task scheduling before.
Ross
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] pkg-config does not find "luajit" since upgrade to sumo
On Thu, 28 Mar 2019 at 23:45, Clemens Eisserer wrote:
> The bb-file specifies luajit as runtime-dependency as well as inherits
> pkgconfig:
>
> RDEPENDS_${PN} = "luajit"
> inherit autotools pkgconfig
Considering you're trying to use luajit at build time, it's probably
sensible to have it as a build dependency instead (DEPENDS).
Ross
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Fwd: Trimming BOOST libraries installed
On Thu, 28 Mar 2019 at 12:40, Gabriele Zampieri wrote: > So I just specify the dependencies in my recipes, and then remove > IMAGE_INSTALL_append = " boost". Am I right? Yes. Your recipe that uses boost just needs DEPENDS=boost as a build-dependency. The linkage will be examined and the appropriate runtime dependencies created for you. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Trimming BOOST libraries installed
On Thu, 28 Mar 2019 at 10:59, Gabriele Zampieri wrote: > I'm building a custom image that install boost libraries: > > IMAGE_INSTALL_append = " boost" > > How can I trim the installed libraries? I see inside > meta/recipes-support/boost/boost.inc a variable called BOOST_LIBS that lists > all the boost components, so in my custom-image.bb I tried: The easy solution is to not do that. The application you're building should DEPEND on boost and then the RDEPENDS will be populated for you, and be the required set not the full set. If you really want to explicitly install some packages, then don't install "boost" which is a meta-package depending on all boost libraries. The sub-libraries are called eg boost-atomic. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] can't find libudev.h
On Fri, 15 Mar 2019 at 17:00, Derek Dresser wrote: > | gcc -fPIC -c -g -MMD -MP -MF build/Debug/GNU-Linux-x86/hid.o.d -o > build/Debug/GNU-Linux-x86/hid.o hid.c 'gcc' isn't a cross compiler, and it isn't using the sysroot flags. The problem with people writing their own makefiles is that they think it's easy, but it isn't. You'll have to figure out why the maze of Makefiles in that project don't respect CC/CPPFLAGS/CFLAGS/LDFLAGS that are exported into the environment. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Incremental rebuild doesn't pick up FILES changes.
On Wed, 6 Mar 2019 at 22:27, Kaz Kylheku (poky)
<442-103-8...@kylheku.com> wrote:
> Ah, okay; this is because it's been split into various sub-packages. So
> we have to operate on "-core".
> The .json manifest brings these into the "core" package:
>
> "${libdir}/python2.7/encodings",
> "${libdir}/python2.7/encodings/aliases.py",
> "${libdir}/python2.7/encodings/utf_8.py",
>
> I don't want all of encoders, just the utf_8.py and the aliases
> dictionary.
>
> So I'm guessing this should be
>
>FILES_${PN}-core_remove =
Yes. It's too late to think about parse ordering because of the
complexity of Python's packaging but that *should* work.
Worst case: provide your own manifest if the packaging isn't what you want.
Ross
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Incremental rebuild doesn't pick up FILES changes.
On Wed, 6 Mar 2019 at 20:14, Kaz Kylheku (poky)
<442-103-8...@kylheku.com> wrote:
> So, the issues are now is that
>
> FILES_${PN}_remove = "${libdir}/python2.7/encodings"
>
> in fact does not work, as I believed.
Have a look at python.bb. Specifically:
PACKAGES_remove = "${PN}"
There is no PN being packaged.
What are you actually trying to do?
Ross
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Removing busybox
On Thu, 28 Feb 2019 at 05:20, Adrian Bunk wrote: > > That's a good start. For a oe-core packagegroup > > 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). But a "close enough" packagegroup in core would be a good starting point. > > 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. Good point well made. > > 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. I thought we had some other editor in core, but can't see one. Worse case we still use busybox for its vi... :) Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Removing busybox
On Thu, 28 Feb 2019 at 00:10, Jean-Christian de Rivaz wrote: > My image recipe look actually like below and require several > meta-openembedded/meta-*. This is not a clean example. The > packagegroup-core-full-cmdline already provides a chunk of commands but > more are required to look like a modern distribution. > > LICENSE = "MIT" > > inherit core-image distro_features_check > > MACHINE_FEATURES += "acpi" > MACHINE_FEATURES += "apm" > MACHINE_FEATURES += "keyboard" > MACHINE_FEATURES += "pcbios" > MACHINE_FEATURES += "pci" > MACHINE_FEATURES += "rtc" > MACHINE_FEATURES += "screen" > MACHINE_FEATURES += "serial" > MACHINE_FEATURES += "wifi" None of those will have an impact. > REQUIRED_DISTRO_FEATURES = "x11" > DISTRO_FEATURES += "keyboard" > DISTRO_FEATURES += "ldconfig" Neither will those. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Removing busybox
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 I'd suggest dropping dnsmasq bridgeutils bindutils to keep it lean. Does that remove everything from meta-networking? Also swap vim for something in core obviously. Ross Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Removing busybox
On Wed, 27 Feb 2019 at 22:25, Jean-Christian de Rivaz wrote: > The project I work for need nodejs and chromium (and a >100MB database > on some nodes), so space is not an issue. I need to deliver an useful > distribution with usual commands, tools and a working console + keyboard > for my locale. If Poky is only maintained to be tested with sysvinit + > busybox and US locale, then I wonder if it's the appropriate choice for > that project. There nothing wrong in providing a sysvinit + busybox > based small distribution, this is simply not the best fit for that project. Installing the commands is pretty simple: be sure to install all of util-linux core-utils psutils etc. Yes, this should be a packagegroup to make it trivial, but this is practically a few minutes work. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Removing busybox
On Wed, 27 Feb 2019 at 21:41, Adrian Bunk wrote: > It is not obvious to me what usecases people have in mind for > getting rid of busybox, and whether everyone is aware that > something like "all busybox commands replaced" is *very* > expensive regarding filesystem size. Considering many of the people who are trying to not install a single byte of busybox are also installing toybox, the GPL is often the reason. Not sure how to square that with also using Linux though... Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Removing busybox
On Wed, 27 Feb 2019 at 18:45, Tom Rini wrote: > OK, so I've kicked things a bit harder again, and here's what I see as > the (small) rub. > $ git grep hddimg meta/conf/ > meta/conf/machine/include/x86-base.inc:IMAGE_FSTYPES ?= "hddimg" > > So yes, we can do a test with qemux86/qemux86-64 and documenting this in > local.conf.sample is good (and a packagegroup that gives more 1:1 > functionality is on my TODO list somewhere). But it's also true that > we'll get people with "I can't remove busybox and I tried what it says" > posts since blindly pulling in hddimg gives at least: > ERROR: Nothing RPROVIDES 'busybox-mdev' (but > /home/trini/work/OE/oe-core/meta/recipes-core/initrdscripts/initramfs-framework_1.0.bb > RDEPENDS on or otherwise requires it) > > That's the point I want to make, after throwing out a quick test build > dir. Sure, so the instructions include "don't use hddimg" until we've a way of not using busybox in the initramfs. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Removing busybox
On Wed, 27 Feb 2019 at 17:58, Tom Rini wrote: > I'm not sure we can blacklist busybox from the build at this time > (hddimg requires initramfs that requires busybox) but instead only force > remove it from the image and ensure it still builds. Don't build an image with a initramfs? -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Removing busybox
On Wed, 27 Feb 2019 at 17:27, Mark Hatle wrote: > You can also blacklist busybox to ensure that it never builds, and thus can't > show up in your target image. > > PNBLACKLIST[busybox] = "Don't build this" Sounds like someone should write a new selftest that does the required configuration changes as per Tom's mail, blacklists busybox, and then tries a core-image-sato build. This would double as a check that we don't break it in the future, and a documented example of how to do it Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to Install Third party rpm packages
On Mon, 25 Feb 2019 at 12:14, chaitanya cherukuri
wrote:
>> If I understand correctly, you want to me copy what script is doing in
>> do_install(). I was thinking to add the script has startup to a YOCTO
>> Image, so that I don't need to copy anything manually and let the script to
>> its job. This is how I am doing it in do_install()
>
> install -m 0755 ${S}/startup-script ${D}${sysconfdir}/init.d/
> ln -sf ../init.d/startup-script ${D}${sysconfdir}/rcS.d/S90startup-script
You'll need to do the install yourself, but the symlink generation
should be done with the update-rcd class.
Ross
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to Install Third party rpm packages
On Mon, 25 Feb 2019 at 00:45, chaitanya cherukuri wrote: > Thank you for the clarification. > In do_install(), I used rpm2cpio.sh to extract the rpm and then copied the > rpm contents in the right place. > $rpm2cpio.sh *.rpm | cpio -idmv > I hope this is the right way to handle RPM packages. Put the RPM in SRC_URI and bitbake will unpack it for you. > RPM has a post-installation script that I need to handle. This script > executes after the installation of RPM. Could I know what is the efficient > way to run the script? Easiest way is to just copy what it does into the recipe. Assuming that a postinst script for Fedora will work on your Yocto distribution is a risky move, just like you wouldn't expect the script to run without errors on Debian. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to Install Third party rpm packages
On Fri, 22 Feb 2019 at 22:16, chaitanya cherukuri wrote: > Do I need to write a recipe where I fetch this package? Yes, write a recipe that has SRC_URI as the original RPM, then you can write a do_install() to put the files in the right place, package it correctly, and so on. Just using the RPM as-is most likely won't work because the chances are your Yocto distribution isn't binary-compatible at the packaging level with whatever distribution the RPM was built for. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-mingw][PATCH] classes/toolchain-scripts-mingw32: Fix bad cmd flag
+1, feel free to push.
Ross
On Wed, 20 Feb 2019 at 21:35, Joshua Watt wrote:
>
> The command to properly set the exit code at the end of the toolchain
> environment was using the correct flag delimiter '/', but the code to
> coerce all the unix-style paths to windows paths was incorrectly
> changing this to a '\'. This worked find in wines cmd, but on an actual
> Windows host, this caused cmd to wait indefinitely. Fix this by
> appending the command after the path separators are coerced.
>
> Signed-off-by: Joshua Watt
> ---
> classes/toolchain-scripts-mingw32.bbclass | 22 +++---
> 1 file changed, 11 insertions(+), 11 deletions(-)
>
> diff --git a/classes/toolchain-scripts-mingw32.bbclass
> b/classes/toolchain-scripts-mingw32.bbclass
> index 32493d7..0afbf7d 100644
> --- a/classes/toolchain-scripts-mingw32.bbclass
> +++ b/classes/toolchain-scripts-mingw32.bbclass
> @@ -38,6 +38,17 @@ toolchain_create_sdk_env_script_sdkmingw32 () {
> # Change unix '/' to Win32 '\'
> sed -e 's,/,\\,g' -i $script
>
> + # set has some annoying properties:
> + # 1) If it is successful %ERRORLEVEL% is unchanged (as opposed to
> being set
> + #to 0 to indicate success)
> + # 2) Making an assignment like "set A=" is considered an error and
> sets
> + #%ERRORLEVEL% to 1.
> + #
> + # Practically, this means that if any of the set calls make an empty
> + # assignment that error will be propagated. To prevent this, a
> command is
> + # run to ensure that the "exit code" of this script is 0
> + echo "@%COMSPEC% /C exit 0 > NUL" >> $script
> +
> # Make the file windows friendly...
> awk 'sub("$", "\r")' $script > $script.new
> mv $script.new $script
> @@ -81,17 +92,6 @@ toolchain_shared_env_script_sdkmingw32 () {
> FOR %%x IN (%OECORE_NATIVE_SYSROOT%\\environment-setup.d\\*.bat) DO call
> "%%x"
> )
> EOF
> -
> - # set has some annoying properties:
> - # 1) If it is successful %ERRORLEVEL% is unchanged (as opposed to
> being set
> - #to 0 to indicate success)
> - # 2) Making an assignment like "set A=" is considered an error and
> sets
> - #%ERRORLEVEL% to 1.
> - #
> - # Practically, this means that if any of the set calls make an empty
> - # assignment that error will be propagated. To prevent this, a
> command is
> - # run to ensure that the "exit code" of this script is 0
> - echo "@%COMSPEC% /C exit 0 > NUL" >> $script
> }
>
> toolchain_create_sdk_siteconfig_append_sdkmingw32 () {
> --
> 2.20.1
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-mingw][PATCH] diffutils: Upgrade to 3.7
Looks good to me, feel free to push.
Ross
On Wed, 20 Feb 2019 at 21:14, Joshua Watt wrote:
>
> Upgrade diffutils from 3.6 to 3.7. The upstream made several fixes so
> the local patches are no longer necessary, but the gnulib-tests need to
> be dropped since they do not compile properly. Since there are no more
> local patches, the bbappend can be made to match all versions.
>
> Signed-off-by: Joshua Watt
> ---
> .../diffutils/diffutils/sdiff-no-kill.patch | 32 ---
> .../diffutils/diffutils_%.bbappend| 14
> .../diffutils/diffutils_3.6.bbappend | 18 ---
> 3 files changed, 14 insertions(+), 50 deletions(-)
> delete mode 100644 recipes-extended/diffutils/diffutils/sdiff-no-kill.patch
> create mode 100644 recipes-extended/diffutils/diffutils_%.bbappend
> delete mode 100644 recipes-extended/diffutils/diffutils_3.6.bbappend
>
> diff --git a/recipes-extended/diffutils/diffutils/sdiff-no-kill.patch
> b/recipes-extended/diffutils/diffutils/sdiff-no-kill.patch
> deleted file mode 100644
> index c9fbc24..000
> --- a/recipes-extended/diffutils/diffutils/sdiff-no-kill.patch
> +++ /dev/null
> @@ -1,32 +0,0 @@
> -Upstream-Status: Backport
> -Signed-off-by: Ross Burton
> -
> -From 56225ecca4f9598c0c9dbd7c46a51dd4816a383f Mon Sep 17 00:00:00 2001
> -From: Paul Eggert
> -Date: Fri, 20 Apr 2018 13:39:15 -0700
> -Subject: sdiff: port to mingw
> -MIME-Version: 1.0
> -Content-Type: text/plain; charset=UTF-8
> -Content-Transfer-Encoding: 8bit
> -
> -Problem reported by Ross Burton (Bug#31218).
> -* src/sdiff.c (checksigs): Use ‘raise’, not ‘kill’.
>
> - src/sdiff.c | 2 +-
> - 1 file changed, 1 insertion(+), 1 deletion(-)
> -
> -diff --git a/src/sdiff.c b/src/sdiff.c
> -index 1b23a0c..b08bc74 100644
> a/src/sdiff.c
> -+++ b/src/sdiff.c
> -@@ -805,7 +805,7 @@ checksigs (void)
> -
> - /* Yield an exit status indicating that a signal was received. */
> - untrapsig (s);
> -- kill (getpid (), s);
> -+ raise (s);
> -
> - /* That didn't work, so exit with error status. */
> - exit (EXIT_TROUBLE);
> ---
> -cgit v1.0-41-gc330
> diff --git a/recipes-extended/diffutils/diffutils_%.bbappend
> b/recipes-extended/diffutils/diffutils_%.bbappend
> new file mode 100644
> index 000..2c54a55
> --- /dev/null
> +++ b/recipes-extended/diffutils/diffutils_%.bbappend
> @@ -0,0 +1,14 @@
> +FILESEXTRAPATHS_prepend_mingw32 := "${THISDIR}/${BPN}:"
> +
> +# Add some definitions for POSIX signals..
> +CFLAGS_append_mingw32 = " -DSIGALRM=14 -DSIGHUP=1 -DSIGQUIT=3 -DSIGPIPE=13
> -DSIGTSTP=18 -DSIGSTOP=17 "
> +
> +do_configure_prepend_mingw32 () {
> +# Remove building of "man" and "gnulib-tests". The tests don't
> +# cross-compile for mingw, but we aren't using them anyway
> +sed -i \
> +-e 's:^SUBDIRS =\(.*\) man\>:SUBDIRS = \1 :g' \
> +-e 's:^SUBDIRS =\(.*\) gnulib-tests\>:SUBDIRS = \1 :g' \
> +${S}/Makefile.am
> +}
> +
> diff --git a/recipes-extended/diffutils/diffutils_3.6.bbappend
> b/recipes-extended/diffutils/diffutils_3.6.bbappend
> deleted file mode 100644
> index f301349..000
> --- a/recipes-extended/diffutils/diffutils_3.6.bbappend
> +++ /dev/null
> @@ -1,18 +0,0 @@
> -
> -FILESEXTRAPATHS_prepend_mingw32 := "${THISDIR}/${BPN}:"
> -
> -SRC_URI_remove_mingw32 =
> "file://0001-explicitly-disable-replacing-getopt.patch"
> -SRC_URI_append_mingw32 = " file://sdiff-no-kill.patch"
> -
> -CACHED_CONFIGUREVARS_append_mingw32 = " ac_cv_header_getopt_h=yes "
> -
> -# Add some definitions for POSIX signals..
> -CFLAGS_append_mingw32 = " -DSIGALRM=14 -DSIGHUP=1 -DSIGQUIT=3 -DSIGPIPE=13
> -DSIGTSTP=18 -DSIGSTOP=17 "
> -
> -do_configure_prepend_mingw32 () {
> -# Remove building of "man"
> -sed -i -e 's:^SUBDIRS = lib src tests doc man po gnulib-test:SUBDIRS =
> lib src tests doc po gnulib-test:g' ${S}/Makefile.am
> -}
> -
> -
> -
> --
> 2.20.1
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Two recipes install the same file
On Thu, 14 Feb 2019 at 20:29, Chuck Wolber wrote: > I have run across this a few times, particularly with man pages, when > including upstream packages into my images. > > I have to use a bbappend recipe in my meta layer to remove the lower priority > version. If you've two manpages with the same name that suggests that there are two binaries with the same name, which presumably are already using update-alternatives. The correct fix here is to use update-alternatives for the manpage too. Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Two recipes install the same file
Two packages can't install the same file. In this case I suspect you'll need to split up the packaging further. A common alternative for binaries in /bin which want to be installed by both e.g. coreutils and busybox is to use update-alternatives. Ross On Thu, 14 Feb 2019 at 16:36, madoga wrote: > > Hello everyone, > > I have an issue while I'm trying to overwrite some files that two recipes are > installing. Task do_rootfs fails and I want to ask about the best way to > solve this: > > - > Error: Transaction check error: > file /app/econfig.xml conflicts between attempted installs of tests-1.0-r0 > and error-1.0-r0 > file /app/controller.xml conflicts between attempted installs of > tests-1.0-r0 and controller-1.0-r0 > file /app/user_mode.xml conflicts between attempted installs of mode-1.0-r0 > and tests-1.0-r0 > Error Summary > - > When I launch bitbake with a concrete image this error appears and I don't > know how I can give "priority" to a recipe. I have found something about > create .bbappend file... > > Thank you, > Mario > > > > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] glxinfo
It's part of mesa-demos. Ross On Tue, 12 Feb 2019 at 16:14, Peter Balazovic wrote: > > I'd like to ask which yocto recipe has "glxinfo" available? I will make > available that package within local.conf... > > Thanks. > Peter > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Python default libraries
You're probably not depending on the entire library so you only get what you ask for. Instal python3-modules and you'll get all of the standard library. On Tue, 12 Feb 2019 at 16:14, Emily Smith wrote: > > Hi - > > I’ve been working with yocto and with some code running on my OS, however I’m > seeing errors that seem to indicate that default python libraries are no > longer included (specifically logging and importlib). Has something about the > default python libraries changed? > > Thanks! > Emily Smith > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] recipe that worked on morty fails on sumo
You're probably using DISTRO=poky, which now disables static libraries.
This is the periodic reminder for the list that the Poky distro is an
example, and does change over time. If you want control over the distro
then create your own distro.
Ross
On Sat, 9 Feb 2019 at 00:01, Greg Wilson-Lindberg
wrote:
>
> I'm working on a boot2qt build of Yocto and the latest release converted
> to sumo. I'm have a recipe for canfestival that we have been using for
> builds with morty that uses several of the packages that are provided by
> the PACKAGES symbol:
>
>
> #original from morty
> #FILES_${PN}-dev = "/usr/lib/libcanfestival*.a
> /usr/include/canfestival/*.h"
> FILES_${PN}-dev = "/usr/lib/libcanfestival*.a"
> #FILES_${PN} = "/usr/lib/libcanfestival*.a /usr/lib/libcanfestival*.so"
> FILES_${PN} = "/usr/include/canfestival/*.h /usr/lib/libcanfestival*.so"
>
> RDEPENDS_${PN}-dev += "${PN}-staticdev"
>
>
> # new try for sumo
> FILES_${PN}-staticdev = "/usr/lib/libcanfestival*.a "
> FILES_${PN}-dev = "/usr/include/canfestival/*.h"
> #FILES_${PN} = "/usr/lib/libcanfestival*.a /usr/lib/libcanfestival*.so"
> #FILES_${PN} = "/usr/include/canfestival/*.h /usr/lib/libcanfestival*.so"
> FILES_${PN} = "/usr/lib/libcanfestival*.so"
>
> RDEPENDS_${PN}-dev += "${PN}-staticdev"
>
> The top version worked on morty, but on sumo I get an error:
>
> Collected errors:
> * Solver encountered 1 problem(s):
> * Problem 1/1:
> * - nothing provides canfestival-staticdev needed by
> canfestival-dev-3-asc-r01.cortexa7hf-neon-vfpv4
> *
>
> I tried changing the lines to explicitly define -staticdev files, but I
> still get the same error.
>
> I would have thought that the bitbake.conf definition of PACKAGES would
> take care of the supplier, but I seem to be wrong.
>
> Can someone point me to what I need to do to tell bitbake that the recipe
> provides -staticdev?
>
> Greg Wilson-Lindberg
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to archive only packages contained in a certain image
Those recipes are special: the gcc-source recipe fetches and and unpacks the GCC source tree, and gcc builds it. So gcc has no source... Add gcc-source explicitly to your list and you'll be sorted. Ross On Mon, 4 Feb 2019 at 16:23, David Zimmermann wrote: > > Thanks for your helpful hints Ross ! > > I now have a script in place which: > - extracts package names from image manifest > - translates package names to recipe names > - grabs the source packages for those recipes (from what the archiver > extracted according to it’s config) > > For two recipes, referenced by the manifest file, the archiver does extract > no source packages: > - libgcc > - gcc-runtime > Why is that ? > > Regards, > David > > > Am 31.01.2019 um 15:46 schrieb Burton, Ross : > > > > Please remember to keep the list on CC. > > > > The reason is that those recipes are built for the target so they'll > > be archived, the archiver doesn't distinguish what recipes go into > > what image. > > > > It's relatively simple to filter the list after the build if you want > > to produce just what is in a specific image, take the image manifest > > and use oe-pkgdata-util to turn the package names into recipes. > > > > Ross > > > > On Thu, 31 Jan 2019 at 14:01, David Zimmermann > > wrote: > >> > >> Hi Ross, > >> > >> and thanks for your reply. > >> I do bake an image based on core-image-minimal with additional packages > >> like openssh and qt (-base, -declarative, -quickcontrols). > >> My folder ’tmp/deploy/sources/arm-poky-linux-gnueabi’ e.g. contains: > >> perl, pulseaudio and python > >> > >> Even though those might be dependencies I inherited by other recipes - > >> python e.g. is not contained / will be installed to my image. > >> As a countercheck I see what licenses will be placed in the image > >> (COPY_LIC_DIRS = 1 && COPY_LIC_MANIFEST = 1) which reflects the limited > >> number of packages I do expect. > >> > >> Regards, > >> David > >> > >>> Am 31.01.2019 um 11:11 schrieb Burton, Ross : > >>> > >>> Does it not just contain the packages used to build the entire image, > >>> so build-time dependents. Can you give an example of a recipe that is > >>> archived but shouldn't be? > >>> > >>> Ross > >>> > >>> On Thu, 31 Jan 2019 at 08:46, David Zimmermann > >>> wrote: > >>>> > >>>> Hi List, > >>>> > >>>> I use Yocto Krogoth and the following configuration for the archiver: > >>>> > >>>> INHERIT += „archiver“ > >>>> COPYLEFT_RECIPE_TYPES = ’target’ > >>>> > >>>> But the ‚tmp/deploy/sources/…/‚ folder for my target architecture > >>>> contains much more packages then those ‚used‘ to build my image. > >>>> Is there a way to extract / archive / isolate only those package sources > >>>> used for a certain image (kernel + rootfs) ? > >>>> > >>>> Thanks for your help, > >>>> David > >>>> -- > >>>> ___ > >>>> yocto mailing list > >>>> yocto@yoctoproject.org > >>>> https://lists.yoctoproject.org/listinfo/yocto > >> > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
