Re: [yocto] "fatal: A branch named 'meta-orig' already exists."

2015-04-02 Thread Robert P. J. Day 
On Wed, 1 Apr 2015, Bruce Ashfield wrote:

... snip ...

> I completely agree .. better to sort this out sooner rather than
> later, I'm just trying to narrow down on a configuration that allows
> me to see the problem and poke at the smouldering pile. If git is
> doing something different now, it won't be hard to fix, but hands
> on, versus code inspection, is the real trick here.

  for a quick test, i started a new project on my fedora rawhide
system:

* latest checkout of poky
* core-image-minimal
* qemuarm (as opposed to initial qemux86, just to be different)

  the initial fetch worked fine (taking advantage of numerous tarballs
i've collected over the months):

  $ bitbake -c fetchall core-image-minimal

  then:

  $ bitbake linux-yocto

which quickly produces the error at the bottom of this note as
displayed by "bb". i'm baffled ... does the kernel tree have some
new, untracked garbage in it that is causing this?

  the native git is version 2.3.0.

rday

$ bb log linux-yocto validate_branches
DEBUG: Executing shell function do_validate_branches
NOTE: Setting branch meta to 9e70b482d3773abf92c9c5850e134cbca1d5651f
error: The following untracked working tree files would be removed by checkout:
.gitignore
.mailmap
COPYING
CREDITS
Documentation/00-INDEX
Documentation/ABI/README
Documentation/ABI/obsolete/proc-sys-vm-nr_pdflush_threads
Documentation/ABI/obsolete/sysfs-bus-usb
Documentation/ABI/obsolete/sysfs-class-rfkill
Documentation/ABI/obsolete/sysfs-driver-hid-roccat-koneplus
Documentation/ABI/obsolete/sysfs-driver-hid-roccat-kovaplus
Documentation/ABI/obsolete/sysfs-driver-hid-roccat-pyra
Documentation/ABI/removed/devfs
Documentation/ABI/removed/dv1394
Documentation/ABI/removed/ip_queue
Documentation/ABI/removed/net_dma
Documentation/ABI/removed/o2cb
Documentation/ABI/removed/raw1394
Documentation/ABI/removed/video1394
Documentation/ABI/stable/firewire-cdev
Documentation/ABI/stable/o2cb
Documentation/ABI/stable/syscalls
Documentation/ABI/stable/sysfs-acpi-pmprofile
Documentation/ABI/stable/sysfs-bus-firewire
Documentation/ABI/stable/sysfs-bus-usb
Documentation/ABI/stable/sysfs-bus-xen-backend
Documentation/ABI/stable/sysfs-class-backlight
Documentation/ABI/stable/sysfs-class-rfkill
Documentation/ABI/stable/sysfs-class-tpm
Documentation/ABI/stable/sysfs-class-ubi
Documentation/ABI/stable/sysfs-class-udc
Documentation/ABI/stable/sysfs-devices-node
Documentation/ABI/stable/sysfs-devices-system-cpu
Documentation/ABI/stable/sysfs-devices-system-xen_memory
Documentation/ABI/stable/sysfs-driver-ib_srp
Documentation/ABI/stable/sysfs-driver-qla2xxx
Documentation/ABI/stable/sysfs-driver-usb-usbtmc
Documentation/ABI/stable/sysfs-driver-w1_ds28e04
Documentation/ABI/stable/sysfs-firmware-efi-vars
Documentation/ABI/stable/sysfs-firmware-opal-dump
Documentation/ABI/stable/sysfs-firmware-opal-elog
Documentation/ABI/stable/sysfs-module
Documentation/ABI/stable/sysfs-transport-srp
Documentation/ABI/stable/thermal-notification
Documentation/ABI/stable/vdso
Documentation/ABI/testing/configfs-spear-pcie-gadget
Documentation/ABI/testing/configfs-usb-gadget
Documentation/ABI/testing/configfs-usb-gadget-acm
Documentation/ABI/testing/configfs-usb-gadget-ecm
Documentation/ABI/testing/configfs-usb-gadget-eem
Documentation/ABI/testing/configfs-usb-gadget-ffs
Documentation/ABI/testing/configfs-usb-gadget-hid
Documentation/ABI/testing/configfs-usb-gadget-loopback
Documentation/ABI/testing/configfs-usb-gadget-mass-storage
Documentation/ABI/testing/configfs-usb-gadget-midi
Documentation/ABI/testing/configfs-usb-gadget-ncm
Documentation/ABI/testing/configfs-usb-gadget-obex
Documentation/ABI/testing/configfs-usb-gadget-phonet
Documentation/ABI/testing/configfs-usb-gadget-rndis
Documentation/ABI/testing/configfs-usb-gadget-serial
Documentation/ABI/testing/configfs-usb-gadget-sourcesink
Documentation/ABI/testing/configfs-usb-gadget-subset
Documentation/ABI/testing/configfs-usb-gadget-uac1
Documentation/ABI/testing/configfs-usb-gadget-uac2
Documentation/ABI/testing/debugfs-driver-genwqe
Documentation/ABI/testing/debugfs-ec
Documentation/ABI/testing/debugfs-ideapad
Documentation/ABI/testing/debugfs-olpc
Documentation/ABI/testing/debugfs-pfo-nx-crypto
Documentation/ABI/testing/debugfs-pktcdvd
Documentation/ABI/testing/dev-kmsg
Documentation/ABI/testing/evm
Documentation/ABI/testing/ima_policy
Documentation/ABI/testing/procfs-diskstats
Documentatio

[yocto] Building crosswalk for armv7

2015-04-02 Thread Lev Lehn 
I’m having troubles building the crosswalk-project OE meta-layer for an armv7 
target.

I followed the short instructions from here:
https://www.yoctoproject.org/blogs/jefro/2014/crosswalk-now-available-yocto-project

However I’m getting this error in do_compile step from the crosswalk recipe:

| /usr/bin/ld: skipping incompatible 
/usr/lib/gcc/x86_64-linux-gnu/4.7/libstdc++.so when searching for -lstdc++
| /usr/bin/ld: skipping incompatible 
/usr/lib/gcc/x86_64-linux-gnu/4.7/libstdc++.a when searching for -lstdc++

So it seems to use
-wrong linker
-wrong path to libs

Any ideas how I can fix this?

Thanks in advance,

Lev



Kardex Software GmbH
Sitz: Wörth a.R., Deutschland
Amtsgericht Landau HRB 30060
UST-IDNR. DE 812560748
Geschäftsführer: Rolf Mössner, Jürgen Schnatterer
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Building crosswalk for armv7

2015-04-02 Thread Gaurang Shastri 
Hi,

I do not have too much info about this, but I hope you have already some
fixes available from here for meta-crosswalk:

https://github.com/crosswalk-project/meta-crosswalk/commit/362674ee6f838aafdaeae5b8bb035615330d243e

//Gaurang Shastri

On Thu, Apr 2, 2015 at 1:34 PM, Lev Lehn  wrote:

>  I’m having troubles building the crosswalk-project OE meta-layer for an
> armv7 target.
>
>
>
> I followed the short instructions from here:
>
>
> https://www.yoctoproject.org/blogs/jefro/2014/crosswalk-now-available-yocto-project
>
>
>
> However I’m getting this error in do_compile step from the crosswalk
> recipe:
>
>
>
> | /usr/bin/ld: skipping incompatible
> /usr/lib/gcc/x86_64-linux-gnu/4.7/libstdc++.so when searching for -lstdc++
>
> | /usr/bin/ld: skipping incompatible
> /usr/lib/gcc/x86_64-linux-gnu/4.7/libstdc++.a when searching for -lstdc++
>
>
>
> So it seems to use
>
> -wrong linker
>
> -wrong path to libs
>
>
>
> Any ideas how I can fix this?
>
>
>
> Thanks in advance,
>
>
> *Lev*
>
> --
>
> Kardex Software GmbH
> Sitz: Wörth a.R., Deutschland
> Amtsgericht Landau HRB 30060
> UST-IDNR. DE 812560748
> Geschäftsführer: Rolf Mössner, Jürgen Schnatterer
>
> --
> ___
> 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] Kernel Panic: /sbin/init not found

