> -Original Message-
> From: akuster808
> Sent: den 22 december 2019 17:16
> To: Peter Kjellerstedt ; openembedded-
> c...@lists.openembedded.org
> Subject: Re: [OE-core] [master][zeus][PATCH] cairo: Adapt license for
> cairo-dbg and cairo-src based on contents
>
> On 12/22/19 5:00 AM,
It is not possible to whitelist packages, WHITELIST_ only takes recipe
names. This seems like a shortcoming, and doesn’t match INCOMPATIBLE_LICENSE,
which works with packages… I am not sure how to address that shortcoming
though, as it wouldn’t be right to allow mixing of recipes and packages
Update the Microblaze to v11.0
Signed-off-by: Manjukumar Matha
---
meta/conf/machine/include/microblaze/feature-microblaze-versions.inc | 2 ++
1 file changed, 2 insertions(+)
diff --git
a/meta/conf/machine/include/microblaze/feature-microblaze-versions.inc
Hi Richard,
On Wed, 2019-12-18 at 11:20 +0800, Anuj Mittal wrote:
> The following changes since commit
> 9c0c8e51dd345dd1b6ba240b027d24a18f55757c:
>
> YP 3.0.1 Docs: Fixed manual revision tables. (2019-12-16 23:32:39
> +)
>
> are available in the Git repository at:
>
>
* For some aging distros, such as CentOS 7, the native version
of gcc is simply too ancient and is a constant source of
headaches for moving forward.
* Add an extended version of buildtools-tarball which adds all
of build-essential, so that the host is now modernized and
capable of
* For buildtools-extended-tarball, where we are adding all of build-essentials
to the nativesdk, we need additional perl modules for autoconf and automake.
Signed-off-by: Tim Orling
---
meta/recipes-core/meta/nativesdk-buildtools-perl-dummy.bb | 3 +++
1 file changed, 3 insertions(+)
diff
As certain distros--such as CentOS7--age, we are increasingly fighting
for instance the ancient version of gcc on the host. As we look forward to
a plan to create an LTS release, we need to have a mechanism to continue
to build components 2+ years into the future. While this can be done with
On Sun, 2019-12-22 at 10:22 -0600, Joshua Watt wrote:
> On Sun, Dec 22, 2019, 10:17 AM Joshua Watt
> wrote:
> >
> > On Sun, Dec 22, 2019, 10:09 AM Richard Purdie <
> > richard.pur...@linuxfoundation.org> wrote:
> > > On Sun, 2019-12-22 at 10:00 -0600, Joshua Watt wrote:
> > > It won't help the
On Sun, Dec 22, 2019 at 12:04 PM Bruce Ashfield
wrote:
>
> On Sat, Dec 21, 2019 at 11:06 PM Khem Raj wrote:
> >
> > Signed-off-by: Khem Raj
> > Cc: Bruce Ashfield
>
> Thanks Khem!
>
> As usual, please don't merge this patch directly, I'll apply it for
> linux-yocto* and linux-yocto-dev so we
On Sat, Dec 21, 2019 at 11:06 PM Khem Raj wrote:
>
> Signed-off-by: Khem Raj
> Cc: Bruce Ashfield
Thanks Khem!
As usual, please don't merge this patch directly, I'll apply it for
linux-yocto* and linux-yocto-dev so we have full coverage on the
reference kernels.
I can send SRCREV bumps
On Sun, Dec 22, 2019, 10:17 AM Joshua Watt wrote:
>
>
> On Sun, Dec 22, 2019, 10:09 AM Richard Purdie <
> richard.pur...@linuxfoundation.org> wrote:
>
>> On Sun, 2019-12-22 at 10:00 -0600, Joshua Watt wrote:
>> > On Sun, Dec 22, 2019, 6:49 AM Richard Purdie <
>> >
On Sun, Dec 22, 2019, 10:09 AM Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:
> On Sun, 2019-12-22 at 10:00 -0600, Joshua Watt wrote:
> > On Sun, Dec 22, 2019, 6:49 AM Richard Purdie <
> > richard.pur...@linuxfoundation.org> wrote:
> > > On Sun, 2019-12-22 at 12:08 +, Richard
On 12/22/19 5:00 AM, Peter Kjellerstedt wrote:
> *ping*
for master or zeus or both?
- armin
>
> //Peter
>
>> -Original Message-
>> From: openembedded-core-boun...@lists.openembedded.org > boun...@lists.openembedded.org> On Behalf Of Peter Kjellerstedt
>> Sent: den 5 december 2019 23:26
On Sun, 2019-12-22 at 10:00 -0600, Joshua Watt wrote:
> On Sun, Dec 22, 2019, 6:49 AM Richard Purdie <
> richard.pur...@linuxfoundation.org> wrote:
> > On Sun, 2019-12-22 at 12:08 +, Richard Purdie wrote:
> >
> > At query time in a clean build, the hashserver cannot know which of
> > the two
On Sun, Dec 22, 2019, 6:49 AM Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:
> On Sun, 2019-12-22 at 12:08 +, Richard Purdie wrote:
> > On Sun, 2019-12-22 at 10:54 +, Richard Purdie wrote:
> > > I did a little digging on the weird hash equiv failure. I've
> > > attached two
-dbg and -src packages are unlikely to be shipped to customers. How about
either whitelisting them globally, or setting INCOMPABIBLE_LICENSE per
image?
What the patch does with LICENSE-dbg/src feels hack-ish to be honest; also
there are other recipes with a similar layout which would also need
*ping*
//Peter
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org boun...@lists.openembedded.org> On Behalf Of Peter Kjellerstedt
> Sent: den 11 december 2019 02:06
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [master][zeus][PATCH]
*ping*
//Peter
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org boun...@lists.openembedded.org> On Behalf Of Peter Kjellerstedt
> Sent: den 5 december 2019 23:26
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [master][zeus][PATCH] cairo:
On Sun, 2019-12-22 at 12:08 +, Richard Purdie wrote:
> On Sun, 2019-12-22 at 10:54 +, Richard Purdie wrote:
> > I did a little digging on the weird hash equiv failure. I've
> > attached two logs, one is the simplified console output, the other
> > is the reams of debug.
I did a bit more
On Sun, 2019-12-22 at 10:54 +, Richard Purdie wrote:
> I did a little digging on the weird hash equiv failure. I've attached
> two logs, one is the simplified console output, the other is the
> reams of debug.
I dumped out what I think is the relevant bits of the database (which
is nearly
Hi Joshua,
I did a little digging on the weird hash equiv failure. I've attached
two logs, one is the simplified console output, the other is the reams
of debug.
What is really odd is this is totally reproducible. If I clean out tmp
and cache from the build, then "bitbake nspr-native", it
I am not sure what is intended by the code:
d.getVar('TARGET_OS', d, 1) == ('' or 'custom')
This is equivalent to:
d.getVar('TARGET_OS', d, 1) == 'custom'
If the intended behavior is to take the second element of the array
when TARGET_OS is empty or 'custom', the correct code would be:
22 matches
Mail list logo
