[yocto] ref manual: what means "package_deploy-rpm"?

[Robert P. J. Day]

  too tired to go track this down so i'll beg for an explanation --
section 4.3.4.2 in ref manual:

"The result of the change should be that all the package,
package_write_rpm, and package_deploy-rpm shared state cache items
would become invalid."

  "package_deploy-rpm"?

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

Re: [yocto] architecture mismatch during kernel build (40 to 3)

[Bruce Ashfield]

On 13-11-05 8:08 PM, Maxwell Bottiger wrote:

Turns out this is a phantom error.  Instead of building mkimage, I had
accidentally added it to my git master branch, but deleted it from my
local copy.  I didn't see it for the longest time, but the whole project
compiled correctly as soon as I removed the binary from the git repo.



Fantastic. I was poking around in my ARM and powerpc builds today, and
couldn't for the life of me see how you managed to build mkimage as
part of a typical build.

I had a half composed email asking for details .. it seems I don't have
to send it now :)

Bruce


Woops.

-Max




On Tue, Nov 5, 2013 at 12:46 PM, Maxwell Bottiger
mailto:sleepyli...@jive-turkey.net>> wrote:

Ok.  so, I should backtrack a bit, just so I understand the issue
completely.  This is my first time putting together a bitbake
recipe, and the kernel is a complex little beastie.

BTW, I'm building for an Atmel ARM cpu.  Sorry didn't mention that
in my first message.

So, when I was building my kernel by hand, here's what I was doing:
make ARCH=arm at91sam9x5ek_defconfig
make ARCH=arm menuconfig
make ARCH=arm
./mkimage -A arm -O linux -C none -T kernel -a 20008000 -e 20008000
-n linux-2.6 -d arch/arm/boot/zImage uImage-2.6.39-at91sam9x5ek.bin

I took the .config file that I'd been using and placed it in
depconfig, then added a line to my bb file to include that
configuration.  So, that's good I think.

When the compile is complete, I should have an arm zImage, and
mkimage should run against that.  So, my understanding would be that
mkimage should be an x86 executable, and the kernel should be an
arm, and mkimage should generate a uImage kernel.  So, the complaint
from do_package that the executables are different architectures
makes sense.

Bruce, I think what you're recommending I do is remove mkImage after
the compile and image creation are complete but before packaging
takes place, as that's where the QA is complaining.  (Which makes a
lot of sense)  I just want to list the details so I'm sure I
understand the problem completely.

To this end I've added a do_install_append to the end of my recipe
to remove the mkImage file.  I tried it a couple of different times,
but it looks like I'm seeing the same error message each time.  I
think the issue is I just don't understand the bb process well
enough.  Maybe I'm trying to delete the file at the wrong stage, or
maybe there's something system specific I don't know about.  I
copied the guts of this recipe from a linux-yocto-custom_3.6 bb
file, which compiled cleanly for this chip.  I'll list the bb recipe
below.  Any advice is greatly appreciated.

linux-yocto-custom_2.6.39.bb 
-
inherit kernel
require recipes-kernel/linux/linux-yocto.inc

LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
#DEFAULT_PREFERENCE = "-1"


LINUX_VERSION = "2.6.39"
LINUX_VERSION_EXTENSION ?= "-custom"
KBRANCH = "master"
META = "meta"


SRC_URI =
"git:///home/blah/blah/blah/linux-2.6.39;protocol=file;branch=master"
SRC_URI += "file://defconfig"
#SRC_URI += "file://extra-cflags-override.patch"

KERNEL_EXTRA_ARGS="LOADADDR=0x200  V=1
KCFLAGS=-mno-unaligned-access"


UBOOT_ENTRYPOINT="200"

SRCREV="master"


PV = "${LINUX_VERSION}"

PR = "r1"

S = "${WORKDIR}/git"
EXTRA_OEMAKE = "${PARALLEL_MAKE}"

KERNEL_IMAGETYPE = "uImage"


# Override COMPATIBLE_MACHINE to include your machine in a bbappend
# file. Leaving it empty here ensures an early explicit build failure.
#COMPATIBLE_MACHINE = "(xo1-mvs)"
COMPATIBLE_MACHINE = "(sama5d3xek|at91sam9x5ek)"

# clean up after module installation
do_install_append() {
 rm -f mkimage

}


On Mon, Nov 4, 2013 at 11:28 PM, Bruce Ashfield
mailto:bruce.ashfi...@windriver.com>>
wrote:

On 13-11-04 8:41 PM, Maxwell Bottiger wrote:

I'm building a custom kernel, and I think I'm nearly there.
  I'm seeing
an error when running mkimage.  bitbake is complaining about an
architecure mismatch, but I don't know which files it is
comparing, or
if the mismatch really matters (32bit x86 vs 64bit x86 or
whatever)

Here's the error string:

WARNING: File '/usr/src/kernel/mkimage' from
linux-yocto-custom was
already stripped, this will prevent future debugging!

ERROR: QA Issue: Architecture did not match (40 to 3) on

/work/at91sam9x5ek-poky-linux-__gnueabi/linux-yocto-custom/2.__6.39-r1/packages-split/kernel-__dev/usr/src/kernel/mkimage


The obvious answer is .. it is mkimage that it is complaining

Re: [yocto] architecture mismatch during kernel build (40 to 3)

[Maxwell Bottiger]

Turns out this is a phantom error.  Instead of building mkimage, I had
accidentally added it to my git master branch, but deleted it from my local
copy.  I didn't see it for the longest time, but the whole project compiled
correctly as soon as I removed the binary from the git repo.

Woops.

-Max




On Tue, Nov 5, 2013 at 12:46 PM, Maxwell Bottiger <
sleepyli...@jive-turkey.net> wrote:

