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: enable
Move the tag from the SRC_URI to SRCREV to enable builds
using BB_NO_NETWORK
Signed-off-by: Martin Donnelly martin.donne...@ge.com
---
meta/recipes-devtools/mtd/mtd-utils_1.5.0.bb | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git
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.
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?
evadeflow%
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 and
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 ' ' -f 4`
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 the
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. (I really
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,
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
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 term.
+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
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 on a
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 benefit.
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,
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
On Fri, Sep 28, 2012 at 2:34 PM, Paul Eggleton
paul.eggle...@linux.intel.com 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
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
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
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
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
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
23 matches
Mail list logo
