On Fri, Nov 25, 2011 at 3:29 AM, Steffen Sledz wrote:
> On 25.11.2011 12:21, Koen Kooi wrote:
>>
>> Op 25 nov. 2011, om 12:05 heeft Steffen Sledz het volgende geschreven:
>>
>>> The LIVE555 project has a really uncommon source deployment policy. :(
>>>
>>> They publish *only* the latest tarball of
On Fri, Nov 25, 2011 at 7:06 AM, Richard Purdie
wrote:
> On my system, the sys/time.h header is in a subdir off /usr/include
> which causes a build failure. Apply the target CFLAGS fix to native
> builds as well to address this.
hmmm I thought CFLAGS would be automtically translated with
BBCLASSE
On Fri, 2011-11-25 at 19:07 +, McClintock Matthew-B29882 wrote:
> On Fri, Nov 25, 2011 at 6:29 AM, Julian Pidancet
> wrote:
> > This patch introduces a distro feature which enables gcc to produce
> > both 32bit and 64bit code, and enables binutils to operate on both
> > 32bit and 64bit binarie
On 11/24/2011 12:05 AM, Darren Hart wrote:
> Add a recipe to build the GRUB efi images. This recipe is written as
> a native recipe as the resulting GRUB utils are required to assemble
> the final image. Rather than build a native and a target recipe (and
> increase build times), this recipe buil
Op 25 nov. 2011, om 19:15 heeft Koen Kooi het volgende geschreven:
>
> Op 25 nov. 2011, om 17:53 heeft Richard Purdie het volgende geschreven:
>
>> On Fri, 2011-11-25 at 16:38 +0100, Koen Kooi wrote:
>>> In OE-classic the opkg-make-index cache was working pretty well,
>>> do_rootfs only spent a
On Fri, Nov 25, 2011 at 6:29 AM, Julian Pidancet
wrote:
> This patch introduces a distro feature which enables gcc to produce
> both 32bit and 64bit code, and enables binutils to operate on both
> 32bit and 64bit binaries.
>
> v3: - Make get_gcc_multiarch_setting more elegant. Use a dictionnary
>
Op 25 nov. 2011, om 17:53 heeft Richard Purdie het volgende geschreven:
> On Fri, 2011-11-25 at 16:38 +0100, Koen Kooi wrote:
>> In OE-classic the opkg-make-index cache was working pretty well,
>> do_rootfs only spent a few seconds doing opkg-make-index on
>> incremental builds. In the OE-core wo
On Fri, 2011-11-25 at 16:38 +0100, Koen Kooi wrote:
> In OE-classic the opkg-make-index cache was working pretty well,
> do_rootfs only spent a few seconds doing opkg-make-index on
> incremental builds. In the OE-core world the situation is different,
> opkg-make-index will reindex every package on
Hi,
In OE-classic the opkg-make-index cache was working pretty well, do_rootfs only
spent a few seconds doing opkg-make-index on incremental builds. In the OE-core
world the situation is different, opkg-make-index will reindex every package on
each do_rootfs run, so after a while building image
Complete the bb.data.getVar/setVar replacements with accesses
directly to the data store object.
Signed-off-by: Richard Purdie
---
diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index 72196d6..a95dfd9 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -3
Avoiding the autoreconf with a hardcoded do_configure is bad practise
since it can hide various errors. This patch ensures we do use the
standard do_configure.
Signed-off-by: Richard Purdie
---
diff --git a/meta/recipes-extended/ghostscript/ghostscript_9.04.bb
b/meta/recipes-extended/ghostscript
On my system, the sys/time.h header is in a subdir off /usr/include
which causes a build failure. Apply the target CFLAGS fix to native
builds as well to address this.
Signed-off-by: Richard Purdie
---
diff --git a/meta/recipes-extended/ghostscript/ghostscript_9.04.bb
b/meta/recipes-extended/gho
There continues to be parallel make race issues showing up on the autobuilder.
This patch removes some potential sources of these. The rm is unrequired
since we're using cp -f. The || true ensures that if we did race against
someone it becomes harmless.
[YOCTO #1202]
Signed-off-by: Richard Purdie
Op 25 nov. 2011, om 14:52 heeft Richard Purdie het volgende geschreven:
> On Fri, 2011-11-25 at 14:17 +0100, Koen Kooi wrote:
>> Op 25 nov. 2011, om 12:44 heeft Paul Eggleton het volgende geschreven:
>>> Hi Koen / Beth / all,
>>>
>>> Following on from my work extending packagehistory (which is s
On Fri, 2011-11-25 at 14:17 +0100, Koen Kooi wrote:
> Op 25 nov. 2011, om 12:44 heeft Paul Eggleton het volgende geschreven:
> > Hi Koen / Beth / all,
> >
> > Following on from my work extending packagehistory (which is still under
> > review), I'm looking at tracking history of the content of im
Op 25 nov. 2011, om 12:44 heeft Paul Eggleton het volgende geschreven:
> Hi Koen / Beth / all,
>
> Following on from my work extending packagehistory (which is still under
> review), I'm looking at tracking history of the content of images so we can
> get warnings about regressions. Thanks to
On Fri, 2011-11-25 at 11:08 +, Richard Purdie wrote:
> The vesa driver looks like its using DGA APIs to expose mode setting. A
> comment to that end is also in a TODO list at the top of the file.
Ah, I see. I guess that can just be turned off for non-DGA builds then.
As you say, making it use
Hi Koen / Beth / all,
Following on from my work extending packagehistory (which is still under
review), I'm looking at tracking history of the content of images so we can
get warnings about regressions. Thanks to Koen we've had this capability via
testlab.bbclass in OE for some time now, and fr
This patch introduces a distro feature which enables gcc to produce
both 32bit and 64bit code, and enables binutils to operate on both
32bit and 64bit binaries.
v3: - Make get_gcc_multiarch_setting more elegant. Use a dictionnary
to store the config options and replace bb.data.getVar with d.getVar
On 25.11.2011 12:21, Koen Kooi wrote:
>
> Op 25 nov. 2011, om 12:05 heeft Steffen Sledz het volgende geschreven:
>
>> The LIVE555 project has a really uncommon source deployment policy. :(
>>
>> They publish *only* the latest tarball of their code [1]. And they don't
>> make the code available u
Op 25 nov. 2011, om 12:05 heeft Steffen Sledz het volgende geschreven:
> The LIVE555 project has a really uncommon source deployment policy. :(
>
> They publish *only* the latest tarball of their code [1]. And they don't make
> the code available under a source code repository [2].
>
> I've as
On Fri, Nov 25, 2011 at 09:03, Phil Blundell wrote:
> On Fri, 2011-11-25 at 00:00 +, Richard Purdie wrote:
> > Looking at vesa.c, there is quite a chunk of code in there depending on
> > DGA.
>
> I guess the question is, is this chunk of code actually doing anything
> useful/important, or is
On Fri, 2011-11-25 at 11:03 +, Phil Blundell wrote:
> On Fri, 2011-11-25 at 00:00 +, Richard Purdie wrote:
> > Looking at vesa.c, there is quite a chunk of code in there depending on
> > DGA.
>
> I guess the question is, is this chunk of code actually doing anything
> useful/important, or
The LIVE555 project has a really uncommon source deployment policy. :(
They publish *only* the latest tarball of their code [1]. And they don't make
the code available under a source code repository [2].
I've asked to change this policy but they are not willing to do that [3].
How can we handle
On Fri, 2011-11-25 at 00:00 +, Richard Purdie wrote:
> Looking at vesa.c, there is quite a chunk of code in there depending on
> DGA.
I guess the question is, is this chunk of code actually doing anything
useful/important, or is it just there to support DGA on VESA? If the
latter then people
On Thu, Nov 24, 2011 at 22:00, Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:
> ...
>
Looking at vesa.c, there is quite a chunk of code in there depending on
> DGA.
>
Yes.
> Is there any harm to building DGA apart from an extra package? Its a
> self contained module isn't it?
>
AF
26 matches
Mail list logo