> Ok.  so, I should backtrack a bit, just so I understand the issue
> completely.  This is my first time putting together a bitbake recipe, and
> the kernel is a complex little beastie.
>
> BTW, I'm building for an Atmel ARM cpu.  Sorry didn't mention that in my
> first message.
>
> So, when I was building my kernel by hand, here's what I was doing:
> make ARCH=arm at91sam9x5ek_defconfig
> make ARCH=arm menuconfig
> make ARCH=arm
> ./mkimage -A arm -O linux -C none -T kernel -a 20008000 -e 20008000 -n
> linux-2.6 -d arch/arm/boot/zImage uImage-2.6.39-at91sam9x5ek.bin
>
> I took the .config file that I'd been using and placed it in depconfig,
> then added a line to my bb file to include that configuration.  So, that's
> good I think.
>
> When the compile is complete, I should have an arm zImage, and mkimage
> should run against that.  So, my understanding would be that mkimage should
> be an x86 executable, and the kernel should be an arm, and mkimage should
> generate a uImage kernel.  So, the complaint from do_package that the
> executables are different architectures makes sense.
>
> Bruce, I think what you're recommending I do is remove mkImage after the
> compile and image creation are complete but before packaging takes place,
> as that's where the QA is complaining.  (Which makes a lot of sense)  I
> just want to list the details so I'm sure I understand the problem
> completely.
>
> To this end I've added a do_install_append to the end of my recipe to
> remove the mkImage file.  I tried it a couple of different times, but it
> looks like I'm seeing the same error message each time.  I think the issue
> is I just don't understand the bb process well enough.  Maybe I'm trying to
> delete the file at the wrong stage, or maybe there's something system
> specific I don't know about.  I copied the guts of this recipe from a
> linux-yocto-custom_3.6 bb file, which compiled cleanly for this chip.  I'll
> list the bb recipe below.  Any advice is greatly appreciated.
>
> linux-yocto-custom_2.6.39.bb
> -
> inherit kernel
> require recipes-kernel/linux/linux-yocto.inc
>
> LICENSE = "GPLv2"
> LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
> #DEFAULT_PREFERENCE = "-1"
>
>
> LINUX_VERSION = "2.6.39"
> LINUX_VERSION_EXTENSION ?= "-custom"
> KBRANCH = "master"
> META = "meta"
>
>
> SRC_URI =
> "git:///home/blah/blah/blah/linux-2.6.39;protocol=file;branch=master"
> SRC_URI += "file://defconfig"
> #SRC_URI += "file://extra-cflags-override.patch"
>
> KERNEL_EXTRA_ARGS="LOADADDR=0x200  V=1 KCFLAGS=-mno-unaligned-access"
>
>
> UBOOT_ENTRYPOINT="200"
>
> SRCREV="master"
>
>
> PV = "${LINUX_VERSION}"
>
> PR = "r1"
>
> S = "${WORKDIR}/git"
> EXTRA_OEMAKE = "${PARALLEL_MAKE}"
>
> KERNEL_IMAGETYPE = "uImage"
>
>
> # Override COMPATIBLE_MACHINE to include your machine in a bbappend
> # file. Leaving it empty here ensures an early explicit build failure.
> #COMPATIBLE_MACHINE = "(xo1-mvs)"
> COMPATIBLE_MACHINE = "(sama5d3xek|at91sam9x5ek)"
>
> # clean up after module installation
> do_install_append() {
> rm -f mkimage
>
> }
>
>
> On Mon, Nov 4, 2013 at 11:28 PM, Bruce Ashfield <
> bruce.ashfi...@windriver.com> wrote:
>
>> On 13-11-04 8:41 PM, Maxwell Bottiger wrote:
>>
>>> I'm building a custom kernel, and I think I'm nearly there.  I'm seeing
>>> an error when running mkimage.  bitbake is complaining about an
>>> architecure mismatch, but I don't know which files it is comparing, or
>>> if the mismatch really matters (32bit x86 vs 64bit x86 or whatever)
>>>
>>> Here's the error string:
>>>
>>> WARNING: File '/usr/src/kernel/mkimage' from linux-yocto-custom was
>>> already stripped, this will prevent future debugging!
>>>
>>> ERROR: QA Issue: Architecture did not match (40 to 3) on
>>> /work/at91sam9x5ek-poky-linux-gnueabi/linux-yocto-custom/2.
>>> 6.39-r1/packages-split/kernel-dev/usr/src/kernel/mkimage
>>>
>>
>> The obvious answer is .. it is mkimage that it is complaining about. You
>> are packaging mkimage (which is likely an x86 elf file) into your
>> kernel-dev package (which is your target arch, likely powerpc or ARM).
>> Hence the QA error.
>>
>> In your kernel recipe, you can remove the file before packaging
>> (i.e. in the do_install_append) or inhibit the QA check for your recipe.
>>
>> What exactly does your kernel recipe look like ? What is building mkimage
>> and then getting it installed into /usr/src/kernel ?
>>
>> My suggestion is to track that down, versus inhibiting the QA check.
>>
>> Bruce
>>
>>
>>> ERROR: QA run found fatal errors. Please consider f

[yocto] Minutes: Yocto Project Technical Team Meeting - Tuesday, November 05, 2013 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US & Canada).

[Liu, Song]

Attendees:
Matthew, Björn, Beth, Nitin, MichaelH, ScottR, Denys, Richard, JeffP, TomZ, 
Cristiana, PaulE, AlexD, Bruce, Darren, RandyM, Saul, AlexG, Jessica, Ross, Song

Agenda:

* Opens collection - 5 min (Song)
* Yocto 1.6 status - 10 min (Song/team)
  https://wiki.yoctoproject.org/wiki/Yocto_1.6_Features
  - Most of the features are in. Still a couple more being worked on. We have 
the end of this week to complete 1.6 planning.
  - Randy: build system infrastructure to identify problems. We have a hefty 
build system, running build on oe-core. Several hundred different distros. Many 
bugs open. Various debugging, configuration, various BSPs, build tests, etc. We 
use a different build system. Scope of machines >10 < 100.
. RP: We have autobuilder running builds, we have auto testing framework in 
place for 1.5 (virtual testing), trying to add real hardware testing. Working 
on self testing too for 1.6. Welcome the community to work with our team 
together.
* SWAT team rotation: Laurentiu Palcu -> Nitin.
* Opens - 10 min
  Beth: AB downtime.
- Making some AB changes on configuration files, new things on git clone. 
Have some testing to do tonight, Anyone seeing any failures in the next 12 
hours, let me know. Downtime will happen in the next 8 hours (8 hours testing 
time).
- Michael: we have a huge storage upgrade, copying file to new ones. 
Downtime in the future for this for about 4 hours. Friday will be a good time. 
16 disk arrays to 24 disk arrays.
* Team Sharing - 20 min
  - Randy: Any plan to add Clang? open source compiler. Developed by Apple. 
Qualcomm is working on it.  RP: there are lots of other things. Not hearing 
from tens of users on this. Welcome others to contribute.


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

