Re: [OE-core] zimage Initramfs booting stuck at Start Kernel
Hi Ferry,
On 10/29/19, Ferry Toth wrote:
>> How did you build the cpio into the kernel?
>
> https://github.com/edison-fw/meta-intel-edison/blob/master/meta-intel-edison-bsp/conf/machine/edison.conf
Thank you for sharing the config, I added the same thing to my image configure:
INITRAMFS_MAXSIZE ="8"
INITRAMFS_FSTYPES = "cpio.gz"
But it doesn't seem any changes in zImage-initramfs format, still
stuck in Start Kernel. There is no cpio in zImage-initramfs format
either:
0 0x0 Linux kernel ARM boot executable zImage
(little-endian)
6904 0x1AF8 LZO compressed data
7316 0x1C94 LZO compressed data
7918 0x1EEE device tree image (dtb)
57505 0xE0A1 device tree image (dtb)
3123020x4C3EE LZ4 compressed data, legacy
2049266 0x1F44F2SHA256 hash constants, little endian
2372864 0x243500mcrypt 2.5 encrypted data, algorithm:
"]", keysize: 23701 bytes, mode: "(",
6093526 0x5CFAD6device tree image (dtb)
8127489 0x7C0401LZ4 compressed data, legacy
8167809 0x7CA181device tree image (dtb)
8211971 0x7D4E03device tree image (dtb)
8466697 0x813109LZ4 compressed data, legacy
10203615 0x9BB1DFSHA256 hash constants, little endian
10527221 0xA0A1F5mcrypt 2.5 encrypted data, algorithm:
"]", keysize: 23701 bytes, mode: "(",
14247896 0xD967D8device tree image (dtb)
16108284 0xF5CAFCLZ4 compressed data, legacy
16581064 0xFD01C8mcrypt 2.5 encrypted data, algorithm:
")}", keysize: 11556 bytes, mode: "|",
18187148 0x115838C PARity archive data - file number 12288
18412397 0x118F36D mcrypt 2.5 encrypted data, algorithm:
"*l", keysize: 20516 bytes, mode: "~",
18642426 0x11C75FA mcrypt 2.5 encrypted data, algorithm:
"9n", keysize: 2452 bytes, mode: "4",
19350585 0x1274439 ELF, 32-bit LSB ("")
19742605 0x12D3F8D ELF, 32-bit LSB ("")
22468397 0x156D72D ELF, 32-bit LSB processor-specific, ("")
22528640 0x157C280 ELF, 32-bit LSB processor-specific, ("")
22974723 0x15E9103 mcrypt 2.5 encrypted data, algorithm:
">", keysize: 2093 bytes, mode: "-",
23196848 0x161F4B0 ZBOOT firmware header, header size: 32
bytes, load address: 0x0564F721, start address: 0x2E4CEE95, checksum:
0x22771426, version: 0x1D216514, image size: 185068065 bytes
24899585 0x17BF001 LZMA compressed data, properties: 0x63,
dictionary size: 2097152 bytes, uncompressed size: 139006573920 bytes
24899761 0x17BF0B1 LZMA compressed data, properties: 0x6C,
dictionary size: 2097152 bytes, uncompressed size: 541203680 bytes
24899796 0x17BF0D4 LZMA compressed data, properties: 0x63,
dictionary size: 2097152 bytes, uncompressed size: 139810176352 bytes
24940767 0x17C90DF LZMA compressed data, properties: 0x5E,
dictionary size: 522190848 bytes, uncompressed size: 2157628 bytes
24946105 0x17CA5B9 LZMA compressed data, properties: 0xBE,
dictionary size: -1108672512 bytes, uncompressed size: 138831226112
bytes
24949352 0x17CB268 LZMA compressed data, properties: 0xC0,
dictionary size: -551550976 bytes, uncompressed size: 2117660 bytes
25029743 0x17DEC6F Copyright string: "Copyright 2017, NXP"
25827134 0x18A173E Unix path: /var/lib/systemd/
27216461 0x19F4A4D eCos RTOS string reference: "ECOS field"
27744796 0x1A75A1C SHA256 hash constants, little endian
27784033 0x1A7F361 mcrypt 2.5 encrypted data, algorithm:
"ute0^", keysize: 25971 bytes, mode: """,
28059592 0x1AC27C8 Base64 standard index table
28258932 0x1AF3274 SHA256 hash constants, little endian
29009250 0x1BAA562 Unix path: /lib/opkg/alternatives/cut
29091303 0x1BBE5E7 LZMA compressed data, properties: 0xB7,
dictionary size: 1572864 bytes, uncompressed size: 106573083904 bytes
31513153 0x1E0DA41 SHA256 hash constants, little endian
31800561 0x1E53CF1 PARity archive data - file number 1944
31937419 0x1E7538B gzip compressed data, from FAT
filesystem (MS-DOS, OS/2, NT), last modified: 1970-01-01 00:01:36
(bogus date)
32101039 0x1E9D2AF gzip compressed data, from FAT
filesystem (MS-DOS, OS/2, NT), last modified: 1970-01-01 00:01:36
(bogus date)
32127133 0x1EA389D gzip compressed data, from FAT
filesystem (MS-DOS, OS/2, NT), last modified: 1970-01-01 00:01:36
(bogus date)
32480356 0x1EF9C64 rzip compressed data - version 16.42
(881272744 bytes)
32537394 0x1F07B32 lrzip compressed data
32537406 0x1F07B3E LZ4 compressed data
32537413 0x1F07B45 LZ4 compressed data, legacy
32539866 0x1F084DA Gameboy ROM,
32540730 0x1F0883A EBML file
32660115 0x1F25A93 LHa 2.x? archive data [lh ] [N
[OE-core] Stable warrior decision
I decided to mark the qemu virgl issue on FC30 as a known issue as we saw it fail in 2.7.1. https://autobuilder.yocto.io/pub/releases/yocto-2.7.1.rc1/testresults/oe-selftest-fedora/testresults.json regards. Armin -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v2] binutils: CVE-2019-17450 and CVE-2019-17451
This patch fix the stack overflow issue for recursive call
and the segment fault issue.
Backport the two CVE pathces from the binutils upstream:
commit 336bfbeb1848f4b9558456fdcf283ee8a32d7fd1
commit 063c511bd79281f33fd33f0964541a73511b9e2b
Signed-off-by: Zhixiong Chi
---
.../binutils/binutils-2.32.inc| 2 +
.../binutils/binutils/CVE-2019-17450.patch| 107 ++
.../binutils/binutils/CVE-2019-17451.patch| 57 ++
3 files changed, 166 insertions(+)
create mode 100644 meta/recipes-devtools/binutils/binutils/CVE-2019-17450.patch
create mode 100644 meta/recipes-devtools/binutils/binutils/CVE-2019-17451.patch
diff --git a/meta/recipes-devtools/binutils/binutils-2.32.inc
b/meta/recipes-devtools/binutils/binutils-2.32.inc
index 19baf8a883..349c3e1154 100644
--- a/meta/recipes-devtools/binutils/binutils-2.32.inc
+++ b/meta/recipes-devtools/binutils/binutils-2.32.inc
@@ -49,6 +49,8 @@ SRC_URI = "\
file://CVE-2019-12972.patch \
file://CVE-2019-14250.patch \
file://CVE-2019-1.patch \
+ file://CVE-2019-17450.patch \
+ file://CVE-2019-17451.patch \
"
S = "${WORKDIR}/git"
diff --git a/meta/recipes-devtools/binutils/binutils/CVE-2019-17450.patch
b/meta/recipes-devtools/binutils/binutils/CVE-2019-17450.patch
new file mode 100644
index 00..1068873447
--- /dev/null
+++ b/meta/recipes-devtools/binutils/binutils/CVE-2019-17450.patch
@@ -0,0 +1,107 @@
+From 18360106e144b3584fc2f822118021086dc17da3 Mon Sep 17 00:00:00 2001
+From: Alan Modra
+Date: Wed, 9 Oct 2019 00:07:29 +1030
+Subject: [PATCH] PR25078, stack overflow in function find_abstract_instance
+
+ PR 25078
+ * dwarf2.c (find_abstract_instance): Delete orig_info_ptr, add
+ recur_count. Error on recur_count reaching 100 rather than
+ info_ptr matching orig_info_ptr. Adjust calls.
+
+CVE: CVE-2019-17450
+Upstream-Status: Backport
+Signed-off-by: Zhixiong Chi
+---
+ bfd/ChangeLog | 7 +++
+ bfd/dwarf2.c | 35 +--
+ 2 files changed, 24 insertions(+), 18 deletions(-)
+
+diff --git a/bfd/ChangeLog b/bfd/ChangeLog
+index e66fb40a2c..2f568ff9bf 100644
+--- a/bfd/ChangeLog
b/bfd/ChangeLog
+@@ -1,3 +1,10 @@
++2019-10-08 Alan Modra
++
++ PR 25078
++ * dwarf2.c (find_abstract_instance): Delete orig_info_ptr, add
++ recur_count. Error on recur_count reaching 100 rather than
++ info_ptr matching orig_info_ptr. Adjust calls.
++
+ 2019-06-21 Alan Modra
+
+ PR 24689
+diff --git a/bfd/dwarf2.c b/bfd/dwarf2.c
+index 0b4e485582..20ec9e2e56 100644
+--- a/bfd/dwarf2.c
b/bfd/dwarf2.c
+@@ -2803,13 +2803,13 @@ lookup_symbol_in_variable_table (struct comp_unit
*unit,
+ }
+
+ static bfd_boolean
+-find_abstract_instance (struct comp_unit * unit,
+- bfd_byte * orig_info_ptr,
+- struct attribute * attr_ptr,
+- const char **pname,
+- bfd_boolean *is_linkage,
+- char ** filename_ptr,
+- int *linenumber_ptr)
++find_abstract_instance (struct comp_unit *unit,
++ struct attribute *attr_ptr,
++ unsigned int recur_count,
++ const char **pname,
++ bfd_boolean *is_linkage,
++ char **filename_ptr,
++ int *linenumber_ptr)
+ {
+ bfd *abfd = unit->abfd;
+ bfd_byte *info_ptr;
+@@ -2820,6 +2820,14 @@ find_abstract_instance (struct comp_unit * unit,
+ struct attribute attr;
+ const char *name = NULL;
+
++ if (recur_count == 100)
++{
++ _bfd_error_handler
++ (_("DWARF error: abstract instance recursion detected"));
++ bfd_set_error (bfd_error_bad_value);
++ return FALSE;
++}
++
+ /* DW_FORM_ref_addr can reference an entry in a different CU. It
+ is an offset from the .debug_info section, not the current CU. */
+ if (attr_ptr->form == DW_FORM_ref_addr)
+@@ -2939,15 +2947,6 @@ find_abstract_instance (struct comp_unit * unit,
+info_ptr, info_ptr_end);
+ if (info_ptr == NULL)
+ break;
+-/* It doesn't ever make sense for DW_AT_specification to
+- refer to the same DIE. Stop simple recursion. */
+-if (info_ptr == orig_info_ptr)
+- {
+-_bfd_error_handler
+- (_("DWARF error: abstract instance recursion detected"));
+-bfd_set_error (bfd_error_bad_value);
+-return FALSE;
+- }
+ switch (attr.name)
+ {
+ case DW_AT_name:
+@@ -2961,7 +2960,7 @@ find_abstract_instance (struct comp_unit * unit,
+ }
+ break;
+ case DW_AT_specification:
+-if (!find_abstract_instance (unit,
[OE-core] ✗ patchtest: failure for binutils: CVE-2019-17450 and CVE-2019-17451
== Series Details == Series: binutils: CVE-2019-17450 and CVE-2019-17451 Revision: 1 URL : https://patchwork.openembedded.org/series/20742/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests have been executed on the proposed series by patchtest resulting in the following failures: * Patchbinutils: CVE-2019-17450 and CVE-2019-17451 Issue Missing or incorrectly formatted CVE tag in included patch file [test_cve_tag_format] Suggested fixCorrect or include the CVE tag on cve patch with format: "CVE: CVE--" * Issue A patch file has been added, but does not have a Signed-off-by tag [test_signed_off_by_presence] Suggested fixSign off the added patch file (meta/recipes-devtools/binutils/binutils/CVE-2019-17450.patch) * Issue Added patch file is missing Upstream-Status in the header [test_upstream_status_presence_format] Suggested fixAdd Upstream-Status: to the header of meta/recipes-devtools/binutils/binutils/CVE-2019-17450.patch Standard format Upstream-Status: Valid status Pending, Accepted, Backport, Denied, Inappropriate [reason], Submitted [where] If you believe any of these test results are incorrect, please reply to the mailing list (openembedded-core@lists.openembedded.org) raising your concerns. Otherwise we would appreciate you correcting the issues and submitting a new version of the patchset if applicable. Please ensure you add/increment the version number when sending the new version (i.e. [PATCH] -> [PATCH v2] -> [PATCH v3] -> ...). --- Guidelines: https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] binutils: CVE-2019-17450 and CVE-2019-17451
This patch fix the stack overflow issue for recursive call
and the segment fault issue.
Backport the two CVE pathces from the binutils upstream:
commit 336bfbeb1848f4b9558456fdcf283ee8a32d7fd1
commit 063c511bd79281f33fd33f0964541a73511b9e2b
Signed-off-by: Zhixiong Chi
---
.../binutils/binutils-2.32.inc| 2 +
.../binutils/binutils/CVE-2019-17450.patch| 104 ++
.../binutils/binutils/CVE-2019-17451.patch| 54 +
3 files changed, 160 insertions(+)
create mode 100644 meta/recipes-devtools/binutils/binutils/CVE-2019-17450.patch
create mode 100644 meta/recipes-devtools/binutils/binutils/CVE-2019-17451.patch
diff --git a/meta/recipes-devtools/binutils/binutils-2.32.inc
b/meta/recipes-devtools/binutils/binutils-2.32.inc
index 19baf8a883..349c3e1154 100644
--- a/meta/recipes-devtools/binutils/binutils-2.32.inc
+++ b/meta/recipes-devtools/binutils/binutils-2.32.inc
@@ -49,6 +49,8 @@ SRC_URI = "\
file://CVE-2019-12972.patch \
file://CVE-2019-14250.patch \
file://CVE-2019-1.patch \
+ file://CVE-2019-17450.patch \
+ file://CVE-2019-17451.patch \
"
S = "${WORKDIR}/git"
diff --git a/meta/recipes-devtools/binutils/binutils/CVE-2019-17450.patch
b/meta/recipes-devtools/binutils/binutils/CVE-2019-17450.patch
new file mode 100644
index 00..e95c9f7aba
--- /dev/null
+++ b/meta/recipes-devtools/binutils/binutils/CVE-2019-17450.patch
@@ -0,0 +1,104 @@
+From 18360106e144b3584fc2f822118021086dc17da3 Mon Sep 17 00:00:00 2001
+From: Alan Modra
+Date: Wed, 9 Oct 2019 00:07:29 +1030
+Subject: [PATCH] PR25078, stack overflow in function find_abstract_instance
+
+ PR 25078
+ * dwarf2.c (find_abstract_instance): Delete orig_info_ptr, add
+ recur_count. Error on recur_count reaching 100 rather than
+ info_ptr matching orig_info_ptr. Adjust calls.
+
+---
+ bfd/ChangeLog | 7 +++
+ bfd/dwarf2.c | 35 +--
+ 2 files changed, 24 insertions(+), 18 deletions(-)
+
+diff --git a/bfd/ChangeLog b/bfd/ChangeLog
+index e66fb40a2c..2f568ff9bf 100644
+--- a/bfd/ChangeLog
b/bfd/ChangeLog
+@@ -1,3 +1,10 @@
++2019-10-08 Alan Modra
++
++ PR 25078
++ * dwarf2.c (find_abstract_instance): Delete orig_info_ptr, add
++ recur_count. Error on recur_count reaching 100 rather than
++ info_ptr matching orig_info_ptr. Adjust calls.
++
+ 2019-06-21 Alan Modra
+
+ PR 24689
+diff --git a/bfd/dwarf2.c b/bfd/dwarf2.c
+index 0b4e485582..20ec9e2e56 100644
+--- a/bfd/dwarf2.c
b/bfd/dwarf2.c
+@@ -2803,13 +2803,13 @@ lookup_symbol_in_variable_table (struct comp_unit
*unit,
+ }
+
+ static bfd_boolean
+-find_abstract_instance (struct comp_unit * unit,
+- bfd_byte * orig_info_ptr,
+- struct attribute * attr_ptr,
+- const char **pname,
+- bfd_boolean *is_linkage,
+- char ** filename_ptr,
+- int *linenumber_ptr)
++find_abstract_instance (struct comp_unit *unit,
++ struct attribute *attr_ptr,
++ unsigned int recur_count,
++ const char **pname,
++ bfd_boolean *is_linkage,
++ char **filename_ptr,
++ int *linenumber_ptr)
+ {
+ bfd *abfd = unit->abfd;
+ bfd_byte *info_ptr;
+@@ -2820,6 +2820,14 @@ find_abstract_instance (struct comp_unit * unit,
+ struct attribute attr;
+ const char *name = NULL;
+
++ if (recur_count == 100)
++{
++ _bfd_error_handler
++ (_("DWARF error: abstract instance recursion detected"));
++ bfd_set_error (bfd_error_bad_value);
++ return FALSE;
++}
++
+ /* DW_FORM_ref_addr can reference an entry in a different CU. It
+ is an offset from the .debug_info section, not the current CU. */
+ if (attr_ptr->form == DW_FORM_ref_addr)
+@@ -2939,15 +2947,6 @@ find_abstract_instance (struct comp_unit * unit,
+info_ptr, info_ptr_end);
+ if (info_ptr == NULL)
+ break;
+-/* It doesn't ever make sense for DW_AT_specification to
+- refer to the same DIE. Stop simple recursion. */
+-if (info_ptr == orig_info_ptr)
+- {
+-_bfd_error_handler
+- (_("DWARF error: abstract instance recursion detected"));
+-bfd_set_error (bfd_error_bad_value);
+-return FALSE;
+- }
+ switch (attr.name)
+ {
+ case DW_AT_name:
+@@ -2961,7 +2960,7 @@ find_abstract_instance (struct comp_unit * unit,
+ }
+ break;
+ case DW_AT_specification:
+-if (!find_abstract_instance (unit, info_ptr, &attr,
++if (!find_abstract_instance (unit, &attr, re
[OE-core] [PATCH] resulttool/store.py: Enable add extra test environment data
Enable the option to add extra test environment data to the
configuration of each test result (as optional).
Example of optional test environment data include:
- custom packages included for runtime test
- detail machine specification used as target
- detail host environment used for bitbake
Signed-off-by: Yeoh Ee Peng
---
scripts/lib/resulttool/store.py | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/scripts/lib/resulttool/store.py b/scripts/lib/resulttool/store.py
index 79c83dd..e0951f0 100644
--- a/scripts/lib/resulttool/store.py
+++ b/scripts/lib/resulttool/store.py
@@ -24,6 +24,8 @@ def store(args, logger):
configvars = resultutils.extra_configvars.copy()
if args.executed_by:
configvars['EXECUTED_BY'] = args.executed_by
+if args.extra_test_env:
+configvars['EXTRA_TEST_ENV'] = args.extra_test_env
results = {}
logger.info('Reading files from %s' % args.source)
if resultutils.is_url(args.source) or os.path.isfile(args.source):
@@ -98,4 +100,5 @@ def register_commands(subparsers):
help='don\'t error if no results to store are
found')
parser_build.add_argument('-x', '--executed-by', default='',
help='add executed-by configuration to each
result file')
-
+parser_build.add_argument('-t', '--extra-test-env', default='',
+ help='add extra test environment data to each
result file configuration')
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] ell: update to 0.25
0.24:
- Add support for extended groups in settings files.
0.25:
- Fix issue with stopping DHCP client and owner notification.
- Fix issue with time calculation overflow and DHCP.
Signed-off-by: Oleksandr Kravchuk
---
meta/recipes-core/ell/{ell_0.23.bb => ell_0.25.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-core/ell/{ell_0.23.bb => ell_0.25.bb} (83%)
diff --git a/meta/recipes-core/ell/ell_0.23.bb
b/meta/recipes-core/ell/ell_0.25.bb
similarity index 83%
rename from meta/recipes-core/ell/ell_0.23.bb
rename to meta/recipes-core/ell/ell_0.25.bb
index f6e91ef6fd..f6201f9bf6 100644
--- a/meta/recipes-core/ell/ell_0.23.bb
+++ b/meta/recipes-core/ell/ell_0.25.bb
@@ -14,8 +14,8 @@ DEPENDS = "dbus"
inherit autotools pkgconfig
SRC_URI =
"https://mirrors.edge.kernel.org/pub/linux/libs/${BPN}/${BPN}-${PV}.tar.xz";
-SRC_URI[md5sum] = "be8214ff5b37012c4314343c8e6bcf15"
-SRC_URI[sha256sum] =
"2efd9f7cdf57dedb9f1ba81bec534a3e0432476b1cb35ec0bc69973772a5f89b"
+SRC_URI[md5sum] = "8a8adc712718c770a72e4df6c9855c26"
+SRC_URI[sha256sum] =
"7f2be568219d991d566ca50c58a56e69df9a248619fed758dcd9a4b04e655e5b"
do_configure_prepend () {
mkdir -p ${S}/build-aux
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] ✗ patchtest: failure for gcr: remove intltool-native
== Series Details == Series: gcr: remove intltool-native Revision: 1 URL : https://patchwork.openembedded.org/series/20734/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests have been executed on the proposed series by patchtest resulting in the following failures: * Issue Series does not apply on top of target branch [test_series_merge_on_head] Suggested fixRebase your series on top of targeted branch Targeted branch master (currently at b91b30c09f) If you believe any of these test results are incorrect, please reply to the mailing list (openembedded-core@lists.openembedded.org) raising your concerns. Otherwise we would appreciate you correcting the issues and submitting a new version of the patchset if applicable. Please ensure you add/increment the version number when sending the new version (i.e. [PATCH] -> [PATCH v2] -> [PATCH v3] -> ...). --- Guidelines: https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] gcr: remove intltool-native
gcr uses gettext now, so no need to depend on intltool-native.
Signed-off-by: Ross Burton
---
meta/recipes-gnome/gcr/gcr_3.34.0.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-gnome/gcr/gcr_3.34.0.bb
b/meta/recipes-gnome/gcr/gcr_3.34.0.bb
index f13bfecbe19..616b0e5bf5d 100644
--- a/meta/recipes-gnome/gcr/gcr_3.34.0.bb
+++ b/meta/recipes-gnome/gcr/gcr_3.34.0.bb
@@ -8,7 +8,7 @@ BUGTRACKER = "https://gitlab.gnome.org/GNOME/gcr/issues";
LICENSE = "GPLv2"
LIC_FILES_CHKSUM = "file://COPYING;md5=55ca817ccb7d5b5b66355690e9abc605"
-DEPENDS = "intltool-native gtk+3 p11-kit glib-2.0 libgcrypt \
+DEPENDS = "gtk+3 p11-kit glib-2.0 libgcrypt \
${@bb.utils.contains('GI_DATA_ENABLED', 'True', 'libxslt-native',
'', d)}"
inherit gnomebase gtk-icon-cache gtk-doc distro_features_check
upstream-version-is-even vala gobject-introspection gettext
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 3/5] gcr: update to 3.34.0
On 24/10/2019 12:11, Alexander Kanavin wrote: inherit gettext, as gcr is now gettextized. Note that gettexting means intltool-native is no longer a build dependency. No need to send a patch, I've queued it locally. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libgcrypt: upgrade 1.8.4 -> 1.8.5
On 19/10/2019 16:52, Trevor Gamblin wrote: Note that the patch 0001-Add-and-use-pkg-config-for-libgcrypt-instead-of-conf.patch was removed as its intent was to provide a pkg-config option, but libgcrypt upstream added one in commit 813b002eaf. I think we need to retain portions of that patch: | checking for libgcrypt-config... /data/poky-tmp/master/work/corei7-64-poky-linux/gcr/3.34.0-r0/recipe-sysroot/usr/bin/crossscripts/libgcrypt-config | checking for LIBGCRYPT - version >= 1.4.5... ERROR: /usr/bin/libgcrypt-config should not be used, use an alternative such as pkg-config | ../gcr-3.34.0/configure: line 14093: test: --should-not-have-used-/usr/bin/libgcrypt-config: integer expression expected | ../gcr-3.34.0/configure: line 14096: test: --should-not-have-used-/usr/bin/libgcrypt-config: integer expression expected Whilst it's great that libgcrypt is shipping a pc file, we need to retain the porting of the macro files to use that pc file. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] ✗ patchtest: failure for sudo: Fix fetching sources
Op 28-10-2019 om 22:36 schreef Ross Burton: On 25/10/2019 21:39, Ferry Toth wrote: Op 25-10-2019 om 21:32 schreef Patchwork: == Series Details == Series: sudo: Fix fetching sources Revision: 1 URL : https://patchwork.openembedded.org/series/20684/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests have been executed on the proposed series by patchtest resulting in the following failures: * Issue Series does not apply on top of target branch [test_series_merge_on_head] Suggested fix Rebase your series on top of targeted branch Targeted branch master (currently at 1a8d18) If you believe any of these test results are incorrect, please reply to the mailing list (openembedded-core@lists.openembedded.org) raising your concerns. Otherwise we would appreciate you correcting the issues and submitting a new version of the patchset if applicable. Please ensure you add/increment the version number when sending the new version (i.e. [PATCH] -> [PATCH v2] -> [PATCH v3] -> ...). The patch applies to thud. But the patch doesn't say [thud] in the subject so nobody else knows this, and the patch process says we fix master, then zeus, then warrior, then thud. Yes, sorry about that. I wanted to send v2 for master but then found it has already been patched. Good to know it will eventually be backported to Thud. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] GStreamer 1.0 meson build transition
Hm, true. Alright, I'll do that. For discussions about the recipe changes, should I create a fork of oe-core and place them there, just like how one would prepare merge requests? To me, it sounds more efficient than posting the patches in the mailing list for discussing them. And speaking of upgrades, my changes are against 1.16.1, so the 1.16.0 -> 1.16.1 upgrade needs to make it into master-next in first. Carlos On 28.10.19 17:44, Ross Burton wrote: On 26/10/2019 11:57, Carlos Rafael Giani wrote: I think it would make sense to not try to get a meson based build done for GStreamer 1.16, and instead target it for 1.18. Minor version upgrades like 1.16.0 -> 1.16.1 aren't expected to bring major changes with them, while major upgrades like 1.16 -> 1.18 are generally known to potentially bring such changes. Also, there's a chance that new patches might make their way into 1.18 before its release. That's fine, but there is value in doing the migration separately to the 1.16->1.18 upgrade: there should be no difference to the installed files which makes verification easier. Basically I've no opinion on when the meson migration is merged, as you say it's not trivial, but please have it as a separate commit to an upgrade. Thanks, Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v4] coreutils: Move stdbuf into an own package coreutils-stdbuf
This LD_PRELOAD trick is not really suitable for busybox,
so can be the only part of coreutils needed.
coreutils depends on the new package,
so nothing changes when installing coreutils.
Signed-off-by: Adrian Bunk
---
meta/recipes-core/coreutils/coreutils_8.31.bb | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/meta/recipes-core/coreutils/coreutils_8.31.bb
b/meta/recipes-core/coreutils/coreutils_8.31.bb
index 4a74f619af..57b2c1bdba 100644
--- a/meta/recipes-core/coreutils/coreutils_8.31.bb
+++ b/meta/recipes-core/coreutils/coreutils_8.31.bb
@@ -49,7 +49,7 @@ bindir_progs = "arch basename chcon cksum comm csplit cut dir
dircolors dirname
env expand expr factor fmt fold groups head hostid id install \
join link logname md5sum mkfifo nl nohup nproc od paste
pathchk \
pinky pr printf ptx readlink realpath runcon seq sha1sum
sha224sum sha256sum \
-sha384sum sha512sum shred shuf sort split stdbuf sum tac tail
tee test timeout \
+sha384sum sha512sum shred shuf sort split sum tac tail tee
test timeout \
tr truncate tsort tty unexpand uniq unlink uptime users vdir
wc who whoami yes"
# hostname gets a special treatment and is not included in this
@@ -58,6 +58,10 @@ base_bindir_progs = "cat chgrp chmod chown cp date dd echo
false hostname kill l
sbindir_progs= "chroot"
+PACKAGE_BEFORE_PN_class-target += "coreutils-stdbuf"
+FILES_coreutils-stdbuf = "${bindir}/stdbuf ${libdir}/coreutils/libstdbuf.so"
+RDEPENDS_coreutils_class-target += "coreutils-stdbuf"
+
# Let aclocal use the relative path for the m4 file rather than the
# absolute since coreutils has a lot of m4 files, otherwise there might
# be an "Argument list too long" error when it is built in a long/deep
--
2.17.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v3] coreutils: Move stdbuf into an own package coreutils-stdbuf
On Mon, Oct 28, 2019 at 01:44:47PM +, Richard Purdie wrote: > On Sun, 2019-10-27 at 17:04 +0200, Adrian Bunk wrote: > > This LD_PRELOAD trick is not really suitable for busybox, > > so can be the only part of coreutils needed. > > > > coreutils depends on the new package, > > so nothing changes when installing coreutils. > > > > Signed-off-by: Adrian Bunk > > --- > > v3: coreutils-native fixed > > --- > > meta/recipes-core/coreutils/coreutils_8.31.bb | 6 +- > > 1 file changed, 5 insertions(+), 1 deletion(-) > > This is better but there look to be nativesdk warnings: > > https://autobuilder.yoctoproject.org/typhoon/#/builders/23/builds/1406 I thought I was also testing nativesdk, but apparently not... So the following works for native (no effect) but not for nativesdk: RDEPENDS_coreutils += "coreutils-stdbuf" v4 (sic) sent. > Cheers, > > Richard cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH V2] mdadm: fix do_package failed when changed local.conf but not cleaned
On 08/10/2019 04:16, Changqing Li wrote:
Ping
My previous comment still stands:
Can't you just pass BINDIR=${base_sbindir} MANDIR=${docdir}/man
UDEVDIR=${nonarch_base_libdir}/udev etc, instead of patching the makefile?
Ross
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libgcrypt: upgrade 1.8.4 -> 1.8.5
On 19/10/2019 16:52, Trevor Gamblin wrote: Note that the patch 0001-Add-and-use-pkg-config-for-libgcrypt-instead-of-conf.patch was removed as its intent was to provide a pkg-config option, but libgcrypt upstream added one in commit 813b002eaf. We've had some more patches land in master before this, can you rebase? Specifically there are some further CVE patches which I suspect made the 1.8.5 release. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libgcrypt: upgrade 1.8.4 -> 1.8.5
On 19/10/2019 16:52, Trevor Gamblin wrote: Note that the patch 0001-Add-and-use-pkg-config-for-libgcrypt-instead-of-conf.patch was removed as its intent was to provide a pkg-config option, but libgcrypt upstream added one in commit 813b002eaf. /me faints We've been asking upstream periodically to add this for literal years. I wonder what changed their mind. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] ✗ patchtest: failure for sudo: Fix fetching sources
On 25/10/2019 21:39, Ferry Toth wrote: Op 25-10-2019 om 21:32 schreef Patchwork: == Series Details == Series: sudo: Fix fetching sources Revision: 1 URL : https://patchwork.openembedded.org/series/20684/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests have been executed on the proposed series by patchtest resulting in the following failures: * Issue Series does not apply on top of target branch [test_series_merge_on_head] Suggested fix Rebase your series on top of targeted branch Targeted branch master (currently at 1a8d18) If you believe any of these test results are incorrect, please reply to the mailing list (openembedded-core@lists.openembedded.org) raising your concerns. Otherwise we would appreciate you correcting the issues and submitting a new version of the patchset if applicable. Please ensure you add/increment the version number when sending the new version (i.e. [PATCH] -> [PATCH v2] -> [PATCH v3] -> ...). The patch applies to thud. But the patch doesn't say [thud] in the subject so nobody else knows this, and the patch process says we fix master, then zeus, then warrior, then thud. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] classes/image_types_wic.bbclass: fix racing risk on rootfs
On 28/10/2019 16:09, Hongxu Jia wrote: Since wic image creation will temporarily update rootfs/etc/fstab (*temporarily* means the fstab will be recovered after wic image creation), there is still racing risk during the temporarily time for other image creation (such as tar, ext) Could this be done with a hardlink tree instead of literally copying the entire filesystem? Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] distutils: pass along parallel make flags to setup.py build
On 24/10/2019 19:25, Nick Owens wrote: i see, it looks like i should apply this to distutils3.bbclass and not distutils.bbclass, since python2 never got support for --parallel. does that seem right? Yes. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] python3-numpy: Stop shipping manual config files
On 27/10/2019 17:36, Adrian Bunk wrote: Automatic generation seems to work fine, and does not become outdated. My hero! Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 0/2] Bug fixes for makedevs.c
On 28/10/2019 19:11, Andre McCurdy wrote: On Mon, Oct 28, 2019 at 10:15 AM Frazer Leslie Clews wrote: fixes a few bugs in some print statements and an overflow bug with usr_buf Frazer Leslie Clews (2): fix format strings in makedevs.c in print statements fix invalidScanfFormatWidth to prevent overflowing usr_buf Perhaps fixing these issues would be a good opportunity to align with the Buildroot (ie upstream?) version instead of diverging even more. https://git.buildroot.net/buildroot/tree/package/makedevs/makedevs.c Yes, this. If we can just fetch makedevs from buildroot that's one less piece of code we have to look after. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] zimage Initramfs booting stuck at Start Kernel
Op 28-10-2019 om 03:02 schreef JH:
On 10/28/19, Ferry Toth wrote:
No, there is no limitation in kernel, BTW, the zImage-initramfs is not
just kernel space, the zImage-initramfs = kernel + rootfs which cannot
be limited to 10 MB. I have a zImage-initramfs created by openwrt, the
size is 28 MB. The problem is created by oe-core, most likely in
kernel.bbclass, could anyone in oe-core development provide insights
where is the 10 MB limitation from and how to fix it?
I see that Ubuntu keeps the initramfs in a separate cpio, while we are
trying to build the cpio into the kernel (afaiu the cpio is unpacked
into a kernel directory, and then built-in by the kernels build system).
I built all package formats, rootfs.tar.gz, rootfs.cpio.gz,
rootfs.cpio.gz.u-boot, zImage->zImage*.bin,
zImage-initramfs->zImage-initramfs*.bin.
I did try to run different images to boot it to imx6 RAM, but the
zImage*.bin (8MB) is the only one I could boot it to imx6 RAM,
obviously it failed to mount rootfs as it did not bundle the rootfs.
How did you build the cpio into the kernel?
https://github.com/edison-fw/meta-intel-edison/blob/master/meta-intel-edison-bsp/conf/machine/edison.conf
And there is the max size!
And that cpio is ~64MB, so it must be possible.
Is the 64MB for compressed cpio.gz? If so, that should be fine. Did
you allude that 64MB is also a limitation for cpio?
No I don't think so.
In my case kernel, cpio and zImage-initramfs are all built. And although
U-Boot allows to load kernel and cpio separately I didn't try (or don't
remember the result). So, maybe that's the trick.
Both rootfs.cpio.gz and rootfs.cpio.gz.u-boot I built are gzip
compressed data, thaI cannot be booted to imx6 RAM.
Here is the image format built from openwrt which I could boot to imx6 RAM:
0 0x0 Linux kernel ARM boot executable zImage
(little-endian)
15464 0x3C68 xz compressed data
15696 0x3D50 xz compressed data
Here is the zImage (8MB) image format I build from bitbake which did
not bundle rootfs, but it could be booted to imx6 RAM
0 0x0 Linux kernel ARM boot executable zImage
(little-endian)
6904 0x1AF8 LZO compressed data
7316 0x1C94 LZO compressed data
7918 0x1EEE device tree image (dtb)
57505 0xE0A1 device tree image (dtb)
3122840x4C3DC LZ4 compressed data, legacy
2049118 0x1F445ESHA256 hash constants, little endian
2372712 0x243468mcrypt 2.5 encrypted data, algorithm:
"]", keysize: 23701 bytes, mode: "(",
6093219 0x5CF9A3device tree image (dtb)
8127047 0x7C0247LZ4 compressed data, legacy
Here is the zImage-initramfs (35 MB) I build from bitbake which
bundled the rootfs, but could not be booted I believe the cause is the
size too large:
0 0x0 Linux kernel ARM boot executable zImage
(little-endian)
6904 0x1AF8 LZO compressed data
7316 0x1C94 LZO compressed data
7918 0x1EEE device tree image (dtb)
57505 0xE0A1 device tree image (dtb)
3123020x4C3EE LZ4 compressed data, legacy
2049266 0x1F44F2SHA256 hash constants, little endian
2372864 0x243500mcrypt 2.5 encrypted data, algorithm:
"]", keysize: 23701 bytes, mode: "(",
6093526 0x5CFAD6device tree image (dtb)
8127489 0x7C0401LZ4 compressed data, legacy
10886101 0xA61BD5ZBOOT firmware header, header size: 32
bytes, load address: 0x0564F721, start address: 0x2E4CEE95, checksum:
0x22771426, version: 0x1D216514, image size: 185068065 bytes
11990008 0xB6F3F8mcrypt 2.5 encrypted data, algorithm:
">", keysize: 2093 bytes, mode: "-",
12899061 0xC4D2F5LZMA compressed data, properties: 0x63,
dictionary size: 2097152 bytes, uncompressed size: 139006573920 bytes
12899237 0xC4D3A5LZMA compressed data, properties: 0x6C,
dictionary size: 2097152 bytes, uncompressed size: 541203680 bytes
12899272 0xC4D3C8LZMA compressed data, properties: 0x63,
dictionary size: 2097152 bytes, uncompressed size: 139810176352 bytes
12899719 0xC4D587LZMA compressed data, properties: 0x65,
dictionary size: 2097152 bytes, uncompressed size: 541990112 bytes
12940308 0xC57414LZMA compressed data, properties: 0x5E,
dictionary size: 522190848 bytes, uncompressed size: 2157628 bytes
12945629 0xC588DDLZMA compressed data, properties: 0xBE,
dictionary size: -1108672512 bytes, uncompressed size: 138831226112
bytes
12948853 0xC59575LZMA compressed data, properties: 0xC0,
dictionary size: -551550976 bytes, uncompressed size: 2117660 bytes
12995870 0xC64D1ECopyright string: "Copyright 2017, NXP"
13729894 0xD18066ELF, 32-bit LSB processor-specific,
14855286 0xE2AC76mcrypt 2.5 encrypte
Re: [OE-core] [PATCH v3 1/3] recipes-devtools/go: Refactor patches for go-1.13.3
Awesome, thanks!
On Mon, Oct 28, 2019 at 7:30 PM Alexander Kube
wrote:
> Done. The latest patchset removes go-1.12 and cleans up the rest of the
> 1.13 recipes.
>
>
> On Fri, Oct 25, 2019 at 1:59 PM Khem Raj wrote:
>
>> Looks good but please delete 1.12 along as well
>>
>> On Thu, Oct 24, 2019 at 9:39 PM Alexander Kube <
>> alexander.j.k...@gmail.com> wrote:
>>
>>> From: Alex Kube
>>>
>>> Signed-off-by: Alex Kube
>>> ---
>>> ...ow-CC-and-CXX-to-have-multiple-words.patch | 38 +++
>>> ...ent-based-hash-generation-less-pedan.patch | 226 ++
>>> ...-to-be-overridden-in-the-environment.patch | 54
>>> ...4-ld-add-soname-to-shareable-objects.patch | 50
>>> ...de-CC-when-building-dist-and-go_boot.patch | 44 +++
>>> ...dist-separate-host-and-target-builds.patch | 279 ++
>>> ...d-go-make-GOROOT-precious-by-default.patch | 113 +++
>>> ...008-use-GOBUILDMODE-to-set-buildmode.patch | 47 +++
>>> ...place-glibc-dynamic-linker-with-musl.patch | 134 +
>>> 9 files changed, 985 insertions(+)
>>> create mode 100644
>>> meta/recipes-devtools/go/go-1.13/0001-allow-CC-and-CXX-to-have-multiple-words.patch
>>> create mode 100644
>>> meta/recipes-devtools/go/go-1.13/0002-cmd-go-make-content-based-hash-generation-less-pedan.patch
>>> create mode 100644
>>> meta/recipes-devtools/go/go-1.13/0003-allow-GOTOOLDIR-to-be-overridden-in-the-environment.patch
>>> create mode 100644
>>> meta/recipes-devtools/go/go-1.13/0004-ld-add-soname-to-shareable-objects.patch
>>> create mode 100644
>>> meta/recipes-devtools/go/go-1.13/0005-make.bash-override-CC-when-building-dist-and-go_boot.patch
>>> create mode 100644
>>> meta/recipes-devtools/go/go-1.13/0006-cmd-dist-separate-host-and-target-builds.patch
>>> create mode 100644
>>> meta/recipes-devtools/go/go-1.13/0007-cmd-go-make-GOROOT-precious-by-default.patch
>>> create mode 100644
>>> meta/recipes-devtools/go/go-1.13/0008-use-GOBUILDMODE-to-set-buildmode.patch
>>> create mode 100644
>>> meta/recipes-devtools/go/go-1.13/0009-ld-replace-glibc-dynamic-linker-with-musl.patch
>>>
>>> diff --git
>>> a/meta/recipes-devtools/go/go-1.13/0001-allow-CC-and-CXX-to-have-multiple-words.patch
>>> b/meta/recipes-devtools/go/go-1.13/0001-allow-CC-and-CXX-to-have-multiple-words.patch
>>> new file mode 100644
>>> index 00..ddfd5e41d1
>>> --- /dev/null
>>> +++
>>> b/meta/recipes-devtools/go/go-1.13/0001-allow-CC-and-CXX-to-have-multiple-words.patch
>>> @@ -0,0 +1,38 @@
>>> +From 9e3dc44cdfa58d96504d0a789dc82617dd5bef55 Mon Sep 17 00:00:00 2001
>>> +From: Alex Kube
>>> +Date: Wed, 23 Oct 2019 21:01:13 +0430
>>> +Subject: [PATCH 1/9] cmd/go: Allow CC and CXX to have multiple words
>>> +
>>> +Upstream-Status: Inappropriate [OE specific]
>>> +
>>> +Adapted to Go 1.13 from patches originally submitted to
>>> +the meta/recipes-devtools/go tree by
>>> +Matt Madison .
>>> +
>>> +Signed-off-by: Alexander J Kube
>>> +
>>> +---
>>> + src/cmd/go/internal/envcmd/env.go | 4 ++--
>>> + 1 file changed, 2 insertions(+), 2 deletions(-)
>>> +
>>> +diff --git a/src/cmd/go/internal/envcmd/env.go
>>> b/src/cmd/go/internal/envcmd/env.go
>>> +index 17852de..7b5ec5e 100644
>>> +--- a/src/cmd/go/internal/envcmd/env.go
>>> b/src/cmd/go/internal/envcmd/env.go
>>> +@@ -100,11 +100,11 @@ func MkEnv() []cfg.EnvVar {
>>> +
>>> + cc := cfg.DefaultCC(cfg.Goos, cfg.Goarch)
>>> + if env := strings.Fields(cfg.Getenv("CC")); len(env) > 0 {
>>> +- cc = env[0]
>>> ++ cc = strings.Join(env, " ")
>>> + }
>>> + cxx := cfg.DefaultCXX(cfg.Goos, cfg.Goarch)
>>> + if env := strings.Fields(cfg.Getenv("CXX")); len(env) > 0 {
>>> +- cxx = env[0]
>>> ++ cxx = strings.Join(env, " ")
>>> + }
>>> + env = append(env, cfg.EnvVar{Name: "AR", Value: envOr("AR",
>>> "ar")})
>>> + env = append(env, cfg.EnvVar{Name: "CC", Value: cc})
>>> +--
>>> +2.17.1 (Apple Git-112)
>>> +
>>> diff --git
>>> a/meta/recipes-devtools/go/go-1.13/0002-cmd-go-make-content-based-hash-generation-less-pedan.patch
>>> b/meta/recipes-devtools/go/go-1.13/0002-cmd-go-make-content-based-hash-generation-less-pedan.patch
>>> new file mode 100644
>>> index 00..4eddd39809
>>> --- /dev/null
>>> +++
>>> b/meta/recipes-devtools/go/go-1.13/0002-cmd-go-make-content-based-hash-generation-less-pedan.patch
>>> @@ -0,0 +1,226 @@
>>> +From a13ae484e41139094505d2834437e9262a5315f7 Mon Sep 17 00:00:00 2001
>>> +From: Alex Kube
>>> +Date: Wed, 23 Oct 2019 21:14:22 +0430
>>> +Subject: [PATCH 2/9] cmd/go: make content-based hash generation less
>>> pedantic
>>> +
>>> +Upstream-Status: Inappropriate [OE specific]
>>> +
>>> +Go 1.10's build tool now uses content-based hashes to
>>> +determine when something should be built or re-built.
>>> +This same mechanism is used to maintain a built-artifact
>>> +cache for speeding up builds.
>>> +
>>> +However, the hashes it generates include information that
>>> +doesn't work well with
Re: [OE-core] [PATCH 0/2] Bug fixes for makedevs.c
On Mon, Oct 28, 2019 at 10:15 AM Frazer Leslie Clews wrote: > > fixes a few bugs in some print statements and an overflow bug with usr_buf > > Frazer Leslie Clews (2): > fix format strings in makedevs.c in print statements > fix invalidScanfFormatWidth to prevent overflowing usr_buf Perhaps fixing these issues would be a good opportunity to align with the Buildroot (ie upstream?) version instead of diverging even more. https://git.buildroot.net/buildroot/tree/package/makedevs/makedevs.c > meta/recipes-devtools/makedevs/makedevs/makedevs.c | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) > > -- > 2.20.1 > > -- > ___ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v3 1/3] recipes-devtools/go: Refactor patches for go-1.13.3
Done. The latest patchset removes go-1.12 and cleans up the rest of the
1.13 recipes.
On Fri, Oct 25, 2019 at 1:59 PM Khem Raj wrote:
> Looks good but please delete 1.12 along as well
>
> On Thu, Oct 24, 2019 at 9:39 PM Alexander Kube
> wrote:
>
>> From: Alex Kube
>>
>> Signed-off-by: Alex Kube
>> ---
>> ...ow-CC-and-CXX-to-have-multiple-words.patch | 38 +++
>> ...ent-based-hash-generation-less-pedan.patch | 226 ++
>> ...-to-be-overridden-in-the-environment.patch | 54
>> ...4-ld-add-soname-to-shareable-objects.patch | 50
>> ...de-CC-when-building-dist-and-go_boot.patch | 44 +++
>> ...dist-separate-host-and-target-builds.patch | 279 ++
>> ...d-go-make-GOROOT-precious-by-default.patch | 113 +++
>> ...008-use-GOBUILDMODE-to-set-buildmode.patch | 47 +++
>> ...place-glibc-dynamic-linker-with-musl.patch | 134 +
>> 9 files changed, 985 insertions(+)
>> create mode 100644
>> meta/recipes-devtools/go/go-1.13/0001-allow-CC-and-CXX-to-have-multiple-words.patch
>> create mode 100644
>> meta/recipes-devtools/go/go-1.13/0002-cmd-go-make-content-based-hash-generation-less-pedan.patch
>> create mode 100644
>> meta/recipes-devtools/go/go-1.13/0003-allow-GOTOOLDIR-to-be-overridden-in-the-environment.patch
>> create mode 100644
>> meta/recipes-devtools/go/go-1.13/0004-ld-add-soname-to-shareable-objects.patch
>> create mode 100644
>> meta/recipes-devtools/go/go-1.13/0005-make.bash-override-CC-when-building-dist-and-go_boot.patch
>> create mode 100644
>> meta/recipes-devtools/go/go-1.13/0006-cmd-dist-separate-host-and-target-builds.patch
>> create mode 100644
>> meta/recipes-devtools/go/go-1.13/0007-cmd-go-make-GOROOT-precious-by-default.patch
>> create mode 100644
>> meta/recipes-devtools/go/go-1.13/0008-use-GOBUILDMODE-to-set-buildmode.patch
>> create mode 100644
>> meta/recipes-devtools/go/go-1.13/0009-ld-replace-glibc-dynamic-linker-with-musl.patch
>>
>> diff --git
>> a/meta/recipes-devtools/go/go-1.13/0001-allow-CC-and-CXX-to-have-multiple-words.patch
>> b/meta/recipes-devtools/go/go-1.13/0001-allow-CC-and-CXX-to-have-multiple-words.patch
>> new file mode 100644
>> index 00..ddfd5e41d1
>> --- /dev/null
>> +++
>> b/meta/recipes-devtools/go/go-1.13/0001-allow-CC-and-CXX-to-have-multiple-words.patch
>> @@ -0,0 +1,38 @@
>> +From 9e3dc44cdfa58d96504d0a789dc82617dd5bef55 Mon Sep 17 00:00:00 2001
>> +From: Alex Kube
>> +Date: Wed, 23 Oct 2019 21:01:13 +0430
>> +Subject: [PATCH 1/9] cmd/go: Allow CC and CXX to have multiple words
>> +
>> +Upstream-Status: Inappropriate [OE specific]
>> +
>> +Adapted to Go 1.13 from patches originally submitted to
>> +the meta/recipes-devtools/go tree by
>> +Matt Madison .
>> +
>> +Signed-off-by: Alexander J Kube
>> +
>> +---
>> + src/cmd/go/internal/envcmd/env.go | 4 ++--
>> + 1 file changed, 2 insertions(+), 2 deletions(-)
>> +
>> +diff --git a/src/cmd/go/internal/envcmd/env.go
>> b/src/cmd/go/internal/envcmd/env.go
>> +index 17852de..7b5ec5e 100644
>> +--- a/src/cmd/go/internal/envcmd/env.go
>> b/src/cmd/go/internal/envcmd/env.go
>> +@@ -100,11 +100,11 @@ func MkEnv() []cfg.EnvVar {
>> +
>> + cc := cfg.DefaultCC(cfg.Goos, cfg.Goarch)
>> + if env := strings.Fields(cfg.Getenv("CC")); len(env) > 0 {
>> +- cc = env[0]
>> ++ cc = strings.Join(env, " ")
>> + }
>> + cxx := cfg.DefaultCXX(cfg.Goos, cfg.Goarch)
>> + if env := strings.Fields(cfg.Getenv("CXX")); len(env) > 0 {
>> +- cxx = env[0]
>> ++ cxx = strings.Join(env, " ")
>> + }
>> + env = append(env, cfg.EnvVar{Name: "AR", Value: envOr("AR",
>> "ar")})
>> + env = append(env, cfg.EnvVar{Name: "CC", Value: cc})
>> +--
>> +2.17.1 (Apple Git-112)
>> +
>> diff --git
>> a/meta/recipes-devtools/go/go-1.13/0002-cmd-go-make-content-based-hash-generation-less-pedan.patch
>> b/meta/recipes-devtools/go/go-1.13/0002-cmd-go-make-content-based-hash-generation-less-pedan.patch
>> new file mode 100644
>> index 00..4eddd39809
>> --- /dev/null
>> +++
>> b/meta/recipes-devtools/go/go-1.13/0002-cmd-go-make-content-based-hash-generation-less-pedan.patch
>> @@ -0,0 +1,226 @@
>> +From a13ae484e41139094505d2834437e9262a5315f7 Mon Sep 17 00:00:00 2001
>> +From: Alex Kube
>> +Date: Wed, 23 Oct 2019 21:14:22 +0430
>> +Subject: [PATCH 2/9] cmd/go: make content-based hash generation less
>> pedantic
>> +
>> +Upstream-Status: Inappropriate [OE specific]
>> +
>> +Go 1.10's build tool now uses content-based hashes to
>> +determine when something should be built or re-built.
>> +This same mechanism is used to maintain a built-artifact
>> +cache for speeding up builds.
>> +
>> +However, the hashes it generates include information that
>> +doesn't work well with OE, nor with using a shared runtime
>> +library.
>> +
>> +First, it embeds path names to source files, unless
>> +building within GOROOT. This prevents the building
>> +of a package in GOPATH for later staging into GOROOT
[OE-core] ✗ patchtest: failure for Bug fixes for makedevs.c
== Series Details == Series: Bug fixes for makedevs.c Revision: 1 URL : https://patchwork.openembedded.org/series/20722/ State : failure == Summary == Thank you for submitting this patch series to OpenEmbedded Core. This is an automated response. Several tests have been executed on the proposed series by patchtest resulting in the following failures: * Patch[1/2] fix format strings in makedevs.c in print statements Issue Shortlog does not follow expected format [test_shortlog_format] Suggested fixCommit shortlog (first line of commit message) should follow the format ": " If you believe any of these test results are incorrect, please reply to the mailing list (openembedded-core@lists.openembedded.org) raising your concerns. Otherwise we would appreciate you correcting the issues and submitting a new version of the patchset if applicable. Please ensure you add/increment the version number when sending the new version (i.e. [PATCH] -> [PATCH v2] -> [PATCH v3] -> ...). --- Guidelines: https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines Test framework: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest Test suite: http://git.yoctoproject.org/cgit/cgit.cgi/patchtest-oe -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/2] fix invalidScanfFormatWidth to prevent overflowing usr_buf
Signed-off-by: Frazer Leslie Clews
---
meta/recipes-devtools/makedevs/makedevs/makedevs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-devtools/makedevs/makedevs/makedevs.c
b/meta/recipes-devtools/makedevs/makedevs/makedevs.c
index 01e564afee..32b9872932 100644
--- a/meta/recipes-devtools/makedevs/makedevs/makedevs.c
+++ b/meta/recipes-devtools/makedevs/makedevs/makedevs.c
@@ -360,7 +360,7 @@ static int interpret_table_entry(char *line)
unsigned long mode = 0755, uid = 0, gid = 0, major = 0, minor = 0;
unsigned long start = 0, increment = 1, count = 0;
- if (0 > sscanf(line, "%4095s %c %lo %40s %40s %lu %lu %lu %lu %lu",
path,
+ if (0 > sscanf(line, "%4095s %c %lo %39s %39s %lu %lu %lu %lu %lu",
path,
&type, &mode, usr_buf, grp_buf, &major, &minor, &start,
&increment, &count))
{
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/2] fix format strings in makedevs.c in print statements
Signed-off-by: Frazer Leslie Clews
---
meta/recipes-devtools/makedevs/makedevs/makedevs.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/meta/recipes-devtools/makedevs/makedevs/makedevs.c
b/meta/recipes-devtools/makedevs/makedevs/makedevs.c
index cba7681414..01e564afee 100644
--- a/meta/recipes-devtools/makedevs/makedevs/makedevs.c
+++ b/meta/recipes-devtools/makedevs/makedevs/makedevs.c
@@ -230,7 +230,7 @@ static void add_new_directory(char *name, char *path,
unsigned long uid, unsigned long gid, unsigned long mode)
{
if (trace)
- fprintf(stderr, "Directory: %s %s UID: %ld GID %ld MODE:
%04lo", path, name, uid, gid, mode);
+ fprintf(stderr, "Directory: %s %s UID: %lu GID %lu MODE:
%04lo", path, name, uid, gid, mode);
if (mkdir(path, mode) < 0) {
if (EEXIST == errno) {
@@ -251,7 +251,7 @@ static void add_new_device(char *name, char *path, unsigned
long uid,
struct stat sb;
if (trace) {
- fprintf(stderr, "Device: %s %s UID: %ld GID: %ld MODE: %04lo
MAJOR: %d MINOR: %d",
+ fprintf(stderr, "Device: %s %s UID: %lu GID: %lu MODE: %04lo
MAJOR: %d MINOR: %d",
path, name, uid, gid, mode, (short)(rdev >> 8),
(short)(rdev & 0xff));
}
@@ -292,7 +292,7 @@ static void add_new_file(char *name, char *path, unsigned
long uid,
unsigned long gid, unsigned long mode)
{
if (trace) {
- fprintf(stderr, "File: %s %s UID: %ld GID: %ld MODE:
%04lo\n",
+ fprintf(stderr, "File: %s %s UID: %lu GID: %lu MODE:
%04lo\n",
path, name, gid, uid, mode);
}
@@ -311,7 +311,7 @@ static void add_new_fifo(char *name, char *path, unsigned
long uid,
unsigned long gid, unsigned long mode)
{
if (trace) {
- printf("Fifo: %s %s UID: %ld GID: %ld MODE: %04lo\n",
+ printf("Fifo: %s %s UID: %lu GID: %lu MODE: %04lo\n",
path, name, gid, uid, mode);
}
--
2.20.1
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/2] Bug fixes for makedevs.c
fixes a few bugs in some print statements and an overflow bug with usr_buf Frazer Leslie Clews (2): fix format strings in makedevs.c in print statements fix invalidScanfFormatWidth to prevent overflowing usr_buf meta/recipes-devtools/makedevs/makedevs/makedevs.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) -- 2.20.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] GStreamer 1.0 meson build transition
On 26/10/2019 11:57, Carlos Rafael Giani wrote: I think it would make sense to not try to get a meson based build done for GStreamer 1.16, and instead target it for 1.18. Minor version upgrades like 1.16.0 -> 1.16.1 aren't expected to bring major changes with them, while major upgrades like 1.16 -> 1.18 are generally known to potentially bring such changes. Also, there's a chance that new patches might make their way into 1.18 before its release. That's fine, but there is value in doing the migration separately to the 1.16->1.18 upgrade: there should be no difference to the installed files which makes verification easier. Basically I've no opinion on when the meson migration is merged, as you say it's not trivial, but please have it as a separate commit to an upgrade. Thanks, Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] libical: add PACKAGECONFIG glib and enable it by default
On 25/10/2019 08:38, Andreas Müller wrote: On Sat, Oct 19, 2019 at 3:06 PM Andreas Müller wrote: * As long as there is no solution upstream [1] build src-generator native and adjust cmake file to find it * libical-glib is a mandatory dependency for evolution-data-server >= 3.34 [1] https://github.com/libical/libical/issues/394 Signed-off-by: Andreas Müller Haven't tested but it might not apply no more after patch adding DESCRIPTION & HOMEPAGE in gnome recipes. Before I go and rebase I want to ask (seems motivation to apply this is limited): Does this has a chance of being accepted. If not: * Why - it is meant as temporary solution * What way would be accepted to get libical-glib building? Looks good to me and merges fine here. Upstream is told they're broken, so unless we find someone who understands cmake enough to fix the build properly we can hang on to this minor hack. Ross -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] classes/image_types_wic.bbclass: fix racing risk on rootfs
Since wic image creation will temporarily update rootfs/etc/fstab
(*temporarily* means the fstab will be recovered after wic image creation),
there is still racing risk during the temporarily time for other image
creation (such as tar, ext)
Make a copy of rootfs(as rootfs_wic), and create wic image based on the copy.
Signed-off-by: Hongxu Jia
---
meta/classes/image_types_wic.bbclass | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/meta/classes/image_types_wic.bbclass
b/meta/classes/image_types_wic.bbclass
index f350dc2..2a93143 100644
--- a/meta/classes/image_types_wic.bbclass
+++ b/meta/classes/image_types_wic.bbclass
@@ -26,15 +26,20 @@ def wks_search(files, search_path):
WIC_CREATE_EXTRA_ARGS ?= ""
IMAGE_CMD_wic () {
+ [ -d "${IMAGE_ROOTFS}_wic" ] && rm -rf "${IMAGE_ROOTFS}_wic"
+ # Refer oe.path.copytree(src, dst): ${WORKDIR}/rootfs ->
${WORKDIR}/rootfs_wic
+ mkdir -p "${IMAGE_ROOTFS}_wic"
+ tar --xattrs --xattrs-include="*" -cf - -S -C "${IMAGE_ROOTFS}" -p . |
tar --xattrs --xattrs-include="*" -xf - -C "${IMAGE_ROOTFS}_wic"
+
out="${IMGDEPLOYDIR}/${IMAGE_NAME}"
wks="${WKS_FULL_PATH}"
if [ -z "$wks" ]; then
bbfatal "No kickstart files from WKS_FILES were found:
${WKS_FILES}. Please set WKS_FILE or WKS_FILES appropriately."
fi
- BUILDDIR="${TOPDIR}" wic create "$wks" --vars
"${STAGING_DIR}/${MACHINE}/imgdata/" -e "${IMAGE_BASENAME}" -o "$out/"
${WIC_CREATE_EXTRA_ARGS}
+ BUILDDIR="${TOPDIR}" wic create "$wks" --vars
"${STAGING_DIR}/${MACHINE}/imgdata/" -e "${IMAGE_BASENAME}" -r
"${IMAGE_ROOTFS}_wic" -o "$out/" ${WIC_CREATE_EXTRA_ARGS}
mv "$out/$(basename "${wks%.wks}")"*.direct
"$out${IMAGE_NAME_SUFFIX}.wic"
- rm -rf "$out/"
+ rm -rf "$out/" "${IMAGE_ROOTFS}_wic"
}
IMAGE_CMD_wic[vardepsexclude] = "WKS_FULL_PATH WKS_FILES TOPDIR"
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Yocto Project Newcomer & Unassigned Bugs - Help Needed
All, The triage team is starting to try and collect up and classify bugs which a newcomer to the project would be able to work on in a way which means people can find them. They're being listed on the triage page under the appropriate heading: https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs The idea is these bugs should be straight forward for a person to help work on who doesn't have deep experience with the project. If anyone can help, please take ownership of the bug and send patches! If anyone needs help/advice there are people on irc who can likely do so, or some of the more experienced contributors will likely be happy to help too. Also, the triage team meets weekly and does its best to handle the bugs reported into the Bugzilla. The number of people attending that meeting has fallen, as have the number of people available to help fix bugs. One of the things we hear users report is they don't know how to help. We (the triage team) are therefore going to start reporting out the currently 297 unassigned or newcomer bugs. We're hoping people may be able to spare some time now and again to help out with these. Bugs are split into two types, "true bugs" where things don't work as they should and "enhancements" which are features we'd want to add to the system. There are also roughly four different "priority" classes right now, “3.1”, “3.2, "3.99" and "Future", the more pressing/urgent issues being in "3.1" and then “3.2”. Please review this link and if a bug is something you would be able to help with either take ownership of the bug, or send me (sjolley.yp...@gmail.com) an e-mail with the bug number you would like and I will assign it to you (please make sure you have a Bugzilla account). The list is at: https://wiki.yoctoproject.org/wiki/Bug_Triage#Unassigned_or_Newcomer_Bugs -- Thanks, *Stephen K. Jolley* *Yocto Project Program Manager* *7867 SW Bayberry Dr., Beaverton, OR 97007* (*Cell*:(208) 244-4460 * *Email*: *s jolley.yp...@gmail.com * -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v3] coreutils: Move stdbuf into an own package coreutils-stdbuf
On Sun, 2019-10-27 at 17:04 +0200, Adrian Bunk wrote: > This LD_PRELOAD trick is not really suitable for busybox, > so can be the only part of coreutils needed. > > coreutils depends on the new package, > so nothing changes when installing coreutils. > > Signed-off-by: Adrian Bunk > --- > v3: coreutils-native fixed > --- > meta/recipes-core/coreutils/coreutils_8.31.bb | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) This is better but there look to be nativesdk warnings: https://autobuilder.yoctoproject.org/typhoon/#/builders/23/builds/1406 Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH v3] coreutils: Move stdbuf into an own package coreutils-stdbuf
On Sun, 2019-10-27 at 17:04 +0200, Adrian Bunk wrote: > This LD_PRELOAD trick is not really suitable for busybox, > so can be the only part of coreutils needed. > > coreutils depends on the new package, > so nothing changes when installing coreutils. > > Signed-off-by: Adrian Bunk > --- > v3: coreutils-native fixed > --- > meta/recipes-core/coreutils/coreutils_8.31.bb | 6 +- > 1 file changed, 5 insertions(+), 1 deletion(-) This is better but there look to be nativesdk warnings: https://autobuilder.yoctoproject.org/typhoon/#/builders/23/builds/1406 Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
