On 12-12-16 16:20, Robert P. J. Day wrote:
(if there's already a doc section for this somewhere, a pointer to
it would be just ducky.)
if one is building an image for a releasable, commercial product,
and that image involves pulling in numerous layers, then dumping all
sorts of proprietary
On 09-12-16 16:13, Patrick Ohly wrote:
Hello everyone!
Thanks for contributing directly to the page. It's great to see this
done collaboratively.
Nice informative page.
Only thing lacking is simple, OE-built in upgrade procedures like: "Just run
'opkg update && opkg upgrade'"
Kind regar
On Tue, 2016-12-13 at 09:51 +0100, Mike Looijmans wrote:
> On 09-12-16 16:13, Patrick Ohly wrote:
> > Hello everyone!
> >
> > Thanks for contributing directly to the page. It's great to see this
> > done collaboratively.
>
> Nice informative page.
>
> Only thing lacking is simple, OE-built in up
Hello Juro,
first off, thanks for taking the kick, whatever its count is.
On 12.12.2016 23:15, Bystricky, Juro wrote:
Building of Zephyr images in Yocto can now be done fairly unobtrusively
via a new layer "meta-zephyr" and specifying a new distro in local.conf:
DISTRO="zephyr"
Leaving out th
On 12/12/2016 1:02 PM, Patrick Ohly wrote:
On Mon, 2016-12-12 at 09:49 -0600, Mariano Lopez wrote:
On 12/12/16 09:41, Patrick Ohly wrote:
On Mon, 2016-12-12 at 08:59 -0600, Mariano Lopez wrote:
In particular the "complexity" column is a bit subjective. Stefano, I
hope you don't mind that I d
Hi,
I have got around to updating these recipes and found a few issues:
asterisk has a autoconf macro file for pjproject in ./third-party/pjproject/,
which does not get picked up by autobuild.bbclass.
This uses find with a -maxdepth of 2 but but 3 would be needed. I found a temp
fix by cop
Thanks, good point. The need for is poky.conf historic, not really needed at
all anymore.
From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Monday, December 12, 2016 4:00 PM
To: Bystricky, Juro
Cc: Philip Balister ; yocto@yoctoproject.org
Subject: Re: [yocto] meta-zephyr layer
On 12 Dece
Hello Josef,
I will find a better place for the meta-zephyr repository eventually.
As for your patches, I would definitely like to see them.
I added the cortex-m3 tune as one of the last steps, just to get
the Zephyr ARM test suite to pass. It works well, but probably
not an optimal implementation
RMC was previously configured to work only with the systemd-boot EFI
bootloader. With this commit we can specify alternative bootloaders by
setting the RMC_BOOTLOADER variable in local.conf. If RMC_BOOTLOADER is
not set systemd-boot will be used by default.
Example for grub-efi:
RMC_BOOTLOADER =
RMC was previously configured to work only with the systemd-boot EFI
bootloader. With this commit we can specify alternative bootloaders by
setting the RMC_BOOTLOADER variable in local.conf. If RMC_BOOTLOADER is
not set systemd-boot will be used by default.
Signed-off-by: Todor Minchev
---
Remove
> On Dec 13, 2016, at 2:56 PM, Todor Minchev
> wrote:
>
> RMC was previously configured to work only with the systemd-boot EFI
> bootloader. With this commit we can specify alternative bootloaders by
> setting the RMC_BOOTLOADER variable in local.conf. If RMC_BOOTLOADER is
> not set systemd-boo
On Tue, 2016-12-13 at 16:22 -0800, Jianxun Zhang wrote:
> > On Dec 13, 2016, at 2:56 PM, Todor Minchev
> > wrote:
> >
> > RMC was previously configured to work only with the systemd-boot EFI
> > bootloader. With this commit we can specify alternative bootloaders by
> > setting the RMC_BOOTLOADER
The new meta-zephyr is work based on previous original work by
Randy Witt and Richard Purdie, so it is actually a second kick at the can.
One of the things I did when I originally put this together that could now
change is qemuzephyrrunner.py which is used in the tests. I did it because
runqe
I like where this is heading but does RMC function with bootloaders
besides systemd-boot yet?
A quick boot test with this patch and RMC_BOOTLOADER = "grub-efi" seems
to give me vanilla grub-efi.
Thanks,
Cal
On 12/13/2016 04:50 PM, Todor Minchev wrote:
On Tue, 2016-12-13 at 16:22 -0800, Jianxu
I have found what I think is a sneaky nasty bug when using package_deb with
SSTATE_MIRRORS on RPM based build hosts. Below is a short description of what
I found and our workaround. A patch that adds a patch that is applied to the
packager that packages the real packager. To avoid this sneaking fa
15 matches
Mail list logo