Re: [yocto] SRCREV how is it supposed to work?

[Hans Beckerus]

On 2013-11-05 11:10, Robert Calhoun wrote:
> -Original Message-
> From: Paul Eggleton 
>> AFAIK, there are two recommended values for SRCREV assuming you are
>> fetching 
> >from an SCM at all:
>> A) A specific revision (SHA1 hash when fetching from git)
>>
>> or
>>
>> B) "${AUTOREV}" if you want to always build the latest version available
>> at 
>> time of building. If you want to build the latest version from a branch,
>> specify it in branch= in the SRC_URI entry.
>>
>> Anything else isn't really a good idea. Sometimes I wonder if we ought to
>> just 
>> tighten this up so that only settings that make sense can be set.
> The current behavior is a little non-intuitive, since using SRCREV =
> "${AUTOREV}" 
> alone will not force the package to be rebuilt when SRCREV changes. Unless
> I am
> mistaken, $PV needs to be modified also. But modifying $PV causes its own
> headaches with patching, so I've ended up using recipes based on the model
> below.
>
> Another challenge is that bitbake's fetch2 is not very well documented. I
> don't
> think the "user" and "pswd" fields for the svn fetcher are documented
> anywhere
> outside of the source code.
>
> I'd love to help address this, but I'm not sure where I should submit
> updated documentation. Is this the right place?
>
> git://git.yoctoproject.org/yocto-docs
>
>
> Hans, below is a model recipe for building current head-of-line from a
> subversion repository:
A good example indeed. I will see what I can make out of it in our own recipes.
I also realized the caveats attached to finding the patch dir etc. when 
auto-incrementing the version.
This will certainly help.

Thanks.
Hans

> -Rob Calhoun
> SST Inc
>  
>
>
>
> ##
>
> DESCRIPTION = "example_1.0.bb, autorevving checkout example"
>
> # This says look for LICENSE in the root of the directory being checked
> out. Fix
> # license filename and md5sum as required.
> LIC_FILES_CHKSUM = "file://LICENSE;md5=abc123"
>
> # this is the rev of your recipe. Bumping it will toss the cache and redo
> everything
> PR = "r1"
>
> # pick up latest svn rev for this module. Note this a deferred evaluation!
> SRCREV = "${AUTOREV}"
>
> # ${PV} is pulled from the recipe filename, e.g. helloworld_2.7.bb ->
> ${PV} expands to "2.7".
> # We use immediate evaluation to define a new var PVBASE holding the
> original value of ${PV}.
> PVBASE := "${PV}"
>
> # We need to tell bitbake about our current directory structure or we
> won't be able to find patches after we mess with ${PV}
> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PVBASE}:"
>
> # Then redefine PV to tack the svn rev onto the base version. This is
> evaluated at fetch time.
> # Then the package will get rebuilt any time the relevant part of the
> source tree changes.
> PV = "${PVBASE}.${SRCPV}"
>
> # Now we format the source code URI.
> # There is nothing special about "module"; it is just the final directory
> of the svn checkout.
> # SRC_URI below is equivalent to the svn command:
> # "svn checkout --username=poky --password=xyzzy
> https://svn.example.com/repo/trunk/example";
> #
> SRC_URI= 
> "svn://svn.example.com/repo/trunk;module=example;protocol=https;user=poky;p
> swd=xyzzy"
>
> # build will fail without this; it specifies where in the workdir to find
> the source. The
> # name must be the same as the "module" name in SRC_URI.
> S = "${WORKDIR}/example"
>
> # BELOW NOT PART OF RECIPE; IT SHOWS WHAT THE WORK DIR LOOKS LIKE WITH
> THIS RECIPE.
> # By setting PV, the cache is invalidated and new code checked out each
> time the 
> # relevant part oF the svn repo gets updated because I've made the svn
> revision look
> # like a package version number to bitbake.
> #
> # Here is a directory listing of the work dir:
> #
> # 
> poky@build:/poky/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/example$
>  ls -l
> #drwxrwxr-x 12 poky poky 4096 Oct 30 10:17 1.0.57400-r1
> #drwxrwxr-x 12 poky poky 4096 Oct 30 11:52 1.0.57401-r1
> #drwxrwxr-x 12 poky poky 4096 Oct 31 12:37 1.0.57408-r1
> #drwxrwxr-x 12 poky poky 4096 Nov  1 07:56 1.0.57412-r1
>
>
>
>

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

Re: [yocto] SRCREV how is it supposed to work?

[Robert Calhoun]

-Original Message-
From: Paul Eggleton 
>
>AFAIK, there are two recommended values for SRCREV assuming you are
>fetching 
>from an SCM at all:
>
>A) A specific revision (SHA1 hash when fetching from git)
>
>or
>
>B) "${AUTOREV}" if you want to always build the latest version available
>at 
>time of building. If you want to build the latest version from a branch,
>specify it in branch= in the SRC_URI entry.
>
>Anything else isn't really a good idea. Sometimes I wonder if we ought to
>just 
>tighten this up so that only settings that make sense can be set.

The current behavior is a little non-intuitive, since using SRCREV =
"${AUTOREV}" 
alone will not force the package to be rebuilt when SRCREV changes. Unless
I am
mistaken, $PV needs to be modified also. But modifying $PV causes its own
headaches with patching, so I've ended up using recipes based on the model
below.

Another challenge is that bitbake's fetch2 is not very well documented. I
don't
think the "user" and "pswd" fields for the svn fetcher are documented
anywhere
outside of the source code.

I'd love to help address this, but I'm not sure where I should submit
updated documentation. Is this the right place?

git://git.yoctoproject.org/yocto-docs


Hans, below is a model recipe for building current head-of-line from a
subversion repository:

-Rob Calhoun
SST Inc
 



##

DESCRIPTION = "example_1.0.bb, autorevving checkout example"

# This says look for LICENSE in the root of the directory being checked
out. Fix
# license filename and md5sum as required.
LIC_FILES_CHKSUM = "file://LICENSE;md5=abc123"

# this is the rev of your recipe. Bumping it will toss the cache and redo
everything
PR = "r1"

# pick up latest svn rev for this module. Note this a deferred evaluation!
SRCREV = "${AUTOREV}"

# ${PV} is pulled from the recipe filename, e.g. helloworld_2.7.bb ->
${PV} expands to "2.7".
# We use immediate evaluation to define a new var PVBASE holding the
original value of ${PV}.
PVBASE := "${PV}"

