Date   

Re: per-image ROOTFS sizes

Robert P. J. Day
 

On Wed, 12 Dec 2012, Trevor Woerner wrote:

Hi Darren,

On Wed, Dec 12, 2012 at 2:59 PM, Darren Hart <dvhart@linux.intel.com> wrote:
On 12/11/2012 01:05 PM, Trevor Woerner wrote:
Are per-image ROOTFS sizes (i.e. IMAGE_ROOTFS_SIZE_<image>) still
supported?
Interesting, I haven't tried myself. Have you tried and run into an issue?

Yes. I had been trying to figure out why my:

IMAGE_ROOTFS_SIZE_vmdk = "500000"

line in my config file wasn't working when I found the link I provided
earlier. Right now all I can say is that it doesn't work for _vmdk
specifically.
since i was going to play with vmdk soon, i took a look at this and
from a position of extreme ignorance, i can see image-vmdk.bbclass
(which i'm going to assume is the class being used) which contains:

#inherit image-live
inherit boot-directdisk

create_vmdk_image () {
qemu-img convert -O vmdk ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.hdddirect ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.vmdk
ln -s ${IMAGE_NAME}.vmdk ${DEPLOY_DIR_IMAGE}/${IMAGE_LINK_NAME}.vmdk

}

so my *guess* is that any sort of rootfs size calculation has to come
from boot-directdisk.bbclass, but if you look there, there's no
apparent reference to IMAGE_ROOTFS_SIZE. what you see are numerous
references to BLOCKS and ROOTFSBLOCKS and BOOTDD_EXTRA_SPACE and so
on, with:

ROOTFSBLOCKS=`du -Lbks ${ROOTFS} | cut -f 1`
TOTALSIZE=`expr $BLOCKS + $ROOTFSBLOCKS`
END1=`expr $BLOCKS \* 1024`
END2=`expr $END1 + 512`
END3=`expr \( $ROOTFSBLOCKS \* 1024 \) + $END1`

echo $ROOTFSBLOCKS $TOTALSIZE $END1 $END2 $END3
rm -rf $IMAGE
dd if=/dev/zero of=$IMAGE bs=1024 seek=$TOTALSIZE count=1

parted $IMAGE mklabel msdos
parted $IMAGE mkpart primary fat16 0 ${END1}B
parted $IMAGE unit B mkpart primary ext2 ${END2}B ${END3}B

so what happens if you try to set the appropriate variables above?

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================


Re: Difference of toolchain recipes

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

Thanks Bill,

 

I will put together my draft for the section and send it your way.  You can give it a good technical review.

 

Scott

 

From: Bill Traynor [mailto:wmat@...]
Sent: Wednesday, December 12, 2012 11:37 AM
To: Rifenbark, Scott M
Cc: Mark Hatle; yocto@...
Subject: Re: [yocto] Difference of toolchain recipes

 

I can likely help with this, Scott.

 

On Wed, Dec 12, 2012 at 2:33 PM, Rifenbark, Scott M <scott.m.rifenbark@...> wrote:

Thanks for the feedback Mark.  I will go ahead with it.

Scott


>-----Original Message-----
>From: Mark Hatle [mailto:mark.hatle@...]
>Sent: Wednesday, December 12, 2012 9:08 AM
>To: Rifenbark, Scott M
>Cc: yocto@...
>Subject: Re: [yocto] Difference of toolchain recipes
>

>On 12/11/12 3:20 PM, Rifenbark, Scott M wrote:
>> I think what I am going to do is document these in general as part of
>the "Terms" section in the YP Development Manual where the term "Cross-
>Development Toolchain" is defined.  Would putting such a high-level list
>in the YP documentation be unnecessary or helpful?
>
>I think it would.  The set of compiler/toolchain elements we have is
>definitely
>confusing to someone new.
>
>--Mark
>
>> Scott
>>
>>> -----Original Message-----
>>> From: yocto-bounces@... [mailto:yocto-
>>> bounces@...] On Behalf Of Mark Hatle
>>> Sent: Thursday, December 06, 2012 10:05 AM
>>> To: yocto@...
>>> Subject: Re: [yocto] Difference of toolchain recipes
>>>
>>> On 12/6/12 4:00 AM, Luo Zhenhua-B19537 wrote:
>>>> Can anybody shed some light, please?
>>>>
>>>>
>>>> Best Regards,
>>>>
>>>> Zhenhua
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Luo Zhenhua-B19537
>>>>> Sent: Tuesday, December 04, 2012 11:53 AM
>>>>> To: openembedded-core@...;
>>> 'yocto@...'
>>>>> Subject: Difference of toolchain recipes
>>>>>
>>>>> It is a bit confused for the different recipes of toolchian, can
>>> somebody
>>>>> help to explain what's the difference for those recipes? E.g. gcc-
>>> cross,
>>>>> gcc-cross-canadian, gcc-cross-initial, gcc-cross-intermediate, gcc-
>>>>> crosssdk, gcc-crosssdk-initial, gcc-crosssdk-intermediate, gcc-
>>> runtime,
>>>>> etc.
>>>
>>> gcc-cross-initial - This is the initial compiler needed to bootstrap
>the
>>> toolchain to build software on the host for the target.  (This is a
>>> 'native'
>>> package.)
>>>
>>> gcc-cross-intermediate - This is the second stage of the bootstrap
>>> process to
>>> build software on the host for the target. (This is a 'native'
>package.)
>>>
>>> gcc-cross - this is the the final stage of the bootstrap process, and
>>> results in
>>> the cross compiler to build software on the host for the target.
>(This
>>> is a
>>> 'native' package.)  If you are replacing the cross compiler toolchain
>>> with a
>>> custom version, this is what you must replace.
>>>
>>> gcc-runtime - these are the runtime libraries, but from the toolchain
>>> bootstrapping process.  This results in a 'target' binary.
>>>
>>> gcc-crosssdk-initial/intermediate - stage 1 and 2 of the a cross
>>> compiler to
>>> build from the 'host' to the 'sdk'.  Often the SDK is not the same
>>> target as the
>>> host.  (This is a 'native' binary.)
>>>
>>> gcc-crosssdk - this the final stage of the SDK compiler.  Again, this
>is
>>> to
>>> build on the host, for the sdk.  This is a 'native' binary.
>>>
>>> gcc-cross-canadian - This is the compiler included with the SDK to
>build
>>> on the
>>> SDK machine creating software for the target.  This is an 'nativesdk'
>>> package.
>>>
>>>>> Is there any document for those description?
>>>
>>> Not that I know of.. It's one of those things that you kind of need
>to
>>> know in
>>> order to work with it.  It likely should be documented somewhere
>>> officially.
>>>
>>> --Mark
>>>
>>>>>
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> Zhenhua
>>>>
>>>> _______________________________________________
>>>> yocto mailing list
>>>> yocto@...
>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>>
>>>
>>> _______________________________________________
>>> yocto mailing list
>>> yocto@...
>>> https://lists.yoctoproject.org/listinfo/yocto

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

 


Re: might it be worth explaining BBMASK more comprehensively?

Tim Bird <tim.bird@...>
 

On 12/12/2012 11:53 AM, Robert P. J. Day wrote:
On Wed, 12 Dec 2012, Tim Bird wrote:
I don't know if the .= with leading bar is the optimal
way to append on to BBMASK, but it seems fairly straightforward
to me. I sometimes use the leading ".*" and sometimes not.
it doesn't seem like the leading ".*" makes any difference but
that's the sort of detail that might confuse a reader and should be
explained.

In my setup it seems to not be required, but maybe for flexibility
it should be used. I'm not sure -- it would depend on whether
python re.match or re.search is used for the regex.
Just to answer my own question...

In bitbake in poky-danny-8.0,
(poky-danny-8.0/bitbake/lib/bb/cooker.py)
bbmask_compiled.search() is used, which means that
the leading ".*" is unnecessary. A python re.search()
can match anywhere in the string, while a python re.match()
must match at the beginning of a string. Maybe previous
versions of bitbake used re.match()??

In any event, I would think that it should be considered
best practice to NOT include the leading ".*" in BBMASK
regex fragments.
-- Tim

=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================


Re: might it be worth explaining BBMASK more comprehensively?

Tim Bird <tim.bird@...>
 

On 12/12/2012 11:53 AM, Robert P. J. Day wrote:
On Wed, 12 Dec 2012, Tim Bird wrote:

On 12/12/2012 11:27 AM, Robert P. J. Day wrote:

a bit more pedantry, but is there a more complete example of the use
of BBMASK than the trivial example in the ref and dev manuals?

the ref manual provides this example by way of explanation:

BBMASK = ".*/meta-ti/recipes-misc/"

well, ok, except you occasinally find slight variations like:

BBMASK = "meta-ti/recipes-misc/"

or

BBMASK = "meta-ti/recipes-misc"

given that there are places where a trailing slash is significant,
are all of the above exactly equivalent? if so, that's worth noting.

also, what about an example showing masking out a couple
directories, or perhaps a single recipe from a layer, and so on? at
the moment, the manuals suggest you can mask multiple recipes but
nowhere do i see the reader being given an actual example of how to do
that.
Indeed. These would be good clarifications. The manual says that
this is a single python regular expression. Hence, when masking multiple
directories or recipes, you use a vertical bar to separate the regex fragments.

Here's a particularly complex case I used once:
BBMASK = "meta-ti/recipes-misc|meta-ti/recipes-ti/packagegroup"
BBMASK .= "|.*meta-oe/recipes-support"
#BBMASK .= "|.*openldap"
#BBMASK .= "|.*opencv"
#BBMASK .= "|.*lzma"
BBMASK .= "|meta-oe/recipes-core/packagegroups"
BBMASK .= "|meta-oe/recipes-devtools"
BBMASK .= "|meta-oe/recipes-extended"
BBMASK .= "|meta-oe/recipes-multimedia"
BBMASK .= "|meta-oe/recipes-navigation"
BBMASK .= "|meta-oe/recipes-connectivity"
BBMASK .= "|meta-oe/recipes-graphics"
BBMASK .= "|meta-oe/recipes-qt"

I don't know if the .= with leading bar is the optimal
way to append on to BBMASK, but it seems fairly straightforward
to me. I sometimes use the leading ".*" and sometimes not.
it doesn't seem like the leading ".*" makes any difference but
that's the sort of detail that might confuse a reader and should be
explained.

In my setup it seems to not be required, but maybe for flexibility
it should be used. I'm not sure -- it would depend on wheter
python re.match or re.search is used for the regex.
-- Tim
from your examples above, is this how you mask individual software
recipes?

BBMASK .= "|.*openldap"

that's kind of useful to know.

That's how I do it. I'm not sure if there's some other preferred
method or not. This should catch that name in all layers.
-- Tim


=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================


Re: per-image ROOTFS sizes

Darren Hart <dvhart@...>
 

On 12/12/2012 12:14 PM, Trevor Woerner wrote:
Hi Darren,

On Wed, Dec 12, 2012 at 2:59 PM, Darren Hart <dvhart@linux.intel.com> wrote:
On 12/11/2012 01:05 PM, Trevor Woerner wrote:
Are per-image ROOTFS sizes (i.e. IMAGE_ROOTFS_SIZE_<image>) still
supported?
Interesting, I haven't tried myself. Have you tried and run into an issue?

Yes. I had been trying to figure out why my:

IMAGE_ROOTFS_SIZE_vmdk = "500000"

line in my config file wasn't working when I found the link I provided
earlier. Right now all I can say is that it doesn't work for _vmdk
specifically.
That was:
http://patches.openembedded.org/patch/4671/

What is the reason you would like to do this just for vmdk? Is it to
avoid increasing the size of all the images when it is only vmdk you
care about? That would makes sense. Perhaps, for now, you could limit
the image types you build to just vmdk and increate the size without the
override?

Saul on CC for comment as that was his RFC Patch.

--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel


Re: per-image ROOTFS sizes

Trevor Woerner
 

Hi Darren,

On Wed, Dec 12, 2012 at 2:59 PM, Darren Hart <dvhart@linux.intel.com> wrote:
On 12/11/2012 01:05 PM, Trevor Woerner wrote:
Are per-image ROOTFS sizes (i.e. IMAGE_ROOTFS_SIZE_<image>) still
supported?
Interesting, I haven't tried myself. Have you tried and run into an issue?

Yes. I had been trying to figure out why my:

IMAGE_ROOTFS_SIZE_vmdk = "500000"

line in my config file wasn't working when I found the link I provided
earlier. Right now all I can say is that it doesn't work for _vmdk
specifically.


SRC_URI and appending and a "style guide"?

Robert P. J. Day
 

it's a pedantry-laden day today so i'm going to continue to whine
about aesthetics. what about a yocto style guide for coding style
recommendations? for example, consider the variations:

poky/meta/recipes-support/libcroco/libcroco_0.6.3.bb:SRC_URI_append = " file://croco.patch;apply=yes \
poky/meta/recipes-support/attr/ea-acl.inc:SRC_URI += "file://relative-libdir.patch;striplevel=0 \
poky/meta/recipes-support/db/db_5.3.15.bb:SRC_URI += "file://arm-thumb-mutex_db5.patch;patchdir=.."
poky/meta/recipes-sato/leafpad/leafpad_0.8.18.1.bb:SRC_URI_append_poky = " file://owl-menu.patch;apply=yes "
poky/meta/recipes-sato/puzzles/oh-puzzles_git.bb:SRC_URI_append_poky = " file://oh-puzzles-owl-menu.patch;striplevel=0 "

in the above, you have three different variations for appending to
SRC_URI. i don't think it would be clear to a reader if there was any
difference between "+=" and "_append", other than that "_append"
forces you to add the space yourself while "+=" doesn't. of course,
"_append_poky" is self-explanatory.

so is there a *preferred* form for things like that? is it written
down somewhere? should it be? just because it works for perl doesn't
always mean that "there's more than one way to do it" is a good idea.
:-)

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================


