[yocto] Release Candidate Build for yocto-1.7.2 rc2 now available.

[Poky Build User]

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

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


Please begin QA on this build as soon as possible.


Build hash information: 
meta-intel : c39a4bf4450845fca6f1b26ccfc0db192a4567e8 
meta-fsl-arm : db1571f40c375a398a8cdbb42de4c4f272ab0cd1 
meta-minnow : 13a5f2ab84c7284647a3e067a33109c11dae0568 
meta-qt3 : 3016129d90b7ac8517a5227d819f10ad417b5b45 
meta-fsl-ppc : 5eeeb3ad74b72d904f805bc6e248e93e722b45c4 
poky : 29812e61736a95f1de64b3e9ebbb9c646ebd28dd 


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

[yocto] Deploying linux-ti-staging initramfs kernel into /boot

[Craig McQueen]

I'm using linux-ti-staging kernel 3.14.x with Yocto dizzy, for a build for 
BeagleBone Black based system.

I'd like to use initramfs in my kernel. So I've set INITRAMFS_IMAGE in my 
linux-ti-staging_3.14.bbappend, and INITRAMFS_IMAGE_BUNDLE = "1" in local.conf. 
Now in build dir tmp/deploy/images/ I'm getting 
zImage-initramfs-.bin being built fine.

However, I'm not getting an initramfs image being deployed to /boot, but just a 
plain zImage without an initramfs.

Looking in the build directory 
tmp/work/-poky-linux-gnueabi/linux-ti-staging/3.14.39-r22b+gitrAUTOINC+ba552b4bc7/packages-split/kernel-image/boot
 I see there is:

zImage-3.14.39
zImage-initramfs-.bin

--however the zImage-initramfs-.bin file isn't being included in 
deploy-rpms//kernel-image-3.14.39-3.14.39-r22b+gitrAUTOINC+ba552b4bc7..rpm
 for some reason.

But, if I change my linux-ti-staging_3.14.bbappend to include any one of the 
following lines, then the kernel-image .rpm file _does_ include both zImage 
files:

RDEPENDS_kernel-base = ""
RDEPENDS_kernel-base = "kernel-devicetree"
RDEPENDS_kernel-base = "kernel-image"

But if I put:

RDEPENDS_kernel-base = "kernel-image kernel-devicetree"

--then there is no zImage-initramfs-.bin in the kernel-image .rpm. 
This seems very confusing.

Why would zImage-initramfs-.bin disappear from the kernel-image 
package when the linux-ti-staging RDEPENDS_kernel-base specifies both 
kernel-image and kernel-devicetree, but not other cases?

-- 
Craig McQueen

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

[yocto] YP 1.8 Release Survey/Retrospective - REMINDER

[Jolley, Stephen K]

All,

Yocto Project 1.8 released last week!   YP provides a major release every six 
months, and as an open source project we are always working to improve our 
processes.  This survey is for the Yocto Project community to provide feedback 
into the development process.  We would greatly appreciate your participation, 
especially if you have participated in the development process for 1.8 by 
writing code, submitting bugs, patches, documentation, contributing to the 
wiki, or actively participating on the mailing lists or IRC channels.

https://www.surveymonkey.com/r/SFV7VPH

Thanks for being an important part of the Yocto Project community!

Stephen K. Jolley
Yocto Project Program Manager
INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124
*   Work Telephone:  (503) 712-0534
*Cell:(208) 244-4460
* Email: stephen.k.jol...@intel.com

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

Re: [yocto] Kernel customized do_fetch issue

[Joel (Xi Zhou) Zhou]

Thanks Bruce!
> You really aren't seeing anything land in the build/downloads/git2/
> directory structure ? ssh fetches seem to work here.

I do see something in build/downloads/git2/git-ccxsw.xxx.com.linux-lsk, but it 
looks like an empty git.
HEAD  branches  config  description  hooks  info  objects  packed-refs  
refs

I bring up this issue to IT department, what they said is, the Yocto expects 
the url contains  host/repo, while gitolit requires host:repo.
This is interesting since the Yocto documentation explicitly mentions gitolite 
in the SCM section:
http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#best-practices-source-control-management

Thanks,
Joel

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

Re: [yocto] Kernel customized do_fetch issue

[Bruce Ashfield]

On 2015-04-29 02:08 PM, Joel (Xi Zhou) Zhou wrote:

But the question has to be asked. Why exactly are you manually fetching
the kernel ? The fetcher can take care of most everything.


The whole story is starting at the url of our git repo. We have a git URL like:
ssh://svcsw...@git-ccxsw.inhouse.com/linux-lsk

So the SRC_URI like this, but the fetcher try to apply "scp" over it.
KBRANCH= 3.14_common_dev
SRC_URI = 
"ssh://svcsw...@git-ccxsw.inhouse.com/linux-lsk;bareclone=1;branch=${KBRANCH}"
Error:
ERROR: Fetcher failure: Fetch command failed with exit code 1, output:
FATAL: unknown git/gitolite command: 'scp -r -f linux-lsk'

Then I change it  according the suggestion in this mailing list:
SRC_URI = 
"git://svcsw...@git-ccxsw.inhouse.com/linux-lsk;bareclone=1;branch=${KBRANCH};protocol=ssh"

This time "bitbake linux-lsk -c fetch" return no error, but the source folder 
in working directory is empty.
In log.do_fetch
DEBUG: Fetcher failure: Fetch command failed with exit code 8, output:
http://downloads.yoctoproject.org/mirror/sources/git2_git-ccxsw.rtp. 
inhouse.com. linux-lsk.tar.gz:
2015-04-29 12:49:36 ERROR 404: Not Found.


I'd expect that it part of the log, since obviously the mirrors aren't
going to have a copy of your kernel.

You really aren't seeing anything land in the build/downloads/git2/
directory structure ? ssh fetches seem to work here.

You'd be better of working through the issues and getting the right
SRC_URI specification for the fetcher, since taking the fetch into a
custom routine is going to short circuit parts of the build .. and you'll
have to take care of them yourself.

Cheers,

Bruce



Thanks,
Joel



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

Re: [yocto] Kernel customized do_fetch issue

[Joel (Xi Zhou) Zhou]

> But the question has to be asked. Why exactly are you manually fetching
> the kernel ? The fetcher can take care of most everything.

The whole story is starting at the url of our git repo. We have a git URL like:
ssh://svcsw...@git-ccxsw.inhouse.com/linux-lsk

