Hi,
I suspect this is documented in a FAQ somewhere, but I'm failing to hit
the correct keywords when googling...
Is there a way to support building images for multiple MACHINEs in a
single workspace at the same time?
This works:
$ MACHINE=qemux86 bitbake core-image-minimal
$ MA
On Thu, May 05, 2016 at 06:45:36AM -0700, Khem Raj wrote:
> > This works:
> >
> > $ MACHINE=qemux86 bitbake core-image-minimal
> > $ MACHINE=qemux86-64 bitbake core-image-minimal
> >
> > and bitbake parallelizes the build across tasks. What I'm trying to
> > figure out is if it's possibl
On Sat, Jul 02, 2016 at 09:02:32AM +0100, Burton, Ross wrote:
> On 2 July 2016 at 03:12, Takashi Matsuzawa
> wrote:
>
> > There seems to be PyPy, Stackless Python, etc. but I am not sure
> > they can be tried 'in-place' to see if they work faster.
> >
> In the context of a bitbake build, the over
On Thu, May 10, 2018 at 10:22:34AM +0100, Burton, Ross wrote:
$ bitbake image-foo image-bar
image-foo and image-bar both contain recipe-flob. recipe-flob will be
built *once* to generate the packages, and those packages used to build
both images. If image-foo is read-only and image-bar is rea
On Fri, Jul 06, 2018 at 09:11:35PM +0200, Ulf Samuelsson wrote:
In my current project we have a simplified version in a
”component.bbclass”. It relies on a variable COMPONENT_DIR
defined in our local.conf.
A recipe located in ”recipe-//_$PV.bb” doing
inherit component
will find its sour
On Wed, Dec 06, 2017 at 02:13:26PM +, Koehler, Yannick wrote:
> In regards to file fetcher, I will go check the code, I thought the
> unpack would only occurs for tarball, not subdir.
If you have:
SRC_URI := "file://some-dir/"
and your tree looks somewhat like this:
.git
On Wed, Dec 06, 2017 at 10:59:37AM -0600, Koehler, Yannick wrote:
> Ok, will try that. If that works, I may see if I can alter the file
> fetcher to use symlinks, not sure if sstate subsystem will like that
> or not.
That was my idea, but I've never tried it. I'm sure the devil is in the
details.
Hi,
I'm in the process of cleaning up our usage of Yocto with the goal of
improving longer-term maintainability, basically implementing something
like this:
http://events.linuxfoundation.org/sites/events/files/slides/Yocto-upgrades-ELC-2017.pdf
Right now I'm looking at several .bbclass files whi
Sorry to go off on a tangent:
On Fri, Mar 04, 2016 at 04:12:54PM -0800, robert_jos...@selinc.com wrote:
> root@test:~# btrfs scrub start /
> scrub started on /, fsid 79dc4fed-a0f7-43e2-b9e7-056b1a2c4cdd
(pid=333)
> libgcc_s.so.1 must be installed for pthread_cancel to work
>
> I can solve thi
On Thu, Mar 08, 2018 at 03:16:44PM -0600, Mark Hatle wrote:
RDEPENDS are automatically promoted to DEPENDS (build-time). I would normally
expect libgcc_s.so.1 to be present via the typical default depends. Does your
recipe have an INHIBIT_DEFAULT_DEPENDS (I think that is it?) defined? If so,
On Thu, Mar 08, 2018 at 01:30:28PM -0800, robert_jos...@selinc.com wrote:
In the case of btrfs-tools, it was simply that it needed libgcc_s.so.1 at
runtime on the target, which my patch fixed. For me, the image I was
building normally worked fine because some other package would pull in
libgcc,
ch and
add /var/lib/nfs to the list of special directories. Needless to say,
this doesn't scale well.
Any comments?
Marcelo
>From fc8819afbadf1e2ffa30babc45267a92ae78e246 Mon Sep 17 00:00:00 2001
From: "Marcelo E. Magallon"
Date: Fri, 30 Dec 2016 09:01:30 -0800
Subject: [PATCH
On Thu, May 25, 2017 at 01:13:03PM +, Koehler, Yannick (HPN Aruba) wrote:
> The case I am mostly interested about is the Vendor layers, if I pull
> in meta-openembedded or meta-freescale in my yocto distro, I will
> never touch those layer at the git level, instead whatever change I
> want wil
13 matches
Mail list logo
