Re: [yocto] [linux-yocto] [PATCH 0/1] [linux-yocto-3.0] boot-live.cfg: enable BLK_DEV_INITRD in kernel

[Tom Zanussi]

On Wed, 2012-09-19 at 19:56 -0400, Bruce Ashfield wrote:
> On 12-09-19 04:54 PM, Mihai Lindner wrote:
> > On 2012-09-19 23:32, Bruce Ashfield wrote:
> >> On 12-09-19 04:22 PM, Bruce Ashfield wrote:
> >>> On 12-09-19 03:39 PM, Mihai Lindner wrote:
>  On 2012-09-19 22:01, Bruce Ashfield wrote:
> > On 12-09-19 11:56 AM, Mihai Lindner wrote:
> >> On 2012-09-19 18:43, Bruce Ashfield wrote:
> >>> On 12-09-18 10:46 AM, Mihai Lindner wrote:
>  On 2012-09-18 17:23, Tom Zanussi wrote:
> > On Tue, 2012-09-18 at 16:58 +0300, Mihai Lindner wrote:
> >> On 2012-09-18 16:49, Tom Zanussi wrote:
> >>> On Tue, 2012-09-18 at 08:21 -0400, Bruce Ashfield wrote:
>  On 12-09-18 01:59 AM, Mihai Lindner wrote:
> > Please pull into linux-yocto-3.0, meta.
> >
> 
>  Adding linux-yocto, Darren and Tom.
> 
>  This looks fine to me, and we should consider it for all the
>  repositories,
>  not just 3.0.
> 
>  Tom/Darren. Any side effects you can think of for this change ?
> 
> >>>
> >>> No, but shouldn't it already be there, inherited from base.cfg?
> >>
> >> For cedartrail, at least, standard.cfg is used.
> >>
> >
> > And standard inherits from base, so it should be turned on. Somehow
> > it's getting turned off in cedartrail...
> 
>  Yes, it the final .config file is turned off. Solved it by setting
>  it in boot-live.
>  --Mihai
> >>>
> >>> To follow up on this, is someone taking a closer look at this config
> >>> to see if we can get a root cause for that option being disabled for
> >>> this board ?
> >>>
> >>> I won't be able to poke at it myself for another day or so.
> >>>
> >>> Bruce
> >>>
> >> I'm still digging on this, trying to figure out what cfg files are
> >> included / omitted by `configme` and why.
> >> base.cfg is not included, nor stanadrd.cfg it seems.
> >> The list of included cfg files is way to short.
> >
> > That likely means the BSP .scc file is missing and update (i.e. does
> > it still have scc_leaf?) and the tools aren't finding it and
> > auto-generating something to get you up and running.
> >
> > I just checked the meta branch here, and it looks to be updated, but
> > if you look at your build's linux source dir, what's in meta/top_tgt ?
> >
> > Bruce
> >
>  In meta/top_tgt i have:
> 
>  /home/mihai/cedartrail/tmp/work/cedartrail-poky-linux/linux-yocto-3.0.32+git5+46e8fc2bbbe73514e8d99101adaaa373f760ffa7_1+1e79e03d115ed177882ab53909a4f3555e434833-r4.1/linux/meta/cfg/kernel-cache/bsp/cedartrail/cedartrail-standard.scc
> 
> 
> 
>  I've also hit an error, after more verbose runs of
>  ./cedartrail-standard in meta/cfg/scratch/obj/:
> 
>  ./0-cedartrail-standard-897c5c055888aca397b3ab0d7be9e6fa.sco: line 17:
>  standard_5b57715386592f694588063dd3ec6ebb: command not found
> 
>  After this the scripts stops.
> 
> >>>
> >>> Aha. This definitely breaks the configuration chain (and would throw
> >>> a hard error in the 3.4 kernel) and is where the options drop. But this
> >>> should no way be specific to this board. I'll get something configured
> >>> here, since I need to see this happen in front of me.
> >>
> >> I've finally reproduced this. Leave the issue with me and I'll get
> >> back to you with a fix.
> >>
> >> Bruce
> >
> > Yay! Thanks.
> > It's not specific, it's just easier to hit; for cedartrail only 3.0 is 
> > available, and also set as preferred.
> >
> 
> Aha. I was right. It is a tools issue and a interface that changed.
> I made a fix for this in the 3.0 kernel tree some time ago, but
> I didn't update the lagging BSPs, and the handoff to a meta-intel
> change was missed.
> 
> With this change (sorry for the linewraps, I'm out of the office):
> 
> --git a/meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend 
> b/meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend
> index 35c4755..212a400 100644
> --- a/meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend
> +++ b/meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend
> @@ -16,7 +16,7 @@ KBRANCH_cedartrail-nopvr  = "yocto/standard/cedartrail"
>   KERNEL_FEATURES_append_cedartrail-nopvr += " cfg/smp.scc"
> 
>   SRCREV_machine_pn-linux-yocto_cedartrail ?= 
> "1e79e03d115ed177882ab53909a4f3555e434833"
> -SRCREV_meta_pn-linux-yocto_cedartrail ?= 
> "46e8fc2bbbe73514e8d99101adaaa373f760ffa7"
> +SRCREV_meta_pn-linux-yocto_cedartrail ?= 
> "bf5ee4945ee6d748e6abe16356f2357f76b5e2f0"
>   SRCREV_pvr_pn-linux-yocto_cedartrail ?= 
> "997f5644664b31ebefd6e16c451c4a3729eb378a"
> 
>   SRCREV_machine_pn-linux-yocto_cedartrail-nopvr ?= 
> "1e79e03d115ed177882ab53909a4f3555e434833"
> 
> i.e. bump the META src

Re: [yocto] 1.3_M5.rc1 branched

[Saul Wold]

On 09/19/2012 05:25 PM, Flanagan, Elizabeth wrote:

All,

1.3_M5 has been branched and rc1 is close to complete. There were a
few minor issues which have caused a targeted regeneration of build
artifacts. Specifically, we are regenerating the build appliance and
the eclipse plugin. Those build artifacts will be moved to the release
cadidate directory when they are complete (a few hours from now.). I
will send out a note when they are finished but if people wish to
begin testing as soon as they are done, I've included the links to
where they're being built out to:

Download: autobuilder.yoctoproject.org/pub/nightly/20120919-2
poky: 52850f0fc6f801298413ee779834b346ef7f48d6
meta-qt3: 8730326c902e6fb256b5dea77a6dde28d813c424
eclipse-poky: 7b86e48a504f79871cdfdabd4995aa64352fdeed

Rebuilds:
Build-appliance:
http://autobuilder.yoctoproject.org/pub/build-appliance/20120919-1
Eclipse-poky: http://autobuilder.yoctoproject.org/pub/eclipse-plugin/20120919-2


QA Folks,

Please finish up on the M4 RC3 Full pass testing so we at least get an 
idea what items we need to work on for the RC2 build!


If it's possible to start some basic testing during your various day 
time on this 1.3_M5 that would be very appreciated also!


If there are any bugs that anyone feels needs more attention, please let 
me know, I know there are some outstanding issues with doing builds with 
ADT, which we are addressing.


Thanks
Sau!

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

Re: [yocto] BB_NO_NETWORK and own-mirrors not working with meta-systemd

[Khem Raj]

On Wednesday, September 19, 2012, Gary Thomas  wrote:
> On 2012-09-19 16:30, Evade Flow wrote:
>>>
>>> I'm just trying to build the thing. :-)  I'll try converting the tag
>>> name into a commit hash and see if that helps, thanks a lot...
>>
>> ::SIGH::  I changed the SRC_URI var in kmod.inc from this:
>>
>>SRC_URI = "git://
git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git;protocol=git;tag=v${PV}"
>>
>> to this:
>>
>>SRC_URI = "git://
git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git;protocol=git"
>>SRCREV="8885ced062131214448fae056ef453f094303805"
>>
>> This is *still* trying to access the network:

This is right change and it should work provided your repo tar ball is up
to date so try to open up the port and get the latest source And retry

> Try doing 'bitbake kmod -c cleansstate;bitbake kmod' - does that still
fail?
>
> NOTE: package kmod-7-r0: task do_fetch: Started
> ERROR: Function failed: Network access disabled through BB_NO_NETWORK
> but access rquested with command git ls-remote
> git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git
> 8885ced062131214448 (for url None)
> ERROR: Logfile of failure stored in:
>
/home/dwolfe/projects/poky-git/build/tmp-eglibc-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/kmod-7-r0/temp/log.do_fetch.11168
> Log data follows:
> | ERROR: Function failed: Network access disabled through
> BB_NO_NETWORK but access rquested with command git ls-remote
> git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git
> 8885ced062131214448 (for url None)
> NOTE: package kmod-7-r0: task do_fetch: Failed
> NOTE: package acl-2.2.51-r3: task do_fetch: Started
> NOTE: package acl-2.2.51-r3: task do_fetch: Succeeded
> ERROR: Task 1374
> (/home/dwolfe/projects/poky-git/meta-systemd/recipes-kernel/kmod/kmod_7.bb
,
> do_fetch) failed with exit code '1'
> NOTE: Tasks Summary: Attempted 699 tasks of which 697 didn't need to
> be rerun and 1 failed.
>
> Summary: 1 task failed:
>/home/dwolfe/projects/poky-git/meta-systemd/recipes-kernel/kmod/
kmod_7.bb,
> do_fetch
> Summary: There was 1 ERROR message shown, returning a non-zero exit code.
> bitbake discovery-image  16.51s user 2.65s system 112% cpu 17.031 total
>
>
> Why is poky/bitbake/whatever running 'git ls-remote'? This seems like a
> bug
>
>
> On Wed, Sep 19, 2012 at 1:33 PM, Evade Flow  wrote:
>
> I'm not sure how to answer your questions, unfortunately, this is all
> quite new to me. I'm not the maintainer of said layer, and don't know
> anything at all yet about 'layer etiquette'. There does seem to be a
> README.md file in meta-systemd, though:
>
>- http://git.yoctoproject.org/cgit/cgit.cgi/meta-systemd/tree/README.md
>
> I'm just trying to build the thing. :-)  I'll try converting the tag
> name into a commit hash and see if that helps, thanks a lot...
>
>
> On Wed, Sep 19, 2012 at 1:23 PM, Gary Thomas  wrote:
>
> On 2012-09-19 11:15, Evade Flow wrote:
>
> Where did you get that meta-systemd layer?
>
>
>  From here:
>
>
> - http://git.yoctoproject.org/cgit/cgit.cgi/meta-systemd/
>
>
> Why are there conflicting meta-systemd layers (and pointers thereto)??
> This layer in git.yoctoproject.org doesn't seem even "legal" - where is
> the README that is expected with every layer?  Without it, I don't have
> enough info to be able to report problems like yours...
>
> The reason your build fails with BB_NO_NETWORK is that the kmod_7.bb
> recipe refers to a git tag, not a specific revision, which cannot be
> resolved without using the network.
>
>
>
>
> On Wed, Sep 19, 2012 at 12:50 PM, Gary Thomas  wrote:
>
> On 2012-09-19 10:34, Evade Flow wrote:
>
>
> Trying to build the meta-ivi discovery-image behind a firewall is
> proving to be quite a challenge. I tried modifying my conf/local.conf
> file as follows:
>
> CONNECTIVITY_CHECK_URIS=""
> BB_GENERATE_MIRROR_TARBALLS = "1"
> SOURCE_MIRROR_URL ?= "file:///home/evadeflow/projects/pok
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] 1.3_M5.rc1 branched

[Flanagan, Elizabeth]

All,

1.3_M5 has been branched and rc1 is close to complete. There were a
few minor issues which have caused a targeted regeneration of build
artifacts. Specifically, we are regenerating the build appliance and
the eclipse plugin. Those build artifacts will be moved to the release
cadidate directory when they are complete (a few hours from now.). I
will send out a note when they are finished but if people wish to
begin testing as soon as they are done, I've included the links to
where they're being built out to:

Download: autobuilder.yoctoproject.org/pub/nightly/20120919-2
poky: 52850f0fc6f801298413ee779834b346ef7f48d6
meta-qt3: 8730326c902e6fb256b5dea77a6dde28d813c424
eclipse-poky: 7b86e48a504f79871cdfdabd4995aa64352fdeed

Rebuilds:
Build-appliance:
http://autobuilder.yoctoproject.org/pub/build-appliance/20120919-1
Eclipse-poky: http://autobuilder.yoctoproject.org/pub/eclipse-plugin/20120919-2

-- 
Elizabeth Flanagan
Yocto Project
Build and Release
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] BB_NO_NETWORK and own-mirrors not working with meta-systemd

[Gary Thomas]

On 2012-09-19 16:30, Evade Flow wrote:

I'm just trying to build the thing. :-)  I'll try converting the tag
name into a commit hash and see if that helps, thanks a lot...


::SIGH::  I changed the SRC_URI var in kmod.inc from this:

   SRC_URI = 
"git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git;protocol=git;tag=v${PV}"

to this:

   SRC_URI = 
"git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git;protocol=git"
   SRCREV="8885ced062131214448fae056ef453f094303805"

This is *still* trying to access the network:


Try doing 'bitbake kmod -c cleansstate;bitbake kmod' - does that still fail?


NOTE: package kmod-7-r0: task do_fetch: Started
ERROR: Function failed: Network access disabled through BB_NO_NETWORK
but access rquested with command git ls-remote
git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git
8885ced062131214448 (for url None)
ERROR: Logfile of failure stored in:
/home/dwolfe/projects/poky-git/build/tmp-eglibc-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/kmod-7-r0/temp/log.do_fetch.11168
Log data follows:
| ERROR: Function failed: Network access disabled through
BB_NO_NETWORK but access rquested with command git ls-remote
git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git
8885ced062131214448 (for url None)
NOTE: package kmod-7-r0: task do_fetch: Failed
NOTE: package acl-2.2.51-r3: task do_fetch: Started
NOTE: package acl-2.2.51-r3: task do_fetch: Succeeded
ERROR: Task 1374
(/home/dwolfe/projects/poky-git/meta-systemd/recipes-kernel/kmod/kmod_7.bb,
do_fetch) failed with exit code '1'
NOTE: Tasks Summary: Attempted 699 tasks of which 697 didn't need to
be rerun and 1 failed.

Summary: 1 task failed:
   /home/dwolfe/projects/poky-git/meta-systemd/recipes-kernel/kmod/kmod_7.bb,
do_fetch
Summary: There was 1 ERROR message shown, returning a non-zero exit code.
bitbake discovery-image  16.51s user 2.65s system 112% cpu 17.031 total


Why is poky/bitbake/whatever running 'git ls-remote'? This seems like a
bug


On Wed, Sep 19, 2012 at 1:33 PM, Evade Flow  wrote:

I'm not sure how to answer your questions, unfortunately, this is all
quite new to me. I'm not the maintainer of said layer, and don't know
anything at all yet about 'layer etiquette'. There does seem to be a
README.md file in meta-systemd, though:

   - http://git.yoctoproject.org/cgit/cgit.cgi/meta-systemd/tree/README.md

I'm just trying to build the thing. :-)  I'll try converting the tag
name into a commit hash and see if that helps, thanks a lot...


On Wed, Sep 19, 2012 at 1:23 PM, Gary Thomas  wrote:

On 2012-09-19 11:15, Evade Flow wrote:


Where did you get that meta-systemd layer?




 From here:



- http://git.yoctoproject.org/cgit/cgit.cgi/meta-systemd/



Why are there conflicting meta-systemd layers (and pointers thereto)??
This layer in git.yoctoproject.org doesn't seem even "legal" - where is
the README that is expected with every layer?  Without it, I don't have
enough info to be able to report problems like yours...

The reason your build fails with BB_NO_NETWORK is that the kmod_7.bb
recipe refers to a git tag, not a specific revision, which cannot be
resolved without using the network.





On Wed, Sep 19, 2012 at 12:50 PM, Gary Thomas  wrote:


On 2012-09-19 10:34, Evade Flow wrote:



Trying to build the meta-ivi discovery-image behind a firewall is
proving to be quite a challenge. I tried modifying my conf/local.conf
file as follows:

CONNECTIVITY_CHECK_URIS=""
BB_GENERATE_MIRROR_TARBALLS = "1"
SOURCE_MIRROR_URL ?= "file:///home/evadeflow/projects/poky-mirror/"
INHERIT += "own-mirrors"

and then ran:

% bitbake discovery-image

in a VM on my home laptop over the weekend. (I'm trying to build using
the meta-ivi layer, per the instructions in its README.) After grinding
and churning for some 60+ hours, it finally succeeded, leaving 11 GB of
'stuff' in my poky-mirror folder.