So the SRC_URI like this, but the fetcher try to apply "scp" over it.
KBRANCH= 3.14_common_dev
SRC_URI = 
"ssh://svcsw...@git-ccxsw.inhouse.com/linux-lsk;bareclone=1;branch=${KBRANCH}"
Error:
ERROR: Fetcher failure: Fetch command failed with exit code 1, output:
FATAL: unknown git/gitolite command: 'scp -r -f linux-lsk'

Then I change it  according the suggestion in this mailing list:
SRC_URI = 
"git://svcsw...@git-ccxsw.inhouse.com/linux-lsk;bareclone=1;branch=${KBRANCH};protocol=ssh"

This time "bitbake linux-lsk -c fetch" return no error, but the source folder 
in working directory is empty. 
In log.do_fetch
DEBUG: Fetcher failure: Fetch command failed with exit code 8, output:
http://downloads.yoctoproject.org/mirror/sources/git2_git-ccxsw.rtp. 
inhouse.com. linux-lsk.tar.gz:
2015-04-29 12:49:36 ERROR 404: Not Found.

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

Re: [yocto] Kernel customized do_fetch issue

[Bruce Ashfield]

On 2015-04-29 01:39 PM, Joel (Xi Zhou) Zhou wrote:

Hi all,

I created a do_fetch() for checkout in-house git repo, which is working
fine with OE.

do_fetch() {

 cd ${WORKDIR}

 rm -rf ${PN}-${PV}

 git clone ssh://svcsw...@git-ccxsw.inhouse.com/linux-lsk ${PN}-${PV}

 cd ${PN}-${PV}

 git checkout ${KBRANCH}

}

With Yocto, the do_fetch() does its job, but do_configure create an issue.

do_configure_prepend() {

 cp ${WORKDIR}/${KERNEL_CONFIG_FILE} ${S}/.config

 oe_runmake oldconfig

}

The do_configure error message:

| make: *** No rule to make target `oldconfig'.  Stop.

Basically, the kernel source checkout by do_fetch() is delete/erase
while running do_configure().

I suspect some tasks between do_fetch and do_configure are doing some
magic work of moving the kernel  source around.


It's better if you can post your entire kernel recipe, and what
branch/release you are using.

There are steps that move the kernel source into work-shared, so that
may be impacting your flow.

But the question has to be asked. Why exactly are you manually fetching
the kernel ? The fetcher can take care of most everything.

If you need to modify the source directory later, have a look at the
steps that I'm taking in kernel-yocto.bbclass, since that works properly
within the fetcher and build infrastructure.

Bruce



Any suggestion?

Thanks,

Joel





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

[yocto] Kernel customized do_fetch issue

[Joel (Xi Zhou) Zhou]

Hi all,

I created a do_fetch() for checkout in-house git repo, which is working fine 
with OE.
do_fetch() {
cd ${WORKDIR}
rm -rf ${PN}-${PV}
git clone ssh://svcsw...@git-ccxsw.inhouse.com/linux-lsk ${PN}-${PV}
cd ${PN}-${PV}
git checkout ${KBRANCH}
}

With Yocto, the do_fetch() does its job, but do_configure create an issue.
do_configure_prepend() {
cp ${WORKDIR}/${KERNEL_CONFIG_FILE} ${S}/.config
oe_runmake oldconfig
}
The do_configure error message:
| make: *** No rule to make target `oldconfig'.  Stop.

Basically, the kernel source checkout by do_fetch() is delete/erase while 
running do_configure().
I suspect some tasks between do_fetch and do_configure are doing some magic 
work of moving the kernel  source around.
Any suggestion?

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

[yocto] How to create a gz file with compiled files from other recipes

[Francisco Torres]

Hello,

I have created some recipes which using an external mingw toolchain are able to 
compile some libraries for windows (e.g. clutter, mx, )

Now I would like to create a compressed file with all the compiled dlls (and if 
possible header files). How can I do that?

(I have tried to create an image but when I do that also some other packages, 
e.g., kernel, that I do not need/want are included).

Thanks,
Francis.
CONFIDENTIALITY: The contents of this e-mail are confidential and intended only 
for the above addressee(s). If you are not the intended recipient, or the 
person responsible for delivering it to the intended recipient, copying or 
delivering it to anyone else or using it in any unauthorized manner is 
prohibited and may be unlawful. If you receive this e-mail by mistake, please 
notify the sender and the systems administrator at straym...@tttech.com 
immediately.
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Kernel git repo fetch issue

[Joel (Xi Zhou) Zhou]

Thanks Khem.
The git repo can accessed by public key, so user/passwd are not need.
After changing the URL to this:
SRC_URI = 
"git://svcsw...@git-ccxsw.inhouse.com/linux-lsk;bareclone=1;branch=${KBRANCH};protocol=ssh"

Then “bitbake linux-lsk –c fetch” return no error, but the source folder in 
working directory is empty.
In log.do_fetch
DEBUG: Fetcher failure: Fetch command failed with exit code 8, output:
http://downloads.yoctoproject.org/mirror/sources/git2_git-ccxsw.rtp. 
inhouse.com. linux-lsk.tar.gz:
2015-04-29 12:49:36 ERROR 404: Not Found.

Thanks,
Joel
From: Khem Raj [mailto:raj.k...@gmail.com]
Sent: Wednesday, April 29, 2015 11:30 AM
To: Joel (Xi Zhou) Zhou
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Kernel git repo fetch issue


On Apr 29, 2015, at 8:21 AM, Joel (Xi Zhou) Zhou 
mailto:joel.z...@broadcom.com>> wrote:

So in linux-lsk_3.14.29.bb file, we define:
SRC_URI = 
"ssh://svcsw...@git-ccxsw.inhouse.com/linux-lsk;bareclone=1;branch=${KBRANCH}"



create a .netrc in your home folder like

machine  git-ccxsw.inhouse.com login svcswgit  
password 


then change the SRC_URI to something

SRC_URI = 
“git://git-ccxsw.inhouse.com/linux.lsk;bareclone=1;branch=;protocol=ssh"
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Eclipse build of existing cmake project

[Minchev, Todor]

Hello Ruben,

> 
> What I did:
> I built an image and support for eclipse (meta-ide-support) for beagle
> bone black (BBB).
> I am able to create a new project in eclipse and build and run this
> new project on my hardware.
> 
> 
> I have an existing CMAKE project which should run on BBB.
> I know how to write an recipe for my project and build this existing
> project with bitbake.
> 
> 
> What I want to do:
> I want to build my existing cmake project with eclipse. Is there any
> possibility to import existing cmake projects to eclipse and do a
> build using yocto toolchain?
> 
The easiest way to do this is to create a "Hello World C CMake Project"
with the template provided by the Yocto plugin and import your source
and CMakeLists.txt file in place of the default main.c and
CMakeLists.txt.