Re: per-image ROOTFS sizes

Darren Hart <dvhart@...>
 

On 12/11/2012 01:05 PM, Trevor Woerner wrote:
Hi,

Are per-image ROOTFS sizes (i.e. IMAGE_ROOTFS_SIZE_<image>) still
supported? From this:

http://patches.openembedded.org/patch/4671/

it would appear not. However
poky-extras/meta-kernel-dev/conf/machine/example.conf contains
IMAGE_ROOTFS_SIZE_ext3 (which would make it appear as though they
are).
Interesting, I haven't tried myself. Have you tried and run into an issue?

--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel


Re: might it be worth explaining BBMASK more comprehensively?

Martin Jansa
 

On Wed, Dec 12, 2012 at 11:42:41AM -0800, Tim Bird wrote:
On 12/12/2012 11:27 AM, Robert P. J. Day wrote:

a bit more pedantry, but is there a more complete example of the use
of BBMASK than the trivial example in the ref and dev manuals?

the ref manual provides this example by way of explanation:

BBMASK = ".*/meta-ti/recipes-misc/"

well, ok, except you occasinally find slight variations like:

BBMASK = "meta-ti/recipes-misc/"

or

BBMASK = "meta-ti/recipes-misc"

given that there are places where a trailing slash is significant,
are all of the above exactly equivalent? if so, that's worth noting.