# We need to tell bitbake about our current directory structure or we
won't be able to find patches after we mess with ${PV}
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PVBASE}:"

# Then redefine PV to tack the svn rev onto the base version. This is
evaluated at fetch time.
# Then the package will get rebuilt any time the relevant part of the
source tree changes.
PV = "${PVBASE}.${SRCPV}"

# Now we format the source code URI.
# There is nothing special about "module"; it is just the final directory
of the svn checkout.
# SRC_URI below is equivalent to the svn command:
# "svn checkout --username=poky --password=xyzzy
https://svn.example.com/repo/trunk/example";
#
SRC_URI= 
"svn://svn.example.com/repo/trunk;module=example;protocol=https;user=poky;p
swd=xyzzy"

# build will fail without this; it specifies where in the workdir to find
the source. The
# name must be the same as the "module" name in SRC_URI.
S = "${WORKDIR}/example"

# BELOW NOT PART OF RECIPE; IT SHOWS WHAT THE WORK DIR LOOKS LIKE WITH
THIS RECIPE.
# By setting PV, the cache is invalidated and new code checked out each
time the 
# relevant part oF the svn repo gets updated because I've made the svn
revision look
# like a package version number to bitbake.
#
# Here is a directory listing of the work dir:
#
# 
poky@build:/poky/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/example$
 ls -l
#drwxrwxr-x 12 poky poky 4096 Oct 30 10:17 1.0.57400-r1
#drwxrwxr-x 12 poky poky 4096 Oct 30 11:52 1.0.57401-r1
#drwxrwxr-x 12 poky poky 4096 Oct 31 12:37 1.0.57408-r1
#drwxrwxr-x 12 poky poky 4096 Nov  1 07:56 1.0.57412-r1




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

Re: [yocto] [PATCH] Documentation: Small number of minor fixes to Ch 1, ref manual

[Rifenbark, Scott M]

Robert, 

Patch applied.  

Thanks,
Scott

>-Original Message-
>From: Robert P. J. Day [mailto:rpj...@crashcourse.ca]
>Sent: Tuesday, November 05, 2013 12:01 AM
>To: Yocto discussion list
>Cc: Rifenbark, Scott M
>Subject: [PATCH] Documentation: Small number of minor fixes to Ch 1, ref
>manual
>
>
> * couple grammar/typo fixes
> * "OpenSUSE" -> "openSUSE"
>
>Signed-off-by: Robert P. J. Day 
>
>---
>
>diff --git a/documentation/ref-manual/introduction.xml
>b/documentation/ref-manual/introduction.xml
>index 3977d73..023e863 100644
>--- a/documentation/ref-manual/introduction.xml
>+++ b/documentation/ref-manual/introduction.xml
>@@ -124,7 +124,7 @@
> Refer to
> url='&OE_HOME_URL;/index.php?title=OEandYourDistro'>OE and Your
>Distro and
> url='&OE_HOME_URL;/index.php?title=Required_software'>Required
>Software
>-for information for information about dependencies and
>+for information about dependencies and
> requirements.
> If you encounter problems, please go to
> Yocto Project
>Bugzilla @@ -251,11 +251,11 @@
> 
>
> 
>-OpenSUSE Packages
>+openSUSE Packages
>
> 
> The following list shows the required packages by function
>-given a supported OpenSUSE Linux distribution:
>+given a supported openSUSE Linux distribution:
> 
> Essentials:
> Packages needed to build an image for a headless @@ 
> -346,8
>+346,8 @@
> you can resolve this by either downloading a pre-built tarball
> containing these tools, or building such a tarball on another
> system.
>-Regardless of the method, once you have the tarball you simply
>-install it somewhere on you system, such as a directory in your
>+Regardless of the method, once you have the tarball, you simply
>+install it somewhere on your system, such as a directory in
>+ your
> home directory, and then source the environment script provided,
> which adds the tools into PATH and sets
> any other environment variables required to run the tools.
>
>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

Re: [yocto] [PATCH] Documentation: Pedantic tweaks to ref manual, usingpoky.xml

[Rifenbark, Scott M]

Robert, 

Patch applied... thanks.

Scott

>-Original Message-
>From: Robert P. J. Day [mailto:rpj...@crashcourse.ca]
>Sent: Tuesday, November 05, 2013 1:32 AM
>To: Yocto discussion list
>Cc: Rifenbark, Scott M
>Subject: [PATCH] Documentation: Pedantic tweaks to ref manual,
>usingpoky.xml
>
>
>Signed-off-by: Robert P. J. Day 
>
>---
>
>diff --git a/documentation/ref-manual/usingpoky.xml b/documentation/ref-
>manual/usingpoky.xml
>index b00e7bc..1edc9ea 100644
>--- a/documentation/ref-manual/usingpoky.xml
>+++ b/documentation/ref-manual/usingpoky.xml
>@@ -40,7 +40,7 @@
> 
>
> 
>-The build_dir is optional and specifies the
>directory the
>+The build_dir argument is optional and
>+ specifies the directory the
> OpenEmbedded build system uses for the build -
> the Build
>Directory.
> If you do not specify a Build Directory, it defaults to a 
> directory @@ -
>72,7 +72,7 @@
>
> 
> Building an image without GNU General Public License Version 3
>(GPLv3) components
>-is only supported for minimal and base images.
>+is supported for only minimal and base images.
> See the "Images" chapter for 
> more
>information.
> 
> 
>@@ -158,7 +158,7 @@
> package_write, and
>build.
> The default task is build and any tasks on 
> which
>it depends
> build first.
>-Some tasks exist, such as devshell, that are 
>not
>part of the
>+Some tasks, such as devshell, are not
>+ part of the
> default build chain.
> If you wish to run a task that is not part of the default build 
> chain, you
>can use the
> -c option in BitBake.
>@@ -479,11 +479,11 @@
> from your conf/local.conf file.
> However, you should realize that enabling and disabling
> build history in this manner can change the
>-do_package task checksums, which if you
>+do_package task checksums which, if
>+ you
> are using the OEBasicHash signature generator (the default
> for many current distro configurations including
> DISTRO = "poky" and
>-DISTRO = "") and will result in the packaging
>+DISTRO = "") will result in the
>+ packaging
> tasks being re-run during the subsequent build.
> 
>
>
>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