Regards,

Todor
 

> -- 
> Ruben Schwarz | SOTEC | r.schw...@sotec.eu | T +49 7033 5458 34 | F
> +49 7033 5458 95
> 
> www.sotec.eu | www.cloudwuerdig.com 
> -- 
> SOTEC Software Entwicklungs GmbH + Co Mikrocomputertechnik KG 
> Calwer Straße 11, D-75395 Ostelsheim 
> Sitz Ostelsheim, Amtsgericht Stuttgart HRA 330821/HRB 330664,
> Geschäftsführer: Florian Holz 
> Cloudwürdig® ist eine eingetragene Marke der SOTEC Software
> Entwicklungs GmbH + Co Mikrocomputertechnik KG
> 
> Der Inhalt dieser e-Mail ist ausschließlich für den bezeichneten
> Adressaten bestimmt. Wenn Sie nicht der vorgesehene Adressat dieser
> e-Mail oder dessen Vertreter sein sollten, so beachten Sie bitte, dass
> jede Form der Kenntnisnahme, Veröffentlichung, Vervielfältigung oder
> Weitergabe des Inhalts dieser e-Mail unzulässig ist. Wir bitten Sie,
> sich in diesem Fall mit dem Absender der e-Mail in Verbindung zu
> setzen.
> 
> The content of this e-mail is meant exclusively for the person to whom
> it is addressed. If you are not the person to whom this e-mail is
> addressed or his/her representative, please be informed, that any form
> of knowledge, publication, duplication or distribution of the content
> of this e-mail is inadmissible. We ask you, therefore, in such a case
> to please contact the sender of this e-mail.
> 
> -- 
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto



smime.p7s
Description: S/MIME cryptographic signature
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Kernel git repo fetch issue

[Khem Raj]

> On Apr 29, 2015, at 8:21 AM, Joel (Xi Zhou) Zhou  
> wrote:
> 
> So in linux-lsk_3.14.29.bb file, we define:
> SRC_URI = 
> "ssh://svcsw...@git-ccxsw.inhouse.com/linux-lsk;bareclone=1;branch=${KBRANCH} 
> "
> 


create a .netrc in your home folder like

machine  git-ccxsw.inhouse.com  login svcswgit  
password 


then change the SRC_URI to something

SRC_URI = “git://git-ccxsw.inhouse.com/linux.lsk;bareclone=1;branch= 
;protocol=ssh"-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Kernel git repo fetch issue

[Joel (Xi Zhou) Zhou]

Hi all,

We have an in-house git repo for Linux kernel:
ssh://svcsw...@git-ccxsw.inhouse.com/linux-lsk

So in linux-lsk_3.14.29.bb file, we define:
SRC_URI = 
"ssh://svcsw...@git-ccxsw.inhouse.com/linux-lsk;bareclone=1;branch=${KBRANCH}"

Then 'bitbake linux-lsk' can't fetch the URL:

ERROR: Fetcher failure: Fetch command failed with exit code 1, output:
FATAL: unknown git/gitolite command: 'scp -r -f linux-linaro-stable'

ERROR: Function failed: Fetcher failure for URL: ' 
ssh://svcsw...@git-ccxsw.inhouse.com/linux-lsk;bareclone=1;branch=3.14_common_dev'.
 Unable to fetch URL from any source.

Any idea how to fix this issue?

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

Re: [yocto] [meta-raspberrypi] meta-ivi & meta-raspberrypi

[Mauro Carvalho Chehab]

Em Wed, 29 Apr 2015 16:05:58 +0200
Alex J Lennon  escreveu:

> 
> On 29/04/2015 15:30, Oliver wrote:
> > Hello
> >
> > I have been working building together the meta-raspberrypi & the meta-ivi 
> > layers.
> > I have been stuck with configuration/compilation of weston(from mata-ivi 
> > layer):
> >
> > 1)
> >
> > You can check the intial thread 
> > http://lists.genivi.org/pipermail/genivi-meta-ivi/2015-April/000508.html
> >
> >
> > egl provided by userlad is not detected as the *.pc files are not deployed
> > Someone has faced similar problems:
> >
> >
> > http://git.buildroot.net/buildroot/commit/?id=2282b93f4248a32de84805456efa352f69b28624
> >
> > 2)
> > With this I am able to reach the do_compile stage but there are errors 
> > related to the undefined type
> >
> > PFNEGLQUERYWAYLANDBUFFERWL
> > Hacked this one forcing the inclusion of  :-S
> >
> >
> > 3)
> > At linking time the next trouble is:
> >
> > /home/oliver/raspberry/build-rpi-ivi/tmp/sysroots/i686-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.1/ld:
> >  cannot find -lwayland-egl
> >
> > IIRC this lib is provided by mesa-gl, but in my build, mesa is 
> > configured(--disable-egl (is this ok being provided by userlad?)) which 
> > might be the reason why libwayland-egl is not getting deployed in the image?
> >
> > Any correction to my statements or hint to go further would be appreciated
> >
> > Best Regards & thanks for your time
> >
> > Oliver
> 
> Hi Oliver,
> 
> I was looking at wayland/weston last year.  I can't remember exactly
> where I was at with it I am afraid, but I think I had it building and
> have pushed some of the code I was playing with to GitHub
> 
> I think this was related to the .pc issue
> 
> https://github.com/DynamicDevices/meta-raspberrypi/commit/491dd14585efdb52378a57fa6ddacb1f15065257
> 
> And this was what I was doing with weston. Looks like I was disabling EGL.
> 
> https://github.com/DynamicDevices/meta-raspberrypi/commit/c657f69deb57035fc43319dd7d41745c17d7d6e1
> 
> Sorry I can't be more help but perhaps there's something in there that
> might be of use.

I was able to build weston/wayland with meta-raspberrypi, for
the Tizen distro:
http://blogs.s-osg.org/bringing-tizen-to-a-raspberry-pi-2-near-you/

I had to apply a few patches to make it work on both Tizen and
meta-raspberrypi. The forks are at:
http://git.s-osg.org/