2015-04-02 Thread Yu, Chan KitX 
Hello all,

My Yocto build environment was working perfectly until last week when I got 
kernel panic caused by missing/sbin/init. When I examined the image, I found 
that /sbin/init is indeed absent from the root image. To troubleshoot the 
issue, I tried building a stock Yocto whose target platform is 64-bit machine 
using a  freshly installed Ubuntu 14.04 from another build machine.  Despite 
that, the kernel panic still occurs and that's the main reason I'm writing 
here; that is to see if anyone else has the same issue. I did not make any 
change or any customization to local.conf aside from setting MACHINE to 64 bit 
and adding the following lines which enable multilib:

IMAGE_INSTALL = "lib32-connman"
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "x86"

I would be more than happy to provide necessary diagnostic message shall you 
request so. Let me know if you guys are able to reproduce this issue.

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

Re: [yocto] "fatal: A branch named 'meta-orig' already exists."

2015-04-02 Thread Robert P. J. Day 
On Wed, 1 Apr 2015, Bruce Ashfield wrote:

... again, snip ...

> I completely agree .. better to sort this out sooner rather than
> later, I'm just trying to narrow down on a configuration that allows
> me to see the problem and poke at the smouldering pile. If git is
> doing something different now, it won't be hard to fix, but hands
> on, versus code inspection, is the real trick here.

  ok, now i'm confused about where i'm getting my kernel source from.
with a fresh build for qemux86 and deliberately not using any of my
local mirror content, i did:

  $ bitbake -c fetchall linux-yocto

assuming the fetch would take a while due to, you know, git checkout.

  the first puzzler is that my downloads directory very quickly
contained (among other things):

-rw-rw-r--. 1 rpjday rpjday 81688872 Feb  8 22:20 linux-3.19.tar.xz

should i have expected that? why do i suddenly have what looks like a
stock linux-3.19 tarball when git should be used for this?

  and here's the salient bit from the fetch log file, clearly showing
a sizable tarball being downloaded from downloads.yoctoproject.org:

/ START /
DEBUG: For url
git://git.yoctoproject.org/linux-yocto-3.19.git;bareclone=1;branch=standard/common-pc,meta;name=machine,meta
returning
http://downloads.yoctoproject.org/mirror/sources/git2_git.yoctoproject.org.linux-yocto-3.19.git.tar.gz
... cut ...
DEBUG: Fetching
http://downloads.yoctoproject.org/mirror/sources/git2_git.yoctoproject.org.linux-yocto-3.19.git.tar.gz
using command '/usr/bin/env wget -t 2 -T 30 -nv --passive-ftp
--no-check-certificate -P /home/rpjday/oe/builds/qemux86/downloads
'http://downloads.yoctoproject.org/mirror/sources/git2_git.yoctoproject.org.linux-yocto-3.19.git.tar.gz''
DEBUG: Fetcher accessed the network with the command /usr/bin/env wget
-t 2 -T 30 -nv --passive-ftp --no-check-certificate -P
/home/rpjday/oe/builds/qemux86/downloads
'http://downloads.yoctoproject.org/mirror/sources/git2_git.yoctoproject.org.linux-yocto-3.19.git.tar.gz'
/// END ///

  that tarball is 927M as you can see here:

http://downloads.yoctoproject.org/mirror/sources/

dated mar 24, so that's fairly new and makes me wonder if there's
something weird/broken about it. waiting for wget to finish ... ok,
done. now try to cuild:

  $ bitbake linux-yocto

hmmm ... and it's already blown by the validate_branches task, so
suddenly, no problem. weird.

  it is entirely possible that, because i was using a local mirror
loaded with tarballs, an earlier kernel tarball was being picked up
and wasn't compatible with later content. after dropping any reference
to my local mirror, validate_branches appears to work.

  still curious as to the presence of the linux-3.19 xz tarball in my
downloads directory.

rday

-- 


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

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



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

Re: [yocto] what is the proper way to build with fedora rawhide/gcc-5.0?

2015-04-02 Thread Robert P. J. Day 
On Tue, 31 Mar 2015, Khem Raj wrote:

> > On Mar 31, 2015, at 12:54 PM, Robert P. J. Day  
> > wrote:
> >
> >  i asked about this a few weeks ago, finally getting back to it
> > ... for better or worse, i'm running fedora rawhide, updated to
> > the point where i have gcc-5.0.0:
> >
> > $ gcc --version
> > gcc (GCC) 5.0.0 20150208 (Red Hat 5.0.0-0.10)
> > Copyright (C) 2015 Free Software Foundation, Inc.
> > This is free software; see the source for copying conditions.  There is NO
> > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> > $
> >
> > which causes a number of build issues trying to build for something as
> > simple as qemux86.
> >
> >  first, there is a linemarkers issue with gcc-5.0 that i got around
> > by adding to local.conf:
> >
> >  CPPFLAGS_append= " -P”
>
> This should not be required. Can you post the failing package with error 
> details
> it should be fixed.
> >
> > and there were two native build issues due to gcc-5.0 being far
> > pickier with warnings that i sidestepped with the cheap hack:
> >
> >  ASSUME_PROVIDED += "elfutils-native"
> >  ASSUME_PROVIDED += "binutils-native”
>
> There is 2.25 update available on my contrib tree.
> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/master
> should help with binutils.

  i *think* i mentioned earlier that the first failing package build