Re: [yocto] [PATCH] Documentation: A number of minor tweaks to ref manual ch 3, closer-look.xml

[Rifenbark, Scott M]

Robert, 

This patch is applied.  Thanks for the close read and review.  You discovered 
several little issues. 

Best, 
Scott

>-Original Message-
>From: Robert P. J. Day [mailto:rpj...@crashcourse.ca]
>Sent: Tuesday, November 05, 2013 3:32 AM
>To: Yocto discussion list
>Cc: Rifenbark, Scott M
>Subject: [PATCH] Documentation: A number of minor tweaks to ref manual ch
>3, closer-look.xml
>
>
>Signed-off-by: Robert P. J. Day 
>
>---
>
>diff --git a/documentation/ref-manual/closer-look.xml b/documentation/ref-
>manual/closer-look.xml
>index 25c03e0..4883981 100644
>--- a/documentation/ref-manual/closer-look.xml
>+++ b/documentation/ref-manual/closer-look.xml
>@@ -267,7 +267,7 @@
>
> 
> The previous section described the user configurations that
>-define the BitBake's global behavior.
>+define BitBake's global behavior.
> This section takes a closer look at the layers the build system
> uses to further control the build.
> These layers provide Metadata for the software, machine, and @@ -
>363,7 +363,7 @@
> for what you typically find in the distribution layer:
> 
> classes:
>-Class files (.bbclass) holds
>+Class files (.bbclass)
>+ hold
> common functionality that can be shared among
> recipes in the distribution.
> When your recipes inherit a class, they take on the 
> @@ -381,7
>+381,7 @@
> recipes-*:
> Recipes and append files that affect common
> functionality across the distribution.
>-This area could include recipes and append files to
>+This area could include recipes and append
>+ files
> to add distribution-specific configuration,
> initialization scripts, custom image recipes,
> and so forth. @@ -421,7 +421,7 @@
> Metadata can exist for multiple formfactors, graphics
> support systems, and so forth.
> 
>-While the figure shows several 
>recipe-*
>+While the figure shows several
>+ recipes-*
> directories, not all these directories appear in all
> BSP layers.
> 
>@@ -487,7 +487,7 @@
>
> 
> Another area that plays a significant role in where source files
>-comes from is pointed to by the
>+come from is pointed to by the
> DL_DIR
> variable.
> This area is a cache that can hold previously downloaded source.
>@@ -546,7 +546,7 @@
> The canonical method through which to include a local project
> is to use the
> externalsrc.bbclass
>-class to include local project.
>+class to include that local project.
> You use either the local.conf or a
> recipe's append file to override or set the
> recipe to point to the local directory on your disk to pull 
> @@ -704,11
>+704,11 @@
> 
>
> 
>-Unpacked source source files are pointed to by the
>+Unpacked source files are pointed to by the
> S variable.
> Each recipe has an area in the Build Directory where the
> unpacked source code resides.
>-The name of directory for any given recipe is defined from
>+The name of that directory for any given recipe is
>+ defined from
> several different variables.
> You can see the variables that define these directories
> by looking at the figure:
>@@ -809,7 +809,7 @@
> variable.
> For information on how this variable works within
> that class, see the
>-meta/classes/autotools.bbclass.
>+meta/classes/autotools.bbclass 
>file.
> 
>
>do_compile:>
> Once a configuration task has been satisfied, BitBake 
> @@ -818,8
>+818,8 @@
> Compilation occurs in the directory pointed to by the
> B
> variable.
>-Realize that the B directory, by
>-default, is the same as the
>+Realize that the B directory is, 
>by
>+default, the same as the
> S
> directory.
>
>do_install:
>@@ -948,7 +948,7 @@
>
> 
> During image generation, the build system attempts to run
>-all pos

Re: [yocto] architecture mismatch during kernel build (40 to 3)

[Maxwell Bottiger]

Ok.  so, I should backtrack a bit, just so I understand the issue
completely.  This is my first time putting together a bitbake recipe, and
the kernel is a complex little beastie.

BTW, I'm building for an Atmel ARM cpu.  Sorry didn't mention that in my
first message.

So, when I was building my kernel by hand, here's what I was doing:
make ARCH=arm at91sam9x5ek_defconfig
make ARCH=arm menuconfig
make ARCH=arm
./mkimage -A arm -O linux -C none -T kernel -a 20008000 -e 20008000 -n
linux-2.6 -d arch/arm/boot/zImage uImage-2.6.39-at91sam9x5ek.bin

I took the .config file that I'd been using and placed it in depconfig,
then added a line to my bb file to include that configuration.  So, that's
good I think.

When the compile is complete, I should have an arm zImage, and mkimage
should run against that.  So, my understanding would be that mkimage should
be an x86 executable, and the kernel should be an arm, and mkimage should
generate a uImage kernel.  So, the complaint from do_package that the
executables are different architectures makes sense.

Bruce, I think what you're recommending I do is remove mkImage after the
compile and image creation are complete but before packaging takes place,
as that's where the QA is complaining.  (Which makes a lot of sense)  I
just want to list the details so I'm sure I understand the problem
completely.

To this end I've added a do_install_append to the end of my recipe to
remove the mkImage file.  I tried it a couple of different times, but it
looks like I'm seeing the same error message each time.  I think the issue
is I just don't understand the bb process well enough.  Maybe I'm trying to
delete the file at the wrong stage, or maybe there's something system
specific I don't know about.  I copied the guts of this recipe from a
linux-yocto-custom_3.6 bb file, which compiled cleanly for this chip.  I'll
list the bb recipe below.  Any advice is greatly appreciated.

linux-yocto-custom_2.6.39.bb
-
inherit kernel
require recipes-kernel/linux/linux-yocto.inc

LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
#DEFAULT_PREFERENCE = "-1"


LINUX_VERSION = "2.6.39"
LINUX_VERSION_EXTENSION ?= "-custom"
KBRANCH = "master"
META = "meta"


SRC_URI =
"git:///home/blah/blah/blah/linux-2.6.39;protocol=file;branch=master"
SRC_URI += "file://defconfig"
#SRC_URI += "file://extra-cflags-override.patch"

KERNEL_EXTRA_ARGS="LOADADDR=0x200  V=1 KCFLAGS=-mno-unaligned-access"


UBOOT_ENTRYPOINT="200"

SRCREV="master"


PV = "${LINUX_VERSION}"

PR = "r1"

