Correct the port order to only list SDVOB and LVDS.
Update the Edid flags as appropriate. No EDID over LVDS. Enable built-in
and edid timings as well as DTDs for the SDVOB port.
Force 24-bit mode for LVDS port to work around an apparent bug with EMGD
in which the default 18-bit mode results in a
Correct the port order to only list SDVOB and LVDS.
Update the Edid flags as appropriate. No EDID over LVDS. Enable built-in
and edid timings as well as DTDs for the SDVOB port.
Force 24-bit mode for LVDS port to work around an apparent bug with EMGD
in which the default 18-bit mode results in a
I don't think it is just the intel ones. All the BSPs I've looked at
had this problem.
The yocto-bsp also creates packages that add to the problem, as it's
finished product adds files that end up in every BSP, and the final
source selected is not dependent on the machine. (userpatches and
userco
>From the perspective of a new, easily confused and overwhelmed user, I
whole heartedly agree with the index entry. And now it makes sense why
there is a PV to store version of a recipe.
On Fri, 2012-09-28 at 18:46 +, Rifenbark, Scott M wrote:
> Rudolf,
>
>
>
> This is good feedback on
The version of nfsd used in 3.4 kernels tries to upcall the
new reboot-recovery daemon and gets stuck if it is not found.
This causes client mounts to fail and prints the following
error message during boot:
"NFSD: starting 90-second grace period
NFSD: Unable to end grace period: -110"
If the dir
The new recovery mechanism used by nfs in 3.4 kernels is currently
failing when building baryon against poky 1.3_M3. This workaround
causes nfs to revert back to the old recovery mechanism.
The issue is discussed in more detail here:
https://lkml.org/lkml/2012/6/11/243
The following changes since
On Fri, Sep 28, 2012 at 2:34 PM, Paul Eggleton
wrote:
> On Friday 28 September 2012 11:27:37 Rudolf Streif wrote:
>> Unfortunately, changing variables like P, PN, PV, PR etc.
>> may cause some pain. If a transition is what the broader community would
>> like to achieve then a period where old and
On 09/28/2012 11:44 AM, Rudolf Streif wrote:
> I am not advocating changing the variable names. I know that this is a huge
> undertaking and prone to many problems. This probably one of the many legacy
> things people will have to live with and
> understand. In most cases recipe name and version
Rudolf,
This is good feedback on the descriptions for the variable names Rudolf. I did
try and clean things up there a bit.
Thanks,
Scott
From: rstr...@linuxfoundation.org [mailto:rstr...@linuxfoundation.org] On
Behalf Of Rudolf Streif
Sent: Friday, September 28, 2012 11:45 AM
To: Rifenbark,
I am not advocating changing the variable names. I know that this is a huge
undertaking and prone to many problems. This probably one of the many
legacy things people will have to live with and understand. In most cases
recipe name and version exactly reflect the name and version of the package
it
I have tried to weed out the ambiguous use of "package" for this upcoming
version of the manual set. I don't think I would want to suggest changing any
of the "P*" type variable names in the code. I agree with Paul here that the
potential for really messing things up out-weighs any other benef
On Friday 28 September 2012 11:27:37 Rudolf Streif wrote:
> +1
>
> I agree with Scott's definition. In the general Linux context a Package is
> a compilation of binaries, documentation, development files, etc. wrapped
> up in a format that can be used by a package management system to install
> it
+1
I agree with Scott's definition. In the general Linux context a Package is
a compilation of binaries, documentation, development files, etc. wrapped
up in a format that can be used by a package management system to install
it on a target system.
It is somewhat confusing that YP and OE use the
Paul,
Thanks for the clarification on the host packages. Maybe I should rewrite "The
Packages" section to use that term. That seems best. I guess the reason I
wanted to explain the weird variable names was because they caused me a lot of
angst as I tried to figure things out. Maybe this is
Hi Scott,
On Friday 28 September 2012 18:14:31 Rifenbark, Scott M wrote:
> * Package: In the context of the Yocto Project, this term refers to
> the packaged output from a baked recipe. A package is generally the
> compiled binaries produced from the recipe's sources. You 'bake' something
This post will have some strong opinions and responses. But, I want to throw
this out as a re-write of the term "Package" as defined in the YP Development
Manual's "Terms" section. I gave this a shot based on my brief understanding
and on some email that was tossed about a while back on the te
Just to bring this full circle: I finally got the CRC error on my Ubuntu
10.04 build server to go away by adding the following line to
/etc/apt/sources.list:
deb http://archive.ubuntu.com/ubuntu lucid-updates main universe restricted
and then executing:
sudo apt-get install gzip
to update g
> Is it definitely tar that's the problem or gzip? ...
Oh! Didn't even think of that. :-% Looks like it's gzip:
evadeflow% gzip -d perl-5.14.2.tar.gz
gzip: perl-5.14.2.tar.gz: invalid compressed data--crc error
Nice find! I'll see about updating my gzip...
On Fri, Sep 28, 2012 at 12:00 PM,
On Friday 28 September 2012 11:53:53 Evade Flow wrote:
> > > Erm... that *specific* bit prints nothing when pasted into a file and
> > > executed. (Is it really supposed to?)
> >
> > No, but the rest of the script (the bit following the blank line that
> > you've omitted) is...
>
> My bad, sorry.
> > Erm... that *specific* bit prints nothing when pasted into a file and
> > executed. (Is it really supposed to?)
> No, but the rest of the script (the bit following the blank line that you've
> omitted) is...
My bad, sorry. (I really need to read more carefully.) Here's what I get when
I add t
On Friday 28 September 2012 11:13:22 Evade Flow wrote:
> > ... could you put this into a file and run it and tell
> > me
> > what it prints on your system?
> >
> > --- snip --
> > #!/bin/sh
> > needtar=1
> > TARVERSION=`tar --version | head -n 1 | cut -d
To answer your questions...
> Just to confirm, this is the same path you get if you run "cat pseudodone"
> in your build directory?
Yessir.
evadeflow% cat pseudodone
/home/evadeflow/projects/poky-git/build/tmp/sysroots/i686-linux/usr/bin
> ... could you put this into a file a
On Friday 28 September 2012 10:16:27 Evade Flow wrote:
> Seems it definitely didn't build tar:
>
> evadeflow% pwd
> /home/evadeflow/projects/poky-git/build/tmp/sysroots/i686-linux/usr/bin
Just to confirm, this is the same path you get if you run "cat pseudodone" in
your build directory?
> evade
Seems it definitely didn't build tar:
evadeflow% pwd
/home/evadeflow/projects/poky-git/build/tmp/sysroots/i686-linux/usr/bin
evadeflow% ls t*
tabs tailf taskset tic toe tput tset tunctl tzselect
evadeflow% tar --version
tar (GNU tar) 1.22
Copyright (C) 2009 Free Software Foundation, Inc.
L
Move the tag from the SRC_URI to SRCREV to enable builds
using BB_NO_NETWORK
Signed-off-by: Martin Donnelly
---
meta/recipes-devtools/mtd/mtd-utils_1.5.0.bb | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-devtools/mtd/mtd-utils_1.5.0.bb
b/meta/recipes-devto
On Thursday 27 September 2012 17:30:48 Kevin Strasser wrote:
> This patch set clears up some of the warnings that are generated when
> building baryon against the tip of the 1.3_M3 branch of poky.
>
> The following changes since commit 500a124831e292d76d864a3c64a57a5007c4553a:
>
> kernel: enabl
26 matches
Mail list logo
