[yocto] Capture download location and checksum?

As part of auditing, I'd like for the build to capture the download location. I am going to work on code that generates a license manifest that also includes the download location and checksum as part of the 'recipeinfo' file. Is this already saved off in a variable or other construct, or do I

Re: [yocto] Hook for layer-only actions?

oss > > On 10 July 2018 at 19:53, Alexander Kanavin > wrote: > > Yes. Implement a class and inherit it from the recipes. > > > > Alex > > > > 2018-07-10 20:50 GMT+02:00 Michael Habibi : > >> I was wondering if there is a way I can apply a global modifi

[yocto] Hook for layer-only actions?

I was wondering if there is a way I can apply a global modification to all recipes in a layer? For instance, we have our own layer for our changes that sit on top of the base Yocto/OE layers. What if, hypothetically, I wanted to insert a do_package_qa action globally, for everything in our layer.

[yocto] Yocto SDK and license manifest

We use Yocto to generate a simple SDK that we use as a toolchain. However, it appears that building the SDK vs an image does not generate the license manifest (we have deploy/rpm, deploy/sdk, but not deploy/license). Have we configured something wrong, or perhaps do we need to do something

Re: [yocto] Generating license/manifest for a specific layer?

some text > manipulation in a ROOTFS_POSTPROCESS_COMMAND would be the way I'd > probably look at tackling it. > > On Wed, Jun 13, 2018 at 2:42 PM, Michael Habibi > wrote: > > Beth, > > > > This is for internal consumption. We want to be able to generate a full > > mani

Re: [yocto] Generating license/manifest for a specific layer?

Beth, This is for internal consumption. We want to be able to generate a full manifest, and also one that reflects how we diverged from base Yocto distribution. On Mon, Jun 11, 2018 at 10:55 AM Beth Flanagan wrote: > On Mon, Jun 11, 2018 at 2:46 PM, Michael Habibi > wrote: > >

[yocto] Generating license/manifest for a specific layer?

Our use case is to capture the license files, manifest (package/version), and download information only for packages we modify/add. We use our own layer to modify/add packages, everything coming from standard Yocto layers are untouched. Is there a way to generate this information on a

Re: [yocto] Patching only the target version of a package?

, Burton, Ross <ross.bur...@intel.com> wrote: > On 1 February 2018 at 15:03, Michael Habibi <mikehab...@gmail.com> wrote: > >> So let's say my whole bbappend file is only necessary for the target >> version. Can I rename the whole thing package-target.bbapp

Re: [yocto] Patching only the target version of a package?

thing more specific? I have only seen -native, -cross, and some other ones that don't seem to apply to this case. On Thu, Feb 1, 2018 at 8:44 AM, Burton, Ross <ross.bur...@intel.com> wrote: > On 1 February 2018 at 14:29, Michael Habibi <mikehab...@gmail.com> wrote: > >> I'

[yocto] Patching only the target version of a package?

I'm sure this is really simple but I haven't quite wrapped my head around it. We have a bbappend file that supplies a set of patches. It currently has the unintended side-effect of patching both the native version used during the Yocto build process, and the eventual target version. How do I

Re: [yocto] Using site.conf

Ok thanks! I think I mistakenly thought that I needed to have it be called site.conf.sample, and it will copy the sample into the .conf file in the build/conf area. On Tue, Oct 31, 2017 at 9:24 AM, Burton, Ross <ross.bur...@intel.com> wrote: > On 31 October 2017 at 14:15, Michael Habibi

Re: [yocto] Using site.conf

Is there an example of this somewhere? I haven't had any luck in documentation or example code to see how to make the site.conf be used. On Mon, Oct 30, 2017 at 6:16 PM, Khem Raj <raj.k...@gmail.com> wrote: > On Fri, Oct 27, 2017 at 11:59 AM, Michael Habibi <mikehab...@gmail.

[yocto] Using site.conf

I'm a bit confused about the usage of site.conf. I see a sample in the poky distro area, but I'm not sure how this actually gets copied into a site.conf and actually used by deployed versions of our distribution. Is there some extra step I need to take to ensure site.conf.sample from my own

[yocto] Git/yocto newbie question re: submodules and multiple layers

Hi, I am well-versed with Git but I haven't really ever had to use submodules. I am trying to create a git repository on our server that will host our yocto distribution. Our distribution will include the yocto repo, plus meta-openembedded repo, plus maybe some other layers. The difficulty I have

[yocto] Building applications and distributions separately, but integrate into final image

All, I am looking at Yocto as a replacement for our embedded distribution. Currently we build everything as a distribution. This includes building the Linux kernel, open source packages, as well as our own IP and applications. As you can imagine, a vast majority of our build is taken up by

Re: [yocto] Trying to run toaster off master, running into issues w/ django

Excellent. Thanks! I knew using latest was going to burn me eventually :) On Wed, Aug 24, 2016 at 5:51 AM, Ed Bartosh <ed.bart...@linux.intel.com> wrote: > On Tue, Aug 23, 2016 at 04:49:42PM -0500, Michael Habibi wrote: >> I am running the master branch and trying to run toaster to

