Re: [yocto] Downloading Git Archives

get works for > you this should actually automatically work for you. If you build system > can at least download using http then > > bitbake --runall=fetch > > should download all the sources for you. Then you can disconnect the box > from the Internet and start the buil

[yocto] Downloading Git Archives

Hi All, Our build environment is stuck behind a firewall with no access to the Internet. When a Yocto build requires a new package, we normally extract the URL from the failed build log and "wget" the package from the upstream source, do our due diligence (checksums, etc), and then add it to the

Re: [yocto] Yocto System Requirement for developing OS

It depends on a lot of factors. But for actually building yocto images... I find that 1.5 gigs of RAM per CPU seems to be about right on the virtual machines we use to build images. ..Ch:W.. On Fri, Apr 26, 2019 at 17:29 raja.g kumar wrote: > Hi > Can I know the RAM ,Disk space and processor

Re: [yocto] Storing Sstate in S3 success stories?

Have you done any wireshark analysis on the traffic? My guess is that the round trip with network latency is bumping your build time by a factor of at least 100x. The state-cache is hammered on continuously, so have probably introduced a significant bottleneck. ..Ch:W.. On Mon, Feb 25, 2019 at

Re: [yocto] npm recipe bad task order

Normally the source archive is unpacked first, which contains the license file. Is there something different with the source packaging for your recipe? ..Ch:W.. On Thu, Feb 14, 2019 at 02:26 Jonas Andersson wrote: > Hi, > > I have some recipes created from npm packages with devtool. > >

Re: [yocto] icecast

You have to refactor xslt-config out of the autotools macros and use pkg-config instead. This recipe is an example: meta/recipes-devtools/swig/swig/0001-configure-use-pkg-config -for-pcre-detection.patch ..Ch:W.. On Thu, Feb 14, 2019 at 05:57 Leonardo Jose Duarte MendesJunior <

Re: [yocto] Two recipes install the same file

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. I quite like the feature because it ensures that all collisions are known and dealt with in a

Re: [yocto] XSLT-CONFIG ERROR

You have to refactor the Icecast bitbake recipe to use pkg-config instead of xslt-config. This patch might give you some ideas: meta/recipes-devtools/swig/swig/0001-configure-use-pkg -config-for-pcre-detection.patch I patched modsecurity to fix the same issue. It mostly works, but their build

Re: [yocto] pcre-config replacement

On Thu, Jan 31, 2019 at 2:14 AM Burton, Ross wrote: > pkg-config. Inherit the pkgconfig class in the recipe if it doesn't > already, and see for example > > meta/recipes-devtools/swig/swig/0001-configure-use-pkg-config-for-pcre-detection.patch > in oe-core for an example. > > This is an

[yocto] pcre-config replacement

What is the recommended packaging approach for an upstream configure script that seems to think that it must have pcre-config (which is disabled by the binconfig-disabled class)? Looking at the source of the upstream package seems to indicate that they actually do need pcre, so this is not as

[yocto] Deactivating KERNEL_FEATURES

This question is with respect to the Yocto thud (2.6.x) branch. I have also reviewed section 2.3.3 and 2.3.4 of the Kernel Development document . My kernel configuration (cfg) seems to be overridden by KERNEL_FEATURES and it is

Re: [yocto] Yocto Thud - /lib64 link - Build Failure

pend_libc-glibc > = " prelink_setup; prelink_image; " > > And as it's using _append, it will be after your 'symlink_lib64'. > Maybe using IMAGE_PREPROCESS_COMMAND_append = " symlink_lib64; " would > work for you? > > Best Regards, > Chen Qi > > On 11/2

[yocto] Yocto Thud - /lib64 link - Build Failure

Background: I have an image that works in pyro. I am migrating the image to thud. Some of the add-on code to our image requires the /lib64 directory (in particular the VirtualBox Additions). I have proven that a simple symlink (/lib -> /lib64) fixes the problem. This symlink was being applied