The current version there is actually disabling EGL. Enabling
it seems to be possible, but we're still trying to make it work
(it compiles fine, though, so I think we're close).

Once done, my plan is to work on porting the patches back to
meta-raspberrypi (and tizen-distro).

The egl-enabled version (with doesn't run, currently), is at the
"devel" branch at both git trees.

I hope that helps.

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

[yocto] Migration from 1.7.1 to 1.8 - kernel-abiversion missing

[Carl van Schaik]

I've just encountered the exact same issue upgrading. 

> Have you tried setting linux-dummy as the preferred provider for the kernel ? 
> >That would skip the build processing doing anything more than satisfying the 
> various kernel dependencies.

We do explicitly set preferred provider to linux-dummy, in our layer.

STAGING_KERNEL_builddir=./armv7/kernel-build-artifacts-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] libgomp inclusion

[Suresh Nagarajan]

Thanks for the info.. Yes, that does the trick..

Thanks
Suresh

On Mon, Apr 27, 2015 at 11:40 AM, Khem Raj  wrote:

>
> On Apr 27, 2015, at 11:32 AM, Suresh Nagarajan 
> wrote:
>
> Hi,
>
> I'm trying to look to see if OpenMP library is included in my yocto build.
>
> I could not find libgomp library in /usr/lib
> However, when I look at gcc-runtime.inc, I do notice that
>
> RUNTIMETARGET = "libssp libstdc++-v3 libgomp"
> PACKAGES = "\
>   ${PN}-dbg \
>   libstdc++ \
>   libstdc++-precompile-dev \
>   libstdc++-dev \
>   libstdc++-staticdev \
>   libg2c \
>   libg2c-dev \
>   libssp \
>   libssp-dev \
>   libssp-staticdev \
>   libgfortran \
>   libgfortran-dev \
>   libgfortran-staticdev \
>   libmudflap \
>   libmudflap-dev \
>   libmudflap-staticdev \
>   libquadmath \
>   libquadmath-dev \
>   libquadmath-staticdev \
>   libgomp \
>   libgomp-dev \
>   libgomp-staticdev \
>
>
> Also, I noticed that in gmane and other web-pages that it is OK to have
> INTIAL/INTERMEDIATE EXTRA_OECONF  to have --disable-libgomp
>
> However, it is not disabled in BASE which reads
> EXTRA_OECONF_BASE = " --enable-lto \
> --enable-libssp \
> --disable-bootstrap \
> --disable-libmudflap \
> --with-system-zlib \
> --with-linker-hash-style=${LINKER_HASH_STYLE} \
> --enable-linker-build-id \
> --with-ppl=no \
> --with-cloog=no \
> --enable-checking=release \
> --enable-cheaders=c_global "
>
>
> Also, it is mentioned that 
>
> Autoconf will not detect OpenMP after this change, because it will
> build and run a target binary on the build system. In order to use
> OpenMP, the variable ac_cv_prog_c_openmp=-fopenmp must be set.
>
> Where exactly are we supposed to set this variable 
> ac_cv_prog_c_openmp=-fopenmp?
>
>
> You might have to add it to your image via IMAGE_INSTALL or some such
>
>
> Thanks
>
> Suresh
>
>
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] libgomp inclusion

[Suresh Nagarajan]

Hi,

I'm trying to look to see if OpenMP library is included in my yocto build.

I could not find libgomp library in /usr/lib
However, when I look at gcc-runtime.inc, I do notice that

RUNTIMETARGET = "libssp libstdc++-v3 libgomp"
PACKAGES = "\
  ${PN}-dbg \
  libstdc++ \
  libstdc++-precompile-dev \
  libstdc++-dev \
  libstdc++-staticdev \
  libg2c \
  libg2c-dev \
  libssp \
  libssp-dev \
  libssp-staticdev \
  libgfortran \
  libgfortran-dev \
  libgfortran-staticdev \
  libmudflap \
  libmudflap-dev \
  libmudflap-staticdev \
  libquadmath \
  libquadmath-dev \
  libquadmath-staticdev \
  libgomp \
  libgomp-dev \
  libgomp-staticdev \


Also, I noticed that in gmane and other web-pages that it is OK to have
INTIAL/INTERMEDIATE EXTRA_OECONF  to have --disable-libgomp

However, it is not disabled in BASE which reads
EXTRA_OECONF_BASE = " --enable-lto \
--enable-libssp \
--disable-bootstrap \
--disable-libmudflap \
--with-system-zlib \
--with-linker-hash-style=${LINKER_HASH_STYLE} \
--enable-linker-build-id \
--with-ppl=no \
--with-cloog=no \
--enable-checking=release \
--enable-cheaders=c_global "


Also, it is mentioned that 

Autoconf will not detect OpenMP after this change, because it will
build and run a target binary on the build system. In order to use
OpenMP, the variable ac_cv_prog_c_openmp=-fopenmp must be set.

Where exactly are we supposed to set this variable ac_cv_prog_c_openmp=-fopenmp?


Thanks

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

Re: [yocto] [meta-raspberrypi] meta-ivi & meta-raspberrypi

[Alex J Lennon]