Re: [yocto] Build toolchain only (crosstools substitute?)

on, 02 May 2016 16:38:16 Michael Habibi wrote: > > I have been a few months out of researching Yocto, so I'm having trouble > > caching it all back in (a lot to absorb!). Excuse me if this is answered > > clearly in the documentation (I glanced around and I know you can build >

[yocto] Build toolchain only (crosstools substitute?)

I have been a few months out of researching Yocto, so I'm having trouble caching it all back in (a lot to absorb!). Excuse me if this is answered clearly in the documentation (I glanced around and I know you can build relocatable toolchains, etc, but I suppose I'm asking more of a philosophical

Re: [yocto] Where root password is defined by default

I see an example of setting the root password in the extrausers class documentation - http://www.yoctoproject.org/docs/2.0/ref-manual/ref-manual.html#ref-classes-extrausers This sets the password to 1876*18: inherit extrausers EXTRA_USERS_PARAMS = "\ usermod -P 1876*18 root;

Re: [yocto] Power off IC over Yocto

Simon, that's more of a kernel development question and probably doesn't fit in the Yocto project mailing list. You may try the linux kernel development mailing lists. However, I will give you some feedback. I think you are modifying code too deep in the kernel. By the time you get to that

Re: [yocto] populate_sdk fails almost immediately

I'm not sure if this was the cause, but I did two things and it fixed: 1) I changed SDK_VENDOR from "-diags-sdk" to "-diagssdk" 2) I deleted /tmp Perhaps having two dashes in SDK_VENDOR was screwing up a parse statement somewhere. On Wed, Dec 16, 2015 at 2:55 PM, Mic

[yocto] populate_sdk fails almost immediately

I decided to built the SDK to play around with the output so I can understand how it all goes together. According to the documentation, I simply do: bitbake -c populate_sdk It's worth noting I am running a custom image and distro and not a poky/yocto image (I do inherit core-image, however). I

[yocto] Custom license in file header

I am trying to pull in the stream benchmark utility into my custom layer. However this appears to have a custom license. It's in the header of stream.c, but it's also copied here: https://www.cs.virginia.edu/stream/FTP/Code/LICENSE.txt For simplicity, I am simply using stream.c and providing

[yocto] Understanding build work directories (machine vs tuning)

I have created a new machine, and that new machine has a tuning specific to our architecture. For example, machine=mymachine and mymachine's default tuning is myarch. I've noticed that for the target, we actually get two different work directories: one based on my machine, e.g.

[yocto] Best practice for building a large amount of source files

If I have some source I want to bring into my layer, for example: Recipe dir: meta-mylayer/recipes-management/myapplication/myapplication_1.0/ What is the best option for adding all of these and compiling? As far as I know, you have to do one of the following: 1) Use a fetch that fetches a

Re: [yocto] Best practice for building a large amount of source files

wrote: > > On 10 December 2015 at 21:16, Michael Habibi <mikehab...@gmail.com> wrote: > >> What is the best option for adding all of these and compiling? As far as >> I know, you have to do one of the following: >> >> 1) Use a fetch that fetches a tarball with a

Re: [yocto] BeagleBone...bitbake -v core-image-sato stops

You may be able to look under ${WORKDIR}/temp/log.do_compile to see what the logs are saying it got stuck doing. On Sun, Dec 6, 2015 at 4:16 AM, wrote: > Hello to all, > > this is my first question ;-) I'm doing my first steps with a beaglebone > black and yocto. I've

Re: [yocto] Best practice for files copied directly into sysroot?

Yes you're right thanks for correcting - I meant rootfs! On Sat, Dec 5, 2015 at 3:23 PM, Paul Eggleton <paul.eggle...@linux.intel.com > wrote: > Hi Michael, > > On Tue, 01 Dec 2015 09:26:15 Michael Habibi wrote: > > I am working on potentially migrating our

Re: [yocto] Best practice for files copied directly into sysroot?

This is perfect, thanks Bryan. On Fri, Dec 4, 2015 at 8:03 AM, Bryan Evenson <beven...@melinkcorp.com> wrote: > Michael, > > > -Original Message- > > From: Michael Habibi [mailto:mikehab...@gmail.com] > > Sent: Thursday, December 03, 2015 5:54 P

[yocto] Wilcard/recursing for SRC_URI file fetcher?

As far as I can tell, there is no way to point to a directory or match based on file type, for example: SRC_URI = "file://*.c \ file://*.h" or SRC_URI = "file://directory/;recurse=true" # include all files under 'directory' Instead, files must be individually selected with

[yocto] Pure initramfs image

All, I have interest in creating an image that runs purely in an initramfs space. It seems that overall this shouldn't be too difficult - I can set my IMAGE_FSTYPE to cpio.gz, and as long as it's a reasonable size, it shouldn't be an issue to point to it as an initrd. The only quirk is that

Re: [yocto] Best practice for files copied directly into sysroot?