also, what about an example showing masking out a couple
directories, or perhaps a single recipe from a layer, and so on? at
the moment, the manuals suggest you can mask multiple recipes but
nowhere do i see the reader being given an actual example of how to do
that.
Indeed. These would be good clarifications. The manual says that
this is a single python regular expression. Hence, when masking multiple
directories or recipes, you use a vertical bar to separate the regex fragments.

Here's a particularly complex case I used once:
BBMASK = "meta-ti/recipes-misc|meta-ti/recipes-ti/packagegroup"
BBMASK .= "|.*meta-oe/recipes-support"
#BBMASK .= "|.*openldap"
#BBMASK .= "|.*opencv"
#BBMASK .= "|.*lzma"
BBMASK .= "|meta-oe/recipes-core/packagegroups"
BBMASK .= "|meta-oe/recipes-devtools"
BBMASK .= "|meta-oe/recipes-extended"
BBMASK .= "|meta-oe/recipes-multimedia"
BBMASK .= "|meta-oe/recipes-navigation"
BBMASK .= "|meta-oe/recipes-connectivity"
BBMASK .= "|meta-oe/recipes-graphics"
BBMASK .= "|meta-oe/recipes-qt"

I don't know if the .= with leading bar is the optimal
way to append on to BBMASK, but it seems fairly straightforward
Yes because += would add extra space and break regexp (_append should
probably work too).

