Great! Would you be willing to accept a patch that makes arch-x86_64.c
handle that condition like the other arches?
-Shane
On Fri, May 24, 2019 at 12:27 PM Khem Raj wrote:
>
>
> On 5/24/19 8:10 AM, Shane Peelar wrote:
> > I did some reading into the sources in other architectures. The
Hello,
In my recipe, I've found that a forward slash in SRCBRANCH, results in an
error during the final image construction,
SRCBRANCH = "feature/compile_with_gcc7_4_rocko_toolchain"
Error given:
Collected errors:
* opkg_prepare_url_for_install: Couldn't find anything to satisfy
'tron-app'.
Hi Khem,
> -Original Message-
> From: Khem Raj [mailto:raj.k...@gmail.com]
> Sent: Thursday, May 23, 2019 07:11 PM
> To: Rudolf Streif ; Greg Wilson-Lindberg
>
> Cc: Yocto list discussion
> Subject: Re: [yocto] problem adding a user
>
>
>
> On 5/23/19 1:40 PM, Rudolf Streif wrote:
>
On Fri, May 24, 2019 at 12:27 PM Mauro Ziliani wrote:
>
> Hi all.
>
> How can I ask to bitbake which is the actual value of virtual/kernel?
>
Here's one way:
bitbake -e virtual/kernel | grep PREFERRED_PROVIDER_virtual\/kernel
# $PREFERRED_PROVIDER_virtual/kernel [2 operations]
On 5/24/19 8:10 AM, Shane Peelar wrote:
I did some reading into the sources in other architectures. The closest
match, arch_i386.c, makes the write conditional as you say.
So do other arches, including |arch_arm.c, |arch_sh.c, |arch-mips.c,
|arch-s390.c, |arch-s390x.c, and
Hi all.
How can I ask to bitbake which is the actual value of virtual/kernel?
Thanks all
MZ
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
YUP! Thank you for the fix (I totally forgot about scripts directory).
Command: make scripts prepare solved it all!
Here is all captured (in order of execution):
https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/Issues/LKM/prepare_modules.log
These bugzillas will be still nice to
I did some reading into the sources in other architectures. The closest
match, arch_i386.c, makes the write conditional as you say.
So do other arches, including arch_arm.c, arch_sh.c, arch-mips.c, arch-s390.c,
arch-s390x.c, and arch-ia64.c.
Notably, arch-cris.c has the same assert as
Is there no way to simply force bitbake to only build the packages I want,
ignoring dependencies? We used to build the image like this before, using
PTXDist.
Everything else seems to be a dirty hack.
Mit freundlichen Grüßen / Best regards
Norman Stetter
SW ENWICKLUNG EMBEDDED SYSTEMS
Garz &
On Fri, May 24, 2019 at 8:50 AM Bruce Ashfield
wrote:
>
>
> On Fri, May 24, 2019 at 7:24 AM Zoran Stojsavljevic <
> zoran.stojsavlje...@gmail.com> wrote:
>
>> As I said, I am a man of experimental try-outs. And here is the try!
>>
>> Now, after setting sources, I tried to compile the example
> I'm going to create two new optional packages for the fall release
> that are simply captured kernel-source and kernel-headers for
> those uses cases where someone really does want the entire
> source tree, or just the headers. The details for that work are in
> bugzilla.
Could you, please,
On Fri, May 24, 2019 at 7:24 AM Zoran Stojsavljevic <
zoran.stojsavlje...@gmail.com> wrote:
> As I said, I am a man of experimental try-outs. And here is the try!
>
> Now, after setting sources, I tried to compile the example (from my Git):
>
On Thu, May 23, 2019 at 9:00 PM Khem Raj wrote:
>
>
> On 5/23/19 3:32 AM, Zoran Stojsavljevic wrote:
> > After some tests (and I had other problems to take care of, as well),
> > here is the following:
> >
> >> These have all been discussed off an on over the past 5 years.
> >> I can't get at
As I said, I am a man of experimental try-outs. And here is the try!
Now, after setting sources, I tried to compile the example (from my Git):
https://github.com/ZoranStojsavljevic/bbb-yocto/tree/master/Issues/LKM
The results are the following (all on the target):
root@beaglebone:~# pwd
In fact the OS is just a minimal rescue OS. On a second partition we run our
main OS, which is ‘properly’ installed.
So, I’m afraid using a ‘proper’ file system wouldn’t fit our use case. We run
the rescue OS as RAMdisk to be able to self-update it without having to worry
about modifying a
Hi Paul,
I understood what you are trying to say but from where does the
Yocto pick up the contents for a directory in final rootfs image. Is there any
recipe file in which I can find this. For example: do_install() etc.
I also came to know from you that I need a recipe for adding
On Fri, 24 May 2019, at 11:02, Tg, Harish wrote:
> Hi Paul,
>I understood what you are trying to say but from where
> does the Yocto pick up the contents for a directory in final rootfs
> image. Is there any recipe file in which I can find this. For example:
> do_install() etc.
On Fri, 24 May 2019, at 10:14, Tg, Harish wrote:
> Kindly help me out in locating the source for /usr/bin of rootfs image
> in yocto. I did a find but I do not see the /usr/bin and its exact
> contents as in the rootfs image. I need to locate this badly as this
> would help in adding the
On Fri, 24 May 2019 at 07:30, Norman Stetter
wrote:
> For the OS image I use cpio.gz as file system. It gets booted as a
> RAMdisk. Sorry, forgot to mention that.
>
Would you consider switching to a proper filesystem? The peril of using a
cpio.gz is that every file you add slows the boot down:
The meta-intel BSP is the recommend BSP for all Intel platfoms.
Ross
On Fri, 24 May 2019 at 10:30, Ranran wrote:
>
> Hello,
>
> I searched for ATOM N450 recipe, but only found very old one:
> https://old.yoctoproject.org/downloads/bsps/edison11/atom-pc
> The problem is that we need newer gcc
Hello,
I searched for ATOM N450 recipe, but only found very old one:
https://old.yoctoproject.org/downloads/bsps/edison11/atom-pc
The problem is that we need newer gcc (above 4.8.2).
Should it be better to just use generic x86 recipe ?
Kindly help me out in locating the source for /usr/bin of rootfs image in
yocto. I did a find but I do not see the /usr/bin and its exact contents as in
the rootfs image. I need to locate this badly as this would help in adding the
commands to the folder which would be finally added to the
Ok, thanks.
On Fri 24 May, 2019, 2:12 PM Burton, Ross, wrote:
> On Thu, 23 May 2019 at 10:43, virendra kumar thakur
> wrote:
> > But I can see in
> rootfs/usr/share/common-license/package/libgcrypt-lic/recipeinfo
> >
> > LICENSE: GPLV2+ + +
> > PR: r0
> > PV : 1.8.4
>
> At a guess, because the
On Thu, 23 May 2019 at 10:43, virendra kumar thakur
wrote:
> But I can see in
> rootfs/usr/share/common-license/package/libgcrypt-lic/recipeinfo
>
> LICENSE: GPLV2+ + +
> PR: r0
> PV : 1.8.4
At a guess, because the libgcrypt recipe is:
LICENSE = "GPLv2+ & LGPLv2.1+ & GPLv3+"
Whereas libgcrypt
Thank you khem raj for your input, I have already tried with
INCOMPATIBLE_LICENSE = "GPLv3+ LGPLv3+ AGPLv3+"
And this also
INCOMPATIBLE_LICENSE = "GPLv3* LGPLv3* AGPLv3*"
But no luck, still I can see same output
rootfs/usr/share/common-license/package/libgcrypt-lic/recipeinfo
LICENSE:
For the OS image I use cpio.gz as file system. It gets booted as a RAMdisk.
Sorry, forgot to mention that.
Building two different images doesn’t suit our use case. We install the image
on a device and run different automated test suites on it, some of which need
python. But for all of the
Hi Raj,
What I am asking you is that how the yocto picks up components for
/usr/bin folder of rootfs. Where do they exist before copying? I am sorry but I
feel I do not need to write a recipe for adding just one of the commands. It is
just that I need to add "ubiattach" to target
27 matches
Mail list logo