On 29/04/2015 16:34, Mauro Carvalho Chehab wrote:
> Em Wed, 29 Apr 2015 16:05:58 +0200
> Alex J Lennon  escreveu:
>
>> On 29/04/2015 15:30, Oliver wrote:
>>> Hello
>>>
>>> I have been working building together the meta-raspberrypi & the meta-ivi 
>>> layers.
>>> I have been stuck with configuration/compilation of weston(from mata-ivi 
>>> layer):
>>>
>>> 1)
>>>
>>> You can check the intial thread 
>>> http://lists.genivi.org/pipermail/genivi-meta-ivi/2015-April/000508.html
>>>
>>>
>>> egl provided by userlad is not detected as the *.pc files are not deployed
>>> Someone has faced similar problems:
>>>
>>>
>>> http://git.buildroot.net/buildroot/commit/?id=2282b93f4248a32de84805456efa352f69b28624
>>>
>>> 2)
>>> With this I am able to reach the do_compile stage but there are errors 
>>> related to the undefined type
>>>
>>> PFNEGLQUERYWAYLANDBUFFERWL
>>> Hacked this one forcing the inclusion of  :-S
>>>
>>>
>>> 3)
>>> At linking time the next trouble is:
>>>
>>> /home/oliver/raspberry/build-rpi-ivi/tmp/sysroots/i686-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.1/ld:
>>>  cannot find -lwayland-egl
>>>
>>> IIRC this lib is provided by mesa-gl, but in my build, mesa is 
>>> configured(--disable-egl (is this ok being provided by userlad?)) which 
>>> might be the reason why libwayland-egl is not getting deployed in the image?
>>>
>>> Any correction to my statements or hint to go further would be appreciated
>>>
>>> Best Regards & thanks for your time
>>>
>>> Oliver
>> Hi Oliver,
>>
>> I was looking at wayland/weston last year.  I can't remember exactly
>> where I was at with it I am afraid, but I think I had it building and
>> have pushed some of the code I was playing with to GitHub
>>
>> I think this was related to the .pc issue
>>
>> https://github.com/DynamicDevices/meta-raspberrypi/commit/491dd14585efdb52378a57fa6ddacb1f15065257
>>
>> And this was what I was doing with weston. Looks like I was disabling EGL.
>>
>> https://github.com/DynamicDevices/meta-raspberrypi/commit/c657f69deb57035fc43319dd7d41745c17d7d6e1
>>
>> Sorry I can't be more help but perhaps there's something in there that
>> might be of use.
> I was able to build weston/wayland with meta-raspberrypi, for
> the Tizen distro:
>   http://blogs.s-osg.org/bringing-tizen-to-a-raspberry-pi-2-near-you/
>
> I had to apply a few patches to make it work on both Tizen and
> meta-raspberrypi. The forks are at:
>   http://git.s-osg.org/
>
> The current version there is actually disabling EGL. Enabling
> it seems to be possible, but we're still trying to make it work
> (it compiles fine, though, so I think we're close).
>
> Once done, my plan is to work on porting the patches back to
> meta-raspberrypi (and tizen-distro).
>
>

Great news Mauro. If you need anybody to test out your patches, when
ready, please give me a shout.

Cheers, Alex

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

[yocto] Eclipse build of existing cmake project

[Ruben Schwarz]

Hi everybody,

What I did:
I built an image and support for eclipse (meta-ide-support) for beagle bone
black (BBB).
I am able to create a new project in eclipse and build and run this new
project on my hardware.

I have an existing CMAKE project which should run on BBB.
I know how to write an recipe for my project and build this existing
project with bitbake.

What I want to do:
I want to build my existing cmake project with eclipse. Is there any
possibility to import existing cmake projects to eclipse and do a build
using yocto toolchain?

Best regards
Ruben

-- 
Ruben Schwarz | SOTEC | r.schw...@sotec.eu | T +49 7033 5458 34 | F +49
7033 5458 95

-- 


www.sotec.eu | www.cloudwuerdig.com 
-- 
SOTEC Software Entwicklungs GmbH + Co Mikrocomputertechnik KG 
Calwer Straße 11, D-75395 Ostelsheim 
Sitz Ostelsheim, Amtsgericht Stuttgart HRA 330821/HRB 330664, 
Geschäftsführer: Florian Holz 
Cloudwürdig® ist eine eingetragene Marke der SOTEC Software Entwicklungs 
GmbH + Co Mikrocomputertechnik KG

Der Inhalt dieser e-Mail ist ausschließlich für den bezeichneten Adressaten 
bestimmt. Wenn Sie nicht der vorgesehene Adressat dieser e-Mail oder dessen 
Vertreter sein sollten, so beachten Sie bitte, dass jede Form der 
Kenntnisnahme, Veröffentlichung, Vervielfältigung oder Weitergabe des 
Inhalts dieser e-Mail unzulässig ist. Wir bitten Sie, sich in diesem Fall 
mit dem Absender der e-Mail in Verbindung zu setzen.

The content of this e-mail is meant exclusively for the person to whom it 
is addressed. If you are not the person to whom this e-mail is addressed or 
his/her representative, please be informed, that any form of knowledge, 
publication, duplication or distribution of the content of this e-mail is 
inadmissible. We ask you, therefore, in such a case to please contact the 
sender of this e-mail.

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

Re: [yocto] Heads up

[Robert P. J. Day]

On Wed, 29 Apr 2015, Gary Thomas wrote:

> This is just a note that the recent upgrade of util-linux
> to version 2.26.1 (from 2.25.2) was much more major than
> the version change implies.  The 'sfdisk' tool changed a
> lot and will no longer be compatible with many scripts out
> there that still use it.

  i remember mentioning this on the beagleboard ML back in january:

https://www.mail-archive.com/beagleboard@googlegroups.com/msg23943.html

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] Heads up

[Gary Thomas]

This is just a note that the recent upgrade of util-linux
to version 2.26.1 (from 2.25.2) was much more major than
the version change implies.  The 'sfdisk' tool changed a
lot and will no longer be compatible with many scripts out
there that still use it.

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [yocto] Migration from 1.7.1 to 1.8 - kernel-abiversion missing

[Carl van Schaik]

I've just encountered the exact same issue upgrading. 

> Have you tried setting linux-dummy as the preferred provider for the kernel ? 
> >That would skip the build processing doing anything more than satisfying the 
> various kernel dependencies.

We do explicitly set preferred provider to linux-dummy, in our layer.

STAGING_KERNEL_builddir=./armv7/kernel-build-artifacts-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-raspberrypi] meta-ivi & meta-raspberrypi

[Alex J Lennon]

On 29/04/2015 15:30, Oliver wrote:
> Hello
>
> I have been working building together the meta-raspberrypi & the meta-ivi 
> layers.
> I have been stuck with configuration/compilation of weston(from mata-ivi 
> layer):
>
> 1)
>
> You can check the intial thread 
> http://lists.genivi.org/pipermail/genivi-meta-ivi/2015-April/000508.html
>
>
> egl provided by userlad is not detected as the *.pc files are not deployed
> Someone has faced similar problems:
>
>
> http://git.buildroot.net/buildroot/commit/?id=2282b93f4248a32de84805456efa352f69b28624
>
> 2)
> With this I am able to reach the do_compile stage but there are errors 
> related to the undefined type
>
> PFNEGLQUERYWAYLANDBUFFERWL
> Hacked this one forcing the inclusion of  :-S
>
>
> 3)
> At linking time the next trouble is:
>
> /home/oliver/raspberry/build-rpi-ivi/tmp/sysroots/i686-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.1/ld:
>  cannot find -lwayland-egl
>
> IIRC this lib is provided by mesa-gl, but in my build, mesa is 
> configured(--disable-egl (is this ok being provided by userlad?)) which might 
> be the reason why libwayland-egl is not getting deployed in the image?
>
> Any correction to my statements or hint to go further would be appreciated
>
> Best Regards & thanks for your time
>
> Oliver

Hi Oliver,

I was looking at wayland/weston last year.  I can't remember exactly
where I was at with it I am afraid, but I think I had it building and
have pushed some of the code I was playing with to GitHub

I think this was related to the .pc issue

https://github.com/DynamicDevices/meta-raspberrypi/commit/491dd14585efdb52378a57fa6ddacb1f15065257

And this was what I was doing with weston. Looks like I was disabling EGL.

https://github.com/DynamicDevices/meta-raspberrypi/commit/c657f69deb57035fc43319dd7d41745c17d7d6e1

Sorry I can't be more help but perhaps there's something in there that
might be of use.

