[yocto] Screencast Video: Getting Started with the Yocto Project
Hi everyone, I am excited to announce a video training resource for new users of the Yocto Project. It is the "Getting Started with the Yocto Project" screencast: On Vimeo: http://vimeo.com/36450321 On YouTube: http://www.youtube.com/watch?v=zNLYanJAQ3s Direct download, Windows Media (300 MB) and Ogg (500 MB) formats: http://www.yoctoproject.org/bulk/Getting_Started_with_the_Yocto_Project.wmv http://www.yoctoproject.org/bulk/Getting_Started_with_the_Yocto_Project.ogv This half-hour screencast introduces you to the Yocto Project and explains its benefits. It also includes live demos which explain the following: * An overview of the Poky build system * How the Poky sources are organized (types of metadata and where to find it) * How to build your first Linux image and run it under emulation * An introduction to recipes and an explanation of the most common types of metadata, using actual recipe examples * An introduction to layers * Where to obtain Yocto BSPs from * How simple it is to download and enable a Yocto BSP * Where to find further project resources (documentation, mailing list, git repository, bugzilla) By the end of this screencast, a new user will understand fundamental concepts about the build system, and be able to start their exploration of the Yocto Project with a solid foundation of knowledge. I hope this screencast becomes a useful training resource to help get new users up to speed as quickly as possible with the Yocto Project. Enjoy, Scott -- Scott Garman Embedded Linux Engineer - Yocto Project Intel Open Source Technology Center ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] trouble using a local kernel repo
On 12-02-17 11:45 AM, Hollis Blanchard wrote: On 02/16/2012 03:02 PM, Bruce Ashfield wrote: That's the problem. I have a patch that detects this and abort is a non bare upstream is used. I just need to send them .. which I'll do when I get back to my desk next week. There are two reason for this bare clone requirement: - technical: this scales to several hundred branches. cloning, and iterating remote branches to create local tracking branches is noisy and time consuming. So there's a trick that has been in use for years that you can clone a bare upstream, and mass convert the branches to local in a single operation. - social: you want to do your development in a different tree from the one that is being cloned and used. That way the tree is clean, and you are building what you expect. One more workflow question: so to test my patch, I need to commit it to my real git repo, then push to the bare git repo, then rebuild Poky. When I find the inevitable problem, do I need to manually delete (git reset --hard) the changeset from both repositories? Is there a better way? As with anything git based ... there's more than one way to do it, and everyone has their favourite way. Me, I'd just revert it and push it. Or hard reset it in the working repo and push -f to the bare one. But generally speaking, you've got the right way. Same as you'd have to pull it off a SRC_URI or remove a bbappend if it was tacked on the end via that method. Cheers, Bruce Hollis Blanchard Mentor Graphics, Embedded Systems Division ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] pseudo interaction issue
We're looking into this issue. You should never get the "pseudo: You must set
the PSEUDO_PREFIX environment variable to run pseudo." message. This means
something appears to have avoided the wrappers.
I'll let you know once we figure out something.
--Mark
On 2/17/12 9:35 AM, Paul Eggleton wrote:
Hi all,
I'm trying to extend buildhistory to write out the metadata revisions just
before it does the commit to the buildhistory repository, and I'm having some
pseudo-related trouble. The structure is a little unusual, in that the
execution flow is an event handler that calls a shell function (via
bb.build.exec_func()) and during parsing this function an ${@...} reference to
a python function is evaluated, which then calls os.popen(), at which point I
get the error "pseudo: You must set the PSEUDO_PREFIX environment variable to
run pseudo."
I don't need pseudo at this stage. I've tried setting PSEUDO_DISABLED=1 and
even PSEUDO_UNLOAD=1 just prior to the os.popen() call (or within it) and
despite evidence that pseudo is taking notice of these being set in other
contexts (when the function is called from elsewhere) even when doing this I
still get the error above. I could rearrange the structure to avoid this
execution flow however that would bar me from reusing existing code that we
have for getting the metadata revision.
Any suggestions?
Cheers,
Paul
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] pseudo interaction issue
Hi all,
I'm trying to extend buildhistory to write out the metadata revisions just
before it does the commit to the buildhistory repository, and I'm having some
pseudo-related trouble. The structure is a little unusual, in that the
execution flow is an event handler that calls a shell function (via
bb.build.exec_func()) and during parsing this function an ${@...} reference to
a python function is evaluated, which then calls os.popen(), at which point I
get the error "pseudo: You must set the PSEUDO_PREFIX environment variable to
run pseudo."
I don't need pseudo at this stage. I've tried setting PSEUDO_DISABLED=1 and
even PSEUDO_UNLOAD=1 just prior to the os.popen() call (or within it) and
despite evidence that pseudo is taking notice of these being set in other
contexts (when the function is called from elsewhere) even when doing this I
still get the error above. I could rearrange the structure to avoid this
execution flow however that would bar me from reusing existing code that we
have for getting the metadata revision.
Any suggestions?
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] trouble using a local kernel repo
On 02/16/2012 03:02 PM, Bruce Ashfield wrote: That's the problem. I have a patch that detects this and abort is a non bare upstream is used. I just need to send them .. which I'll do when I get back to my desk next week. There are two reason for this bare clone requirement: - technical: this scales to several hundred branches. cloning, and iterating remote branches to create local tracking branches is noisy and time consuming. So there's a trick that has been in use for years that you can clone a bare upstream, and mass convert the branches to local in a single operation. - social: you want to do your development in a different tree from the one that is being cloned and used. That way the tree is clean, and you are building what you expect. One more workflow question: so to test my patch, I need to commit it to my real git repo, then push to the bare git repo, then rebuild Poky. When I find the inevitable problem, do I need to manually delete (git reset --hard) the changeset from both repositories? Is there a better way? Hollis Blanchard Mentor Graphics, Embedded Systems Division ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] unable to add a new file to base-files recipe via bbappend
Hello Martin,
On Fri, 2012-02-17 at 15:45 +0100, Martin Jansa wrote:
> You need to set something like
> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> for fetcher to look in ${PN} subdirectory of directory where
> you have .bbappend
Thanks for the info.
> And you're bbappending wrong recipe, xorg.conf belongs to
> meta/recipes-graphics/xorg-xserver/xserver-xf86-config/
Oops. Will bbappend to the above mentioned recipe.
Regards
Joshua
--
Joshua Immanuel
HiPro IT Solutions Private Limited
http://hipro.co.in
signature.asc
Description: This is a digitally signed message part
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] unable to add a new file to base-files recipe via bbappend
On Fri, Feb 17, 2012 at 08:10:48PM +0530, Joshua Immanuel wrote:
> Hello all,
> I added a base-files_3.0.14.bbappend file in my custom layer and
> pointed the SRC_URI as follows
>
> SRC_URI += "file://xorg.conf"
>
> The xorg.conf file is at "base-files/files/xorg.conf" on my custom
> layer. But, the bitbake fails to find the file.
>
> > | ERROR: Function 'Fetcher failure for URL: 'file://xorg.conf'.
> > Unable to fetch URL file://xorg.conf from any source.' failed
>
> I guess, the method that I am following here to add a new source file
> via the bbappend is wrong.
You need to set something like
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
for fetcher to look in ${PN} subdirectory of directory where
you have .bbappend
And you're bbappending wrong recipe, xorg.conf belongs to
meta/recipes-graphics/xorg-xserver/xserver-xf86-config/
Cheers,
>
> Please guide me.
>
> Regards
> Joshua
> --
> Joshua Immanuel
> HiPro IT Solutions Private Limited
> http://hipro.co.in
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
--
Martin 'JaMa' Jansa jabber: martin.ja...@gmail.com
signature.asc
Description: Digital signature
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] unable to add a new file to base-files recipe via bbappend
Hello all, I added a base-files_3.0.14.bbappend file in my custom layer and pointed the SRC_URI as follows SRC_URI += "file://xorg.conf" The xorg.conf file is at "base-files/files/xorg.conf" on my custom layer. But, the bitbake fails to find the file. > | ERROR: Function 'Fetcher failure for URL: 'file://xorg.conf'. > Unable to fetch URL file://xorg.conf from any source.' failed I guess, the method that I am following here to add a new source file via the bbappend is wrong. Please guide me. Regards Joshua -- Joshua Immanuel HiPro IT Solutions Private Limited http://hipro.co.in signature.asc Description: This is a digitally signed message part ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Perl build failure
Hi, I'm attempting to build the head of the master branch, targeting core-image-minimal on qemux86 with an up to date Ubuntu 10.04 32-bit system. I am getting the following error from perl: /home/welchma/Documents/linux/yocto/yocto_head/build/tmp/work/i586-poky-linux/perl-5.14.2-r2/perl-5.14.2/Cross/generate_config_sh config.sh-x86-linux > /home/welchma/Documents/linux/yocto/yocto_head/build/tmp/work/i586-poky-linux/perl-5.14.2-r2/perl-5.14.2/Cross/../config.sh Unable to open config.sh-x86-linux at /home/welchma/Documents/linux/yocto/yocto_head/build/tmp/work/i586-poky-linux/perl-5.14.2-r2/perl-5.14.2/Cross/generate_config_sh line 47. make: *** [perl] Error 2 looking in the "Cross" folder there is no config.sh-x86-linux, there is however a config.sh-i586-linux. Looking into the Makefile that seems to be run I see: $(TOPDIR)/generate_config_sh config.sh-$(SYS) > $(TOPDIR)/../config.sh where: export SYS=$(ARCH)-$(OS) The run.do_compile script has: export ARCH="x86" Which I guess explains why it's getting that value. Looking at the perl recipe, the do_configure stage creates a config file and I can see that this exists in build dir and that contains what I believe are the required values: ARCH = i586 OS = linux However this doesn't seem to be explicitly referenced by do_compile and doesn't seem to be referenced by generate_config_sh. Any ideas? Martyn -- Martyn Welch (Lead Software Engineer) | Registered in England and Wales GE Intelligent Platforms | (3828642) at 100 Barbirolli Square T +44(0)1327322748 | Manchester, M2 3AB E martyn.we...@ge.com | VAT:GB 927559189 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] The sysroot location in eclipse plugin?
Ni Qingliang wrote on 2012-02-17: > thanks! another question: > why I must specify the sysroot location in eclipse plugin? the > environment-setup has it already. > In case you need another target sysroot which is different from the sysroot defined in the environment files. Best Regards, Lianhao ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] The sysroot location in eclipse plugin?
thanks! another question: why I must specify the sysroot location in eclipse plugin? the environment-setup has it already. On Fri, 2012-02-17 at 15:49 +0800, Lu, Lianhao wrote: > Ni Qingliang wrote on 2012-02-17: > > the environment-setup file in build tree had defined CFLAGS and CXXFLAGS > > which include the sysroot argument(/tmp/sysroots/). > > > > Do we must specify the sysroot location in the eclipse plugin? > > > > after specify it, I found the CFLAGS CXXFLAGS in project property follow > > it, and dropped the sysroot defined in environment-setup file. > > > > and I have another sysroot running on target (qemu) unzipped from the > > image. > > > > If I specify the target sysroot in eclipse-plugin, I can't compile my > > code, because there is no any header file in /usr/include. > > If I specify the /tmp/sysroots/, I can't running > > the qemu machine in eclipse, because there is no 'init'. > > > The eclipse-plugin by default assumes the user using the same target sysroot > for both cross compiling and qemu launching. So this requires the target > sysroot having the libraries and header files. > > You might have 2 options here: > 1. build a new image with the "dev-pkgs" image feature(you can set that in > conf/local.conf in variable EXTRA_IMAGE_FEATURES) and use that image as > target sysroot in eclipse. > > 2. launch the qemu in console terminal, out of eclipse, using a different > target sysroot. > > Best Regards, > Lianhao > > -- Yi Qingliang niqingli...@insigma.com.cn https://niqingliang2003.wordpress.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
