[yocto] ia32-base.inc: Drop glibc --with-tls option, its now the only option for glibc

[Richard Purdie]

This option is unused by (e)glibc since 2011 and is the default. It has been
shown to interact badly with the configure option in atom-pc from meta-yocto 
causing a rebuild of the whole system despite the only change being an 
assignment with += vs =. The easiest fix is simply to drop it.

Signed-off-by: Richard Purdie 

diff --git a/conf/machine/include/ia32-base.inc 
b/conf/machine/include/ia32-base.inc
index 99ac352..17ff714 100644
--- a/conf/machine/include/ia32-base.inc
+++ b/conf/machine/include/ia32-base.inc
@@ -21,7 +21,6 @@ SERIAL_CONSOLE ?= "115200 ttyS0"
 # glibc-related variables
 #
 GLIBC_ADDONS ?= "nptl"
-GLIBC_EXTRA_OECONF += "--with-tls"
 
 #
 # kernel-related variables


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

Re: [yocto] RFC: OE-Core task rework

[Paul Eggleton]

On Monday 20 August 2012 15:45:07 Mark Hatle wrote:
> > 1) Do we rename "task" to something a little more understandable to the
> > uninitiated, such as "package group"? The word "task" is already used in a
> > much more natural sense within bitbake as a unit of work. Historically I
> > believe we picked up this term from Debian but I'm not aware of
> > significant use by other mainstream distributions.
> 
> "group" or "packagegroup" or "package-group" is my suggestion for the
> existing 'task' recipes.  From what I've seen, it should be a rename
> opportunity -- we can even provide/rprovide the old names

Indeed, and I think we would for compatibility purposes.
 
> > 2) Look at the existing tasks and:
> >   * evaluate their usefulness
> >   * remove any that are obsolete
> >   * adjust existing contents if needed
> >   * look for useful groups of packages that might be added
> >   
> >   We need to pay particular attention to task-core-boot and task-base as
> >   these> 
> > are pulled in by default in any image that inherits from
> > core-image.bbclass - if these are not generally working for people that
> > are creating their own images, we need to change them such that they are.
> 
> During the pre-oe-core Yocto Project development, a design was generated to
> roughly group the packages into functional areas.  For the most part, this
> design (as well as legacy elements) still exist.
> 
> I think the boot, base and others need to be evaluated for usefulness... but
> my feeling is most of them are close to being correct.

I think so as well. We may be pulling in one or two packages unconditionally 
where they should be optional (e.g. modutils-initscripts?) but most of it is 
pretty sensible.
 
> >   *  Try to make each task have a reasonable name - there are some current
> >   uses of "core" and "base" that don't actually convey any meaning; LSB
> >   specific tasks should be named as such, etc.
> 
> Yup, there is a logical grouping for the lsb specific tasks, as for others. 
> The naming needs to be made clear as to why it's there, and what it
> represents. Same with the summary and descriptions -- they should list the
> functionality provided by this group of components.

The main concern with LSB is that we have something called task-basic, which 
seems to be intended for LSB but does not state as much, and I know at least 
one person has tried to use it and then been a little puzzled as to why rpm 
has been pulled in when ipk packaging has been selected. Just naming some of 
these tasks more appropriately would help avoid such situations. In the 
specific case of task-basic there may be a case for creating a similar but not 
LSB-focused task that pulls in real shell utilities in preference to the light 
versions provided by busybox.

> > 4) Consider the usefulness of the existing PACKAGE_GROUP_ structure which
> > converts some IMAGE_FEATURES into the addition of tasks to be installed
> > (see classes/core-image.bbclass). At the very least we should probably
> > rename this if we rename tasks to package groups, and there's a question
> > as to how IMAGE_FEATURES scales - should every task be represented in
> > there or only a select list? Would we be better off not trying to bring
> > any tasks in via IMAGE_FEATURES at all and mostly leave that to control
> > post-processing (e.g. package-management, debug-tweaks, etc.)?
> 
> I'd certainly prefer that images were limited to selecting software from
> task (group) recipes only, and not providing their own.  An image should be
> able to change the selection based on an "image feature" or similar
> configuration, but the underlying tasks/groups, recipes, etc should all be
> 'generic' to a given distribution configuration.

The first part seems reasonable to me; but I'm still short of an answer as to 
what to do with the existing IMAGE_FEATURES code as mentioned above. At the 
moment aside from the special features such as debug-tweaks, these are just a 
thin layer on top of task recipes which doesn't add very much at all other 
than extra maintenance.

> I think if you go through the images today, a lot of that stuff is either
> old, or could be simplified by creating appropriate tasks/groups.

OK, that's a good point. I have another task on my list to clean up our image 
recipes and that would be a good segue into that.

Cheers,
Paul

-- 

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

Re: [yocto] RFC: OE-Core task rework

[Paul Eggleton]

On Tuesday 21 August 2012 09:49:37 Paul Eggleton wrote:
> The main concern with LSB is that we have something called task-basic,
> which  seems to be intended for LSB but does not state as much, and I know
> at least one person has tried to use it and then been a little puzzled as
> to why rpm has been pulled in when ipk packaging has been selected. Just
> naming some of these tasks more appropriately would help avoid such
> situations. In the specific case of task-basic there may be a case for
> creating a similar but not LSB-focused task that pulls in real shell
> utilities in preference to the light versions provided by busybox.

Ugh, sorry. I meant task-core-basic here - not to be confused with task-basic 
in meta-oe [1].

Cheers,
Paul

[1] http://www.openembedded.org/wiki/Meta-oe_tasks

-- 

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

Re: [yocto] Raspberry Pi do_fetch failure

[Jack Mitchell]

On 20/08/12 18:23, Andrei Gherzan wrote:
It seems like even if i got no feedback from github, this issue is not 
reproducible anymore. Fetch is working as it should now. Could you 
please confirm?


Si it could have been a temporary bug or this was solved meanwhile.

ag




On Mon, Aug 13, 2012 at 9:58 PM, Andrei Gherzan > wrote:



On Mon, Aug 13, 2012 at 7:38 PM, Chris Tapp
mailto:opensou...@keylevel.com>> wrote:

On 13 Aug 2012, at 15:00, Jack Mitchell wrote:

> On 13/08/12 14:51, Andrei Gherzan wrote:
>>
>> On Mon, Aug 13, 2012 at 4:34 PM, Jack Mitchell
mailto:m...@communistcode.co.uk>
>> wrote:
>>
>>Good afternoon everyone,
>>
>>I am trying (yet again) to get yocto to build for the
Raspberry Pi
>>and I am falling at the do_fetch hurdle on the RasPi kernel.
>>
>>   ERROR: Fetcher failure: Fetch command export
HOME="/home/jack";
>>   export SSH_AGENT_PID="1350"; export
>> SSH_AUTH_SOCK="/home/jack/.cache/keyring-fjEm9a/ssh"; export
>>
 
GIT_CONFIG="/home/jack/Projects/poky-rasp/raspberry/tmp/sysroots/x86_64-linux/etc/gitconfig";
>>   export
>>
 
PATH="/home/jack/Projects/poky-rasp/scripts:/home/jack/Projects/poky-rasp/raspberry/tmp/sysroots/x86_64-linux/usr/bin/armv6-vfp-poky-linux-gnueabi:/home/jack/Projects/poky-rasp/raspberry/tmp/sysroots/raspberrypi/usr/bin/crossscripts:/home/jack/Projects/poky-rasp/raspberry/tmp/sysroots/x86_64-linux/usr/sbin:/home/jack/Projects/poky-rasp/raspberry/tmp/sysroots/x86_64-linux/usr/bin:/home/jack/Projects/poky-rasp/raspberry/tmp/sysroots/x86_64-linux/sbin:/home/jack/Projects/poky-rasp/raspberry/tmp/sysroots/x86_64-linux//bin:/home/jack/Projects/poky-rasp/scripts:/home/jack/Projects/poky-rasp/bitbake/bin/:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/bin/core_perl";
>>   git clone --bare --mirror
>>git://github.com/raspberrypi/linux.git

>>
>>
>>
>> Does this work in a shell? Just try to clone it on your
computer.
>>
>> ag
>
> Yes, cloning it now without issues - it took a while to get
going and someone has suggested that it might be timing out
within bitbake...


I've had similar issues in the past that seemed to be caused
by Github. If I ran a manual fetch I could see errors relating
to compressed folders (I think - was a while back) that
couldn't be found. It sorted itself after a day or so.

I sent an email to github. Will keep you posted.

ag




Working fine for me now.

--

  Jack Mitchell (j...@embed.me.uk)
  Embedded Systems Engineer
  http://www.embed.me.uk

--

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

[yocto] [PATCH] meta-emenlow: unset preferred providers for virtual/libgles[12]

[Ross Burton]

The recent changes to enable GLES/EGL in mesa-dri have caused emenlow to fail:

ERROR: Trying to resolve runtime dependency libglu resulted in conflicting 
PREFERRED_PROVIDER entries being found.
The providers found were: 
['/srv/home/pokybuild/yocto-autobuilder/yocto-slave/emenlow/build/yocto/meta-intel/meta-emenlow/recipes-graphics/xpsb-glx/xpsb-glx_0.18.bb',
 
'/srv/home/pokybuild/yocto-autobuilder/yocto-slave/emenlow/build/meta/recipes-graphics/mesa/mesa-dri_8.0.4.bb']
The PREFERRED_PROVIDER entries resulting in this conflict were: 
['PREFERRED_PROVIDER_mesa-dri = xpsb-glx', 'PREFERRED_PROVIDER_virtual/libgles1 
= mesa-dri']

Because emenlow's xpsb-glx contains mesa, it needs to entirely replace
mesa-dri. We'd normally set virtual/libgles1 and virtual/libgles2 to xpsb-glx
but these drivers don't build the GLES libraries so that would be a lie.

So, unset the preferred provider entries so that bitbake doesn't look at
mesa-dri at all.
---
 meta-emenlow/conf/machine/emenlow.conf |2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta-emenlow/conf/machine/emenlow.conf 
b/meta-emenlow/conf/machine/emenlow.conf
index afb3866..65dcd5a 100644
--- a/meta-emenlow/conf/machine/emenlow.conf
+++ b/meta-emenlow/conf/machine/emenlow.conf
@@ -13,6 +13,8 @@ PREFERRED_PROVIDER_libdrm = "libdrm-poulsbo"
 PREFERRED_PROVIDER_drm = "libdrm-poulsbo"
 PREFERRED_PROVIDER_virtual/libx11 = "libx11-trim"
 PREFERRED_PROVIDER_virtual/libgl = "xpsb-glx"
+PREFERRED_PROVIDER_virtual/libgles1 = ""
+PREFERRED_PROVIDER_virtual/libgles2 = ""
 PREFERRED_PROVIDER_virtual/xserver = "xserver-psb"
 PREFERRED_PROVIDER_virtual/xserver-xf86 = "xserver-psb"
 PREFERRED_PROVIDER_mesa-dri = "xpsb-glx"
-- 
1.7.10

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

[yocto] [PATCH] [Fixed]Yocto-BSP Main Page - time consuming processes block the UI

[Ioana Grigoropol]

- problems on the main page of yocto-bsp wizard :
- getting the available kernel architectures is invoked from the UI
-> similar to the properties page, when loading the
architectures a new thread is created in the background and a
progress monitor dialog is shown.
- getting qemu kernel architectures is invoked from the UI
-> as above.
- creation of properties file is done with each change in any of
the controls
-> this action should only be done once, and the most
convenient place would be when flipping to next page. Unfortunately, the
method that checks if we can flip to the next page is called at each
change on the controls, in so re-writing the file with each keystroke.
The creation of this file was moved on the YoctoBSP Wizard, when
clicking on finish.

In order to reuse the code that sends a process in the background
and shows the progress from the properties page, we use a
generic class BSPThread that runs a command from the shell in the
background and collects the output & error, and a BSPProgressDialog to
show. Each command will customize the processing of its output by
subclassing BSPThread. the progress of the background thread.


Signed-off-by: Ioana Grigoropol 
---
 .../sdk/remotetools/wizards/bsp/BSPAction.java |   32 ++
 .../remotetools/wizards/bsp/BSPProgressDialog.java |   44 +++
 .../sdk/remotetools/wizards/bsp/BSPThread.java |   92 ++
 .../wizards/bsp/ErrorCollectorThread.java  |   19 ++
 .../remotetools/wizards/bsp/KernelArchGetter.java  |   23 ++
 .../wizards/bsp/KernelBranchesGetter.java  |   28 ++
 .../sdk/remotetools/wizards/bsp/MainPage.java  |  296 +++--
 .../wizards/bsp/OutputCollectorThread.java |   19 ++
 .../remotetools/wizards/bsp/PropertiesPage.java|  335 +++-
 .../remotetools/wizards/bsp/QemuArchGetter.java|   27 ++
 .../remotetools/wizards/bsp/YoctoBSPWizard.java|   99 +++---
 11 files changed, 579 insertions(+), 435 deletions(-)
 create mode 100644 
plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/BSPAction.java
 create mode 100644 
plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/BSPProgressDialog.java
 create mode 100644 
plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/BSPThread.java
 create mode 100644 
plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/ErrorCollectorThread.java
 create mode 100644 
plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/KernelArchGetter.java
 create mode 100644 
plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/KernelBranchesGetter.java
 create mode 100644 
plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/OutputCollectorThread.java
 create mode 100644 
plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/QemuArchGetter.java

diff --git 
a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/BSPAction.java
 
b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/BSPAction.java
new file mode 100644
index 000..171f181
--- /dev/null
+++ 
b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/BSPAction.java
@@ -0,0 +1,32 @@
+package org.yocto.sdk.remotetools.wizards.bsp;
+
+/**
+ * Stores a list of items from the output of a background thread and the error 
message if something went wrong
+ * @author ioana.grigoropol
+ *
+ */
+public class BSPAction {
+   private String[] items;
+   private String message;
+
+   BSPAction(String[] items, String message){
+   this.setItems(items);
+   this.setMessage(message);
+   }
+
+   public String[] getItems() {
+   return items;
+   }
+
+   public void setItems(String[] items) {
+   this.items = items;
+   }
+
+   public String getMessage() {
+   return message;
+   }
+
+   public void setMessage(String message) {
+   this.message = message;
+   }
+}
\ No newline at end of file
diff --git 
a/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/BSPProgressDialog.java
 
b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/BSPProgressDialog.java
new file mode 100644
index 000..5cf713d
--- /dev/null
+++ 
b/plugins/org.yocto.sdk.remotetools/src/org/yocto/sdk/remotetools/wizards/bsp/BSPProgressDialog.java
@@ -0,0 +1,44 @@
+package org.yocto.sdk.remotetools.wizards.bsp;
+
+import org.eclipse.core.runtime.IProgressMonitor;
+import org.eclipse.jface.dialogs.ProgressMonitorDialog;
+import org.eclipse.jface.operation.IRunnableWithProgress;
+import org.eclipse.swt.widgets.Shell;
+
+/**
+ * Creates a progress monitor dialog that will run in the background a 
BSPThread and display a custom message
+ * @

Re: [yocto] Toolchain rework, call for testing

[Martin Jansa]

On Thu, Aug 16, 2012 at 09:47:37PM -0700, Khem Raj wrote:
> Hi All
> 
> Recently glibc build has been simplified upstream. It has dropped the
> dependency on libgcc_s and libgcc_eh for building glibc itself.
> This means that we can simplify our toolchain bootstrap a bit by
> dropping 1 of the 3 cross gcc build stages. We do not need
> gcc-cross-intermediate
> anymore. This should bring some build time reduction and simplify the
> bootstrap. I have a series of patches which I have tested
> by building core-image-minimal and meta-toolchain for all supported
> qemu architectures and also uclibc/eglibc both
> but it needs a lot more testing therefore I am calling out wider
> audience for help in testing it out.
> 
> The branch is
> 
> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/toolchain-rework

eglibc fails to build in incremental build

| arm-oe-linux-gnueabi-gcc  -march=armv4t -marm -mthumb-interwork 
-mtune=arm920t --sysroot=/OE/shr-core/tmp-eglibc/sysroots/om-gta02-tcbootstrap  
 -nostdlib -nostartfiles -r -o 
/OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/eglibc-2.16-r6+svnr19922/build-arm-oe-linux-gnueabi/libc_pic.os
 \
|  -Wl,-d -Wl,--whole-archive 
/OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/eglibc-2.16-r6+svnr19922/build-arm-oe-linux-gnueabi/libc_pic.a
 -o 
/OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/eglibc-2.16-r6+svnr19922/build-arm-oe-linux-gnueabi/libc_pic.os
| arm-oe-linux-gnueabi-gcc  -march=armv4t -marm -mthumb-interwork 
-mtune=arm920t --sysroot=/OE/shr-core/tmp-eglibc/sysroots/om-gta02-tcbootstrap  
 -nostdlib -nostartfiles -r -o 
/OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/eglibc-2.16-r6+svnr19922/build-arm-oe-linux-gnueabi/elf/librtld.map.o
 '-Wl,-(' 
/OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/eglibc-2.16-r6+svnr19922/build-arm-oe-linux-gnueabi/elf/dl-allobjs.os
 
/OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/eglibc-2.16-r6+svnr19922/build-arm-oe-linux-gnueabi/libc_pic.a
 -lgcc '-Wl,-)' 
-Wl,-Map,/OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/eglibc-2.16-r6+svnr19922/build-arm-oe-linux-gnueabi/elf/librtld.mapT
| 
/OE/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/libexec/armv4t-oe-linux-gnueabi.gcc-cross-initial/gcc/arm-oe-linux-gnueabi/4.7.2/ld:
 cannot find -lgcc
| collect2: error: ld returned 1 exit status
| make[2]: *** 
[/OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/eglibc-2.16-r6+svnr19922/build-arm-oe-linux-gnueabi/elf/librtld.map]
 Error 1
| make[2]: *** Waiting for unfinished jobs
| make[2]: Leaving directory 
`/OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/eglibc-2.16-r6+svnr19922/eglibc-2_16/libc/elf'
| make[1]: *** [elf/subdir_lib] Error 2
| make[1]: Leaving directory 
`/OE/shr-core/tmp-eglibc/work/armv4t-oe-linux-gnueabi/eglibc-2.16-r6+svnr19922/eglibc-2_16/libc'

Maybe it's because 
http://git.openembedded.org/openembedded-core/commit/?id=30617bde61a3b0a0944b49a0c9fb7159dacbb19f
is missing PR bump and gcc wasn't rebuilt before eglibc upgrade (OEBasic not 
OEBasicHash here).

Cheers,
-- 
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com


signature.asc
Description: Digital signature
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Classes

[Stewart, David C]

Seth - it sounds like you need something different than an overview class. I 
think you might want to have one of the consultants who are familiar with 
building projects using the Yocto Project work for you for a couple of days to 
help you sort these things out, for a fee. I'm sure one of them on this mailing 
list would be willing to offer their help. (Guys - you know who you are...)

Dave

From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Seth Bollinger
Sent: Monday, August 20, 2012 7:14 PM
To: yocto@yoctoproject.org
Subject: [yocto] Classes

Hello,

Will anyone recommend some classes regarding yocto and open embedded?  It would 
be nice to get up to speed quickly and into the nitty gritty instead of an 
overview.

Something covering the following items would be nice:

1.  How should projects be laid out?  Distro, image, task, BSP, what things 
should go where?
2.  How should subprojects inherit from superprojects?  If you need to create 
many subplatforms from a base platform, what's the best way to go about this?
3.  How should classes such as distutils be created to be inherited by other 
recipes (ruby modules that require a C extension to be compiled would be one 
example).
4.  How should hardware specific software be handled?

I fear that (as a newb) I will design a layout that will be sub-optimal, but 
we'll discover that after we have 25 platforms that will need major 
refactoring.  :)

Thanks,

Seth

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

Re: [yocto] [meta-fsl-ppc][PATCH 2/2] fsl.conf: Let linux-qoriq-sdk-headers-nativesdk provide linux-libc-headers-nativesdk

[David Nyström]

On 08/20/2012 09:50 PM, McClintock Matthew-B29882 wrote:

Adding David back...

-M

On Mon, Aug 20, 2012 at 2:42 PM, Matthew McClintock  wrote:

On Mon, Aug 20, 2012 at 2:27 PM, Khem Raj  wrote:

I just checked and we do have a few obscure bits in our kernel tree's
header files. Nothing that 99.9% would use but it seems reasonable to
include these...

Do you want applications for sdk host to be built using these obscure bits ?
if yes I would like to know why?

since then you are creating a scenariou where nativesdk is dependent on target
kernel and we need to fix it so that nativesdk can be common again.

if patches you are carrying are good for nativesdk headers can they be made
available for other kernels like linux-yocto e.g. ?

right now if we do this we are pretty much saying fsl machine layer can really
not mix with other BSPs. Many people use yocto commonly on more than one kind
of CPU and this does not scale.

Hmm I think I was just confused. We don't need any modifications for
the headers for nativesdk foo (that is the x86 tools in
meta-toolchain).

So, I think everything is OK as is.. if you look at meta-toolchain you
will see it includes our kernel's headers for cross compiling.

-M


Oh, sorry for the misunderstanding

I was under the impression that linux-libc-headers-nativesdk was 
installed under

/opt/poky/1.2/sysroots//..., which it obviously is not.

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

[yocto] How does bitbake work

[Liu]

Hi all,
 In order to learn to use poky,I am wondering how bitbake works with so 
many recipes. When I bitbake , I want to know how bitbake collect the 
providers of  . Then bitbake will prepare the runqueue tasks to build 
the .So I need to know which tasks to assign to build the .And 
bitbake run these tasks in what order.In other words according to the 
characteristics of what to decided to implement which task first and then next.
  I am very eager to know the answers.
  Thanks ,
 -- Yu Liu 
  Following is the some output of bitbake busybox and in this example I 
want to know why first do the task of (quilt-native_0.51.bb, do_fetch)  :
  
 Parsing recipes...done.
Parsing of 830 .bb files complete (0 cached, 830 parsed). 1106 targets, 34 
skipped, 0 masked, 0 errors.
 OE Build Configuration:
BB_VERSION= "1.15.2"
TARGET_ARCH   = "arm"
TARGET_OS = "linux-gnueabi"
MACHINE   = "qemuarm"
DISTRO= "poky"
DISTRO_VERSION= "1.2.1"
TUNE_FEATURES = "armv5 dsp thumb arm926ejs"
TARGET_FPU= "soft"
meta  
meta-yocto= ":"
 NOTE: Resolving any missing task queue dependencies
NOTE: multiple providers are available for virtual/arm-none-linux-gnueabi-g++ 
(external-csl-toolchain, gcc-cross)
NOTE: consider defining a PREFERRED_PROVIDER entry to match 
virtual/arm-none-linux-gnueabi-g++
NOTE: multiple providers are available for runtime linux-libc-headers-dev 
(linux-libc-headers, linux-libc-headers-yocto, 
linux-libc-headers-yocto-nativesdk)
NOTE: consider defining a PREFERRED_PROVIDER entry to match 
linux-libc-headers-dev
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Running task 1 of 706 (ID: 18, 
/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/quilt/quilt-native_0.51.bb,
 do_fetch)
NOTE: Running task 2 of 706 (ID: 228, 
virtual:native:/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/gnu-config/gnu-config_2011.bb,
 do_fetch)
NOTE: Running task 3 of 706 (ID: 189, 
virtual:native:/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/autoconf/autoconf_2.68.bb,
 do_fetch)
NOTE: Running task 4 of 706 (ID: 515, 
/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/m4/m4-native_1.4.16.bb, 
do_fetch)
NOTE: package gnu-config-native-2011-r1: task do_fetch: Started
NOTE: package m4-native-1.4.16-r2: task do_fetch: Started
NOTE: package quilt-native-0.51-r1: task do_fetch: Started
NOTE: package autoconf-native-2.68-r7: task do_fetch: Started
NOTE: package gnu-config-native-2011-r1: task do_fetch: Succeeded
NOTE: Running task 5 of 706 (ID: 224, 
virtual:native:/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/gnu-config/gnu-config_2011.bb,
 do_unpack)
NOTE: package gnu-config-native-2011-r1: task do_unpack: Started
NOTE: package gnu-config-native-2011-r1: task do_unpack: Succeeded
NOTE: Running task 6 of 706 (ID: 202, 
virtual:native:/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/automake/automake_1.11.2.bb,
 do_fetch)
NOTE: package automake-native-1.11.2-r3: task do_fetch: Started
NOTE: package m4-native-1.4.16-r2: task do_fetch: Succeeded
NOTE: Running task 7 of 706 (ID: 511, 
/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/m4/m4-native_1.4.16.bb, 
do_unpack)
NOTE: package m4-native-1.4.16-r2: task do_unpack: Started
NOTE: package m4-native-1.4.16-r2: task do_unpack: Succeeded
NOTE: Running task 8 of 706 (ID: 215, 
/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/libtool/libtool-native_2.4.2.bb,
 do_fetch)
NOTE: package autoconf-native-2.68-r7: task do_fetch: Succeeded
NOTE: Running task 9 of 706 (ID: 185, 
virtual:native:/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/autoconf/autoconf_2.68.bb,
 do_unpack)
NOTE: package libtool-native-2.4.2-r2.0: task do_fetch: Started
NOTE: package autoconf-native-2.68-r7: task do_unpack: Started
NOTE: package autoconf-native-2.68-r7: task do_unpack: Succeeded
NOTE: Running task 10 of 706 (ID: 254, 
virtual:native:/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-core/zlib/zlib_1.2.6.bb,
 do_fetch)
NOTE: package automake-native-1.11.2-r3: task do_fetch: Succeeded
NOTE: Running task 11 of 706 (ID: 198, 
virtual:native:/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/automake/automake_1.11.2.bb,
 do_unpack)
NOTE: package zlib-native-1.2.6-r1: task do_fetch: Started
NOTE: package automake-native-1.11.2-r3: task do_unpack: Started
NOTE: package automake-native-1.11.2-r3: task do_unpack: Succeeded
NOTE: Running task 12 of 706 (ID: 450, 
virtual:native:/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/pkgconfig/pkgconfig_0.25.bb,
 do_fetch)
NOTE: package pkgconfig-native-0.25-r3: task do_fetch: Started
WARNING: Failed to fetch URL http://www.zlib.net/zlib-1.2.6.tar.bz2
NOTE: package zlib-native-1.2.6-r1: task do_fetch: Succeeded
NOTE: Running task 13 of 706 (ID: 250, 
virtual:native:/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-core/zlib/zlib_1.2.6.bb,
 do_unpack)
NOTE: package zlib-n

[yocto] adding packages in my Yocto

[aaryak gautam]

Hello

I am  a hobbyist and quite new to both Linux and Yocto.
I had already compiled my Yocto kernel for I.MX23 successfully.
But I want to add few packages.
Like if i want to have ffmpeg in my yocto,how should I add it?
I have gone through the documentation,but could not understand.

can you help me out?
I am using Bitbake core-image-minimal , not sato.


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

[yocto] Request for photos

[Stewart, David C]

All - I'm prepping to give a talk at LinuxCon next week on an update to the 
Yocto Project, and I would like to create a slide which shows a bunch of 
devices which are based on YP.

Can you please send me a quick note with anything you know about to include 
here? Particularly nice if you have a photo or logo for the thing.

Thanks!!

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

Re: [yocto] How does bitbake work

[Stewart, David C]

I like the chapter Beth Flanagan wrote recently about the architecture of the 
Yocto Project. Check it out at the following link, and I think you might learn 
a lot.  I do suspect that what's happening for you is that certain native tools 
like quilt need to be built first so that other parts of the build will run. 
(Quilt is used to manage the patches that applied in the build process).

Dave

http://www.aosabook.org/en/yocto.html

From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Liu
Sent: Tuesday, August 21, 2012 1:11 AM
To: yocto
Subject: [yocto] How does bitbake work

Hi all,
In order to learn to use poky,I am wondering how bitbake works with so many 
recipes. When I bitbake , I want to know how bitbake collect the 
providers of  . Then bitbake will prepare the runqueue tasks to build 
the .So I need to know which tasks to assign to build the .And 
bitbake run these tasks in what order.In other words according to the 
characteristics of what to decided to implement which task first and then next.
 I am very eager to know the answers.
 Thanks ,
-- Yu Liu
 Following is the some output of bitbake busybox and in this example I want 
to know why first do the task of (quilt-native_0.51.bb, do_fetch)  :

Parsing recipes...done.
Parsing of 830 .bb files complete (0 cached, 830 parsed). 1106 targets, 34 
skipped, 0 masked, 0 errors.
OE Build Configuration:
BB_VERSION= "1.15.2"
TARGET_ARCH   = "arm"
TARGET_OS = "linux-gnueabi"
MACHINE   = "qemuarm"
DISTRO= "poky"
DISTRO_VERSION= "1.2.1"
TUNE_FEATURES = "armv5 dsp thumb arm926ejs"
TARGET_FPU= "soft"
meta
meta-yocto= ":"
NOTE: Resolving any missing task queue dependencies
NOTE: multiple providers are available for virtual/arm-none-linux-gnueabi-g++ 
(external-csl-toolchain, gcc-cross)
NOTE: consider defining a PREFERRED_PROVIDER entry to match 
virtual/arm-none-linux-gnueabi-g++
NOTE: multiple providers are available for runtime linux-libc-headers-dev 
(linux-libc-headers, linux-libc-headers-yocto, 
linux-libc-headers-yocto-nativesdk)
NOTE: consider defining a PREFERRED_PROVIDER entry to match 
linux-libc-headers-dev
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Running task 1 of 706 (ID: 18, 
/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/quilt/quilt-native_0.51.bb,
 do_fetch)
NOTE: Running task 2 of 706 (ID: 228, 
virtual:native:/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/gnu-config/gnu-config_2011.bb,
 do_fetch)
NOTE: Running task 3 of 706 (ID: 189, 
virtual:native:/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/autoconf/autoconf_2.68.bb,
 do_fetch)
NOTE: Running task 4 of 706 (ID: 515, 
/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/m4/m4-native_1.4.16.bb, 
do_fetch)
NOTE: package gnu-config-native-2011-r1: task do_fetch: Started
NOTE: package m4-native-1.4.16-r2: task do_fetch: Started
NOTE: package quilt-native-0.51-r1: task do_fetch: Started
NOTE: package autoconf-native-2.68-r7: task do_fetch: Started
NOTE: package gnu-config-native-2011-r1: task do_fetch: Succeeded
NOTE: Running task 5 of 706 (ID: 224, 
virtual:native:/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/gnu-config/gnu-config_2011.bb,
 do_unpack)
NOTE: package gnu-config-native-2011-r1: task do_unpack: Started
NOTE: package gnu-config-native-2011-r1: task do_unpack: Succeeded
NOTE: Running task 6 of 706 (ID: 202, 
virtual:native:/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/automake/automake_1.11.2.bb,
 do_fetch)
NOTE: package automake-native-1.11.2-r3: task do_fetch: Started
NOTE: package m4-native-1.4.16-r2: task do_fetch: Succeeded
NOTE: Running task 7 of 706 (ID: 511, 
/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/m4/m4-native_1.4.16.bb, 
do_unpack)
NOTE: package m4-native-1.4.16-r2: task do_unpack: Started
NOTE: package m4-native-1.4.16-r2: task do_unpack: Succeeded
NOTE: Running task 8 of 706 (ID: 215, 
/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/libtool/libtool-native_2.4.2.bb,
 do_fetch)
NOTE: package autoconf-native-2.68-r7: task do_fetch: Succeeded
NOTE: Running task 9 of 706 (ID: 185, 
virtual:native:/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/autoconf/autoconf_2.68.bb,
 do_unpack)
NOTE: package libtool-native-2.4.2-r2.0: task do_fetch: Started
NOTE: package autoconf-native-2.68-r7: task do_unpack: Started
NOTE: package autoconf-native-2.68-r7: task do_unpack: Succeeded
NOTE: Running task 10 of 706 (ID: 254, 
virtual:native:/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-core/zlib/zlib_1.2.6.bb,
 do_fetch)
NOTE: package automake-native-1.11.2-r3: task do_fetch: Succeeded
NOTE: Running task 11 of 706 (ID: 198, 
virtual:native:/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/automake/automake_1.11.2.bb,
 do_unpack)
NOTE: package zlib-native-1.2.6-r1: task do_fetch: Started
NOTE: package automake-native-1.11.2

Re: [yocto] adding packages in my Yocto

[Jeff Osier-Mixon]

Hi - please take a look at the FAQ here: https://wiki.yoctoproject.org/wiki/FAQ

Near the bottom there are some technical answers, one of which is how
to add a single package:

Q: How can I add a package to my project?

A: As with any complex system, the real answer is it depends, but of
course that is not very helpful. The simplest method for adding a
single package to your build is to add a line like this to
conf/local.conf:

   IMAGE_INSTALL_append += " package"

Use your own package name in place of package. Note the leading space
before the package name.
For more information, read this chapter in the Yocto Project
Development Manual
(http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#usingpoky-extend-addpkg).

I also highly recommend trying out the Hob interface, as it makes the
whole system easier to understand. I like to make changes in the Hob
and then examine those changes in the resulting configuration files to
better understand the system at work.

Hope this helps!

On Tue, Aug 21, 2012 at 1:26 AM, aaryak gautam  wrote:
> Hello
>
> I am  a hobbyist and quite new to both Linux and Yocto.
> I had already compiled my Yocto kernel for I.MX23 successfully.
> But I want to add few packages.
> Like if i want to have ffmpeg in my yocto,how should I add it?
> I have gone through the documentation,but could not understand.
>
> can you help me out?
> I am using Bitbake core-image-minimal , not sato.
>
>
> Thank You.
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>



-- 
Jeff Osier-Mixon http://jefro.net/blog
Yocto Project Community Manager @Intel http://yoctoproject.org
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] adding packages in my Yocto

[Robert P. J. Day]

On Tue, 21 Aug 2012, Jeff Osier-Mixon wrote:

> Hi - please take a look at the FAQ here: 
> https://wiki.yoctoproject.org/wiki/FAQ
>
> Near the bottom there are some technical answers, one of which is how
> to add a single package:
>
> Q: How can I add a package to my project?
>
> A: As with any complex system, the real answer is it depends, but of
> course that is not very helpful. The simplest method for adding a
> single package to your build is to add a line like this to
> conf/local.conf:
>
>IMAGE_INSTALL_append += " package"

   grr ...^ "="

the "+=" is redundant.

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] adding packages in my Yocto

[Stewart, David C]

Good advice. A quick check of openembedded-core shows that gst-ffmpeg appears 
to be one of the packages available. Yes, definitely check the hob.

>-Original Message-
>From: yocto-boun...@yoctoproject.org [mailto:yocto-
>boun...@yoctoproject.org] On Behalf Of Jeff Osier-Mixon
>Sent: Tuesday, August 21, 2012 9:01 AM
>To: aaryak gautam
>Cc: Yocto Project
>Subject: Re: [yocto] adding packages in my Yocto
>
>Hi - please take a look at the FAQ here:
>https://wiki.yoctoproject.org/wiki/FAQ
>
>Near the bottom there are some technical answers, one of which is how
>to add a single package:
>
>Q: How can I add a package to my project?
>
>A: As with any complex system, the real answer is it depends, but of
>course that is not very helpful. The simplest method for adding a
>single package to your build is to add a line like this to
>conf/local.conf:
>
>   IMAGE_INSTALL_append += " package"
>
>Use your own package name in place of package. Note the leading space
>before the package name.
>For more information, read this chapter in the Yocto Project
>Development Manual
>(http://www.yoctoproject.org/docs/current/dev-manual/dev-
>manual.html#usingpoky-extend-addpkg).
>
>I also highly recommend trying out the Hob interface, as it makes the
>whole system easier to understand. I like to make changes in the Hob
>and then examine those changes in the resulting configuration files to
>better understand the system at work.
>
>Hope this helps!
>
>On Tue, Aug 21, 2012 at 1:26 AM, aaryak gautam 
>wrote:
>> Hello
>>
>> I am  a hobbyist and quite new to both Linux and Yocto.
>> I had already compiled my Yocto kernel for I.MX23 successfully.
>> But I want to add few packages.
>> Like if i want to have ffmpeg in my yocto,how should I add it?
>> I have gone through the documentation,but could not understand.
>>
>> can you help me out?
>> I am using Bitbake core-image-minimal , not sato.
>>
>>
>> Thank You.
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>
>
>
>--
>Jeff Osier-Mixon http://jefro.net/blog
>Yocto Project Community Manager @Intel http://yoctoproject.org
>___
>yocto mailing list
>yocto@yoctoproject.org
>https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Documenting the mailing lists.

[Darren Hart]

On 08/20/2012 04:19 PM, Paul Eggleton wrote:
> On Monday 20 August 2012 15:50:37 Darren Hart wrote:
>> On 08/20/2012 03:43 PM, Jeff Osier-Mixon wrote:
>>> On Mon, Aug 20, 2012 at 3:37 PM, Darren Hart  
> wrote:
 On 08/20/2012 03:18 PM, Jeff Osier-Mixon wrote:
> The mailing lists and website stuff is generally my responsibility,
> but please fix anything you like. :)  Be aware that the new website is

 No intent to take over anything, I've just had to answer the "what goes
 where" question a few too many times these last couple of weeks and felt
 I should do something about it :-)
>>>
>>> Oh, I'm not joking - please fix anything you want! or Scott or I can
>>> do it. Thanks for getting the ball rolling. I'll catch up on this
>>> thread.
>>>
 I made sure you were on CC so you could help guide this.

> under construction, so I am loathe to change much on the old website
> at this point.  For the new one, it may be possible to dynamically
> grab the description from mailman.

 We'll still need descriptions of the non-yocto-project lists, so that
 may not be particularly helpful.
>>>
>>> The only YP-related, non-YP lists I currently track are
>>> openembedded-core and bitbake-devel.  Both are OE lists, and I have
>>> recently volunteered to help admin, so can make sure they have valid
>>> Descriptions. If there are other lists we should track, please let me
>>> know and I'll add them to the pile.
>>
>> The only additional one that we reference in the manual is:
>>
>> *http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>> - Discussion mailing list about OpenEmbedded.
>>
>> I'm not sure we need reference it at all though, perhaps oe-core is
>> sufficient.
> 
> FYI, the reason I added oe-devel is because it's the list that is used to 
> discuss/submit patches for almost all OE community layers other than OE-Core 
> and the ones that are hosted on yoctoproject.org.

Fair enough.

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] ia32-base.inc: Drop glibc --with-tls option, its now the only option for glibc

[Darren Hart]

On 08/21/2012 12:13 AM, Richard Purdie wrote:
> This option is unused by (e)glibc since 2011 and is the default. It has been
> shown to interact badly with the configure option in atom-pc from meta-yocto 
> causing a rebuild of the whole system despite the only change being an 
> assignment with += vs =. The easiest fix is simply to drop it.
> 
> Signed-off-by: Richard Purdie 

Seems clearly correct.

Acked-by: Darren Hart 



> 
> diff --git a/conf/machine/include/ia32-base.inc 
> b/conf/machine/include/ia32-base.inc
> index 99ac352..17ff714 100644
> --- a/conf/machine/include/ia32-base.inc
> +++ b/conf/machine/include/ia32-base.inc
> @@ -21,7 +21,6 @@ SERIAL_CONSOLE ?= "115200 ttyS0"
>  # glibc-related variables
>  #
>  GLIBC_ADDONS ?= "nptl"
> -GLIBC_EXTRA_OECONF += "--with-tls"
>  
>  #
>  # kernel-related variables
> 
> 


-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] adding packages in my Yocto

[Paul Eggleton]

On Tuesday 21 August 2012 12:16:26 Robert P. J. Day wrote:
> On Tue, 21 Aug 2012, Jeff Osier-Mixon wrote:
> > Hi - please take a look at the FAQ here:
> > https://wiki.yoctoproject.org/wiki/FAQ
> > 
> > Near the bottom there are some technical answers, one of which is how
> > to add a single package:
> > 
> > Q: How can I add a package to my project?
> > 
> > A: As with any complex system, the real answer is it depends, but of
> > course that is not very helpful. The simplest method for adding a
> > single package to your build is to add a line like this to
> > 
> > conf/local.conf:
> >IMAGE_INSTALL_append += " package"
> 
>grr ...^ "="
> 
> the "+=" is redundant.

Fixed.

Cheers,
Paul

-- 

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

Re: [yocto] adding packages in my Yocto

[Robert P. J. Day]

On Tue, 21 Aug 2012, Paul Eggleton wrote:

> On Tuesday 21 August 2012 12:16:26 Robert P. J. Day wrote:
> > On Tue, 21 Aug 2012, Jeff Osier-Mixon wrote:
> > > Hi - please take a look at the FAQ here:
> > > https://wiki.yoctoproject.org/wiki/FAQ
> > >
> > > Near the bottom there are some technical answers, one of which is how
> > > to add a single package:
> > >
> > > Q: How can I add a package to my project?
> > >
> > > A: As with any complex system, the real answer is it depends, but of
> > > course that is not very helpful. The simplest method for adding a
> > > single package to your build is to add a line like this to
> > >
> > > conf/local.conf:
> > >IMAGE_INSTALL_append += " package"
> >
> >grr ...^ "="
> >
> > the "+=" is redundant.
>
> Fixed.

  if there's no objection, i added how to add multiple packages as
well, just below 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

Re: [yocto] Toolchain rework, call for testing

[Khem Raj]

On Tue, Aug 21, 2012 at 5:18 AM, Martin Jansa  wrote:
>
> Maybe it's because
> http://git.openembedded.org/openembedded-core/commit/?id=30617bde61a3b0a0944b49a0c9fb7159dacbb19f
> is missing PR bump and gcc wasn't rebuilt before eglibc upgrade (OEBasic not 
> OEBasicHash here).

yes seems so. I have stopped using OEBasic long ago, you should stop
using it too.
But feel free to send a PR bump patchlet.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] https://bugzilla.yoctoproject.org/show_bug.cgi?id=1649

[Darren Hart]

On 08/20/2012 09:13 PM, Bruce Ashfield wrote:

>>> +Kernel types (ktypes) are the highest level policy containers and represent
>>> +a significant set of kernel functionality that has been grouped (and named)
>>> +or partitioned.
>>
>> What are you trying to convey with "partitioned" vs. "grouped" ? The
>> "or" indicates a functional difference, but it isn't clear what that is
>> from this reading.
> 
> partitioned means that they are really being kept apart since they won't
> work together (think BFS vs CFS, or grsec vs another security patch). 
> Grouped
> just means that you have 15 or 20 things that you want to collectively
> call a "kernel type" and validate that they work together in a particular
> configuration. But there's no fundamental incompatibility between these
> features and others in the system.
> 
> It's a hard vs soft partitioning.
> 
> Would the expansion that I have above help ?

Hrm, nah. Let's leave it and address it if someone else raises a
concern. I might be alone here.

>>> + - behaviour. A kernel type defines a default behaviour, which is often a
>>
>> behaviour: a kernel type ...
> 
> You left my Canadian behaviour .. my spell checker thanks you! Fixed.

With a UK architect it seemed presumptuous to do otherwise ;-)

>>> +named category. These typically are included by kernel types, and are not
>>> +meant to implement a defined functionality or be included multiple times.
>>> +
>>> +These often contain bug fixes, backports or other small changes to the 
>>> kernel
>>> +tree, and do not typically contain any kernel configuration fragments. 
>>> patches
>>
>> typically? How can a patch contain a config change?
> 
> That just means that a directory called 'patches' vs 'features' wouldn't
> contain associated config fragments to enable that functionality. But since
> the system is flexible, there's no reason they can't, so I went with
> "typically" :) I can clarify.

Yeah... I think we need to kill config vs feature vs patches and merge
them together into a single term. Having the three seems to add more
confusion than information.

What do you see as the value for maintaining the 3 concepts separately?

>>> +Config groups are collections of configuration options that when included
>>> +enable a specific behaviour or functionality. Configuration groups do not
>>> +contain patches, and can be included multiple times by any other feature or
>>> +kernel type. The impact of configuration groups is additive, and order
>>> +matters, since the last included config group can override the behaviour of
>>> +previous includes.
>>
>> Is this the same thing as "config fragment"? If so, we should pick one
>> and be consistent. If not, how do they differ?
> 
> I was more thinking about the "cfg" subdir and the .scc file that includes
> a .cfg when I wrote this. The foo.cfg is the config fragment, the named
> group is the .scc file + the .cfg.
> 
> I'm not sure it is worth splitting the hair here. I can just go with
> configuration fragment. How does that sound ?

You're right, the config .scc file is not a config fragment, the .cfg
files are. So a config group includes one or more config fragments. Got it.


>>> +Note: Depending on the architecture of the meta data, configuration groups
>>> +can be complete, or partitioned. Complete config groups contain all the

^ comma should be removed

>>> +options required to enable functionality, partitioned configurations rely 
>>> on
>>> +multiple includes to build up a set of non overlapping options to enable
>>
>> non-overlapping
>>
>>> +functionality. Complete groups are simpler to include, but make it more
>>> +difficult to remove or disable an option (since it can appear multiple
>>> +times),
>>
>> If a config fragment includes another one - isn't the end result the same?
> 
> which part ? The appear multiple times ? Yes, you can end up with thing
> via fragments that include others, but not if you've partitioned them
> all.


complete.scc
  include complete.cfg

complete.cfg
  CONFIG_A=y
  CONFIG_B=y

partitioned.scc
  include partitioned_a.cfg
  include partitioned_b.cfg

partitioned_a.cfg
  CONFIG_A=y

partitioned_b.cfg
  CONFIG_B=y

This is how I understood your description. Assuming I have this right,
there is no difference between including compelte.scc or
partitioned.scc. Each will pull in all the same CONFIG* options and
modify/overwrite/etc any existing settings in exactly the same way. This
is what I meant by "same end result".

I guess what you're saying is the partitioned approach is more modular
and allows for changing a specific option in one place (CONFIG_A in
partitioned_a.cfg which will roll up into partitioned.scc) rather than
having several scc's similar to complete.scc which all need to be
modidfied to change CONFIG_A.

That could probably be made clearer.

>>> +supports and is the typical entry point of a build system to the
>>> +configuration data of the meta branch.
>>
>> For whatever reason, that reads as ve

Re: [yocto] adding packages in my Yocto

[Paul Eggleton]

On Tuesday 21 August 2012 12:51:41 Robert P. J. Day wrote:
> On Tue, 21 Aug 2012, Paul Eggleton wrote:
> > On Tuesday 21 August 2012 12:16:26 Robert P. J. Day wrote:
> > > On Tue, 21 Aug 2012, Jeff Osier-Mixon wrote:
> > > > Hi - please take a look at the FAQ here:
> > > > https://wiki.yoctoproject.org/wiki/FAQ
> > > > 
> > > > Near the bottom there are some technical answers, one of which is how
> > > > to add a single package:
> > > > 
> > > > Q: How can I add a package to my project?
> > > > 
> > > > A: As with any complex system, the real answer is it depends, but of
> > > > course that is not very helpful. The simplest method for adding a
> > > > single package to your build is to add a line like this to
> > > > 
> > > > conf/local.conf:
> > > >IMAGE_INSTALL_append += " package"
> > >
> > >grr ...^ "="
> > > 
> > > the "+=" is redundant.
> > 
> > Fixed.
> 
>   if there's no objection, i added how to add multiple packages as
> well, just below that.

Looks good to me, thanks.

Cheers,
Paul

-- 

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

Re: [yocto] [OE-core] RFC: OE-Core task rework

[Philip Balister]

On 08/21/2012 01:49 AM, Paul Eggleton wrote:

On Monday 20 August 2012 15:45:07 Mark Hatle wrote:

...



Yup, there is a logical grouping for the lsb specific tasks, as for others.
The naming needs to be made clear as to why it's there, and what it
represents. Same with the summary and descriptions -- they should list the
functionality provided by this group of components.


The main concern with LSB is that we have something called task-basic, which
seems to be intended for LSB but does not state as much, and I know at least
one person has tried to use it and then been a little puzzled as to why rpm
has been pulled in when ipk packaging has been selected. Just naming some of
these tasks more appropriately would help avoid such situations. In the
specific case of task-basic there may be a case for creating a similar but not
LSB-focused task that pulls in real shell utilities in preference to the light
versions provided by busybox.


I was seriously stumped by the presence of rpm in what I felt should 
have been a very basic image. If a task/group is targeted at lsb, it 
needs to have lsb plastered all over the name so the rest of us can 
avoid it :)


Philip




4) Consider the usefulness of the existing PACKAGE_GROUP_ structure which
converts some IMAGE_FEATURES into the addition of tasks to be installed
(see classes/core-image.bbclass). At the very least we should probably
rename this if we rename tasks to package groups, and there's a question
as to how IMAGE_FEATURES scales - should every task be represented in
there or only a select list? Would we be better off not trying to bring
any tasks in via IMAGE_FEATURES at all and mostly leave that to control
post-processing (e.g. package-management, debug-tweaks, etc.)?


I'd certainly prefer that images were limited to selecting software from
task (group) recipes only, and not providing their own.  An image should be
able to change the selection based on an "image feature" or similar
configuration, but the underlying tasks/groups, recipes, etc should all be
'generic' to a given distribution configuration.


The first part seems reasonable to me; but I'm still short of an answer as to
what to do with the existing IMAGE_FEATURES code as mentioned above. At the
moment aside from the special features such as debug-tweaks, these are just a
thin layer on top of task recipes which doesn't add very much at all other
than extra maintenance.


I think if you go through the images today, a lot of that stuff is either
old, or could be simplified by creating appropriate tasks/groups.


OK, that's a good point. I have another task on my list to clean up our image
recipes and that would be a good segue into that.

Cheers,
Paul


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

Re: [yocto] yocto-bsp create

[Tom Zanussi]

On Fri, 2012-08-17 at 20:56 +0100, Chris Tapp wrote:
> On 17 Aug 2012, at 20:47, Bruce Ashfield wrote:
> 
> > On 12-08-17 03:40 PM, Chris Tapp wrote:
> >> 
> >> On 17 Aug 2012, at 20:33, Bruce Ashfield wrote:
> >> 
> >>> On 12-08-17 03:32 PM, Chris Tapp wrote:
>  On 17 Aug 2012, at 15:59, Bruce Ashfield wrote:
>  
> > On 12-08-17 06:47 AM, Chris Tapp wrote:
> >> 
> >> On 17 Aug 2012, at 00:48, Bruce Ashfield wrote:
> >> 
> >>> ech. That means that the tree was somehow dirty and branches couldn't
> >>> be switched/checked out.
> >>> 
> >>> If you have a copy of your BSP layer, I can try a build here and shed
> >>> some light on what exactly went wrong.
> >> 
> >> 
> >> Thanks Bruce. Meta layer attached.
> > 
> > Fixed here. This was completely generated from the tools ? If so, the
> > branching information was wrong.
> > 
> > KBRANCH_LX800  = "standard/default/LX800"
> > YOCTO_KERNEL_EXTERNAL_BRANCH_LX800  = "standard/default/LX800"
> > 
> > The "base" is always inferred and only exists because of the
> > way that git manages refs on disk. So the branch that you
> > want to build is what I have above, and the tools will
> > automatically make that branch point off the default/base
> > branch.
> > 
> > Let me know if that did come from the tools and I'll follow
> > up to the list.
>  
>  I'm 99.99% sure it did, but it runs ok after making the changes you give 
>  above, deleting tmp/ and rebuilding.
>  
>  I've not g0t any real changes in yet, so I'll go try again and see what 
>  I get. It's just possible I didn't do a complete rebuild (i.e. nuke 
>  tmp/) which may have caused a problem last time round.
> >>> 
> >>> ok. cool. no rush. I was just going to do a final update on the mailing
> >>> list to not leave it hanging, and if there's a bug in the scripts, we
> >>> can let Tom know .. so he can fix it!
> >> 
> >> 
> >> I've just recreated the BSP. I selected option 4 for the kernel branch 
> >> (standard/default/base), which gives:
> >> 
> >> KBRANCH_LX800  = "standard/default/base/LX800"
> >> YOCTO_KERNEL_EXTERNAL_BRANCH_LX800  = "standard/default/base/LX800"
> > 
> > ok. Worth firing off a bug report to Tom Zaunussi. .. that
> > won't work .. ever.
> 
> Just bringing this back on-list.
> 
> I'll get something added to the tracker.
> 

Just back from vacation and getting to this...

Yeah, this is a known bug and was fixed by the yocto-bsp patchsets I
sent out just before I left.  See the last entry in the bug below for
links to the branches that fixed it and a few other issues:

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

I see that the denzil branch has been updated with the changes, but have
yet to hit master.

Tom

> Chris Tapp
> 
> opensou...@keylevel.com
> www.keylevel.com
> 
> 
> 
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto


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

[yocto] ERROR: QA Issue: No GNU_HASH in the elf binary

[Saxena, Rahul]

Hi,

I am using  poky/1.3_M3 branch and I get a bunch of "ERROR: QA Issue: No 
GNU_HASH in the elf binary:"

My recipe is for installing binary files only.
I have the following statement in my recipe:

INSANE_SKIP_${PN} = "ldflags"

But I still get the errors ..any suggestions ?

WARNING: File '/usr/lib/libEGL.so.1' from cdv-pvr-driver was already stripped, 
this will prevent future debugging!
WARNING: File '/usr/lib/libGLESv2.so.2' from cdv-pvr-driver was already 
stripped, this will prevent future debugging!
ERROR: QA Issue: No GNU_HASH in the elf binary: 
'/home/rsaxena/YoctoWork1/cedartrail6/tmp/work/core2-poky-linux/cdv-pvr-driver-1.0.2-r1/packages-split/cdv-pvr-driver-dev/usr/lib/libpvrPVR2D_LINUXFBWSEGL.so'
ERROR: QA Issue: No GNU_HASH in the elf binary: 
'/home/rsaxena/YoctoWork1/cedartrail6/tmp/work/core2-poky-linux/cdv-pvr-driver-1.0.2-r1/packages-split/cdv-pvr-driver-dev/usr/lib/libpvrPVR2D_DRIWSEGL.so'
ERROR: QA Issue: No GNU_HASH in the elf binary: 
'/home/rsaxena/YoctoWork1/cedartrail6/tmp/work/core2-poky-linux/cdv-pvr-driver-1.0.2-r1/packages-split/cdv-pvr-driver-dev/usr/lib/libPVROGL_MESA.so'
ERROR: QA Issue: No GNU_HASH in the elf binary: 
'/home/rsaxena/YoctoWork1/cedartrail6/tmp/work/core2-poky-linux/cdv-pvr-driver-1.0.2-r1/packages-split/cdv-pvr-driver-dev/usr/lib/libOpenVGU.so'
ERROR: QA Issue: No GNU_HASH in the elf binary: 
'/home/rsaxena/YoctoWork1/cedartrail6/tmp/work/core2-poky-linux/cdv-pvr-driver-1.0.2-r1/packages-split/cdv-pvr-driver-dev/usr/lib/libpvrPVR2D_BLITWSEGL.so'
ERROR: QA Issue: No GNU_HASH in the elf binary: 
'/home/rsaxena/YoctoWork1/cedartrail6/tmp/work/core2-poky-linux/cdv-pvr-driver-1.0.2-r1/packages-split/cdv-pvr-driver-dev/usr/lib/libpvrPVR2D_FLIPWSEGL.so'


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

Re: [yocto] ERROR: QA Issue: No GNU_HASH in the elf binary

[Khem Raj]

On Tue, Aug 21, 2012 at 11:03 AM, Saxena, Rahul  wrote:
> cdv-pvr-driver-dev/usr/lib/libOpenVGU.so

this seems to be a proper file and not a symlink so firstly you have
.so in -dev packages
if you fix that it will work secondly if you intentionally want those
.so in -dev package
then add

INSANE_SKIP_${PN}-dev = "ldflags"

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

Re: [yocto] How does bitbake work

[Tim Bird]

On 08/21/2012 01:11 AM, Liu wrote:
> Hi all,
>  In order to learn to use poky,I am wondering how bitbake works with so 
> many 
> recipes. When I bitbake , I want to know how bitbake collect the 
> providers of  . Then bitbake will prepare the runqueue tasks to build 
> the .So I need to know which tasks to assign to build the 
> .And 
> bitbake run these tasks in what order.In other words according to the 
> characteristics of what to decided to implement which task first and then 
> next.
>   I am very eager to know the answers.

I'm not an expert, but here's some information that I believe is correct.
(If someone else knows better, please correct this...)

bitbake reads the entire set of recipe files that are specified by
the local configuration, and parses them all into a global task namespace.
This includes all the class files and include files as well.  These
are specified by the BBFILES and BBLAYERS variables in the conf/bblayers.conf
file.  Within the layers directories, the /conf/layer.conf
file is used to indicate the set of .bb files to parse for that layer.

Note that this global parse of the entire set of recipe files is
quite different from 'make', which usually operated on a single Makefile.
(This is also why bitbake startup is a little slow).

Information in the meta-data (the DEPENDS and PROVIDES lines) determine
package ordering.  Where packages are independent of each other, the
build order is dependent (I believe) on file parse order.  In this case,
processing is not required to be in any particular order (and, in fact,
can be parallelized). You can have bitbake produce the dependency graph
of the packages for your build by using the -g option.  This produces output in
'dot' syntax (suitable for processing using some graphviz visualizer).

The list of tasks to perform within a package appears to come
from the common class meta-data
(see meta/classes/utility-tasks.bbclass, for example) and the
meta-data for the individual package  These are added by
the 'addtask' keyword.  You can see a list of tasks for an
individual package with: bitbake  -c listtasks

I have started to put together an overview introduction of Yocto at:
http://elinux.org/Yocto_Project_Introduction

I haven't gotten much completed yet, but I do discuss bitbake there
a bit.  Hopefully what I've got so far will be helpful.
 -- Tim

P.S. someone correct me if I'm wrong.

>   Thanks ,
> -- Yu Liu
>   Following is the some output of bitbake busybox and in this example I 
> want 
> to know why first do the task of (quilt-native_0.51.bb, do_fetch)  :
> Parsing recipes...done.
> Parsing of 830 .bb files complete (0 cached, 830 parsed). 1106 targets, 34 
> skipped, 0 masked, 0 errors.
> OE Build Configuration:
> BB_VERSION= "1.15.2"
> TARGET_ARCH   = "arm"
> TARGET_OS = "linux-gnueabi"
> MACHINE   = "qemuarm"
> DISTRO= "poky"
> DISTRO_VERSION= "1.2.1"
> TUNE_FEATURES = "armv5 dsp thumb arm926ejs"
> TARGET_FPU= "soft"
> meta
> meta-yocto= ":"
> NOTE: Resolving any missing task queue dependencies
> NOTE: multiple providers are available for virtual/arm-none-linux-gnueabi-g++ 
> (external-csl-toolchain, gcc-cross)
> NOTE: consider defining a PREFERRED_PROVIDER entry to match 
> virtual/arm-none-linux-gnueabi-g++
> NOTE: multiple providers are available for runtime linux-libc-headers-dev 
> (linux-libc-headers, linux-libc-headers-yocto, 
> linux-libc-headers-yocto-nativesdk)
> NOTE: consider defining a PREFERRED_PROVIDER entry to match 
> linux-libc-headers-dev
> NOTE: Preparing runqueue
> NOTE: Executing SetScene Tasks
> NOTE: Executing RunQueue Tasks
> NOTE: Running task 1 of 706 (ID: 18, 
> /home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/quilt/quilt-native_0.51.bb,
>  
> do_fetch)
> NOTE: Running task 2 of 706 (ID: 228, 
> virtual:native:/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/gnu-config/gnu-config_2011.bb,
>  
> do_fetch)
> NOTE: Running task 3 of 706 (ID: 189, 
> virtual:native:/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/autoconf/autoconf_2.68.bb,
>  
> do_fetch)
> NOTE: Running task 4 of 706 (ID: 515, 
> /home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/m4/m4-native_1.4.16.bb,
>  
> do_fetch)
> NOTE: package gnu-config-native-2011-r1: task do_fetch: Started
> NOTE: package m4-native-1.4.16-r2: task do_fetch: Started
> NOTE: package quilt-native-0.51-r1: task do_fetch: Started
> NOTE: package autoconf-native-2.68-r7: task do_fetch: Started
> NOTE: package gnu-config-native-2011-r1: task do_fetch: Succeeded
> NOTE: Running task 5 of 706 (ID: 224, 
> virtual:native:/home/ly/yocto/poky-denzil-7.0.1/meta/recipes-devtools/gnu-config/gnu-config_2011.bb,
>  
> do_unpack)
> NOTE: package gnu-config-native-2011-r1: task do_unpack: Started
> NOTE: package gnu-config-native-2011-r1: task do_unpack: Succeeded
> NOTE: Running task 6 of 706 (ID: 202, 
> virtual:native:/home/ly/yocto/poky-denzil-7.0

Re: [yocto] Toolchain rework, call for testing

[Martin Jansa]

On Tue, Aug 21, 2012 at 10:15:47AM -0700, Khem Raj wrote:
> On Tue, Aug 21, 2012 at 5:18 AM, Martin Jansa  wrote:
> >
> > Maybe it's because
> > http://git.openembedded.org/openembedded-core/commit/?id=30617bde61a3b0a0944b49a0c9fb7159dacbb19f
> > is missing PR bump and gcc wasn't rebuilt before eglibc upgrade (OEBasic 
> > not OEBasicHash here).
> 
> yes seems so. I have stopped using OEBasic long ago, you should stop
> using it too.

I'm using OEBasicHash on one jenkins setup, but that one is still
building changes from 2 days ago.. (building 24/7.. )

> But feel free to send a PR bump patchlet.

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


signature.asc
Description: Digital signature
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] ERROR: QA Issue: No GNU_HASH in the elf binary

[Saxena, Rahul]

You are right, these are regular files and not symlinks and are ending up in 
usr/lib in packagename-dev package
However I want them to be in the regular package.

I do have the following statement in my recipe:

FILES_${PN} += "${libdir}/lib*.so"

and nothing in my recipe has statements such as FILES_${PN)-dev = ...


So it seems that the build is making a assumption these are symlinks and
and should necessarily go into -dev package ignoring my above statement in the 
above. How do I fix this ?
The denzel branch of poky does not have this behavior, I checked that it is not 
putting any .so files in -dev package.

Thanks
Rahul
 

-Original Message-
From: Khem Raj [mailto:raj.k...@gmail.com] 
Sent: Tuesday, August 21, 2012 11:09 AM
To: Saxena, Rahul
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] ERROR: QA Issue: No GNU_HASH in the elf binary

On Tue, Aug 21, 2012 at 11:03 AM, Saxena, Rahul  wrote:
> cdv-pvr-driver-dev/usr/lib/libOpenVGU.so

this seems to be a proper file and not a symlink so firstly you have .so in 
-dev packages if you fix that it will work secondly if you intentionally want 
those .so in -dev package then add

INSANE_SKIP_${PN}-dev = "ldflags"

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

Re: [yocto] ERROR: QA Issue: No GNU_HASH in the elf binary

[Chris Larson]

On Tue, Aug 21, 2012 at 12:05 PM, Saxena, Rahul  wrote:
> You are right, these are regular files and not symlinks and are ending up in 
> usr/lib in packagename-dev package
> However I want them to be in the regular package.
>
> I do have the following statement in my recipe:
>
> FILES_${PN} += "${libdir}/lib*.so"
>
> and nothing in my recipe has statements such as FILES_${PN)-dev = ...


Read oe-core/meta/conf/bitbake.conf.
-- 
Christopher Larson
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] ERROR: QA Issue: No GNU_HASH in the elf binary

[Saxena, Rahul]

oe-core/meta/conf/bitbake.conf specifies the default package settings.
However the problem I seem to be seeing is that my recipe is not able to 
override the default.

However let me know if I should still be looking at that file..

Rahul

-Original Message-
From: kerg...@gmail.com [mailto:kerg...@gmail.com] On Behalf Of Chris Larson
Sent: Tuesday, August 21, 2012 12:07 PM
To: Saxena, Rahul
Cc: Khem Raj; yocto@yoctoproject.org
Subject: Re: [yocto] ERROR: QA Issue: No GNU_HASH in the elf binary

On Tue, Aug 21, 2012 at 12:05 PM, Saxena, Rahul  wrote:
> You are right, these are regular files and not symlinks and are ending 
> up in usr/lib in packagename-dev package However I want them to be in the 
> regular package.
>
> I do have the following statement in my recipe:
>
> FILES_${PN} += "${libdir}/lib*.so"
>
> and nothing in my recipe has statements such as FILES_${PN)-dev = ...


Read oe-core/meta/conf/bitbake.conf.

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

Re: [yocto] ERROR: QA Issue: No GNU_HASH in the elf binary

[Saxena, Rahul]

Looks like the order of packages (as shown in bitbake.conf) in PACKAGES 
variable is different  in 1.3_M3 compared to Denzel.

In 1.3_M3, ${PN} package is last (that is comes after ${PN}-dev package) ..so 
that probably explains the issue.
I will explicitly change it and try-out.

Chris, you were right bitbake.conf was the place to look at :)

Rahul


-Original Message-
From: Saxena, Rahul 
Sent: Tuesday, August 21, 2012 12:25 PM
To: 'Chris Larson'
Cc: Khem Raj; yocto@yoctoproject.org
Subject: RE: [yocto] ERROR: QA Issue: No GNU_HASH in the elf binary

oe-core/meta/conf/bitbake.conf specifies the default package settings.
However the problem I seem to be seeing is that my recipe is not able to 
override the default.

However let me know if I should still be looking at that file..

Rahul

-Original Message-
From: kerg...@gmail.com [mailto:kerg...@gmail.com] On Behalf Of Chris Larson
Sent: Tuesday, August 21, 2012 12:07 PM
To: Saxena, Rahul
Cc: Khem Raj; yocto@yoctoproject.org
Subject: Re: [yocto] ERROR: QA Issue: No GNU_HASH in the elf binary

On Tue, Aug 21, 2012 at 12:05 PM, Saxena, Rahul  wrote:
> You are right, these are regular files and not symlinks and are ending 
> up in usr/lib in packagename-dev package However I want them to be in the 
> regular package.
>
> I do have the following statement in my recipe:
>
> FILES_${PN} += "${libdir}/lib*.so"
>
> and nothing in my recipe has statements such as FILES_${PN)-dev = ...


Read oe-core/meta/conf/bitbake.conf.

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

[yocto] [ADT] Sysroot setup issue

[Rudolf Streif]

Hi,

I am trying to setup the ADT using an ADT installer. I have downloaded the
installer from
http://downloads.yoctoproject.org/releases/yocto/yocto-1.2.1/adt_installer/ as
well as created my own installer using a build environment with Denzil
7.0.1.

The adt_installer.conf contains these settings:

YOCTOADT_REPO="http://adtrepo.yoctoproject.org/1.2.1";
YOCTOADT_TARGETS="arm x86"
YOCTOADT_QEMU="Y"
YOCTOADT_NFS_UTIL="Y"

YOCTOADT_ROOTFS_arm="minimal"
YOCTOADT_TARGET_SYSROOT_IMAGE_arm="minimal"
YOCTOADT_TARGET_SYSROOT_LOC_arm="$HOME/test-yocto/arm"

YOCTOADT_ROOTFS_x86="minimal"
YOCTOADT_TARGET_SYSROOT_IMAGE_x86="minimal"
YOCTOADT_TARGET_SYSROOT_LOC_x86="$HOME/test-yocto/x86"

The installer downloads kernel and root fs images. After the installation
has finished

${HOME}/test-yocto/arm/boot does not contain any kernel images and

${HOME}/test-yocto/x86/boot only contains a empty link bzImage ->
bzImage-3.2.18-yocto-standard

I manually copied the x86 kernel image bzImage-qemux86.bin from the
download_image directory of the extracted installer tarball into the
directory, initialized the ADT environment and then ran

runqemu ${HOME}/test-yocto/x86/boot/bzImage-qemux86.bin ${HOME}/test-yocto/x86

The NFS user-space server initializes on the tap0 interface and the kernel
boots. However, it panics because it cannot locate the root fs. rpcbind is
started with the -i option on my system.

I also ran QEMU directly using:

/opt/poky/1.2.1/sysroots/x86_64-pokysdk-linux/usr/bin/qemu -kernel
/home/rudi/test-yocto/x86/boot/bzImage-qemux86.bin -show-cursor -usb
-usbdevice wacom-tablet -vga vmware -enable-gl -no-reboot -m 128 --append
"root=/dev/nfs nfsroot=192.168.100.199://home/rudi/test-yocto/x86 rw
ip=192.168.100.38::192.168.100.199:255.255.255.0 mem=128M oprofile.timer=1 "

with my dev system's NFS server running and exporting the file system (I
verified that I can mount the exported file system via NFS).

Questions:

   1. Why do the sysroot boot directory not contain any kernel images? I
   don't think that is what it is supposed to be.
   2. Is there anything broken with the sysroot causing the boot process to
   fail when the kernel tries to access the root fs?
   3. Any hints on how to fix it?

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

Re: [yocto] ERROR: QA Issue: No GNU_HASH in the elf binary

[Saxena, Rahul]

Yes, rearranging the package generation order worked. Was not aware that 
default package
generation could change between poky releases.

Rahul

-Original Message-
From: Saxena, Rahul 
Sent: Tuesday, August 21, 2012 12:54 PM
To: Saxena, Rahul; Chris Larson
Cc: Khem Raj; yocto@yoctoproject.org
Subject: RE: [yocto] ERROR: QA Issue: No GNU_HASH in the elf binary

Looks like the order of packages (as shown in bitbake.conf) in PACKAGES 
variable is different  in 1.3_M3 compared to Denzel.

In 1.3_M3, ${PN} package is last (that is comes after ${PN}-dev package) ..so 
that probably explains the issue.
I will explicitly change it and try-out.

Chris, you were right bitbake.conf was the place to look at :)

Rahul


-Original Message-
From: Saxena, Rahul
Sent: Tuesday, August 21, 2012 12:25 PM
To: 'Chris Larson'
Cc: Khem Raj; yocto@yoctoproject.org
Subject: RE: [yocto] ERROR: QA Issue: No GNU_HASH in the elf binary

oe-core/meta/conf/bitbake.conf specifies the default package settings.
However the problem I seem to be seeing is that my recipe is not able to 
override the default.

However let me know if I should still be looking at that file..

Rahul

-Original Message-
From: kerg...@gmail.com [mailto:kerg...@gmail.com] On Behalf Of Chris Larson
Sent: Tuesday, August 21, 2012 12:07 PM
To: Saxena, Rahul
Cc: Khem Raj; yocto@yoctoproject.org
Subject: Re: [yocto] ERROR: QA Issue: No GNU_HASH in the elf binary

On Tue, Aug 21, 2012 at 12:05 PM, Saxena, Rahul  wrote:
> You are right, these are regular files and not symlinks and are ending 
> up in usr/lib in packagename-dev package However I want them to be in the 
> regular package.
>
> I do have the following statement in my recipe:
>
> FILES_${PN} += "${libdir}/lib*.so"
>
> and nothing in my recipe has statements such as FILES_${PN)-dev = ...


Read oe-core/meta/conf/bitbake.conf.

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

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

[Liu, Song]

Attendees:

Alex, LaurentiuS, Saul, Richard, Kevin, Denys, MichaelH, Beth, Jefro, Bogdan, 
Tom, Jeff, Dave, ChrisL, Ross, MichaelB (Dell), Paul, Belen, Sean, Darren, 
Cristian, Song 
 
Agenda:
 
* Opens collection - 5 min (Song)
* 1.3 Beta Program - 5 min (Song)
  . A little background: Feedback gathering for a release close to the end of 
the release. Some feedback we can address in this release, others will be 
addressed in future release. Good opportunity to try out the latest 
features/improvements. 
  . Schedule: Beta build this week or next, then 2-4 weeks for testing and 
feedback.
  . calling for participation.
* Yocto 1.3 status - 10 min (Song/team)
https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.3_Status 
  
 - Laurentiu: M3 RC2 is in testing,  Weekly testing should be done this 
evening, tomorrow evening we will have the full pass report. Relocatable tool 
chain has some issue, working on it (2 Laurentius), as far as we don't relocate 
it, it should be fine. It's not a blocking issue for M3 release. 
  - Bug number is going down a little bit. The team has made more progress 
fixing bugs last week.
  - Will review features and bugs tomorrow, cut down some features and leave 
rooms for more bug fixing. 
  - Beth: master build. There were some issues, one of them is eclipse plugin. 
Put in a pull request yesterday. RP: Outcome/display of ab is confusing. We 
should try to re-organize the information. Will work with Saul and Beth and try 
to improve things. 
 
* SWAT team rotation: Jessica -> Ross
 
* Opens - 10 min
  
- Jefro: very quick announcement about LinuxCon next week.
 
LinxuCon next week in San Diego, we have a talk on Friday from Dave. Then YP 
BoF.
 
- Beth: minor upcoming autobuilder changes.
 
Not sure if I will put in before M3 is out. The change will be put in later 
this week or early next week. Require very short (about 5 minutes) ab downtime. 
 
 
* Team sharing - 20 min
 
Beth: worked on license manifest. Support SPDX, found some issues for the spec. 
talking with them. It's not perfect. Having some issues with parallel image 
creation, working on it. Not sure if there is a way to do that. If someone can 
help, appreciate it.
 
Belen: I sent an email about grouping our base images in HOB. Would like 
feedback from the community. Christian will look at it. But it may not happen 
immediately, sometime this week. Have a lot of other things working on. 
Valentin is not here, on vacation, Cristian will help on Valentin's tasks too.
 
Michael: last week on answering questions, gateway upgrade, service work for 
LF. Main thing, we had 7-8 minutes downtime on the download server. Resolved 
the issues, but not completely. Need to run a different kernel to resolve it 
once and for all. Next to complete gateway upgrade, bugzilla, get AB dev 
cluster running the save version, running plugin to monitor tapes, etc.
 
Paul: sent out RFC last week. It's about task rework mentioned last week. 
Documented all tasks we have. Suggested something we should be doing. 
Appreciate if anyone has feedback. Breaking up qemu config recipes. Continue 
along with those tasks.
 
Radu: doing package update last week. Will be doing bug fixing, debugging, just 
starting now.
 
Cristian: working on HOB, will work on fixing bugs. Connectivity and HOB. 
Balance between the two. There are many features to work on.


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

Re: [yocto] [PATCH 00/19] yocto-bsp updates for master, v3

[Tom Zanussi]

On Fri, 2012-08-10 at 14:06 -0500, tom.zanu...@intel.com wrote:
> From: Tom Zanussi 
> 
> This patchset fixes yocto bugs [YOCTO #2693] and [YOCTO #2587], and
> fixes some other minor usability problems reported by users.
> 
> Please pull into poky/master.
> 

Ping, just wondering if this got overlooked, been a couple weeks, etc...

Tom

> v2: This is the same patchset as the previous one, but an additional
> couple of patches fixing problems found in testing has been tacked on.
> 
> v3: This removes all instances of YOCTO_KERNEL_EXTERNAL_BRANCH usage
>  - some were missed the last time around.
> 
> The following changes since commit 2dec760b79bb7e2e79c33c5127fa64685bd86a18:
> 
>   foomatic: fix perl path for target (2012-08-08 10:06:00 +0100)
> 
> are available in the git repository at:
> 
>   git://git.yoctoproject.org/poky-contrib.git 
> tzanussi/yocto-bsp-master-update.v3
>   
> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=tzanussi/yocto-bsp-master-update.v3
> 
> Tom Zanussi (19):
>   yocto-bsp: add new strip_base() function
>   yocto-bsp: strip '/base' from kernel branches in templates
>   yocto-bsp: update default branch names
>   yocto-bsp: allow branch display filtering
>   yocto-bsp: use branches_base
>   yocto-bsp: add standard branch mapping
>   yocto-bsp: use standard branch mapping in bsp templates
>   yocto-bsp: use rstrip() for assignment lines
>   yocto-bsp: remove 'branch' statements in .scc if reusing branch
>   yocto-bsp: add some standard policy
>   yocto-bsp: add i586 option for i386
>   yocto-bsp: use emgd 1.10 for i386 template
>   yocto-bsp: generate default properties even if json specified
>   yocto-bsp: add 3.4/remove 3.0 kernel from templates
>   yocto-bsp: update standard branch mapping
>   yocto-bsp: use emgd 1.14 for i386 template
>   yocto-bsp: remove YOCTO_KERNEL_EXTERNAL_BRANCH usage
>   yocto-bsp: use base branches for qemu 'newbranch' case
>   yocto-bsp: add missing xserver-xf86-config .bbappend for qemu
> 
>  scripts/lib/bsp/engine.py  |   44 
> ++--
>  scripts/lib/bsp/kernel.py  |   19 +
>  .../linux/files/{{=machine}}-standard.scc  |1 +
>  .../arm/recipes-kernel/linux/kernel-list.noinstall |4 +-
>  ...yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend" |   13 +++---
>  ...yocto-rt_3.4\": }} linux-yocto-rt_3.4.bbappend" |   13 +++---
>  ...linux-yocto_3.2\": }} linux-yocto_3.2.bbappend" |   13 +++---
>  ...linux-yocto_3.4\": }} linux-yocto_3.4.bbappend" |   15 +++
>  .../arch/i386/conf/machine/{{=machine}}.conf   |   14 ---
>  .../linux/files/{{=machine}}-preempt-rt.scc|7 
>  .../linux/files/{{=machine}}-standard.scc  |   14 ++-
>  .../recipes-kernel/linux/files/{{=machine}}.scc|2 +-
>  .../recipes-kernel/linux/kernel-list.noinstall |4 +-
>  ...yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend" |9 ++--
>  ...yocto-rt_3.4\": }} linux-yocto-rt_3.4.bbappend" |   13 +++---
>  ...linux-yocto_3.2\": }} linux-yocto_3.2.bbappend" |9 ++--
>  ...linux-yocto_3.4\": }} linux-yocto_3.4.bbappend" |   15 +++
>  .../linux/files/{{=machine}}-standard.scc  |1 +
>  .../recipes-kernel/linux/kernel-list.noinstall |4 +-
>  ...yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend" |9 ++--
>  ...yocto-rt_3.4\": }} linux-yocto-rt_3.4.bbappend" |   13 +++---
>  ...linux-yocto_3.2\": }} linux-yocto_3.2.bbappend" |9 ++--
>  ...linux-yocto_3.4\": }} linux-yocto_3.4.bbappend" |   15 +++
>  .../linux/files/{{=machine}}-standard.scc  |1 +
>  .../recipes-kernel/linux/files/{{=machine}}.scc|3 --
>  .../recipes-kernel/linux/kernel-list.noinstall |4 +-
>  ...yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend" |9 ++--
>  ...yocto-rt_3.4\": }} linux-yocto-rt_3.4.bbappend" |   13 +++---
>  ...linux-yocto_3.2\": }} linux-yocto_3.2.bbappend" |9 ++--
>  ...linux-yocto_3.4\": }} linux-yocto_3.4.bbappend" |   15 +++
>  .../xorg-xserver/xserver-xf86-config_0.1.bbappend  |2 +
>  .../linux/files/{{=machine}}-preempt-rt.scc|5 +--
>  .../linux/files/{{=machine}}-standard.scc  |9 ++--
>  .../recipes-kernel/linux/kernel-list.noinstall |4 +-
>  ...yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend" |   25 +--
>  ...yocto-rt_3.4\": }} linux-yocto-rt_3.4.bbappend" |   29 ++---
>  ...linux-yocto_3.2\": }} linux-yocto_3.2.bbappend" |   25 +--
>  ...linux-yocto_3.4\": }} linux-yocto_3.4.bbappend" |   29 ++---
>  .../linux/files/{{=machine}}-preempt-rt.scc|7 
>  .../linux/files/{{=machine}}-standard.scc  |   10 -
>  .../recipes-kernel/linux/kernel-list.noinstall |4 +-
>  ...yocto-rt_3.0\": }} linux-yocto-rt_3.0.bbappend" |   39 -
>  ...yocto-rt_3.2\": }} linux-yocto-rt_3.2.bbappend" |9 ++--
>  ...yocto-rt_3.4\": }} linux-yocto-rt_3.4.bbappend" |   36 
>  ...linux-yocto_3