is ncurses-native:

| In file included from
/home/rpjday/oe/builds/qemux86/tmp/work/x86_64-linux/ncurses-native/5.9-r15.1/ncurses-5.9/ncurses/curses.priv.h:283:0,
|  from ../ncurses/lib_gen.c:19:
| _9187.c:835:15: error: expected ')' before 'int'
| ../include/curses.h:1594:56: note: in definition of macro
'mouse_trafo'
|  #define mouse_trafo(y,x,to_screen)
wmouse_trafo(stdscr,y,x,to_screen)
| ^
| gcc  -DHAVE_CONFIG_H -I../ncurses
-I/home/rpjday/oe/builds/qemux86/tmp/work/x86_64-linux/ncurses-native/5.9-r15.1/ncurses-5.9/ncurses
-isystem/home/rpjday/oe/builds/qemux86/tmp/sysroots/x86_64-linux/usr/include
-D_GNU_SOURCE -DNDEBUG -I. -I../include
-I/home/rpjday/oe/builds/qemux86/tmp/work/x86_64-linux/ncurses-native/5.9-r15.1/ncurses-5.9/ncurses/../include
-I/home/rpjday/oe/builds/qemux86/tmp/sysroots/x86_64-linux/usr/include
-isystem/home/rpjday/oe/builds/qemux86/tmp/sysroots/x86_64-linux/usr/include
-D_GNU_SOURCE -O2 -pipe  --param max-inline-insns-single=1200 -fPIC -c
/home/rpjday/oe/builds/qemux86/tmp/work/x86_64-linux/ncurses-native/5.9-r15.1/ncurses-5.9/ncurses/base/lib_isendwin.c
-o ../obj_s/lib_isendwin.o
| Makefile:1682: recipe for target '../obj_s/lib_gen.o' failed

  this appears to be related to the issues listed in this post
describing a mass rebuild of fedora packages with gcc-5.0.0:

https://lists.fedoraproject.org/pipermail/devel/2015-February/207549.html

particularly this:

"Main offender this time is probably the gnu11 change that entails
different inline semantics, enables some warnings by default, bumps
the __STDC_VERSION__, and so on.  Hopefully it won't take too long
till these packages catch on. Many packages were not prepared for the
new major version of GCC.  There's also been quite a lot of churn
because of the preprocessor now emitting linemarkers in the output
when the -P option is not turned on.  The C++ compiler now rejects
some code that it used to accept.  Furthermore, GCC 5 has a batch of
new warnings, which, combined with -Werror, caused some additional
failures."

  sure enough, down that page, ncurses and a bunch of other packages
are identified as having the issue:

"these packages failed to build because of the changes in the
preprocessor; gcc started to generate line directives to better detect
whether a macro tokens come from a system header - see
http://gcc.gnu.org/PR60723 The fix is to use the -P option if the code
isn't prepared to deal with such directives."

  i see that your oe-contrib repo has a newer version of binutils, but
not of ncurses, although your ncurses SRC_URI is different. anyway,
this is just what i've tripped over lately on my rawhide system.

rday

-- 


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

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

Re: [yocto] what is the proper way to build with fedora rawhide/gcc-5.0?

2015-04-02 Thread Robert P. J. Day 
On Tue, 31 Mar 2015, Khem Raj wrote:

>
> > On Mar 31, 2015, at 12:54 PM, Robert P. J. Day  
> > wrote:
> >
> >
> >  i asked about this a few weeks ago, finally getting back to it ...
> > for better or worse, i'm running fedora rawhide, updated to the point
> > where i have gcc-5.0.0:
> >
> > $ gcc --version
> > gcc (GCC) 5.0.0 20150208 (Red Hat 5.0.0-0.10)
> > Copyright (C) 2015 Free Software Foundation, Inc.
> > This is free software; see the source for copying conditions.  There is NO
> > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> > $
> >
> > which causes a number of build issues trying to build for something as
> > simple as qemux86.
> >
> >  first, there is a linemarkers issue with gcc-5.0 that i got around
> > by adding to local.conf:
> >
> >  CPPFLAGS_append= " -P”
>
> This should not be required. Can you post the failing package with
> error details it should be fixed.

  FYI, your version of ncurses-5,9 with a more upstream SRC_URI
appears to solve the problem with building ncurses-native.

rday

-- 


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

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

Re: [yocto] Kernel Panic: /sbin/init not found

2015-04-02 Thread Paul Eggleton 
Hi Chan Kit,

On Thursday 02 April 2015 09:25:35 Yu, Chan KitX wrote:
> My Yocto build environment was working perfectly until last week when I got
> kernel panic caused by missing/sbin/init. When I examined the image, I
> found that /sbin/init is indeed absent from the root image. To troubleshoot
> the issue, I tried building a stock Yocto whose target platform is 64-bit
> machine using a  freshly installed Ubuntu 14.04 from another build machine.
>  Despite that, the kernel panic still occurs and that's the main reason I'm
> writing here; that is to see if anyone else has the same issue. I did not
> make any change or any customization to local.conf aside from setting
> MACHINE to 64 bit and adding the following lines which enable multilib:
> 
> IMAGE_INSTALL = "lib32-connman"
> require conf/multilib.conf
> MULTILIBS = "multilib:lib32"
> DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
> 
> I would be more than happy to provide necessary diagnostic message shall you
> request so. Let me know if you guys are able to reproduce this issue.

What version of the build system are you using? What exact image are you 
building? What image output type are you trying this with (ext3 / live / 
etc.)? What is your MACHINE value? Can you attach the manifest file for the 
image that is broken?

Cheers,
Paul

-- 

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

Re: [yocto] python3-native problems

2015-04-02 Thread Matthew Karas 
I've attempted through the icr channel to install python3 and pip such that
I can install packages and use the standard library.