Cheers,

--
Martin 'JaMa' Jansa jabber: Martin.Jansa@gmail.com


Re: might it be worth explaining BBMASK more comprehensively?

Robert P. J. Day
 

On Wed, 12 Dec 2012, Tim Bird wrote:

On 12/12/2012 11:27 AM, Robert P. J. Day wrote:

a bit more pedantry, but is there a more complete example of the use
of BBMASK than the trivial example in the ref and dev manuals?

the ref manual provides this example by way of explanation:

BBMASK = ".*/meta-ti/recipes-misc/"

well, ok, except you occasinally find slight variations like:

BBMASK = "meta-ti/recipes-misc/"

or

BBMASK = "meta-ti/recipes-misc"

given that there are places where a trailing slash is significant,
are all of the above exactly equivalent? if so, that's worth noting.

also, what about an example showing masking out a couple
directories, or perhaps a single recipe from a layer, and so on? at
the moment, the manuals suggest you can mask multiple recipes but
nowhere do i see the reader being given an actual example of how to do
that.
Indeed. These would be good clarifications. The manual says that
this is a single python regular expression. Hence, when masking multiple
directories or recipes, you use a vertical bar to separate the regex fragments.

Here's a particularly complex case I used once:
BBMASK = "meta-ti/recipes-misc|meta-ti/recipes-ti/packagegroup"
BBMASK .= "|.*meta-oe/recipes-support"
#BBMASK .= "|.*openldap"
#BBMASK .= "|.*opencv"
#BBMASK .= "|.*lzma"
BBMASK .= "|meta-oe/recipes-core/packagegroups"
BBMASK .= "|meta-oe/recipes-devtools"
BBMASK .= "|meta-oe/recipes-extended"
BBMASK .= "|meta-oe/recipes-multimedia"
BBMASK .= "|meta-oe/recipes-navigation"
BBMASK .= "|meta-oe/recipes-connectivity"
BBMASK .= "|meta-oe/recipes-graphics"
BBMASK .= "|meta-oe/recipes-qt"

