Tracked down the problem to the fact that conflict checking in RPM 5.4.16 in
Morty is broken.
Backported some changes from upstream and it is working for me now (i.e.,
detecting and
reporting the conflict.)
MV
From: Vuille, Martin (Martin)
Sent: March 09, 2018 20:50
To: yocto@yoctoproject.org
Ran into an issue where we have two packages installing different
content for the same file in rootfs. Whichever gets installed last "wins".
I thought there was a check to prevent this. I'm sure I've seen a
warning/error like that in the past.
Is this condition detected? Should it be?
We're usin
Transitioning from Fido to Morty
Noticed that there now QA warnings for packages with incorrect names.
But it seems these warnings only show up in tmp/qa.txt, they are not displayed
in the build output.
Is that a bug or intentional? Is there a way to make them appear in the
build output?
MV
--
In the process of transitioning from Fido to Morty.
In the past, when sanity detected a version mismatch with some of
the configuration files (e.g., local.conf, bblayers.conf,) an error message
was displayed.
Now, we see the below, which I do not find very informative or helpful.
Is that a bug o
> -Original Message-
> From: Burton, Ross [mailto:ross.bur...@intel.com]
>
> On 28 November 2016 at 15:02, Vuille, Martin (Martin)
> wrote:
> Or am I completely off-track?
>
> It will track the md5 of files mentioned in SRC_URI, but if a file is
> generated
I have a custom recipe for building some peculiarly-structured code:
the Makefile is compiling source from ${S}/.. (i.e., parent directory of
the ${S} directory).
It seems (not 100% sure of this, sstate is still "magic" to me) that the sstate
hash only includes the files in ${S} (which is reasonab
Currently using Yocto 1.8, planning upgrade to 2.2
Per the Reference Manual, "The uninative class is now enabled by default in
Poky. [...]
With this class enabled, a tarball containing a pre-built C library is
downloaded at the start of the build."
We have to build with BB_NO_NETWORK = "1"
How
Thanks Ross, Khem
It looks like we aren’t setting ‘read-only-rootfs’
Our images and init are very customized, so we missed that.
Will look into it.
Regards,
MV
From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: November 09, 2016 08:19
To: Vuille, Martin (Martin)
Cc: yocto@yoctoproject.org
We are running with our rootfs mounted read-only.
Consequently, any postinsts that get deferred to first boot fail.
Is there a way to fail the build for any postinsts that can't
be performed during the build and have to be deferred?
MV
--
___
yocto mai
> From: Khem Raj [mailto:raj.k...@gmail.com]
> Sent: November 07, 2016 12:37
>
> On 11/7/16 9:27 AM, Vuille, Martin (Martin) wrote:
> > I see that “sysvinit” and “systemd” style init is supported.
> >
> >
> >
> > Is there support for BSD-style init, or s
I see that "sysvinit" and "systemd" style init is supported.
Is there support for BSD-style init, or some other minimal init?
Does anyone know of such support in a separate layer?
MV
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yocto
Has there ever been any discussion of making select releases
"Long Term Support" releases, i.e., committing to support them
for a number of years?
Presumably that would entail having the resources to commit
a maintainer to that release for the LTS interval.
Out of curiosity, how much effort is re
Thank you for the quick answer
MV
From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: November 01, 2016 11:28
To: Vuille, Martin (Martin); Rifenbark, Scott M
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Yocto 2.2 Morty supported Linux Distros
On 1 November 2016 at 15:19, Vuille, Martin
Noticed that Ubuntu 16.04 LTS is not on the list of supported
distributions for Morty.
Is that correct/intentional, or a documentation oversight?
Ubuntu 16.04 is mentioned elsewhere in the docs.
We are planning to upgrade from Ubuntu 12.04 LTS and it would
make more sense to go to the latest LTS
I should clarify that these build machines are not for Yocto builds,
but for building an application that uses the Yocto SDK.
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On
Behalf Of Vuille, Martin (Martin)
Sent: October 31, 2016 10:38
To: yocto@yoctoproject.org
We are looking at upgrading from Yocto 1.8 to 2.2.
Yocto 2.2 has a minimum kernel requirement of 3.2.0.
This isn't an issue for our target (ARMv5, Linux 4.4) but may be
an issue for our automated build machines (x86, Linux 2.6.32-CentOS 6.)
However, there is a note that says
"For x86 and x86_64,
I am building two out-of-tree KLMs with separate yocto recipes.
One of the KLMs depends on a data structure defined in the other one. At
present the structure definition is simply duplicated in both KLMs' source.
I would prefer to define it in a header that one KLM can export and the other
can #in
> From: Khem Raj [mailto:raj.k...@gmail.com]
> Sent: January 19, 2016 1:58 PM
>
> its a distro policy based upon licensing if weak assignment is used then the
> licensing won’t be able to enforce the decision
> if someone overrides it.
Thanks, that makes sense.
MV
--
__
ked if it hadn't been
overridden
by this one.
MV
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On
Behalf Of Vuille, Martin (Martin)
Sent: January 19, 2016 8:16 AM
To: yocto@yoctoproject.org
Subject: [yocto] PREFERRED_VERSION for native package
Yocto Fido
Yocto Fido
I am trying to use PREFERRED_VERSION to select an earlier version
of the "db" package. The build includes both db and db-native variants
of the package.
I set PREFERRED_VERSION_db variable and this successfully changes
the version of the db package but not the db-native package.
I tri
in a "wrapper" header and make your
customizations in the wrapper instead?
Regards,
MV
> -Original Message-
> From: Longchamp, Valentin [mailto:valentin.longch...@keymile.com]
> Sent: December 10, 2015 4:47 AM
> To: Vuille, Martin (Martin); yocto@yoctoproject.or
Hi Valentin,
Not sure whether this the “canonical” Yocto way, but here’s how we solved
the same issue.
First, let me say that we use a BSP from our technology partner, and have
our own meta-XXX layer for customization.
- Created a .bbappend in our layer for the kernel recipe
-
What is the best way to refer to (require) a .inc recipe
in one layer from another layer?
MV
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
In my custom .bbclass, I have a python function
python whatever () {
...
}
and I would like to call it from a shell function
do_something () {
...
whatever
...
}
but bitbake gives me an error "whatever: not found" when building
recipes based on this class
Is what I am trying to
> From: Khem Raj [mailto:raj.k...@gmail.com]
> Sent: October 14, 2015 1:25 PM
>
>
> > On Oct 14, 2015, at 9:25 AM, Vuille, Martin (Martin)
> > wrote:
> >
> > Hi,
> >
> > I am having a bit of trouble understanding something about
> >
Hi,
I am having a bit of trouble understanding something about
packaging.
I have a custom recipe to build a package that contains both
a daemon executable and a shared object interface library
for the daemon.
But the .so is only packaged in ${PN}-dev, not ${PN}, so
it doesn't end up on the targe
> -Original Message-
> From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
> Sent: June 03, 2015 3:42 AM
>
> On Tuesday 02 June 2015 19:58:50 Vuille, Martin wrote:
> > Yocto 1.6.1
> >
> > I have added a module to my kernel.
> >
> > The module is getting built, I see a kernel-module-
Yocto 1.6.1
I have added a module to my kernel.
The module is getting built, I see a kernel-module-blah-blah RPM
and it contains the .ko
I add kernel-module-blah-blah to one of the packagegroups
contained in my image, I see do_rootfs task run, but the module
is not in the image. In log.do_rootfs
module by changing modules.alias line
from "alias net-pf-10 ipv6" to "alias net-pf-10 off"
Any suggestions how to do this?
MV
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On
Behalf Of Vuille, Martin (Martin)
Sent: May 08, 2015 4:04 PM
To: yo
I see that depmod/depmodwrapper is being run in a postinst
script in kernel.bbclass.
I need to adjust the contents of modules.alias after it has been
generated.
Can someone suggest what would be the "right" way to do this?
MV
--
___
yocto mailing list
> From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
> Sent: March 25, 2015 9:51 AM
>
> Just define the empty sysroot_stage_dirs, not populate_sysroot. The
> stage_dirs function handles copying files so if its empty, no files will be
> copied in.
>
Thanks, Richard, works fine!
MV
-
> From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
> Sent: March 25, 2015 9:09 AM
>
> On Tue, 2015-03-24 at 22:22 +0000, Vuille, Martin (Martin) wrote:
> > Is there a better way to suppress populate_sysroot without breaking
> > setscene?
>
> Defi
Poky Daisy 1.6.1
I have a custom package of font files and a custom recipe to install then
into ${libdir}/fonts.
I don't want these files in the sysroot, as they are not necessary there,
they are only required on the target, and they make the SDK larger.
In my recipe, I defined an empty populate
6
MV
From: Khem Raj [mailto:raj.k...@gmail.com]
Sent: March 09, 2015 4:47 PM
To: Vuille, Martin (Martin)
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Yocto Daisy 1.6.1 on CentOS 6.5
On Mar 9, 2015, at 1:36 PM, Vuille, Martin (Martin)
mailto:vmar...@avaya.com>> wrote:
The Yocto 1.
The Yocto 1.6.1 Project Reference Manual states that it is supported and tested
against CentOS release 6.5, but later states that Python 2.7.3 is required,
CentOS 6.5
seems to have an older version of Python (2.6.6).
The build does not, in fact, work and complains that the version of Python is
t
Poky Daisy 1.6.1
We have to fetch a git repo using https protocol. We are looking to
see whether we can change this to ssh instead, but that is not
possible at the moment.
Access requires a userid and password. We do not want to hard-code
the credentials into the recipe or into some other file li
Poky Daisy 1.6.1
I have a recipe that must fetch from a git repo using https. I have specified
";protocol=https" in the SRC_URI.
The fetch task for this recipe is failing with:
ERROR: Fetcher failure: Fetch command failed with exit code
128, output:
Cloning into
I have read the information at
https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance
I would like to know how long stable branches are maintained.
If we are using daisy (1.6), how long can we count on point releases with
security patches before we should plan to upgrade to a newer release
We build Qt4-embedded and export the headers and libraries
into the SDK for the application to build against.
We also include nativesdk-qt4-tools in the SDK.
The application team is saying that they also need the mkspecs,
and those are not included in the SDK.
Are the mkspecs supposed to be expo
> -Original Message-
> From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
> Sent: November 06, 2014 5:16 AM
>
> This is a slightly different symptom of the same underlying problem, yes.
>
I have filed a bug report in Yocto Bugzilla
https://bugzilla.yoctoproject.org/show_bug.cgi?i
> -Original Message-
> From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
> Sent: November 05, 2014 11:04 AM
>
> OK, so this kind of explains it. To be perfectly honest the bitbake memory
> resident functionality (which Toaster uses behind the scenes) does have
> some holes in pick
> -Original Message-
> From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
> Sent: November 05, 2014 11:04 AM
> >
> > I don't recall you asking this before, and I certainly never checked.
>
> Yeah, I should really have asked the above, instead I asked about what script
> you started
> -Original Message-
> From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
> >
> > Same result
>
> If by "same result" you mean you are still getting these errors, something
> very strange is going on.
Yes, that's what I mean. Yes, very strange.
>
> I know I kind of asked this be
> -Original Message-
> From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
> Sent: November 05, 2014 10:36 AM
>
> Rather than removing or renaming
> /home/platform/Workspace/somename/poky/build/tmp/cache/default-
> eglibc/sonic/i686, you should remove/rename the cache directory abov
> -Original Message-
> From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
> Sent: November 05, 2014 10:29 AM
>
> No, you really don't need to do a complete rebuild. This is a cache problem,
> if
> you have properly removed the cache the issue (at least the latest errors)
> will go
> -Original Message-
> From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
> Sent: November 05, 2014 10:23 AM
>
> OK, so perhaps this wasn't the best idea after all - I think what's happened
> there is that part of the cache is there and the other part now isn't. Instead
> of moving
> -Original Message-
> From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
> Sent: November 05, 2014 10:10 AM
>
> So it does appear to be cache related, but I just tried creating a similar
> packagegroup here and even set SDKMACHINE and could not reproduce the
> problem, adding the
> -Original Message-
> From: yocto-boun...@yoctoproject.org [mailto:yocto-
> boun...@yoctoproject.org] On Behalf Of Vuille, Martin (Martin)
> Sent: November 05, 2014 7:35 AM
> >
> > Indeed it appears that the .bb file is not being read.
> >
>
> But bi
> -Original Message-
> From: Vuille, Martin (Martin)
> Sent: November 05, 2014 5:53 AM
>
>
> I deliberately introduced syntax errors into the packagegroup .bb file
>
> bitbake does not report any error bitbake does
> not report any error
>
> Indeed it
> -Original Message-
> From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
> Sent: November 05, 2014 5:56 AM
> >
> > I deliberately introduced syntax errors into the packagegroup .bb file
>
> What kind of syntax error? Inside a function or outside?
>
This is my packagegroup .bb fi
> -Original Message-
> From: yocto-boun...@yoctoproject.org [mailto:yocto-
> boun...@yoctoproject.org] On Behalf Of Vuille, Martin (Martin)
> Sent: November 04, 2014 5:02 PM
>
> It's as though bitbake is not seeing my changes.
>
I deliberately introdu
I reported a similar issue a few days ago, but at the time I did not
know how to collect the relevant information to help diagnose the
issue. Hopefully I did better this time.
I have an image that lists several packagegroups in IMAGE_INSTALL.
I updated one of the packagegroups by adding a new pac
Hi Martin,
> -Original Message-
> From: Martin Jansa [mailto:martin.ja...@gmail.com]
> Sent: November 03, 2014 11:05 AM
>
> On Mon, Nov 03, 2014 at 03:09:43PM +, Vuille, Martin (Martin) wrote:
> > Hi Richard,
> >
> > > -Original Mes
Hi Richard,
> -Original Message-
> From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
> Sent: November 03, 2014 10:06 AM
>
> On Mon, 2014-11-03 at 12:53 +, Vuille, Martin (Martin) wrote:
> > I have a variable “REV_TOOLS” defined in distro/conf/s
> -Original Message-
> From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
> Sent: November 03, 2014 9:13 AM
>
> I honestly don't know how to explain this behaviour either, because it
> should not happen this way. BitBake automatically extracts variable
> references within variable
I have a package named "foo-Bar" built by a recipe "foo-Bar_1.0.0.bb".
Just noticed in Toaster that for that package it is reporting the package
name as "foo-" instead of "foo-Bar".
Is that a bug in Toaster or a restriction on package names?
MV
--
___
Hi Belén,
> -Original Message-
> From: Barros Pena, Belen [mailto:belen.barros.p...@intel.com]
> Sent: November 03, 2014 9:12 AM
>
> Hi Martin,
>
> You probably found this already, but just in case. The instructions to set up
> Toaster:
>
> https://wiki.yoctoproject.org/wiki/Toaster
>
Hi Paul,
> -Original Message-
> From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
> Sent: November 03, 2014 9:13 AM
>
> On Monday 03 November 2014 12:53:23 Vuille, Martin wrote:
> > Poky 1.6.1 / daisy
> >
> > I have a variable "REV_TOOLS" defined in distro/conf/somename.conf in
>
Hi Paul,
> -Original Message-
> From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
>
> Hi Martin,
>
> On Saturday 01 November 2014 15:57:34 Vuille, Martin wrote:
> > Yocto 1.6.1 / daisy
> >
> > I'm making the transition from denzil/1.2 to daisy.
> >
> > I have converted tasks fro
Poky 1.6.1 / daisy
I have a variable "REV_TOOLS" defined in distro/conf/somename.conf in a
custom distro layer from a git repo.
This variable is assigned to SRCREV in a number of recipes (SRCREV =
"${REV_TOOLS}")
for packages included in my images and SDKs.
Pulled an update to the distro layer
Yocto 1.6.1 / daisy
I'm making the transition from denzil/1.2 to daisy.
I have converted tasks from 1.2 to packagegroups.
Something is not working properly, and perhaps I am doing
something wrong, or perhaps my expectations are incorrect.
My image recipes refer to my package groups in IMAGE_INS
> -Original Message-
> From: yocto-boun...@yoctoproject.org [mailto:yocto-
> boun...@yoctoproject.org] On Behalf Of Bob Cochran
> Sent: November 01, 2014 9:08 AM
> To: yocto@yoctoproject.org
> Subject: Re: [yocto] How to debug dependency/setscene/sstate issues
>
> Won't Toaster give you th
I am using Poky daisy / Yocto 1.6.1
Occasionally, when building a custom image or SDK after changing
a package recipe or package content, I find that the do_rootfs task is not
executed for the image or the do_populate_sdk task is not executed
for the sdk.
There are custom classes, packages, packa
> From: kerg...@gmail.com [mailto:kerg...@gmail.com] On Behalf Of Christopher
> Larson
>
> - isn't a valid character in a shell function, so while potentially
> irritating, it's not surprising :)
Hmm, good point! Thanks
MV
--
___
yocto mailing list
y
I have custom classes that override a task thus (in foo.bbclass)
foo_do_something () {
...
}
EXPORT_FUNCTIONS do_something
but if I change the name to foo-bar.bbclass and change the class thus
foo-bar_do_something () {
...
After successfully building an image, the second and subsequent
attempts at building the image were failing with a python "OSError:
File exists" exception in do_rootfs.
Even bitbake -c clean did not fix the problem.
Eventually tracked it down to IMAGE_LINK_NAME having been
configured as "" (empt
> Trying to make the transition from denzil (1.2) to daisy (1.6.1) and have
> run into a problem that's got me stumped.
>
> There seems to have been a change in the way things are packaged that
> is breaking a number of my custom recipes.
>
> Let's say I have a package X that consists of source for
Trying to make the transition from denzil (1.2) to daisy (1.6.1) and have
run into a problem that's got me stumped.
There seems to have been a change in the way things are packaged that
is breaking a number of my custom recipes.
Let's say I have a package X that consists of source for an .so and
> -Original Message-
> From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
> Sent: October 24, 2014 4:35 AM
> To: Vuille, Martin (Martin)
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] QA Issue for recipe inheriting from native.bbclass
>
> On
> -Original Message-
> From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
> Sent: October 24, 2014 4:32 AM
> To: Vuille, Martin (Martin)
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] autotools-brokensep.bbclass not working
>
> > so seperat
(Using daisy/1.6.1)
I need to build an older version of dhcp because of some
custom functionality that was patched into the client.
That version of dhcp does not support ${B} != ${S}. So I
changed the recipe to inherit autotools-brokensep instead
of inheriting autotools.
But this has no effect.
I have a recipe that inherits from meta/classes/native.bbclass
I am getting an ERROR: QA Issue: for this recipe:
"Variable RPROVIDES is set as not being package specific, please fix this."
which, as far as I can tell, is due to the RPROVIDES assignment in
native.bbclass
Is this a bug? Is the r
We're planning an update to Dizzy, and to keep up-to-date after that.
Thanks for your help
MV
> -Original Message-
> From: Burton, Ross [mailto:ross.bur...@intel.com]
> Sent: September 26, 2014 5:55 PM
> To: Vuille, Martin (Martin)
> Cc: yocto@yoctoproject.org
&
We have run into the problem fixed by this patch
http://patchwork.openembedded.org/patch/77027/
Will this fix be included in 1.7/Dizzy?
MV
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Any ideas?
MV
> -Original Message-
> From: Burton, Ross [mailto:ross.bur...@intel.com]
> Sent: September 23, 2014 9:33 AM
> To: Vuille, Martin (Martin)
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] Forcing fetch task when source changes
>
> On 23 September
I was afraid of that...
Another good reason to upgrade.
Will try the work-around.
Thanks again!
MV
> -Original Message-
> From: Burton, Ross [mailto:ross.bur...@intel.com]
> Sent: September 23, 2014 9:33 AM
> To: Vuille, Martin (Martin)
> Cc: yocto@yoctoproject.or
ut doesn't address
my issue of having to manually force a fetch/unpack every
time the source changes.
Perhaps due to my old versions: Poky 1.2 and bitbake 1.15.1?
MV
> -Original Message-
> From: Burton, Ross [mailto:ross.bur...@intel.com]
> Sent: September 22, 2014 7:34
gt; Sent: September 22, 2014 7:34 AM
> To: Vuille, Martin (Martin)
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] Forcing fetch task when source changes
>
> On 22 September 2014 12:25, Vuille, Martin (Martin)
> wrote:
> > I have defined a class with a customized fetch t
I have defined a class with a customized fetch task (that
copies files from a local read-only directory to the ${S}
directory).
I am looking for a way to cause the fetch task to run
again whenever the contents of the local directory
change w.r.t. what was last fetched/copied to ${S}.
Is there a w
I have defined a class with a customized fetch task (that
copies files from a local directory to the ${S} directory).
I am looking for a way to cause the fetch task to run
whenever the contents of the local directory change
w.r.t. what was last fetched/copied to ${S}.
Seems to me that I could do
Exactly what I am looking for.
Thanks!
MV
> -Original Message-
> From: Khem Raj [mailto:raj.k...@gmail.com]
> Sent: May 05, 2014 12:34 PM
> To: Vuille, Martin (Martin)
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] Migrating LDAT fs_final.sh to Yocto
>
> On
Migrating from LDAT to Yocto, and wondering whether
there is an equivalent to LDAT's fs_final.sh script?
The objective is to do some post-processing on the
rootfs "tree" before it is packaged into the UBIFS image.
MV
--
___
yocto mailing list
yocto@yoc
> From: Bruce Ashfield
> Sent: April 24, 2014 4:06 PM
> To: Vuille, Martin (Martin); yocto@yoctoproject.org
> Subject: Re: [yocto] Exporting kernel header from patch
>
> On 14-04-24 03:54 PM, Vuille, Martin (Martin) wrote:
> >> From: Bruce Ashfield
> >>
> From: Bruce Ashfield
> Sent: April 24, 2014 2:01 PM
> To: Vuille, Martin (Martin); yocto@yoctoproject.org
> Subject: Re: [yocto] Exporting kernel header from patch
>
> On 14-04-24 01:52 PM, Vuille, Martin (Martin) wrote:
> >> From: Bruce Ashfield
> >> Sent:
> From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
> Sent: April 24, 2014 1:32 PM
>
> On 14-04-24 11:57 AM, Vuille, Martin (Martin) wrote:
> > I have a custom layer to add patches to my vendor's BSP layer
> >
> > (based on Linux 3.4, if it m
I have a custom layer to add patches to my vendor's BSP layer
(based on Linux 3.4, if it matters) and a .bbappend to list the
patches.
One of the patches adds a header, and this header needs to
be exported to the sysroot.
I added the following to my .bbappend, based on a discussion
I found:
do_i
86 matches
Mail list logo