S = "${WORKDIR}/git"
EXTRA_OEMAKE = "${PARALLEL_MAKE}"

KERNEL_IMAGETYPE = "uImage"


# Override COMPATIBLE_MACHINE to include your machine in a bbappend
# file. Leaving it empty here ensures an early explicit build failure.
#COMPATIBLE_MACHINE = "(xo1-mvs)"
COMPATIBLE_MACHINE = "(sama5d3xek|at91sam9x5ek)"

# clean up after module installation
do_install_append() {
rm -f mkimage
}


On Mon, Nov 4, 2013 at 11:28 PM, Bruce Ashfield <
bruce.ashfi...@windriver.com> wrote:

> On 13-11-04 8:41 PM, Maxwell Bottiger wrote:
>
>> I'm building a custom kernel, and I think I'm nearly there.  I'm seeing
>> an error when running mkimage.  bitbake is complaining about an
>> architecure mismatch, but I don't know which files it is comparing, or
>> if the mismatch really matters (32bit x86 vs 64bit x86 or whatever)
>>
>> Here's the error string:
>>
>> WARNING: File '/usr/src/kernel/mkimage' from linux-yocto-custom was
>> already stripped, this will prevent future debugging!
>>
>> ERROR: QA Issue: Architecture did not match (40 to 3) on
>> /work/at91sam9x5ek-poky-linux-gnueabi/linux-yocto-custom/2.
>> 6.39-r1/packages-split/kernel-dev/usr/src/kernel/mkimage
>>
>
> The obvious answer is .. it is mkimage that it is complaining about. You
> are packaging mkimage (which is likely an x86 elf file) into your
> kernel-dev package (which is your target arch, likely powerpc or ARM).
> Hence the QA error.
>
> In your kernel recipe, you can remove the file before packaging
> (i.e. in the do_install_append) or inhibit the QA check for your recipe.
>
> What exactly does your kernel recipe look like ? What is building mkimage
> and then getting it installed into /usr/src/kernel ?
>
> My suggestion is to track that down, versus inhibiting the QA check.
>
> Bruce
>
>
>> ERROR: QA run found fatal errors. Please consider fixing them.
>>
>> ERROR: Function failed: do_package_qa
>>
>> ERROR: Logfile of failure stored in:
>> /home/sleepylight/workspace/yocto/poky/build-atmel/tmp/
>> work/at91sam9x5ek-poky-linux-gnueabi/linux-yocto-custom/2.
>> 6.39-r1/temp/log.do_package.11527
>>
>> ERROR: Task 18
>> (/home/sleepylight/workspace/yocto/poky/meta-atmel/recipes-kernel/linux/
>> linux-yocto-custom_2.6.39.bb
>> , do_package) failed with exit code
>> '1'
>>
>>
>>
>> I'm building on a 64 bit linux platform, I don't know if that makes a
>> difference.
>>
>> Thanks all. 

Re: [yocto] Change Sato theme

[Burton, Ross]

On 4 November 2013 09:17, Diego Gonzalez  wrote:
> I was reading in the mailing list how take control over Sato theme. If you
> see this :
>
> https://lists.yoctoproject.org/pipermail/yocto/2013-February/014360.html
>
> you will see that they are talking about matchbox-session-sato.schemas which
> I can't find it in Master or Dora branches.

The schemas file isn't used any more.  The matchbox-sato recipe has a
postinst that sets the default theme (and some other keys), so you
should write a recipe that does the same and install that instead of
matchbox-sato.

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

[yocto] [PATCH] Documentation: A number of minor tweaks to ref manual ch 3, closer-look.xml

[Robert P. J. Day]

Signed-off-by: Robert P. J. Day 

---

diff --git a/documentation/ref-manual/closer-look.xml 
b/documentation/ref-manual/closer-look.xml
index 25c03e0..4883981 100644
--- a/documentation/ref-manual/closer-look.xml
+++ b/documentation/ref-manual/closer-look.xml
@@ -267,7 +267,7 @@

 
 The previous section described the user configurations that
-define the BitBake's global behavior.
+define BitBake's global behavior.
 This section takes a closer look at the layers the build system
 uses to further control the build.
 These layers provide Metadata for the software, machine, and
@@ -363,7 +363,7 @@
 for what you typically find in the distribution layer:
 
 classes:
-Class files (.bbclass) holds
+Class files (.bbclass) hold
 common functionality that can be shared among
 recipes in the distribution.
 When your recipes inherit a class, they take on the
@@ -381,7 +381,7 @@
 recipes-*:
 Recipes and append files that affect common
 functionality across the distribution.
-This area could include recipes and append files to
+This area could include recipes and append files
 to add distribution-specific configuration,
 initialization scripts, custom image recipes,
 and so forth.
@@ -421,7 +421,7 @@
 Metadata can exist for multiple formfactors, graphics
 support systems, and so forth.
 
-While the figure shows several 
recipe-*
+While the figure shows several 
recipes-*
 directories, not all these directories appear in all
 BSP layers.
 
@@ -487,7 +487,7 @@

 
 Another area that plays a significant role in where source files
-comes from is pointed to by the
+come from is pointed to by the
 DL_DIR
 variable.
 This area is a cache that can hold previously downloaded source.
@@ -546,7 +546,7 @@
 The canonical method through which to include a local project
 is to use the
 externalsrc.bbclass
-class to include local project.
+class to include that local project.
 You use either the local.conf or a
 recipe's append file to override or set the
 recipe to point to the local directory on your disk to pull
@@ -704,11 +704,11 @@
 

 
-Unpacked source source files are pointed to by the
+Unpacked source files are pointed to by the
 S variable.
 Each recipe has an area in the Build Directory where the
 unpacked source code resides.
-The name of directory for any given recipe is defined from
+The name of that directory for any given recipe is defined from
 several different variables.
 You can see the variables that define these directories
 by looking at the figure:
@@ -809,7 +809,7 @@
 variable.
 For information on how this variable works within
 that class, see the
-meta/classes/autotools.bbclass.
+meta/classes/autotools.bbclass 
file.
 
 
do_compile:
 Once a configuration task has been satisfied, BitBake
@@ -818,8 +818,8 @@
 Compilation occurs in the directory pointed to by the
 B
 variable.
-Realize that the B directory, by
-default, is the same as the
+Realize that the B directory is, 
by
+default, the same as the
 S
 directory.
 
do_install:
@@ -948,7 +948,7 @@

 
 During image generation, the build system attempts to run