I don't know if the .= with leading bar is the optimal
way to append on to BBMASK, but it seems fairly straightforward
to me. I sometimes use the leading ".*" and sometimes not.
it doesn't seem like the leading ".*" makes any difference but
that's the sort of detail that might confuse a reader and should be
explained.

In my setup it seems to not be required, but maybe for flexibility
it should be used. I'm not sure -- it would depend on wheter
python re.match or re.search is used for the regex.
-- Tim
from your examples above, is this how you mask individual software
recipes?

BBMASK .= "|.*openldap"

that's kind of useful to know.

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================


Re: might it be worth explaining BBMASK more comprehensively?

Tim Bird <tim.bird@...>
 

On 12/12/2012 11:27 AM, Robert P. J. Day wrote:

a bit more pedantry, but is there a more complete example of the use
of BBMASK than the trivial example in the ref and dev manuals?

the ref manual provides this example by way of explanation:

BBMASK = ".*/meta-ti/recipes-misc/"

well, ok, except you occasinally find slight variations like:

BBMASK = "meta-ti/recipes-misc/"

or

BBMASK = "meta-ti/recipes-misc"

given that there are places where a trailing slash is significant,
are all of the above exactly equivalent? if so, that's worth noting.

also, what about an example showing masking out a couple
directories, or perhaps a single recipe from a layer, and so on? at
the moment, the manuals suggest you can mask multiple recipes but
nowhere do i see the reader being given an actual example of how to do
that.
Indeed. These would be good clarifications. The manual says that
this is a single python regular expression. Hence, when masking multiple
directories or recipes, you use a vertical bar to separate the regex fragments.

Here's a particularly complex case I used once:
BBMASK = "meta-ti/recipes-misc|meta-ti/recipes-ti/packagegroup"
BBMASK .= "|.*meta-oe/recipes-support"
#BBMASK .= "|.*openldap"
#BBMASK .= "|.*opencv"
#BBMASK .= "|.*lzma"
BBMASK .= "|meta-oe/recipes-core/packagegroups"
BBMASK .= "|meta-oe/recipes-devtools"
BBMASK .= "|meta-oe/recipes-extended"
BBMASK .= "|meta-oe/recipes-multimedia"
BBMASK .= "|meta-oe/recipes-navigation"
BBMASK .= "|meta-oe/recipes-connectivity"
BBMASK .= "|meta-oe/recipes-graphics"
BBMASK .= "|meta-oe/recipes-qt"

I don't know if the .= with leading bar is the optimal
way to append on to BBMASK, but it seems fairly straightforward
to me. I sometimes use the leading ".*" and sometimes not.
In my setup it seems to not be required, but maybe for flexibility
it should be used. I'm not sure -- it would depend on wheter
python re.match or re.search is used for the regex.
-- Tim


=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================


Strange error with missing "meta-yocto" in bblayers

Darren Hart <dvhart@...>
 

When trying to build a machine I had not built in a while, I got the
following error:

$ bitbake core-image-minimal
Pseudo is not present but is required, building this first before the
main build
NOTE: Your conf/bblayers.conf has been automatically updated. Please
re-run bitbake
.
mkdir: cannot create directory `/../../var/pseudo': Permission denied
/home/dvhart/source/poky/scripts/bitbake: line 178: /pseudo: No such
file or direct
ory

It turns out I had "meta" and "meta-yocto-bsp" in bblayers, but not
"meta-yocto". The error wasn't at all helpful, but I figured it had to
be something in my configuration. Would there be someway to better
articulate to the user what the failure actually was?

--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel


Re: might it be worth explaining BBMASK more comprehensively?

Robert P. J. Day
 

On Wed, 12 Dec 2012, Rifenbark, Scott M wrote:

Please feel free (anyone) to provide some useful examples and a bit
of explanation for each and I will be happy to get them in the
manual(s).
i forgot to mention this snippet i ran across in the meta-angstrom
layer's contrib/local.conf:

BBFILES := "/OE/org.openembedded.dev/recipes/*/*.bb"
BBMASK = ""

that combination isn't something that appears to be explained anywhere
and some readers might wonder what it means to explicitly set BBFILES
and clear BBMASK.

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================


Re: Difference of toolchain recipes

Bill Traynor <wmat@...>
 

I can likely help with this, Scott.


On Wed, Dec 12, 2012 at 2:33 PM, Rifenbark, Scott M <scott.m.rifenbark@...> wrote:
Thanks for the feedback Mark.  I will go ahead with it.

Scott

>-----Original Message-----
>From: Mark Hatle [mailto:mark.hatle@...]
>Sent: Wednesday, December 12, 2012 9:08 AM
>To: Rifenbark, Scott M
>Cc: yocto@...
>Subject: Re: [yocto] Difference of toolchain recipes
>
>On 12/11/12 3:20 PM, Rifenbark, Scott M wrote:
>> I think what I am going to do is document these in general as part of
>the "Terms" section in the YP Development Manual where the term "Cross-
>Development Toolchain" is defined.  Would putting such a high-level list
>in the YP documentation be unnecessary or helpful?
>
>I think it would.  The set of compiler/toolchain elements we have is
>definitely
>confusing to someone new.
>
>--Mark
>
>> Scott
>>
>>> -----Original Message-----
>>> From: yocto-bounces@... [mailto:yocto-
>>> bounces@...] On Behalf Of Mark Hatle
>>> Sent: Thursday, December 06, 2012 10:05 AM
>>> To: yocto@...
>>> Subject: Re: [yocto] Difference of toolchain recipes
>>>
>>> On 12/6/12 4:00 AM, Luo Zhenhua-B19537 wrote:
>>>> Can anybody shed some light, please?
>>>>
>>>>
>>>> Best Regards,
>>>>
>>>> Zhenhua
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Luo Zhenhua-B19537
>>>>> Sent: Tuesday, December 04, 2012 11:53 AM
>>>>> To: openembedded-core@...;
>>> 'yocto@...'
>>>>> Subject: Difference of toolchain recipes
>>>>>
>>>>> It is a bit confused for the different recipes of toolchian, can
>>> somebody
>>>>> help to explain what's the difference for those recipes? E.g. gcc-
>>> cross,
>>>>> gcc-cross-canadian, gcc-cross-initial, gcc-cross-intermediate, gcc-
>>>>> crosssdk, gcc-crosssdk-initial, gcc-crosssdk-intermediate, gcc-
>>> runtime,
>>>>> etc.
>>>
>>> gcc-cross-initial - This is the initial compiler needed to bootstrap
>the
>>> toolchain to build software on the host for the target.  (This is a
>>> 'native'
>>> package.)
>>>
>>> gcc-cross-intermediate - This is the second stage of the bootstrap
>>> process to
>>> build software on the host for the target. (This is a 'native'
>package.)
>>>
>>> gcc-cross - this is the the final stage of the bootstrap process, and
>>> results in
>>> the cross compiler to build software on the host for the target.
>(This
>>> is a
>>> 'native' package.)  If you are replacing the cross compiler toolchain
>>> with a
>>> custom version, this is what you must replace.
>>>
>>> gcc-runtime - these are the runtime libraries, but from the toolchain
>>> bootstrapping process.  This results in a 'target' binary.
>>>
>>> gcc-crosssdk-initial/intermediate - stage 1 and 2 of the a cross
>>> compiler to
>>> build from the 'host' to the 'sdk'.  Often the SDK is not the same
>>> target as the
>>> host.  (This is a 'native' binary.)
>>>
>>> gcc-crosssdk - this the final stage of the SDK compiler.  Again, this
>is
>>> to
>>> build on the host, for the sdk.  This is a 'native' binary.
>>>
>>> gcc-cross-canadian - This is the compiler included with the SDK to
>build
>>> on the
>>> SDK machine creating software for the target.  This is an 'nativesdk'
>>> package.
>>>
>>>>> Is there any document for those description?
>>>
>>> Not that I know of.. It's one of those things that you kind of need
>to
>>> know in
>>> order to work with it.  It likely should be documented somewhere
>>> officially.
>>>
>>> --Mark
>>>
>>>>>
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> Zhenhua
>>>>
>>>> _______________________________________________
>>>> yocto mailing list
>>>> yocto@...
>>>> https://lists.yoctoproject.org/listinfo/yocto
>>>>
>>>
>>> _______________________________________________
>>> yocto mailing list
>>> yocto@...
>>> https://lists.yoctoproject.org/listinfo/yocto

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


Re: should users be able to run yocto's pre-built images standalone?

Robert P. J. Day
 

On Tue, 11 Dec 2012, Rudolf Streif wrote:

Hi Robert,



a basic question -- is it supported that users be able to download and
run yocto's pre-built QEMU images without having to download an entire
build system, and set up bitbake, etc?  theoretically, of course, it
can be done, but it's not set up to do it conveniently (if it even
should be).


IMHO that is exactly what the ADT installer does. OK, it could use
some enhancements but it lets you specify what pre-built images you
would like to use and sets it up, including QEMU and the related
scripts.  
ok, i haven't poked around there yet, i'll look at that later.

  first, one can't get yocto's qemu-related utilities without
downloading either oe-core or a toolchain.  is that really necessary?
how hard would it be to break out the QEMU stuff into a much smaller
tarball if that's all people want?


I think you want at least QEMU, the scripts, the user-space NFS
server and the cross-toolchain. Quite frankly, what do you really do
with just QEMU, scripts and images? Either you want to build your
own images then you need Poky (the build system) or you want to do
user-space development then you need images and a cross-toolchain.
Just booting an image into QEMU seems quite boring to me. 
good point ... i originally envisioned someone perhaps wanting to do
nothing more than just downloading and running the pre-built images to
see what all the fuss was about. if that's really not considered a
useful example, i'll forget about it.

  and if that's done, certainly, the help messages from runqemu can be
updated, since those utilities clearly assume they're running as part
of a build infrastructure when that's not necessary.

Fair enough, but if you could provide more details outlining what
the error message said, what the root cause of the problem was, and
what you think the error message should say, it would really help
the developers to make the improvements. Unless you are inclined to
rummage through the code, fix it and submit patches.
ah, that i can provide. in the runqemu usage message, you see the
suggestion:

$MYNAME qemux86-64 core-image-sato ext3"

but that assumes you're in a build directory. of course, using the
adt-installer as you suggested might make all this moot.

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================


Re: Difference of toolchain recipes

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

Thanks for the feedback Mark. I will go ahead with it.

Scott

-----Original Message-----
From: Mark Hatle [mailto:mark.hatle@windriver.com]
Sent: Wednesday, December 12, 2012 9:08 AM
To: Rifenbark, Scott M
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Difference of toolchain recipes

On 12/11/12 3:20 PM, Rifenbark, Scott M wrote:
I think what I am going to do is document these in general as part of
the "Terms" section in the YP Development Manual where the term "Cross-
Development Toolchain" is defined. Would putting such a high-level list
in the YP documentation be unnecessary or helpful?

I think it would. The set of compiler/toolchain elements we have is
definitely
confusing to someone new.

--Mark

Scott

-----Original Message-----
From: yocto-bounces@yoctoproject.org [mailto:yocto-
bounces@yoctoproject.org] On Behalf Of Mark Hatle
Sent: Thursday, December 06, 2012 10:05 AM
To: yocto@yoctoproject.org
Subject: Re: [yocto] Difference of toolchain recipes

On 12/6/12 4:00 AM, Luo Zhenhua-B19537 wrote:
Can anybody shed some light, please?


Best Regards,

Zhenhua


-----Original Message-----
From: Luo Zhenhua-B19537
Sent: Tuesday, December 04, 2012 11:53 AM
To: openembedded-core@lists.openembedded.org;
'yocto@yoctoproject.org'
Subject: Difference of toolchain recipes

It is a bit confused for the different recipes of toolchian, can
somebody
help to explain what's the difference for those recipes? E.g. gcc-
cross,
gcc-cross-canadian, gcc-cross-initial, gcc-cross-intermediate, gcc-
crosssdk, gcc-crosssdk-initial, gcc-crosssdk-intermediate, gcc-
runtime,
etc.
gcc-cross-initial - This is the initial compiler needed to bootstrap
the
toolchain to build software on the host for the target. (This is a
'native'
package.)

gcc-cross-intermediate - This is the second stage of the bootstrap
process to
build software on the host for the target. (This is a 'native'
package.)

gcc-cross - this is the the final stage of the bootstrap process, and
results in
the cross compiler to build software on the host for the target.
(This
is a
'native' package.) If you are replacing the cross compiler toolchain
with a
custom version, this is what you must replace.

gcc-runtime - these are the runtime libraries, but from the toolchain
bootstrapping process. This results in a 'target' binary.

gcc-crosssdk-initial/intermediate - stage 1 and 2 of the a cross
compiler to
build from the 'host' to the 'sdk'. Often the SDK is not the same
target as the
host. (This is a 'native' binary.)

gcc-crosssdk - this the final stage of the SDK compiler. Again, this
is
to
build on the host, for the sdk. This is a 'native' binary.

gcc-cross-canadian - This is the compiler included with the SDK to
build
on the
SDK machine creating software for the target. This is an 'nativesdk'
package.

Is there any document for those description?
Not that I know of.. It's one of those things that you kind of need
to
know in
order to work with it. It likely should be documented somewhere
officially.

--Mark



Best Regards,

Zhenhua
_______________________________________________
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: might it be worth explaining BBMASK more comprehensively?

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

Please feel free (anyone) to provide some useful examples and a bit of explanation for each and I will be happy to get them in the manual(s).

Scott

-----Original Message-----
From: yocto-bounces@yoctoproject.org [mailto:yocto-
bounces@yoctoproject.org] On Behalf Of Robert P. J. Day
Sent: Wednesday, December 12, 2012 11:27 AM
To: Yocto discussion list
Subject: [yocto] might it be worth explaining BBMASK more
comprehensively?


a bit more pedantry, but is there a more complete example of the use
of BBMASK than the trivial example in the ref and dev manuals?

the ref manual provides this example by way of explanation:

BBMASK = ".*/meta-ti/recipes-misc/"

well, ok, except you occasinally find slight variations like:

BBMASK = "meta-ti/recipes-misc/"

or

BBMASK = "meta-ti/recipes-misc"

given that there are places where a trailing slash is significant,
are all of the above exactly equivalent? if so, that's worth noting.

also, what about an example showing masking out a couple
directories, or perhaps a single recipe from a layer, and so on? at
the moment, the manuals suggest you can mask multiple recipes but
nowhere do i see the reader being given an actual example of how to do
that.

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto


might it be worth explaining BBMASK more comprehensively?

Robert P. J. Day
 

a bit more pedantry, but is there a more complete example of the use
of BBMASK than the trivial example in the ref and dev manuals?

the ref manual provides this example by way of explanation:

BBMASK = ".*/meta-ti/recipes-misc/"

well, ok, except you occasinally find slight variations like:

BBMASK = "meta-ti/recipes-misc/"

or

BBMASK = "meta-ti/recipes-misc"

given that there are places where a trailing slash is significant,
are all of the above exactly equivalent? if so, that's worth noting.

also, what about an example showing masking out a couple
directories, or perhaps a single recipe from a layer, and so on? at
the moment, the manuals suggest you can mask multiple recipes but
nowhere do i see the reader being given an actual example of how to do
that.

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================


Re: Disabling PREMIRRORS and upstream sources

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

If this is something we would not encourage in a published recipe, then it is questionable as to documenting this simple way. Or, perhaps, document it with the caveat that it is not something you would normally do?

Scott

-----Original Message-----
From: Paul Eggleton [mailto:paul.eggleton@linux.intel.com]
Sent: Wednesday, December 12, 2012 8:49 AM
To: Jon Szymaniak
Cc: Rifenbark, Scott M; yocto@yoctoproject.org
Subject: Re: [yocto] Disabling PREMIRRORS and upstream sources

On Wednesday 12 December 2012 11:32:39 Jon Szymaniak wrote:
Just to make sure I'm understanding this... so when I place PREMIRRORS
= ""
in a recipe, I see that it doesn't affect the associated variables in
other
recipes.

Is this because I'm inherently setting up PREMIRRORS_${PN}, which is
initialized with the PREMIRROR defaults (and what was appended and
prepended in the local.conf)?
When you set a variable within a recipe it's setting it just within the
context of that recipe, so there's no way for it to affect other
recipes.

I'm also guessing that touching PREMIRRORS and MIRRORS within recipes
is generally a bad practice. I'd be curious to hear if my use case
sounds totally
wacky, as I'm still very much getting up to speed on Yocto/OE and best
practices.
I guess it's not unreasonable to want to avoid touching anything
external when
building something internal; but you're right as a general practice this
is
something we would not do in published recipes.

Cheers,
Paul

--

Paul Eggleton
Intel Open Source Technology Centre


Re: adding package management

Mark Hatle <mark.hatle@...>
 

On 12/12/12 6:07 AM, Tim Coote wrote:
ok. Thanks.

just spotted the split between rpm / rpm5 and yum. I suppose that the knock on is managing multiple repos for different update managers.

don't suppose you know if there are material differences from a packaging/dependency point of view between rpm4 and rpm5?
Generated packages are more or less compatible. The only big difference is that all RPM5 packages are 'self-signed' to integrity purposes. Self-signing is better then simply md5sums. (They of course can also be signed with a specific key to indicate trust as well.)

But the primary difference is in cross compiling and support for the activities that we need when cross-constructing root filesystems and such. There is also an aspect of 'control' behind this. We have input into the RPM5 development, in RPM4 we have absolutely no influence and they have removed everything that helped in a cross-compiled environment after the split.

is there an eta for smart in the mainstream core?
Hopefully the next version of the integration patches should be sent up today. We're really trying to get the code in by next week.

--Mark

On 12 Dec 2012, at 11:43, "Burton, Ross" <ross.burton@intel.com> wrote:

On 12 December 2012 11:31, Tim Coote <tim+yoctoproject.org@coote.org> wrote:
Am I right in thinking that yum isn't in the standard recipes?
Yum, no. Zypper is in oe-core and is used when you construct a RPM-based image.

(note that Zypper is being replaced by Smart in oe-core master)

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