Then, I copied the poky-mirror folder to a firewalled machine at work
and added:

BB_NO_NETWORK="1"

to local.conf.  When I tried to bitbake discovery-image on this machine,
I got the following error:


NOTE: Running task 697 of 3568 (ID: 1374,


/home/evadeflow/projects/poky-git/meta-systemd/recipes-kernel/kmod/kmod_7.bb,
do_fetch)
NOTE: package kmod-7-r0: task do_fetch: Started
ERROR: Function failed: Network access disabled through BB_NO_NETWORK
but access rquested with command git ls-remote
git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git v7 (for url
None)
ERROR: Logfile of failure stored in:


/home/evadeflow/projects/poky-git/build/tmp-eglibc-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/kmod-7-r0/temp/log.do_fetch.29423
Log data follows:
| ERROR: Function failed: Network access disabled through
BB_NO_NETWORK but access rquested with command git ls-remote
git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git v7 (for url
None)
NOTE: package kmod-7-r0: task do_fetch: Failed
ERROR: Task 1374


(/home/evadeflow/projects/poky-git/meta-systemd/recipes-kernel/kmod/kmod_7.bb,
do_fetch) failed with exit code '1'
Waiting

Re: [yocto] [linux-yocto] [PATCH 0/1] [linux-yocto-3.0] boot-live.cfg: enable BLK_DEV_INITRD in kernel

[Bruce Ashfield]

On 12-09-19 04:54 PM, Mihai Lindner wrote:

On 2012-09-19 23:32, Bruce Ashfield wrote:

On 12-09-19 04:22 PM, Bruce Ashfield wrote:

On 12-09-19 03:39 PM, Mihai Lindner wrote:

On 2012-09-19 22:01, Bruce Ashfield wrote:

On 12-09-19 11:56 AM, Mihai Lindner wrote:

On 2012-09-19 18:43, Bruce Ashfield wrote:

On 12-09-18 10:46 AM, Mihai Lindner wrote:

On 2012-09-18 17:23, Tom Zanussi wrote:

On Tue, 2012-09-18 at 16:58 +0300, Mihai Lindner wrote:

On 2012-09-18 16:49, Tom Zanussi wrote:

On Tue, 2012-09-18 at 08:21 -0400, Bruce Ashfield wrote:

On 12-09-18 01:59 AM, Mihai Lindner wrote:

Please pull into linux-yocto-3.0, meta.



Adding linux-yocto, Darren and Tom.

This looks fine to me, and we should consider it for all the
repositories,
not just 3.0.

Tom/Darren. Any side effects you can think of for this change ?



No, but shouldn't it already be there, inherited from base.cfg?


For cedartrail, at least, standard.cfg is used.



And standard inherits from base, so it should be turned on. Somehow
it's getting turned off in cedartrail...


Yes, it the final .config file is turned off. Solved it by setting
it in boot-live.
--Mihai


To follow up on this, is someone taking a closer look at this config
to see if we can get a root cause for that option being disabled for
this board ?

I won't be able to poke at it myself for another day or so.

Bruce


I'm still digging on this, trying to figure out what cfg files are
included / omitted by `configme` and why.
base.cfg is not included, nor stanadrd.cfg it seems.
The list of included cfg files is way to short.


That likely means the BSP .scc file is missing and update (i.e. does
it still have scc_leaf?) and the tools aren't finding it and
auto-generating something to get you up and running.

I just checked the meta branch here, and it looks to be updated, but
if you look at your build's linux source dir, what's in meta/top_tgt ?

Bruce


In meta/top_tgt i have:

/home/mihai/cedartrail/tmp/work/cedartrail-poky-linux/linux-yocto-3.0.32+git5+46e8fc2bbbe73514e8d99101adaaa373f760ffa7_1+1e79e03d115ed177882ab53909a4f3555e434833-r4.1/linux/meta/cfg/kernel-cache/bsp/cedartrail/cedartrail-standard.scc



I've also hit an error, after more verbose runs of
./cedartrail-standard in meta/cfg/scratch/obj/:

./0-cedartrail-standard-897c5c055888aca397b3ab0d7be9e6fa.sco: line 17:
standard_5b57715386592f694588063dd3ec6ebb: command not found

After this the scripts stops.



Aha. This definitely breaks the configuration chain (and would throw
a hard error in the 3.4 kernel) and is where the options drop. But this
should no way be specific to this board. I'll get something configured
here, since I need to see this happen in front of me.


I've finally reproduced this. Leave the issue with me and I'll get
back to you with a fix.

Bruce


Yay! Thanks.
It's not specific, it's just easier to hit; for cedartrail only 3.0 is 
available, and also set as preferred.



Aha. I was right. It is a tools issue and a interface that changed.
I made a fix for this in the 3.0 kernel tree some time ago, but
I didn't update the lagging BSPs, and the handoff to a meta-intel
change was missed.