-all post installation scripts.
+all post-installation scripts.
 Any that fail to run on the build host are run on the
 target when the target system is first booted.
 If you are using a
@@ -1052,7 +1052,7 @@
 
 The images produced by the OpenEmbedded build system
 are compressed forms of the
-root filesystems that are ready to boot on a target device.
+root filesystem that

Re: [yocto] SRCREV how is it supposed to work?

[Paul Eggleton]

On Tuesday 05 November 2013 10:25:24 Hans Beckérus wrote:
> I have seen recipes that defines PV = "xyz+git${SRCPV}" and then
> SRCREV to a specific tag instead of ${AUTOREV}.
> Is that not contradictory? Or is it simply that the author of that
> recipe wished to have a git tag automatically added to the version
> string?
> Are there any specific cases when that approach is to prefere?

AFAIK, there are two recommended values for SRCREV assuming you are fetching 
from an SCM at all:

A) A specific revision (SHA1 hash when fetching from git)

or

B) "${AUTOREV}" if you want to always build the latest version available at 
time of building. If you want to build the latest version from a branch, 
specify it in branch= in the SRC_URI entry.

Anything else isn't really a good idea. Sometimes I wonder if we ought to just 
tighten this up so that only settings that make sense can be set.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] filling in the "missing" entries in the ref manual variable glossary

[Paul Eggleton]

Hi Robert,

On Tuesday 05 November 2013 01:34:56 Robert P. J. Day wrote:
> On Mon, 4 Nov 2013, Rifenbark, Scott M wrote:
> > This will be useful for me... thanks Robert.
> 
>   i'm about halfway through the categorized variable glossary:
> 
> http://www.crashcourse.ca/wiki/index.php/OE_variable_glossary
> 
> and a few variables that caught my eye:
> 
>  * BUGTRACKER (not mentioned)
>  * TUNE_ARCH (not mentioned)
>  * TUNE_FEATURES (not mentioned)
>  * CLASSOVERRIDE (not mentioned)
>  * UBOOT_TARGET (mentioned, but replaced by UBOOT_MAKE_TARGET?)
> 
> and a number of UBOOT-related variables aren't mentioned. not clear if
> any of these *should* be added -- there's obviously a limit to how
> many variables you should explain -- but you can decide if any should
> be added to the ref manual.

I think a variable should be documented if anyone will ever need to know what 
it does - and that probably includes almost all variables. I have talked with 
Scott in the past about some kind of labelling system for the variable 
glossary so you can see at a glance where the variable is supposed to be used 
and (hopefully, if we can come up with sane categorisation) when it's 
appropriate to modify.

IMO, all of those you listed should be documented. I've just entered a bug 
about documenting the tune files / variables at least:

https://bugzilla.yoctoproject.org/show_bug.cgi?id=5463

Cheers,
Paul


-- 

Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-mono] Mono 3.2.3 support

[Alex J Lennon]

Hi all,

I've successfully built and tested a Mono 3.2.3 recipe with Yocto.

The code is in a fork I took of current meta-mono head, which is here:

g...@git.assembla.com:ciseco-eve.meta-mono.git

Web access:https://www.assembla.com/code/ciseco-eve/git-2/nodes 



I have tested against a qemux86 target and also against an i.MX6 target
built out of the meta-arm-fsl layer (MACHINE = 'imx6qsabresd', 
fsl-image-gui)


Bitbake layer versions and major environment settings are here 
http://pastebin.com/SQhB4JgL


The testing I have done thus far is basic, simply running a console 
"Hello World" application

and a corresponding version showing a Windows Form with a button.

Floating Point


At this time Mono does not support arm hardfp although there may be some 
patches
floating around. There are some notes on upcoming support for Mono in 
the the near

future but nothing I can see in the repository yet,

ref: http://blog.alexrp.com/2013/07/21/recent-improvements-to-mono-on-arm/

As such any images which are tuned by default to use hardfp need this 
overridden (e.g. fsl-image-gui)


To build fsl-image-gui I added the following to my local.conf

DEFAULTTUNE_mx6 = "cortexa9-neon"

(I'm not sure if this is the best way - any advice on this would be 
appreciated)


Build Issues
==

Lastly I had a lot of trouble building. From comments seen on the 
inter-web I suspect
there is an issue with bitbake tracking dependencies across differing 
tunings.


"I tried this on imx6qsabresd and have no issues.   Right before release 
we did have problems with
disabling hwfp correctly but it was enabled in the final update. Also 
I've seen multiple times that switching
between hwfp and swfp can corrupt build states.  I always keep these 
completely separate builds both

with cache and tmp directories."

ref: https://community.freescale.com/thread/310233

I was seeing that recipe builds failed, and in one case when I 
investigated the RPM .spec file
the spec file had been created with dependencies on packages with 
-hardfp in the naming.


I had to create a completely new build directory for my softfp build and 
with this done

the build then worked.

I think this may have been something touched upon by commentators at 
ELCE the other week.


---

Lastly, if anybody has time to review the recipes I've modified here and 
advise me on any non-compliances
with Yocto policies I'd be pleased to make any needed changes to bring 
them into compliance with a view

to committal to the official git repo.

Best Regards,

Alex Lennon

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

[yocto] [PATCH] Documentation: Pedantic tweaks to ref manual, usingpoky.xml

[Robert P. J. Day]

Signed-off-by: Robert P. J. Day 

---

diff --git a/documentation/ref-manual/usingpoky.xml 
b/documentation/ref-manual/usingpoky.xml
index b00e7bc..1edc9ea 100644
--- a/documentation/ref-manual/usingpoky.xml
+++ b/documentation/ref-manual/usingpoky.xml
@@ -40,7 +40,7 @@
 

 
-The build_dir is optional and specifies the 
directory the
+The build_dir argument is optional and 
specifies the directory the
 OpenEmbedded build system uses for the build -
 the Build 
Directory.
 If you do not specify a Build Directory, it defaults to a directory
@@ -72,7 +72,7 @@

 
 Building an image without GNU General Public License Version 3 
(GPLv3) components
-is only supported for minimal and base images.
+is supported for only minimal and base images.
 See the "Images" chapter for 
more information.
 
 
@@ -158,7 +158,7 @@
 package_write, and build.
 The default task is build and any tasks on 
which it depends
 build first.
