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 nee
gt; Ross
>
> 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 m
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.
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
additio
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
>
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:
> > Our
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 layer-by-lay
, Burton, Ross wrote:
> On 1 February 2018 at 15:03, Michael Habibi wrote:
>
>> So let's say my whole bbappend file is only necessary for the target
>> version. Can I rename the whole thing package-target.bbappend (add the
>> -target suffix) and it will only append i
something
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 wrote:
> On 1 February 2018 at 14:29, Michael Habibi wrote:
>
>> I'm sure this is really simple but I haven
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 modif
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 wrote:
> On 31 October 2017 at 14:15, Michael Habibi wrote:
>
>>
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 wrote:
> On Fri, Oct 27, 2017 at 11:59 AM, Michael Habibi
> wrote:
> > I'm a bit confu
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 distri
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
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
repeat
Excellent. Thanks! I knew using latest was going to burn me eventually :)
On Wed, Aug 24, 2016 at 5:51 AM, Ed Bartosh 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 play
>> around with th
I am running the master branch and trying to run toaster to play
around with the web interface (already successfully completed a build
w/o toaster setup).
I followed the instructions in the documentation. I created a
virtualenv, sourced/activated my virtualenv, and while under venv I
did a pip ins
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
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 que
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; \
Unfortunately I don't think this will work well, because generally http
protocol URLs are slightly different than git protocol URLs. However, in my
work environment, our firewall blocks git protocol. This means that for all
mirrors that do not include an http protocol mirror, the recipe will
outrig
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 functio
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, Mi
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 d
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 begi
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. mymachine-distro-li
015 at 21:16, Michael Habibi 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 all your source, or a repo
>> with all of your sourc
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 tarba
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 bought the beaglebone book
Yes you're right thanks for correcting - I meant rootfs!
On Sat, Dec 5, 2015 at 3:23 PM, Paul Eggleton wrote:
> Hi Michael,
>
> On Tue, 01 Dec 2015 09:26:15 Michael Habibi wrote:
> > I am working on potentially migrating our distribution to Yocto (will be
> a
> > lo
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 the
This is perfect, thanks Bryan.
On Fri, Dec 4, 2015 at 8:03 AM, Bryan Evenson
wrote:
> Michael,
>
> > -Original Message-
> > From: Michael Habibi [mailto:mikehab...@gmail.com]
> > Sent: Thursday, December 03, 2015 5:54 PM
> > To: Bryan Evenson
> > Cc
copy them
to ${S}? Or is this something I need to do?
Thanks,
Michael
On Tue, Dec 1, 2015 at 2:03 PM, Michael Habibi wrote:
> Thanks Bryan!
>
> On Tue, Dec 1, 2015 at 1:50 PM, Bryan Evenson
> wrote:
>
>> Michael,
>>
>> > -Original Message-
>>
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 wrote:
> On 2015-12-03 09:24, Michael Habibi wrote:
>
>> All,
>>
>> I have interest i
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
kernel
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 wrote:
> Hi Michael,
>
> On Wed, 02 Dec 2015 09:41:41 Michael Habibi wrote:
> > I'm struggling with some network proxy issues and pulling down
>
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 useful
Thanks Bryan!
On Tue, Dec 1, 2015 at 1:50 PM, Bryan Evenson
wrote:
> Michael,
>
> > -Original Message-
> > From: yocto-boun...@yoctoproject.org [mailto:yocto-
> > boun...@yoctoproject.org] On Behalf Of Michael Habibi
> > Sent: Tuesday, December 0
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
di
dded-core/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 similar
will also work without finding any data. 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
wrote:
> Mark, I am continuing to look at this. I hope you don
ng one.
On Wed, Nov 25, 2015 at 4:58 PM, Michael Habibi
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
ython-2.7.9/Lib/plat-linux2
/projects/yocto-git/build/tmp/sysroots/x86_64-linux/usr/bin/python-native/python2.7
-S -m sysconfig --generate-posix-vars
bash$ ls pybuilddir.txt
pybuilddir.txt
Maybe I'm missing something.
On Wed, Nov 25, 2015 at 4:38 PM, Mark Hatle
wrote:
> On 11/25/15 1
shot!
On Wed, Nov 25, 2015 at 10:01 AM, Michael Habibi
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
on2.7 needs to be pointing to the absolute path instead of relying on
$PATH.
On Wed, Nov 25, 2015 at 9:45 AM, Michael Habibi
wrote:
> For what it's worth, this is the offending portion of Makefile.pre:452:
>
> # Create build directory and generate the sysconfig bu
o execute a target
> 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
All,
I added a new machine definition with tuning parameters for haswell
microarchitectures (basically just duplicated corei7 but tuned it for
haswell). This seems to work correctly, but failed when running do_install
for python toward the end of the build process. I am running with the Yocto
2.0
27;ll
have what they need 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
wrote:
> Hi Michael,
>
> See my replies below.
>
> On 11/10/2015 02:27 PM, Michael Habibi wrote:
>
>
>>
>> This is f
Thanks for the great info Randy.
On Tue, Nov 10, 2015 at 6:06 PM, Randy Witt
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 into Yocto/BB/OE as a
>> potential
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 confs/recipes/class
50 matches
Mail list logo