It didn't look like the python 3 package group was setup.  I attempted to
do what khem` suggested to get around the problem.

https://www.yoctoproject.org/irc/%23yocto.2015-04-01.log.html
mkaras: look into build tree of python3 and see what all ipk/rpms it
generated
and add them all to IMAGE_INSTALL

Doing that still produced errors.  So I tried out getting pip and python 2
on my target and it worked on the first try.

Adding these to IMAGE_INSTALL - did exactly what I was looking for.
python \
python-pip \


On Wed, Apr 1, 2015 at 11:19 AM, Burton, Ross  wrote:

>
> On 1 April 2015 at 15:29, Matthew Karas  wrote:
>
>> DEPENDS = "python3 python3-native python3-distribute"
>> RDEPENDS_${PN} = "python3 python3-native python3-distribute"
>> RDEPENDS_${PN}-dev = "bash python3 python3-native python3-distribute"
>>
>
> python3-native is a form of Python 3 that is built and executed on your
> build machine, so it makes no sense to have this as a runtime dependency.
> The RDEPENDS should just be python3 python3-distribute.
>
> Ross
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] what is the proper way to build with fedora rawhide/gcc-5.0?

2015-04-02 Thread Robert P. J. Day 
On Tue, 31 Mar 2015, Khem Raj wrote:

>
> > On Mar 31, 2015, at 12:54 PM, Robert P. J. Day  
> > wrote:
> >
> >
> >  i asked about this a few weeks ago, finally getting back to it ...
> > for better or worse, i'm running fedora rawhide, updated to the point
> > where i have gcc-5.0.0:
> >
> > $ gcc --version
> > gcc (GCC) 5.0.0 20150208 (Red Hat 5.0.0-0.10)
> > Copyright (C) 2015 Free Software Foundation, Inc.
> > This is free software; see the source for copying conditions.  There is NO
> > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> > $
> >
> > which causes a number of build issues trying to build for something as
> > simple as qemux86.
> >
> >  first, there is a linemarkers issue with gcc-5.0 that i got around
> > by adding to local.conf:
> >
> >  CPPFLAGS_append= " -P”
>
> This should not be required. Can you post the failing package with error 
> details
> it should be fixed.
>
> >
> > and there were two native build issues due to gcc-5.0 being far
> > pickier with warnings that i sidestepped with the cheap hack:
> >
> >  ASSUME_PROVIDED += "elfutils-native"
> >  ASSUME_PROVIDED += "binutils-native”
>
> There is 2.25 update available on my contrib tree.
> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/master
> should help with binutils.

  ok, i finally have a full build for qemux86/core-image-minimal.
things i did:

* wiped the old kernel tarball from my local source mirror -- not
  sure why that fixed the kernel issue but a fresh download seems
  to have done the trick.
* removed the above CPPFLAGS_append line from local.conf
* used khem's ncurses recipe
* left the two ASSUME_PROVIDED lines where they were, out of sheer
  laziness since they seem to work.

  enough excitement for one day ...

rday

-- 


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

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

Re: [yocto] Devshell configuration

2015-04-02 Thread Burton, Ross 
On 1 April 2015 at 08:59, PIEWALD Georg 
wrote:

> Ideally I would imagine that I can somewhere configure the exact command
> that is called when I execute "bitbake xxx –c devshell". If that's not
> possible, can I at least change some of the points mentioned above?
>
>
For most things you said not currently, but classes/devshell.bbclass and
classes/terminal.bbclass are where the logic lies, so patches are welcome.

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

Re: [yocto] what is the proper way to build with fedora rawhide/gcc-5.0?

2015-04-02 Thread Khem Raj 
On Thu, Apr 2, 2015 at 6:12 AM, Robert P. J. Day  wrote:
> On Tue, 31 Mar 2015, Khem Raj wrote:
>
>>
>> > On Mar 31, 2015, at 12:54 PM, Robert P. J. Day  
>> > wrote:
>> >
>> >
>> >  i asked about this a few weeks ago, finally getting back to it ...
>> > for better or worse, i'm running fedora rawhide, updated to the point
>> > where i have gcc-5.0.0:
>> >
>> > $ gcc --version
>> > gcc (GCC) 5.0.0 20150208 (Red Hat 5.0.0-0.10)
>> > Copyright (C) 2015 Free Software Foundation, Inc.
>> > This is free software; see the source for copying conditions.  There is NO
>> > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>> > $
>> >
>> > which causes a number of build issues trying to build for something as
>> > simple as qemux86.
>> >
>> >  first, there is a linemarkers issue with gcc-5.0 that i got around
>> > by adding to local.conf:
>> >
>> >  CPPFLAGS_append= " -P”
>>
>> This should not be required. Can you post the failing package with error 
>> details
>> it should be fixed.
>>
>> >
>> > and there were two native build issues due to gcc-5.0 being far
>> > pickier with warnings that i sidestepped with the cheap hack:
>> >
>> >  ASSUME_PROVIDED += "elfutils-native"
>> >  ASSUME_PROVIDED += "binutils-native”
>>
>> There is 2.25 update available on my contrib tree.
>> http://git.openembedded.org/openembedded-core-contrib/log/?h=kraj/master
>> should help with binutils.
>
>   ok, i finally have a full build for qemux86/core-image-minimal.
> things i did:
>
> * wiped the old kernel tarball from my local source mirror -- not
>   sure why that fixed the kernel issue but a fresh download seems
>   to have done the trick.
> * removed the above CPPFLAGS_append line from local.conf
> * used khem's ncurses recipe
> * left the two ASSUME_PROVIDED lines where they were, out of sheer
>   laziness since they seem to work.

my branch will have more fixes for packages that are specifically
originating from gcc5 work. Some has already been merged some more are
to come


>
>   enough excitement for one day ...
>
> rday
>
> --
>
> 
> Robert P. J. Day Ottawa, Ontario, CANADA
> http://crashcourse.ca
>
> Twitter:   http://twitter.com/rpjday
> LinkedIn:   http://ca.linkedin.com/in/rpjday
> 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Yocto 1.8_M4.rc1 Full Pass test report.

2015-04-02 Thread Georgescu, Alexandru C 
Hello,

Here is the Full pass test report for Yocto 1.8_M4.rc1.
Below you can view the summary report. The full pass test report is available 
on the wiki: 
https://wiki.yoctoproject.org/wiki/WW13_-_2015-03-25_-_Full_Pass_1.8_M4.rc1 
including the Distro test results and build performance test.


Testing data

 Test type:  Full Pass Release Test
 Branch: master
 Build name: 1.8_M4.rc1
 poky commit: 8b3d3e7c957ad06c390886487f69aeb8e145da6a
 Autobuilder images repository: 
http://autobuilder.yoctoproject.org/pub/releases/yocto-1.8_M4.rc1/
 Distributions tested: Ubuntu 14.04 64bit, Fedora 21 64bit, Opensuse 13.2 
64bit, CentOS 7 64 bit


Test Run Summary Report
Testing Summary Report

Test RunTest Plan   Environment Passed  Other issuesFailed  
Failing bugsBlocked Blocking bugs   Complete
3645 
3646 ADT: master 
branch  Fedora 21 i686  98.5%   none1.5%
7536 
7545   0.0%none 
   100.0%
3647 
3648 ADT: master 
branch  Ubuntu 14.04 x86_64 98.5%   none1.5%
7536 
7545   0.0%none 
   100.0%
3651 
3652 BSP/QEMU: 
master branch Beaglebone Black98.7%   none1.3%
75430.0%none
100.0%
3657 
3658 BSP/QEMU: 
master branch EdgeRouter  100.0%  none0.0%none0.0%none
100.0%
3632 
3633 BSP/QEMU: 
master branch generic-x86 on AtomPC   98.8%   none1.2%
75320.0%none
100.0%
3630 
3631 BSP/QEMU: 
master branch genericx86-64 on Sugarbay   100.0%  none0.0%none
0.0%none100.0%
3659 
3660 BSP/QEMU: 
master branch MPC8315e-rdb100.0%  none0.0%none0.0%none
100.0%
3653 
3655 BSP/QEMU: 
master branch P1022ds 100.0%  none0.0%none0.0%none100.0%
3634 
3635 BSP/QEMU: 
master branch qemu-x86100.0%  none0.0%none0.0%none
100.0%
3638 
3639 BSP/QEMU: 
master branch qemuarm 100.0%  none0.0%none0.0%none100.0%
3640 
3641 BSP/QEMU: 
master branch qemumips100.0%  none0.0%none0.0%none
100.0%
3642 
3643 BSP/QEMU: 
master branch qemuppc 100.0%  
72360.0%none
0.0%none100.0%
3636 
3637 BSP/QEMU: 
master branch qemux86-64  100.0%  none0.0%none0.0%none
100.0%
3625 Eclipse 
Plugin: master branch   Fedora 21 x86_6433.3%   
75303.0%
5163 
7530   63.6%   
7530100.0%
3649 
3650 Meta-yocto: 
master branch   Ubuntu 14.04 x86_64 100.0%  
61560.0%none
0.0

[yocto] How to find libraries when building software

2015-04-02 Thread Andy Falanga (afalanga) 
HI,

Thanks to Gary Thomas' response, I was able to get the python libraries from 
Boost built.  Now, when I'm building my own library, which requires 
libboost_python, the configure script isn't able to find it.  How do I work 
with these cross compilation environments?

What I have is this.  I added the line below to local.conf as Gary instructed.

PACKAGECONFIG_pn-boost = "python"

I then ran

bitbake core-image-minimal

This built both python and the full set of boost (include libboost_python).  I 
see this in /sysroots/zc706-zynq7/usr/lib.  (In case it's relevant, 
this environment was constructed using 
/opt/yocto/poky-dizzy-12.0.1/oe-init-build-env.)  I then use a script that a 
co-worker wrote (quite simple) which configures the paths accordingly to use 
the cross compiler toolset.  My path is as follows:

/home/afalanga/src/crisscross/tmp/sysroots/x86_64-linux/usr/bin/arm-poky-linux-gnueabi:/home/afalanga/src/crisscross/tmp/sysroots/x86_64-linux/usr/bin:/opt/yocto/poky-dizzy-12.0.1/scripts:/opt/yocto/poky-dizzy-12.0.1/bitbake/bin:/opt/petalinux-v2014.4-final/tools/linux-i386/arm-xilinx-linux-gnueabi/bin:/opt/petalinux-v2014.4-final/tools/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

In my own library project, I run my configure script with this:

./configure --host=arm-poky-linux-gnueabi

All is working quite well except that I run into this error:
...
checking for Boost headers version >= 1.47.0... yes
checking for Boost's header version... 1_56
checking for the toolset name used by Boost for arm-poky-linux-gnueabi-g++... 
gcc49 -gcc
checking boost/system/error_code.hpp usability... yes
checking boost/system/error_code.hpp presence... yes
checking for boost/system/error_code.hpp... yes
checking for the Boost system library... yes
checking boost/filesystem/path.hpp usability... yes
checking boost/filesystem/path.hpp presence... yes
checking for boost/filesystem/path.hpp... yes
checking for the Boost filesystem library... (cached) yes
checking boost/python.hpp usability... no
checking boost/python.hpp presence... no
checking for boost/python.hpp... no
configure: error: cannot find boost/python.hpp

I can find this file in /sysroots/zx706-zinq7/usr/include/boost, 
why can't the configure script?  What's wrong with how I've done things?  Or, 
and probably much more beneficial, when I say, "--host=arm-poky-linux-gnueabi" 
what does that actually mean?  Where are these things installed?  Why is it 
saying that it cannot find the header when I can?  The only rational 
explanation is that it's looking somewhere other than where I am.  Thus, I 
don't understand as much as I should.  What should I read in the manual? 

Andy

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

Re: [yocto] How to find libraries when building software

2015-04-02 Thread Gary Thomas 

On 2015-04-02 11:36, Andy Falanga (afalanga) wrote:

HI,

Thanks to Gary Thomas' response, I was able to get the python libraries from 
Boost built.  Now, when I'm building my own library, which requires 
libboost_python, the configure script isn't able to find it.  How do I work 
with these cross compilation environments?

What I have is this.  I added the line below to local.conf as Gary instructed.

PACKAGECONFIG_pn-boost = "python"

I then ran

bitbake core-image-minimal

This built both python and the full set of boost (include libboost_python).  I see 
this in /sysroots/zc706-zynq7/usr/lib.  (In case it's relevant, 
this environment was constructed using 
/opt/yocto/poky-dizzy-12.0.1/oe-init-build-env.)  I then use a script that a 
co-worker wrote (quite simple) which configures the paths accordingly to use the 
cross compiler toolset.  My path is as follows:

/home/afalanga/src/crisscross/tmp/sysroots/x86_64-linux/usr/bin/arm-poky-linux-gnueabi:/home/afalanga/src/crisscross/tmp/sysroots/x86_64-linux/usr/bin:/opt/yocto/poky-dizzy-12.0.1/scripts:/opt/yocto/poky-dizzy-12.0.1/bitbake/bin:/opt/petalinux-v2014.4-final/tools/linux-i386/arm-xilinx-linux-gnueabi/bin:/opt/petalinux-v2014.4-final/tools/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

In my own library project, I run my configure script with this:

./configure --host=arm-poky-linux-gnueabi

All is working quite well except that I run into this error:
...
checking for Boost headers version >= 1.47.0... yes
checking for Boost's header version... 1_56
checking for the toolset name used by Boost for arm-poky-linux-gnueabi-g++... 
gcc49 -gcc
checking boost/system/error_code.hpp usability... yes
checking boost/system/error_code.hpp presence... yes
checking for boost/system/error_code.hpp... yes
checking for the Boost system library... yes
checking boost/filesystem/path.hpp usability... yes
checking boost/filesystem/path.hpp presence... yes
checking for boost/filesystem/path.hpp... yes
checking for the Boost filesystem library... (cached) yes
checking boost/python.hpp usability... no
checking boost/python.hpp presence... no
checking for boost/python.hpp... no
configure: error: cannot find boost/python.hpp

I can find this file in /sysroots/zx706-zinq7/usr/include/boost, why can't 
the configure script?  What's wrong with how I've done things?  Or, and probably much more 
beneficial, when I say, "--host=arm-poky-linux-gnueabi" what does that actually mean? 
 Where are these things installed?  Why is it saying that it cannot find the header when I can? 
 The only rational explanation is that it's looking somewhere other than where I am.  Thus, I 
don't understand as much as I should.  What should I read in the manual?


Library dependencies like this are handled by DEPENDS

Does your recipe DEPENDS contain "boost"? e.g.
  DEPENDS = "boost"

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [yocto] How to find libraries when building software

2015-04-02 Thread Gary Thomas 

On 2015-04-02 11:36, Andy Falanga (afalanga) wrote:

HI,

Thanks to Gary Thomas' response, I was able to get the python libraries from 
Boost built.  Now, when I'm building my own library, which requires 
libboost_python, the configure script isn't able to find it.  How do I work 
with these cross compilation environments?

What I have is this.  I added the line below to local.conf as Gary instructed.

PACKAGECONFIG_pn-boost = "python"

I then ran

bitbake core-image-minimal

This built both python and the full set of boost (include libboost_python).  I see 
this in /sysroots/zc706-zynq7/usr/lib.  (In case it's relevant, 
this environment was constructed using 
/opt/yocto/poky-dizzy-12.0.1/oe-init-build-env.)  I then use a script that a 
co-worker wrote (quite simple) which configures the paths accordingly to use the 
cross compiler toolset.  My path is as follows:

/home/afalanga/src/crisscross/tmp/sysroots/x86_64-linux/usr/bin/arm-poky-linux-gnueabi:/home/afalanga/src/crisscross/tmp/sysroots/x86_64-linux/usr/bin:/opt/yocto/poky-dizzy-12.0.1/scripts:/opt/yocto/poky-dizzy-12.0.1/bitbake/bin:/opt/petalinux-v2014.4-final/tools/linux-i386/arm-xilinx-linux-gnueabi/bin:/opt/petalinux-v2014.4-final/tools/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games

In my own library project, I run my configure script with this:

./configure --host=arm-poky-linux-gnueabi

All is working quite well except that I run into this error:
...
checking for Boost headers version >= 1.47.0... yes
checking for Boost's header version... 1_56
checking for the toolset name used by Boost for arm-poky-linux-gnueabi-g++... 
gcc49 -gcc
checking boost/system/error_code.hpp usability... yes
checking boost/system/error_code.hpp presence... yes
checking for boost/system/error_code.hpp... yes
checking for the Boost system library... yes
checking boost/filesystem/path.hpp usability... yes
checking boost/filesystem/path.hpp presence... yes
checking for boost/filesystem/path.hpp... yes
checking for the Boost filesystem library... (cached) yes
checking boost/python.hpp usability... no
checking boost/python.hpp presence... no
checking for boost/python.hpp... no
configure: error: cannot find boost/python.hpp

I can find this file in /sysroots/zx706-zinq7/usr/include/boost, why can't 
the configure script?  What's wrong with how I've done things?  Or, and probably much more 
beneficial, when I say, "--host=arm-poky-linux-gnueabi" what does that actually mean? 
 Where are these things installed?  Why is it saying that it cannot find the header when I can? 
 The only rational explanation is that it's looking somewhere other than where I am.  Thus, I 
don't understand as much as I should.  What should I read in the manual?


Another thing to look at is the 'config.log' in your build
(for your "library" recipe).  It should tell you more about
why it can't find boost/python.hpp

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

[yocto] Installing custom python packages

2015-04-02 Thread Matthew Karas 
How do I install a custom python package in yocto?  I've tried looking up
google but nothing comes up.  On my non-target machine I just do pip
install .  What do I put in my bb file?

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

Re: [yocto] How to find libraries when building software

2015-04-02 Thread Andy Falanga (afalanga) 
__
From: yocto-boun...@yoctoproject.org [yocto-boun...@yoctoproject.org] on behalf 
of Gary Thomas [g...@mlbassoc.com]
Sent: Thursday, April 02, 2015 11:58 AM
To: yocto@yoctoproject.org
Subject: Re: [yocto] How to find libraries when building software

On 2015-04-02 11:36, Andy Falanga (afalanga) wrote:
> HI,
>
> Thanks to Gary Thomas' response, I was able to get the python libraries from 
> Boost built.  Now, when I'm building my own library, which requires 
> libboost_python, the configure script isn't able to find it.  How do I work 
> with these cross compilation environments?
>
> What I have is this.  I added the line below to local.conf as Gary instructed.
>
> PACKAGECONFIG_pn-boost = "python"
>
> I then ran
>
> bitbake core-image-minimal
>
> This built both python and the full set of boost (include libboost_python).  
> I see this in /sysroots/zc706-zynq7/usr/lib.  (In case it's 
> relevant, this environment was constructed using 
> /opt/yocto/poky-dizzy-12.0.1/oe-init-build-env.)  I then use a script that a 
> co-worker wrote (quite simple) which configures the paths accordingly to use 
> the cross compiler toolset.  My path is as follows:
>
> /home/afalanga/src/crisscross/tmp/sysroots/x86_64-linux/usr/bin/arm-poky-linux-gnueabi:/home/afalanga/src/crisscross/tmp/sysroots/x86_64-linux/usr/bin:/opt/yocto/poky-dizzy-12.0.1/scripts:/opt/yocto/poky-dizzy-12.0.1/bitbake/bin:/opt/petalinux-v2014.4-final/tools/linux-i386/arm-xilinx-linux-gnueabi/bin:/opt/petalinux-v2014.4-final/tools/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
>
> In my own library project, I run my configure script with this:
>
> ./configure --host=arm-poky-linux-gnueabi
>
> All is working quite well except that I run into this error:
> ...
> checking for Boost headers version >= 1.47.0... yes
> checking for Boost's header version... 1_56
> checking for the toolset name used by Boost for arm-poky-linux-gnueabi-g++... 
> gcc49 -gcc
> checking boost/system/error_code.hpp usability... yes
> checking boost/system/error_code.hpp presence... yes
> checking for boost/system/error_code.hpp... yes
> checking for the Boost system library... yes
> checking boost/filesystem/path.hpp usability... yes
> checking boost/filesystem/path.hpp presence... yes
> checking for boost/filesystem/path.hpp... yes
> checking for the Boost filesystem library... (cached) yes
> checking boost/python.hpp usability... no
> checking boost/python.hpp presence... no
> checking for boost/python.hpp... no
> configure: error: cannot find boost/python.hpp
>
> I can find this file in /sysroots/zx706-zinq7/usr/include/boost, 
> why can't the configure script?  What's wrong with how I've done things?  Or, 
> and probably much more beneficial, when I say, 
> "--host=arm-poky-linux-gnueabi" what does that actually mean?  Where are 
> these things installed?  Why is it saying that it cannot find the header when 
> I can?  The only rational explanation is that it's looking somewhere other 
> than where I am.  Thus, I don't understand as much as I should.  What should 
> I read in the manual?

Another thing to look at is the 'config.log' in your build
(for your "library" recipe).  It should tell you more about
why it can't find boost/python.hpp


I want to ensure I've been clear enough.  I fear I didn’t explain well
how I'm trying to build my library.  (It's a C++ library exposed in
python.)  I have a standard GNU configure script which I'm trying to use
with the cross compiler that was built.  I'm not using recipes in bitbake
to make this library.

Also, I have been reviewing the config.log file.  It appears to me that
the real problem is that the build cannot find python.h.  This is rather
strange because the file does exist and it's in
.../sysroots/zc706-zynq7/usr/include/python2.7.  I would have assumed that
the automate macro AM_PATH_PYTHON.  At any rate, this does seem to be the
problem.  Curiously, I haven't yet been able to workaround it by supplying
a customized "CPPFLAGS=" argument.  I've tried both CPPFLAGS= and 
"BOOST_PYTHON_CPPFLAGS=" to the same effect.

Any pointers are most appreciated.

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

Re: [yocto] Installing custom python packages

2015-04-02 Thread Tim Orling 
Matthew,

Please have a look at the python recipes in
http://git.openembedded.org/meta-openembedded/tree/meta-python/recipes-devtools/python
Creating your own similar recipe will allow you to add the python package
to your built image, or load it an runtime as an rpm/ipk/deb.
You could add this recipe to your own layer, if it is custom and not useful
to the community.

It is possible to run pip on the target (if you added pip to your image,
e.g. IMAGE_INSTALL_append = " python-pip" is in your local.conf).


Regards,

--Tim


On Thu, Apr 2, 2015 at 12:09 PM, Matthew Karas  wrote:

> How do I install a custom python package in yocto?  I've tried looking up
> google but nothing comes up.  On my non-target machine I just do pip
> install .  What do I put in my bb file?
>
> Many Thanks
>
> --
> ___
> 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] Release Candidate Build for yocto- now available.

2015-04-02 Thread Poky Build User 

A release candidate build for yocto- is now available at:

 
http://autobuilder.yoctoproject.org/pub/releases/yocto-


Please begin QA on this build as soon as possible.


Build hash information: 
meta-intel : 53eea4f12311b4808b3af9695ac822eea1fc60c2 
meta-fsl-arm : bfe01a0ebde407086f4a7710ea165c6beff310d7 
meta-minnow : 13a5f2ab84c7284647a3e067a33109c11dae0568 
meta-qt3 : 3016129d90b7ac8517a5227d819f10ad417b5b45 
meta-fsl-ppc : 4c8cd553f9de56379e2b6502ceb996521e2d6a20 
poky : 33558eacc8a2d3dce3396b9ab2fd0773ac5076bc 


This is an automated message from
The Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder
Email: elizabeth.flana...@intel.com 
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Difference b/w yocto kernels and normal linux.org kernels

2015-04-02 Thread Raghavendra Kakarla 
Hi Paul Eggleton,

I have some doubts on the SDK and build errors.

Could you please clarify my doubts.

1. Can we get the consolidated log/file for total installed packages for 
corresponding SDK. If user wants to know what packages are included in the SDK.

2. When trying to build the images always getting a error saying that clean 
things in kernel path in build error log, then we goto that path run command 
"make mrproper" then it is working fine. 


Thanks and Regards,
Raghavendra K.



From: Paul Eggleton 
Sent: Friday, March 13, 2015 2:23 PM
To: Raghavendra Kakarla
Cc: yocto@yoctoproject.org
Subject: Re: Difference b/w yocto kernels and normal linux.org kernels

On Friday 13 March 2015 08:14:13 Raghavendra Kakarla wrote:
> Is it kernel is must be a git repository code for building in the yocto?
>
> When i gave my custom kernel which is not a git repository code and it is in
> my development PC, i got invalid SRCREV number error. But when give the
> same kernel from the git repository it is working. Can you please help me
> in resolving this error.

If you want to use your own non-git sources you are moving further away from
how the linux-yocto recipe works. If you have not already I would suggest
using linux-yocto-custom as described in our kernel development manual:

http://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html#working-with-your-own-sources

Note that you must not have SRCPV included in the recipe's value of PV, or
you will get the error you mentioned.

Cheers,
Paul

--

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

Re: [yocto] Kernel Panic: /sbin/init not found

2015-04-02 Thread Yu, Chan KitX 


> -Original Message-
> From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
> Sent: Thursday, April 02, 2015 7:37 PM
> To: Yu, Chan KitX
> Cc: yocto@yoctoproject.org
> Subject: Re: [yocto] Kernel Panic: /sbin/init not found
> 
> Hi Chan Kit,
> 
> On Thursday 02 April 2015 09:25:35 Yu, Chan KitX wrote:
> > My Yocto build environment was working perfectly until last week when
> > I got kernel panic caused by missing/sbin/init. When I examined the
> > image, I found that /sbin/init is indeed absent from the root image.
> > To troubleshoot the issue, I tried building a stock Yocto whose target
> > platform is 64-bit machine using a  freshly installed Ubuntu 14.04 from
> another build machine.
> >  Despite that, the kernel panic still occurs and that's the main
> > reason I'm writing here; that is to see if anyone else has the same
> > issue. I did not make any change or any customization to local.conf
> > aside from setting MACHINE to 64 bit and adding the following lines which
> enable multilib:
> >
> > IMAGE_INSTALL = "lib32-connman"
> > require conf/multilib.conf
> > MULTILIBS = "multilib:lib32"
> > DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
> >
> > I would be more than happy to provide necessary diagnostic message
> > shall you request so. Let me know if you guys are able to reproduce this
> issue.
> 
> What version of the build system are you using? What exact image are you
> building? What image output type are you trying this with (ext3 / live / 
> etc.)?
> What is your MACHINE value?
Build Configuration:
BB_VERSION= "1.24.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING   = "Ubuntu-14.04"
TARGET_SYS= "x86_64-poky-linux"
MACHINE   = "valleyisland-64"
DISTRO= "poky"
DISTRO_VERSION= "1.7.1"
TUNE_FEATURES = "m64 corei7"
TARGET_FPU= ""
meta
meta-yocto
meta-yocto-bsp= "dizzy:ec75238f6cc2d2d8d40e0268f6d2acc070cbe9a4"
meta-intel
meta-valleyisland = "dizzy:c39a4bf4450845fca6f1b26ccfc0db192a4567e8"

The above is the build configuration. As of the image that I was trying to 
build, I did the hddimg and iso. I got the KP issue from using the iso image. I 
thought the issue might have to do with the meta-valleyisland so I switched to 
genericx86-64 instead. No luck.


Can you attach the manifest file for the image
> that is broken?

Attached.

UPDATE: I tried disabling the multilib feature by commenting out the following 
in local.conf:

IMAGE_INSTALL = "lib32-connman"
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "x86"

I used to enable multilib in Yocto by adding those lines and it has always 
worked. I got this step from 
https://wiki.yoctoproject.org/wiki/Multilib#How_to_use_it . However, I'm not 
very sure if that's the proper way to enable multilib in Yocto.

Thanks,
Chan Kit


> 
> --
> 
> Paul Eggleton
> Intel Open Source Technology Centre


core-image-sato-sdk-valleyisland-64-20150402170740.rootfs.manifest
Description: core-image-sato-sdk-valleyisland-64-20150402170740.rootfs.manifest
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Kernel Panic: /sbin/init not found

2015-04-02 Thread Yu, Chan KitX 


> -Original Message-
> From: Yu, Chan KitX
> Sent: Friday, April 03, 2015 2:30 PM
> To: 'Paul Eggleton'
> Cc: yocto@yoctoproject.org
> Subject: RE: [yocto] Kernel Panic: /sbin/init not found
> 
> 
> 
> > -Original Message-
> > From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com]
> > Sent: Thursday, April 02, 2015 7:37 PM
> > To: Yu, Chan KitX
> > Cc: yocto@yoctoproject.org
> > Subject: Re: [yocto] Kernel Panic: /sbin/init not found
> >
> > Hi Chan Kit,
> >
> > On Thursday 02 April 2015 09:25:35 Yu, Chan KitX wrote:
> > > My Yocto build environment was working perfectly until last week
> > > when I got kernel panic caused by missing/sbin/init. When I examined
> > > the image, I found that /sbin/init is indeed absent from the root image.
> > > To troubleshoot the issue, I tried building a stock Yocto whose
> > > target platform is 64-bit machine using a  freshly installed Ubuntu
> > > 14.04 from
> > another build machine.
> > >  Despite that, the kernel panic still occurs and that's the main
> > > reason I'm writing here; that is to see if anyone else has the same
> > > issue. I did not make any change or any customization to local.conf
> > > aside from setting MACHINE to 64 bit and adding the following lines
> > > which
> > enable multilib:
> > >
> > > IMAGE_INSTALL = "lib32-connman"
> > > require conf/multilib.conf
> > > MULTILIBS = "multilib:lib32"
> > > DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
> > >
> > > I would be more than happy to provide necessary diagnostic message
> > > shall you request so. Let me know if you guys are able to reproduce
> > > this
> > issue.
> >
> > What version of the build system are you using? What exact image are
> > you building? What image output type are you trying this with (ext3 / live /
> etc.)?
> > What is your MACHINE value?
> Build Configuration:
> BB_VERSION= "1.24.0"
> BUILD_SYS = "x86_64-linux"
> NATIVELSBSTRING   = "Ubuntu-14.04"
> TARGET_SYS= "x86_64-poky-linux"
> MACHINE   = "valleyisland-64"
> DISTRO= "poky"
> DISTRO_VERSION= "1.7.1"
> TUNE_FEATURES = "m64 corei7"
> TARGET_FPU= ""
> meta
> meta-yocto
> meta-yocto-bsp= "dizzy:ec75238f6cc2d2d8d40e0268f6d2acc070cbe9a4"
> meta-intel
> meta-valleyisland = "dizzy:c39a4bf4450845fca6f1b26ccfc0db192a4567e8"
> 
> The above is the build configuration. As of the image that I was trying to
> build, I did the hddimg and iso. I got the KP issue from using the iso image. 
> I
> thought the issue might have to do with the meta-valleyisland so I switched
> to genericx86-64 instead. No luck.
> 
> 
> Can you attach the manifest file for the image
> > that is broken?
> 
> Attached.
> 
> UPDATE: I tried disabling the multilib feature by commenting out the
> following in local.conf:
> 
> IMAGE_INSTALL = "lib32-connman"
> require conf/multilib.conf
> MULTILIBS = "multilib:lib32"
> DEFAULTTUNE_virtclass-multilib-lib32 = "x86"

Argh...I forgot to mention the main thing; that is the KP issue disappears iff 
I disable the multilib by removing/commenting those lines. As happy as I am 
since I found the root cause, I really need the multilib feature and hopefully 
we can dig deeper from here to fix this.

Chan Kit


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