Re: [yocto] [meta-baryon][PATCH 0/4] clear up build warnings
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 nfsd when using the 3.4 kernel (2012-09-13 10:43:26 -0700) are available in the git repository at: git://git.yoctoproject.org/poky-contrib strassek/baryon-warnings http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=strassek/baryon-wa rnings Kevin Strasser (4): proftpd: remove unused directories after install samba: remove unused directories after install orc: specify the generic licenses being used talloc: specify the version of LGPL and include the license text recipes-connectivity/samba/samba.inc |2 ++ recipes-extended/proftpd/proftpd_1.3.4b.bb |1 + recipes-multimedia/orc/orc.inc |2 +- recipes-multimedia/orc/orc_0.4.5.bb|2 +- recipes-support/talloc/talloc_2.0.1.bb |6 +++--- 5 files changed, 8 insertions(+), 5 deletions(-) Merged to meta-baryon master, thanks. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH] mtd-utils: update SRC_URI to support BB_NO_NETWORK
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 a/meta/recipes-devtools/mtd/mtd-utils_1.5.0.bb
b/meta/recipes-devtools/mtd/mtd-utils_1.5.0.bb
index 1a9d4d3..f371739 100644
--- a/meta/recipes-devtools/mtd/mtd-utils_1.5.0.bb
+++ b/meta/recipes-devtools/mtd/mtd-utils_1.5.0.bb
@@ -6,8 +6,9 @@ LICENSE = GPLv2+
LIC_FILES_CHKSUM = file://COPYING;md5=0636e73ff0215e8d672dc4c32c317bb3 \
file://include/common.h;beginline=1;endline=17;md5=ba05b07912a44ea2bf81ce409380049c
-SRC_URI =
git://git.infradead.org/mtd-utils.git;protocol=git;tag=ca39eb1d98e736109c64ff9c1aa2a6ecca222d8f
\
- file://add-exclusion-to-mkfs-jffs2-git-2.patch
+SRC_URI = git://git.infradead.org/mtd-utils.git;protocol=git \
+ file://add-exclusion-to-mkfs-jffs2-git-2.patch
+SRCREV = ca39eb1d98e736109c64ff9c1aa2a6ecca222d8f
S = ${WORKDIR}/git/
--
1.7.11.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] build failure on current
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. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by John Gilmore and Jay Fenlason. This is on denzil, BTW. (Maybe the check against the tar version was added later?) evadeflow% bitbake core-image-sato WARNING: Host distribution Ubuntu 10.04 LTS has not been validated with this version of the build system; you may possibly experience unexpected failures. It is recommended that you use a tested distribution. Parsing recipes: 100% |###| Time: 00:00:07 Parsing of 829 .bb files complete (0 cached, 829 parsed). 1105 targets, 34 skipped, 0 masked, 0 errors. OE Build Configuration: BB_VERSION= 1.15.2 TARGET_ARCH = arm TARGET_OS = linux-gnueabi MACHINE = qemuarm DISTRO= poky DISTRO_VERSION= 1.2.1 TUNE_FEATURES = armv5 dsp thumb arm926ejs TARGET_FPU= soft meta meta-yocto= denzil:65ffa7395055f7e012cb973f63f92380828eed0d Maybe I got my build tree into an inconsistent state somehow when I was trying to 'fix' this. I can try rebuilding if it helps, using the original perl archive (not the one I re-tarballed with tar 1.22)... On Thu, Sep 27, 2012 at 6:58 PM, Paul Eggleton paul.eggle...@linux.intel.com wrote: On Thursday 27 September 2012 17:55:45 Evade Flow wrote: Fair enough. And I should mention that the error I reported occurs on Ubuntu 10.04. It's not like I wasn't warned. :-} WARNING: Host distribution Ubuntu 10.04 LTS has not been validated with this version of the build system; you may possibly experience unexpected failures. It is recommended that you use a tested distribution. (Other than this oddity with the perl package, things seem to work fine.) Yeah, it's just a warning :) This issue is rather perplexing. We're supposed to not be using the host tar if it is older than 1.24 due to another bug in earlier versions - if an older version is found we build tar-replacement-native before anything else gets built. Was tar-replacement-native built on the machine where it was failing? You can verify it built by just checking under tmp/sysroots/native sysroot/usr/bin/ to see if tar exists there. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] build failure on current
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% ls t*
tabs tailf taskset tic toetput tset tunctl tzselect
evadeflow% tar --version
tar (GNU tar) 1.22
...
This is on denzil, BTW. (Maybe the check against the tar version was added
later?)
No, the code to do this was there in denzil as well. Here's the code cut out
into a shell script - 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`
float_test() {
echo | awk 'END { exit ( !( '$1')); }'
}
# Tar version 1.24 and onwards handle overwriting symlinks correctly
# but earlier versions do not; this needs to work properly for sstate
float_test $TARVERSION 1.23 needtar=0
echo $needtar
--- snip --
Thanks,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] build failure on current
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 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`
float_test() {
echo | awk 'END { exit ( !( '$1')); }'
}
Erm... that *specific* bit prints nothing when pasted into a file and
executed. (Is it really supposed to?)
evadeflow% cat temp.sh
#!/bin/sh
needtar=1
TARVERSION=`tar --version | head -n 1 | cut -d ' ' -f 4`
float_test() {
echo | awk 'END { exit ( !( '$1')); }'
}
evadeflow% chmod +x temp.sh
evadeflow% ./temp.sh
evadeflow% ls -la /bin/sh
lrwxrwxrwx 1 root root 9 2010-08-13 05:08 /bin/sh - /bin/bash
evadeflow% tar --version | head -n 1 | cut -d ' ' -f 4
1.22
On Fri, Sep 28, 2012 at 10:34 AM, Paul Eggleton
paul.eggle...@linux.intel.com wrote:
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% ls t*
tabs tailf taskset tic toetput tset tunctl tzselect
evadeflow% tar --version
tar (GNU tar) 1.22
...
This is on denzil, BTW. (Maybe the check against the tar version was added
later?)
No, the code to do this was there in denzil as well. Here's the code cut out
into a shell script - 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`
float_test() {
echo | awk 'END { exit ( !( '$1')); }'
}
# Tar version 1.24 and onwards handle overwriting symlinks correctly
# but earlier versions do not; this needs to work properly for sstate
float_test $TARVERSION 1.23 needtar=0
echo $needtar
--- snip --
Thanks,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] build failure on current
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`
float_test() {
echo | awk 'END { exit ( !( '$1')); }'
}
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... I wanted to ensure that both the stripping out of the version
and float_test were working.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] build failure on current
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 missing lines:
evadeflow% cat temp.sh
#!/bin/sh
needtar=1
TARVERSION=`tar --version | head -n 1 | cut -d ' ' -f 4`
float_test() {
echo | awk 'END { exit ( !( '$1')); }'
}
# Tar version 1.24 and onwards handle overwriting symlinks correctly
# but earlier versions do not; this needs to work properly for sstate
float_test $TARVERSION 1.23 needtar=0
echo $needtar
evadeflow% chmod +x temp.sh
evadeflow% ./temp.sh
1
So... it correctly determines that it needs to build tar, but... the built tar
can't unpack the tarball from CPAN:
evadeflow% wget http://www.cpan.org/src/5.0/perl-5.14.2.tar.gz
--2012-09-28 11:46:13-- http://www.cpan.org/src/5.0/perl-5.14.2.tar.gz
Resolving usaprox1.lightning.com... 10.102.184.7
Connecting to usaprox1.lightning.com|10.102.184.7|:8080... connected.
Proxy request sent, awaiting response... 200 OK
Length: 15223598 (15M) [application/x-gzip]
Saving to: `perl-5.14.2.tar.gz'
100%[]
15,223,598 62.2M/s in 0.2s
2012-09-28 11:46:13 (62.2 MB/s) - `perl-5.14.2.tar.gz' saved [15223598/15223598]
evadeflow% ./poky-git/build/tmp/sysroots/i686-linux/usr/bin/tar xf
perl-5.14.2.tar.gz
gzip: stdin: invalid compressed data--crc error
./poky-git/build/tmp/sysroots/i686-linux/usr/bin/tar: Child returned status 1
./poky-git/build/tmp/sysroots/i686-linux/usr/bin/tar: Error is not
recoverable: exiting now
Weird. Anyway, I have a workaround, so it's not a big deal--especially given
that Ubuntu 10.04 isn't officially supported. I'm happy to run any other
tests you can think of to hunt down the cause of this (I've got a pretty fast
build mchine now), but I totally understand if you've got bigger fish to fry
at the moment...
On Fri, Sep 28, 2012 at 11:19 AM, Paul Eggleton
paul.eggle...@linux.intel.com wrote:
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`
float_test() {
echo | awk 'END { exit ( !( '$1')); }'
}
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... I wanted to ensure that both the stripping out of the version
and float_test were working.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] build failure on current
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 need to read more carefully.) Here's what I get
when I add the missing lines:
evadeflow% cat temp.sh
#!/bin/sh
needtar=1
TARVERSION=`tar --version | head -n 1 | cut -d ' ' -f 4`
float_test() {
echo | awk 'END { exit ( !( '$1')); }'
}
# Tar version 1.24 and onwards handle overwriting symlinks correctly
# but earlier versions do not; this needs to work properly for sstate
float_test $TARVERSION 1.23 needtar=0
echo $needtar
evadeflow% chmod +x temp.sh
evadeflow% ./temp.sh
1
So... it correctly determines that it needs to build tar, but... the built
tar can't unpack the tarball from CPAN:
evadeflow% wget http://www.cpan.org/src/5.0/perl-5.14.2.tar.gz
--2012-09-28 11:46:13-- http://www.cpan.org/src/5.0/perl-5.14.2.tar.gz
Resolving usaprox1.lightning.com... 10.102.184.7
Connecting to usaprox1.lightning.com|10.102.184.7|:8080... connected.
Proxy request sent, awaiting response... 200 OK
Length: 15223598 (15M) [application/x-gzip]
Saving to: `perl-5.14.2.tar.gz'
100%[]
15,223,598 62.2M/s in 0.2s
2012-09-28 11:46:13 (62.2 MB/s) - `perl-5.14.2.tar.gz' saved
[15223598/15223598]
evadeflow% ./poky-git/build/tmp/sysroots/i686-linux/usr/bin/tar xf
perl-5.14.2.tar.gz
gzip: stdin: invalid compressed data--crc error
./poky-git/build/tmp/sysroots/i686-linux/usr/bin/tar: Child returned status
1 ./poky-git/build/tmp/sysroots/i686-linux/usr/bin/tar: Error is not
recoverable: exiting now
Weird. Anyway, I have a workaround, so it's not a big deal--especially given
that Ubuntu 10.04 isn't officially supported. I'm happy to run any other
tests you can think of to hunt down the cause of this (I've got a pretty
fast build mchine now), but I totally understand if you've got bigger fish
to fry at the moment...
Is it definitely tar that's the problem or gzip? This would suggest gzip:
http://code.google.com/p/go/issues/detail?id=3443
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] build failure on current
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, Paul Eggleton
paul.eggle...@linux.intel.com wrote:
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 need to read more carefully.) Here's what I get
when I add the missing lines:
evadeflow% cat temp.sh
#!/bin/sh
needtar=1
TARVERSION=`tar --version | head -n 1 | cut -d ' ' -f 4`
float_test() {
echo | awk 'END { exit ( !( '$1')); }'
}
# Tar version 1.24 and onwards handle overwriting symlinks correctly
# but earlier versions do not; this needs to work properly for sstate
float_test $TARVERSION 1.23 needtar=0
echo $needtar
evadeflow% chmod +x temp.sh
evadeflow% ./temp.sh
1
So... it correctly determines that it needs to build tar, but... the built
tar can't unpack the tarball from CPAN:
evadeflow% wget http://www.cpan.org/src/5.0/perl-5.14.2.tar.gz
--2012-09-28 11:46:13-- http://www.cpan.org/src/5.0/perl-5.14.2.tar.gz
Resolving usaprox1.lightning.com... 10.102.184.7
Connecting to usaprox1.lightning.com|10.102.184.7|:8080... connected.
Proxy request sent, awaiting response... 200 OK
Length: 15223598 (15M) [application/x-gzip]
Saving to: `perl-5.14.2.tar.gz'
100%[]
15,223,598 62.2M/s in 0.2s
2012-09-28 11:46:13 (62.2 MB/s) - `perl-5.14.2.tar.gz' saved
[15223598/15223598]
evadeflow% ./poky-git/build/tmp/sysroots/i686-linux/usr/bin/tar xf
perl-5.14.2.tar.gz
gzip: stdin: invalid compressed data--crc error
./poky-git/build/tmp/sysroots/i686-linux/usr/bin/tar: Child returned status
1 ./poky-git/build/tmp/sysroots/i686-linux/usr/bin/tar: Error is not
recoverable: exiting now
Weird. Anyway, I have a workaround, so it's not a big deal--especially given
that Ubuntu 10.04 isn't officially supported. I'm happy to run any other
tests you can think of to hunt down the cause of this (I've got a pretty
fast build mchine now), but I totally understand if you've got bigger fish
to fry at the moment...
Is it definitely tar that's the problem or gzip? This would suggest gzip:
http://code.google.com/p/go/issues/detail?id=3443
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] build failure on current
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 gzip. Thanks, Paul, for all of your help in tracking this
down...
On Fri, Sep 28, 2012 at 12:34 PM, Evade Flow evadef...@gmail.com wrote:
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, Paul Eggleton
paul.eggle...@linux.intel.com wrote:
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 need to read more carefully.) Here's what I get
when I add the missing lines:
evadeflow% cat temp.sh
#!/bin/sh
needtar=1
TARVERSION=`tar --version | head -n 1 | cut -d ' ' -f 4`
float_test() {
echo | awk 'END { exit ( !( '$1')); }'
}
# Tar version 1.24 and onwards handle overwriting symlinks correctly
# but earlier versions do not; this needs to work properly for sstate
float_test $TARVERSION 1.23 needtar=0
echo $needtar
evadeflow% chmod +x temp.sh
evadeflow% ./temp.sh
1
So... it correctly determines that it needs to build tar, but... the built
tar can't unpack the tarball from CPAN:
evadeflow% wget http://www.cpan.org/src/5.0/perl-5.14.2.tar.gz
--2012-09-28 11:46:13-- http://www.cpan.org/src/5.0/perl-5.14.2.tar.gz
Resolving usaprox1.lightning.com... 10.102.184.7
Connecting to usaprox1.lightning.com|10.102.184.7|:8080... connected.
Proxy request sent, awaiting response... 200 OK
Length: 15223598 (15M) [application/x-gzip]
Saving to: `perl-5.14.2.tar.gz'
100%[]
15,223,598 62.2M/s in 0.2s
2012-09-28 11:46:13 (62.2 MB/s) - `perl-5.14.2.tar.gz' saved
[15223598/15223598]
evadeflow% ./poky-git/build/tmp/sysroots/i686-linux/usr/bin/tar xf
perl-5.14.2.tar.gz
gzip: stdin: invalid compressed data--crc error
./poky-git/build/tmp/sysroots/i686-linux/usr/bin/tar: Child returned status
1 ./poky-git/build/tmp/sysroots/i686-linux/usr/bin/tar: Error is not
recoverable: exiting now
Weird. Anyway, I have a workaround, so it's not a big deal--especially given
that Ubuntu 10.04 isn't officially supported. I'm happy to run any other
tests you can think of to hunt down the cause of this (I've got a pretty
fast build mchine now), but I totally understand if you've got bigger fish
to fry at the moment...
Is it definitely tar that's the problem or gzip? This would suggest gzip:
http://code.google.com/p/go/issues/detail?id=3443
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] The term Package as used in the YP docs
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. What I would like to ultimately come up with is a definition that works for the term as we want to use it in the YP docs and also as an explanation for some of our older variable names like PR, PV, and so forth that really refer to recipes. Please thrash over it * 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 by running it through BitBake. It is worth noting that the term package can, in general, have subtle meanings. For example, the packages refered to in the The Packageshttp://www.yoctoproject.org/docs/1.3/yocto-project-qs/yocto-project-qs.html#packages section are compiled binaries that when installed add functionality to your Linux distribution. Another point worth noting is that historically within the Yocto Project, recipes were referred to as packages - thus, the existence of several BitBake variables that are seemingly mis-named, (e.g. PRhttp://www.yoctoproject.org/docs/1.3/poky-ref-manual/poky-ref-manual.html#var-PR, PRINChttp://www.yoctoproject.org/docs/1.3/poky-ref-manual/poky-ref-manual.html#var-PRINC, PVhttp://www.yoctoproject.org/docs/1.3/poky-ref-manual/poky-ref-manual.html#var-PV, and PEhttp://www.yoctoproject.org/docs/1.3/poky-ref-manual/poky-ref-manual.html#var-PE). Scott Rifenbark Intel Corporation Yocto Project Documentation 503.712.2702 503.341.0418 (cell) ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] The term Package as used in the YP docs
+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 term 'package' synonymously with 'recipe'. In most cases a package is the output of a recipe. I am all for making this more consistent at least to start with in the documentation. 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 new variables can be used interchangeably (if possible) would be the way to go. :rjs On Fri, Sep 28, 2012 at 11:14 AM, Rifenbark, Scott M scott.m.rifenb...@intel.com wrote: 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. What I would like to ultimately come up with is a definition that works for the term as we want to use it in the YP docs and also as an explanation for some of our older variable names like PR, PV, and so forth that really refer to recipes. Please thrash over it…. ** ** **· ***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 by running it through BitBake. It is worth noting that the term package can, in general, have subtle meanings. For example, the packages refered to in the The Packageshttp://www.yoctoproject.org/docs/1.3/yocto-project-qs/yocto-project-qs.html#packages section are compiled binaries that when installed add functionality to your Linux distribution. Another point worth noting is that historically within the Yocto Project, recipes were referred to as packages - thus, the existence of several BitBake variables that are seemingly mis-named, (e.g. PRhttp://www.yoctoproject.org/docs/1.3/poky-ref-manual/poky-ref-manual.html#var-PR, PRINChttp://www.yoctoproject.org/docs/1.3/poky-ref-manual/poky-ref-manual.html#var-PRINC, PVhttp://www.yoctoproject.org/docs/1.3/poky-ref-manual/poky-ref-manual.html#var-PV, and PEhttp://www.yoctoproject.org/docs/1.3/poky-ref-manual/poky-ref-manual.html#var-PE). ** ** ** ** *Scott Rifenbark*** Intel Corporation Yocto Project Documentation 503.712.2702 503.341.0418 (cell) ** ** ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] The term Package as used in the YP docs
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 target system. No dispute there. It is somewhat confusing that YP and OE use the term 'package' synonymously with 'recipe'. In most cases a package is the output of a recipe. The thing is, we no longer do that - we've fixed a number of references in the documentation, help text and error messages for this release so that recipe is used when that's what we mean. If we've left any references that should be considered a bug. 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 new variables can be used interchangeably (if possible) would be the way to go. I'm not sure there's a huge amount to be gained by doing this when weighed against the cost - it would certainly cause a massive amount of churn, with the potential for problems with layer interaction where one layer has done the big rename and another that bbappends recipes in the first hasn't. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] The term Package as used in the YP docs
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. This is why I was trying to worm in a bit of history behind those names for the people that might struggle like me. Scott -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Paul Eggleton Sent: Friday, September 28, 2012 11:34 AM To: Rudolf Streif Cc: yocto@yoctoproject.org Subject: Re: [yocto] The term Package as used in the YP docs 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 target system. No dispute there. It is somewhat confusing that YP and OE use the term 'package' synonymously with 'recipe'. In most cases a package is the output of a recipe. The thing is, we no longer do that - we've fixed a number of references in the documentation, help text and error messages for this release so that recipe is used when that's what we mean. If we've left any references that should be considered a bug. 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 new variables can be used interchangeably (if possible) would be the way to go. I'm not sure there's a huge amount to be gained by doing this when weighed against the cost - it would certainly cause a massive amount of churn, with the potential for problems with layer interaction where one layer has done the big rename and another that bbappends recipes in the first hasn't. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] The term Package as used in the YP docs
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, Scott M Cc: Paul Eggleton; yocto@yoctoproject.org Subject: Re: [yocto] The term Package as used in the YP docs 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 is intended to build which to some extend mitigates the issue. As far as the Terms section in the manuals is concerned, I see that you already changed the describing text for the variables. That's sufficient, I think. :rjs On Fri, Sep 28, 2012 at 11:37 AM, Rifenbark, Scott M scott.m.rifenb...@intel.commailto:scott.m.rifenb...@intel.com wrote: 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. This is why I was trying to worm in a bit of history behind those names for the people that might struggle like me. Scott -Original Message- From: yocto-boun...@yoctoproject.orgmailto:yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.orgmailto:yocto-boun...@yoctoproject.org] On Behalf Of Paul Eggleton Sent: Friday, September 28, 2012 11:34 AM To: Rudolf Streif Cc: yocto@yoctoproject.orgmailto:yocto@yoctoproject.org Subject: Re: [yocto] The term Package as used in the YP docs 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 target system. No dispute there. It is somewhat confusing that YP and OE use the term 'package' synonymously with 'recipe'. In most cases a package is the output of a recipe. The thing is, we no longer do that - we've fixed a number of references in the documentation, help text and error messages for this release so that recipe is used when that's what we mean. If we've left any references that should be considered a bug. 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 new variables can be used interchangeably (if possible) would be the way to go. I'm not sure there's a huge amount to be gained by doing this when weighed against the cost - it would certainly cause a massive amount of churn, with the potential for problems with layer interaction where one layer has done the big rename and another that bbappends recipes in the first hasn't. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.orgmailto:yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] The term Package as used in the YP docs
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 exactly reflect the name and version of the package it is intended to build which to some extend mitigates the issue. As far as the Terms section in the manuals is concerned, I see that you already changed the describing text for the variables. That's sufficient, I think. (I answered Scott privately by mistake - here's some feedback on-list) I'm in favor of mentioning the history somewhere, because the names do have a 'P' in them, and this is confusing otherwise. Overall, I think the new wording is worthwhile. -- Tim = Tim Bird Architecture Group Chair, CE Workgroup of the Linux Foundation Senior Staff Engineer, Sony Network Entertainment = ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] The term Package as used in the YP docs
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 a period where old and new variables can be used interchangeably (if possible) would be the way to go. I'm not sure there's a huge amount to be gained by doing this when weighed against the cost - it would certainly cause a massive amount of churn, with the potential for problems with layer interaction where one layer has done the big rename and another that bbappends recipes in the first hasn't. Not that it matters in the grand scheme of things, but I would be in favour of switching the variable names. Consistency is as consistency does; if there's any hope people can stop confusing poky for yocto, yocto with the yocto project, and packages for recipes then it needs to be pervasively correct. Provided the Yocto Project continues to grow, changes like this only get harder with time, and if the project gets bigger (i.e. more uses) the confusion only spreads further the longer it is left unchecked. In any case I applaud all the efforts to standardize the wording, especially in the documentation. As such I think it would be quite helpful to have the proposed historical note included. Hopefully, the sooner newcomers are aware of the issue, the less they're likely to trip up over it. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-baryon][PATCH 0/1] nfs regression workaround
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 commit e4efadec4a1ded0a66fa67c7cca868b7a4b6221b: talloc: specify the version of LGPL and include the license text (2012-09-27 16:54:08 -0700) are available in the git repository at: git://git.yoctoproject.org/poky-contrib strassek/baryon-nfsd-regression http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=strassek/baryon-nfsd-regression Kevin Strasser (1): nfs-utils: workaround for nfsd regression in the 3.4 kernel .../nfs-utils/nfs-utils_1.2.3.bbappend |8 1 file changed, 8 insertions(+) create mode 100644 recipes-connectivity/nfs-utils/nfs-utils_1.2.3.bbappend -- 1.7.9.5 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-baryon][PATCH 1/1] nfs-utils: workaround for nfsd regression in the 3.4 kernel
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 directory /var/lib/nfs/v4recovery exists, nfsd will
revert back to the old method.
Signed-off-by: Kevin Strasser kevin.stras...@linux.intel.com
---
.../nfs-utils/nfs-utils_1.2.3.bbappend |8
1 file changed, 8 insertions(+)
create mode 100644 recipes-connectivity/nfs-utils/nfs-utils_1.2.3.bbappend
diff --git a/recipes-connectivity/nfs-utils/nfs-utils_1.2.3.bbappend
b/recipes-connectivity/nfs-utils/nfs-utils_1.2.3.bbappend
new file mode 100644
index 000..2c91a93
--- /dev/null
+++ b/recipes-connectivity/nfs-utils/nfs-utils_1.2.3.bbappend
@@ -0,0 +1,8 @@
+PR = r5
+
+# Work around linux 3.4 nfsd regression
+do_install_prepend () {
+ install -d ${D}/var/lib/nfs/v4recovery
+}
+
+FILES_${PN} += /var/lib/nfs/v4recovery
--
1.7.9.5
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] The term Package as used in the YP docs
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 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, Scott M Cc: Paul Eggleton; yocto@yoctoproject.org Subject: Re: [yocto] The term Package as used in the YP docs 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 is intended to build which to some extend mitigates the issue. As far as the Terms section in the manuals is concerned, I see that you already changed the describing text for the variables. That's sufficient, I think. :rjs On Fri, Sep 28, 2012 at 11:37 AM, Rifenbark, Scott M scott.m.rifenb...@intel.com wrote: 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. This is why I was trying to worm in a bit of history behind those names for the people that might struggle like me. Scott -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Paul Eggleton Sent: Friday, September 28, 2012 11:34 AM To: Rudolf Streif Cc: yocto@yoctoproject.org Subject: Re: [yocto] The term Package as used in the YP docs 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 target system. No dispute there. It is somewhat confusing that YP and OE use the term 'package' synonymously with 'recipe'. In most cases a package is the output of a recipe. The thing is, we no longer do that - we've fixed a number of references in the documentation, help text and error messages for this release so that recipe is used when that's what we mean. If we've left any references that should be considered a bug. 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 new variables can be used interchangeably (if possible) would be the way to go. I'm not sure there's a huge amount to be gained by doing this when weighed against the cost - it would certainly cause a massive amount of churn, with the potential for problems with layer interaction where one layer has done the big rename and another that bbappends recipes in the first hasn't. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Cannot do atom-pc build with meta-cedartrail
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
userconfig).
If you have filed a bug, I'll add to that, otherwise I was looking to
add a bug discussing this myself. I just hadn't had time to see just
how pervasive it is, but it is definitely pervasive enough that the
problem should be mentioned in the project documentation and methods to
avoid it given.
Brian A. Lloyd
On Thu, 2012-09-27 at 17:10 +0300, Mihai Lindner wrote:
On 2012-09-27 14:31, Burton, Ross wrote:
Hi,
If I add meta-intel and meta-cedartrail to my bblayers, when I try and
do an atom-pc build (which I thought should still work, right?) I get
the following error:
NOTE: Error during finalise of
/home/ross/Yocto/poky/meta/recipes-kernel/linux/linux-yocto_3.0.bb
ERROR: ExpansionError during parsing
/home/ross/Yocto/poky/meta/recipes-kernel/linux/linux-yocto_3.0.bb:
Failure expanding variable SRCPV, expression was
${@bb.fetch2.get_srcrev(d)} which triggered exception FetchError:
Fetcher failure for URL:
'git://git.yoctoproject.org/linux-yocto-3.0;protocol=git;bareclone=1;branch=yocto/standard/common-pc/atom-pc,meta,yocto/pvr;name=machine,meta,pvr'.
Please set SRCREV to a valid value
That's a bug, right?
Ross
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
That's a bug alright.
It seems the overall SRC_URI of linux-yocto is overwritten by meta-cedartrail
layer, when included. Should be fixed by using SRC_URI_cedartrail instead.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH][meta-intel] fri2: Update xorg.conf per EMGD 1.14 user guide
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 dim display using the secondary (LVDS) HDMI port (lower port). Add backlight intensity and inverter frequency specifications for the LVDS port per the note in the EMGD 1.14 User Guide (p 184) for E6xx CPUs. Signed-off-by: Darren Hart dvh...@linux.intel.com --- .../xserver-xf86-config/fri2/xorg.conf | 29 +- 1 file changed, 23 insertions(+), 6 deletions(-) diff --git a/meta-fri2/recipes-graphics/xorg-xserver/xserver-xf86-config/fri2/xorg.conf b/meta-fri2/recipes-graphics/xorg-xserver/xserver-xf86-config/fri2/xorg.conf index 73736ac..8c31565 100644 --- a/meta-fri2/recipes-graphics/xorg-xserver/xserver-xf86-config/fri2/xorg.conf +++ b/meta-fri2/recipes-graphics/xorg-xserver/xserver-xf86-config/fri2/xorg.conf @@ -23,15 +23,32 @@ Section Device Option PcfVersion1792 Option ConfigId 1 Option ALL/1/name e6xx -Option ALL/1/General/PortOrder 32400 +Option ALL/1/General/PortOrder 24000 Option ALL/1/General/DisplayConfig 1 Option ALL/1/General/DisplayDetect 1 -Option ALL/1/General/TuningWA 1 -Option ALL/1/Port/4/General/name lvds -Option ALL/1/Port/4/General/EdidAvail 3 -Option ALL/1/Port/4/General/EdidNotAvail 1 -Option ALL/1/Port/4/General/Rotation 0 +Option ALL/1/General/TuningWA 1 + +# Primary display (upper HDMI port, driven by sDVOB) +Option ALL/1/Port/2/General/name Primary +Option ALL/1/Port/2/General/Edid 1 +Option ALL/1/Port/2/General/EdidAvail 7 +Option ALL/1/Port/2/General/EdidNotAvail 5 +Option ALL/1/Port/2/General/Rotation 0 +Option ALL/1/Port/2/Attr/7120300 + +# Secondary display (lower HDMI port, driven by LVDS, 1366x768) +Option ALL/1/Port/4/General/name Secondary Option ALL/1/Port/4/General/Edid 0 +Option ALL/1/Port/4/General/Rotation 0 + +# Panel depth (the default 18 results in a dim display) +# Force dither off for 24-bit panels +Option ALL/1/Port/4/Attr/2624 +Option ALL/1/Port/4/Attr/450 + +# Backlight intensity and inverter frequency for E6xx CPUs +Option ALL/1/Port/4/Attr/70100 +Option ALL/1/Port/4/Attr/7120300 EndSection Section ServerLayout -- 1.7.11.4 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH V2][meta-intel] fri2: Update xorg.conf per EMGD 1.14 user guide
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 dim display using the
secondary (LVDS) HDMI port (lower port).
Add backlight intensity and inverter frequency specifications for the
LVDS port per the note in the EMGD 1.14 User Guide (p 184) for E6xx
CPUs.
V2: Update PRINC
Applies to both master and denzil
Signed-off-by: Darren Hart dvh...@linux.intel.com
---
.../xserver-xf86-config/fri2/xorg.conf | 29 +++
.../xorg-xserver/xserver-xf86-config_0.1.bbappend |2 +-
2 files changed, 24 insertions(+), 7 deletions(-)
diff --git
a/meta-fri2/recipes-graphics/xorg-xserver/xserver-xf86-config/fri2/xorg.conf
b/meta-fri2/recipes-graphics/xorg-xserver/xserver-xf86-config/fri2/xorg.conf
index 73736ac..8c31565 100644
--- a/meta-fri2/recipes-graphics/xorg-xserver/xserver-xf86-config/fri2/xorg.conf
+++ b/meta-fri2/recipes-graphics/xorg-xserver/xserver-xf86-config/fri2/xorg.conf
@@ -23,15 +23,32 @@ Section Device
Option PcfVersion1792
Option ConfigId 1
Option ALL/1/name e6xx
-Option ALL/1/General/PortOrder 32400
+Option ALL/1/General/PortOrder 24000
Option ALL/1/General/DisplayConfig 1
Option ALL/1/General/DisplayDetect 1
-Option ALL/1/General/TuningWA 1
-Option ALL/1/Port/4/General/name lvds
-Option ALL/1/Port/4/General/EdidAvail 3
-Option ALL/1/Port/4/General/EdidNotAvail 1
-Option ALL/1/Port/4/General/Rotation 0
+Option ALL/1/General/TuningWA 1
+
+# Primary display (upper HDMI port, driven by sDVOB)
+Option ALL/1/Port/2/General/name Primary
+Option ALL/1/Port/2/General/Edid 1
+Option ALL/1/Port/2/General/EdidAvail 7
+Option ALL/1/Port/2/General/EdidNotAvail 5
+Option ALL/1/Port/2/General/Rotation 0
+Option ALL/1/Port/2/Attr/7120300
+
+# Secondary display (lower HDMI port, driven by LVDS, 1366x768)
+Option ALL/1/Port/4/General/name Secondary
Option ALL/1/Port/4/General/Edid 0
+Option ALL/1/Port/4/General/Rotation 0
+
+# Panel depth (the default 18 results in a dim display)
+# Force dither off for 24-bit panels
+Option ALL/1/Port/4/Attr/2624
+Option ALL/1/Port/4/Attr/450
+
+# Backlight intensity and inverter frequency for E6xx CPUs
+Option ALL/1/Port/4/Attr/70100
+Option ALL/1/Port/4/Attr/7120300
EndSection
Section ServerLayout
diff --git
a/meta-fri2/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
b/meta-fri2/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
index 4b8d0e6..a6d7d8e 100644
--- a/meta-fri2/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
+++ b/meta-fri2/recipes-graphics/xorg-xserver/xserver-xf86-config_0.1.bbappend
@@ -1,3 +1,3 @@
THISDIR := ${@os.path.dirname(bb.data.getVar('FILE', d, True))}
FILESPATH =. ${@base_set_filespath([${THISDIR}/${PN}], d)}:
-
+PRINC := ${@int(PRINC) + 1}
--
1.7.5.4
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
