On Fri, Jul 11, 2014 at 4:41 PM, Otavio Salvador
wrote:
> Hello,
>
> +OE-Core
>
> On Fri, Jul 11, 2014 at 7:23 PM, Robert P. J. Day
> wrote:
>>
>> Reformat the assignment to CORE_IMAGE_BASE_INSTALL to be more
>> intuitively obvious.
>>
>> Signed-off-by: Robert P. J. Day
>>
>> ---
>>
>> compil
From: "Peter A. Bigot"
The original patch removed gcrypt from an m4 source file that
contributes to configure.in, but didn't apply those changes to or
rebuild the configure script itself. This allowed libgcrypt-config to
be found, adding native libraries to the target build.
Signed-off-by: Pete
Hello,
+OE-Core
On Fri, Jul 11, 2014 at 7:23 PM, Robert P. J. Day wrote:
>
> Reformat the assignment to CORE_IMAGE_BASE_INSTALL to be more
> intuitively obvious.
>
> Signed-off-by: Robert P. J. Day
>
> ---
>
> compile and run-time tested, building a core-image-minimal for
> qemuarm.
>
> diff
On Thu, Jul 10, 2014 at 12:21 PM, Robert P. J. Day
wrote:
>
> a number of the current packagegroup recipe files still have
> backward compatibility support for the old "task-core" names, seems
> like that's been there for well over a year, would it be safe to
> finally just toss that? seems like
On Fri, 11 Jul 2014 22:32:49 +0100
Richard Purdie wrote:
> The issue is the lack of the xattr headers from what I saw, not the
> xattr support itself and we're missing what looks like a single define.
> For the complexity, I did wonder if we should ship a default...
Hmm. We could in theory add a
On Fri, 2014-07-11 at 15:24 -0500, Peter Seebach wrote:
> On Fri, 11 Jul 2014 21:21:06 +0100
> "Burton, Ross" wrote:
>
> > The extended attributes code means adding build-dependency on attr.
> >
> > Which leads onto the discussion as to whether we add attr-native to
> > the build for pseudo-nati
On Fri, 2014-07-11 at 20:37 +0100, Burton, Ross wrote:
> On 11 July 2014 14:22, Richard Purdie
> wrote:
> > The anonymous python fragment should be fine, it sets the data at the
> > right level, the global recipe level rather than burying it in some
> > task.
>
> FWIW this broke the X drivers as
On Fri, 11 Jul 2014 21:21:06 +0100
"Burton, Ross" wrote:
> The extended attributes code means adding build-dependency on attr.
>
> Which leads onto the discussion as to whether we add attr-native to
> the build for pseudo-native, or use ASSUME_PROVIDED and document that
> the host needs to provi
On 11 July 2014 21:22, Peter Seebach wrote:
> This uprevs pseudo to 1.6. This merges in all of the existing
> fixes, and also adds partial support for extended attributes,
> including storing arbitrary extended attributes in the database,
> and also interpreting the posix permissions ACLs as chmod
This uprevs pseudo to 1.6. This merges in all of the existing
fixes, and also adds partial support for extended attributes,
including storing arbitrary extended attributes in the database,
and also interpreting the posix permissions ACLs as chmod
requests.
---
meta/recipes-devtools/pseudo/pseudo.i
pseudo 1.6.0 is a moderately significant update. It should actually
be better in a number of ways. Performance may be slightly improved
by changes to how debugging messages are generated. Debugging output
is dramatically improved. Extended attributes are supported.
I don't really feel this can be
On Fri, Jul 11, 2014 at 4:37 PM, Burton, Ross wrote:
> On 11 July 2014 14:22, Richard Purdie
> wrote:
>> The anonymous python fragment should be fine, it sets the data at the
>> right level, the global recipe level rather than burying it in some
>> task.
>
> FWIW this broke the X drivers as they
On 11 July 2014 14:22, Richard Purdie
wrote:
> The anonymous python fragment should be fine, it sets the data at the
> right level, the global recipe level rather than burying it in some
> task.
FWIW this broke the X drivers as they inject dependencies in
populate_packages_prepend(). It's probab
On Fri, 2014-07-11 at 13:46 -0300, Otavio Salvador wrote:
> On Fri, Jul 11, 2014 at 10:22 AM, Richard Purdie
> wrote:
> > On Fri, 2014-07-11 at 09:14 -0300, Otavio Salvador wrote:
> ...
> >> > I would not recommend setting variables in function prepends like this,
> >> > its ugly and error prone,
On Fri, Jul 11, 2014 at 10:22 AM, Richard Purdie
wrote:
> On Fri, 2014-07-11 at 09:14 -0300, Otavio Salvador wrote:
...
>> > I would not recommend setting variables in function prepends like this,
>> > its ugly and error prone, as you've just found out.
>>
>> Any suggested better way of to do it?
pm/rpm_5.4.14.bb,
do_compile) failed with exit code '1'
My configuration is:
BB_VERSION= "1.23.1"
BUILD_SYS = "i686-linux"
NATIVELSBSTRING = "Fedora-13"
TARGET_SYS= "arm-amltd-linux-gnueabi"
MACHINE = "imx53qs
A previously upstreamed patch has been applied. Bump the version to
incorporate this upstream update.
Signed-off-by: Trevor Woerner
---
.../grub/grub/asciih-fix-build-warning-error.patch | 34 --
meta/recipes-bsp/grub/grub_git.bb | 3 +-
2 files changed, 1 i
Sorry for the mess...
At least consider it as my way to tell that I think the iniscripts options
should be reviewed.
>From what I see in /etc/init.d/rc, the script will not be started at runlevels
0 6 due to lines 146-161 :
if [ $previous != N ] && [ $previous != S ]
then
Adding the possibility to skip the download phase completely.
This is useful for repeating runs with the same image types and similar
configurations.
Signed-off-by: Corneliu Stoicescu
---
scripts/test-remote-image | 27 ---
1 file changed, 16 insertions(+), 11 deletions(
From 963a99512475b6bc402d2339fa4e4765960e4c26 Mon Sep 17 00:00:00 2001
From: Diego
Date: Fri, 11 Jul 2014 14:30:56 +0200
Subject: [PATCH] Try to make urandom more random using the proper seed.
If we follow the syntax here we think that previously, at shutdown, the seed
file was created after ura
On Fri, 2014-07-11 at 09:14 -0300, Otavio Salvador wrote:
> >> When I see a RFC serie I expect people to wait some days /for
> >> comments/. I learned today those are already merged and /no comment
> >> time/ has been given.
> >
> > The whole RFC was not merged. The previous RFC was and when that
>
Hi Matthieu,
I used a different approach, but could't test with master yet.
http://git.openembedded.org/openembedded-core-contrib/commit/?h=obi/daisy&id=1e3c64a768a5aeaf8d904609a14dd29e298821df
While at it, you may also take a look at this commit:
http://git.openembedded.org/openembedded-core-c
Hello Richard,
On Fri, Jul 11, 2014 at 5:27 AM, Richard Purdie
wrote:
> On Thu, 2014-07-10 at 23:43 -0300, Otavio Salvador wrote:
>> On Wed, Jul 9, 2014 at 5:15 PM, Richard Purdie
>> wrote:
>> > Its possible to run the package QA checks as a separate task rather than
>> > as part of the do_packa
Hi Koen,
Something like this (in a small python function) would be acceptable?
d.setVar('LICENSE', 'CLOSED')
Regards,
Matthieu
-Message d'origine-
De : Koen Kooi [mailto:k...@dominion.thruhere.net]
Envoyé : vendredi 11 juillet 2014 08:37
À : Martin Jansa
Cc : Matthieu CRAPET; openembe
Meta-networking seems the obvious home to me.
Ross
On Friday, 11 July 2014, Martin Jansa wrote:
> On Fri, Jul 11, 2014 at 12:20:13PM +0200, Martin Jansa wrote:
> > On Thu, Jul 10, 2014 at 09:57:56PM -0400, jackie.hu...@windriver.com
> wrote:
> > > From: Jackie Huang >
> > >
> > > Postfix is Wi
On Fri, Jul 11, 2014 at 12:20:13PM +0200, Martin Jansa wrote:
> On Thu, Jul 10, 2014 at 09:57:56PM -0400, jackie.hu...@windriver.com wrote:
> > From: Jackie Huang
> >
> > Postfix is Wietse Venema's mail server that started life at IBM
> > research as an alternative to the widely-used Sendmail pro
On Thu, Jul 10, 2014 at 09:57:56PM -0400, jackie.hu...@windriver.com wrote:
> From: Jackie Huang
>
> Postfix is Wietse Venema's mail server that started life at IBM
> research as an alternative to the widely-used Sendmail program.
>
> Postfix attempts to be fast, easy to administer, and secure.
On Thu, 2014-07-10 at 23:43 -0300, Otavio Salvador wrote:
> On Wed, Jul 9, 2014 at 5:15 PM, Richard Purdie
> wrote:
> > Its possible to run the package QA checks as a separate task rather than
> > as part of the do_package task. This offers more parallelism but the
> > fact that made me propose th
On 07/11/2014 01:45 PM, Paul Eggleton wrote:
Hi Chong,
On Friday 11 July 2014 09:25:07 Chong Lu wrote:
On 07/09/2014 09:39 AM, Chong Lu wrote:
QA errors/warnings would show the name of the QA failure in the
error/warning message.>
The format is listed:
[The name of QA] QA Issue: messa
On 11 July 2014 08:34, Anders Darander wrote:
> I think meta-oe is a better place for postfix. So, please resend it to
> meta-oe.
Agreed.
Ross
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-
> boun...@lists.openembedded.org] On Behalf Of Anders Darander
> Sent: Friday, July 11, 2014 3:34 PM
> To: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH 0
* jackie.hu...@windriver.com [140711 03:58]:
> We ported postfix from openembedded a year ago, and updated it to 2.9.5,
> now we are updating it to the latest stable release 2.11.1, and I'm
> sending here to see if oe-core take it, if not, I will send it to meta-oe.
I think meta-oe is a better pl
32 matches
Mail list logo