Regards,

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

Re: [yocto] Yocto linux-kernel

[nick]

On 2015-04-29 09:20 AM, Bruce Ashfield wrote:
> On 04/29/2015 08:38 AM, Parthiban Kandasamy wrote:
>> i am using beagleboard-xm like board for my custom use. for my
>> development i am using yocto-dora-1.5 as bsp and kernel-2.6.32(i
>> downgraded).
>>   while bitbaking kernel, i got error as follows:
>>
>> Log data follows:
>> | DEBUG: Executing shell function do_kernel_checkout
>> | Reinitialized existing Git repository in
>> /home/parthiban/UliveSytems/Parthiban/CODE/OpenSource/BSP/beagleboard-dora-10.0.0/BeagleBuild/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto/2.6.32-r0/linux-2.6.32/.git/
>> | On branch standard/base
>> | nothing to commit, working directory clean
>> | ERROR. The branch 'meta' is required and was not
>> | found. Ensure that the SRC_URI points to a valid linux-yocto
>> | kernel repository
>> | WARNING:
>> /home/parthiban/UliveSytems/Parthiban/CODE/OpenSource/BSP/beagleboard-dora-10.0.0/BeagleBuild/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto/2.6.32-r0/temp/run.do_kernel_checkout.32588:1
>> exit 1 from
>> |   exit 1
>> | ERROR: Function failed: do_kernel_checkout (log file is located at
>> /home/parthiban/UliveSytems/Parthiban/CODE/OpenSource/BSP/beagleboard-dora-10.0.0/BeagleBuild/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto/2.6.32-r0/temp/log.do_kernel_checkout.32588)
>>
>> due to this error i thought error can be cleared if kernel fetched from
>> yocto git repository, but i cat get from there,  so how do i get
>> kernel-2.6.32 for yocto project.
> 
> There isn't a released 2.6.32 linux-yocto version, so if you
> really want that old version, you'd need to create a linux-yocto-custom
> recipe for the version (unless that is what you already did).
> 
> Bruce
> 
>>
>> -- 
>> thanks and regards,
>> parthiban
>>+919790329795
>>
>>
> 
The only reason to use such a old kernel is for one of two reasons in my 
experience either 
it's on custom hardware and written by a vendor supporting that hardware or 
people want to
run a long term supported kernel. I am wondering of the two which one are you 
under Parthiban.
Nick
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-raspberrypi] meta-ivi & meta-raspberrypi

[Oliver]

Hello

I have been working building together the meta-raspberrypi & the meta-ivi 
layers.
I have been stuck with configuration/compilation of weston(from mata-ivi layer):

1)

You can check the intial thread 
http://lists.genivi.org/pipermail/genivi-meta-ivi/2015-April/000508.html


egl provided by userlad is not detected as the *.pc files are not deployed
Someone has faced similar problems:

   
http://git.buildroot.net/buildroot/commit/?id=2282b93f4248a32de84805456efa352f69b28624

2)
With this I am able to reach the do_compile stage but there are errors related 
to the undefined type

PFNEGLQUERYWAYLANDBUFFERWL
Hacked this one forcing the inclusion of  :-S


3)
At linking time the next trouble is:

/home/oliver/raspberry/build-rpi-ivi/tmp/sysroots/i686-linux/usr/libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.9.1/ld:
 cannot find -lwayland-egl

IIRC this lib is provided by mesa-gl, but in my build, mesa is 
configured(--disable-egl (is this ok being provided by userlad?)) which might 
be the reason why libwayland-egl is not getting deployed in the image?

Any correction to my statements or hint to go further would be appreciated

Best Regards & thanks for your time

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

Re: [yocto] Migration from 1.7.1 to 1.8 - kernel-abiversion missing

[Bruce Ashfield]

On 04/29/2015 03:38 AM, Schaumlöffel, Jan wrote:

Have you tried setting linux-dummy as the preferred provider for the kernel
? That would skip the build processing doing anything more than satisfying
the various kernel dependencies.


Ah, that's a good hint, I'll try that.




After your build has failed, if you look in STAGING_KERNEL_BUILDDIR
do you see the abiversion file ?


There are three instances of the file:

~/yocto-build-fido$ find . -name kernel-abiversion
./tmp/work/beaglebone-poky-linux-gnueabi/linux-

yocto/3.14.36+gitAUTOIN

C+162dfe3bb0_dbe5b52e93-r0/pkgdata/kernel-depmod/kernel-abiversion
./tmp/sysroots/beaglebone/pkgdata/kernel-depmod/kernel-abiversion
./tmp/work-shared/beaglebone/kernel-build-artifacts/kernel-abiversion


Those are where I'd expect them for 1.8, so they should be found and used
by the various parts of the build process. Something different is happening in
your build .. hmm.


It looks like those were from another run, built from scratch in a new 
directory I now see the following result:


NOTE: Executing RunQueue Tasks
ERROR: No kernel-abiversion file found 
(/home/astro/yocto-build-reproduce/tmp/sysroots/u159/pkgdata/kernel-depmod/kernel-abiversion),
 cannot run depmod, aborting
ERROR: Function failed: do_rootfs
ERROR: Logfile of failure stored in: 
/home/astro/yocto-build-reproduce/tmp/work/u159-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.7440
ERROR: Task 7 
(/home/astro/git/poky/meta/recipes-core/images/core-image-minimal.bb, 
do_rootfs) failed with exit code '1'
NOTE: Tasks Summary: Attempted 1776 tasks of which 93 didn't need to be rerun 
and 1 failed.
No currently running tasks (1775 of 1777)

Summary: 1 task failed:
   /home/astro/git/poky/meta/recipes-core/images/core-image-minimal.bb, 
do_rootfs
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
astro@eldk-vm:~/yocto-build-reproduce$ find . -name kernel-abiversion
astro@eldk-vm:~/yocto-build-reproduce$ bitbake -e core-image-minimal | grep 
STAGING_KERNEL_BUILDDIR
# $STAGING_KERNEL_BUILDDIR
STAGING_KERNEL_BUILDDIR="/home/astro/yocto-build-reproduce/tmp/work-shared/u159/kernel-build-artifacts"
astro@eldk-vm:~/yocto-build-reproduce$ ls -la 
/home/astro/yocto-build-reproduce/tmp/work-shared/u159/kernel-build-artifacts
ls: cannot access 
/home/astro/yocto-build-reproduce/tmp/work-shared/u159/kernel-build-artifacts: 
No such file or directory
astro@eldk-vm:~/yocto-build-reproduce$

It looks like the entire STAGING_KERNEL_BUILDDIR is missing.


