[yocto] [ANNOUNCEMENT] Milestone 3 for Yocto Project 2.4 (yocto-2.4_M3) now available

The third milestone release for Yocto Project 2.4 (yocto-2.4_M3) is available for download now. Download: http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-2.4_M3/ eclipse-poky-mars 92aa0e79e8b01c56f0670af3cd8296ec68b43350 eclipse-poky-neon 83e0083ef3a71e10039ace7d18057dddc15440

Re: [yocto] [psplash][PATCH] Fix text width calculation.

Merged to master, thanks. Ross On 11 August 2017 at 22:18, Kevin Corry wrote: > Psplash: Fix text width calculation. > > Using the "psplash-write MSG " command, you can display > messages > when the splash screen is running. As part of this, psplash needs to > calculate > the height and width o

Re: [yocto] Pyro's uninative and libstdc++ symbols

On Fri, 2017-09-01 at 12:14 -0700, akuster wrote: > > On 08/29/2017 01:03 AM, Richard Purdie wrote: > > > > On Fri, 2017-08-25 at 14:50 +0200, Raphael Kubo da Costa wrote: > > > > > > I've recently updated my host system to Fedora 26, which has GCC > > > 7. > > > > > > This seems to be causing

Re: [yocto] Pyro's uninative and libstdc++ symbols

On 08/29/2017 01:03 AM, Richard Purdie wrote: On Fri, 2017-08-25 at 14:50 +0200, Raphael Kubo da Costa wrote: I've recently updated my host system to Fedora 26, which has GCC 7. This seems to be causing some issues on Pyro, where I have a -native recipe that is built with my system's g++ and

[yocto] modify sources.list file

Hi, I am build a deb package manager for the target image. for that i set these variables in conf/local.conf > *PACKAGE_FEED_URIS = "http:///my-repo/yahia-repo/expiremental \* > > *"* > > *PACKAGE_FEED_BASE_PATHS = "deb"* > > *PACKAGE_FEED_ARCHS = "all"* > >

[yocto] do_package: pseudo_append_element: path too long (wanted 4098 bytes)

Hello, I have written a recipe that copies files to rootfs and I am getting the following error when running bitbake: ERROR: pm2-bunyan-0.1-r1.4 do_package: file copy failed with exit code 2 (cmd was tar -cf - -C [local-path]/tmp/work/cortexa7hf-neon-dey-linux-gnueabi/pm2-bunyan/0.1

Re: [yocto] cannot re-use shared state cache between build hosts

On Fri, Sep 1, 2017 at 5:04 PM, Andrea Galbusera wrote: > Hi Maciej, > > On Fri, Sep 1, 2017 at 4:08 PM, Maciej Borzęcki > wrote: >> >> On Fri, Sep 1, 2017 at 3:54 PM, Andrea Galbusera wrote: >> > Hi! >> > >> > I was trying to share sstate between different hosts, but the consumer >> > build >>

Re: [yocto] cannot re-use shared state cache between build hosts

Hi Maciej, On Fri, Sep 1, 2017 at 4:08 PM, Maciej Borzęcki wrote: > On Fri, Sep 1, 2017 at 3:54 PM, Andrea Galbusera wrote: > > Hi! > > > > I was trying to share sstate between different hosts, but the consumer > build > > system seems to be unable to use re-use any sstate object. My scenario i

Re: [yocto] cannot re-use shared state cache between build hosts

On Fri, Sep 1, 2017 at 3:54 PM, Andrea Galbusera wrote: > Hi! > > I was trying to share sstate between different hosts, but the consumer build > system seems to be unable to use re-use any sstate object. My scenario is > setup as follows: > > * The cache was populated by a pristine qemux86 core-im

Re: [yocto] cannot re-use shared state cache between build hosts

On Fri, Sep 1, 2017 at 3:57 PM, Martin Jansa wrote: > Why do you use: > > ";downloadfilename=PATH > " > > ? > Most likely because I copy/pasted from local.conf comments. I see the same syntax on both "morty" [1] and "current" docu

Re: [yocto] cannot re-use shared state cache between build hosts

Why do you use: ";downloadfilename=PATH " ? On Fri, Sep 1, 2017 at 3:54 PM, Andrea Galbusera wrote: > Hi! > > I was trying to share sstate between different hosts, but the consumer > build system seems to be unable to use re-use

[yocto] cannot re-use shared state cache between build hosts

Hi! I was trying to share sstate between different hosts, but the consumer build system seems to be unable to use re-use any sstate object. My scenario is setup as follows: * The cache was populated by a pristine qemux86 core-image-minimal build of morty. This was done in a crops/poky container (

[yocto] [meta-security][v2][PATCH] fail2Ban: Add new package

Fail2Ban scans log files like /var/log/auth.log and bans IP addresses having too many failed login attempts. It does this by updating system firewall rules to reject new connections from those IP addresses, for a configurable amount of time. Fail2Ban comes out-of-the-box ready to read many stand

Re: [yocto] [meta-security][PATCH] fail2bin: Add new package

Hello Paul, On 08/31/2017 10:35 PM, Paul Eggleton wrote: Hi Armin, On Friday, 1 September 2017 5:09:23 PM NZST Armin Kuster wrote: Fail2Ban scans log files like /var/log/auth.log and bans IP addresses having too many failed login attempts. It does this by updating system firewall rules to re

Re: [yocto] apt-key not found

On 09/01/2017 06:17 AM, yahia farghaly wrote: So, what the right way to do this ? You should study how signing RPM/IPK package feeds is done in Yocto, and modify the code in the same way. Start from meta/recipes-core/meta/signing-keys.bb meta/classes/sign_package_feed.bbclass meta/lib/oe/pa

Re: [yocto] Building Custom Python 3 Packages

On 08/31/2017 04:54 PM, Seilis, Aaron wrote: This clearly indicates that the issue is that the build is looking for setup.py in the ${B} location, but it is only present in the ${S} location when `devtool modify` has been run. I have tried setting ${B} to ${S} explicitly in the recipe, but this d

Re: [yocto] [meta-gplv2][PATCH] gmp_4.2.1: prevent calls to mpn_add_nc() if HAVE_NATIVE_mpn_sub_nc is false

Sorry I'd merged but not pushed. Now pushed. Ross On 31 August 2017 at 19:49, Andre McCurdy wrote: > On Fri, Aug 25, 2017 at 5:50 PM, Andre McCurdy > wrote: > > When building for aarch64 (ie relying only on generic C code rather > > than asm) libgmp.so contains undefined references to __gmpn_