to ${S}? Or is this something I need to do? Thanks, Michael On Tue, Dec 1, 2015 at 2:03 PM, Michael Habibi <mikehab...@gmail.com> wrote: > Thanks Bryan! > > On Tue, Dec 1, 2015 at 1:50 PM, Bryan Evenson <beven...@melinkcorp.com> > wrote: > >> Michael, >> &g

Re: [yocto] Pure initramfs image

Oh well that's easy. I figured it was already added because it was in the deployed directory, but I guess the tasks behave differently. On Thu, Dec 3, 2015 at 10:32 AM, Gary Thomas <g...@mlbassoc.com> wrote: > On 2015-12-03 09:24, Michael Habibi wrote: > >> All, >> >&g

[yocto] do_fetch hanging - any way to see debugging?

I'm struggling with some network proxy issues and pulling down linux-yocto. I left my build running overnight and it simply hung at do_fetch. I tried using -v and -DDD but it doesn't actually show any output from the do_fetch recipe. I looked at the do_fetch logs and it doesn't have anything

Re: [yocto] do_fetch hanging - any way to see debugging?

I'll try running it outside the script and see what I can devise - thanks! On Wed, Dec 2, 2015 at 2:18 PM, Paul Eggleton <paul.eggle...@linux.intel.com > wrote: > Hi Michael, > > On Wed, 02 Dec 2015 09:41:41 Michael Habibi wrote: > > I'm struggling with some network proxy is

Re: [yocto] Best practice for files copied directly into sysroot?

Thanks Bryan! On Tue, Dec 1, 2015 at 1:50 PM, Bryan Evenson <beven...@melinkcorp.com> wrote: > Michael, > > > -Original Message- > > From: yocto-boun...@yoctoproject.org [mailto:yocto- > > boun...@yoctoproject.org] On Behalf Of Michael Habibi > > Sent:

[yocto] Best practice for files copied directly into sysroot?

I am working on potentially migrating our distribution to Yocto (will be a long, long process). We have an area of our filesystem where any file placed will go directly into the rootfs of the target. This works well with our product, as we have certain binaries and scripts that need to be copied

Re: [yocto] Cross-compiling python fails with new custom tuning

, Michael Habibi <mikehab...@gmail.com> wrote: > Mark, > > I ran the same command, including the offending PYTHONPATH, from the shell > without error. Any reason why that would work, despite it not working from > within the Makefile? I was thinking it was another

Re: [yocto] Cross-compiling python fails with new custom tuning

. python-native should continue to work with its internal settings to find modules and libraries. To be continued tomorrow, I'm sure... On Mon, Nov 30, 2015 at 11:37 AM, Michael Habibi <mikehab...@gmail.com> wrote: > Mark, I am continuing to look at this. I hope you don't mind if I keep &

Re: [yocto] Cross-compiling python fails with new custom tuning

e/2015-November/113456.html > > > http://lists.openembedded.org/pipermail/openembedded-core/2015-November/113458.html > > On 11/30/15 5:12 PM, Michael Habibi wrote: > > OK I've dug into this further today, and here are some findings: > > > > With my patch (which is s

Re: [yocto] Cross-compiling python fails with new custom tuning

rget > binary > > and QEMU doesn't have instruction support -- but that doesn't look like > the case > > here. > > > > --Mark > > > > On 11/24/15 3:06 PM, Michael Habibi wrote: > >> All, > >> > >> I added a new machine definiti

Re: [yocto] Cross-compiling python fails with new custom tuning

t 10:01 AM, Michael Habibi <mikehab...@gmail.com> wrote: > Ah sorry, I misspoke. I walked through the Makefile and configure scripts > a bit more, and $(PYTHON_FOR_BUILD) should in fact be a host version of > Python. It seems it's not being configured correctly. Either the path is &g

Re: [yocto] Cross-compiling python fails with new custom tuning

/25/15 10:11 AM, Michael Habibi wrote: > > Well, I'm wrong yet again. A 'which python2.7' shows that it's pointing > to a > > native version of Python: > > > > *| which python2.7* > > *| > > > /projects/yocto-git/build/tmp/sy

Re: [yocto] Transitioning to Yocto, some basic questions about workflow

to get started? Thanks, still trying to wrap my head around this a bit. On Tue, Nov 10, 2015 at 6:06 PM, Randy Witt <randy.e.w...@linux.intel.com> wrote: > Hi Michael, > > See my replies below. > > On 11/10/2015 02:27 PM, Michael Habibi wrote: > > >> >>

[yocto] Transitioning to Yocto, some basic questions about workflow

All, First I appreciate taking the time to read through this email. I have spent the last couple weeks reading through Yocto/bitbake documentation, and have run a couple of the reference builds, e.g. core-image-minimal. I have a better-than-vague sense now of how it’s parsing

Re: [yocto] Transitioning to Yocto, some basic questions about workflow

Thanks for the great info Randy. On Tue, Nov 10, 2015 at 6:06 PM, Randy Witt <randy.e.w...@linux.intel.com> wrote: > Hi Michael, > See my replies below. > On 11/10/2015 02:27 PM, Michael Habibi wrote: >> >> >> This is fundamentally why I have been looking i