I'll try some more variatons of my setup to try and narrow down why that 
happens.



That is really odd. I'll be interested to hear how that happened. I just
did a test and it points to where I expect:

 [/home/bruc...poky/build]> bitbake -e core-image-minimal | grep 
STAGING_KERNEL_BUILDDIR

# $STAGING_KERNEL_BUILDDIR
STAGING_KERNEL_BUILDDIR="/home/bruce/poky/build/tmp/work-shared/qemux86-64/kernel-build-artifacts"

Bruce




Jan



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

Re: [yocto] Yocto linux-kernel

[Bruce Ashfield]

On 04/29/2015 08:38 AM, Parthiban Kandasamy wrote:

i am using beagleboard-xm like board for my custom use. for my
development i am using yocto-dora-1.5 as bsp and kernel-2.6.32(i
downgraded).
  while bitbaking kernel, i got error as follows:

Log data follows:
| DEBUG: Executing shell function do_kernel_checkout
| Reinitialized existing Git repository in
/home/parthiban/UliveSytems/Parthiban/CODE/OpenSource/BSP/beagleboard-dora-10.0.0/BeagleBuild/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto/2.6.32-r0/linux-2.6.32/.git/
| On branch standard/base
| nothing to commit, working directory clean
| ERROR. The branch 'meta' is required and was not
| found. Ensure that the SRC_URI points to a valid linux-yocto
| kernel repository
| WARNING:
/home/parthiban/UliveSytems/Parthiban/CODE/OpenSource/BSP/beagleboard-dora-10.0.0/BeagleBuild/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto/2.6.32-r0/temp/run.do_kernel_checkout.32588:1
exit 1 from
|   exit 1
| ERROR: Function failed: do_kernel_checkout (log file is located at
/home/parthiban/UliveSytems/Parthiban/CODE/OpenSource/BSP/beagleboard-dora-10.0.0/BeagleBuild/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto/2.6.32-r0/temp/log.do_kernel_checkout.32588)

due to this error i thought error can be cleared if kernel fetched from
yocto git repository, but i cat get from there,  so how do i get
kernel-2.6.32 for yocto project.


There isn't a released 2.6.32 linux-yocto version, so if you
really want that old version, you'd need to create a linux-yocto-custom
recipe for the version (unless that is what you already did).

Bruce



--
thanks and regards,
parthiban
   +919790329795




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

Re: [yocto] Yocto linux-kernel

[Gary Thomas]

On 2015-04-29 07:11, Parthiban Kandasamy wrote:

our previous development was in kernel-2.6.32, so we do not like change the 
kernel level specification for new project because i/o interfaces is like 
previous project and we are
upgrading only processor card only, so we like to go on same kernel.


Please keep your replies on the mailing list so that all may benefit.

It's understandable that you would want to keep with familiar versions
but 2.6.32 dates from 2009, many years before the BeagleBoard was even
created.  It is unlikely that a kernel from that period would run on
that board.  Also, much of the Yocto infrastructure (e.g. udev) relies
on much newer kernels to function properly.

If you want to use newer hardware, you are inevitably going to need
the newer software that goes with it.



On 29 April 2015 at 18:13, Gary Thomas mailto:g...@mlbassoc.com>> wrote:

On 2015-04-29 06:38, Parthiban Kandasamy wrote:

i am using beagleboard-xm like board for my custom use. for my 
development i am using yocto-dora-1.5 as bsp and kernel-2.6.32(i downgraded).
   while bitbaking kernel, i got error as follows:

Log data follows:
| DEBUG: Executing shell function do_kernel_checkout
| Reinitialized existing Git repository in

/home/parthiban/UliveSytems/Parthiban/CODE/OpenSource/BSP/beagleboard-dora-10.0.0/BeagleBuild/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto/2.6.32-r0/linux-2.6.32/.git/
| On branch standard/base
| nothing to commit, working directory clean
| ERROR. The branch 'meta' is required and was not
| found. Ensure that the SRC_URI points to a valid linux-yocto
| kernel repository
| WARNING:

/home/parthiban/UliveSytems/Parthiban/CODE/OpenSource/BSP/beagleboard-dora-10.0.0/BeagleBuild/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto/2.6.32-r0/temp/run.do_kernel_checkout.32588:1
exit 1 from
|   exit 1
| ERROR: Function failed: do_kernel_checkout (log file is located at

/home/parthiban/UliveSytems/Parthiban/CODE/OpenSource/BSP/beagleboard-dora-10.0.0/BeagleBuild/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto/2.6.32-r0/temp/log.do_kernel_checkout.32588)

due to this error i thought error can be cleared if kernel fetched from 
yocto git repository, but i cat get from there,  so how do i get kernel-2.6.32 
for yocto project.


Why would you want such an old kernel for that board?

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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




--
thanks and regards,
parthiban
   +919790329795


--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

Re: [yocto] Yocto linux-kernel

[Gary Thomas]

On 2015-04-29 06:38, Parthiban Kandasamy wrote:

i am using beagleboard-xm like board for my custom use. for my development i am 
using yocto-dora-1.5 as bsp and kernel-2.6.32(i downgraded).
  while bitbaking kernel, i got error as follows:

Log data follows:
| DEBUG: Executing shell function do_kernel_checkout
| Reinitialized existing Git repository in
/home/parthiban/UliveSytems/Parthiban/CODE/OpenSource/BSP/beagleboard-dora-10.0.0/BeagleBuild/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto/2.6.32-r0/linux-2.6.32/.git/
| On branch standard/base
| nothing to commit, working directory clean
| ERROR. The branch 'meta' is required and was not
| found. Ensure that the SRC_URI points to a valid linux-yocto
| kernel repository
| WARNING:
/home/parthiban/UliveSytems/Parthiban/CODE/OpenSource/BSP/beagleboard-dora-10.0.0/BeagleBuild/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto/2.6.32-r0/temp/run.do_kernel_checkout.32588:1
exit 1 from
|   exit 1
| ERROR: Function failed: do_kernel_checkout (log file is located at
/home/parthiban/UliveSytems/Parthiban/CODE/OpenSource/BSP/beagleboard-dora-10.0.0/BeagleBuild/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto/2.6.32-r0/temp/log.do_kernel_checkout.32588)

due to this error i thought error can be cleared if kernel fetched from yocto 
git repository, but i cat get from there,  so how do i get kernel-2.6.32 for 
yocto project.


Why would you want such an old kernel for that board?

--

Gary Thomas |  Consulting for the
MLB Associates  |Embedded world

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

[yocto] Yocto linux-kernel

