On 02/28/2018 07:41 PM, Alexander Kanavin wrote:
On 02/28/2018 07:56 AM, Chen Qi wrote:
Upgrade systemd to 236.
Latest upstream release is 237, should we use that?
Alex
Thanks for reminding me of this.
I'll try to use the latest 237 version in V2.
Best Regards,
Chen Qi
--
On 02/28/2018 09:32 PM, Burton, Ross wrote:
No, still broken:
ERROR: systemd-boot-236-r0 do_compile: oe_runmake failed
ERROR: systemd-boot-236-r0 do_compile: Function failed: do_compile
(log file is located at
/data/poky-tmp/master/work/corei7-64-intel-common-poky-linux/systemd-boot/236-r0/tem
Hi Cal,
On 03/01/2018 10:15 AM, California Sullivan wrote:
> This way we could theoretically support multiple bootloaders, and we
> keep the convention of boot(x64|ia32).
>
> Signed-off-by: California Sullivan
> ---
> meta/recipes-bsp/grub/grub-efi_2.02.bb | 13 -
> 1 file changed,
We can't guarantee vmlinuz anymore. Use KERNEL_IMAGETYPE instead.
Signed-off-by: California Sullivan
---
meta/classes/systemd-boot-cfg.bbclass | 6 +-
meta/classes/systemd-boot.bbclass | 2 +-
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/meta/classes/systemd-boot-cfg.bb
This class is useful on its own and can be used to create configuration
recipes.
Signed-off-by: California Sullivan
---
...stemd-boot.bbclass => systemd-boot-cfg.bbclass} | 57 --
meta/classes/systemd-boot.bbclass | 70 +-
2 files changed, 1 i
Previously this wasn't needed because the kernel was added at image
creation time to the boot partition. Now that the boot partition is
created from the /boot/ partition of the rootfs, it needs to be
installed there.
Signed-off-by: California Sullivan
---
meta/recipes-core/packagegroups/packageg
We can't guarantee the kernel will be named vmlinuz anymore. Use
KERNEL_IMAGETYPE instead.
Signed-off-by: California Sullivan
---
meta/classes/syslinux.bbclass | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/meta/classes/syslinux.bbclass b/meta/classes/syslinux.bbclass
ind
Using --exclude-path and a wks.in file we can create an image that takes
the /boot/ directory for the boot partition, has an empty /boot/
directory in the rootfs partition. The boot partition gets mounted to
/boot/ after startup.
Signed-off-by: California Sullivan
---
scripts/lib/wic/canned-wks/
We can no longer rely on the kernel having a static name of "vmlinuz".
This means we can't use it as a sentinel value in our sed commands, and
we can't just copy vmlinuz to the boot directory.
Instead, we'll use "root=" as the sentinel value for our sed commands,
and we'll search for common kernel
Rather than renaming the kernel to vmlinuz and assuming the name is
vmlinuz in the grub.cfg, copy to ${KERNEL_IMAGETYPE} and also use that
value in the grub.cfg file.
Signed-off-by: California Sullivan
---
meta/classes/grub-efi-cfg.bbclass | 4 +++-
meta/classes/grub-efi.bbclass | 2 +-
2 fi
Reuses our systemd-boot-cfg bbclass to generate systemd-boot
configuration files.
Signed-off-by: California Sullivan
---
meta/recipes-core/systemd/systemd-bootconf_1.00.bb | 31 ++
1 file changed, 31 insertions(+)
create mode 100644 meta/recipes-core/systemd/systemd-bootconf
Since kernels will not necessarily be installed as vmlinuz anymore,
don't assume that's its name for either the bootloader config or the
copy of the kernel.
Also, allow installing multiple kernels by searching for common kernel
names.
Signed-off-by: California Sullivan
---
.../initrdscripts/fil
There's no need to add to the local copy of overrides and then not do
anything with it.
Now that this function is being used in package creation it was causing
sstate issues as well, as MACHINE is always in OVERRIDES, so something
trivial such as the name of the MACHINE would cause the hash to cha
If the EFI_PROVIDER is systemd-boot, install as boot(x64|ia32) as per
convention. If its not the EFI_PROVIDER, install as
systemd-boot(x64|ia32), as to not collide with other possible
bootloaders.
Signed-off-by: California Sullivan
---
meta/recipes-core/systemd/systemd-boot_234.bb | 28 +
The bootloaders depend on these to be functional in the non-deploy case,
but changes in them don't require rebuilding of the packages.
Signed-off-by: California Sullivan
---
meta/conf/layer.conf | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/conf/layer.conf b/meta/conf/layer.conf
ind
There's no need to add to the local copy of overrides and then not do
anything with it.
Now that this function is being used in package creation it was causing
sstate issues as well, as MACHINE is always in OVERRIDES, so something
trivial such as the name of the MACHINE would cause the hash to cha
Simple test case that adds 'efi' to MACHINE_FEATURES, sets WKS_FILE to
"efi-bootdisk.wks.in", installed required boot items, and attempts to
boot the wic image.
Quick check to make sure that the feature actually works.
Signed-off-by: California Sullivan
---
meta/lib/oeqa/selftest/cases/efibootp
This part is useful on its own, whereas the whole class together is
specific for image-live.
Signed-off-by: California Sullivan
---
.../{grub-efi.bbclass => grub-efi-cfg.bbclass} | 40 ---
meta/classes/grub-efi.bbclass | 122 +
2 files changed, 1
Since /boot/ will be recipe/package controlled now we can't just deploy.
Signed-off-by: California Sullivan
---
meta/recipes-bsp/grub/grub-bootconf_1.00.bb | 2 +-
meta/recipes-bsp/grub/grub-efi_2.02.bb | 34 +++--
2 files changed, 28 insertions(+), 8 deletions(-)
Signed-off-by: California Sullivan
---
meta/conf/distro/include/maintainers.inc | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/conf/distro/include/maintainers.inc
b/meta/conf/distro/include/maintainers.inc
index 50392487903..ba5e6137e77 100644
--- a/meta/conf/distro/include/maintaine
Since the bootloader is now installed instead of added at image creation
time, this is necessary for booting.
Also set the default to grub-efi. This is done because a default of
grub-efi is already used by live-vm-common.bbclass, and in the event
that EFI_PROVIDER isn't defined errors would occur.
I can't find VM_DEFAULT_KERNEL used anywhere else, and we should not be
statically installing the kernel as vmlinuz.
Signed-off-by: California Sullivan
---
meta/classes/live-vm-common.bbclass | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/meta/classes/live-vm-common
EFI images require a boot partition containing the bootloader, the
kernel, the bootloader configuration, and any other EFI binaries that
your platform needs. Currently, the boot partition is done at image
creation time rather than through packages, making it very difficult to
add to its contents. A
This way we could theoretically support multiple bootloaders, and we
keep the convention of boot(x64|ia32).
Signed-off-by: California Sullivan
---
meta/recipes-bsp/grub/grub-efi_2.02.bb | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/meta/recipes-bsp/grub/grub-e
This makes use of the grub-efi-cfg bbclass that was split out to create
a grub.cfg file just like the old one.
Signed-off-by: California Sullivan
---
meta/recipes-bsp/grub/grub-bootconf_1.00.bb | 29 +
1 file changed, 29 insertions(+)
create mode 100644 meta/recipes-
Ping.
// Robert
On 02/02/2018 11:23 AM, Robert Yang wrote:
The qemuboot.conf uses configparser which can't suport upper case as key, and
json is more clearer than configparser and is widely used in oe-core, so use
qemuboot.json to replace qemuboot.conf.
// Robert
The following changes since c
0001-tune-octeon-change-Octeon-II-to-soft-float.patch
Description: Binary data
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
0.3.5 -> 0.3.6
Patches:
- Add support for tar versions that don't support --sort
- Use local time when setting the modication time on the archives
Signed-off-by: Alejandro del Castillo
---
...rt-name-on-versions-of-tar-which-support-.patch | 54 ++
...Use-local-time-for-bu
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Francesco Giancane
> Sent: den 28 februari 2018 23:09
> To: openembedded-core@lists.openembedded.org
> Subject: [OE-core] [meta-oe][PATCH
Hi,
Sorry again. The patch was based on openembedded-core rather than poky, and
this is why the patchwork failed to apply it.
This should be the last one.
Thanks for the patience,
Francesco Giancane
2018-02-28 23:08 GMT+01:00 Francesco Giancane
:
> libepoxy 1.4.3 did not compile successfully
libepoxy 1.4.3 did not compile successfully because of
implicit symbol definitions and link-time errors.
A new recipe with latest libepoxy release (1.5.0) which
successfully compiles is provided.
Patch to disable 'dlvsym' has also been forward-ported
to be applicable to version 1.5.0.
The patch 'A
== Series Details ==
Series: libepoxy: New recipe updated to latest release (rev2)
Revision: 2
URL : https://patchwork.openembedded.org/series/11150/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests hav
On 2018-02-28 4:10 PM, Mark Hatle wrote:
One question, below inline:
On 2/28/18 1:20 PM, Bruce Ashfield wrote:
The existing kernel-devsrc package starts with a full copy of the kernel
source and then starts to strip out elements that are not required.
This results in extra time (I/O) and extra
One question, below inline:
On 2/28/18 1:20 PM, Bruce Ashfield wrote:
> The existing kernel-devsrc package starts with a full copy of the kernel
> source and then starts to strip out elements that are not required.
>
> This results in extra time (I/O) and extra space being taken up in the
> final
== Series Details ==
Series: glibc: Enable static PIE support
Revision: 1
URL : https://patchwork.openembedded.org/series/11152/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been executed on th
== Series Details ==
Series: opkg & opkg-utils upgrade to 0.3.6 (rev2)
Revision: 2
URL : https://patchwork.openembedded.org/series/11058/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been execu
Hi,
Thank you for the review.
I took the opportunity to re-check my patch, as requested:
- removed old version;
- updated the patches for 1.5.0 version of the library;
- fixed configure-time flags;
- tested again.
Everything seems OK now.
a PATCH v2 shall follow.
Thanks,
Francesco Giancane
201
libepoxy 1.4.3 did not compile successfully because of
implicit symbol definitions and link-time errors.
A new recipe with latest libepoxy release (1.5.0) which
successfully compiles is provided.
Patch to disable 'dlvsym' has also been forward-ported
to be applicable to version 1.5.0.
The patch 'A
go programs when compiled with PIE fails otherwise on aarch64
Signed-off-by: Khem Raj
---
meta/recipes-core/glibc/glibc_2.27.bb | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-core/glibc/glibc_2.27.bb
b/meta/recipes-core/glibc/glibc_2.27.bb
index e9d4117a47..62db3e9d02 100644
-
On Wed, Feb 28, 2018 at 12:33 PM, Matt Madison wrote:
> On Wed, Feb 28, 2018 at 11:48 AM, Khem Raj wrote:
>> On Tue, Feb 27, 2018 at 4:36 AM, Matt Madison wrote:
>>> * Patches and recipes reworked for go 1.10's significant
>>> changes to its bootstrap and build steps
>>>
>>> * Update go1.4 sou
0.3.5 -> 0.3.6
Patches:
- Add support for tar versions that don't support --sort
- Use local time when setting the modication time on the archives
Signed-off-by: Alejandro del Castillo
---
Changes since V1:
- Add patch to support versions of tar that don't support --sort
- Add patch to corr
On Wed, Feb 28, 2018 at 11:48 AM, Khem Raj wrote:
> On Tue, Feb 27, 2018 at 4:36 AM, Matt Madison wrote:
>> * Patches and recipes reworked for go 1.10's significant
>> changes to its bootstrap and build steps
>>
>> * Update go1.4 source tarball used for go-native
>> bootstrapping to the versi
Please also delete the old release.
Ross
On 28 February 2018 at 18:42, Francesco Giancane <
francescogianca...@gmail.com> wrote:
> libepoxy 1.4.3 did not compile successfully because of
> implicit symbol definitions and link-time errors.
> A new recipe with latest libepoxy release (1.5.0) which
On Tue, Feb 27, 2018 at 4:36 AM, Matt Madison wrote:
> * Patches and recipes reworked for go 1.10's significant
> changes to its bootstrap and build steps
>
> * Update go1.4 source tarball used for go-native
> bootstrapping to the version recommended
> in the current go documentation
>
> * R
The existing kernel-devsrc package starts with a full copy of the kernel
source and then starts to strip out elements that are not required.
This results in extra time (I/O) and extra space being taken up in the
final package. The main purpose of the kernel-devsrc package has been to
build modules
libepoxy 1.4.3 did not compile successfully because of
implicit symbol definitions and link-time errors.
A new recipe with latest libepoxy release (1.5.0) which
successfully compiles is provided.
Signed-off-by: Francesco Giancane
---
meta/recipes-graphics/libepoxy/libepoxy_1.5.0.bb | 24
From: Joshua Watt
Generating the host keys atomically prevents power interruptions during the
first boot from leaving the key files incomplete, which often prevents users
from being able to ssh into the device.
[YOCTO #11671]
Signed-off-by: Joshua Watt
Signed-off-by: Ross Burton
Signed-off-by
Yes, that is the root cause. I did file a bug a while ago:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=12273
It is a race, I put the libraries in a hidden file, hoping they would not be
found.
I also considered linking the tests statically (which would eliminate the need
for the shared lib
On 02/28/2018 11:51 AM, Bruce Ashfield wrote:
Unfortunately, I can't reproduce that here.
This has been built and tested on all arches by myself and others, but
I can try again .. just no promises when I'll get back to it.
Ahaha. 32 bit ARM with a little bit of a manual hack on my machine
and
So the problem is that dbus-test has a libdbus-1.so.3 and if it is built
after dbus then it wins the race for "who provides libdbus.so". Obviously
this isn't right, I'm testing a fix now using PRIVATE_LIBS and want to file
a bug to fix this behviour in 2.6.
Ross
On 28 February 2018 at 14:54, Max
On 02/28/2018 06:20 PM, Niko Mauno wrote:
When running bitbake -c populate_sdk , it is expected that
packages matching SDKIMAGE_INSTALL_COMPLEMENTARY name mask (unless
declared in PACKAGE_EXCLUDE_COMPLEMENTARY) are installed to resulting
SDK. Underlying mechanism issues a package manager install
Unfortunately, I can't reproduce that here.
This has been built and tested on all arches by myself and others, but
I can try again .. just no promises when I'll get back to it.
Bruce
On 02/28/2018 11:38 AM, Burton, Ross wrote:
Sorry, but this breaks on ARM:
ERROR: kernel-devsrc-1.0-r0 do_inst
Sorry, but this breaks on ARM:
ERROR: kernel-devsrc-1.0-r0 do_install: Function failed: do_install (log
file is located at
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-arm/build/build/tmp/work/qemuarm-poky-linux-gnueabi/kernel-devsrc/1.0-r0/temp/log.do_install.25822)
ERROR: Logfile of fa
When running bitbake -c populate_sdk , it is expected that
packages matching SDKIMAGE_INSTALL_COMPLEMENTARY name mask (unless
declared in PACKAGE_EXCLUDE_COMPLEMENTARY) are installed to resulting
SDK. Underlying mechanism issues a package manager install call for set
of complementary packages. Howe
On Wed, Feb 28, 2018 at 12:46 AM, ChenQi wrote:
> On 02/28/2018 04:29 PM, Khem Raj wrote:
>>
>> On Tue, Feb 27, 2018 at 9:56 PM, Chen Qi wrote:
>>>
>>> Remove the 'fstack-protector' and 'fstack-protector-strong' flags
>>> as a workaround to fix the following error when building for qemux86
>>> an
Remove unused patch:
0001-openssh-Fix-syntax-error-on-x32.patch
Signed-off-by: Maxin B. John
---
.../0001-openssh-Fix-syntax-error-on-x32.patch | 33 --
1 file changed, 33 deletions(-)
delete mode 100644
meta/recipes-connectivity/openssh/openssh/0001-openssh-Fix
Hi,
On Tue, Feb 27, 2018 at 12:19:26PM -0800, Juro Bystricky wrote:
> The result of running dbus-test-ptest was a series of
> various segfaults, interpreted as FAILs. This was a direct consequence
> of the test suite loading the installed shared library libdbus-1.so, not the
> one built along the
On Wed, 2018-02-28 at 14:14 +, Richard Purdie wrote:
> On Tue, 2018-02-27 at 16:47 -0600, Joshua Watt wrote:
> > Wildcard support in SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS allows the
> > native
> > tools that were in a hardcoded list to be specified in layer.conf
> > with
> > the other exclusions.
>
On Tue, 2018-02-27 at 16:47 -0600, Joshua Watt wrote:
> Wildcard support in SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS allows the native
> tools that were in a hardcoded list to be specified in layer.conf
> with
> the other exclusions.
I was always reluctant to add wildcard support to this but it does make
s
No, still broken:
ERROR: systemd-boot-236-r0 do_compile: oe_runmake failed
ERROR: systemd-boot-236-r0 do_compile: Function failed: do_compile (log
file is located at
/data/poky-tmp/master/work/corei7-64-intel-common-poky-linux/systemd-boot/236-r0/temp/log.do_compile.31074)
ERROR: Logfile of failur
ERROR: systemd-boot-236-r0 do_compile: Function failed: do_compile (log
file is located at
/data/poky-tmp/master/work/corei7-64-intel-common-poky-linux/systemd-boot/236-r0/temp/log.do_compile.10165)
ERROR: Logfile of failure stored in:
/data/poky-tmp/master/work/corei7-64-intel-common-poky-linux/sy
Looks like a multilib issue. I'll fix it up and send out a v3.
Thanks,
-Matt
On Wed, Feb 28, 2018 at 3:44 AM, Richard Purdie
wrote:
> On Wed, 2018-02-28 at 08:42 -0300, Otavio Salvador wrote:
>> On Wed, Feb 28, 2018 at 8:37 AM, Richard Purdie
>> wrote:
>> >
>> > On Wed, 2018-02-28 at 10:47 +00
On 02/28/2018 07:56 AM, Chen Qi wrote:
Upgrade systemd to 236.
Latest upstream release is 237, should we use that?
Alex
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/open
On Wed, 2018-02-28 at 08:42 -0300, Otavio Salvador wrote:
> On Wed, Feb 28, 2018 at 8:37 AM, Richard Purdie
> wrote:
> >
> > On Wed, 2018-02-28 at 10:47 +, Richard Purdie wrote:
> > >
> > > On Tue, 2018-02-27 at 14:16 -0300, Otavio Salvador wrote:
> > > > tested it in -next, one issue:
> > >
On Wed, Feb 28, 2018 at 8:37 AM, Richard Purdie
wrote:
> On Wed, 2018-02-28 at 10:47 +, Richard Purdie wrote:
>> On Tue, 2018-02-27 at 14:16 -0300, Otavio Salvador wrote:
>> >
>> > On Tue, Feb 27, 2018 at 9:36 AM, Matt Madison > > >
>> > wrote:
>> > >
>> > >
>> > > New in v2:
>> > > * Fixe
The recipe depends on many machine specific tasks and should be marked
as machine specific itself. This fixes signature tests after some dependency
issues were fixed at the bitbake level which exposed that issue.
Signed-off-by: Richard Purdie
---
meta/recipes-core/meta/meta-world-pkgdata.bb | 2
On Wed, 2018-02-28 at 10:47 +, Richard Purdie wrote:
> On Tue, 2018-02-27 at 14:16 -0300, Otavio Salvador wrote:
> >
> > On Tue, Feb 27, 2018 at 9:36 AM, Matt Madison > >
> > wrote:
> > >
> > >
> > > New in v2:
> > > * Fixed Upstream-Status line in go patches
> > > * Added GOTMPDIR
Packages with a different architecture will be installed in a different
multilib workdir.
When those packages are updated, it will remove the files from the default
workdir,
but not from the multilib workdir.
This will throw a file exists error later on.
Remove the files from the multilib workdir
On Tue, 2018-02-27 at 14:16 -0300, Otavio Salvador wrote:
> On Tue, Feb 27, 2018 at 9:36 AM, Matt Madison
> wrote:
> >
> > New in v2:
> > * Fixed Upstream-Status line in go patches
> > * Added GOTMPDIR to do_configure[dirs]
> >
> > Updates to the go recipes and bbclasses for go1.10, whic
== Series Details ==
Series: staging: remove files from multilib workdir
Revision: 1
URL : https://patchwork.openembedded.org/series/11134/
State : failure
== Summary ==
Thank you for submitting this patch series to OpenEmbedded Core. This is
an automated response. Several tests have been exe
Packages with a different architecture will be installed in a different
multilib workdir.
When those packages are updated, it will remove the files from the default
workdir,
but not from the multilib workdir.
This will throw a file exists error later on.
Remove the files from the multilib workdir
On 02/28/2018 04:25 PM, Khem Raj wrote:
On Tue, Feb 27, 2018 at 9:56 PM, Chen Qi wrote:
We should use the value of CC for the c compiler setting in cross
compilation configuration file for meson. For example, if we only
use ${HOST_PREFIX}gcc instead of ${CC}, we would meet the following
do_comp
On 02/28/2018 04:29 PM, Khem Raj wrote:
On Tue, Feb 27, 2018 at 9:56 PM, Chen Qi wrote:
Remove the 'fstack-protector' and 'fstack-protector-strong' flags
as a workaround to fix the following error when building for qemux86
and qemuppc with musl.
undefined reference to `__stack_chk_fail_loca
On Tue, Feb 27, 2018 at 9:56 PM, Chen Qi wrote:
> Remove the 'fstack-protector' and 'fstack-protector-strong' flags
> as a workaround to fix the following error when building for qemux86
> and qemuppc with musl.
>
> undefined reference to `__stack_chk_fail_local'
>
> Signed-off-by: Chen Qi
> --
On Tue, Feb 27, 2018 at 9:56 PM, Chen Qi wrote:
> We should use the value of CC for the c compiler setting in cross
> compilation configuration file for meson. For example, if we only
> use ${HOST_PREFIX}gcc instead of ${CC}, we would meet the following
> do_compile failure for systemd.
>
> cc1:
75 matches
Mail list logo
