I see a bbclass for this, but no IMAGE_FEATURE to get the resultant packages
into an image. Is there, or should there, be one? I also see reference to
various similar packages, like *-dbg in an sdk bbclass, but have not found how
any of this stuff actually gets put into a target image. Any po
-Original Message-
From: Richard Purdie
Sent: Thursday, July 25, 2019 2:45 PM
To: Slater, Joseph ;
openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [oe-core][PATCH 1/1] oeqa: small modification to
oe_syslog
On Thu, 2019-07-25 at 13:30 -0700, Joe Slater wrote:
> Skip logger
That's a question I have about things like this, where some information seems
of minimal use, but is there and is now malignant. Chuck it or modify it to be
benign.
Joe
-Original Message-
From: Burton, Ross
Sent: Thursday, July 11, 2019 2:56 PM
To: Adrian Bunk
Cc: Slater, J
behalf of Slater, Joseph
[joe.sla...@windriver.com]
Sent: Wednesday, June 19, 2019 2:56 PM
To: Richard Purdie; openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [oe-core][PATCH 1/1] parted: change device manager check
in ptest
I will send a patch upstream. Joe
I will send a patch upstream. Joe
From: Richard Purdie [richard.pur...@linuxfoundation.org]
Sent: Wednesday, June 19, 2019 2:39 PM
To: Slater, Joseph; openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [oe-core][PATCH 1/1] parted: change
Although the exact issues have changed over releases, I think that sysstat has
dependencies on host /etc files or directories when using sysvinit instead of
systemd. Since any "fixes" would potentially change target behavior, what are
we looking for?
Joe
--
__
gdk-pixbuf is fast? Not for me. Some of its tests take about 2000 seconds on
qemux86-64 on a 32 core machine with 64GB ram.
Joe
From: openembedded-core-boun...@lists.openembedded.org
[openembedded-core-boun...@lists.openembedded.org] on behalf of akuste
I think it might. This is distro related, I think. Should distro's be fooling
with things like CXXFLAGS, and if so, how?
From: Andre McCurdy [armccu...@gmail.com]
Sent: Monday, August 06, 2018 5:33 PM
To: Slater, Joseph
Cc: openembedded
This class clobbers a number of things that might be manipulated in a recipe.
If, say, I want to add something to CXXFLAGS, what/where do I put it? It looks
like "_append" works, but "+=" might not.
Joe
--
___
Openembedded-core mailing list
Openemb
aclocal can generate rather large command lines (194000 characters) when
calling autom4te to trace macros. I think that this breaks at a little beyond
the argument length I've mentioned. I'm not familiar with this code but I
think the bulk of the items could be piped into autom4te rather than
Should this be resubmitted? I could always remove the comment about 4.0.8.
Joe
From: Slater, Joseph
Sent: Tuesday, July 10, 2018 4:56 PM
To: akuster808; openembedded-core@lists.openembedded.org
Subject: RE: [OE-core] [oe-core][PATCH 1/1] tiff: security
10, 2018 4:48 PM
To: Slater, Joseph; openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [oe-core][PATCH 1/1] tiff: security fix CVE-2018-10963
On 07/10/2018 04:03 PM, Joe Slater wrote:
> Denial of service described at
> https://nvd.nist.gov/vuln/detail/CVE-2018-10963.
>
Actually, it is a screw-up trying to deal with something that was already
fixed. At least it never gets executed.
Joe
From: Alexander Kanavin [alex.kana...@gmail.com]
Sent: Tuesday, June 26, 2018 12:19 PM
To: Slater, Joseph
Cc: OE-core
Subject: Re: [OE
:10 AM
To: Slater, Joseph
Cc: OE-core
Subject: Re: [OE-core] [oe-core][PATCH 1/1] gnome-desktop: do not free() a
static buffer
I'm not sure we need this patch anymore, it's been rebased on top of upstream
changes but one of those changes were to fix x32 builds:
https://git.gnome.org/br
:10 AM
To: Slater, Joseph
Cc: OE-core
Subject: Re: [OE-core] [oe-core][PATCH 1/1] gnome-desktop: do not free() a
static buffer
I'm not sure we need this patch anymore, it's been rebased on top of upstream
changes but one of those changes were to fix x32 builds:
https://git.gnome.org/br
Neglecting buildhistory, there is only one recipe, I think, that uses
SSTATEPOSTINSTFUNCS -- php-native, and that does not work. Since there is
nothing to compare to, I do not know if sysconfdir is set incorrectly, or if
the function is supposed to realize it is under sysroot-destdir and adjust
:58 PM
To: Slater, Joseph; Alexander Kanavin;
openembedded-core@lists.openembedded.org; BURTON, ROSS
Subject: Re: [OE-core] [oe-core][PATCH 1/1] allarch: do not set baselib
On Wed, 2018-01-03 at 21:46 +, Slater, Joseph wrote:
> Currently, we do have to provide qemuwrapper with
> LD_LIBRAR
ed by allarch.
Maybe qemuwrapper should be smart enough to compute LD_LIBRARY_PATH...
Joe
-Original Message-
From: Alexander Kanavin [mailto:alexander.kana...@linux.intel.com]
Sent: Wednesday, January 03, 2018 12:43 AM
To: Richard Purdie; Slater, Joseph; openembedded-core@lists.openembedde
I tried the patch to the allarch class and the problem does away.Joe
From: Alexander Kanavin [alexander.kana...@linux.intel.com]
Sent: Friday, December 22, 2017 12:34 AM
To: Slater, Joseph; Richard Purdie; openembedded-core@lists.openembedded.org
@linuxfoundation.org]
Sent: Thursday, December 21, 2017 2:28 PM
To: Slater, Joseph; openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [oe-core][PATCH 1/1] liberation-fonts: do not inherit
allarch
On Thu, 2017-12-21 at 13:23 -0800, Joe Slater wrote:
> The fontcache class performs
l backfill processing can be
eliminated and regular constructs used I think that would be desirable.
Joe
From: Andre McCurdy [armccu...@gmail.com]
Sent: Monday, November 20, 2017 7:24 PM
To: Slater, Joseph
Cc: openembedded-core@lists.openembedded.org
Subject: Re
The backfill mechanism is not compatible with multilib. This could possibly be
fixed, but the backfill_considered functionality is also obscure, so I think in
at least the machine related .inc files we should replace lines like
MACHINE_FEATURES_BACKFILL_CONSIDERED_append = "
${@bb.utils.contai
, 2017 11:39 AM
To: Slater, Joseph
Cc: Patches and discussions about the oe-core layer
Subject: Re: [OE-core] [oe-core][PATCH 1/1] nss: pay attention to CFLAGS
On Wed, Nov 15, 2017 at 10:54 AM, Joe Slater wrote:
> nss ignores CFLAGS so we suggest them via CC.
is that a limitation or intentional
ilib.
Joe
From: Alexander Kanavin [alexander.kana...@linux.intel.com]
Sent: Friday, October 27, 2017 2:13 AM
To: Slater, Joseph; Andre McCurdy
Cc: OE Core mailing list
Subject: Re: [OE-core] [oe-core][PATCH 1/1] qemumips64: no qemu-usermode for n32
On 10/26/2017 11:51 PM, Slater, Joseph
using overrides. In any
case, I do not believe any of the CONSIDERED definitions work.
Joe
-Original Message-
From: Andre McCurdy [mailto:armccu...@gmail.com]
Sent: Thursday, October 26, 2017 11:09 AM
To: Slater, Joseph
Cc: Alexander Kanavin; OE Core mailing list
Subject: Re: [OE-core] [oe
pposed to expand the variable? Put print msg's in
meta/lib/oe/utils.py to see this behavior.
Joe
________
From: Slater, Joseph
Sent: Wednesday, October 25, 2017 11:24 AM
To: Andre McCurdy; Alexander Kanavin
Cc: OE Core mailing list
Subject: RE: [OE-core] [oe-core][
I found that libn32-gobject-introspection would not compile without the remove,
but I could check again. Joe
-Original Message-
From: Andre McCurdy [mailto:armccu...@gmail.com]
Sent: Wednesday, October 25, 2017 10:19 AM
To: Alexander Kanavin
Cc: Slater, Joseph; OE Core mailing list
I think it would be nicer if recipes that currently require network access to
check repo version info warned, but did not fail to parse. I actually think
that allowing AUTOREV at all should be conditional, because it subverts
reproducible builds. I'd also guess that if tags change that is not
This is the default tune for qemumips. It appears that the problem does not
occur for an oe-core checkout just before the split creating go-runtime.
Before the split, go-helloworld will build, but after the split it will not
because it needs go-runtime.
Joe
--
A while ago I sent a patch to change the way the kernel module tools get built
such that they would be built once, not each time a recipe that inherits
module.bbclass runs. The current way is wasteful and allows module recipes to
interfere with each other.
I can send the patch again, but I wou
Is there something "different" about this branch? I find that if I have a
local master and master-next, and am on master, when I do a pull master-next
will wind up both ahead and behind origin/master-next. If I switch to
master-next and rebase, it might fail, or it might leave me with one or m
I’ll look at the CVEs. LICENSE updated from 2016 to 2017. Text is the same.
Joe
From: Martin Jansa [mailto:martin.ja...@gmail.com]
Sent: Tuesday, August 08, 2017 1:31 PM
To: Leonardo Sandoval
Cc: Slater, Joseph; Patches and discussions about the oe-core layer
Subject: Re: [OE-core] [oe-core
This will break application of a patch submitted a little later yesterday which
moves the make_scripts task.
Joe
From: openembedded-core-boun...@lists.openembedded.org
[openembedded-core-boun...@lists.openembedded.org] on behalf of California
Sullivan [c
]
Sent: Friday, July 21, 2017 10:30 AM
To: Slater, Joseph
Cc: Patches and discussions about the oe-core layer
Subject: Re: [OE-core] [oe-core][PATCH 1/1] modules: move creation of some
module related tools
On Fri, Jul 21, 2017 at 1:13 PM, Joe Slater
mailto:jsla...@windriver.com>> wrote
A couple of patches have been submitted moving ghostscript from 9.20 to 9.21.
Should I submit a new one fixing the CUPSCONFIG issue, or is the one from Fan
Xin being considered instead?
Joe
From: Slater, Joseph
Sent: Thursday, May 25, 2017 2:54 PM
To: Slater, Joseph; BURTON, ROSS
Cc: OE-core
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of Slater,
Joseph
Sent: Thursday, May 25, 2017 12:44 PM
To: BURTON, ROSS
Cc: OE-core
Subject: Re: [OE-core] [oe-core][PATCH 1/1] ghostscript: move to version 9.21
I don’t know if it’s intentional, but it does seem to be a
the new log, CUPSCONFIG is
null.
Joe
From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Thursday, May 25, 2017 5:50 AM
To: Slater, Joseph
Cc: OE-core
Subject: Re: [OE-core] [oe-core][PATCH 1/1] ghostscript: move to version 9.21
On 24 May 2017 at 18:39, Joe Slater
mailto:jsla
> -Original Message-
> From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
> Sent: Thursday, March 16, 2017 3:14 PM
> To: Slater, Joseph; openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [oe-core][v2][PATCH 1/1] build-compare: add date to
To: openembedded-core@lists.openembedded.org
> Cc: Slater, Joseph
> Subject: [oe-core][v2][PATCH 1/1] build-compare: add date to PV
>
> We want PV values to be easily ordered, so
> use the latest entry in build-compare.changes which
> will also match the date of SRC
I believe that SRCPV for a git SRC_URI always contains the string AUTOINC.
This could be considered
wrong, or just misleading, since SRCREV can be set to a sha. I think I might
have brought this up
in the past, but I cannot remember if there is some reason to retain the
AUTOINC unconditionally
Hm, I see this whole thing is being re-written. Maybe that will fix it.
Joe
From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Tuesday, December 06, 2016 1:52 AM
To: Slater, Joseph
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] oetest.py construction of
This variable is a dictionary with entries based on package, but for multillib
a package might exist in only some variants. Perhaps
each entry should be a dictionary of multilib variants?
Joe
--
___
Openembedded-core mailing list
Openembedded-core@lis
> -Original Message-
> From: Andre McCurdy [mailto:armccu...@gmail.com]
> Sent: Tuesday, September 06, 2016 1:52 PM
> To: Slater, Joseph
> Cc: OE Core mailing list
> Subject: Re: [OE-core] [oe-core][PATCH 1/1] libwebp: do not assume armv7a has
> neon
> intri
t: Monday, August 22, 2016 7:21 AM
> To: openembedded-core@lists.openembedded.org; Slater, Joseph
> Cc: openembedded-comm...@lists.openembedded.org
> Subject: Re: [oe-commits] [openembedded-core] 01/02: systemd-compat-units:
> pkg_postinst()
> does not work
>
> On Thu, Aug 1
I'm seeing strange behavior in terminal.py since the use of
oe-gnome-terminal-phonehome was added. If the script is on
my "base" path before starting a bitbake shell, everything is fine. If it is
under oe-core/scripts, terminal.py does not find it. If I manually search PATH
in terminal.py, I
This might or might not be a bug, but it does lead to unpleasant behavior if
two recipes create the same user. They probably should not, but who's stopping
them?
I realize they are not in oe-core, but proftpd and vsftpd are an example of
this. We have seen failures when building world because
es do not fail, you are not building what you
think
you are.
Joe
> -Original Message-
> From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
> Sent: Wednesday, June 22, 2016 7:30 PM
> To: openembedded-core@lists.openembedded.org
> Cc: Hatle, Mark; Slater, Joseph; Kh
> -Original Message-
> From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
> Sent: Wednesday, June 22, 2016 7:30 PM
> To: openembedded-core@lists.openembedded.org
> Cc: Hatle, Mark; Slater, Joseph; Khem Raj
> Subject: Re: [OE-core] [oe-core][PATCH 0/1] blacklist
This variable is used by librsvg_2.40.10.bb, but I can't find anybody who
processes it, at least not a bbclass.
Without adding an explicit do_populate_sysroot_setscene[depends] to the recipe,
gdk-pixbuf-native
will install from sstate after librsvg-native and clobber the svg loader. At
least i
That's fine with me. I'll rename the package and eliminate the comment. Joe
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-
> boun...@lists.openembedded.org] On Behalf Of Andreas Oberritter
> Sent: Tuesday, September 08, 2015 1
> -Original Message-
> From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
> Sent: Friday, September 04, 2015 10:33 PM
> To: Slater, Joseph
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [oe-core][PATCH 1/1] busybox: more nails in
out the oe-core layer; Slater, Joseph; Otavio
> Salvador
> Subject: Re: [OE-core] [oe-core][PATCH 1/2] ifupdown: import recipe
>
> On Thu, 2015-09-03 at 14:15 -0700, Khem Raj wrote:
> > > On Sep 3, 2015, at 1:27 PM, Richard Purdie
> > > wrote:
> > >
> >
I believe that if we specify "NO_GENERIC_LICENSE[X]" in a recipe that unless we
name the license file "generic_X", we will see a
QA warning when the fs is put together.
Perhaps we could take care of this by having the code which copies the special
license also create a link to it named "generic_
ok. I think I just sent a new version of the patch (but for some reason I did
not get a copy). Joe
From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Tuesday, July 28, 2015 12:46 PM
To: Slater, Joseph
Cc: OE-core
Subject: Re: [OE-core] [oe-core][PATCH 1/1] nss: advance to version
> -Original Message-
> From: Khem Raj [mailto:raj.k...@gmail.com]
> Sent: Wednesday, March 18, 2015 4:37 PM
> To: Slater, Joseph
> Cc: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [oe-core][PATCH 1/1] ltp: find all .debug directories
>
&
rnhard Reutner-Fischer
> Cc: Slater, Joseph; openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [oe-core][PATCH 1/1] package.bbclass: decouple
> splitting and
> stripping
>
> On Fri, 2015-03-13 at 23:50 +0100, Bernhard Reutner-Fischer wrote:
> > On March 13,
-D_FORTIFY_SOURCE=2 is usually set in SECURITY_CFLAGS which will cause lots of
warnings, and possibly failures, if DEBUG_BUILD=1.
Since there are already lots of package overrides for SECURITY_CFLAGS, we could
just add more for packages that won't build under
these conditions, or
we could not i
It appears that cross-localedef-native should have the above variable set, and
it does not. I don't know why this does not normally cause a problem, but if
get_srcrev() in fetcher2 code is run in an event handler, it fails for this
recipe. I cannot find any recipe that sets this variable, so I
It is not runtime tested. The intent is to allow world builds for aarch64.
Joe
> -Original Message-
> From: Khem Raj [mailto:raj.k...@gmail.com]
> Sent: Monday, September 15, 2014 11:10 PM
> To: Slater, Joseph
> Cc: Patches and discussions about the oe-core layer
>
> -Original Message-
> From: Burton, Ross [mailto:ross.bur...@intel.com]
> Sent: Sunday, September 14, 2014 1:44 PM
> To: Slater, Joseph
> Cc: OE-core
> Subject: Re: [OE-core] [oe-core][PATCH 1/1] sysprof: add aarch64 support
>
> On 12 September 2014 22:03, Joe
Is there some way to specify incompatible licenses for native recipes? An
alternate mechanism might work,
but here is a case in which it would be valuable:
If I do not allow AGPL licenses, rpm builds with db-5. rpm-native builds with
db-6. When you try
to run rpm on the target it gets very up
uxfoundation.org]
> Sent: Tuesday, April 08, 2014 2:34 PM
> To: Slater, Joseph
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] libxslt populate_sysroot dependencies
>
> On Tue, 2014-04-08 at 21:21 +, Slater, Joseph wrote:
> >
>
> -Original Message-
> From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
> Sent: Tuesday, April 08, 2014 9:58 AM
> To: Slater, Joseph
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] libxslt populate_sysroot dependencies
>
>
I have attached a patch that makes sure libxml2-native is available when both
it and libxslt-native
are taken from sstate.
The patch parallels one from a few weeks ago for pixbufcache, but the
underlying problem might
have been fixed since then. I looked for likely commits, and didn't see
anyt
> -Original Message-
> From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
> Sent: Tuesday, November 12, 2013 11:45 AM
> To: Slater, Joseph
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH 1/1] linuxdoc-tools: add dependency
At least, that looks like what happened for the
build failure this patch attempts to fix.
Joe
> -Original Message-
> From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
> Sent: Tuesday, November 12, 2013 2:47 AM
> To: Slater, Joseph
> Cc: openembedded-core@l
AM
To: openembedded-core@lists.openembedded.org
Cc: MacLeod, Randy; Slater, Joseph
Subject: [v2][PATCH 1/1] vala.bbclass: add dependency on vala
This class points the inheritor, if it is a target,
to directories in the target sysroot, so we want to
be sure the .vapi files are there.
Signed-off-by
> -Original Message-
> From: Burton, Ross [mailto:ross.bur...@intel.com]
> Sent: Tuesday, September 17, 2013 3:53 AM
> To: Martin Jansa
> Cc: Khem Raj; Slater, Joseph; Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 1/1] webkit-gt
From: Joe Slater [mailto:jsla...@windriver.com]
Sent: Monday, September 23, 2013 1:53 PM
To: MacLeod, Randy; Polk, Jeffrey
Cc: lpd-eng-rr
Subject: [PATCH 1/1] vala.bbclass: add dependency on vala
This class points the inheritor to directories in
the target sysroot, so we want to be sure things
li
Hi,
Several packages in oe-core have PACKAGECONFIG[] info, or the equivalent,
concerning
explicitly disabling audit support.
Some people believe that PACKAGECONFIG[] data concerning features not in oe-core
should not be in oe-core. I do think it should be there unless the package
requires spec
> -Original Message-
> From: Saul Wold [mailto:s...@linux.intel.com]
> Sent: Tuesday, August 13, 2013 2:48 PM
> To: Slater, Joseph
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH 1/1] coreutils: allow for acl support
>
> On 08/13/2
> -Original Message-
> From: Yi Qingliang [mailto:niqingliang2...@gmail.com]
> Sent: Thursday, May 16, 2013 5:46 PM
> To: Slater, Joseph
> Cc: openembedded-core@lists.openembedded.org oe-core layer
> Subject: Re: [OE-core] qt keyboard problem
>
> On Thursday,
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-
> boun...@lists.openembedded.org] On Behalf Of Yi Qingliang
> Sent: Tuesday, May 14, 2013 11:19 PM
> To: openembedded-core@lists.openembedded.org oe-core layer
> Subject: [OE-core]
> -Original Message-
> From: Phil Blundell [mailto:p...@pbcl.net]
> Sent: Wednesday, May 15, 2013 1:45 PM
> To: Slater, Joseph
> Cc: Hatle, Mark; openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH 1/1] zlib: put shared libraries in base_libdir
&g
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-
> boun...@lists.openembedded.org] On Behalf Of Mark Hatle
> Sent: Wednesday, May 15, 2013 6:08 AM
> To: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH 1/1]
Hi,
I see this class for generating a report of package data, but I don't see it
ever
being used. Is there info about how to use it?
Joe
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/ma
> -Original Message-
> From: Saul Wold [mailto:s...@linux.intel.com]
> Sent: Friday, May 10, 2013 3:00 PM
> To: Burton, Ross; Slater, Joseph
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH 1/1] sysvinit: modify bootlog location
>
>
> -Original Message-
> From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
> Sent: Thursday, March 28, 2013 3:40 PM
> To: Bruce Ashfield
> Cc: Slater, Joseph; openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] QEMU_UI_OPTIONS
>
> On
I notice that, by default, we pretend we have a touchscreen instead of a
mouse (-usbdevice wacom-tablet option) for the qemu bsp's. Is there
some reason for this?
I have experimented some and, with other adjustments, have found
it possible to not specify it, but I do admit interaction with the t
> -Original Message-
> From: kerg...@gmail.com [mailto:kerg...@gmail.com] On Behalf Of Chris Larson
> Sent: Monday, March 25, 2013 2:16 PM
> To: Slater, Joseph
> Cc: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 1/1] dosfstools: really
> -Original Message-
> From: otavio.salva...@gmail.com [mailto:otavio.salva...@gmail.com] On Behalf
> Of Otavio
> Salvador
> Sent: Monday, March 18, 2013 2:06 PM
> To: Slater, Joseph
> Cc: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core]
easier to just override it.
I am using the acpid recipe from openembedded-core master branch.
Joe
From: Saul Wold [s...@linux.intel.com]
Sent: Thursday, February 14, 2013 12:24 PM
To: Slater, Joseph
Cc: openembedded-core@lists.openembedded.org
Subject: Re
> -Original Message-
> From: Richard Purdie [mailto:richard.pur...@linuxfoundation.org]
> Sent: Wednesday, September 26, 2012 1:48 AM
> To: Slater, Joseph
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH] cmake.bbclass: modify constr
I don't know your issue, but the attached recipe should work. You could
try it and then starting ripping things out.
Joe
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-
> boun...@lists.openembedded.org] On Behalf Of Elvis Dowso
To change the installation for popt but not popt-native, I said
do_install_append_pn-popt {
...
}
which seems to work, but is there a better way, like some
${@building_for_host("yes text","no text",d)}
construct?
Joe
___
Openembedded-core mailing l
It looks like opkg already uses --disable-gpg, so opkg-nogpg builds the same
and the packaging conflicts with opkg, so perhaps it could be eliminated?
Joe
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.linuxtogo
Subject: Re: [OE-core] EXCLUDE_FROM_WORLD
>
> On Thu, 2012-07-26 at 18:45 +, Slater, Joseph wrote:
> > Could somebody clarify excluding things from world? I see
> > EXCLUDE_FROM_WORLD = "1" in
> >
> > many places, including libx11.inc, and I'm s
Hi all,
Could somebody clarify excluding things from world? I see EXCLUDE_FROM_WORLD =
"1" in
many places, including libx11.inc, and I'm sure there's plenty of libx11 stuff
in world.
I also see package specific exclusions in world-broken.inc.
If one wants to exclude items for a particular bsp
Subject: Re: [OE-core] modifying inittab (for example)
>
> On Wed, Jul 18, 2012 at 11:29:43PM +, Slater, Joseph wrote:
> > Suppose we want to boot to different runlevels for different images. We
> > could modify
> the default inittab
> > to reflect that. We could
Suppose we want to boot to different runlevels for different images. We could
modify the default inittab
to reflect that. We could modify it in various ways, but I don't think the
exact mechanism much matters.
What is an interesting question is WHEN we modify it.
One way would be to have a s
90 matches
Mail list logo