[Parthiban Kandasamy]

i am using beagleboard-xm like board for my custom use. for my development
i am using yocto-dora-1.5 as bsp and kernel-2.6.32(i downgraded).
 while bitbaking kernel, i got error as follows:

Log data follows:
| DEBUG: Executing shell function do_kernel_checkout
| Reinitialized existing Git repository in
/home/parthiban/UliveSytems/Parthiban/CODE/OpenSource/BSP/beagleboard-dora-10.0.0/BeagleBuild/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto/2.6.32-r0/linux-2.6.32/.git/
| On branch standard/base
| nothing to commit, working directory clean
| ERROR. The branch 'meta' is required and was not
| found. Ensure that the SRC_URI points to a valid linux-yocto
| kernel repository
| WARNING:
/home/parthiban/UliveSytems/Parthiban/CODE/OpenSource/BSP/beagleboard-dora-10.0.0/BeagleBuild/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto/2.6.32-r0/temp/run.do_kernel_checkout.32588:1
exit 1 from
|   exit 1
| ERROR: Function failed: do_kernel_checkout (log file is located at
/home/parthiban/UliveSytems/Parthiban/CODE/OpenSource/BSP/beagleboard-dora-10.0.0/BeagleBuild/tmp/work/beagleboard-poky-linux-gnueabi/linux-yocto/2.6.32-r0/temp/log.do_kernel_checkout.32588)

due to this error i thought error can be cleared if kernel fetched from
yocto git repository, but i cat get from there,  so how do i get
kernel-2.6.32 for yocto project.

-- 
thanks and regards,
parthiban
  +919790329795
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Definition of native toolchain, support for -m32?

[Alex J Lennon]

Hi,

I'm having some trouble building chromium which I think is due to a
definition in chromium.inc which uses the host compiler rather than the
Yocto native compile toolchain

CC_host="${BUILD_CC}" export CC_host
CXX_host="${BUILD_CXX}" export CXX_host

This seems to map to the gcc/g++ on my host system which is surely
incorrect?

Am I right in thinking that the correct way to define the Yocto native
toolchain is using something more like this from native.bbclass?

CC_host="${CCACHE}${HOST_PREFIX}gcc ${HOST_CC_ARCH}" export CC_host
CXX_host="${CCACHE}${HOST_PREFIX}g++ ${HOST_CC_ARCH}" export CXX_host

If I do this to eliminate the external dependency I run into a problem
that -m32 is not accepted by the Yocto compiler toolchain (which is
built/running on an x64 Ubuntu 14.04).

Could anybody advise on what steps I might take to have the Yocto native
compile toolchain accepting -m32?

Thanks,

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

Re: [yocto] Migration from 1.7.1 to 1.8 - kernel-abiversion missing

[Schaumlöffel , Jan]

> Have you tried setting linux-dummy as the preferred provider for the kernel
> ? That would skip the build processing doing anything more than satisfying
> the various kernel dependencies.

Ah, that's a good hint, I'll try that.

> >
> >> After your build has failed, if you look in STAGING_KERNEL_BUILDDIR
> >> do you see the abiversion file ?
> >
> > There are three instances of the file:
> >
> > ~/yocto-build-fido$ find . -name kernel-abiversion
> > ./tmp/work/beaglebone-poky-linux-gnueabi/linux-
> yocto/3.14.36+gitAUTOIN
> > C+162dfe3bb0_dbe5b52e93-r0/pkgdata/kernel-depmod/kernel-abiversion
> > ./tmp/sysroots/beaglebone/pkgdata/kernel-depmod/kernel-abiversion
> > ./tmp/work-shared/beaglebone/kernel-build-artifacts/kernel-abiversion
> 
> Those are where I'd expect them for 1.8, so they should be found and used
> by the various parts of the build process. Something different is happening in
> your build .. hmm.

It looks like those were from another run, built from scratch in a new 
directory I now see the following result:


NOTE: Executing RunQueue Tasks
ERROR: No kernel-abiversion file found 
(/home/astro/yocto-build-reproduce/tmp/sysroots/u159/pkgdata/kernel-depmod/kernel-abiversion),
 cannot run depmod, aborting
ERROR: Function failed: do_rootfs
ERROR: Logfile of failure stored in: 
/home/astro/yocto-build-reproduce/tmp/work/u159-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.7440
ERROR: Task 7 
(/home/astro/git/poky/meta/recipes-core/images/core-image-minimal.bb, 
do_rootfs) failed with exit code '1'
NOTE: Tasks Summary: Attempted 1776 tasks of which 93 didn't need to be rerun 
and 1 failed.
No currently running tasks (1775 of 1777)

Summary: 1 task failed:
  /home/astro/git/poky/meta/recipes-core/images/core-image-minimal.bb, do_rootfs
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
astro@eldk-vm:~/yocto-build-reproduce$ find . -name kernel-abiversion
astro@eldk-vm:~/yocto-build-reproduce$ bitbake -e core-image-minimal | grep 
STAGING_KERNEL_BUILDDIR
# $STAGING_KERNEL_BUILDDIR
STAGING_KERNEL_BUILDDIR="/home/astro/yocto-build-reproduce/tmp/work-shared/u159/kernel-build-artifacts"
astro@eldk-vm:~/yocto-build-reproduce$ ls -la 
/home/astro/yocto-build-reproduce/tmp/work-shared/u159/kernel-build-artifacts
ls: cannot access 
/home/astro/yocto-build-reproduce/tmp/work-shared/u159/kernel-build-artifacts: 
No such file or directory
astro@eldk-vm:~/yocto-build-reproduce$

It looks like the entire STAGING_KERNEL_BUILDDIR is missing.


I'll try some more variatons of my setup to try and narrow down why that 
happens.

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

[yocto] initramfs-framework ERROR: There's no '/dev' on rootfs.

[Craig McQueen]

I'm trying to use initramfs-framework to mount an overlayfs, and I've got it 
working mostly. However, I found that when it boots, I get an error:

ERROR: There's no '/dev' on rootfs.

That comes from initramfs-framework's 'finish' script. I got around it by 
creating the /dev directory on my writable partition. I also created /proc and 
/sys since it looks as though those would be needed too.

Would it be better to change the 'finish' script to just create the required 
directory(s)? E.g.:

-   if [ ! -d $ROOTFS_DIR/dev ]; then
-   fatal "ERROR: There's no '/dev' on rootfs."
-   fi
+   mkdir -p $ROOTFS_DIR/dev
+   mkdir -p $ROOTFS_DIR/proc
+   mkdir -p $ROOTFS_DIR/sys

-- 
Craig McQueen

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