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

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.

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.strasser@...>
---
.../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 0000000..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

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

On Fri, Sep 28, 2012 at 2:34 PM, Paul Eggleton
<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 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.

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
=============================

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.

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

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

+1

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 not so for others. I certainly don't need to provide a history lesson if I am the minority.

Scott

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
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
Packages<http://www.yoctoproject.org/docs/1.3/yocto-project-qs/yocto-projec
t-qs.html#packages>" section are compiled binaries that when installed add
functionality to your Linux distribution.

The thing is, this is actually the same meaning, we're just talking about
packages for your host distribution rather than packages for the custom distro
you're building - the concept is the same. If we do need to clarify it I would
suggest using the term "host package" or something very similar for packages
to be installed as pre-requisites on the host system.

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.
PR<http://www.yoctoproject.org/docs/1.3/poky-ref-manual/poky-ref-manual.htm
l#var-PR>,
PRINC<http://www.yoctoproject.org/docs/1.3/poky-ref-manual/poky-ref-manual.
html#var-PRINC>,
PV<http://www.yoctoproject.org/docs/1.3/poky-ref-manual/poky-ref-manual.htm
l#var-PV>, and
PE<http://www.yoctoproject.org/docs/1.3/poky-ref-manual/poky-ref-manual.htm
l#var-PE>).

I have to say, whilst this is an interesting point of history, I'm not sure
anyone really needs to know this in the manual, particularly if we've replaced
all historical use of the word "package" when we mean "recipe" (as I think we
now have for this release).

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre

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...

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.eggleton@...> 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

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

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.eggleton@...> 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

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

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.eggleton@...> 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 toe tput 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