Re: [yocto] SOLVED: How to get mkfs.ext4 in rootfs package
Hi Gaurang, On Jun 11, 2013, at 10:47 PM, Gaurang Shastri gmshas...@gmail.commailto:gmshas...@gmail.com wrote: Can you try with IMAGE_INSTALL_append = e2fsprogs and run once again bitbake core-image-minimal or whatever you are referring for your final target The 'e2fsprogs' target adds libs, but not the executables. I needed to add 'e2fsprogs-mke2fs' to get what I wanted. regards, Ben //Gaurang Shastri On Wed, Jun 12, 2013 at 1:06 AM, Ben Warren ben.war...@spidercloud.commailto:ben.war...@spidercloud.com wrote: Sorry for the spam. Still learning how this works… Turns out I needed 'e2fsprogs-mke2fs' regards, Ben On Jun 11, 2013, at 10:51 AM, Ben Warren ben.war...@spidercloud.commailto:ben.war...@spidercloud.com wrote: Hi, I'm trying to get the 'mkfs.ext4' binary from e2fsprogs into my image, in particular the '.ext3' rootfs image, and am obviously missing something fundamental. I'm using a custom image based on (copy/pasted from) 'kvm_image_minimal', and have added 'e2fsprogs' to the IMAGE_INSTALL string in the image descriptor file. I see that the library is compiling and the binary is in tmp/sysroots: ben@ubuntu-scw:/opt/scw-appscard-build$ ls tmp/sysroots/x86_64-linux/sbin/mkfs.* tmp/sysroots/x86_64-linux/sbin/mkfs.ext2 tmp/sysroots/x86_64-linux/sbin/mkfs.ext4 tmp/sysroots/x86_64-linux/sbin/mkfs.minix tmp/sysroots/x86_64-linux/sbin/mkfs.ext3 tmp/sysroots/x86_64-linux/sbin/mkfs.ext4dev but it's not making it to the rootfs images. I've tried to read the documentation but still am not quite sure about what defines the contents of the rootfs images. thanks, Ben ___ yocto mailing list yocto@yoctoproject.orgmailto:yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] 1.4.1 rc1 available for testing
Folks We're going to respin this due to some autobuilder issues. I'll send out a mail in a bit to update you on the status/location. If you've begun testing, please stop and wait for this build. -b On Tue, Jun 11, 2013 at 6:15 PM, Flanagan, Elizabeth elizabeth.flana...@intel.com wrote: All, we've begun a spin of 1.4.1. This is the first release candidate. Unfortunately, a minor issue has occurred with the eclipse-plugin, so that will have to be rebuilt once the build run ends (as we may have to bring the buildbot slave down to fix it) The artifacts should be available in a few hours. Please begin testing as they are available. Location: http://autobuilder.yoctoproject.org/pub/nightly/20130611-2 meta-fsl-armd31a4e85673874dbc6b42bb5d1e8496810c574cc meta-fsl-ppc51252492cdda18eb3838b1c3108217a59243ba2a meta-intel 048def7bae8e3e1a11c91f5071f99bdcf8e6dd16 meta-minnow 0d428f867ffdf83dd35803c7318180751ddb096f meta-qt34c27cce6688aa39852f3cba5e7b80ec279019605 poky73f103bf9b2cdf985464dc53bf4f1cfd71d4531f I'll have the eclipse-plugin hash when we build it out. -b -- Elizabeth Flanagan Yocto Project Build and Release -- Elizabeth Flanagan Yocto Project Build and Release ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] 1.4.1 rc1 available for testing
Ok, we have the start of a build. The issue was due to not being able to checkout bitbake during the nightly-oecore build because we had set the branch to dylan (which doesn't exist). The new location (with what should be the same git hashes) is at: http://autobuilder.yoctoproject.org/pub/nightly/20130612-5 This should only take a few hours to build out, so please check back in about 3 hours as there should be a fair amount of artifacts to begin testing. -b On Tue, Jun 11, 2013 at 11:33 PM, Flanagan, Elizabeth elizabeth.flana...@intel.com wrote: Folks We're going to respin this due to some autobuilder issues. I'll send out a mail in a bit to update you on the status/location. If you've begun testing, please stop and wait for this build. -b On Tue, Jun 11, 2013 at 6:15 PM, Flanagan, Elizabeth elizabeth.flana...@intel.com wrote: All, we've begun a spin of 1.4.1. This is the first release candidate. Unfortunately, a minor issue has occurred with the eclipse-plugin, so that will have to be rebuilt once the build run ends (as we may have to bring the buildbot slave down to fix it) The artifacts should be available in a few hours. Please begin testing as they are available. Location: http://autobuilder.yoctoproject.org/pub/nightly/20130611-2 meta-fsl-armd31a4e85673874dbc6b42bb5d1e8496810c574cc meta-fsl-ppc51252492cdda18eb3838b1c3108217a59243ba2a meta-intel 048def7bae8e3e1a11c91f5071f99bdcf8e6dd16 meta-minnow 0d428f867ffdf83dd35803c7318180751ddb096f meta-qt34c27cce6688aa39852f3cba5e7b80ec279019605 poky73f103bf9b2cdf985464dc53bf4f1cfd71d4531f I'll have the eclipse-plugin hash when we build it out. -b -- Elizabeth Flanagan Yocto Project Build and Release -- Elizabeth Flanagan Yocto Project Build and Release -- Elizabeth Flanagan Yocto Project Build and Release ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] SOLVED: How to get mkfs.ext4 in rootfs package
Yes, as per e2fsprogs.bb file,
PACKAGES =+ e2fsprogs-e2fsck e2fsprogs-mke2fs e2fsprogs-tune2fs
e2fsprogs-badblocks
..
FILES_e2fsprogs-mke2fs = ${base_sbindir}/mke2fs
${base_sbindir}/mkfs.ext* ${sysconfdir}/mke2fs.conf
But finally you got what you want :)
//Gaurang Shastri
On Wed, Jun 12, 2013 at 11:40 AM, Ben Warren ben.war...@spidercloud.comwrote:
Hi Gaurang,
On Jun 11, 2013, at 10:47 PM, Gaurang Shastri gmshas...@gmail.com wrote:
Can you try with IMAGE_INSTALL_append = e2fsprogs and run once again
bitbake core-image-minimal or whatever you are referring for your final
target
The 'e2fsprogs' target adds libs, but not the executables. I needed to
add 'e2fsprogs-mke2fs' to get what I wanted.
regards,
Ben
//Gaurang Shastri
On Wed, Jun 12, 2013 at 1:06 AM, Ben Warren ben.war...@spidercloud.comwrote:
Sorry for the spam. Still learning how this works…
Turns out I needed 'e2fsprogs-mke2fs'
regards,
Ben
On Jun 11, 2013, at 10:51 AM, Ben Warren ben.war...@spidercloud.com
wrote:
Hi,
I'm trying to get the 'mkfs.ext4' binary from e2fsprogs into my image,
in particular the '.ext3' rootfs image, and am obviously missing something
fundamental.
I'm using a custom image based on (copy/pasted from)
'kvm_image_minimal', and have added 'e2fsprogs' to the IMAGE_INSTALL string
in the image descriptor file.
I see that the library is compiling and the binary is in tmp/sysroots:
ben@ubuntu-scw:/opt/scw-appscard-build$ ls
tmp/sysroots/x86_64-linux/sbin/mkfs.*
tmp/sysroots/x86_64-linux/sbin/mkfs.ext2
tmp/sysroots/x86_64-linux/sbin/mkfs.ext4
tmp/sysroots/x86_64-linux/sbin/mkfs.minix
tmp/sysroots/x86_64-linux/sbin/mkfs.ext3
tmp/sysroots/x86_64-linux/sbin/mkfs.ext4dev
but it's not making it to the rootfs images.
I've tried to read the documentation but still am not quite sure about
what defines the contents of the rootfs images.
thanks,
Ben
___
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] question about packagegroups
hello, i am creating a packagegroup to organize better my image/recipes. i am doing something along these lines: DESCRIPTION = My Custom Package Groups inherit packagegroup PACKAGES = \ packagegroup-custom-apps \ packagegroup-custom-tools \ RDEPENDS_packagegroup-custom-apps = \ dropbear \ portmap \ psplash RDEPENDS_packagegroup-custom-tools = \ oprofile \ oprofileui-server \ lttng-control \ lttng-viewer and in my imageA i am pulling *only* packagegroup-custom-tools with IMAGE_INSTALL. What I notice is that all packages listed in my packagegroup even the ones from packagegroup-custom-apps which isn't pulled in my image are built when building my image. Of course they are not installed, but why are they built? it is wasting a large amount of time, while it's not even needed. is that really expected or am i doing something wrong here? thanks nicolas ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] question about packagegroups
On 2013-06-12 09:08, Nicolas Dechesne wrote: hello, i am creating a packagegroup to organize better my image/recipes. i am doing something along these lines: DESCRIPTION = My Custom Package Groups inherit packagegroup PACKAGES = \ packagegroup-custom-apps \ packagegroup-custom-tools \ RDEPENDS_packagegroup-custom-apps = \ dropbear \ portmap \ psplash RDEPENDS_packagegroup-custom-tools = \ oprofile \ oprofileui-server \ lttng-control \ lttng-viewer and in my imageA i am pulling *only* packagegroup-custom-tools with IMAGE_INSTALL. What I notice is that all packages listed in my packagegroup even the ones from packagegroup-custom-apps which isn't pulled in my image are built when building my image. Of course they are not installed, but why are they built? it is wasting a large amount of time, while it's not even needed. is that really expected or am i doing something wrong here? The problem is that bitbake runs recipes, not packages. So in order to get the package 'packagegroup-custom-tools', you have to build your main recipe which will also build 'packagegroup-custom-apps' I've run across this myself and what I did was to split my package groups (then called tasks) into separate recipes. -- Gary Thomas | Consulting for the MLB Associates |Embedded world ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] question about packagegroups
On Wed, Jun 12, 2013 at 10:24 AM, Gary Thomas g...@mlbassoc.com wrote: The problem is that bitbake runs recipes, not packages. So in order to get the package 'packagegroup-custom-tools', you have to build your main recipe which will also build 'packagegroup-custom-apps' I've run across this myself and what I did was to split my package groups (then called tasks) into separate recipes. ok, i was suspecting something like that.. but i wasn't sure why. ok, i will just split my recipes, then. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] What does virtual/ mean?
I see lots of references to virtual/kernel, as opposed to simply kernel. The bitbake docs show virtual/whatever and virtual/package in some of its syntactic examples. But what does the virtual/ prefix actually mean? Google coughs up endless uses of the term, as though everyone knows what it means, but no explanation of it. -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto branches with other meta-data sets
Hi Edward, On Tuesday 11 June 2013 08:50:49 Edward Vidal wrote: I am trying to understand the various branches of poky. It appears that 1.4_M6 became dylan-9.0.0 which is DISTRO_VERSION= 1.4. Is this correct? I don't see a 1.4_M6 branch, only a 1.4_M6.rc1 tag which is not the same as the dylan-9.0.0 tag. DISTRO_VERSION for the dylan-9.0.0 tag would be 1.4, yes. top level of meta-oe git branch -a * master remotes/origin/HEAD - origin/master remotes/origin/danny remotes/origin/danny-next remotes/origin/denzil remotes/origin/denzil-next remotes/origin/dylan remotes/origin/dylan-next remotes/origin/master my conf/bblayers has the following entry /home/vidal/POKY/build060613_dylan/poky/meta-oe/meta-oe \ When I have the following in my conf/bblayers /home/vidal/POKY/build060613_dylan/poky/meta-oe \ I get errors. can not find conf/layer.conf. meta-openembedded (the repository) contains a few different layers in subdirectories, one of which is meta-oe. I think you just need to add an additional /meta-oe onto the path you've given for the layer in bblayers.conf. When using meta-oe with Yocto which branch should I be using origin/master, origin/dylan, or origin/dylan-next? I would say dylan; dylan-next is a proving temporary staging area for patches for the dylan branch and you should not rely upon it. My previous builds have been using origin/master For my Yocto I use the following git clone git://git.yoctoproject.org/poky cd poky git checkout -b dylan origin/dylan Which I found in dev-manual 3.6.1. Repositories, Tags, and Branches I noticed that this started as DISTRO_VERSION= 1.4 a few days ago and now it is DISTRO_VERSION= 1.4.1. If you're using the dylan branch of Poky or OE-Core then you're tracking a branch rather than a fixed version; we're preparing our upcoming point release of the dylan/1.4 series which will be 1.4.1, hence the recent version bump. When using meta-ti which I use to build images for beaglebone pandaboard. top level of meta-ti git branch -a * master remotes/origin/HEAD - origin/master remotes/origin/danny remotes/origin/denzil remotes/origin/master remotes/origin/split This branch works with origin/dylan of yocto meta-ti = (nobranch):d61bfa88ed3df9190ac9fd5643c27f77b34c5f01. I do not see a origin/dylan for meta-ti. You should talk to the meta-ti maintainers about this (probably on the meta-ti mailing list). Is Yocto the main source of meta-data that other are creating same branches? Is Yocto project participation Yocto Project Compatible what is driving the same branches? I don't know that there is any requirement about branches in version control within either of those programmes. I would certainly recommend people create branches corresponding to the release branches in OE-Core and use the same names to avoid confusion, but there's nothing forcing maintainers of other layers to do so. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] What does virtual/ mean?
Hi Paul, On Wednesday 12 June 2013 01:43:31 Paul D. DeRocco wrote: I see lots of references to virtual/kernel, as opposed to simply kernel. The bitbake docs show virtual/whatever and virtual/package in some of its syntactic examples. But what does the virtual/ prefix actually mean? Google coughs up endless uses of the term, as though everyone knows what it means, but no explanation of it. It's simply a convention to indicate the particular item is not a real package but a virtual placeholder that could be configured at build time to point to one of a selection of different providers; i.e. a recipe that requires kernel headers could have virtual/kernel in its DEPENDS rather than having to name a specific kernel recipe and the distro or machine configuration can set PREFERRED_PROVIDER_virtual/kernel to point to whatever real kernel recipe is desired. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [RFC v3 PATCH 00/50] Refactor and merge windows-build to master
This is only the cover letter for the entire patch series. Changed since v2: fixed license for files. Please review the following changes for suitability for inclusion. If you have any objections or suggestions for improvement, please respond to the patches. If you agree with the changes, please provide your Acked-by. The following changes since commit 0b2dc574b1b08eab2102b37f3b64ab7bd70d9595: Add resources to remote.util bin [yocto #4596] (2013-06-04 14:42:15 -0700) are available in the git repository at: git://git.yoctoproject.org/poky-contrib igrigorx/common-remote-refactor2 http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=igrigorx/common-remote-refactor2 Ioana Grigoropol (50): Rename RSEHelper to RemoteHelper to match usages in org.yocto.bc.ui.plugin Add ProcessStreamBuffer utility class Move ICommandResponseHandler to org.yocto.remote.utils Add YoctoCommand utility class Add CommandResponseHandler implementation of ICommandResponseHandler Add ConsoleRunnable utility class Add ConsoleHelper utility class Add OutputProcessor utility class Add CommandOutputProcessor utilty class Refactor RemoteHelper class Remove ICommandResponseHandler from plugin and use org.yocto.remote.utils implementation Remove unused Bitbake Actions Remove storing of init script location Remove unused method loadInit in Activator Remove unused getInitScript from ProjectInfoHelper Use URI for storing project locations Redirect bitbake environment parsing to file parse Use YoctoHostFile for storing OEFile(s) Remove unused checkReadOnlyParent method of OEFile Fix full path of OEFile Fix NullPointerException when detecting changed files Fix Hob launching on Linux host Enable editsave of remote files Fix variables hoover Fix ShellSession execute Remove shell type from ShellSession constructor Use / as separator instead of OS separator Remove unsed methods inner classes from ShellSession Save active connection for Bitbake recipe Initialize and store the connection on Recipe Wizard Store connection for recipe in Recipe Wizard Page Refactor Wizard Page fields to have consistent names Refactor populate method name Break handlePopulate into remote and local functions Use uri instead of string to determine location of recipe determine archive type Store metadata location as URI instead of String Refactor Recipe Wizard Page to use Remote target Api Run all Recipe task in wizard container Enable Populate button when src URI changes Store reference to OptionsPage in InstallWizard Collect Bitbake error lines Refactor Bitbake wizard to use RemoteHelper API Retrieve console from RemoteHelper instead of recreating it Remove LongRunningTask,ICalculatePercentage from InstallWizard Create separated class for ConsoleWriter Remove unused ConsoleWriter Add implicit constructror for OEFileSystemContributor Refactor and clean-up of OptionsPage fields Refactor OptionsPage to use Remote Location box validation Validate project name to check for invalid characters plugins/org.yocto.bc.ui/META-INF/MANIFEST.MF | 11 +- plugins/org.yocto.bc.ui/plugin.xml | 55 -- .../src/org/yocto/bc/bitbake/BBRecipe.java | 29 +- .../src/org/yocto/bc/bitbake/BBSession.java| 120 +++-- .../org/yocto/bc/bitbake/ProjectInfoHelper.java| 61 +-- .../src/org/yocto/bc/bitbake/ShellSession.java | 167 +++--- .../org/yocto/bc/remote/utils/ConsoleWriter.java | 46 ++ .../bc/remote/utils/YoctoRunnableWithProgress.java | 221 .../src/org/yocto/bc/ui/Activator.java | 86 ++-- .../ui/actions/AbstractBitbakeCommandAction.java | 199 .../bc/ui/actions/BitbakeBuildRecipeAction.java| 24 - .../bc/ui/actions/BitbakeCleanRecipeAction.java| 26 - .../yocto/bc/ui/actions/BitbakeImportAction.java | 106 .../bc/ui/actions/BitbakeRebuildRecipeAction.java | 29 -- .../bc/ui/actions/LaunchVariableWizardAction.java | 21 +- .../bc/ui/builder/BitbakeCommanderNature.java |5 +- .../bc/ui/editors/bitbake/BBVariableTextHover.java | 43 +- .../editors/bitbake/BitBakeDocumentProvider.java | 43 +- .../bc/ui/editors/bitbake/BitBakeFileEditor.java | 24 +- .../bitbake/BitBakeSourceViewerConfiguration.java | 21 +- .../src/org/yocto/bc/ui/filesystem/OEFile.java | 298 +++ .../org/yocto/bc/ui/filesystem/OEFileSystem.java | 40 +- .../bc/ui/filesystem/OEFileSystemContributor.java |6 +- .../org/yocto/bc/ui/filesystem/OEIgnoreFile.java | 10 +- .../org/yocto/bc/ui/filesystem/YoctoLocation.java | 44 ++ .../src/org/yocto/bc/ui/model/ProjectInfo.java | 78 ++- .../src/org/yocto/bc/ui/model/YoctoHostFile.java | 316 .../yocto/bc/ui/views/RecipeContentProvider.java |7 +- .../bc/ui/wizards/BitbakeRecipeUIElement.java | 18 +- .../bc/ui/wizards/NewBitBakeFileRecipeWizard.java |
Re: [yocto] Need clarification on some terms
Cross-Development Toolchain: A collection of software development tools and utilities that allow you to develop software for targeted architectures. Is that different from the toolchain that bitbake builds in the beginning, and then uses to build the image? If so, what is it? A cross development toolchain is a toolchain that runs on an architecture (cpu+os+libc) that is different from the architecture it generates code for. That can even be a toolchain running on an IA64-Linux machine generating object-code for an IA32-Linux machine. Following is a list of toolchain recipes... This is followed by gcc-cross-initial, gcc-cross-intermediate, gcc-cross. All three of these things say that the toolchain runs on the host and is used to build software for the target. So why are there three of them? What are the differences among them? The gcc must be build multiple times when you bootstrap it. For building the gcc you need to build the libc and therefor you need to build the linux kernel headers and therefor you need the gcc. Oops. Thats why you first build a gcc only with c support and no libc first. Use that to generate the kernel headers, then build the initial libc and then another gcc with libc support and all the frontends you need (c,c++,java,fortran,..). Why there is the gcc-cross-intermediate I am not shure, but there will be a reason and another one can clarify that. It also says that each one is a native package. In my experience, a native toolchain has always meant a toolchain that produces code for the same machine that the toolchain runs on, while a cross toolchain produces code for a different machine. That's obviously not what native means in this context, so what does it mean? In terms of openembedded a native package is a package that contains code that is intended to run on the build machine (your workstation). The cross-compiler runs on your build-machine to produce code for your target-machine. Thats why it is a native package. And there are a lot more native packages than only the compiler. The documentation makes frequent references to the SDK without ever defining it. I know what it means generically, but what is it in the Yocto context? And why does the SDK involve yet another set of three toolchains? (Oh, and why is one of them called canadian?) A canadian-cross is a term from the compiler stuff, not specific to the Yocto Project or Poky or Openembedded. Building a canadian-cross is the process of build a toolchain on architecture A that runs on architecture B and produces object-code for architecture C. An example is building a gcc on an IA32 architecture, that will run on an ARM, producing code for an M68K. Yes, that does make sence, if the ARM machine does not have the resources to be able to bootstrap the compiler by itself. Hope that made some things clear. Michael ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Need clarification on some terms
On Wed, Jun 12, 2013 at 7:16 AM, mich...@cubic.org wrote: Cross-Development Toolchain: A collection of software development tools and utilities that allow you to develop software for targeted architectures. Is that different from the toolchain that bitbake builds in the beginning, and then uses to build the image? If so, what is it? A cross development toolchain is a toolchain that runs on an architecture (cpu+os+libc) that is different from the architecture it generates code for. That can even be a toolchain running on an IA64-Linux machine generating object-code for an IA32-Linux machine. Following is a list of toolchain recipes... This is followed by gcc-cross-initial, gcc-cross-intermediate, gcc-cross. All three of these things say that the toolchain runs on the host and is used to build software for the target. So why are there three of them? What are the differences among them? The gcc must be build multiple times when you bootstrap it. For building the gcc you need to build the libc and therefor you need to build the linux kernel headers and therefor you need the gcc. Oops. Thats why you first build a gcc only with c support and no libc first. Use that to generate the kernel headers, then build the initial libc and then another gcc with libc support and all the frontends you need (c,c++,java,fortran,..). Why there is the gcc-cross-intermediate I am not shure, but there will be a reason and another one can clarify that. It also says that each one is a native package. In my experience, a native toolchain has always meant a toolchain that produces code for the same machine that the toolchain runs on, while a cross toolchain produces code for a different machine. That's obviously not what native means in this context, so what does it mean? In terms of openembedded a native package is a package that contains code that is intended to run on the build machine (your workstation). The cross-compiler runs on your build-machine to produce code for your target-machine. Thats why it is a native package. And there are a lot more native packages than only the compiler. The documentation makes frequent references to the SDK without ever defining it. I know what it means generically, but what is it in the Yocto context? And why does the SDK involve yet another set of three toolchains? (Oh, and why is one of them called canadian?) A canadian-cross is a term from the compiler stuff, not specific to the Yocto Project or Poky or Openembedded. Building a canadian-cross is the process of build a toolchain on architecture A that runs on architecture B and produces object-code for architecture C. An example is building a gcc on an IA32 architecture, that will run on an ARM, producing code for an M68K. Yes, that does make sence, if the ARM machine does not have the resources to be able to bootstrap the compiler by itself. And for what it's worth, the reason it's called Canadian is because at the time of it's naming, Canada had 3 political parties. http://en.wikipedia.org/wiki/Cross_compiler#Canadian_Cross Hope that made some things clear. Michael ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Need clarification on some terms
That little tidbit is interesting... Thanks Bill. BTW - I am incorporating some of this information into Terms section to help clear up stuff. Scott From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Bill Traynor Sent: Wednesday, June 12, 2013 4:33 AM To: mich...@cubic.org Cc: yocto@yoctoproject.org Subject: Re: [yocto] Need clarification on some terms On Wed, Jun 12, 2013 at 7:16 AM, mich...@cubic.orgmailto:mich...@cubic.org wrote: Cross-Development Toolchain: A collection of software development tools and utilities that allow you to develop software for targeted architectures. Is that different from the toolchain that bitbake builds in the beginning, and then uses to build the image? If so, what is it? A cross development toolchain is a toolchain that runs on an architecture (cpu+os+libc) that is different from the architecture it generates code for. That can even be a toolchain running on an IA64-Linux machine generating object-code for an IA32-Linux machine. Following is a list of toolchain recipes... This is followed by gcc-cross-initial, gcc-cross-intermediate, gcc-cross. All three of these things say that the toolchain runs on the host and is used to build software for the target. So why are there three of them? What are the differences among them? The gcc must be build multiple times when you bootstrap it. For building the gcc you need to build the libc and therefor you need to build the linux kernel headers and therefor you need the gcc. Oops. Thats why you first build a gcc only with c support and no libc first. Use that to generate the kernel headers, then build the initial libc and then another gcc with libc support and all the frontends you need (c,c++,java,fortran,..). Why there is the gcc-cross-intermediate I am not shure, but there will be a reason and another one can clarify that. It also says that each one is a native package. In my experience, a native toolchain has always meant a toolchain that produces code for the same machine that the toolchain runs on, while a cross toolchain produces code for a different machine. That's obviously not what native means in this context, so what does it mean? In terms of openembedded a native package is a package that contains code that is intended to run on the build machine (your workstation). The cross-compiler runs on your build-machine to produce code for your target-machine. Thats why it is a native package. And there are a lot more native packages than only the compiler. The documentation makes frequent references to the SDK without ever defining it. I know what it means generically, but what is it in the Yocto context? And why does the SDK involve yet another set of three toolchains? (Oh, and why is one of them called canadian?) A canadian-cross is a term from the compiler stuff, not specific to the Yocto Project or Poky or Openembedded. Building a canadian-cross is the process of build a toolchain on architecture A that runs on architecture B and produces object-code for architecture C. An example is building a gcc on an IA32 architecture, that will run on an ARM, producing code for an M68K. Yes, that does make sence, if the ARM machine does not have the resources to be able to bootstrap the compiler by itself. And for what it's worth, the reason it's called Canadian is because at the time of it's naming, Canada had 3 political parties. http://en.wikipedia.org/wiki/Cross_compiler#Canadian_Cross Hope that made some things clear. Michael ___ yocto mailing list yocto@yoctoproject.orgmailto:yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Need clarification on some terms
See http://www.yoctoproject.org/docs/1.5/dev-manual/dev-manual.html#cross-development-toolchain for the changes that I have made to the Cross-Development Toolchain term description. Let me know if this helps. Also let me know if I have botched anything. Thanks, Scott -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto- boun...@yoctoproject.org] On Behalf Of mich...@cubic.org Sent: Wednesday, June 12, 2013 4:17 AM To: yocto@yoctoproject.org Subject: Re: [yocto] Need clarification on some terms Cross-Development Toolchain: A collection of software development tools and utilities that allow you to develop software for targeted architectures. Is that different from the toolchain that bitbake builds in the beginning, and then uses to build the image? If so, what is it? A cross development toolchain is a toolchain that runs on an architecture (cpu+os+libc) that is different from the architecture it generates code for. That can even be a toolchain running on an IA64- Linux machine generating object-code for an IA32-Linux machine. Following is a list of toolchain recipes... This is followed by gcc-cross-initial, gcc-cross-intermediate, gcc-cross. All three of these things say that the toolchain runs on the host and is used to build software for the target. So why are there three of them? What are the differences among them? The gcc must be build multiple times when you bootstrap it. For building the gcc you need to build the libc and therefor you need to build the linux kernel headers and therefor you need the gcc. Oops. Thats why you first build a gcc only with c support and no libc first. Use that to generate the kernel headers, then build the initial libc and then another gcc with libc support and all the frontends you need (c,c++,java,fortran,..). Why there is the gcc-cross-intermediate I am not shure, but there will be a reason and another one can clarify that. It also says that each one is a native package. In my experience, a native toolchain has always meant a toolchain that produces code for the same machine that the toolchain runs on, while a cross toolchain produces code for a different machine. That's obviously not what native means in this context, so what does it mean? In terms of openembedded a native package is a package that contains code that is intended to run on the build machine (your workstation). The cross-compiler runs on your build-machine to produce code for your target-machine. Thats why it is a native package. And there are a lot more native packages than only the compiler. The documentation makes frequent references to the SDK without ever defining it. I know what it means generically, but what is it in the Yocto context? And why does the SDK involve yet another set of three toolchains? (Oh, and why is one of them called canadian?) A canadian-cross is a term from the compiler stuff, not specific to the Yocto Project or Poky or Openembedded. Building a canadian-cross is the process of build a toolchain on architecture A that runs on architecture B and produces object-code for architecture C. An example is building a gcc on an IA32 architecture, that will run on an ARM, producing code for an M68K. Yes, that does make sence, if the ARM machine does not have the resources to be able to bootstrap the compiler by itself. Hope that made some things clear. Michael ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Need clarification on some terms
This begs the question for gcc-crosssdk-intermediate... Is that gone as well? -Original Message- From: Paul Eggleton [mailto:paul.eggle...@linux.intel.com] Sent: Wednesday, June 12, 2013 5:00 AM To: yocto@yoctoproject.org Cc: Rifenbark, Scott M Subject: Re: [yocto] Need clarification on some terms On Wednesday 12 June 2013 04:16:30 mich...@cubic.org wrote: Paul D. DeRocco wrote on Tuesday, June 11, 2013 at 9:07 PM: Following is a list of toolchain recipes... This is followed by gcc-cross-initial, gcc-cross-intermediate, gcc-cross. All three of these things say that the toolchain runs on the host and is used to build software for the target. So why are there three of them? What are the differences among them? The gcc must be build multiple times when you bootstrap it. For building the gcc you need to build the libc and therefor you need to build the linux kernel headers and therefor you need the gcc. Oops. Thats why you first build a gcc only with c support and no libc first. Use that to generate the kernel headers, then build the initial libc and then another gcc with libc support and all the frontends you need (c,c++,java,fortran,..). Why there is the gcc-cross-intermediate I am not shure, but there will be a reason and another one can clarify that. gcc-cross-intermediate is gone as of 1.3; as I understand it current versions of glibc can be compiled using gcc-cross-initial so the intermediate step is no longer required. We should remove mention of this from the documentation (other than in the migration section that is). Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Need clarification on some terms
On Wednesday 12 June 2013 12:27:16 Rifenbark, Scott M wrote: This begs the question for gcc-crosssdk-intermediate... Is that gone as well? Yes. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Custom kernel in Yocto/dylan branch.
Hi!
Thank you for your help.
Finally I've had to change the meta/classes/kernel.bbclass in order to
fix the copy of defconfig to .config:
- if [ -f ${WORKDIR}/defconfig ] [ ! -f ${B}/.config ]; then
+ if [ -f ${WORKDIR}/defconfig ]; then
cp ${WORKDIR}/defconfig ${B}/.config
fi
I don't know the exact problem, and I'm trying to find out it.
Cheers.
Javi Roman
On Tue, Jun 11, 2013 at 5:34 PM, Paul Eggleton
paul.eggle...@linux.intel.com wrote:
On Tuesday 11 June 2013 16:47:53 Javi Roman wrote:
With
SRC_URI_append = file://defconfig
Does your actual recipe have a leading space in the value? _append won't add
this for you so you have to do it explicitly.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Custom kernel in Yocto/dylan branch.
On 13-06-12 08:37 AM, Javi Roman wrote:
Hi!
Thank you for your help.
Finally I've had to change the meta/classes/kernel.bbclass in order to
fix the copy of defconfig to .config:
- if [ -f ${WORKDIR}/defconfig ] [ ! -f ${B}/.config ]; then
+ if [ -f ${WORKDIR}/defconfig ]; then
cp ${WORKDIR}/defconfig ${B}/.config
fi
Right. That check is what prevents the fallback defconfig processing
from clobbering the .config which is generated by a linux-yocto* based
kernel configuration task (which gives you defconfig + fragments).
The point is that in the linux-yocto configme task essentially the
same thing that happens. The defconfig is fed into the configuration
as the baseline config, applied after a allnoconfig and then has
any fragments layered on top.
Which again leads me to my question about what exactly you were
seeing before that change in the linux build directory as the .config ?
Cheers,
Bruce
I don't know the exact problem, and I'm trying to find out it.
Cheers.
Javi Roman
On Tue, Jun 11, 2013 at 5:34 PM, Paul Eggleton
paul.eggle...@linux.intel.com wrote:
On Tuesday 11 June 2013 16:47:53 Javi Roman wrote:
With
SRC_URI_append = file://defconfig
Does your actual recipe have a leading space in the value? _append won't add
this for you so you have to do it explicitly.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Yet another LIC_FILES_CHKSUM question
In what way does LIC_FILES_CHKSUM correlate to what is specified in LICENSE?
LIC_FILES_CHKSUM *must* be specified unless LICENSE is set to CLOSED.
But, what if the package does not itself provide a license type file?
Is it then ok to simply leave LIC_FILES_CHKSUM = ?
Also, I could see that there was an Erlang Public License file
available in poky. But the file is named ErlPL-1.1 and there were no
maps attached to it, this patch will add that.
Hans
diff --git a/meta/conf/licenses.conf b/meta/conf/licenses.conf
index 3cb143c..ffed997 100644
--- a/meta/conf/licenses.conf
+++ b/meta/conf/licenses.conf
@@ -101,9 +101,14 @@ SPDXLICENSEMAP[AFL-1] = AFL-1.2
SPDXLICENSEMAP[AFLv2] = AFL-2.0
SPDXLICENSEMAP[AFLv1] = AFL-1.2
+#Erlang variations
+SPDXLICENSEMAP[ErlPLv1.1] = ErlPL-1.1
+SPDXLICENSEMAP[ErlPL1.1] = ErlPL-1.1
+
#Other variations
SPDXLICENSEMAP[EPLv1.0] = EPL-1.0
+
# Additional license directories. Add your custom licenses
directories this path.
# LICENSE_PATH += ${COREBASE}/custom-licenses
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Recompile the recipe everytime
Hi , Please help me out I am stuck in some issue, actually I want my recipe to do compilation everytime on every run of Bitbake linux-yocto ie can I remove stamping or sstate-cache that it allows me to run compilation everytime on every run of bitbake linux-yocto. I tried do_compile[nostamp] =1 but it did not work but same thing worked for do_install[nostamp]=1 Thanks in advance! Regards, Rohit Jindal === Please refer to http://www.aricent.com/legal/email_disclaimer.html for important disclosures regarding this electronic communication. === ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Recompile the recipe everytime
On 12 June 2013 14:15, Rohit2 Jindal rohit2.jin...@aricent.com wrote: Hi , Please help me out I am stuck in some issue, actually I want my recipe to do compilation everytime on every run of Bitbake linux-yocto I'm currently tweaking the kernel myself and using bitbake linux-yocto -c compile -f each time. That's recommended by http://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html as it avoids re-doing the packaging every time you just want to check if something compiles. You may also need to do bitbake linux-yocto -c compile_kernelmodules -f to rebuild modules. It's the -f that causes the task to be forced. Is this any help? It doesn't solve exactly the question you asked but might be what you need. -- Paul Barker Email: p...@paulbarker.me.uk http://www.paulbarker.me.uk ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] 1.4.1 rc1 available for testing
On Wednesday 12 June 2013 00:12:35 Flanagan, Elizabeth wrote: Ok, we have the start of a build. The issue was due to not being able to checkout bitbake during the nightly-oecore build because we had set the branch to dylan (which doesn't exist). The new location (with what should be the same git hashes) is at: http://autobuilder.yoctoproject.org/pub/nightly/20130612-5 This should only take a few hours to build out, so please check back in about 3 hours as there should be a fair amount of artifacts to begin testing. This build has finished successfully :) so 1.4.1 rc1 testing should be able to go ahead now. Thanks, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to deal with non-standard license.
In data martedì 11 giugno 2013 15:10:42, Flanagan, Elizabeth ha scritto:
On Tue, Jun 11, 2013 at 5:28 AM, Diego diego...@zoho.com wrote:
Hi everybody,
I have written a recipe which I'd like to contribute for glmark2:
https://launchpad.net/glmark2
The last thing that puzzles me before submitting it is that it's partly
GPL3+, and partly under this license:
https://github.com/rafalmiel/glmark2-wl/blob/master/COPYING.SGI
which is not in this list:
https://wiki.yoctoproject.org/wiki/License_Infrastructure_Interest_Group#L
icenses Is there any way to deal with that license? What should I put in
the LICENSE field in my recipe?
So, you will need to add a custom license or submit a patch OE-Core to
add that license. Where are you contributing this to?
If it's to a layer, you'll want to add the license to a custom license
path. You'll want that file to be unique and descriptive. Please make
sure the license filename has a version in the file name. eg SGI-1.
Within the layer you'll make a directory (in this example I use
custom-licenses), add the license text to a file named SGI-1, then add
this to your layer.conf:
LICENSE_PATH += ${LAYERDIR}/custom-licenses
SPDXLICENSEMAP[SGIv1] = SGI-1
That should get you what you want.
Hi Elizabeth,
I'm trying to integrate glmark2 into openembedded (meta-oe layer). I know this
is not the right mailing list for that task, but I'm still on the license
problem.
I've tried to do as you suggested, but I'm getting:
WARNING: glmark2: No generic license file exists for: SGI-1 in any provider
Paul suggested:
LICENSE = GPLv3+ SGI-1
I've tried also:
LICENSE = GPLv3+ SGIv1
but I'm still getting the same error message (obviously with SGIv1 instead).
I'm attaching the full patch for you to review if I'm doing something wrong.
Thank you for any hint you might give me,
DiegoFrom e050d390b053f4287634778e8ec3c7b582cd8b14 Mon Sep 17 00:00:00 2001
From: Diego Rondini diego...@zoho.com
Date: Wed, 12 Jun 2013 17:57:39 +0200
Subject: [meta-oe][PATCH] glmark2: Add recipe for glmark2
Add a recipe for glmark2, which is an OpenGL 2.0 / OpenGL ES 2.0 benchmark.
Signed-off-by: Diego Rondini diego...@zoho.com
---
.../recipes-benchmark/glmark2/glmark2_2012.12.bb | 35 +
toolchain-layer/conf/layer.conf|3 ++
toolchain-layer/custom-licenses/SGI-1 | 40
3 files changed, 78 insertions(+)
create mode 100644 meta-oe/recipes-benchmark/glmark2/glmark2_2012.12.bb
create mode 100644 toolchain-layer/custom-licenses/SGI-1
diff --git a/meta-oe/recipes-benchmark/glmark2/glmark2_2012.12.bb b/meta-oe/recipes-benchmark/glmark2/glmark2_2012.12.bb
new file mode 100644
index 000..eea6d37
--- /dev/null
+++ b/meta-oe/recipes-benchmark/glmark2/glmark2_2012.12.bb
@@ -0,0 +1,35 @@
+SUMMARY = OpenGL (ES) 2.0 benchmark
+DESCRIPTION = glmark2 is a benchmark for OpenGL (ES) 2.0. \
+It uses only the subset of the OpenGL 2.0 API that is compatible with OpenGL ES 2.0.
+HOMEPAGE = https://launchpad.net/glmark2;
+BUGTRACKER = https://bugs.launchpad.net/glmark2;
+
+LICENSE = GPLv3+ SGI-1
+LIC_FILES_CHKSUM = file://COPYING;md5=d32239bcb673463ab874e80d47fae504 \
+file://COPYING.SGI;md5=7125c8894bd29eddfd44ede5ce3ab1e4
+
+DEPENDS = libpng12
+
+SRC_URI = https://launchpad.net/${BPN}/trunk/${PV}/+download/${BP}.tar.gz;
+
+SRC_URI[md5sum] = 4f306664aa3886fa0cf93853603603f8
+SRC_URI[sha256sum] = bea6f9de2cdce376195bd91e4a2fdfdf80bf3e480abff8e05b90a6458c1deb47
+
+inherit pkgconfig
+
+PACKAGECONFIG ?= gl gles2
+
+PACKAGECONFIG[gl] = --enable-gl,,virtual/libgl
+PACKAGECONFIG[gles2] = --enable-glesv2,,virtual/libgles2
+
+do_configure() {
+ ./waf configure --prefix=${prefix} ${EXTRA_OECONF}
+}
+
+do_compile() {
+ ./waf build ${PARALLEL_MAKE}
+}
+
+do_install() {
+ ./waf install --destdir=${D}
+}
diff --git a/toolchain-layer/conf/layer.conf b/toolchain-layer/conf/layer.conf
index ca81eb1..9165754 100644
--- a/toolchain-layer/conf/layer.conf
+++ b/toolchain-layer/conf/layer.conf
@@ -23,3 +23,6 @@ BBFILE_PATTERN_toolchain-layer := ^${LAYERDIR}/
BBFILE_PRIORITY_toolchain-layer = 6
+# Import custom license
+LICENSE_PATH += ${LAYERDIR}/custom-licenses
+SPDXLICENSEMAP[SGIv1] = SGI-1
diff --git a/toolchain-layer/custom-licenses/SGI-1 b/toolchain-layer/custom-licenses/SGI-1
new file mode 100644
index 000..94ab8db
--- /dev/null
+++ b/toolchain-layer/custom-licenses/SGI-1
@@ -0,0 +1,40 @@
+The data and some of the control logic for the ideas scene was adapted from
+the Ideas in Motion GLUT demo. Per the rights granted by the source for that
+demo, the following notice is reproduced here:
+
+/*
+ * (c) Copyright 1993, Silicon Graphics, Inc.
+ * ALL RIGHTS RESERVED
+ * Permission to use, copy, modify, and distribute this software for
+ * any purpose and without fee is hereby granted, provided that the above
+ * copyright notice appear in all copies and that both the copyright notice
+ * and
[yocto] /var/lib/wdj/l10n: what is it doing in the target rootfs?
Hi. Anyone that can tell me why 'wdj' and 'wdj/l10n' folders are added to /var/lib? I sort of dislike having files/folders generated that I can not explain what they are doing; eventually the question will arise ;) Has it something to do with RPM? Should it really be there? I do not have RPM support on my target device. Hans ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yet another LIC_FILES_CHKSUM question
On Wed, Jun 12, 2013 at 6:05 AM, Hans Beckérus hans.becke...@gmail.com wrote:
In what way does LIC_FILES_CHKSUM correlate to what is specified in LICENSE?
LIC_FILES_CHKSUM *must* be specified unless LICENSE is set to CLOSED.
But, what if the package does not itself provide a license type file?
Is it then ok to simply leave LIC_FILES_CHKSUM = ?
That's kind of a tricky situation. I'm not a lawyer, but I haven't
actually seen an actual instance where there was a stated open source
license that wasn't also in the source. If there is then the correct
path is to probably put actual license text in the upstream as I can
imagine all sorts of legal issues with this. Any lawyers care to field
this on?
-b
Also, I could see that there was an Erlang Public License file
available in poky. But the file is named ErlPL-1.1 and there were no
maps attached to it, this patch will add that.
Hans
diff --git a/meta/conf/licenses.conf b/meta/conf/licenses.conf
index 3cb143c..ffed997 100644
--- a/meta/conf/licenses.conf
+++ b/meta/conf/licenses.conf
@@ -101,9 +101,14 @@ SPDXLICENSEMAP[AFL-1] = AFL-1.2
SPDXLICENSEMAP[AFLv2] = AFL-2.0
SPDXLICENSEMAP[AFLv1] = AFL-1.2
+#Erlang variations
+SPDXLICENSEMAP[ErlPLv1.1] = ErlPL-1.1
+SPDXLICENSEMAP[ErlPL1.1] = ErlPL-1.1
+
#Other variations
SPDXLICENSEMAP[EPLv1.0] = EPL-1.0
+
# Additional license directories. Add your custom licenses
directories this path.
# LICENSE_PATH += ${COREBASE}/custom-licenses
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
--
Elizabeth Flanagan
Yocto Project
Build and Release
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Problems fetching branch for linux-yocto-custom
All,
I have a custom linux recipe that I would like to fetch the head of a specific
branch on a Git repository. During the build it always fetches the master
branch, not the branch I am specifying. I've tried adding every relavant flag
to the SRC_URI that I can think of and it still fetches and builds the master
branch. Any ideas on what I am doing wrong?
Here is my build environment details:
Build Configuration:
BB_VERSION= 1.16.0
TARGET_ARCH = arm
TARGET_OS = linux-gnueabi
MACHINE = at91sam9x5ek
DISTRO= poky
DISTRO_VERSION= 1.3.2
TUNE_FEATURES = armv5 dsp thumb arm926ejs
TARGET_FPU= soft
meta-atmel= master:a3b649c46c6f48cea4c95d35028e950d8d5b3a13
meta
meta-yocto
meta-yocto-bsp= danny:c3505828f267ca68aaf454355466f54772545a22
-
Here is my kernel recipe (Removed the boilerplate comments at top of
linux-yocto-custom recipe to reduce clutter):
inherit kernel
require recipes-kernel/linux/linux-yocto.inc
# Override SRC_URI in a bbappend file to point at a different source
# tree if you do not want to build from Linus' tree.
SRC_URI =
git://github.com/linux4sam/linux-at91.git;branch=linux-3.9-at91;tag=dcdf169e24c0cb6d7dc69e0a09d2395934e95075;protocol=git;nocheckout=1
SRC_URI += file://${MACHINE}/defconfig
LINUX_VERSION ?= 3.9.0
LINUX_VERSION_EXTENSION ?= -custom
# Override SRCREV to point to a different commit in a bbappend file to
# build a different release of the Linux kernel.
# tag: v3.4 76e10d158efb6d4516018846f60c2ab5501900bc
# tag: linux-3.9-at91 as of 2013-06-12, dcdf169e24c0cb6d7dc69e0a09d2395934e95075
SRCREV=dcdf169e24c0cb6d7dc69e0a09d2395934e95075
PV = ${LINUX_VERSION}+${SRCREV}
PR = r1
# Override COMPATIBLE_MACHINE to include your machine in a bbappend
# file. Leaving it empty here ensures an early explicit build failure.
COMPATIBLE_MACHINE = (sama5d3xek|at91sam9x5ek)
-
And here is my bbappend:
FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
COMPATIBLE_MACHINE_sama5d3xek = at91sama5d3xek
COMPATIBLE_MACHINE_at91sam9x5ek = at91sam9x5ek
Any insight would be appreciated.
Thanks,
Bryan
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Problems fetching branch for linux-yocto-custom
On Wed, Jun 12, 2013 at 3:10 PM, Bryan Evenson beven...@melinkcorp.com wrote:
All,
I have a custom linux recipe that I would like to fetch the head of a
specific branch on a Git repository. During the build it always fetches the
master branch, not the branch I am specifying. I've tried adding every
relavant flag to the SRC_URI that I can think of and it still fetches and
builds the master branch. Any ideas on what I am doing wrong?
What release are you using ?
Have you tried setting KBRANCH ?
Cheers,
Bruce
Here is my build environment details:
Build Configuration:
BB_VERSION= 1.16.0
TARGET_ARCH = arm
TARGET_OS = linux-gnueabi
MACHINE = at91sam9x5ek
DISTRO= poky
DISTRO_VERSION= 1.3.2
TUNE_FEATURES = armv5 dsp thumb arm926ejs
TARGET_FPU= soft
meta-atmel= master:a3b649c46c6f48cea4c95d35028e950d8d5b3a13
meta
meta-yocto
meta-yocto-bsp= danny:c3505828f267ca68aaf454355466f54772545a22
-
Here is my kernel recipe (Removed the boilerplate comments at top of
linux-yocto-custom recipe to reduce clutter):
inherit kernel
require recipes-kernel/linux/linux-yocto.inc
# Override SRC_URI in a bbappend file to point at a different source
# tree if you do not want to build from Linus' tree.
SRC_URI =
git://github.com/linux4sam/linux-at91.git;branch=linux-3.9-at91;tag=dcdf169e24c0cb6d7dc69e0a09d2395934e95075;protocol=git;nocheckout=1
SRC_URI += file://${MACHINE}/defconfig
LINUX_VERSION ?= 3.9.0
LINUX_VERSION_EXTENSION ?= -custom
# Override SRCREV to point to a different commit in a bbappend file to
# build a different release of the Linux kernel.
# tag: v3.4 76e10d158efb6d4516018846f60c2ab5501900bc
# tag: linux-3.9-at91 as of 2013-06-12,
dcdf169e24c0cb6d7dc69e0a09d2395934e95075
SRCREV=dcdf169e24c0cb6d7dc69e0a09d2395934e95075
PV = ${LINUX_VERSION}+${SRCREV}
PR = r1
# Override COMPATIBLE_MACHINE to include your machine in a bbappend
# file. Leaving it empty here ensures an early explicit build failure.
COMPATIBLE_MACHINE = (sama5d3xek|at91sam9x5ek)
-
And here is my bbappend:
FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
COMPATIBLE_MACHINE_sama5d3xek = at91sama5d3xek
COMPATIBLE_MACHINE_at91sam9x5ek = at91sam9x5ek
Any insight would be appreciated.
Thanks,
Bryan
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
--
Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Problems fetching branch for linux-yocto-custom
-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@gmail.com]
Sent: Wednesday, June 12, 2013 3:15 PM
To: Bryan Evenson
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Problems fetching branch for linux-yocto-custom
On Wed, Jun 12, 2013 at 3:10 PM, Bryan Evenson
beven...@melinkcorp.com wrote:
All,
I have a custom linux recipe that I would like to fetch the head of a
specific branch on a Git repository. During the build it always
fetches the master branch, not the branch I am specifying. I've tried
adding every relavant flag to the SRC_URI that I can think of and it
still fetches and builds the master branch. Any ideas on what I am
doing wrong?
What release are you using ?
Have you tried setting KBRANCH ?
I didn't know about the KBRANCH variable. That sure helped. I changed my
recipe as shown below, and it is switching branches and checking out the
specified commit.
Thanks!
Bryan
Cheers,
Bruce
Here is my build environment details:
Build Configuration:
BB_VERSION= 1.16.0
TARGET_ARCH = arm
TARGET_OS = linux-gnueabi
MACHINE = at91sam9x5ek
DISTRO= poky
DISTRO_VERSION= 1.3.2
TUNE_FEATURES = armv5 dsp thumb arm926ejs
TARGET_FPU= soft
meta-atmel= master:a3b649c46c6f48cea4c95d35028e950d8d5b3a13
meta
meta-yocto
meta-yocto-bsp= danny:c3505828f267ca68aaf454355466f54772545a22
-
Here is my kernel recipe (Removed the boilerplate comments at top of
linux-yocto-custom recipe to reduce clutter):
inherit kernel
require recipes-kernel/linux/linux-yocto.inc
# Added KBRANCH spec
KBRANCH = linux-3.9-at91
# Override SRC_URI in a bbappend file to point at a different source
#
tree if you do not want to build from Linus' tree.
SRC_URI = git://github.com/linux4sam/linux-at91.git;branch=linux-
3.9-
at91;tag=dcdf169e24c0cb6d7dc69e0a09d2395934e95075;protocol=git;nochecko
ut=1
# Changed SRC_URI to following
SRC_URI =
git://github.com/linux4sam/linux-at91.git;branch=${KBRANCH};protocol=git;nocheckout=1
SRC_URI += file://${MACHINE}/defconfig
LINUX_VERSION ?= 3.9.0
LINUX_VERSION_EXTENSION ?= -custom
# Override SRCREV to point to a different commit in a bbappend file
to
# build a different release of the Linux kernel.
# tag: v3.4 76e10d158efb6d4516018846f60c2ab5501900bc
# tag: linux-3.9-at91 as of 2013-06-12,
dcdf169e24c0cb6d7dc69e0a09d2395934e95075
SRCREV=dcdf169e24c0cb6d7dc69e0a09d2395934e95075
PV = ${LINUX_VERSION}+${SRCREV}
PR = r1
# Override COMPATIBLE_MACHINE to include your machine in a bbappend #
file. Leaving it empty here ensures an early explicit build failure.
COMPATIBLE_MACHINE = (sama5d3xek|at91sam9x5ek)
-
And here is my bbappend:
FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
COMPATIBLE_MACHINE_sama5d3xek = at91sama5d3xek
COMPATIBLE_MACHINE_at91sam9x5ek = at91sam9x5ek
Any insight would be appreciated.
Thanks,
Bryan
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
--
Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Problems fetching branch for linux-yocto-custom
On 13-06-12 03:37 PM, Bryan Evenson wrote:
-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@gmail.com]
Sent: Wednesday, June 12, 2013 3:15 PM
To: Bryan Evenson
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Problems fetching branch for linux-yocto-custom
On Wed, Jun 12, 2013 at 3:10 PM, Bryan Evenson
beven...@melinkcorp.com wrote:
All,
I have a custom linux recipe that I would like to fetch the head of a
specific branch on a Git repository. During the build it always
fetches the master branch, not the branch I am specifying. I've tried
adding every relavant flag to the SRC_URI that I can think of and it
still fetches and builds the master branch. Any ideas on what I am
doing wrong?
What release are you using ?
Have you tried setting KBRANCH ?
I didn't know about the KBRANCH variable. That sure helped. I changed my
recipe as shown below, and it is switching branches and checking out the
specified commit.
Hmmm. I swear it had been documented, that's a gap. I'll double
check and get things updated if it is missing.
Bruce
Thanks!
Bryan
Cheers,
Bruce
Here is my build environment details:
Build Configuration:
BB_VERSION= 1.16.0
TARGET_ARCH = arm
TARGET_OS = linux-gnueabi
MACHINE = at91sam9x5ek
DISTRO= poky
DISTRO_VERSION= 1.3.2
TUNE_FEATURES = armv5 dsp thumb arm926ejs
TARGET_FPU= soft
meta-atmel= master:a3b649c46c6f48cea4c95d35028e950d8d5b3a13
meta
meta-yocto
meta-yocto-bsp= danny:c3505828f267ca68aaf454355466f54772545a22
-
Here is my kernel recipe (Removed the boilerplate comments at top of
linux-yocto-custom recipe to reduce clutter):
inherit kernel
require recipes-kernel/linux/linux-yocto.inc
# Added KBRANCH spec
KBRANCH = linux-3.9-at91
# Override SRC_URI in a bbappend file to point at a different source
#
tree if you do not want to build from Linus' tree.
SRC_URI = git://github.com/linux4sam/linux-at91.git;branch=linux-
3.9-
at91;tag=dcdf169e24c0cb6d7dc69e0a09d2395934e95075;protocol=git;nochecko
ut=1
# Changed SRC_URI to following
SRC_URI =
git://github.com/linux4sam/linux-at91.git;branch=${KBRANCH};protocol=git;nocheckout=1
SRC_URI += file://${MACHINE}/defconfig
LINUX_VERSION ?= 3.9.0
LINUX_VERSION_EXTENSION ?= -custom
# Override SRCREV to point to a different commit in a bbappend file
to
# build a different release of the Linux kernel.
# tag: v3.4 76e10d158efb6d4516018846f60c2ab5501900bc
# tag: linux-3.9-at91 as of 2013-06-12,
dcdf169e24c0cb6d7dc69e0a09d2395934e95075
SRCREV=dcdf169e24c0cb6d7dc69e0a09d2395934e95075
PV = ${LINUX_VERSION}+${SRCREV}
PR = r1
# Override COMPATIBLE_MACHINE to include your machine in a bbappend #
file. Leaving it empty here ensures an early explicit build failure.
COMPATIBLE_MACHINE = (sama5d3xek|at91sam9x5ek)
-
And here is my bbappend:
FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
COMPATIBLE_MACHINE_sama5d3xek = at91sama5d3xek
COMPATIBLE_MACHINE_at91sam9x5ek = at91sam9x5ek
Any insight would be appreciated.
Thanks,
Bryan
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
--
Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Problems fetching branch for linux-yocto-custom
-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Wednesday, June 12, 2013 3:44 PM
To: Bryan Evenson
Cc: Bruce Ashfield; yocto@yoctoproject.org
Subject: Re: [yocto] Problems fetching branch for linux-yocto-custom
On 13-06-12 03:37 PM, Bryan Evenson wrote:
-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@gmail.com]
Sent: Wednesday, June 12, 2013 3:15 PM
To: Bryan Evenson
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Problems fetching branch for linux-yocto-custom
On Wed, Jun 12, 2013 at 3:10 PM, Bryan Evenson
beven...@melinkcorp.com wrote:
All,
I have a custom linux recipe that I would like to fetch the head of
a
specific branch on a Git repository. During the build it always
fetches the master branch, not the branch I am specifying. I've
tried adding every relavant flag to the SRC_URI that I can think of
and it still fetches and builds the master branch. Any ideas on
what
I am doing wrong?
What release are you using ?
Have you tried setting KBRANCH ?
I didn't know about the KBRANCH variable. That sure helped. I
changed my recipe as shown below, and it is switching branches and
checking out the specified commit.
Hmmm. I swear it had been documented, that's a gap. I'll double check
and get things updated if it is missing.
No, KBRANCH is documented; I found it in the mega-manual after the fact. It's
just a variable I hadn't used yet so I didn't know to look for it. No amount
of documentation can fix that problem.
-Bryan
Bruce
Thanks!
Bryan
Cheers,
Bruce
Here is my build environment details:
Build Configuration:
BB_VERSION= 1.16.0
TARGET_ARCH = arm
TARGET_OS = linux-gnueabi
MACHINE = at91sam9x5ek
DISTRO= poky
DISTRO_VERSION= 1.3.2
TUNE_FEATURES = armv5 dsp thumb arm926ejs
TARGET_FPU= soft
meta-atmel=
master:a3b649c46c6f48cea4c95d35028e950d8d5b3a13
meta
meta-yocto
meta-yocto-bsp=
danny:c3505828f267ca68aaf454355466f54772545a22
-
Here is my kernel recipe (Removed the boilerplate comments at top
of
linux-yocto-custom recipe to reduce clutter):
inherit kernel
require recipes-kernel/linux/linux-yocto.inc
# Added KBRANCH spec
KBRANCH = linux-3.9-at91
# Override SRC_URI in a bbappend file to point at a different
source
#
tree if you do not want to build from Linus' tree.
SRC_URI = git://github.com/linux4sam/linux-at91.git;branch=linux-
3.9-
at91;tag=dcdf169e24c0cb6d7dc69e0a09d2395934e95075;protocol=git;nochec
ko
ut=1
# Changed SRC_URI to following
SRC_URI = git://github.com/linux4sam/linux-
at91.git;branch=${KBRANCH};protocol=git;nocheckout=1
SRC_URI += file://${MACHINE}/defconfig
LINUX_VERSION ?= 3.9.0
LINUX_VERSION_EXTENSION ?= -custom
# Override SRCREV to point to a different commit in a bbappend file
to
# build a different release of the Linux kernel.
# tag: v3.4 76e10d158efb6d4516018846f60c2ab5501900bc
# tag: linux-3.9-at91 as of 2013-06-12,
dcdf169e24c0cb6d7dc69e0a09d2395934e95075
SRCREV=dcdf169e24c0cb6d7dc69e0a09d2395934e95075
PV = ${LINUX_VERSION}+${SRCREV}
PR = r1
# Override COMPATIBLE_MACHINE to include your machine in a bbappend
# file. Leaving it empty here ensures an early explicit build
failure.
COMPATIBLE_MACHINE = (sama5d3xek|at91sam9x5ek)
-
And here is my bbappend:
FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
COMPATIBLE_MACHINE_sama5d3xek = at91sama5d3xek
COMPATIBLE_MACHINE_at91sam9x5ek = at91sam9x5ek
Any insight would be appreciated.
Thanks,
Bryan
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
--
Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Need clarification on some terms
From: Paul Eggleton gcc-cross-intermediate is gone as of 1.3; as I understand it current versions of glibc can be compiled using gcc-cross-initial so the intermediate step is no longer required. We should remove mention of this from the documentation (other than in the migration section that is). Okay, so now there are two stages to each cross-compilation, so there's gcc-cross-initial producing gcc-cross, and also gcc-crosssdk-initial producing gcc-crosssdk. But is the difference between those two pairs that the first pair ultimately produces a cross-compiler that runs on the host, and the second pair ultimately produces a native compiler that runs on the target? From what I can gather about the various references to SDK, it sounds like it's supposed to be a set of native tools that runs on the target and produces output for the target. If that's true, then the new descriptions are still wrong. Shouldn't gcc-cross be described as a cross package rather than a native, and shouldn't gcc-crosssdk be described as a native binary that runs on the target? Or am I still fundamentally misinterpreting these things? For now, I really just need to know if I'm interested in the SDK, since I have no intention of ever running compilations on my target system. -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Problems fetching branch for linux-yocto-custom
On 13-06-12 03:47 PM, Bryan Evenson wrote:
-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com]
Sent: Wednesday, June 12, 2013 3:44 PM
To: Bryan Evenson
Cc: Bruce Ashfield; yocto@yoctoproject.org
Subject: Re: [yocto] Problems fetching branch for linux-yocto-custom
On 13-06-12 03:37 PM, Bryan Evenson wrote:
-Original Message-
From: Bruce Ashfield [mailto:bruce.ashfi...@gmail.com]
Sent: Wednesday, June 12, 2013 3:15 PM
To: Bryan Evenson
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Problems fetching branch for linux-yocto-custom
On Wed, Jun 12, 2013 at 3:10 PM, Bryan Evenson
beven...@melinkcorp.com wrote:
All,
I have a custom linux recipe that I would like to fetch the head of
a
specific branch on a Git repository. During the build it always
fetches the master branch, not the branch I am specifying. I've
tried adding every relavant flag to the SRC_URI that I can think of
and it still fetches and builds the master branch. Any ideas on
what
I am doing wrong?
What release are you using ?
Have you tried setting KBRANCH ?
I didn't know about the KBRANCH variable. That sure helped. I
changed my recipe as shown below, and it is switching branches and
checking out the specified commit.
Hmmm. I swear it had been documented, that's a gap. I'll double check
and get things updated if it is missing.
No, KBRANCH is documented; I found it in the mega-manual after the fact. It's
just a variable I hadn't used yet so I didn't know to look for it. No amount
of documentation can fix that problem.
Aha. Thanks for following up. I'm just glad you are up and running,
it was a good question and something I'd like to make completely transparent
in the upcoming 1.5 release.
Cheers,
Bruce
-Bryan
Bruce
Thanks!
Bryan
Cheers,
Bruce
Here is my build environment details:
Build Configuration:
BB_VERSION= 1.16.0
TARGET_ARCH = arm
TARGET_OS = linux-gnueabi
MACHINE = at91sam9x5ek
DISTRO= poky
DISTRO_VERSION= 1.3.2
TUNE_FEATURES = armv5 dsp thumb arm926ejs
TARGET_FPU= soft
meta-atmel=
master:a3b649c46c6f48cea4c95d35028e950d8d5b3a13
meta
meta-yocto
meta-yocto-bsp=
danny:c3505828f267ca68aaf454355466f54772545a22
-
Here is my kernel recipe (Removed the boilerplate comments at top
of
linux-yocto-custom recipe to reduce clutter):
inherit kernel
require recipes-kernel/linux/linux-yocto.inc
# Added KBRANCH spec
KBRANCH = linux-3.9-at91
# Override SRC_URI in a bbappend file to point at a different
source
#
tree if you do not want to build from Linus' tree.
SRC_URI = git://github.com/linux4sam/linux-at91.git;branch=linux-
3.9-
at91;tag=dcdf169e24c0cb6d7dc69e0a09d2395934e95075;protocol=git;nochec
ko
ut=1
# Changed SRC_URI to following
SRC_URI = git://github.com/linux4sam/linux-
at91.git;branch=${KBRANCH};protocol=git;nocheckout=1
SRC_URI += file://${MACHINE}/defconfig
LINUX_VERSION ?= 3.9.0
LINUX_VERSION_EXTENSION ?= -custom
# Override SRCREV to point to a different commit in a bbappend file
to
# build a different release of the Linux kernel.
# tag: v3.4 76e10d158efb6d4516018846f60c2ab5501900bc
# tag: linux-3.9-at91 as of 2013-06-12,
dcdf169e24c0cb6d7dc69e0a09d2395934e95075
SRCREV=dcdf169e24c0cb6d7dc69e0a09d2395934e95075
PV = ${LINUX_VERSION}+${SRCREV}
PR = r1
# Override COMPATIBLE_MACHINE to include your machine in a bbappend
# file. Leaving it empty here ensures an early explicit build
failure.
COMPATIBLE_MACHINE = (sama5d3xek|at91sam9x5ek)
-
And here is my bbappend:
FILESEXTRAPATHS_prepend := ${THISDIR}/${PN}:
COMPATIBLE_MACHINE_sama5d3xek = at91sama5d3xek
COMPATIBLE_MACHINE_at91sam9x5ek = at91sam9x5ek
Any insight would be appreciated.
Thanks,
Bryan
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
--
Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Need clarification on some terms
I need this clarified as well. I am taking some guesses here and hoping for input. Scott -Original Message- From: Paul D. DeRocco [mailto:pdero...@ix.netcom.com] Sent: Wednesday, June 12, 2013 12:51 PM To: 'Paul Eggleton'; Rifenbark, Scott M Cc: yocto@yoctoproject.org Subject: RE: [yocto] Need clarification on some terms From: Paul Eggleton gcc-cross-intermediate is gone as of 1.3; as I understand it current versions of glibc can be compiled using gcc-cross-initial so the intermediate step is no longer required. We should remove mention of this from the documentation (other than in the migration section that is). Okay, so now there are two stages to each cross-compilation, so there's gcc-cross-initial producing gcc-cross, and also gcc-crosssdk-initial producing gcc-crosssdk. But is the difference between those two pairs that the first pair ultimately produces a cross-compiler that runs on the host, and the second pair ultimately produces a native compiler that runs on the target? From what I can gather about the various references to SDK, it sounds like it's supposed to be a set of native tools that runs on the target and produces output for the target. If that's true, then the new descriptions are still wrong. Shouldn't gcc-cross be described as a cross package rather than a native, and shouldn't gcc-crosssdk be described as a native binary that runs on the target? Or am I still fundamentally misinterpreting these things? For now, I really just need to know if I'm interested in the SDK, since I have no intention of ever running compilations on my target system. -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [linux-yocto] [3.8] I2C Fragments and MinnowBoard Support
On 13-06-12 03:02 PM, Darren Hart wrote: Add I2C fragments for ease of use in BSP descriptions and recipe-space KERNEL_FEATURES. Add I2C_CHARDEV support to the MinnowBoard description. Ack'd. These are fine. I'm on my way out for the evening, but will have these merged later tonight. Bruce ___ linux-yocto mailing list linux-yo...@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto ___ linux-yocto mailing list linux-yo...@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [yocto] Yet another LIC_FILES_CHKSUM question
On 2013-06-12 7:55, Flanagan, Elizabeth wrote:
On Wed, Jun 12, 2013 at 6:05 AM, Hans Beckérus hans.becke...@gmail.com wrote:
In what way does LIC_FILES_CHKSUM correlate to what is specified in LICENSE?
LIC_FILES_CHKSUM *must* be specified unless LICENSE is set to CLOSED.
But, what if the package does not itself provide a license type file?
Is it then ok to simply leave LIC_FILES_CHKSUM = ?
That's kind of a tricky situation. I'm not a lawyer, but I haven't
actually seen an actual instance where there was a stated open source
license that wasn't also in the source. If there is then the correct
path is to probably put actual license text in the upstream as I can
imagine all sorts of legal issues with this. Any lawyers care to field
this on?
-b
Hi Elizabeth, I understand you are not a lawyer ;) I did not really
expect one either.
Let's tweak the question into something slightly different. Assume that
LICENSE is saying eg. GPLv2, but the COPYING file provided by the
package says GPLv3? Iow, there is a mismatch between the what the recipe
says and what the package tells you.
I am a little bit confused to how LICENSE and LIC_FILES_CHKSUM really
works together? Why do we need two different ways of telling what
license we use or actually expect? Or is LICENSE checked against the
files pointed to by LIC_FILES_CHKSUM? Should it not always be the
file(s) stored in the upstream package that dictates what license should
be applied?
Hans
Also, I could see that there was an Erlang Public License file
available in poky. But the file is named ErlPL-1.1 and there were no
maps attached to it, this patch will add that.
Hans
diff --git a/meta/conf/licenses.conf b/meta/conf/licenses.conf
index 3cb143c..ffed997 100644
--- a/meta/conf/licenses.conf
+++ b/meta/conf/licenses.conf
@@ -101,9 +101,14 @@ SPDXLICENSEMAP[AFL-1] = AFL-1.2
SPDXLICENSEMAP[AFLv2] = AFL-2.0
SPDXLICENSEMAP[AFLv1] = AFL-1.2
+#Erlang variations
+SPDXLICENSEMAP[ErlPLv1.1] = ErlPL-1.1
+SPDXLICENSEMAP[ErlPL1.1] = ErlPL-1.1
+
#Other variations
SPDXLICENSEMAP[EPLv1.0] = EPL-1.0
+
# Additional license directories. Add your custom licenses
directories this path.
# LICENSE_PATH += ${COREBASE}/custom-licenses
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yet another LIC_FILES_CHKSUM question
On Wed, Jun 12, 2013 at 1:06 PM, Hans Beckerus hans.becke...@gmail.com wrote:
On 2013-06-12 7:55, Flanagan, Elizabeth wrote:
On Wed, Jun 12, 2013 at 6:05 AM, Hans Beckérus hans.becke...@gmail.com
wrote:
In what way does LIC_FILES_CHKSUM correlate to what is specified in
LICENSE?
LIC_FILES_CHKSUM *must* be specified unless LICENSE is set to CLOSED.
But, what if the package does not itself provide a license type file?
Is it then ok to simply leave LIC_FILES_CHKSUM = ?
That's kind of a tricky situation. I'm not a lawyer, but I haven't
actually seen an actual instance where there was a stated open source
license that wasn't also in the source. If there is then the correct
path is to probably put actual license text in the upstream as I can
imagine all sorts of legal issues with this. Any lawyers care to field
this on?
-b
Hi Elizabeth, I understand you are not a lawyer ;) I did not really expect
one either.
Let's tweak the question into something slightly different. Assume that
LICENSE is saying eg. GPLv2, but the COPYING file provided by the package
says GPLv3? Iow, there is a mismatch between the what the recipe says and
what the package tells you.
Ah, in that case, the LICENSE is obviously incorrect and the recipe
should be patched, right?
I am a little bit confused to how LICENSE and LIC_FILES_CHKSUM really works
together? Why do we need two different ways of telling what license we use
or actually expect?
This is a way for us to tell that the LICENSE may have changed. If the
text of the license files in LIC_FILES_CHKSUM change, something
happened that needs to be looked at.
Or is LICENSE checked against the files pointed to by
LIC_FILES_CHKSUM? Should it not always be the file(s) stored in the upstream
package that dictates what license should be applied?
They are, but there are a few problems with this
1. Figuring out license automatically is an interesting and kind of
time consuming issue. COPYING isn't *always* the license information.
We've got source that has license information in headers, in COPYING,
in LICENSE, in a lot of places and figuring out is a file contains
license information without a common portable data exchange is kind of
hard (license people see where I'm going here ;) )..
2. This is one of the reasons that Matt Germonprez and a team of
people at the University of Nebraska Omaha are working on implementing
some tooling around SPDX within the project (for more on SPDX see:
www.spdx.org). We need a way to do deep inspection of source as well
as recognize when the upstream has implemented an SPDX file. This
should be implemented in the 1.5 time frame.
So, in a nutshell, scanning for license during every build is time
consuming. We want to do it once, improve the LICENSE data where we
can, and utilize LIC_FILES_CHKSUM to help maintain it, running our
SPDX utilities now and then to be able to find new licenses added that
LIC_FILES_CHKSUM may not know about.
-b
Hans
Also, I could see that there was an Erlang Public License file
available in poky. But the file is named ErlPL-1.1 and there were no
maps attached to it, this patch will add that.
Hans
diff --git a/meta/conf/licenses.conf b/meta/conf/licenses.conf
index 3cb143c..ffed997 100644
--- a/meta/conf/licenses.conf
+++ b/meta/conf/licenses.conf
@@ -101,9 +101,14 @@ SPDXLICENSEMAP[AFL-1] = AFL-1.2
SPDXLICENSEMAP[AFLv2] = AFL-2.0
SPDXLICENSEMAP[AFLv1] = AFL-1.2
+#Erlang variations
+SPDXLICENSEMAP[ErlPLv1.1] = ErlPL-1.1
+SPDXLICENSEMAP[ErlPL1.1] = ErlPL-1.1
+
#Other variations
SPDXLICENSEMAP[EPLv1.0] = EPL-1.0
+
# Additional license directories. Add your custom licenses
directories this path.
# LICENSE_PATH += ${COREBASE}/custom-licenses
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
--
Elizabeth Flanagan
Yocto Project
Build and Release
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Problems fetching branch for linux-yocto-custom
On Wed, Jun 12, 2013 at 3:37 PM, Bryan Evenson beven...@melinkcorp.com wrote:
# Added KBRANCH spec
KBRANCH = linux-3.9-at91
# Override SRC_URI in a bbappend file to point at a different source
#
tree if you do not want to build from Linus' tree.
SRC_URI = git://github.com/linux4sam/linux-at91.git;branch=linux-
3.9-
at91;tag=dcdf169e24c0cb6d7dc69e0a09d2395934e95075;protocol=git;nochecko
ut=1
# Changed SRC_URI to following
SRC_URI =
git://github.com/linux4sam/linux-at91.git;branch=${KBRANCH};protocol=git;nocheckout=1
It looks like all you did was to define the string linux-3.9-at91 in
its own variable, put that in your SRC_URI string, and remove the
tag=... field. Would your original recipe have worked if all you did
was remove the tag=... field?
Is KBRANCH being used somewhere else? Doesn't bitbake's git fetcher
already have a generic way of specifying a branch? Why would a kernel
recipe need to also define a branch variable? Do non-kernel recipes
also need to define some kind of branch variable too?
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Need clarification on some terms
On Wed, Jun 12, 2013 at 3:51 PM, Paul D. DeRocco pdero...@ix.netcom.com wrote: Shouldn't gcc-cross be described as a cross package rather than a native, and shouldn't gcc-crosssdk be described as a native binary that runs on the target? Or am I still fundamentally misinterpreting these things? Your understanding is quite good, actually. But I think you're mixing up your contexts :-) If you were at GCC or LLVM conference talking to a bunch of compiler geeks about compilers, they would use the term native to refer to a compiler which produces executables for the same machine on which the compile was taking place. As opposed to a cross-compiler which produces executables meant to run on some other architecture. If you were on the Yocto/OE mailing lists talking to people about native packages or output, you would be differentiating between packages which are meant to run on the build machine rather than on the (embedded) target. So in the Yocto world, any package meant to run on the build machine is a native package. Even if that package is a cross-compiling compiler (i.e. a non-native compiler). :-D ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Problems fetching branch for linux-yocto-custom
-Original Message-
From: Trevor Woerner [mailto:twoer...@gmail.com]
Sent: Wednesday, June 12, 2013 4:42 PM
To: Bryan Evenson
Cc: Bruce Ashfield; yocto@yoctoproject.org
Subject: Re: [yocto] Problems fetching branch for linux-yocto-custom
On Wed, Jun 12, 2013 at 3:37 PM, Bryan Evenson
beven...@melinkcorp.com wrote:
# Added KBRANCH spec
KBRANCH = linux-3.9-at91
# Override SRC_URI in a bbappend file to point at a different
source
#
tree if you do not want to build from Linus' tree.
SRC_URI = git://github.com/linux4sam/linux-at91.git;branch=linux-
3.9-
at91;tag=dcdf169e24c0cb6d7dc69e0a09d2395934e95075;protocol=git;nochec
ko
ut=1
# Changed SRC_URI to following
SRC_URI = git://github.com/linux4sam/linux-
at91.git;branch=${KBRANCH};protocol=git;nocheckout=1
It looks like all you did was to define the string linux-3.9-at91 in
its own variable, put that in your SRC_URI string, and remove the
tag=... field. Would your original recipe have worked if all you did
was remove the tag=... field?
Is KBRANCH being used somewhere else? Doesn't bitbake's git fetcher
already have a generic way of specifying a branch? Why would a kernel
recipe need to also define a branch variable? Do non-kernel recipes
also need to define some kind of branch variable too?
From looking through meta/classes/kernel-yocto.bbclass, I see KBRANCH being
used a lot in reference to the specific branch to be checked out.
KBRANCH_DEFAULT defines the default branch (which defaults to master) so if
you don't specify KBRANCH, then it'll checkout the KBRANCH_DEFAULT branch.
With that said, I'm wondering what would happen if I specified KBRANCH but
didn't put the branch=${KBRANCH} in the SRC_URI. Is this branch= variable
from the SRC_URI being used for the kernel?
-Bryan
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Need clarification on some terms
On Wed, Jun 12, 2013 at 3:51 PM, Paul D. DeRocco pdero...@ix.netcom.com wrote: For now, I really just need to know if I'm interested in the SDK, since I have no intention of ever running compilations on my target system. Imagine a company which produces embedded devices running Linux. There are hardware engineers, and software people. Within the software group there will always be that person (or group) which is responsible for creating the Linux filesystem which runs on the device, i.e. the base system, and there is the person or group responsible for writing the special sauce, the program which (or programs that) make the device do the special thing that sets this device apart (i.e. the application developer group). Sometimes these people are the one and the same person, other times they are separate people/groups. Only the person/group responsible for the base filesystem need to know about Yocto/OE. The special sauce people don't need to know anything about packages, kernels, udev, /etc, or any of that other stuff. But what they do need is a compiler[1] so they can build the software for their target device. The compiler they need has to be tied to the base filesystem. They shouldn't be using a compiler that isn't aware of what libraries (and therefore also be using the correct header files) that are going to be available on the target, and they shouldn't be using a compiler that isn't aware of the version of the kernel that will be available on the target. In order to help get the Yocto/OE group and the application group in sync, Yocto/OE has this neat target which allows the platform team to generate an compiler (i.e. the SDK) that the application group can use which is, through the magic of the Yocto system, perfectly tuned for the image the platform team is creating. In other words, the application team doesn't need to perform Yocto builds in order to write their software, they just need the Yocto people to generate an SDK for them and produce a new SDK anytime anything on the target image changes. The Yocto people can generate this SDK using a very simple one-liner. For a little more information, please have a look at item 19 of https://github.com/twoerner/meta-trevor/blob/master/misc/notes [1] When I say compiler here (in quotes) I really mean the cross-compiler, the necessary header files, the cross-linker, etc, etc... ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Problems fetching branch for linux-yocto-custom
On 13-06-12 4:41 PM, Trevor Woerner wrote:
On Wed, Jun 12, 2013 at 3:37 PM, Bryan Evenson beven...@melinkcorp.com wrote:
# Added KBRANCH spec
KBRANCH = linux-3.9-at91
# Override SRC_URI in a bbappend file to point at a different source
#
tree if you do not want to build from Linus' tree.
SRC_URI = git://github.com/linux4sam/linux-at91.git;branch=linux-
3.9-
at91;tag=dcdf169e24c0cb6d7dc69e0a09d2395934e95075;protocol=git;nochecko
ut=1
# Changed SRC_URI to following
SRC_URI =
git://github.com/linux4sam/linux-at91.git;branch=${KBRANCH};protocol=git;nocheckout=1
It looks like all you did was to define the string linux-3.9-at91 in
its own variable, put that in your SRC_URI string, and remove the
tag=... field. Would your original recipe have worked if all you did
was remove the tag=... field?
Is KBRANCH being used somewhere else? Doesn't bitbake's git fetcher
already have a generic way of specifying a branch? Why would a kernel
recipe need to also define a branch variable? Do non-kernel recipes
also need to define some kind of branch variable too?
This is specific to the linux-yocto branch management. It is passed to
the configuration subsystem (and others) to properly prepare and process
the kernel.
It doesn't have anything to do with the fetcher.
Remember. linux-yocto is a set of standalone tools, mapped to bitbake
and yocto, so we are passing in what the tools need to work.
Cheers,
Bruce
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Problems fetching branch for linux-yocto-custom
On 13-06-12 4:54 PM, Bryan Evenson wrote:
-Original Message-
From: Trevor Woerner [mailto:twoer...@gmail.com]
Sent: Wednesday, June 12, 2013 4:42 PM
To: Bryan Evenson
Cc: Bruce Ashfield; yocto@yoctoproject.org
Subject: Re: [yocto] Problems fetching branch for linux-yocto-custom
On Wed, Jun 12, 2013 at 3:37 PM, Bryan Evenson
beven...@melinkcorp.com wrote:
# Added KBRANCH spec
KBRANCH = linux-3.9-at91
# Override SRC_URI in a bbappend file to point at a different
source
#
tree if you do not want to build from Linus' tree.
SRC_URI = git://github.com/linux4sam/linux-at91.git;branch=linux-
3.9-
at91;tag=dcdf169e24c0cb6d7dc69e0a09d2395934e95075;protocol=git;nochec
ko
ut=1
# Changed SRC_URI to following
SRC_URI = git://github.com/linux4sam/linux-
at91.git;branch=${KBRANCH};protocol=git;nocheckout=1
It looks like all you did was to define the string linux-3.9-at91 in
its own variable, put that in your SRC_URI string, and remove the
tag=... field. Would your original recipe have worked if all you did
was remove the tag=... field?
Is KBRANCH being used somewhere else? Doesn't bitbake's git fetcher
already have a generic way of specifying a branch? Why would a kernel
recipe need to also define a branch variable? Do non-kernel recipes
also need to define some kind of branch variable too?
From looking through meta/classes/kernel-yocto.bbclass, I see KBRANCH being used a lot
in reference to the specific branch to be checked out. KBRANCH_DEFAULT defines the
default branch (which defaults to master) so if you don't specify KBRANCH,
then it'll checkout the KBRANCH_DEFAULT branch.
With that said, I'm wondering what would happen if I specified KBRANCH but didn't put the
branch=${KBRANCH} in the SRC_URI. Is this branch= variable from the SRC_URI
being used for the kernel?
There are compatibility checks that will pick up branch, and set
KBRANCH on your behalf if you only use branch= in the SRC_URI, but
there are limitations since clobbering a KBRANCH variable isn't
always possible due to when they are expanded (i.e. recipe parse
time).
Cheers,
Bruce
-Bryan
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to deal with non-standard license.
On Wed, Jun 12, 2013 at 9:41 AM, Diego diego...@zoho.com wrote:
In data martedì 11 giugno 2013 15:10:42, Flanagan, Elizabeth ha scritto:
On Tue, Jun 11, 2013 at 5:28 AM, Diego diego...@zoho.com wrote:
Hi everybody,
I have written a recipe which I'd like to contribute for glmark2:
https://launchpad.net/glmark2
The last thing that puzzles me before submitting it is that it's partly
GPL3+, and partly under this license:
https://github.com/rafalmiel/glmark2-wl/blob/master/COPYING.SGI
which is not in this list:
https://wiki.yoctoproject.org/wiki/License_Infrastructure_Interest_Group#L
icenses Is there any way to deal with that license? What should I put in
the LICENSE field in my recipe?
So, you will need to add a custom license or submit a patch OE-Core to
add that license. Where are you contributing this to?
If it's to a layer, you'll want to add the license to a custom license
path. You'll want that file to be unique and descriptive. Please make
sure the license filename has a version in the file name. eg SGI-1.
Within the layer you'll make a directory (in this example I use
custom-licenses), add the license text to a file named SGI-1, then add
this to your layer.conf:
LICENSE_PATH += ${LAYERDIR}/custom-licenses
SPDXLICENSEMAP[SGIv1] = SGI-1
That should get you what you want.
Hi Elizabeth,
I'm trying to integrate glmark2 into openembedded (meta-oe layer). I know this
is not the right mailing list for that task, but I'm still on the license
problem.
Ah, ok. In that case, ignore what I just said and patch oe-core's
files/common-licenses with the SGI license and
files/conf/licenses.conf with:
SPDXLICENSEMAP[SGIv1] = SGI-1
SRC_DISTRIBUTE_LICENSES += SGI-1
That's the right way to do this, IMHO
I've tried to do as you suggested, but I'm getting:
WARNING: glmark2: No generic license file exists for: SGI-1 in any provider
Paul suggested:
LICENSE = GPLv3+ SGI-1
I've tried also:
LICENSE = GPLv3+ SGIv1
but I'm still getting the same error message (obviously with SGIv1 instead).
I'm attaching the full patch for you to review if I'm doing something wrong.
Thank you for any hint you might give me,
Diego
-b
--
Elizabeth Flanagan
Yocto Project
Build and Release
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Need clarification on some terms
On 06/12/2013 03:51 PM, Paul D. DeRocco wrote: For now, I really just need to know if I'm interested in the SDK, since I have no intention of ever running compilations on my target system. Trevor's answer has a lot of great background. My short answer is gcc-cross is for use inside bitbake (in the host) and gcc-crosssdk is for use outside of bitbake (still on the host). This outside bitbake use case is the SDK Trevor described. Why does gcc need to get built differently between these two use cases? I gave up asking this many years ago and accepted it as something I can not change for my own serenity. I am sure Paul or Khem could give the detail. The sdk version does have extra stuff to make it relocatable etc that is not needed inside of bitbake. However I don't know why we don't always build the sdk-able version. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Need clarification on some terms
From: Trevor Woerner Imagine a company which produces embedded devices running Linux. There are hardware engineers, and software people. Within the software group there will always be that person (or group) which is responsible for creating the Linux filesystem which runs on the device, i.e. the base system, and there is the person or group responsible for writing the special sauce, the program which (or programs that) make the device do the special thing that sets this device apart (i.e. the application developer group). Sometimes these people are the one and the same person, other times they are separate people/groups. Only the person/group responsible for the base filesystem need to know about Yocto/OE. The special sauce people don't need to know anything about packages, kernels, udev, /etc, or any of that other stuff. But what they do need is a compiler[1] so they can build the software for their target device. The compiler they need has to be tied to the base filesystem. They shouldn't be using a compiler that isn't aware of what libraries (and therefore also be using the correct header files) that are going to be available on the target, and they shouldn't be using a compiler that isn't aware of the version of the kernel that will be available on the target. In order to help get the Yocto/OE group and the application group in sync, Yocto/OE has this neat target which allows the platform team to generate an compiler (i.e. the SDK) that the application group can use which is, through the magic of the Yocto system, perfectly tuned for the image the platform team is creating. In other words, the application team doesn't need to perform Yocto builds in order to write their software, they just need the Yocto people to generate an SDK for them and produce a new SDK anytime anything on the target image changes. The Yocto people can generate this SDK using a very simple one-liner. For a little more information, please have a look at item 19 of https://github.com/twoerner/meta-trevor/blob/master/misc/notes Okay, so I'm wrong about the SDK being a toolchain that runs on the target. It does indeed run on the host, right? So why is the toolchain that builds the target application on the host different from the toolchain that builds the target OS image on the host? -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Need clarification on some terms
Or, looking at your notes, is it that bitbake -c populate_sdk image takes the toolchain that was used to build the image, and packages it up as an SDK for the benefit of application developers (the normal case), while bitbake meta-toolchain builds a new SDK that may be different in some ways, including maybe running on a third intermediate machine (the special case)? -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Need clarification on some terms
Hi Paul, Both of them will generate the cross toolchain which will be used by application developer on their development host for generate binaries for their target embedded devices, this cross toolchain includes the cross compiler, cross linker, etc. But to allow for cross development, the application developer also needs development packages that contains target headers and libraries that they can develop application against. These development packages are included in the sysroot that cross toolchain is compiling and linking against. This sysroot is typically base on the target devices' image rootfs. The first command bitbae -c populate_sdk image will generate the full SDK that includes toolchain and a target image matching sysroot, while the command bitbake meta_toolchain only generate the cross toolchain and a minimum sysroot that you shouldn't use to develop against. For the latter case, we suggest people to setup their sysroot using a target image rootfs. Cheers, Jessica -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Paul D. DeRocco Sent: Wednesday, June 12, 2013 3:10 PM To: 'Trevor Woerner' Cc: yocto@yoctoproject.org Subject: Re: [yocto] Need clarification on some terms Or, looking at your notes, is it that bitbake -c populate_sdk image takes the toolchain that was used to build the image, and packages it up as an SDK for the benefit of application developers (the normal case), while bitbake meta-toolchain builds a new SDK that may be different in some ways, including maybe running on a third intermediate machine (the special case)? -- Ciao, Paul D. DeRocco Paulmailto:pdero...@ix.netcom.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [linux-yocto] looking for doc for in-house linux-kernel dev tree
Hi Bruce, thanks for the answers!
On 2013-06-10, at 1:04 AM, Bruce Ashfield wrote:
[...]
Couple of questions:
- What exactly does AUTOREV do?
The fetcher always gets the latest commit on the branches. During
development, we want to pick up everything that is pushed, without
needing to tweak all the SRCREVs.
- Is it possible to get this bbappend to use the current working directory
state (including un-committed changes)
using the SRC_URI and AUTOREV?
The SRCREV will only control what the fetcher pulls in, and then
what is checked out. The compile phase will then start. If there
are patches, or other touches to files that aren't committed, they
will be built. But if you have uncommitted changes, you'll have
potential issues with branch switches, etc.
You mean if I make changes in the non-bare repo clone found in
tmp/work/.../linux-yoctoXYZ/linux after the bitbake build has set it up?
- what is the _pn_ and why is it absent in the poky-contrib example?
(SRCREV_machine_${MACHINE}=${AUTOREV} and
SRCREV_meta=${AUTOREV})
A bitbake OVERRIDE value. _pn_ package name. You'll find other
examples floating around the tree, and various layers.
I have found other examples yes, still don't know what it overrides, and why the
linux-yocto_3.x.bbappends use that, but the poky-contrib
linux-yocto_3.x.bbappends don't.
- in SRC_URI what does the nocheckout=1 and bareclone=[0-1] do? I've had
error reports about this in
tmp/work/machine/linux-yoctoXYZ/temp logs.
The tools work on the branches, to quickly make a copy of the tree
that has all the branches local, a bareclone and checkout in the
build directory is done. That is what those options control.
Right... Found the most detailed doc I could at:
poky/bitbake/lib/bb/fetch2/git.py Is the term bareclone the same as in git
terminology? I.e. a bare clone is just the .git directory, no files are checked
out of the git DB. I could not detect any difference between bareclone=1 and
nocheckout=1, nor could I find any git bare clones in tmp/work. The
downloads directory contains a true git bare clone of the repo mentioned in
SRC_URI in either cases (nocheckout=1 or bareclone=1). Still a bit fuzzy, I am
gathering that this is more of an optimization than anything perhaps?
[...]
We did some more experiments and found a lot of confusion around
recipe-space's
KBRANCH_osprey = x vs. meta-space's branch osprey statements. I have
observed that if in my gitlab repo, I create a branch called
standard/osprey
and this branch is a merge of my-master + emgd-1.16 + standard/crownbay, the
recipe build tries to patch things like kprobes and such, and basically fails
saying:
| ERROR: branch standard/osprey was requested, but was not properly
|configured to be built. The current branch is standard/osprey/base
'standard/osprey/base' has not be mentionned anywhere that I can see, it's a
product of the recipe's work.
It's a property of there being a subbranch of standard/osprey being
detected. Due to the way that git stores refs on disk, we have to
rename standard/osprey to standard/osprey/base if something like
standard/osprey/bsp is being requested.
If I don't prefix with standard/ in KBRANCH, then it doesn't patch and
things
seems to work correctly. (BTW, my gitlab is a clone of your
linux-yocto-3.4, we
just add new branches to that)
Is this behaviour normal? If so, is there documentation for this? Another
detail
when I had the prefix standard/ in my setup: I have temporarily tried to
set
branch standard/base at the same sha1 as my standard/osprey branch, that
made
no difference.
It is normal, and just the tools trying to help you out. The docs
may be slim in this area, I'll double check tomorrow.
What does your BSP's .scc file look like ? Is it something you
can share ?
bsp/osprey/osprey.scc:
define KMACHINE osprey
define KTYPE standard
define KARCH i386
include ktypes/standard/standard.scc
branch osprey
kconf hardware bsp/common-sonatest/hardware.cfg
kconf hardware bsp/common-sonatest/w1.cfg
kconf hardware osprey.cfg
kconf non-hardware bsp/common-sonatest/non-hardware.cfg
include cfg/x86.scc
include features/irq/irq.scc
include features/intel-e1/intel-e100.scc
include features/intel-e1/intel-e1.scc
include cfg/dmaengine.scc
include cfg/8250.scc
include features/power/intel.scc
include features/usb/ehci-hcd.scc
include features/usb/ohci-hcd.scc
include features/aufs/aufs.scc
include features/drm-emgd/drm-emgd-1.16.scc
# default policy for standard kernels
include cfg/usb-mass-storage.scc
include cfg/boot-live.scc
include features/latencytop/latencytop.scc
include features/profiling/profiling.scc
aufs.scc looks like:
kconf non-hardware aufs.cfg
branch aufs
and branch aufs exists in my linux clone. It's a merge of upstream-aufs-3.4 +
v3.4.46 + standard/base. The resulting aufs branch is merged into my machine
Re: [linux-yocto] looking for doc for in-house linux-kernel dev tree
On 13-06-12 11:27 AM, Jean-François Dagenais wrote:
Hi Bruce, thanks for the answers!
On 2013-06-10, at 1:04 AM, Bruce Ashfield wrote:
[...]
Couple of questions:
- What exactly does AUTOREV do?
The fetcher always gets the latest commit on the branches. During
development, we want to pick up everything that is pushed, without
needing to tweak all the SRCREVs.
- Is it possible to get this bbappend to use the current working directory
state (including un-committed changes)
using the SRC_URI and AUTOREV?
The SRCREV will only control what the fetcher pulls in, and then
what is checked out. The compile phase will then start. If there
are patches, or other touches to files that aren't committed, they
will be built. But if you have uncommitted changes, you'll have
potential issues with branch switches, etc.
You mean if I make changes in the non-bare repo clone found in
tmp/work/.../linux-yoctoXYZ/linux after the bitbake build has set it up?
Not quite. SRCREV is only used when the fetcher is pulling from
the upstream source. Wherever SRC_URI is pointing. If you modify files
in your build directory, they'll be compiled. Assuming that you don't
clean and rebuild of course.
- what is the _pn_ and why is it absent in the poky-contrib example?
(SRCREV_machine_${MACHINE}=${AUTOREV} and
SRCREV_meta=${AUTOREV})
A bitbake OVERRIDE value. _pn_ package name. You'll find other
examples floating around the tree, and various layers.
I have found other examples yes, still don't know what it overrides, and why the
linux-yocto_3.x.bbappends use that, but the poky-contrib
linux-yocto_3.x.bbappends don't.
It should be in the oe-core/yocto manuals, but I'd describe it as a more
'specific' variable. What you can use as override values is defined by
the OVERRIDES variable. var_OVERRIDE = will be used over simply var =.
_pn_ means that only when the package being built matches the name, will the
override take place. So it is specific to a recipe.
- in SRC_URI what does the nocheckout=1 and bareclone=[0-1] do? I've had error
reports about this in
tmp/work/machine/linux-yoctoXYZ/temp logs.
The tools work on the branches, to quickly make a copy of the tree
that has all the branches local, a bareclone and checkout in the
build directory is done. That is what those options control.
Right... Found the most detailed doc I could at:
poky/bitbake/lib/bb/fetch2/git.py Is the term bareclone the same as in git
terminology? I.e. a bare clone is just the .git directory, no files are checked
out of the git DB. I could not detect any difference between bareclone=1 and
nocheckout=1, nor could I find any git bare clones in tmp/work. The
downloads directory contains a true git bare clone of the repo mentioned in
SRC_URI in either cases (nocheckout=1 or bareclone=1). Still a bit fuzzy, I am
gathering that this is more of an optimization than anything perhaps?
It was required in the early days, now it is more of an optimization. You'd
only see the bare clone in your tmp/dowloads/* directory structure, not
in tmp/work, since the linux-yocto* recipes and classes debare the
tree and make it ready for building.
[...]
We did some more experiments and found a lot of confusion around recipe-space's
KBRANCH_osprey = x vs. meta-space's branch osprey statements. I have
observed that if in my gitlab repo, I create a branch called standard/osprey
and this branch is a merge of my-master + emgd-1.16 + standard/crownbay, the
recipe build tries to patch things like kprobes and such, and basically fails
saying:
| ERROR: branch standard/osprey was requested, but was not properly
|configured to be built. The current branch is standard/osprey/base
'standard/osprey/base' has not be mentionned anywhere that I can see, it's a
product of the recipe's work.
It's a property of there being a subbranch of standard/osprey being
detected. Due to the way that git stores refs on disk, we have to
rename standard/osprey to standard/osprey/base if something like
standard/osprey/bsp is being requested.
If I don't prefix with standard/ in KBRANCH, then it doesn't patch and things
seems to work correctly. (BTW, my gitlab is a clone of your linux-yocto-3.4, we
just add new branches to that)
Is this behaviour normal? If so, is there documentation for this? Another detail
when I had the prefix standard/ in my setup: I have temporarily tried to set
branch standard/base at the same sha1 as my standard/osprey branch, that made
no difference.
It is normal, and just the tools trying to help you out. The docs
may be slim in this area, I'll double check tomorrow.
What does your BSP's .scc file look like ? Is it something you
can share ?
bsp/osprey/osprey.scc:
define KMACHINE osprey
define KTYPE standard
define KARCH i386
include ktypes/standard/standard.scc
branch osprey
kconf hardware bsp/common-sonatest/hardware.cfg
kconf hardware bsp/common-sonatest/w1.cfg
kconf hardware osprey.cfg
kconf non-hardware
[linux-yocto] [PATCH 1/2] meta: Add i2c feature descriptions
Add feature scc files for i2c, i2c debugging, and i2c character device support. Signed-off-by: Darren Hart dvh...@linux.intel.com --- meta/cfg/kernel-cache/features/i2c/i2c.cfg|2 ++ meta/cfg/kernel-cache/features/i2c/i2c.scc|4 meta/cfg/kernel-cache/features/i2c/i2cdbg.cfg |5 + meta/cfg/kernel-cache/features/i2c/i2cdbg.scc |5 + meta/cfg/kernel-cache/features/i2c/i2cdev.cfg |1 + meta/cfg/kernel-cache/features/i2c/i2cdev.scc |5 + 6 files changed, 22 insertions(+), 0 deletions(-) create mode 100644 meta/cfg/kernel-cache/features/i2c/i2c.cfg create mode 100644 meta/cfg/kernel-cache/features/i2c/i2c.scc create mode 100644 meta/cfg/kernel-cache/features/i2c/i2cdbg.cfg create mode 100644 meta/cfg/kernel-cache/features/i2c/i2cdbg.scc create mode 100644 meta/cfg/kernel-cache/features/i2c/i2cdev.cfg create mode 100644 meta/cfg/kernel-cache/features/i2c/i2cdev.scc diff --git a/meta/cfg/kernel-cache/features/i2c/i2c.cfg b/meta/cfg/kernel-cache/features/i2c/i2c.cfg new file mode 100644 index 000..bcd08a3 --- /dev/null +++ b/meta/cfg/kernel-cache/features/i2c/i2c.cfg @@ -0,0 +1,2 @@ +CONFIG_I2C=y +CONFIG_I2C_HELPER_AUTO=y diff --git a/meta/cfg/kernel-cache/features/i2c/i2c.scc b/meta/cfg/kernel-cache/features/i2c/i2c.scc new file mode 100644 index 000..b4b5944 --- /dev/null +++ b/meta/cfg/kernel-cache/features/i2c/i2c.scc @@ -0,0 +1,4 @@ +define KFEATURE_DESCRIPTION Enable I2C Support +define KFEATURE_COMPATIBILITY board + +kconf hardware i2c.cfg diff --git a/meta/cfg/kernel-cache/features/i2c/i2cdbg.cfg b/meta/cfg/kernel-cache/features/i2c/i2cdbg.cfg new file mode 100644 index 000..f9da439 --- /dev/null +++ b/meta/cfg/kernel-cache/features/i2c/i2cdbg.cfg @@ -0,0 +1,5 @@ +CONFIG_EXPERIMENTAL=y +CONFIG_I2C_STUB=m +CONFIG_I2C_DEBUG_CORE=y +CONFIG_I2C_DEBUG_ALGO=y +CONFIG_I2C_DEBUG_BUS=y diff --git a/meta/cfg/kernel-cache/features/i2c/i2cdbg.scc b/meta/cfg/kernel-cache/features/i2c/i2cdbg.scc new file mode 100644 index 000..969f412 --- /dev/null +++ b/meta/cfg/kernel-cache/features/i2c/i2cdbg.scc @@ -0,0 +1,5 @@ +define KFEATURE_DESCRIPTION Enable I2C Debugging Options +define KFEATURE_COMPATIBILITY board + +include i2c.scc +kconf hardware i2cdbg.cfg diff --git a/meta/cfg/kernel-cache/features/i2c/i2cdev.cfg b/meta/cfg/kernel-cache/features/i2c/i2cdev.cfg new file mode 100644 index 000..d843de2 --- /dev/null +++ b/meta/cfg/kernel-cache/features/i2c/i2cdev.cfg @@ -0,0 +1 @@ +CONFIG_I2C_CHARDEV=m diff --git a/meta/cfg/kernel-cache/features/i2c/i2cdev.scc b/meta/cfg/kernel-cache/features/i2c/i2cdev.scc new file mode 100644 index 000..777ac25 --- /dev/null +++ b/meta/cfg/kernel-cache/features/i2c/i2cdev.scc @@ -0,0 +1,5 @@ +define KFEATURE_DESCRIPTION Enable userspace I2C access +define KFEATURE_COMPATIBILITY board + +include i2c.scc +kconf hardware i2cdev.cfg -- 1.7.5.4 ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] [PATCH 2/2] meta/minnow: Add i2cdev support
Support userspace I2C development by including I2C_CHARDEV in the BSP. Signed-off-by: Darren Hart dvh...@linux.intel.com --- meta/cfg/kernel-cache/bsp/minnow/minnow.scc |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/meta/cfg/kernel-cache/bsp/minnow/minnow.scc b/meta/cfg/kernel-cache/bsp/minnow/minnow.scc index 1a590d9..41b98a2 100644 --- a/meta/cfg/kernel-cache/bsp/minnow/minnow.scc +++ b/meta/cfg/kernel-cache/bsp/minnow/minnow.scc @@ -10,6 +10,7 @@ include cfg/timer/hpet.scc include cfg/timer/rtc.scc include features/leds/leds.scc include features/spi/spidev.scc +include features/i2c/i2cdev.scc # Earlyprintk and port debug requires 8250 # This is a =y fragment -- 1.7.5.4 ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] [3.8] I2C Fragments and MinnowBoard Support
On 13-06-12 3:02 PM, Darren Hart wrote: Add I2C fragments for ease of use in BSP descriptions and recipe-space KERNEL_FEATURES. Add I2C_CHARDEV support to the MinnowBoard description. merged to linux-yocto-3.8 and linux-yocto-dev. Cheers, Bruce ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