-Some tasks exist, such as devshell, that are 
not part of the
+Some tasks, such as devshell, are not part of 
the
 default build chain.
 If you wish to run a task that is not part of the default build 
chain, you can use the
 -c option in BitBake.
@@ -479,11 +479,11 @@
 from your conf/local.conf file.
 However, you should realize that enabling and disabling
 build history in this manner can change the
-do_package task checksums, which if you
+do_package task checksums which, if you
 are using the OEBasicHash signature generator (the default
 for many current distro configurations including
 DISTRO = "poky" and
-DISTRO = "") and will result in the packaging
+DISTRO = "") will result in the packaging
 tasks being re-run during the subsequent build.
 


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

Re: [yocto] SRCREV how is it supposed to work?

[Hans Beckérus]

On Tue, Oct 29, 2013 at 3:20 PM, Hans Beckérus  wrote:
> On Tue, Oct 29, 2013 at 2:42 PM, Martin Jansa  wrote:
>> On Tue, Oct 29, 2013 at 02:27:30PM +0100, Hans Beckérus wrote:
>>> On Tue, Oct 29, 2013 at 12:00 PM, Martin Jansa  
>>> wrote:
>>> > On Tue, Oct 29, 2013 at 12:46:18PM +0100, Hans Beckérus wrote:
>>> >> Hi. I am wondering if we are using SRCREV wrong somehow.
>>> >> Is it expected that if we use SRCREV = "${AUTOREV}", that any changes
>>> >> to the remote should be automatically detected and downloaded/fetched?
>>> >> I can no see that this is actually what happens. Any changes made to
>>> >> the remote still need to be manually fetched or indirectly by stepping
>>> >> the recipe revision.
>>> >> Are we using SRCREV wrong or is this actually the way it is supposed
>>> >> to work? Also, is there some way to force a download to me made every
>>> >> single time by a recipe,
>>> >> irrespective of if the remote changed or not?
>>> >
>>> > It's supposed to run git ls-remote while parsing to get latest revision
>>> > in remote repo and then rebuild the package because of SRCPV change in
>>> > PV, are you using something like:
>>> >
>>> > PV = "1.0+git${SRCPV}"
>>> >
>>> > ?
>>> >
>>> Nope. I did not know we had to use PV. Sounds like we need to in the
>>> general case. But in this case,
>>
>> You need to reference it somewhere, if you were using multiple git repos
>> in SRC_URI you probably need to define SRCREV_foo = "${AUTOREV}" for all
>> of them (where foo is from name=foo param for each repo).
>>
> Sure.
>
>>> we actually do not have versions on the package itself since it is
>>> simply a container for several other binary packages merged into one
>>> binary file.
>>> So our "package" is downloading packages from several git repos,
>>
>> "package" -> "recipe"
>>
> Yea, yea! :)
>
>>> stored in different folders using 'destsuffix'.
>>> Would it be ok to simply set PV = "${SRCPV}" ? I guess this will
>>
>> SRCPV is sortable and consistent only with shared persistent PR server is 
>> used
>> across all builders - if that's not the case it's safer to prefix SRCPV
>> with some manually maintained version.
>>
> No problem. That is doable.
>
>>> result in a new target folder for each changed remote? And will this
>>> work when referring to several git repos in SRC_URI?
>>
>> You'll need to define SRCREV_FORMAT and name parameter for each repo in
>> SRC_URI.
>>
> Now I am not following you :( name I understand, but what is SRCREV_FORMAT?
>
>>> Since changes are expected to happen frequently some sort of
>>> garbage-collection function is needed to get rid of all the obsolete
>>> package trees. IIRC was there not an option for this somewhere?
>>
>> Maybe you're talking about rm_work, but I'm not sure what you mean by
>> package trees.
>>
> Maybe it was rm_work, by "package trees" I mean whatever is unpacked
> from the fetch.
>

I have seen recipes that defines PV = "xyz+git${SRCPV}" and then
SRCREV to a specific tag instead of ${AUTOREV}.
Is that not contradictory? Or is it simply that the author of that
recipe wished to have a git tag automatically added to the version
string?
Are there any specific cases when that approach is to prefere?

Thanks.
Hans

>> --
>> Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] ref manual, sections 2.3.[67], ambiguity with "-b" option to bitbake

[Robert P. J. Day]

  section 2.3.6 of ref manual explains that bitbake "-b" option refers
specifically to a recipe *file*:

"If you really want to build a specific .bb file, you can use the
command form bitbake -b ."

but the very next section uses "-b" in the context of a simple recipe
*name* when combining it with "-e":

"You can use the -e BitBake option to display the resulting
environment for a configuration when you do not specify a package or
for a specific package when you do specify the package. If you want to
show the environment resulting from parsing a single recipe, use the
-b recipename form."

  that suggests i could run something like:

$ bitbake -e -b zlib

which seems to work. clarification? is "-b" meant to refer to a simple
recipe *name* when used in the context of "-e"?

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

[yocto] [PATCH] Documentation: Small number of minor fixes to Ch 1, ref manual

[Robert P. J. Day]

 * couple grammar/typo fixes
 * "OpenSUSE" -> "openSUSE"

Signed-off-by: Robert P. J. Day 

---

diff --git a/documentation/ref-manual/introduction.xml 
b/documentation/ref-manual/introduction.xml
index 3977d73..023e863 100644
--- a/documentation/ref-manual/introduction.xml
+++ b/documentation/ref-manual/introduction.xml
@@ -124,7 +124,7 @@
 Refer to
 OE and Your Distro 
and
 Required Software
-for information for information about dependencies and
+for information about dependencies and
 requirements.
 If you encounter problems, please go to
 Yocto Project 
Bugzilla
@@ -251,11 +251,11 @@
 

 
-OpenSUSE Packages
+openSUSE Packages

 
 The following list shows the required packages by function
-given a supported OpenSUSE Linux distribution:
+given a supported openSUSE Linux distribution:
 
 Essentials:
 Packages needed to build an image for a headless
@@ -346,8 +346,8 @@
 you can resolve this by either downloading a pre-built tarball
 containing these tools, or building such a tarball on another
 system.
-Regardless of the method, once you have the tarball you simply
-install it somewhere on you system, such as a directory in your
+Regardless of the method, once you have the tarball, you simply
+install it somewhere on your system, such as a directory in your
 home directory, and then source the environment script provided,
 which adds the tools into PATH and sets
 any other environment variables required to run the tools.

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