With this change (sorry for the linewraps, I'm out of the office):

--git a/meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend 
b/meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend

index 35c4755..212a400 100644
--- a/meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend
+++ b/meta-cedartrail/recipes-kernel/linux/linux-yocto_3.0.bbappend
@@ -16,7 +16,7 @@ KBRANCH_cedartrail-nopvr  = "yocto/standard/cedartrail"
 KERNEL_FEATURES_append_cedartrail-nopvr += " cfg/smp.scc"

 SRCREV_machine_pn-linux-yocto_cedartrail ?= 
"1e79e03d115ed177882ab53909a4f3555e434833"
-SRCREV_meta_pn-linux-yocto_cedartrail ?= 
"46e8fc2bbbe73514e8d99101adaaa373f760ffa7"
+SRCREV_meta_pn-linux-yocto_cedartrail ?= 
"bf5ee4945ee6d748e6abe16356f2357f76b5e2f0"
 SRCREV_pvr_pn-linux-yocto_cedartrail ?= 
"997f5644664b31ebefd6e16c451c4a3729eb378a"


 SRCREV_machine_pn-linux-yocto_cedartrail-nopvr ?= 
"1e79e03d115ed177882ab53909a4f3555e434833"


i.e. bump the META srcrev and everything is properly configured.
Tom or Darren .. or someone else can make the change permanently in
meta-intel/meta-cedartrail.

Cheers,

Bruce





--Mihai





Cheers,

Bruce



Mihai





--Mihai




Tom


--Mihai



Tom


Bruce


Added BLK_DEV_INITRD in boot-live.cfg for linux-yocto-3.0,
meta branch.
Cedartrail (at least) cannot boot live from ISO image due to
BLK_DEV_INITRD missing:
"VFS: Cannot open root device "ram0" or unkown-block(0,0)"
Should fix #3050

[YOCTO #3050]

Signed-off-by: Mihai Lindner
---

The following changes since commit
bf5ee4945ee6d748e6abe16356f2357f76b5e2f0:

meta: rename virto.scc to virtio.scc (2012-08-18 22:09:35 -0400)

are available in the git repository at:
git://git.yoctoproject.org/poky-contrib
mihai/linux-yocto-3.0/meta

Mihai Lindner (1):
boot-live.cfg: enable BLK_DEV_INITRD in kernel

meta/cfg/kernel-cache

Re: [yocto] About bug 2331

[Bruce Ashfield]

On Wed, Sep 19, 2012 at 5:13 PM, Marc Ferland  wrote:
> Saul Wold  writes:
>
>> On 09/19/2012 01:53 PM, Marc Ferland wrote:
>>> Saul Wold  writes:
>>>
 On 09/19/2012 01:41 PM, Marc Ferland wrote:
> Hi,
>
> I'm currently trying to create a "live" system with squashfs+unionfs and
> I stumbled on the same bug described here:
>
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=2331
>
> I was wondering if there was a plan to resolve this issue for 1.3?
>
 Marc,

 It seems to be marked as resolved and verified, is there still and
 issue?  If so we need to reopen this bug.  Or are you referring to the
 underlying issue?

>>> I was referring to the underlying issue.
>>>
>>>
>> No, unfortunately it seems that did not have visibility, I think bug
>> 1487 is open against that issue, at least with an ISO image, which is
>> what got partially reverted.  I think the issue was upstream unionfs,
>> do you know if any changes to resolve the problem upstream?
>>
> Unfortunately no. Maybe I'll have more chance using aufs or maybe
> overlayfs. Unionfs looks pretty much dead... I'm probably better off
> without it!

If you check the unionfs support I have staged in the 3.4 kernel, it contains
several big usability fixes.

If you look at the yocto dev kernel, I've dropped unionfs and am taking aufs
for a spin (while watching overlayfs and unionmounts as well).

So there are options to try that may address that issue, and also chart a
way forward.

Cheers,

Bruce

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



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [PATCH 3/3] [meta-intel] meta-crystalforest: Add Silesia Corpus recipe.

[kishore . k . bodke]

From: Kishore Bodke 

Add a new recipe Silesia Corpus for testing with another
Data Compression algorithm for Crystal Forest BSP.

Signed-off-by: Kishore Bodke 
---
 .../silesia-corpus/silesia-corpus.bb   |   32 
 1 file changed, 32 insertions(+)
 create mode 100644 
meta-crystalforest/recipes-corpus/silesia-corpus/silesia-corpus.bb

diff --git a/meta-crystalforest/recipes-corpus/silesia-corpus/silesia-corpus.bb 
b/meta-crystalforest/recipes-corpus/silesia-corpus/silesia-corpus.bb
new file mode 100644
index 000..73058eb
--- /dev/null
+++ b/meta-crystalforest/recipes-corpus/silesia-corpus/silesia-corpus.bb
@@ -0,0 +1,32 @@
+SUMMARY = "The Data Compression Resource on the Internet"
+DESCRIPTION = "The intention of the Silesia corpus is to provide a data set of 
files \
+   that covers the typical data types used nowadays. \
+   The sizes of the files are between 6 MB and 51 MB."
+
+HOMEPAGE = "http://www.data-compression.info/index.htm";
+SECTION = "misc"
+LICENSE = "GPLv2"
+LIC_FILES_CHKSUM = 
"file://${COMMON_LICENSE_DIR}/GPL-2.0;md5=801f80980d171dd6425610833a22dbe6"
+
+PR="r0"
+
+S = "${WORKDIR}/silesia-corpus"
+
+SRC_URI = "http://sun.aei.polsl.pl/~sdeor/corpus/silesia.zip";
+
+SRC_URI[md5sum] = "c240c17d6805fb8a0bde763f1b94cd99"
+SRC_URI[sha256sum] = 
"0626e25f45c0ffb5dc801f13b7c82a3b75743ba07e3a71835a41e3d9f63c77af"
+
+do_unpack () {
+mkdir -p ${S}
+   cp ${DL_DIR}/silesia.zip ${S}
+   cd ${S} && unzip silesia.zip
+}
+
+do_install () {
+
+   install -d  ${D}${base_libdir}/firmware
+   install -m 664 ${S}/*   ${D}${base_libdir}/firmware
+}
+
+FILES_${PN} = "/lib/firmware/*"
-- 
1.7.9.5

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

[yocto] [PATCH 2/3] [meta-intel] meta-crystalforest: Add Canterbury Cropus recipe.

[kishore . k . bodke]

From: Kishore Bodke 

Add a new recipe for Crystal Forest BSP for testing
the lossless compresstion algorithms with Canterbury Corpus.

Signed-off-by: Kishore Bodke 
---
 .../canterbury-corpus/canterbury-corpus.bb |   40 
 1 file changed, 40 insertions(+)
 create mode 100644 
meta-crystalforest/recipes-corpus/canterbury-corpus/canterbury-corpus.bb

diff --git 
a/meta-crystalforest/recipes-corpus/canterbury-corpus/canterbury-corpus.bb 
b/meta-crystalforest/recipes-corpus/canterbury-corpus/canterbury-corpus.bb
new file mode 100644
index 000..6dfdef2
--- /dev/null
+++ b/meta-crystalforest/recipes-corpus/canterbury-corpus/canterbury-corpus.bb
@@ -0,0 +1,40 @@
+SUMMARY = "Intel Quick Assist Driver - Canterbury Corpus"
+DESCRIPTION = "Set of files for testing losless compression algorithms \
+   for Intel Crystal Forest BSP Quick Assist Technology Software 
Package"
+
+HOMEPAGE = "http://corpus.canterbury.ac.nz";
+SECTION = "misc"
+LICENSE = "GPLv2"
+
+LIC_FILES_CHKSUM = 
"file://${COMMON_LICENSE_DIR}/GPL-2.0;md5=801f80980d171dd6425610833a22dbe6"
+
+PR = "r0"
+
+S = "${WORKDIR}/canterbury-corpus"
+
+SRC_URI = "http://corpus.canterbury.ac.nz/resources/cantrbry.tar.gz";
+
+SRC_URI[md5sum] = "442e56cfffdf460d25b0b91650a55908"
+SRC_URI[sha256sum] = 
"f140e8a5b73d3f53198555a63bfb827889394a42f20825df33c810c3d5e3f8fb"
+
+WARN_QA += "arch"
+
+ERROR_QA = ""
+
+do_package_qa[noexec] = "1"
+
+do_unpack () {
+
+   mkdir -p ${S}
+   tar -xf ${DL_DIR}/cantrbry.tar.gz -C ${S}
+
+}
+
+FILES_${PN} = "/lib/firmware/*"
+
+do_install () {
+
+   install -d ${D}${base_libdir}/firmware
+   install -m 644 ${S}/* ${D}${base_libdir}/firmware
+
+}
-- 
1.7.9.5

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

[yocto] [PATCH 1/3] [meta-intel] meta-crystalforest: Add Calgary Corpus recipe.

[kishore . k . bodke]

From: Kishore Bodke 

Add a new recipe Calgary Corpus for Crystal Forest BSP
for testing the lossless compression algorithms.

Signed-off-by: Kishore Bodke 
---
 .../calgary-corpus/calgary-corpus.bb   |   27 
 1 file changed, 27 insertions(+)
 create mode 100644 
meta-crystalforest/recipes-corpus/calgary-corpus/calgary-corpus.bb

diff --git a/meta-crystalforest/recipes-corpus/calgary-corpus/calgary-corpus.bb 
b/meta-crystalforest/recipes-corpus/calgary-corpus/calgary-corpus.bb
new file mode 100644
index 000..fbcbda2
--- /dev/null
+++ b/meta-crystalforest/recipes-corpus/calgary-corpus/calgary-corpus.bb
@@ -0,0 +1,27 @@
+SUMMARY = "Set of files for testing losless compression algorithms"
+DESCRIPTION = "Set of files for testing losless compression algorithms"
+HOMEPAGE = "http://corpus.canterbury.ac.nz";
+SECTION = "misc"
+LICENSE = "GPLv2"
+LIC_FILES_CHKSUM = 
"file://${COMMON_LICENSE_DIR}/GPL-2.0;md5=801f80980d171dd6425610833a22dbe6"
+
+S = "${WORKDIR}/corpus"
+
+SRC_URI = "http://corpus.canterbury.ac.nz/resources/calgary.tar.gz";
+
+SRC_URI[md5sum] = "651d06b35d3d39522157cf8dc4a3d01c"
+SRC_URI[sha256sum] = 
"e109eebdc19c5cee533c58bd6a49a4be3a77cc52f84ba234a089148a4f2093b7"
+
+do_unpack () {
+   
+   mkdir -p ${S}
+   tar -xf ${DL_DIR}/calgary.tar.gz -C ${WORKDIR}/corpus
+}
+
+FILES_${PN} = "/lib/firmware/*" 
+
+do_install () {
+
+   install -d ${D}/lib/firmware
+   install -m 664 ${S}/* ${D}/lib/firmware
+}
-- 
1.7.9.5

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

[yocto] [PATCH 0/3][meta-intel] Add new Corpus recipes to Crystal Forest BSP.

[kishore . k . bodke]

From: Kishore Bodke 

Hi,

This patch set adds three different types of Corpus files
to Crystal Forest BSP, which are basically used to test the
Lossless Compression algorithms.

1. calgary-corpus
2. canterbury-corpus
3. silesia-corpus

These have been tested on both Crystal Forest Platforms.

Please pull into meta-intel/master.

Thanks
Kishore.

The following changes since commit c3644c66fad3d9a91259ea382e72304dc6576ca0:

  cdv-pvr-driver: fix unpack (2012-09-19 12:24:19 +0100)

are available in the git repository at:

  git://git.pokylinux.org/meta-intel-contrib Kishore/CRF-corpus
  http://git.pokylinux.org/cgit.cgi/meta-intel-contrib/log/?h=Kishore/CRF-corpus

Kishore Bodke (3):
  meta-crystalforest: Add Calgary Corpus recipe.
  meta-crystalforest: Add Canterbury Cropus recipe.
  meta-crystalforest: Add Silesia Corpus recipe.

 .../calgary-corpus/calgary-corpus.bb   |   27 +
 .../canterbury-corpus/canterbury-corpus.bb |   40 
 .../silesia-corpus/silesia-corpus.bb   |   32 
 3 files changed, 99 insertions(+)
 create mode 100644 
meta-crystalforest/recipes-corpus/calgary-corpus/calgary-corpus.bb
 create mode 100644 
meta-crystalforest/recipes-corpus/canterbury-corpus/canterbury-corpus.bb
 create mode 100644 
meta-crystalforest/recipes-corpus/silesia-corpus/silesia-corpus.bb

-- 
1.7.9.5

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

Re: [yocto] BB_NO_NETWORK and own-mirrors not working with meta-systemd

[Evade Flow]

> I'm just trying to build the thing. :-)  I'll try converting the tag
> name into a commit hash and see if that helps, thanks a lot...

::SIGH::  I changed the SRC_URI var in kmod.inc from this:

  SRC_URI = 
"git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git;protocol=git;tag=v${PV}"

to this:

  SRC_URI = 
"git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git;protocol=git"
  SRCREV="8885ced062131214448fae056ef453f094303805"

This is *still* trying to access the network:


NOTE: package kmod-7-r0: task do_fetch: Started
ERROR: Function failed: Network access disabled through BB_NO_NETWORK
but access rquested with command git ls-remote
git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git
8885ced062131214448 (for url None)
ERROR: Logfile of failure stored in:
/home/dwolfe/projects/poky-git/build/tmp-eglibc-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/kmod-7-r0/temp/log.do_fetch.11168
Log data follows:
| ERROR: Function failed: Network access disabled through
BB_NO_NETWORK but access rquested with command git ls-remote
git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git
8885ced062131214448 (for url None)
NOTE: package kmod-7-r0: task do_fetch: Failed
NOTE: package acl-2.2.51-r3: task do_fetch: Started
NOTE: package acl-2.2.51-r3: task do_fetch: Succeeded
ERROR: Task 1374
(/home/dwolfe/projects/poky-git/meta-systemd/recipes-kernel/kmod/kmod_7.bb,
do_fetch) failed with exit code '1'
NOTE: Tasks Summary: Attempted 699 tasks of which 697 didn't need to
be rerun and 1 failed.

Summary: 1 task failed:
  /home/dwolfe/projects/poky-git/meta-systemd/recipes-kernel/kmod/kmod_7.bb,
do_fetch
Summary: There was 1 ERROR message shown, returning a non-zero exit code.
bitbake discovery-image  16.51s user 2.65s system 112% cpu 17.031 total


Why is poky/bitbake/whatever running 'git ls-remote'? This seems like a
bug


On Wed, Sep 19, 2012 at 1:33 PM, Evade Flow  wrote:
> I'm not sure how to answer your questions, unfortunately, this is all
> quite new to me. I'm not the maintainer of said layer, and don't know
> anything at all yet about 'layer etiquette'. There does seem to be a
> README.md file in meta-systemd, though:
>
>   - http://git.yoctoproject.org/cgit/cgit.cgi/meta-systemd/tree/README.md
>
> I'm just trying to build the thing. :-)  I'll try converting the tag
> name into a commit hash and see if that helps, thanks a lot...
>
>
> On Wed, Sep 19, 2012 at 1:23 PM, Gary Thomas  wrote:
>> On 2012-09-19 11:15, Evade Flow wrote:

 Where did you get that meta-systemd layer?
>>>
>>>
 From here:
>>>
>>>
>>>- http://git.yoctoproject.org/cgit/cgit.cgi/meta-systemd/
>>
>>
>> Why are there conflicting meta-systemd layers (and pointers thereto)??
>> This layer in git.yoctoproject.org doesn't seem even "legal" - where is
>> the README that is expected with every layer?  Without it, I don't have
>> enough info to be able to report problems like yours...
>>
>> The reason your build fails with BB_NO_NETWORK is that the kmod_7.bb
>> recipe refers to a git tag, not a specific revision, which cannot be
>> resolved without using the network.
>>
>>
>>>
>>>
>>> On Wed, Sep 19, 2012 at 12:50 PM, Gary Thomas  wrote:

 On 2012-09-19 10:34, Evade Flow wrote:
>
>
> Trying to build the meta-ivi discovery-image behind a firewall is
> proving to be quite a challenge. I tried modifying my conf/local.conf
> file as follows:
>
> CONNECTIVITY_CHECK_URIS=""
> BB_GENERATE_MIRROR_TARBALLS = "1"
> SOURCE_MIRROR_URL ?= "file:///home/evadeflow/projects/poky-mirror/"
> INHERIT += "own-mirrors"
>
> and then ran:
>
> % bitbake discovery-image
>
> in a VM on my home laptop over the weekend. (I'm trying to build using
> the meta-ivi layer, per the instructions in its README.) After grinding
> and churning for some 60+ hours, it finally succeeded, leaving 11 GB of
> 'stuff' in my poky-mirror folder.
>
> Then, I copied the poky-mirror folder to a firewalled machine at work
> and added:
>
> BB_NO_NETWORK="1"
>
> to local.conf.  When I tried to bitbake discovery-image on this machine,
> I got the following error:
>
>
> NOTE: Running task 697 of 3568 (ID: 1374,
>
>
> /home/evadeflow/projects/poky-git/meta-systemd/recipes-kernel/kmod/kmod_7.bb,
> do_fetch)
> NOTE: package kmod-7-r0: task do_fetch: Started
> ERROR: Function failed: Network access disabled through BB_NO_NETWORK
> but access rquested with command git ls-remote
> git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git v7 (for url
> None)
> ERROR: Logfile of failure stored in:
>
>
> /home/evadeflow/projects/poky-git/build/tmp-eglibc-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/kmod-7-r0/temp/log.do_fetch.29423
> Log data follows:
> | ERROR: Function failed: Network access disabled through
> BB_NO_NETWORK but access rquested with command git ls-remote
> git://git.kernel.org/pub/s

Re: [yocto] imx6 meta-ivi support

[Andrei Gherzan]

Ack.
On Sep 20, 2012 12:56 AM, "Adrian Alonso"  wrote:

> This patch series enables imx6 target support for meta-ivi based
> on denzil branch.
>
> [meta-ivi][PATCH 1/3] pormap: append portmap.service
> [meta-ivi][PATCH 2/3] wpa-supplicant: append wpa-supplicant.service
> [meta-ivi][PATCH 3/3] layer-management: fix machine search string
>
> ___
> 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] [meta-ivi][PATCH 1/3] pormap: append portmap.service

[Adrian Alonso]

* Remove append conditional for vexpressa9 target
* Allow different targets to append this service

Signed-off-by: Adrian Alonso 
---
 recipes-connectivity/portmap/portmap_6.0.bbappend | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-connectivity/portmap/portmap_6.0.bbappend 
b/recipes-connectivity/portmap/portmap_6.0.bbappend
index a8c6ed5..8c0e4ec 100644
--- a/recipes-connectivity/portmap/portmap_6.0.bbappend
+++ b/recipes-connectivity/portmap/portmap_6.0.bbappend
@@ -1,7 +1,7 @@
 # Find "files" directory
 FILESEXTRAPATHS := "${THISDIR}/files"
 
-SRC_URI_append_vexpressa9 = " file://portmap.service"
+SRC_URI_append = " file://portmap.service"
 
 
 PACKAGES =+ "${PN}-systemd"
-- 
1.7.11.4


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

[yocto] [meta-ivi][PATCH 2/3] wpa-supplicant: append wpa-supplicant.service

[Adrian Alonso]

* Remove append conditional for vexpressa9 target
* Allow different targets to append this service

Signed-off-by: Adrian Alonso 
---
 recipes-connectivity/wpa-supplicant/wpa-supplicant_0.7.3.bbappend | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-connectivity/wpa-supplicant/wpa-supplicant_0.7.3.bbappend 
b/recipes-connectivity/wpa-supplicant/wpa-supplicant_0.7.3.bbappend
index 7f40119..e9c2e94 100644
--- a/recipes-connectivity/wpa-supplicant/wpa-supplicant_0.7.3.bbappend
+++ b/recipes-connectivity/wpa-supplicant/wpa-supplicant_0.7.3.bbappend
@@ -1,7 +1,7 @@
 # Find "files" directory
 FILESEXTRAPATHS := "${THISDIR}/files"
 
-SRC_URI_append_vexpressa9 = " file://wpa_supplicant.service"
+SRC_URI_append = " file://wpa_supplicant.service"
 
 PACKAGES =+ "${PN}-systemd"
 
-- 
1.7.11.4


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

[yocto] imx6 meta-ivi support

[Adrian Alonso]

This patch series enables imx6 target support for meta-ivi based
on denzil branch.

[meta-ivi][PATCH 1/3] pormap: append portmap.service
[meta-ivi][PATCH 2/3] wpa-supplicant: append wpa-supplicant.service
[meta-ivi][PATCH 3/3] layer-management: fix machine search string

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

[yocto] [meta-ivi][PATCH 3/3] layer-management: fix machine search string for imx6 targets

[Adrian Alonso]

* Fix machine search string for imx6 targets
  Likely all imx6 target boards will be prefixed with
  "imx6", this change allows to append -DLINUX flag.

Signed-off-by: Adrian Alonso 
---
 recipes-graphics/layer-management/layer-management_0.9.5.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-graphics/layer-management/layer-management_0.9.5.bb 
b/recipes-graphics/layer-management/layer-management_0.9.5.bb
index 90ad25c..71d8646 100644
--- a/recipes-graphics/layer-management/layer-management_0.9.5.bb
+++ b/recipes-graphics/layer-management/layer-management_0.9.5.bb
@@ -17,7 +17,7 @@ SRC_URI = 
"git://git.genivi.org/srv/git/layer_management;protocol=git \
   "
 # Needed this for imx6 boards to use precompiled EGL libraries
 python () {
-if ((d.getVar("MACHINE", True) or "").find("imx6sabre") != -1):
+if ((d.getVar("MACHINE", True) or "").find("imx6") != -1):
flags = d.getVar("OECMAKE_CXX_FLAGS", True)
flags += " -DLINUX"
d.setVar('OECMAKE_CXX_FLAGS', flags)
-- 
1.7.11.4


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

Re: [yocto] [linux-yocto] [PATCH 0/1] [linux-yocto-3.0] boot-live.cfg: enable BLK_DEV_INITRD in kernel

[Brian Lloyd]

FYI: I've been using linux-yocto 3.2.  After doing a git pull recently,
I found both my own BSP and crownbay-noemgd to be miss configured, both
for linux-yocto and for xorg.conf, like it couldn't find the
configuration files.  I think the root problem with files not being
found may be a little larger than just the linux-yocto-3.0 bake file.
It was a lot of commits grabbed all at once, and I haven't had time to
isolate which commit changed the behavior.  Restoring a backup of the
files from before the pull restored the prior configuration behavior.



On Wed, 2012-09-19 at 23:54 +0300, Mihai Lindner wrote:
> On 2012-09-19 23:32, Bruce Ashfield wrote:
> > On 12-09-19 04:22 PM, Bruce Ashfield wrote:
> >> On 12-09-19 03:39 PM, Mihai Lindner wrote:
> >>> On 2012-09-19 22:01, Bruce Ashfield wrote:
>  On 12-09-19 11:56 AM, Mihai Lindner wrote:
> > On 2012-09-19 18:43, Bruce Ashfield wrote:
> >> On 12-09-18 10:46 AM, Mihai Lindner wrote:
> >>> On 2012-09-18 17:23, Tom Zanussi wrote:
>  On Tue, 2012-09-18 at 16:58 +0300, Mihai Lindner wrote:
> > On 2012-09-18 16:49, Tom Zanussi wrote:
> >> On Tue, 2012-09-18 at 08:21 -0400, Bruce Ashfield wrote:
> >>> On 12-09-18 01:59 AM, Mihai Lindner wrote:
>  Please pull into linux-yocto-3.0, meta.
> 
> >>>
> >>> Adding linux-yocto, Darren and Tom.
> >>>
> >>> This looks fine to me, and we should consider it for all the
> >>> repositories,
> >>> not just 3.0.
> >>>
> >>> Tom/Darren. Any side effects you can think of for this change ?
> >>>
> >>
> >> No, but shouldn't it already be there, inherited from base.cfg?
> >
> > For cedartrail, at least, standard.cfg is used.
> >
> 
>  And standard inherits from base, so it should be turned on. Somehow
>  it's getting turned off in cedartrail...
> >>>
> >>> Yes, it the final .config file is turned off. Solved it by setting
> >>> it in boot-live.
> >>> --Mihai
> >>
> >> To follow up on this, is someone taking a closer look at this config
> >> to see if we can get a root cause for that option being disabled for
> >> this board ?
> >>
> >> I won't be able to poke at it myself for another day or so.
> >>
> >> Bruce
> >>
> > I'm still digging on this, trying to figure out what cfg files are
> > included / omitted by `configme` and why.
> > base.cfg is not included, nor stanadrd.cfg it seems.
> > The list of included cfg files is way to short.
> 
>  That likely means the BSP .scc file is missing and update (i.e. does
>  it still have scc_leaf?) and the tools aren't finding it and
>  auto-generating something to get you up and running.
> 
>  I just checked the meta branch here, and it looks to be updated, but
>  if you look at your build's linux source dir, what's in meta/top_tgt ?
> 
>  Bruce
> 
> >>> In meta/top_tgt i have:
> >>>
> >>> /home/mihai/cedartrail/tmp/work/cedartrail-poky-linux/linux-yocto-3.0.32+git5+46e8fc2bbbe73514e8d99101adaaa373f760ffa7_1+1e79e03d115ed177882ab53909a4f3555e434833-r4.1/linux/meta/cfg/kernel-cache/bsp/cedartrail/cedartrail-standard.scc
> >>>
> >>>
> >>>
> >>> I've also hit an error, after more verbose runs of
> >>> ./cedartrail-standard in meta/cfg/scratch/obj/:
> >>>
> >>> ./0-cedartrail-standard-897c5c055888aca397b3ab0d7be9e6fa.sco: line 17:
> >>> standard_5b57715386592f694588063dd3ec6ebb: command not found
> >>>
> >>> After this the scripts stops.
> >>>
> >>
> >> Aha. This definitely breaks the configuration chain (and would throw
> >> a hard error in the 3.4 kernel) and is where the options drop. But this
> >> should no way be specific to this board. I'll get something configured
> >> here, since I need to see this happen in front of me.
> > 
> > I've finally reproduced this. Leave the issue with me and I'll get
> > back to you with a fix.
> > 
> > Bruce
> 
> Yay! Thanks.
> It's not specific, it's just easier to hit; for cedartrail only 3.0 is 
> available, and also set as preferred.
> 
> --Mihai
> 
> > 
> >>
> >> Cheers,
> >>
> >> Bruce
> >>
> >>
> >>> Mihai
> >>>
> 
> >
> > --Mihai
> >>>
> 
>  Tom
> 
> > --Mihai
> >
> >>
> >> Tom
> >>
> >>> Bruce
> >>>
>  Added BLK_DEV_INITRD in boot-live.cfg for linux-yocto-3.0,
>  meta branch.
>  Cedartrail (at least) cannot boot live from ISO image due to
>  BLK_DEV_INITRD missing:
>  "VFS: Cannot open root device "ram0" or unkown-block(0,0)"
>  Should fix #3050
> 
>  [YOCTO #3050]
> 
>  Signed-off-by: Mihai Lindner
>  ---
> 
>  The following changes since commit
>  bf5ee4945ee6d748e6abe16356f2357f76b

Re: [yocto] About bug 2331

[Marc Ferland]

Saul Wold  writes:

> On 09/19/2012 01:53 PM, Marc Ferland wrote:
>> Saul Wold  writes:
>>
>>> On 09/19/2012 01:41 PM, Marc Ferland wrote:
 Hi,

 I'm currently trying to create a "live" system with squashfs+unionfs and
 I stumbled on the same bug described here:

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

 I was wondering if there was a plan to resolve this issue for 1.3?

>>> Marc,
>>>
>>> It seems to be marked as resolved and verified, is there still and
>>> issue?  If so we need to reopen this bug.  Or are you referring to the
>>> underlying issue?
>>>
>> I was referring to the underlying issue.
>>
>>
> No, unfortunately it seems that did not have visibility, I think bug
> 1487 is open against that issue, at least with an ISO image, which is
> what got partially reverted.  I think the issue was upstream unionfs,
> do you know if any changes to resolve the problem upstream?
>
Unfortunately no. Maybe I'll have more chance using aufs or maybe
overlayfs. Unionfs looks pretty much dead... I'm probably better off
without it!
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] About bug 2331

[Saul Wold]

On 09/19/2012 01:53 PM, Marc Ferland wrote:

Saul Wold  writes:


On 09/19/2012 01:41 PM, Marc Ferland wrote:

Hi,

I'm currently trying to create a "live" system with squashfs+unionfs and
I stumbled on the same bug described here:

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

I was wondering if there was a plan to resolve this issue for 1.3?


Marc,

It seems to be marked as resolved and verified, is there still and
issue?  If so we need to reopen this bug.  Or are you referring to the
underlying issue?


I was referring to the underlying issue.


No, unfortunately it seems that did not have visibility, I think bug 
1487 is open against that issue, at least with an ISO image, which is 
what got partially reverted.  I think the issue was upstream unionfs, do 
you know if any changes to resolve the problem upstream?


Sau!

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

Re: [yocto] All incompassing documentation

[Jeff Osier-Mixon]

It also occurs to me that a source for the confusion might be that
there is more than one build process going on with BitBake. It is used
both to create packages and to install them into a rootfs in order to
create an image. Thus, the workflow looks something like this,
starting from the point of download:

[tarball/repo] -> [source] -> [binary] -> [package] -> [image]

or, the evolution of a chunk of information, in terms of its file type:

[.tar.gz/.git] -> [*.c,*.h,Makefile,etc] -> [executable] ->
[.rpm,.deb,.ipk] -> [.ext3]

Yes, this is a gross generalization with many exceptions. I'm just
trying to capture discrete terms for each step of the process.

Our term "package" is often used to describe the first item, sometimes
to describe the second item, and always used to describe the fourth
item. It is also sometimes used to describe the repository - the
ecosystem of files that defines a given piece of software.

Brian - thanks very much for starting this conversation. Terminology
is important, and just because people use overloaded terms every day
doesn't mean we shouldn't work to differentiate them.

--
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] [linux-yocto] [PATCH 0/1] [linux-yocto-3.0] boot-live.cfg: enable BLK_DEV_INITRD in kernel

[Mihai Lindner]

On 2012-09-19 23:32, Bruce Ashfield wrote:
> On 12-09-19 04:22 PM, Bruce Ashfield wrote:
>> On 12-09-19 03:39 PM, Mihai Lindner wrote:
>>> On 2012-09-19 22:01, Bruce Ashfield wrote:
 On 12-09-19 11:56 AM, Mihai Lindner wrote:
> On 2012-09-19 18:43, Bruce Ashfield wrote:
>> On 12-09-18 10:46 AM, Mihai Lindner wrote:
>>> On 2012-09-18 17:23, Tom Zanussi wrote:
 On Tue, 2012-09-18 at 16:58 +0300, Mihai Lindner wrote:
> On 2012-09-18 16:49, Tom Zanussi wrote:
>> On Tue, 2012-09-18 at 08:21 -0400, Bruce Ashfield wrote:
>>> On 12-09-18 01:59 AM, Mihai Lindner wrote:
 Please pull into linux-yocto-3.0, meta.

>>>
>>> Adding linux-yocto, Darren and Tom.
>>>
>>> This looks fine to me, and we should consider it for all the
>>> repositories,
>>> not just 3.0.
>>>
>>> Tom/Darren. Any side effects you can think of for this change ?
>>>
>>
>> No, but shouldn't it already be there, inherited from base.cfg?
>
> For cedartrail, at least, standard.cfg is used.
>

 And standard inherits from base, so it should be turned on. Somehow
 it's getting turned off in cedartrail...
>>>
>>> Yes, it the final .config file is turned off. Solved it by setting
>>> it in boot-live.
>>> --Mihai
>>
>> To follow up on this, is someone taking a closer look at this config
>> to see if we can get a root cause for that option being disabled for
>> this board ?
>>
>> I won't be able to poke at it myself for another day or so.
>>
>> Bruce
>>
> I'm still digging on this, trying to figure out what cfg files are
> included / omitted by `configme` and why.
> base.cfg is not included, nor stanadrd.cfg it seems.
> The list of included cfg files is way to short.

 That likely means the BSP .scc file is missing and update (i.e. does
 it still have scc_leaf?) and the tools aren't finding it and
 auto-generating something to get you up and running.

 I just checked the meta branch here, and it looks to be updated, but
 if you look at your build's linux source dir, what's in meta/top_tgt ?

 Bruce

>>> In meta/top_tgt i have:
>>>
>>> /home/mihai/cedartrail/tmp/work/cedartrail-poky-linux/linux-yocto-3.0.32+git5+46e8fc2bbbe73514e8d99101adaaa373f760ffa7_1+1e79e03d115ed177882ab53909a4f3555e434833-r4.1/linux/meta/cfg/kernel-cache/bsp/cedartrail/cedartrail-standard.scc
>>>
>>>
>>>
>>> I've also hit an error, after more verbose runs of
>>> ./cedartrail-standard in meta/cfg/scratch/obj/:
>>>
>>> ./0-cedartrail-standard-897c5c055888aca397b3ab0d7be9e6fa.sco: line 17:
>>> standard_5b57715386592f694588063dd3ec6ebb: command not found
>>>
>>> After this the scripts stops.
>>>
>>
>> Aha. This definitely breaks the configuration chain (and would throw
>> a hard error in the 3.4 kernel) and is where the options drop. But this
>> should no way be specific to this board. I'll get something configured
>> here, since I need to see this happen in front of me.
> 
> I've finally reproduced this. Leave the issue with me and I'll get
> back to you with a fix.
> 
> Bruce

Yay! Thanks.
It's not specific, it's just easier to hit; for cedartrail only 3.0 is 
available, and also set as preferred.

--Mihai

> 
>>
>> Cheers,
>>
>> Bruce
>>
>>
>>> Mihai
>>>

>
> --Mihai
>>>

 Tom

> --Mihai
>
>>
>> Tom
>>
>>> Bruce
>>>
 Added BLK_DEV_INITRD in boot-live.cfg for linux-yocto-3.0,
 meta branch.
 Cedartrail (at least) cannot boot live from ISO image due to
 BLK_DEV_INITRD missing:
 "VFS: Cannot open root device "ram0" or unkown-block(0,0)"
 Should fix #3050

 [YOCTO #3050]

 Signed-off-by: Mihai Lindner
 ---

 The following changes since commit
 bf5ee4945ee6d748e6abe16356f2357f76b5e2f0:

 meta: rename virto.scc to virtio.scc (2012-08-18 22:09:35 -0400)

 are available in the git repository at:
 git://git.yoctoproject.org/poky-contrib
 mihai/linux-yocto-3.0/meta

 Mihai Lindner (1):
 boot-live.cfg: enable BLK_DEV_INITRD in kernel

 meta/cfg/kernel-cache/cfg/boot-live.cfg | 2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

 Mihai Lindner (1):
 boot-live.cfg: enable BLK_DEV_INITRD in kernel

 meta/cfg/kernel-cache/cfg/boot-live.cfg | 2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

>>>
>>
>>
>>
>>
>
>




>>>

Re: [yocto] About bug 2331

[Marc Ferland]

Saul Wold  writes:

> On 09/19/2012 01:41 PM, Marc Ferland wrote:
>> Hi,
>>
>> I'm currently trying to create a "live" system with squashfs+unionfs and
>> I stumbled on the same bug described here:
>>
>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=2331
>>
>> I was wondering if there was a plan to resolve this issue for 1.3?
>>
> Marc,
>
> It seems to be marked as resolved and verified, is there still and
> issue?  If so we need to reopen this bug.  Or are you referring to the
> underlying issue?
>
I was referring to the underlying issue.
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] About bug 2331

[Saul Wold]

On 09/19/2012 01:41 PM, Marc Ferland wrote:

Hi,

I'm currently trying to create a "live" system with squashfs+unionfs and
I stumbled on the same bug described here:

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

I was wondering if there was a plan to resolve this issue for 1.3?


Marc,

It seems to be marked as resolved and verified, is there still and 
issue?  If so we need to reopen this bug.  Or are you referring to the 
underlying issue?


Sau!


Regards,

Marc
___
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] All incompassing documentation

[Jeff Osier-Mixon]

I'm afraid "source tarball" doesn't quite work, as not all are
required to be tarballs, e.g. if something is in a git repo or in a
local CVS repo.

Can it be true that there is no single term that refers to the
collection of pieces that, when built, create a discrete package?

On Wed, Sep 19, 2012 at 8:50 AM, Brian Lloyd  wrote:
> I would like to point out Yocto's own documentation uses it for two
> separate items, which is the point I was making.  Neither of which are
> source tarballs
>
> It is a product produced by Yocto.
> It is the items to be installed from the host system.

I think these actually refer to the same thing. "Packages" are
products of the Yocto Project build process whose purpose is to be
installed on the target. They are "packaged" using a specific format
(.rpm, .deb, .ipk). This is a universal development term, at least
within the wider Linux community, not a specific Yocto Project term.
Unless I misunderstand what you are saying?

> That may be right, but if so, we can't say that for Yocto it only means
> the first, as we use it for the second as well.  If we want it to only
> be the first, then we must use a different term for the second, such as
> host applications, and the user should be notified of the unusual word
> choice and why early in the documentation.  I believe there are several
> locations where terms are explained already in the documentation, even
> if we later use the term in a way other than that identified as it's
> meaning (3.4. Yocto Project Terms comes to mind).  Discussing Package
> meaning there, perhaps we should identify the term that will be used for
> host package, or how we will identify when the term is used with a
> different meaning than the one just given.

There shouldn't be any applications on your host (meaning: built for
your host) that end up being installed on the target. There may be
"packages" that you have downloaded that you'd like to install on your
target, but that

> Or if we concede that packages is what the user expects to see when
> discussing what to install, we need to disambiguate in some way to
> differentiate the two uses.  Indexes are good at this.  The biggest
> advantage to an index over straight search is that author's can use
> context to differentiate the different uses when a word has them.
> Another option could be prepending to both the context at each location
> used, so we use Yocto package and host package or where we always prefix
> context to one of the two for every use.  However, doing only one with a
> context makes for more manual searches, where we are making a document
> with the goal of making searching for information more effective.

Can you tell us what you mean by "host package"?

>
> On Tue, 2012-09-18 at 21:02 -0700, Jeff Osier-Mixon wrote:
>> 
>>
>> On Tue, Sep 18, 2012 at 12:04 PM, Trevor Woerner  wrote:
>> > On Tue, Sep 18, 2012 at 2:23 PM, Brian Lloyd  
>> > wrote:
>> >> Most of my hits for such an item
>> >> discuss the packages I will need to install in my host distribution so I
>> >> can use the yocto project (not surprised, the danger of a term as vague
>> >> as packages).
>> >
>> > In bitbake/yocto/OE/etc. the term "packages" is not vague and has a
>> > very specific meaning: bitbake processes recipes to produce one or
>> > more packages. Some of these packages are then assembled into an
>>
>> This is quite true - but the term itself is overloaded. I have often
>> heard "package" referred to also as the collection of source code one
>> would use to create a given piece of software, e.g. "the busybox
>> package". This is no doubt the result of downloading numerous
>> "packages" from the net in binary form rather than source. It doesn't
>> help that there are "source packages" in the RPM world
>> (http://www.rpm.org/max-rpm/s1-rpm-miscellania-srpms.html) and in the
>> Debian world 
>> (http://www.debian.org/doc/manuals/apt-howto/ch-sourcehandling.en.html),
>> so the confusion is natural.
>>
>> In OE-based systems like the Yocto Project, the term refers to the
>> results of a build rather than the ingredients. I agree with you that
>> we should continue to push the correct usage to unload the term.
>> Anyone have a good term for "source packages"?
>>
>
>
> ___
> 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] About bug 2331

[Marc Ferland]

Hi,

I'm currently trying to create a "live" system with squashfs+unionfs and
I stumbled on the same bug described here:

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

I was wondering if there was a plan to resolve this issue for 1.3?

Regards,

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

Re: [yocto] [linux-yocto] [PATCH 0/1] [linux-yocto-3.0] boot-live.cfg: enable BLK_DEV_INITRD in kernel

[Bruce Ashfield]

On 12-09-19 04:22 PM, Bruce Ashfield wrote:

On 12-09-19 03:39 PM, Mihai Lindner wrote:

On 2012-09-19 22:01, Bruce Ashfield wrote:

On 12-09-19 11:56 AM, Mihai Lindner wrote:

On 2012-09-19 18:43, Bruce Ashfield wrote:

On 12-09-18 10:46 AM, Mihai Lindner wrote:

On 2012-09-18 17:23, Tom Zanussi wrote:

On Tue, 2012-09-18 at 16:58 +0300, Mihai Lindner wrote:

On 2012-09-18 16:49, Tom Zanussi wrote:

On Tue, 2012-09-18 at 08:21 -0400, Bruce Ashfield wrote:

On 12-09-18 01:59 AM, Mihai Lindner wrote:

Please pull into linux-yocto-3.0, meta.



Adding linux-yocto, Darren and Tom.

This looks fine to me, and we should consider it for all the
repositories,
not just 3.0.

Tom/Darren. Any side effects you can think of for this change ?



No, but shouldn't it already be there, inherited from base.cfg?


For cedartrail, at least, standard.cfg is used.



And standard inherits from base, so it should be turned on. Somehow
it's getting turned off in cedartrail...


Yes, it the final .config file is turned off. Solved it by setting
it in boot-live.
--Mihai


To follow up on this, is someone taking a closer look at this config
to see if we can get a root cause for that option being disabled for
this board ?

I won't be able to poke at it myself for another day or so.

Bruce


I'm still digging on this, trying to figure out what cfg files are
included / omitted by `configme` and why.
base.cfg is not included, nor stanadrd.cfg it seems.
The list of included cfg files is way to short.


That likely means the BSP .scc file is missing and update (i.e. does
it still have scc_leaf?) and the tools aren't finding it and
auto-generating something to get you up and running.

I just checked the meta branch here, and it looks to be updated, but
if you look at your build's linux source dir, what's in meta/top_tgt ?

Bruce


In meta/top_tgt i have:

/home/mihai/cedartrail/tmp/work/cedartrail-poky-linux/linux-yocto-3.0.32+git5+46e8fc2bbbe73514e8d99101adaaa373f760ffa7_1+1e79e03d115ed177882ab53909a4f3555e434833-r4.1/linux/meta/cfg/kernel-cache/bsp/cedartrail/cedartrail-standard.scc



I've also hit an error, after more verbose runs of
./cedartrail-standard in meta/cfg/scratch/obj/:

./0-cedartrail-standard-897c5c055888aca397b3ab0d7be9e6fa.sco: line 17:
standard_5b57715386592f694588063dd3ec6ebb: command not found

After this the scripts stops.



Aha. This definitely breaks the configuration chain (and would throw
a hard error in the 3.4 kernel) and is where the options drop. But this
should no way be specific to this board. I'll get something configured
here, since I need to see this happen in front of me.


I've finally reproduced this. Leave the issue with me and I'll get
back to you with a fix.

Bruce



Cheers,

Bruce



Mihai





--Mihai




Tom


--Mihai



Tom


Bruce


Added BLK_DEV_INITRD in boot-live.cfg for linux-yocto-3.0,
meta branch.
Cedartrail (at least) cannot boot live from ISO image due to
BLK_DEV_INITRD missing:
"VFS: Cannot open root device "ram0" or unkown-block(0,0)"
Should fix #3050

[YOCTO #3050]

Signed-off-by: Mihai Lindner
---

The following changes since commit
bf5ee4945ee6d748e6abe16356f2357f76b5e2f0:

meta: rename virto.scc to virtio.scc (2012-08-18 22:09:35 -0400)

are available in the git repository at:
git://git.yoctoproject.org/poky-contrib
mihai/linux-yocto-3.0/meta

Mihai Lindner (1):
boot-live.cfg: enable BLK_DEV_INITRD in kernel

meta/cfg/kernel-cache/cfg/boot-live.cfg | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)

Mihai Lindner (1):
boot-live.cfg: enable BLK_DEV_INITRD in kernel

meta/cfg/kernel-cache/cfg/boot-live.cfg | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)



































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


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

Re: [yocto] [PATCH 0/1] [linux-yocto-3.0] boot-live.cfg: enable BLK_DEV_INITRD in kernel

[Bruce Ashfield]

On 12-09-19 03:39 PM, Mihai Lindner wrote:

On 2012-09-19 22:01, Bruce Ashfield wrote:

On 12-09-19 11:56 AM, Mihai Lindner wrote:

On 2012-09-19 18:43, Bruce Ashfield wrote:

On 12-09-18 10:46 AM, Mihai Lindner wrote:

On 2012-09-18 17:23, Tom Zanussi wrote:

On Tue, 2012-09-18 at 16:58 +0300, Mihai Lindner wrote:

On 2012-09-18 16:49, Tom Zanussi wrote:

On Tue, 2012-09-18 at 08:21 -0400, Bruce Ashfield wrote:

On 12-09-18 01:59 AM, Mihai Lindner wrote:

Please pull into linux-yocto-3.0, meta.



Adding linux-yocto, Darren and Tom.

This looks fine to me, and we should consider it for all the repositories,
not just 3.0.

Tom/Darren. Any side effects you can think of for this change ?



No, but shouldn't it already be there, inherited from base.cfg?


For cedartrail, at least, standard.cfg is used.



And standard inherits from base, so it should be turned on.  Somehow
it's getting turned off in cedartrail...


Yes, it the final .config file is turned off. Solved it by setting it in 
boot-live.
--Mihai


To follow up on this, is someone taking a closer look at this config
to see if we can get a root cause for that option being disabled for
this board ?

I won't be able to poke at it myself for another day or so.

Bruce


I'm still digging on this, trying to figure out what cfg files are included / 
omitted by `configme` and why.
base.cfg is not included, nor stanadrd.cfg it seems.
The list of included cfg files is way to short.


That likely means the BSP .scc file is missing and update (i.e. does
it still have scc_leaf?) and the tools aren't finding it and auto-generating 
something to get you up and running.

I just checked the meta branch here, and it looks to be updated, but
if you look at your build's linux source dir, what's in meta/top_tgt ?

Bruce


In meta/top_tgt i have:

/home/mihai/cedartrail/tmp/work/cedartrail-poky-linux/linux-yocto-3.0.32+git5+46e8fc2bbbe73514e8d99101adaaa373f760ffa7_1+1e79e03d115ed177882ab53909a4f3555e434833-r4.1/linux/meta/cfg/kernel-cache/bsp/cedartrail/cedartrail-standard.scc


I've also hit an error, after more verbose runs of ./cedartrail-standard in 
meta/cfg/scratch/obj/:

./0-cedartrail-standard-897c5c055888aca397b3ab0d7be9e6fa.sco: line 17: 
standard_5b57715386592f694588063dd3ec6ebb: command not found

After this the scripts stops.



Aha. This definitely breaks the configuration chain (and would throw
a hard error in the 3.4 kernel) and is where the options drop. But this
should no way be specific to this board. I'll get something configured
here, since I need to see this happen in front of me.

Cheers,

Bruce



Mihai





--Mihai




Tom


--Mihai



Tom


Bruce


Added BLK_DEV_INITRD in boot-live.cfg for linux-yocto-3.0, meta branch.
Cedartrail (at least) cannot boot live from ISO image due to
BLK_DEV_INITRD missing:
"VFS: Cannot open root device "ram0" or unkown-block(0,0)"
Should fix #3050

[YOCTO #3050]

Signed-off-by: Mihai Lindner
---

The following changes since commit bf5ee4945ee6d748e6abe16356f2357f76b5e2f0:

  meta: rename virto.scc to virtio.scc (2012-08-18 22:09:35 -0400)

are available in the git repository at:
  git://git.yoctoproject.org/poky-contrib mihai/linux-yocto-3.0/meta

Mihai Lindner (1):
  boot-live.cfg: enable BLK_DEV_INITRD in kernel

 meta/cfg/kernel-cache/cfg/boot-live.cfg |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

Mihai Lindner (1):
  boot-live.cfg: enable BLK_DEV_INITRD in kernel

 meta/cfg/kernel-cache/cfg/boot-live.cfg |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)



































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

Re: [yocto] [PATCH 0/1] [linux-yocto-3.0] boot-live.cfg: enable BLK_DEV_INITRD in kernel

[Mihai Lindner]

On 2012-09-19 22:01, Bruce Ashfield wrote:
> On 12-09-19 11:56 AM, Mihai Lindner wrote:
>> On 2012-09-19 18:43, Bruce Ashfield wrote:
>>> On 12-09-18 10:46 AM, Mihai Lindner wrote:
 On 2012-09-18 17:23, Tom Zanussi wrote:
> On Tue, 2012-09-18 at 16:58 +0300, Mihai Lindner wrote:
>> On 2012-09-18 16:49, Tom Zanussi wrote:
>>> On Tue, 2012-09-18 at 08:21 -0400, Bruce Ashfield wrote:
 On 12-09-18 01:59 AM, Mihai Lindner wrote:
> Please pull into linux-yocto-3.0, meta.
>

 Adding linux-yocto, Darren and Tom.

 This looks fine to me, and we should consider it for all the 
 repositories,
 not just 3.0.

 Tom/Darren. Any side effects you can think of for this change ?

>>>
>>> No, but shouldn't it already be there, inherited from base.cfg?
>>
>> For cedartrail, at least, standard.cfg is used.
>>
>
> And standard inherits from base, so it should be turned on.  Somehow
> it's getting turned off in cedartrail...

 Yes, it the final .config file is turned off. Solved it by setting it in 
 boot-live.
 --Mihai
>>>
>>> To follow up on this, is someone taking a closer look at this config
>>> to see if we can get a root cause for that option being disabled for
>>> this board ?
>>>
>>> I won't be able to poke at it myself for another day or so.
>>>
>>> Bruce
>>>
>> I'm still digging on this, trying to figure out what cfg files are included 
>> / omitted by `configme` and why.
>> base.cfg is not included, nor stanadrd.cfg it seems.
>> The list of included cfg files is way to short.
> 
> That likely means the BSP .scc file is missing and update (i.e. does
> it still have scc_leaf?) and the tools aren't finding it and auto-generating 
> something to get you up and running.
> 
> I just checked the meta branch here, and it looks to be updated, but
> if you look at your build's linux source dir, what's in meta/top_tgt ?
> 
> Bruce
> 
In meta/top_tgt i have:

/home/mihai/cedartrail/tmp/work/cedartrail-poky-linux/linux-yocto-3.0.32+git5+46e8fc2bbbe73514e8d99101adaaa373f760ffa7_1+1e79e03d115ed177882ab53909a4f3555e434833-r4.1/linux/meta/cfg/kernel-cache/bsp/cedartrail/cedartrail-standard.scc


I've also hit an error, after more verbose runs of ./cedartrail-standard in 
meta/cfg/scratch/obj/:

./0-cedartrail-standard-897c5c055888aca397b3ab0d7be9e6fa.sco: line 17: 
standard_5b57715386592f694588063dd3ec6ebb: command not found

After this the scripts stops.

Mihai

> 
>>
>> --Mihai

>
> Tom
>
>> --Mihai
>>
>>>
>>> Tom
>>>
 Bruce

> Added BLK_DEV_INITRD in boot-live.cfg for linux-yocto-3.0, meta 
> branch.
> Cedartrail (at least) cannot boot live from ISO image due to
> BLK_DEV_INITRD missing:
> "VFS: Cannot open root device "ram0" or unkown-block(0,0)"
> Should fix #3050
>
> [YOCTO #3050]
>
> Signed-off-by: Mihai Lindner
> ---
>
> The following changes since commit 
> bf5ee4945ee6d748e6abe16356f2357f76b5e2f0:
>
>  meta: rename virto.scc to virtio.scc (2012-08-18 22:09:35 -0400)
>
> are available in the git repository at:
>  git://git.yoctoproject.org/poky-contrib 
> mihai/linux-yocto-3.0/meta
>
> Mihai Lindner (1):
>  boot-live.cfg: enable BLK_DEV_INITRD in kernel
>
> meta/cfg/kernel-cache/cfg/boot-live.cfg |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> Mihai Lindner (1):
>  boot-live.cfg: enable BLK_DEV_INITRD in kernel
>
> meta/cfg/kernel-cache/cfg/boot-live.cfg |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>

>>>
>>>
>>>
>>>
>>
>>
>
>
>
>


>>>
>>>
>>>
>>
>>
> 
> 
> 


-- 
Mihai Lindner
Yocto Project
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [PATCH 0/1] [linux-yocto-3.0] boot-live.cfg: enable BLK_DEV_INITRD in kernel

[Bruce Ashfield]

On 12-09-19 11:56 AM, Mihai Lindner wrote:

On 2012-09-19 18:43, Bruce Ashfield wrote:

On 12-09-18 10:46 AM, Mihai Lindner wrote:

On 2012-09-18 17:23, Tom Zanussi wrote:

On Tue, 2012-09-18 at 16:58 +0300, Mihai Lindner wrote:

On 2012-09-18 16:49, Tom Zanussi wrote:

On Tue, 2012-09-18 at 08:21 -0400, Bruce Ashfield wrote:

On 12-09-18 01:59 AM, Mihai Lindner wrote:

Please pull into linux-yocto-3.0, meta.



Adding linux-yocto, Darren and Tom.

This looks fine to me, and we should consider it for all the repositories,
not just 3.0.

Tom/Darren. Any side effects you can think of for this change ?



No, but shouldn't it already be there, inherited from base.cfg?


For cedartrail, at least, standard.cfg is used.



And standard inherits from base, so it should be turned on.  Somehow
it's getting turned off in cedartrail...


Yes, it the final .config file is turned off. Solved it by setting it in 
boot-live.
--Mihai


To follow up on this, is someone taking a closer look at this config
to see if we can get a root cause for that option being disabled for
this board ?

I won't be able to poke at it myself for another day or so.

Bruce


I'm still digging on this, trying to figure out what cfg files are included / 
omitted by `configme` and why.
base.cfg is not included, nor stanadrd.cfg it seems.
The list of included cfg files is way to short.


That likely means the BSP .scc file is missing and update (i.e. does
it still have scc_leaf?) and the tools aren't finding it and 
auto-generating something to get you up and running.


I just checked the meta branch here, and it looks to be updated, but
if you look at your build's linux source dir, what's in meta/top_tgt ?

Bruce




--Mihai




Tom


--Mihai



Tom


Bruce


Added BLK_DEV_INITRD in boot-live.cfg for linux-yocto-3.0, meta branch.
Cedartrail (at least) cannot boot live from ISO image due to
BLK_DEV_INITRD missing:
"VFS: Cannot open root device "ram0" or unkown-block(0,0)"
Should fix #3050

[YOCTO #3050]

Signed-off-by: Mihai Lindner
---

The following changes since commit bf5ee4945ee6d748e6abe16356f2357f76b5e2f0:

 meta: rename virto.scc to virtio.scc (2012-08-18 22:09:35 -0400)

are available in the git repository at:
 git://git.yoctoproject.org/poky-contrib mihai/linux-yocto-3.0/meta

Mihai Lindner (1):
 boot-live.cfg: enable BLK_DEV_INITRD in kernel

meta/cfg/kernel-cache/cfg/boot-live.cfg |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)

Mihai Lindner (1):
 boot-live.cfg: enable BLK_DEV_INITRD in kernel

meta/cfg/kernel-cache/cfg/boot-live.cfg |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)




























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

Re: [yocto] maximum recursion depth exceeded errors with gnutls_2.12.17.bb

[Paul Eggleton]

On Wednesday 19 September 2012 17:00:20 Saxena, Rahul wrote:
> I have suddenly started getting maximum recursion depth exceeded python
> errors with gnutls_2.12.17.bb
> 
>  recipe on Denzil branch.
> 
> I am copying snippets of the message log below (some of the stuff that
> repeats has been removed)
> 
> Any suggestions as what could be the problem ?

This is a symptom of this bug:

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

I've sent a backported patch to fix this for denzil, Scott is about to add it 
to his queue:

http://patchwork.openembedded.org/patch/36547/

Cheers,
Paul

-- 

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

Re: [yocto] BB_NO_NETWORK and own-mirrors not working with meta-systemd

[Evade Flow]

I'm not sure how to answer your questions, unfortunately, this is all
quite new to me. I'm not the maintainer of said layer, and don't know
anything at all yet about 'layer etiquette'. There does seem to be a
README.md file in meta-systemd, though:

  - http://git.yoctoproject.org/cgit/cgit.cgi/meta-systemd/tree/README.md

I'm just trying to build the thing. :-)  I'll try converting the tag
name into a commit hash and see if that helps, thanks a lot...


On Wed, Sep 19, 2012 at 1:23 PM, Gary Thomas  wrote:
> On 2012-09-19 11:15, Evade Flow wrote:
>>>
>>> Where did you get that meta-systemd layer?
>>
>>
>>> From here:
>>
>>
>>- http://git.yoctoproject.org/cgit/cgit.cgi/meta-systemd/
>
>
> Why are there conflicting meta-systemd layers (and pointers thereto)??
> This layer in git.yoctoproject.org doesn't seem even "legal" - where is
> the README that is expected with every layer?  Without it, I don't have
> enough info to be able to report problems like yours...
>
> The reason your build fails with BB_NO_NETWORK is that the kmod_7.bb
> recipe refers to a git tag, not a specific revision, which cannot be
> resolved without using the network.
>
>
>>
>>
>> On Wed, Sep 19, 2012 at 12:50 PM, Gary Thomas  wrote:
>>>
>>> On 2012-09-19 10:34, Evade Flow wrote:


 Trying to build the meta-ivi discovery-image behind a firewall is
 proving to be quite a challenge. I tried modifying my conf/local.conf
 file as follows:

 CONNECTIVITY_CHECK_URIS=""
 BB_GENERATE_MIRROR_TARBALLS = "1"
 SOURCE_MIRROR_URL ?= "file:///home/evadeflow/projects/poky-mirror/"
 INHERIT += "own-mirrors"

 and then ran:

 % bitbake discovery-image

 in a VM on my home laptop over the weekend. (I'm trying to build using
 the meta-ivi layer, per the instructions in its README.) After grinding
 and churning for some 60+ hours, it finally succeeded, leaving 11 GB of
 'stuff' in my poky-mirror folder.

 Then, I copied the poky-mirror folder to a firewalled machine at work
 and added:

 BB_NO_NETWORK="1"

 to local.conf.  When I tried to bitbake discovery-image on this machine,
 I got the following error:


 NOTE: Running task 697 of 3568 (ID: 1374,


 /home/evadeflow/projects/poky-git/meta-systemd/recipes-kernel/kmod/kmod_7.bb,
 do_fetch)
 NOTE: package kmod-7-r0: task do_fetch: Started
 ERROR: Function failed: Network access disabled through BB_NO_NETWORK
 but access rquested with command git ls-remote
 git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git v7 (for url
 None)
 ERROR: Logfile of failure stored in:


 /home/evadeflow/projects/poky-git/build/tmp-eglibc-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/kmod-7-r0/temp/log.do_fetch.29423
 Log data follows:
 | ERROR: Function failed: Network access disabled through
 BB_NO_NETWORK but access rquested with command git ls-remote
 git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git v7 (for url
 None)
 NOTE: package kmod-7-r0: task do_fetch: Failed
 ERROR: Task 1374


 (/home/evadeflow/projects/poky-git/meta-systemd/recipes-kernel/kmod/kmod_7.bb,
 do_fetch) failed with exit code '1'
 Waiting for 1 running tasks to finish:
 0: libusb1-1.0.8-r4 do_compile (pid 29232)
 NOTE: package libusb1-1.0.8-r4: task do_compile: Succeeded
 NOTE: Tasks Summary: Attempted 697 tasks of which 105 didn't need to
 be rerun and 1 failed.

 Summary: 1 task failed:


 /home/evadeflow/projects/poky-git/meta-systemd/recipes-kernel/kmod/kmod_7.bb,
 do_fetch
 Summary: There was 1 ERROR message shown, returning a non-zero exit
 code.
 bitbake discovery-image  5338.15s user 995.52s system 187% cpu 56:12.92
 total

 [NOTE: I'm on poky denzil@65ffa73, meta-ivi denzil@e068388, and
 meta-systemd denzil@6a358e9. Also, that typo in the output
 isn't mine, i.e., 'rquested' should be 'requested'.]

 Can anyone explain what's going on here? If I look in the poky-mirror
 folder for kmod-related stuff, I see:

 % ls /home/evadeflow/projects/poky-mirror/*kmod*


 /home/evadeflow/projects/poky-mirror/git2_git.kernel.org.pub.scm.utils.kernel.kmod.kmod.git.tar.gz


 /home/evadeflow/projects/poky-mirror/git2_git.profusion.mobi.kmod.git.tar.gz

 I *think* this is what needs to be downloaded for this recipe(?) Why is
 `git ls-remote` being run at all? I'm not sure whether this is the fault
 of poky/oe-core, or of the meta-systemd layer. I'd just really wish it
 worked. `:-}  Any advice?
>>>
>>>
>>>
>>> Where did you get that meta-systemd layer?  I can't find your
>>> recipe nor that revision (denzil@6a358e9) in the published version
>>> which is at git://git.openembedded.org/meta-openembedded according
>>> to http://www.openembedded.org/wiki/LayerIndex
>>>
>>> --
>>> --

Re: [yocto] BB_NO_NETWORK and own-mirrors not working with meta-systemd

[Gary Thomas]

On 2012-09-19 11:15, Evade Flow wrote:

Where did you get that meta-systemd layer?



From here:


   - http://git.yoctoproject.org/cgit/cgit.cgi/meta-systemd/


Why are there conflicting meta-systemd layers (and pointers thereto)??
This layer in git.yoctoproject.org doesn't seem even "legal" - where is
the README that is expected with every layer?  Without it, I don't have
enough info to be able to report problems like yours...

The reason your build fails with BB_NO_NETWORK is that the kmod_7.bb
recipe refers to a git tag, not a specific revision, which cannot be
resolved without using the network.




On Wed, Sep 19, 2012 at 12:50 PM, Gary Thomas  wrote:

On 2012-09-19 10:34, Evade Flow wrote:


Trying to build the meta-ivi discovery-image behind a firewall is
proving to be quite a challenge. I tried modifying my conf/local.conf
file as follows:

CONNECTIVITY_CHECK_URIS=""
BB_GENERATE_MIRROR_TARBALLS = "1"
SOURCE_MIRROR_URL ?= "file:///home/evadeflow/projects/poky-mirror/"
INHERIT += "own-mirrors"

and then ran:

% bitbake discovery-image

in a VM on my home laptop over the weekend. (I'm trying to build using
the meta-ivi layer, per the instructions in its README.) After grinding
and churning for some 60+ hours, it finally succeeded, leaving 11 GB of
'stuff' in my poky-mirror folder.

Then, I copied the poky-mirror folder to a firewalled machine at work
and added:

BB_NO_NETWORK="1"

to local.conf.  When I tried to bitbake discovery-image on this machine,
I got the following error:


NOTE: Running task 697 of 3568 (ID: 1374,

/home/evadeflow/projects/poky-git/meta-systemd/recipes-kernel/kmod/kmod_7.bb,
do_fetch)
NOTE: package kmod-7-r0: task do_fetch: Started
ERROR: Function failed: Network access disabled through BB_NO_NETWORK
but access rquested with command git ls-remote
git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git v7 (for url
None)
ERROR: Logfile of failure stored in:

/home/evadeflow/projects/poky-git/build/tmp-eglibc-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/kmod-7-r0/temp/log.do_fetch.29423
Log data follows:
| ERROR: Function failed: Network access disabled through
BB_NO_NETWORK but access rquested with command git ls-remote
git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git v7 (for url
None)
NOTE: package kmod-7-r0: task do_fetch: Failed
ERROR: Task 1374

(/home/evadeflow/projects/poky-git/meta-systemd/recipes-kernel/kmod/kmod_7.bb,
do_fetch) failed with exit code '1'
Waiting for 1 running tasks to finish:
0: libusb1-1.0.8-r4 do_compile (pid 29232)
NOTE: package libusb1-1.0.8-r4: task do_compile: Succeeded
NOTE: Tasks Summary: Attempted 697 tasks of which 105 didn't need to
be rerun and 1 failed.

Summary: 1 task failed:

/home/evadeflow/projects/poky-git/meta-systemd/recipes-kernel/kmod/kmod_7.bb,
do_fetch
Summary: There was 1 ERROR message shown, returning a non-zero exit code.
bitbake discovery-image  5338.15s user 995.52s system 187% cpu 56:12.92
total

[NOTE: I'm on poky denzil@65ffa73, meta-ivi denzil@e068388, and
meta-systemd denzil@6a358e9. Also, that typo in the output
isn't mine, i.e., 'rquested' should be 'requested'.]

Can anyone explain what's going on here? If I look in the poky-mirror
folder for kmod-related stuff, I see:

% ls /home/evadeflow/projects/poky-mirror/*kmod*

/home/evadeflow/projects/poky-mirror/git2_git.kernel.org.pub.scm.utils.kernel.kmod.kmod.git.tar.gz

/home/evadeflow/projects/poky-mirror/git2_git.profusion.mobi.kmod.git.tar.gz

I *think* this is what needs to be downloaded for this recipe(?) Why is
`git ls-remote` being run at all? I'm not sure whether this is the fault
of poky/oe-core, or of the meta-systemd layer. I'd just really wish it
worked. `:-}  Any advice?



Where did you get that meta-systemd layer?  I can't find your
recipe nor that revision (denzil@6a358e9) in the published version
which is at git://git.openembedded.org/meta-openembedded according
to http://www.openembedded.org/wiki/LayerIndex

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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


--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [yocto] BB_NO_NETWORK and own-mirrors not working with meta-systemd

[Evade Flow]

> Where did you get that meta-systemd layer?

>From here:

  - http://git.yoctoproject.org/cgit/cgit.cgi/meta-systemd/


On Wed, Sep 19, 2012 at 12:50 PM, Gary Thomas  wrote:
> On 2012-09-19 10:34, Evade Flow wrote:
>>
>> Trying to build the meta-ivi discovery-image behind a firewall is
>> proving to be quite a challenge. I tried modifying my conf/local.conf
>> file as follows:
>>
>> CONNECTIVITY_CHECK_URIS=""
>> BB_GENERATE_MIRROR_TARBALLS = "1"
>> SOURCE_MIRROR_URL ?= "file:///home/evadeflow/projects/poky-mirror/"
>> INHERIT += "own-mirrors"
>>
>> and then ran:
>>
>> % bitbake discovery-image
>>
>> in a VM on my home laptop over the weekend. (I'm trying to build using
>> the meta-ivi layer, per the instructions in its README.) After grinding
>> and churning for some 60+ hours, it finally succeeded, leaving 11 GB of
>> 'stuff' in my poky-mirror folder.
>>
>> Then, I copied the poky-mirror folder to a firewalled machine at work
>> and added:
>>
>> BB_NO_NETWORK="1"
>>
>> to local.conf.  When I tried to bitbake discovery-image on this machine,
>> I got the following error:
>>
>>
>> NOTE: Running task 697 of 3568 (ID: 1374,
>>
>> /home/evadeflow/projects/poky-git/meta-systemd/recipes-kernel/kmod/kmod_7.bb,
>> do_fetch)
>> NOTE: package kmod-7-r0: task do_fetch: Started
>> ERROR: Function failed: Network access disabled through BB_NO_NETWORK
>> but access rquested with command git ls-remote
>> git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git v7 (for url
>> None)
>> ERROR: Logfile of failure stored in:
>>
>> /home/evadeflow/projects/poky-git/build/tmp-eglibc-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/kmod-7-r0/temp/log.do_fetch.29423
>> Log data follows:
>> | ERROR: Function failed: Network access disabled through
>> BB_NO_NETWORK but access rquested with command git ls-remote
>> git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git v7 (for url
>> None)
>> NOTE: package kmod-7-r0: task do_fetch: Failed
>> ERROR: Task 1374
>>
>> (/home/evadeflow/projects/poky-git/meta-systemd/recipes-kernel/kmod/kmod_7.bb,
>> do_fetch) failed with exit code '1'
>> Waiting for 1 running tasks to finish:
>> 0: libusb1-1.0.8-r4 do_compile (pid 29232)
>> NOTE: package libusb1-1.0.8-r4: task do_compile: Succeeded
>> NOTE: Tasks Summary: Attempted 697 tasks of which 105 didn't need to
>> be rerun and 1 failed.
>>
>> Summary: 1 task failed:
>>
>> /home/evadeflow/projects/poky-git/meta-systemd/recipes-kernel/kmod/kmod_7.bb,
>> do_fetch
>> Summary: There was 1 ERROR message shown, returning a non-zero exit code.
>> bitbake discovery-image  5338.15s user 995.52s system 187% cpu 56:12.92
>> total
>>
>> [NOTE: I'm on poky denzil@65ffa73, meta-ivi denzil@e068388, and
>> meta-systemd denzil@6a358e9. Also, that typo in the output
>> isn't mine, i.e., 'rquested' should be 'requested'.]
>>
>> Can anyone explain what's going on here? If I look in the poky-mirror
>> folder for kmod-related stuff, I see:
>>
>> % ls /home/evadeflow/projects/poky-mirror/*kmod*
>>
>> /home/evadeflow/projects/poky-mirror/git2_git.kernel.org.pub.scm.utils.kernel.kmod.kmod.git.tar.gz
>>
>> /home/evadeflow/projects/poky-mirror/git2_git.profusion.mobi.kmod.git.tar.gz
>>
>> I *think* this is what needs to be downloaded for this recipe(?) Why is
>> `git ls-remote` being run at all? I'm not sure whether this is the fault
>> of poky/oe-core, or of the meta-systemd layer. I'd just really wish it
>> worked. `:-}  Any advice?
>
>
> Where did you get that meta-systemd layer?  I can't find your
> recipe nor that revision (denzil@6a358e9) in the published version
> which is at git://git.openembedded.org/meta-openembedded according
> to http://www.openembedded.org/wiki/LayerIndex
>
> --
> 
> Gary Thomas |  Consulting for the
> MLB Associates  |Embedded world
> 
> ___
> 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] maximum recursion depth exceeded errors with gnutls_2.12.17.bb

[Saxena, Rahul]

Hi,



I have suddenly started getting maximum recursion depth exceeded python errors 
with gnutls_2.12.17.bb

 recipe on Denzil branch.



I am copying snippets of the message log below (some of the stuff that repeats 
has been removed)



Any suggestions as what could be the problem ?



Thanks

Rahul



Pseudo is not present but is required, building this first before the main build
WARNING: Host distribution "Ubuntu 11.04" has not been validated with this 
version of the build system; you may possibly experience unexpected failures. 
It is recommended that you use a tested distribution.
Parsing recipes...done.
Parsing of 848 .bb files complete (0 cached, 848 parsed). 1125 targets, 25 
skipped, 0 masked, 0 errors.

OE Build Configuration:
BB_VERSION= "1.15.2"
TARGET_ARCH   = "i586"
TARGET_OS = "linux"
MACHINE   = "cedartrail"
DISTRO= "poky"
DISTRO_VERSION= "1.2.1"
TUNE_FEATURES = "m32 core2"
TARGET_FPU= ""
meta
meta-yocto= "denzil19aug:65ffa7395055f7e012cb973f63f92380828eed0d"
meta-intel
meta-cedartrail   = "denzil5:eb89634175a1993df879e00325c029d37bea0f1d"

.
.
.
.

lib/libxfont_1.4.5.bb, do_fetch)
NOTE: package perl-5.14.2-r6: task do_patch: Succeeded
NOTE: package liboil-0.3.17-r5: task do_populate_lic: Started
ERROR: Error executing a python function in 
/home/rsaxena/YoctoWork3x/meta/recipes-support/gnutls/gnutls_2.12.17.bb:
RuntimeError: maximum recursion depth exceeded

ERROR: The stack trace of python calls that resulted in this exception/failure 
was:
ERROR:   File "base_do_fetch", line 18, in 
ERROR:
ERROR:   File "base_do_fetch", line 13, in base_do_fetch
ERROR:
ERROR:   File "/home/rsaxena/YoctoWork3x/bitbake/lib/bb/fetch2/__init__.py", 
line 1029, in download
ERROR: localpath = try_mirrors (self.d, ud, mirrors)
ERROR:
ERROR:   File "/home/rsaxena/YoctoWork3x/bitbake/lib/bb/fetch2/__init__.py", 
line 547, in try_mirrors
ERROR: uris, uds = build_mirroruris(origud, mirrors, ld)
ERROR:
ERROR:   File "/home/rsaxena/YoctoWork3x/bitbake/lib/bb/fetch2/__init__.py", 
line 481, in build_mirroruris
ERROR: adduri(None, origud, uris, uds)
ERROR:
ERROR:   File "/home/rsaxena/YoctoWork3x/bitbake/lib/bb/fetch2/__init__.py", 
line 479, in adduri
ERROR: adduri(newuri, newud, uris, uds)
NOTE: Running task 1165 of 5212 (ID: 3334, 
/home/rsaxena/YoctoWork3x/meta/recipes-graphics/xorg-proto/xcmiscproto_1.2.1.bb,
 do_fetch)
ERROR:
ERROR:   File "/home/rsaxena/YoctoWork3x/bitbake/lib/bb/fetch2/__init__.py", 
line 479, in adduri
ERROR: adduri(newuri, newud, uris, uds)
ERROR:
ERROR:   File "/home/rsaxena/YoctoWork3x/bitbake/lib/bb/fetch2/__init__.py", 
line 479, in adduri
ERROR: adduri(newuri, newud, uris, uds)
ERROR:
ERROR:   File "/home/rsaxena/YoctoWork3x/bitbake/lib/bb/fetch2/__init__.py", 
line 479, in adduri
ERROR: adduri(newuri, newud, uris, uds)
ERROR:
ERROR:   File "/home/rsaxena/YoctoWork3x/bitbake/lib/bb/fetch2/__init__.py", 
line 479, in adduri
ERROR: adduri(newuri, newud, uris, uds)
ERROR:
ERROR:   File "/home/rsaxena/YoctoWork3x/bitbake/lib/bb/fetch2/__init__.py", 
line 479, in adduri
ERROR: adduri(newuri, newud, uris, uds)
ERROR:
ERROR:   File "/home/rsaxena/YoctoWork3x/bitbake/lib/bb/fetch2/__init__.py", 
line 479, in adduri
ERROR: adduri(newuri, newud, uris, uds)
ERROR:
.

.

.

.

.

"/home/rsaxena/YoctoWork3x/bitbake/lib/bb/fetch2/__init__.py", line 479, in 
adduri
ERROR: adduri(newuri, newud, uris, uds)
ERROR:
ERROR:   File "/home/rsaxena/YoctoWork3x/bitbake/lib/bb/fetch2/__init__.py", 
line 462, in adduri
ERROR: newuri = uri_replace(ud, find, replace, ld)
ERROR:
ERROR:   File "/home/rsaxena/YoctoWork3x/bitbake/lib/bb/fetch2/__init__.py", 
line 182, in uri_replace
ERROR: logger.debug(2, "For url %s comparing %s to %s" % (uri_decoded, 
uri_find_decoded, uri_replace_decoded))
ERROR:
ERROR:   File "/home/rsaxena/YoctoWork3x/bitbake/lib/bb/__init__.py", line 58, 
in bbdebug
ERROR: return self.log(logging.DEBUG - level + 1, msg, *args, **kwargs)
ERROR:
ERROR:   File "/usr/lib/python2.7/logging/__init__.py", line 1195, in log
ERROR: self._log(level, msg, args, **kwargs)
ERROR:
ERROR:   File "/usr/lib/python2.7/logging/__init__.py", line 1250, in _log
ERROR: self.handle(record)
ERROR:
ERROR:   File "/usr/lib/python2.7/logging/__init__.py", line 1260, in handle
ERROR: self.callHandlers(record)
ERROR:
ERROR:   File "/usr/lib/python2.7/logging/__init__.py", line 1300, in 
callHandlers
ERROR: hdlr.handle(record)
ERROR:
ERROR:   File "/usr/lib/python2.7/logging/__init__.py", line 744, in handle
ERROR: self.emit(record)
ERROR:
ERROR:   File "/home/rsaxena/YoctoWork3x/bitbake/lib/bb/event.py", line 502, in 
emit
ERROR: fire(record, None)
ERROR:
ERROR:   File "/home/rsaxena/YoctoWork3x/bitbake/lib/bb/event.py", line 143, in 
fire
ERROR: worker_fire(event, d)
ERROR:
ERROR:   File "/home/rsaxena/YoctoWork3x/bitbake/lib/bb/event.py", line 148, in 
worker_fire
ERROR: Ru

Re: [yocto] BB_NO_NETWORK and own-mirrors not working with meta-systemd

[Gary Thomas]

On 2012-09-19 10:34, Evade Flow wrote:

Trying to build the meta-ivi discovery-image behind a firewall is
proving to be quite a challenge. I tried modifying my conf/local.conf
file as follows:

CONNECTIVITY_CHECK_URIS=""
BB_GENERATE_MIRROR_TARBALLS = "1"
SOURCE_MIRROR_URL ?= "file:///home/evadeflow/projects/poky-mirror/"
INHERIT += "own-mirrors"

and then ran:

% bitbake discovery-image

in a VM on my home laptop over the weekend. (I'm trying to build using
the meta-ivi layer, per the instructions in its README.) After grinding
and churning for some 60+ hours, it finally succeeded, leaving 11 GB of
'stuff' in my poky-mirror folder.

Then, I copied the poky-mirror folder to a firewalled machine at work
and added:

BB_NO_NETWORK="1"

to local.conf.  When I tried to bitbake discovery-image on this machine,
I got the following error:


NOTE: Running task 697 of 3568 (ID: 1374,
/home/evadeflow/projects/poky-git/meta-systemd/recipes-kernel/kmod/kmod_7.bb,
do_fetch)
NOTE: package kmod-7-r0: task do_fetch: Started
ERROR: Function failed: Network access disabled through BB_NO_NETWORK
but access rquested with command git ls-remote
git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git v7 (for url
None)
ERROR: Logfile of failure stored in:
/home/evadeflow/projects/poky-git/build/tmp-eglibc-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/kmod-7-r0/temp/log.do_fetch.29423
Log data follows:
| ERROR: Function failed: Network access disabled through
BB_NO_NETWORK but access rquested with command git ls-remote
git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git v7 (for url
None)
NOTE: package kmod-7-r0: task do_fetch: Failed
ERROR: Task 1374
(/home/evadeflow/projects/poky-git/meta-systemd/recipes-kernel/kmod/kmod_7.bb,
do_fetch) failed with exit code '1'
Waiting for 1 running tasks to finish:
0: libusb1-1.0.8-r4 do_compile (pid 29232)
NOTE: package libusb1-1.0.8-r4: task do_compile: Succeeded
NOTE: Tasks Summary: Attempted 697 tasks of which 105 didn't need to
be rerun and 1 failed.

Summary: 1 task failed:
   /home/evadeflow/projects/poky-git/meta-systemd/recipes-kernel/kmod/kmod_7.bb,
do_fetch
Summary: There was 1 ERROR message shown, returning a non-zero exit code.
bitbake discovery-image  5338.15s user 995.52s system 187% cpu 56:12.92 total

[NOTE: I'm on poky denzil@65ffa73, meta-ivi denzil@e068388, and
meta-systemd denzil@6a358e9. Also, that typo in the output
isn't mine, i.e., 'rquested' should be 'requested'.]

Can anyone explain what's going on here? If I look in the poky-mirror
folder for kmod-related stuff, I see:

% ls /home/evadeflow/projects/poky-mirror/*kmod*
/home/evadeflow/projects/poky-mirror/git2_git.kernel.org.pub.scm.utils.kernel.kmod.kmod.git.tar.gz
/home/evadeflow/projects/poky-mirror/git2_git.profusion.mobi.kmod.git.tar.gz

I *think* this is what needs to be downloaded for this recipe(?) Why is
`git ls-remote` being run at all? I'm not sure whether this is the fault
of poky/oe-core, or of the meta-systemd layer. I'd just really wish it
worked. `:-}  Any advice?


Where did you get that meta-systemd layer?  I can't find your
recipe nor that revision (denzil@6a358e9) in the published version
which is at git://git.openembedded.org/meta-openembedded according
to http://www.openembedded.org/wiki/LayerIndex

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

[yocto] BB_NO_NETWORK and own-mirrors not working with meta-systemd

[Evade Flow]

Trying to build the meta-ivi discovery-image behind a firewall is
proving to be quite a challenge. I tried modifying my conf/local.conf
file as follows:

CONNECTIVITY_CHECK_URIS=""
BB_GENERATE_MIRROR_TARBALLS = "1"
SOURCE_MIRROR_URL ?= "file:///home/evadeflow/projects/poky-mirror/"
INHERIT += "own-mirrors"

and then ran:

% bitbake discovery-image

in a VM on my home laptop over the weekend. (I'm trying to build using
the meta-ivi layer, per the instructions in its README.) After grinding
and churning for some 60+ hours, it finally succeeded, leaving 11 GB of
'stuff' in my poky-mirror folder.

Then, I copied the poky-mirror folder to a firewalled machine at work
and added:

BB_NO_NETWORK="1"

to local.conf.  When I tried to bitbake discovery-image on this machine,
I got the following error:


NOTE: Running task 697 of 3568 (ID: 1374,
/home/evadeflow/projects/poky-git/meta-systemd/recipes-kernel/kmod/kmod_7.bb,
do_fetch)
NOTE: package kmod-7-r0: task do_fetch: Started
ERROR: Function failed: Network access disabled through BB_NO_NETWORK
but access rquested with command git ls-remote
git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git v7 (for url
None)
ERROR: Logfile of failure stored in:
/home/evadeflow/projects/poky-git/build/tmp-eglibc-eglibc/work/armv7a-vfp-neon-oe-linux-gnueabi/kmod-7-r0/temp/log.do_fetch.29423
Log data follows:
| ERROR: Function failed: Network access disabled through
BB_NO_NETWORK but access rquested with command git ls-remote
git://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git v7 (for url
None)
NOTE: package kmod-7-r0: task do_fetch: Failed
ERROR: Task 1374
(/home/evadeflow/projects/poky-git/meta-systemd/recipes-kernel/kmod/kmod_7.bb,
do_fetch) failed with exit code '1'
Waiting for 1 running tasks to finish:
0: libusb1-1.0.8-r4 do_compile (pid 29232)
NOTE: package libusb1-1.0.8-r4: task do_compile: Succeeded
NOTE: Tasks Summary: Attempted 697 tasks of which 105 didn't need to
be rerun and 1 failed.

Summary: 1 task failed:
  /home/evadeflow/projects/poky-git/meta-systemd/recipes-kernel/kmod/kmod_7.bb,
do_fetch
Summary: There was 1 ERROR message shown, returning a non-zero exit code.
bitbake discovery-image  5338.15s user 995.52s system 187% cpu 56:12.92 total

[NOTE: I'm on poky denzil@65ffa73, meta-ivi denzil@e068388, and
meta-systemd denzil@6a358e9. Also, that typo in the output
isn't mine, i.e., 'rquested' should be 'requested'.]

Can anyone explain what's going on here? If I look in the poky-mirror
folder for kmod-related stuff, I see:

% ls /home/evadeflow/projects/poky-mirror/*kmod*
/home/evadeflow/projects/poky-mirror/git2_git.kernel.org.pub.scm.utils.kernel.kmod.kmod.git.tar.gz
/home/evadeflow/projects/poky-mirror/git2_git.profusion.mobi.kmod.git.tar.gz

I *think* this is what needs to be downloaded for this recipe(?) Why is
`git ls-remote` being run at all? I'm not sure whether this is the fault
of poky/oe-core, or of the meta-systemd layer. I'd just really wish it
worked. `:-}  Any advice?
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] All incompassing documentation

[Rifenbark, Scott M]

These are all great points and we can adjust the manual set to use proper forms 
of the term.  We do have a "Terms" section and can add a clear definition of 
the term there.  Then, throughout the docs as the term is used it can be linked 
back to the definition.  Once we settle on the primary use I can go forward 
with that.  Regarding an index - Indices are great and the set should have one. 
This needs to be a "to do" item for the set.  I have written many indices and a 
good index takes a lot of effort.  Case in point - there are documentation 
specialists that limit their work exclusively to creating indices.

Good feedback!

Thanks,
Scott

-Original Message-
From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On 
Behalf Of Brian Lloyd
Sent: Wednesday, September 19, 2012 8:51 AM
To: yocto@yoctoproject.org
Subject: Re: [yocto] All incompassing documentation

I would like to point out Yocto's own documentation uses it for two
separate items, which is the point I was making.  Neither of which are
source tarballs


It is a product produced by Yocto.
It is the items to be installed from the host system.


That may be right, but if so, we can't say that for Yocto it only means
the first, as we use it for the second as well.  If we want it to only
be the first, then we must use a different term for the second, such as
host applications, and the user should be notified of the unusual word
choice and why early in the documentation.  I believe there are several
locations where terms are explained already in the documentation, even
if we later use the term in a way other than that identified as it's
meaning (3.4. Yocto Project Terms comes to mind).  Discussing Package
meaning there, perhaps we should identify the term that will be used for
host package, or how we will identify when the term is used with a
different meaning than the one just given.


Or if we concede that packages is what the user expects to see when
discussing what to install, we need to disambiguate in some way to
differentiate the two uses.  Indexes are good at this.  The biggest
advantage to an index over straight search is that author's can use
context to differentiate the different uses when a word has them.
Another option could be prepending to both the context at each location
used, so we use Yocto package and host package or where we always prefix
context to one of the two for every use.  However, doing only one with a
context makes for more manual searches, where we are making a document
with the goal of making searching for information more effective.


On Tue, 2012-09-18 at 21:02 -0700, Jeff Osier-Mixon wrote:
> 
> 
> On Tue, Sep 18, 2012 at 12:04 PM, Trevor Woerner  wrote:
> > On Tue, Sep 18, 2012 at 2:23 PM, Brian Lloyd  wrote:
> >> Most of my hits for such an item
> >> discuss the packages I will need to install in my host distribution so I
> >> can use the yocto project (not surprised, the danger of a term as vague
> >> as packages).
> >
> > In bitbake/yocto/OE/etc. the term "packages" is not vague and has a
> > very specific meaning: bitbake processes recipes to produce one or
> > more packages. Some of these packages are then assembled into an
> 
> This is quite true - but the term itself is overloaded. I have often
> heard "package" referred to also as the collection of source code one
> would use to create a given piece of software, e.g. "the busybox
> package". This is no doubt the result of downloading numerous
> "packages" from the net in binary form rather than source. It doesn't
> help that there are "source packages" in the RPM world
> (http://www.rpm.org/max-rpm/s1-rpm-miscellania-srpms.html) and in the
> Debian world 
> (http://www.debian.org/doc/manuals/apt-howto/ch-sourcehandling.en.html),
> so the confusion is natural.
> 
> In OE-based systems like the Yocto Project, the term refers to the
> results of a build rather than the ingredients. I agree with you that
> we should continue to push the correct usage to unload the term.
> Anyone have a good term for "source packages"?
> 


___
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] [PATCH 0/1] [linux-yocto-3.0] boot-live.cfg: enable BLK_DEV_INITRD in kernel

[Mihai Lindner]

On 2012-09-19 18:43, Bruce Ashfield wrote:
> On 12-09-18 10:46 AM, Mihai Lindner wrote:
>> On 2012-09-18 17:23, Tom Zanussi wrote:
>>> On Tue, 2012-09-18 at 16:58 +0300, Mihai Lindner wrote:
 On 2012-09-18 16:49, Tom Zanussi wrote:
> On Tue, 2012-09-18 at 08:21 -0400, Bruce Ashfield wrote:
>> On 12-09-18 01:59 AM, Mihai Lindner wrote:
>>> Please pull into linux-yocto-3.0, meta.
>>>
>>
>> Adding linux-yocto, Darren and Tom.
>>
>> This looks fine to me, and we should consider it for all the 
>> repositories,
>> not just 3.0.
>>
>> Tom/Darren. Any side effects you can think of for this change ?
>>
>
> No, but shouldn't it already be there, inherited from base.cfg?

 For cedartrail, at least, standard.cfg is used.

>>>
>>> And standard inherits from base, so it should be turned on.  Somehow
>>> it's getting turned off in cedartrail...
>>
>> Yes, it the final .config file is turned off. Solved it by setting it in 
>> boot-live.
>> --Mihai
> 
> To follow up on this, is someone taking a closer look at this config
> to see if we can get a root cause for that option being disabled for
> this board ?
> 
> I won't be able to poke at it myself for another day or so.
> 
> Bruce
> 
I'm still digging on this, trying to figure out what cfg files are included / 
omitted by `configme` and why.
base.cfg is not included, nor stanadrd.cfg it seems.
The list of included cfg files is way to short.

--Mihai
>>
>>>
>>> Tom
>>>
 --Mihai

>
> Tom
>
>> Bruce
>>
>>> Added BLK_DEV_INITRD in boot-live.cfg for linux-yocto-3.0, meta branch.
>>> Cedartrail (at least) cannot boot live from ISO image due to
>>> BLK_DEV_INITRD missing:
>>> "VFS: Cannot open root device "ram0" or unkown-block(0,0)"
>>> Should fix #3050
>>>
>>> [YOCTO #3050]
>>>
>>> Signed-off-by: Mihai Lindner
>>> ---
>>>
>>> The following changes since commit 
>>> bf5ee4945ee6d748e6abe16356f2357f76b5e2f0:
>>>
>>> meta: rename virto.scc to virtio.scc (2012-08-18 22:09:35 -0400)
>>>
>>> are available in the git repository at:
>>> git://git.yoctoproject.org/poky-contrib mihai/linux-yocto-3.0/meta
>>>
>>> Mihai Lindner (1):
>>> boot-live.cfg: enable BLK_DEV_INITRD in kernel
>>>
>>>meta/cfg/kernel-cache/cfg/boot-live.cfg |2 ++
>>>1 files changed, 2 insertions(+), 0 deletions(-)
>>>
>>> Mihai Lindner (1):
>>> boot-live.cfg: enable BLK_DEV_INITRD in kernel
>>>
>>>meta/cfg/kernel-cache/cfg/boot-live.cfg |2 ++
>>>1 files changed, 2 insertions(+), 0 deletions(-)
>>>
>>
>
>
>
>


>>>
>>>
>>>
>>>
>>
>>
> 
> 
> 


-- 
Mihai Lindner
Yocto Project
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] All incompassing documentation

[Brian Lloyd]

I would like to point out Yocto's own documentation uses it for two
separate items, which is the point I was making.  Neither of which are
source tarballs


It is a product produced by Yocto.
It is the items to be installed from the host system.


That may be right, but if so, we can't say that for Yocto it only means
the first, as we use it for the second as well.  If we want it to only
be the first, then we must use a different term for the second, such as
host applications, and the user should be notified of the unusual word
choice and why early in the documentation.  I believe there are several
locations where terms are explained already in the documentation, even
if we later use the term in a way other than that identified as it's
meaning (3.4. Yocto Project Terms comes to mind).  Discussing Package
meaning there, perhaps we should identify the term that will be used for
host package, or how we will identify when the term is used with a
different meaning than the one just given.


Or if we concede that packages is what the user expects to see when
discussing what to install, we need to disambiguate in some way to
differentiate the two uses.  Indexes are good at this.  The biggest
advantage to an index over straight search is that author's can use
context to differentiate the different uses when a word has them.
Another option could be prepending to both the context at each location
used, so we use Yocto package and host package or where we always prefix
context to one of the two for every use.  However, doing only one with a
context makes for more manual searches, where we are making a document
with the goal of making searching for information more effective.


On Tue, 2012-09-18 at 21:02 -0700, Jeff Osier-Mixon wrote:
> 
> 
> On Tue, Sep 18, 2012 at 12:04 PM, Trevor Woerner  wrote:
> > On Tue, Sep 18, 2012 at 2:23 PM, Brian Lloyd  wrote:
> >> Most of my hits for such an item
> >> discuss the packages I will need to install in my host distribution so I
> >> can use the yocto project (not surprised, the danger of a term as vague
> >> as packages).
> >
> > In bitbake/yocto/OE/etc. the term "packages" is not vague and has a
> > very specific meaning: bitbake processes recipes to produce one or
> > more packages. Some of these packages are then assembled into an
> 
> This is quite true - but the term itself is overloaded. I have often
> heard "package" referred to also as the collection of source code one
> would use to create a given piece of software, e.g. "the busybox
> package". This is no doubt the result of downloading numerous
> "packages" from the net in binary form rather than source. It doesn't
> help that there are "source packages" in the RPM world
> (http://www.rpm.org/max-rpm/s1-rpm-miscellania-srpms.html) and in the
> Debian world 
> (http://www.debian.org/doc/manuals/apt-howto/ch-sourcehandling.en.html),
> so the confusion is natural.
> 
> In OE-based systems like the Yocto Project, the term refers to the
> results of a build rather than the ingredients. I agree with you that
> we should continue to push the correct usage to unload the term.
> Anyone have a good term for "source packages"?
> 


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

Re: [yocto] [PATCH 0/1] [linux-yocto-3.0] boot-live.cfg: enable BLK_DEV_INITRD in kernel

[Bruce Ashfield]

On 12-09-18 10:46 AM, Mihai Lindner wrote:

On 2012-09-18 17:23, Tom Zanussi wrote:

On Tue, 2012-09-18 at 16:58 +0300, Mihai Lindner wrote:

On 2012-09-18 16:49, Tom Zanussi wrote:

On Tue, 2012-09-18 at 08:21 -0400, Bruce Ashfield wrote:

On 12-09-18 01:59 AM, Mihai Lindner wrote:

Please pull into linux-yocto-3.0, meta.



Adding linux-yocto, Darren and Tom.

This looks fine to me, and we should consider it for all the repositories,
not just 3.0.

Tom/Darren. Any side effects you can think of for this change ?



No, but shouldn't it already be there, inherited from base.cfg?


For cedartrail, at least, standard.cfg is used.



And standard inherits from base, so it should be turned on.  Somehow
it's getting turned off in cedartrail...


Yes, it the final .config file is turned off. Solved it by setting it in 
boot-live.
--Mihai


To follow up on this, is someone taking a closer look at this config
to see if we can get a root cause for that option being disabled for
this board ?

I won't be able to poke at it myself for another day or so.

Bruce





Tom


--Mihai



Tom


Bruce


Added BLK_DEV_INITRD in boot-live.cfg for linux-yocto-3.0, meta branch.
Cedartrail (at least) cannot boot live from ISO image due to
BLK_DEV_INITRD missing:
"VFS: Cannot open root device "ram0" or unkown-block(0,0)"
Should fix #3050

[YOCTO #3050]

Signed-off-by: Mihai Lindner
---

The following changes since commit bf5ee4945ee6d748e6abe16356f2357f76b5e2f0:

meta: rename virto.scc to virtio.scc (2012-08-18 22:09:35 -0400)

are available in the git repository at:
git://git.yoctoproject.org/poky-contrib mihai/linux-yocto-3.0/meta

Mihai Lindner (1):
boot-live.cfg: enable BLK_DEV_INITRD in kernel

   meta/cfg/kernel-cache/cfg/boot-live.cfg |2 ++
   1 files changed, 2 insertions(+), 0 deletions(-)

Mihai Lindner (1):
boot-live.cfg: enable BLK_DEV_INITRD in kernel

   meta/cfg/kernel-cache/cfg/boot-live.cfg |2 ++
   1 files changed, 2 insertions(+), 0 deletions(-)





















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

Re: [yocto] All incompassing documentation

[Trevor Woerner]

On Wed, Sep 19, 2012 at 12:02 AM, Jeff Osier-Mixon  wrote:
> Anyone have a good term for "source packages"?

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

Re: [yocto] Lighttpd recipe is falling ERROR: Error executing a python function

[Tarek El-Sherbiny]

I have attached the bb and bbappend files.

Thanks

On Wed, Sep 19, 2012 at 1:14 PM, Gary Thomas  wrote:

> On 2012-09-19 06:08, Tarek El-Sherbiny wrote:
>
>> I would like to build lighttpd for my imx6 project.
>>
>> Her is the error I'm getting after I type bitbake lighttpd
>>
>> NOTE: Resolving any missing task queue dependencies
>> NOTE: Preparing runqueue
>> NOTE: Executing SetScene Tasks
>> NOTE: Executing RunQueue Tasks
>> NOTE: Running task 644 of 885 (ID: 9, /home/telsherbiny/work/fsl/**
>> sources/poky/meta/recipes-**extended/lighttpd/lighttpd_1.**4.30.bb<
>> http://lighttpd_1.4.30.bb>, do_package)
>> NOTE: Running task 882 of 885 (ID: 3, /home/telsherbiny/work/fsl/**
>> sources/poky/meta/recipes-**extended/lighttpd/lighttpd_1.**4.30.bb<
>> http://lighttpd_1.4.30.bb>, do_populate_sysroot)
>>
>> NOTE: package lighttpd-1.4.30-r12: task do_package: Started
>> NOTE: package lighttpd-1.4.30-r12: task do_populate_sysroot: Started
>> NOTE: package lighttpd-1.4.30-r12: task do_populate_sysroot: Succeeded
>> ERROR: Error executing a python function in /home/telsherbiny/work/fsl/**
>> sources/poky/meta/recipes-**extended/lighttpd/lighttpd_1.**4.30.bb<
>> http://lighttpd_1.4.30.bb>:
>>
>> AttributeError: 'NoneType' object has no attribute 'split'
>>
>> ERROR: The stack trace of python calls that resulted in this
>> exception/failure was:
>> ERROR:   File "populate_packages", line 323, in 
>> ERROR:
>> ERROR:   File "populate_packages", line 115, in populate_packages
>> ERROR:
>> ERROR:   File "populate_packages", line 72, in systemd_check_services
>> ERROR:
>> ERROR: The code that was being executed was:
>> ERROR:  0319:bb.note("%s contains dangling symlink to %s" % (pkg, l))
>> ERROR:  0320:d.setVar('RDEPENDS_' + pkg, bb.utils.join_deps(rdepends,
>> commasep=False))
>> ERROR:  0321:
>> ERROR:  0322:
>> ERROR:  *** 0323:populate_packages(d)
>> ERROR:  0324:
>> ERROR: (file: 'populate_packages', lineno: 323, function: )
>> ERROR:  0111:for pkg_systemd in d.getVar('SYSTEMD_PACKAGES',
>> 1).split():
>> ERROR:  0112:if d.getVar('SYSTEMD_SERVICE' + "_" + pkg_systemd, 1)
>> and d.getVar('SYSTEMD_SERVICE' + "_" + pkg_systemd, 1).strip():
>> ERROR:  0113:systemd_generate_package_**scripts(pkg_systemd)
>> ERROR:  0114:systemd_add_rdepends(pkg_**systemd)
>> ERROR:  *** 0115:systemd_check_services()
>> ERROR:  0116:lighttpd_libdir = d.expand('/usr/lib')
>> ERROR:  0117:do_split_packages(d, lighttpd_libdir,
>> '^mod_(.*)\.so$', 'lighttpd-module-%s', 'Lighttpd module for %s',
>> extra_depends='')
>> ERROR:  0118:def update_rcd_package(pkg):
>> ERROR:  0119:bb.debug(1, 'adding update-rc.d calls to postinst/postrm
>> for %s' % pkg)
>> ERROR: (file: 'populate_packages', lineno: 115, function:
>> populate_packages)
>> ERROR: Function failed: populate_packages
>> ERROR: Logfile of failure stored in: /home/telsherbiny/work/fsl/**
>> build/tmp/work/armv7a-vfp-**neon-poky-linux-gnueabi/**
>> lighttpd-1.4.30-r12/temp/log.**do_package.32369
>> NOTE: package lighttpd-1.4.30-r12: task do_package: Failed
>> ERROR: Task 9 (/home/telsherbiny/work/fsl/**sources/poky/meta/recipes-**
>> extended/lighttpd/lighttpd_1.**4.30.bb  <
>> http://lighttpd_1.4.30.bb>, do_package) failed with exit code '1'
>>
>> NOTE: Tasks Summary: Attempted 882 tasks of which 880 didn't need to be
>> rerun and 1 failed.
>>
>> Summary: 1 task failed:
>>/home/telsherbiny/work/fsl/**sources/poky/meta/recipes-**
>> extended/lighttpd/lighttpd_1.**4.30.bb  <
>> http://lighttpd_1.4.30.bb>, do_package
>>
>> Summary: There were 27 ERROR messages shown, returning a non-zero exit
>> code.
>>
>>
>> Can anyone help to solve this problem?
>>
>
> It would be necessary to see your recipe: lighttpd_1.4.30.bb
> (and any associated files)
>
> --
> --**--
> Gary Thomas |  Consulting for the
> MLB Associates  |Embedded world
> --**--
> __**_
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.**org/listinfo/yocto
>


lighttpd_1.4.30.bb
Description: Binary data


lighttpd_1.4.30.bbappend
Description: Binary data
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Lighttpd recipe is falling ERROR: Error executing a python function

[Gary Thomas]

On 2012-09-19 06:08, Tarek El-Sherbiny wrote:

I would like to build lighttpd for my imx6 project.

Her is the error I'm getting after I type bitbake lighttpd

NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Running task 644 of 885 (ID: 9, 
/home/telsherbiny/work/fsl/sources/poky/meta/recipes-extended/lighttpd/lighttpd_1.4.30.bb
 , do_package)
NOTE: Running task 882 of 885 (ID: 3, 
/home/telsherbiny/work/fsl/sources/poky/meta/recipes-extended/lighttpd/lighttpd_1.4.30.bb
 , do_populate_sysroot)
NOTE: package lighttpd-1.4.30-r12: task do_package: Started
NOTE: package lighttpd-1.4.30-r12: task do_populate_sysroot: Started
NOTE: package lighttpd-1.4.30-r12: task do_populate_sysroot: Succeeded
ERROR: Error executing a python function in 
/home/telsherbiny/work/fsl/sources/poky/meta/recipes-extended/lighttpd/lighttpd_1.4.30.bb
 :
AttributeError: 'NoneType' object has no attribute 'split'

ERROR: The stack trace of python calls that resulted in this exception/failure 
was:
ERROR:   File "populate_packages", line 323, in 
ERROR:
ERROR:   File "populate_packages", line 115, in populate_packages
ERROR:
ERROR:   File "populate_packages", line 72, in systemd_check_services
ERROR:
ERROR: The code that was being executed was:
ERROR:  0319:bb.note("%s contains dangling symlink to %s" % (pkg, l))
ERROR:  0320:d.setVar('RDEPENDS_' + pkg, bb.utils.join_deps(rdepends, 
commasep=False))
ERROR:  0321:
ERROR:  0322:
ERROR:  *** 0323:populate_packages(d)
ERROR:  0324:
ERROR: (file: 'populate_packages', lineno: 323, function: )
ERROR:  0111:for pkg_systemd in d.getVar('SYSTEMD_PACKAGES', 1).split():
ERROR:  0112:if d.getVar('SYSTEMD_SERVICE' + "_" + pkg_systemd, 1) and 
d.getVar('SYSTEMD_SERVICE' + "_" + pkg_systemd, 1).strip():
ERROR:  0113:systemd_generate_package_scripts(pkg_systemd)
ERROR:  0114:systemd_add_rdepends(pkg_systemd)
ERROR:  *** 0115:systemd_check_services()
ERROR:  0116:lighttpd_libdir = d.expand('/usr/lib')
ERROR:  0117:do_split_packages(d, lighttpd_libdir, 
'^mod_(.*)\.so$', 'lighttpd-module-%s', 'Lighttpd module for %s', 
extra_depends='')
ERROR:  0118:def update_rcd_package(pkg):
ERROR:  0119:bb.debug(1, 'adding update-rc.d calls to postinst/postrm for 
%s' % pkg)
ERROR: (file: 'populate_packages', lineno: 115, function: populate_packages)
ERROR: Function failed: populate_packages
ERROR: Logfile of failure stored in: 
/home/telsherbiny/work/fsl/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/lighttpd-1.4.30-r12/temp/log.do_package.32369
NOTE: package lighttpd-1.4.30-r12: task do_package: Failed
ERROR: Task 9 
(/home/telsherbiny/work/fsl/sources/poky/meta/recipes-extended/lighttpd/lighttpd_1.4.30.bb
 , do_package) failed with exit code '1'
NOTE: Tasks Summary: Attempted 882 tasks of which 880 didn't need to be rerun 
and 1 failed.

Summary: 1 task failed:
   
/home/telsherbiny/work/fsl/sources/poky/meta/recipes-extended/lighttpd/lighttpd_1.4.30.bb
 , do_package
Summary: There were 27 ERROR messages shown, returning a non-zero exit code.


Can anyone help to solve this problem?


It would be necessary to see your recipe: lighttpd_1.4.30.bb
(and any associated files)

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

[yocto] Lighttpd recipe is falling ERROR: Error executing a python function

[Tarek El-Sherbiny]

I would like to build lighttpd for my imx6 project.

Her is the error I'm getting after I type bitbake lighttpd

NOTE: Resolving any missing task queue dependencies
NOTE: Preparing runqueue
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
NOTE: Running task 644 of 885 (ID: 9,
/home/telsherbiny/work/fsl/sources/poky/meta/recipes-extended/lighttpd/
lighttpd_1.4.30.bb, do_package)
NOTE: Running task 882 of 885 (ID: 3,
/home/telsherbiny/work/fsl/sources/poky/meta/recipes-extended/lighttpd/
lighttpd_1.4.30.bb, do_populate_sysroot)
NOTE: package lighttpd-1.4.30-r12: task do_package: Started
NOTE: package lighttpd-1.4.30-r12: task do_populate_sysroot: Started
NOTE: package lighttpd-1.4.30-r12: task do_populate_sysroot: Succeeded
ERROR: Error executing a python function in
/home/telsherbiny/work/fsl/sources/poky/meta/recipes-extended/lighttpd/
lighttpd_1.4.30.bb:
AttributeError: 'NoneType' object has no attribute 'split'

ERROR: The stack trace of python calls that resulted in this
exception/failure was:
ERROR:   File "populate_packages", line 323, in 
ERROR:
ERROR:   File "populate_packages", line 115, in populate_packages
ERROR:
ERROR:   File "populate_packages", line 72, in systemd_check_services
ERROR:
ERROR: The code that was being executed was:
ERROR:  0319: bb.note("%s contains dangling symlink to %s" % (pkg, l))
ERROR:  0320: d.setVar('RDEPENDS_' + pkg, bb.utils.join_deps(rdepends,
commasep=False))
ERROR:  0321:
ERROR:  0322:
ERROR:  *** 0323:populate_packages(d)
ERROR:  0324:
ERROR: (file: 'populate_packages', lineno: 323, function: )
ERROR:  0111: for pkg_systemd in d.getVar('SYSTEMD_PACKAGES',
1).split():
ERROR:  0112: if d.getVar('SYSTEMD_SERVICE' + "_" + pkg_systemd, 1) and
d.getVar('SYSTEMD_SERVICE' + "_" + pkg_systemd, 1).strip():
ERROR:  0113: systemd_generate_package_scripts(pkg_systemd)
ERROR:  0114: systemd_add_rdepends(pkg_systemd)
ERROR:  *** 0115: systemd_check_services()
ERROR:  0116:lighttpd_libdir = d.expand('/usr/lib')
ERROR:  0117:do_split_packages(d, lighttpd_libdir,
'^mod_(.*)\.so$', 'lighttpd-module-%s', 'Lighttpd module for %s',
extra_depends='')
ERROR:  0118: def update_rcd_package(pkg):
ERROR:  0119: bb.debug(1, 'adding update-rc.d calls to postinst/postrm
for %s' % pkg)
ERROR: (file: 'populate_packages', lineno: 115, function: populate_packages)
ERROR: Function failed: populate_packages
ERROR: Logfile of failure stored in:
/home/telsherbiny/work/fsl/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/lighttpd-1.4.30-r12/temp/log.do_package.32369
NOTE: package lighttpd-1.4.30-r12: task do_package: Failed
ERROR: Task 9
(/home/telsherbiny/work/fsl/sources/poky/meta/recipes-extended/lighttpd/
lighttpd_1.4.30.bb, do_package) failed with exit code '1'
NOTE: Tasks Summary: Attempted 882 tasks of which 880 didn't need to be
rerun and 1 failed.

Summary: 1 task failed:
  /home/telsherbiny/work/fsl/sources/poky/meta/recipes-extended/lighttpd/
lighttpd_1.4.30.bb, do_package
Summary: There were 27 ERROR messages shown, returning a non-zero exit code.


Can anyone help to solve this problem?

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

Re: [yocto] Autotools CFLAGS & LDFLAGS

[Tarek El-Sherbiny]

CFLAGS_append and  LDLAGS_append worked for me

Thanks

On Wed, Sep 19, 2012 at 6:30 AM, Khem Raj  wrote:

> On Mon, Sep 17, 2012 at 6:55 AM, Tarek El-Sherbiny
>  wrote:
> > Hi All,
> >
> > What is the easiest way to add nonstandard directory paths for libraries
> and
> > header files in a recipe that inherit autotools and pkgconfig?
> >
>
> Adding them to CFLAGS and LDFLAGS doesnt work ?
>
> > Regards,
> > Tarek
> >
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> >
>
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto