Date   

Re: Cannot do atom-pc build with meta-cedartrail

Brian Lloyd <blloyd@...>
 

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


Re: The term Package as used in the YP docs

Brian Lloyd <blloyd@...>
 

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 +0000, 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: rstreif@... [mailto:rstreif@...]
On Behalf Of Rudolf Streif
Sent: Friday, September 28, 2012 11:45 AM
To: Rifenbark, Scott M
Cc: Paul Eggleton; yocto@...
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.rifenbark@...> 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-bounces@...
[mailto:yocto-bounces@...] On Behalf Of Paul Eggleton
Sent: Friday, September 28, 2012 11:34 AM
To: Rudolf Streif
Cc: yocto@...
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@...
https://lists.yoctoproject.org/listinfo/yocto





_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


[meta-baryon][PATCH 1/1] nfs-utils: workaround for nfsd regression in the 3.4 kernel

Kevin Strasser <kevin.strasser@...>
 

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


[meta-baryon][PATCH 0/1] nfs regression workaround

Kevin Strasser <kevin.strasser@...>
 

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


Re: The term Package as used in the YP docs

Trevor Woerner
 

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.


Re: The term Package as used in the YP docs

Tim Bird <tim.bird@...>
 

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


Re: The term Package as used in the YP docs

Rifenbark, Scott M <scott.m.rifenbark@...>
 

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: rstreif@... [mailto:rstreif@...] On Behalf Of Rudolf Streif
Sent: Friday, September 28, 2012 11:45 AM
To: Rifenbark, Scott M
Cc: Paul Eggleton; yocto@...
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.rifenbark@...> 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-bounces@... [mailto:yocto-bounces@...] On Behalf Of Paul Eggleton
Sent: Friday, September 28, 2012 11:34 AM
To: Rudolf Streif
Cc: yocto@...
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@...
https://lists.yoctoproject.org/listinfo/yocto

 


Re: The term Package as used in the YP docs

Rudolf Streif <rudolf.streif@...>
 

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.rifenbark@...> 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-bounces@... [mailto:yocto-bounces@...] On Behalf Of Paul Eggleton
Sent: Friday, September 28, 2012 11:34 AM
To: Rudolf Streif
Cc: yocto@...
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@...
https://lists.yoctoproject.org/listinfo/yocto


Re: The term Package as used in the YP docs

Rifenbark, Scott M <scott.m.rifenbark@...>
 

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-bounces@... [mailto:yocto-bounces@...] On Behalf Of Paul Eggleton
Sent: Friday, September 28, 2012 11:34 AM
To: Rudolf Streif
Cc: yocto@...
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@...
https://lists.yoctoproject.org/listinfo/yocto


Re: The term Package as used in the YP docs

Paul Eggleton
 

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


Re: The term Package as used in the YP docs

Rudolf Streif <rudolf.streif@...>
 

+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.rifenbark@...> 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 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. PR, PRINC, PV, and PE).

 

 

Scott Rifenbark

Intel Corporation

Yocto Project Documentation

503.712.2702

503.341.0418 (cell)

 


_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto



Re: The term Package as used in the YP docs

Rifenbark, Scott M <scott.m.rifenbark@...>
 

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

-----Original Message-----
From: Paul Eggleton [mailto:paul.eggleton@...]
Sent: Friday, September 28, 2012 11:23 AM
To: Rifenbark, Scott M
Cc: yocto@...
Subject: Re: [yocto] The term Package as used in the YP docs

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


Re: The term Package as used in the YP docs

Paul Eggleton
 

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


The term Package as used in the YP docs

Rifenbark, Scott M <scott.m.rifenbark@...>
 

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 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. PR, PRINC, PV, and PE).

 

 

Scott Rifenbark

Intel Corporation

Yocto Project Documentation

503.712.2702

503.341.0418 (cell)

 


Re: build failure on current

Evade Flow <evadeflow@...>
 

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


Re: build failure on current

Evade Flow <evadeflow@...>
 

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


Re: build failure on current

Paul Eggleton
 

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


Re: build failure on current

Evade Flow <evadeflow@...>
 

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


Re: build failure on current

Paul Eggleton
 

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


Re: build failure on current

Evade Flow <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 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