Re: [OE-core] [PATCH 16/19] meson: update to 0.52.0
On Sun, Oct 20, 2019 at 2:32 PM wrote: > > Feeling suitably responsible for this breakage, I looked into it. The > following two patches, one for meson in OE-Core and the other for dconf > in meta-oe seem to address the problem. I'm not entirely sure they're > correct but they don't actually change the library binary so its > probably fine whilst upstream sorts it out. > > If they look ok to you I'll submit them "properly". > > Cheers, > > Richard > Had exactly the same idea for dconf: in the discussion they did link_whole->link_with for libdconf_common which is wrong and was just meant as example. As soon as I finished bisecting do_rootfs issue (reported) I will try * dconf-patch * dconf+meson patch and report. Thanks for taking care Andreas -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Help with intermittent autobuilder exposed bugs
On 10/20/19 5:54 AM, Richard Purdie wrote: > We have a situation brewing on the autobuilder. Each run there are some > bugs which sometimes can appear. Law of averages says one or more of > the issues below will now appear as we have so many of them. The > project's standard processes aren't helping to capture the issues or > track them down. > > With the release mostly sorted out from my perspective I can look at > some of the other health aspects of the project. > > In theory SWAT should have filed bugs for these. In most cases they > haven't. If they did, we'd discuss them at triage, decide they looked > hard and then there wouldn't be anyone to "assign" to them so they'd > most likely end up on my plate anyway. I find it hard to know what to > do with these. I already have a load in my bug backlog which I've not > gotten sorted out so adding more probably won't help. > > To summarise the issues [just from the last few builds]: I'll get started logging bugs > > https://autobuilder.yoctoproject.org/typhoon/#/builders/56/builds/756 > oe-selftest recipetool.RecipetoolTests.test_recipetool_load_plugin > RP has a long standing bug: > https://bugzilla.yoctoproject.org/show_bug.cgi?id=13070 > https://autobuilder.yoctoproject.org/typhoon/#/builders/72/builds/1177 > qa-extras2 step2c testimage logrotate.LogrotateTest.test_2_logrotate > for core-image-sato > [no open bug?] https://bugzilla.yoctoproject.org/show_bug.cgi?id=13602 > > https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/441 > oe-selftest devtool.DevtoolExtractTests.test_devtool_deploy_target > [no open bug, unhelpful backtrace from tinfoil] Bug #13601, seen with stable/warrior-nmut and on same host - fedora30-ty-1 > https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/440 > oe-sefltest signing.LockedSignatures.test_locked_signatures > [no open bug or any idea why it failed] https://bugzilla.yoctoproject.org/show_bug.cgi?id=13605 > https://autobuilder.yoctoproject.org/typhoon/#/builders/80/builds/440 > oe-selftest distrodata.Distrodata.test_maintainer > [no open bug, same unhelpful backtrace from tinfoil] https://bugzilla.yoctoproject.org/show_bug.cgi?id=13604 > > https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/440 > oe-selftest reproducible.ReproducibleTests.test_reproducible_builds > [no open bug?, fedora specific perldoc reproducibility issue] Think its the same as https://bugzilla.yoctoproject.org/show_bug.cgi?id=13602 > > https://autobuilder.yoctoproject.org/typhoon/#/builders/110/builds/52 > qemuarm systemd timeout parselogs error > """Central error: Oct 19 11:21:48 qemuarm login[228]:I have > pam_systemd(login:session): Failed to create session: Connection timed > out""" > [no open bug] I am seeing this on one of my arm machines at home when it boots so I will take this one. https://bugzilla.yoctoproject.org/show_bug.cgi?id=13603 > > Some of these are with master-next but I don't believe are related to > any issue specific to -next, its just because -next has had more test > runs. > > I'm not sure what we do about this. The SWAT process really needs to > pay more attention, equally the people are volunteers and therefore I > try to be grateful for any help. > > These issues are becoming more frequent and mean we lose confidence in > the builds which delays patch merging. People often ask me how they can > help, ideas on how we can move forward with this would be welcome... > > I also know Armin has a difficult to debug selftest issue with warrior > which is blocking its release build right now. > > Cheers, > > Richard > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 16/19] meson: update to 0.52.0
On Sun, Oct 20, 2019 at 5:08 PM Andreas Müller wrote: > > On Sun, Oct 20, 2019 at 2:32 PM wrote: > > > > Feeling suitably responsible for this breakage, I looked into it. The > > following two patches, one for meson in OE-Core and the other for dconf > > in meta-oe seem to address the problem. I'm not entirely sure they're > > correct but they don't actually change the library binary so its > > probably fine whilst upstream sorts it out. > > > > If they look ok to you I'll submit them "properly". > > > > Cheers, > > > > Richard > > > Had exactly the same idea for dconf: in the discussion they did > link_whole->link_with for libdconf_common which is wrong and was just > meant as example. > > As soon as I finished bisecting do_rootfs issue (reported) I will try > > * dconf-patch > * dconf+meson patch > > and report. > > Thanks for taking care > Had to adjust the dconf-patch: * Here (and in master-next) we moved dconf 0.32 -> 0.34 * The SRC_URI has to go below inherit gnomebase otherwise it does not cause effect. But very important result: dconf-patch only fixes dconf build! Will send out reworked version to meta-oe list Andreas -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] python-setuptools:upgrade 41.2.0 -> 41.4.0
Signed-off-by: Zang Ruochen
---
meta/recipes-devtools/python/python-setuptools.inc| 4 ++--
.../{python-setuptools_41.2.0.bb => python-setuptools_41.4.0.bb} | 0
.../{python3-setuptools_41.2.0.bb => python3-setuptools_41.4.0.bb}| 0
3 files changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-devtools/python/{python-setuptools_41.2.0.bb =>
python-setuptools_41.4.0.bb} (100%)
rename meta/recipes-devtools/python/{python3-setuptools_41.2.0.bb =>
python3-setuptools_41.4.0.bb} (100%)
diff --git a/meta/recipes-devtools/python/python-setuptools.inc
b/meta/recipes-devtools/python/python-setuptools.inc
index 322197e..027e259 100644
--- a/meta/recipes-devtools/python/python-setuptools.inc
+++ b/meta/recipes-devtools/python/python-setuptools.inc
@@ -10,8 +10,8 @@ inherit pypi
SRC_URI_append_class-native = "
file://0001-conditionally-do-not-fetch-code-by-easy_install.patch"
-SRC_URI[md5sum] = "a3470ce184da33f0fa6c9f44f6221bc0"
-SRC_URI[sha256sum] =
"66b86bbae7cc7ac2e867f52dc08a6bd064d938bac59dfec71b9b565dd36d6012"
+SRC_URI[md5sum] = "89a592d733b31e180a4b6ad760c0685a"
+SRC_URI[sha256sum] =
"7eae782ccf36b790c21bde7d86a4f303a441cd77036b25c559a602cf5186ce4d"
DEPENDS += "${PYTHON_PN}"
diff --git a/meta/recipes-devtools/python/python-setuptools_41.2.0.bb
b/meta/recipes-devtools/python/python-setuptools_41.4.0.bb
similarity index 100%
rename from meta/recipes-devtools/python/python-setuptools_41.2.0.bb
rename to meta/recipes-devtools/python/python-setuptools_41.4.0.bb
diff --git a/meta/recipes-devtools/python/python3-setuptools_41.2.0.bb
b/meta/recipes-devtools/python/python3-setuptools_41.4.0.bb
similarity index 100%
rename from meta/recipes-devtools/python/python3-setuptools_41.2.0.bb
rename to meta/recipes-devtools/python/python3-setuptools_41.4.0.bb
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/1] util-linux: fix PKNAME name is NULL when use lsblk [LIN1019-2963]
PKNAME is NULL when run "lsblk -o+PKNAME /dev/sda1" backport an upstream patch to fix it. Signed-off-by: Liwei Song --- ...-force-to-print-PKNAME-for-partition.patch | 36 +++ .../util-linux/util-linux_2.34.bb | 1 + 2 files changed, 37 insertions(+) create mode 100644 meta/recipes-core/util-linux/util-linux/0001-lsblk-force-to-print-PKNAME-for-partition.patch diff --git a/meta/recipes-core/util-linux/util-linux/0001-lsblk-force-to-print-PKNAME-for-partition.patch b/meta/recipes-core/util-linux/util-linux/0001-lsblk-force-to-print-PKNAME-for-partition.patch new file mode 100644 index ..5d4c148fb3d1 --- /dev/null +++ b/meta/recipes-core/util-linux/util-linux/0001-lsblk-force-to-print-PKNAME-for-partition.patch @@ -0,0 +1,36 @@ +From e3bb9bfb76c17b1d05814436ced62c05c4011f48 Mon Sep 17 00:00:00 2001 +From: Karel Zak +Date: Thu, 27 Jun 2019 09:22:18 +0200 +Subject: [PATCH] lsblk: force to print PKNAME for partition + +PKNAME (parent kernel device name) is based on printed tree according +to parent -> child relationship. The tree is optional and not printed +if partition specified (.e.g "lsblk -o+PKNAME /dev/sda1"), but old +versions print the PKNAME also in this case. + +Upstream-Status: Backport [https://github.com/karelzak/util-linux/commit/e3bb9bfb76c17b1d05814436ced62c05c4011f48] + +Addresses: https://github.com/karelzak/util-linux/issues/813 +Signed-off-by: Karel Zak +Signed-off-by: Liwei Song +--- + misc-utils/lsblk.c | 3 +++ + 1 file changed, 3 insertions(+) + +diff --git a/misc-utils/lsblk.c b/misc-utils/lsblk.c +index e95af7af0256..3ce6da730264 100644 +--- a/misc-utils/lsblk.c b/misc-utils/lsblk.c +@@ -1019,6 +1019,9 @@ static void device_to_scols( + DBG(DEV, ul_debugobj(dev, "add '%s' to scols", dev->name)); + ON_DBG(DEV, if (ul_path_isopen_dirfd(dev->sysfs)) ul_debugobj(dev, " %s ---> is open!", dev->name)); + ++ if (!parent && dev->wholedisk) ++ parent = dev->wholedisk; ++ + /* Do not print device more than one in --list mode */ + if (!(lsblk->flags & LSBLK_TREE) && dev->is_printed) + return; +-- +2.17.1 + diff --git a/meta/recipes-core/util-linux/util-linux_2.34.bb b/meta/recipes-core/util-linux/util-linux_2.34.bb index 262f4bacb00b..e9c2d80e902b 100644 --- a/meta/recipes-core/util-linux/util-linux_2.34.bb +++ b/meta/recipes-core/util-linux/util-linux_2.34.bb @@ -7,6 +7,7 @@ SRC_URI += "file://configure-sbindir.patch \ file://run-ptest \ file://display_testname_for_subtest.patch \ file://avoid_parallel_tests.patch \ +file://0001-lsblk-force-to-print-PKNAME-for-partition.patch \ " SRC_URI[md5sum] = "a78cbeaed9c39094b96a48ba8f891d50" SRC_URI[sha256sum] = "743f9d0c7252b6db246b659c1e1ce0bd45d8d4508b4dfa427bbb4a3e9b9f62b5" -- 2.17.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] python3-pip:upgrade 19.2.3 -> 19.3.1
Signed-off-by: Zang Ruochen
---
.../python/{python3-pip_19.2.3.bb => python3-pip_19.3.1.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-devtools/python/{python3-pip_19.2.3.bb =>
python3-pip_19.3.1.bb} (81%)
diff --git a/meta/recipes-devtools/python/python3-pip_19.2.3.bb
b/meta/recipes-devtools/python/python3-pip_19.3.1.bb
similarity index 81%
rename from meta/recipes-devtools/python/python3-pip_19.2.3.bb
rename to meta/recipes-devtools/python/python3-pip_19.3.1.bb
index 019e327..d27e6fc 100644
--- a/meta/recipes-devtools/python/python3-pip_19.2.3.bb
+++ b/meta/recipes-devtools/python/python3-pip_19.3.1.bb
@@ -6,8 +6,8 @@ LIC_FILES_CHKSUM =
"file://LICENSE.txt;md5=8ba06d529c955048e5ddd7c45459eb2e"
DEPENDS += "python3 python3-setuptools-native"
-SRC_URI[md5sum] = "f417444c66a0db1a82c8d9d2283a2f95"
-SRC_URI[sha256sum] =
"e7a31f147974362e6c82d84b91c7f2bdf57e4d3163d3d454e6c3e71944d67135"
+SRC_URI[md5sum] = "1aaaf90fbafc50e7ba1e66ffceb00960"
+SRC_URI[sha256sum] =
"21207d76c1031e517668898a6b46a9fb1501c7a4710ef5dfd6a40ad9e6757ea7"
inherit pypi distutils3
--
2.7.4
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] e2fsprogs: fix CVE-2019-5094
From: Changqing Li
Signed-off-by: Changqing Li
---
.../e2fsprogs/e2fsprogs/CVE-2019-5094.patch| 217 +
.../recipes-devtools/e2fsprogs/e2fsprogs_1.45.3.bb | 1 +
2 files changed, 218 insertions(+)
create mode 100644
meta/recipes-devtools/e2fsprogs/e2fsprogs/CVE-2019-5094.patch
diff --git a/meta/recipes-devtools/e2fsprogs/e2fsprogs/CVE-2019-5094.patch
b/meta/recipes-devtools/e2fsprogs/e2fsprogs/CVE-2019-5094.patch
new file mode 100644
index 000..56925cb
--- /dev/null
+++ b/meta/recipes-devtools/e2fsprogs/e2fsprogs/CVE-2019-5094.patch
@@ -0,0 +1,217 @@
+From 8dbe7b475ec5e91ed767239f0e85880f416fc384 Mon Sep 17 00:00:00 2001
+From: Theodore Ts'o
+Date: Sun, 1 Sep 2019 00:59:16 -0400
+Subject: libsupport: add checks to prevent buffer overrun bugs in quota code
+
+A maliciously corrupted file systems can trigger buffer overruns in
+the quota code used by e2fsck. To fix this, add sanity checks to the
+quota header fields as well as to block number references in the quota
+tree.
+
+Addresses: CVE-2019-5094
+Addresses: TALOS-2019-0887
+Signed-off-by: Theodore Ts'o
+
+
+Upstream-Status: Backport
[https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/commit/?h=maint=8dbe7b475ec5e91ed767239f0e85880f416fc384]
+CVE: CVE-2019-5094
+
+Signed-off-by: Changqing Li
+---
+ lib/support/mkquota.c | 1 +
+ lib/support/quotaio_tree.c | 71 ++
+ lib/support/quotaio_v2.c | 28 ++
+ 3 files changed, 76 insertions(+), 24 deletions(-)
+
+diff --git a/lib/support/mkquota.c b/lib/support/mkquota.c
+index 0b9e7665..ddb53124 100644
+--- a/lib/support/mkquota.c
b/lib/support/mkquota.c
+@@ -671,6 +671,7 @@ errcode_t quota_compare_and_update(quota_ctx_t qctx, enum
quota_type qtype,
+ err = qh.qh_ops->scan_dquots(, scan_dquots_callback, _data);
+ if (err) {
+ log_debug("Error scanning dquots");
++ *usage_inconsistent = 1;
+ goto out_close_qh;
+ }
+
+diff --git a/lib/support/quotaio_tree.c b/lib/support/quotaio_tree.c
+index a7c2028c..6cc4fb5b 100644
+--- a/lib/support/quotaio_tree.c
b/lib/support/quotaio_tree.c
+@@ -540,6 +540,17 @@ struct dquot *qtree_read_dquot(struct quota_handle *h,
qid_t id)
+ return dquot;
+ }
+
++static int check_reference(struct quota_handle *h, unsigned int blk)
++{
++ if (blk >= h->qh_info.u.v2_mdqi.dqi_qtree.dqi_blocks) {
++ log_err("Illegal reference (%u >= %u) in %s quota file",
++ blk, h->qh_info.u.v2_mdqi.dqi_qtree.dqi_blocks,
++ quota_type2name(h->qh_type));
++ return -1;
++ }
++ return 0;
++}
++
+ /*
+ * Scan all dquots in file and call callback on each
+ */
+@@ -558,7 +569,7 @@ static int report_block(struct dquot *dquot, unsigned int
blk, char *bitmap,
+ int entries, i;
+
+ if (!buf)
+- return 0;
++ return -1;
+
+ set_bit(bitmap, blk);
+ read_blk(dquot->dq_h, blk, buf);
+@@ -580,23 +591,12 @@ static int report_block(struct dquot *dquot, unsigned
int blk, char *bitmap,
+ return entries;
+ }
+
+-static void check_reference(struct quota_handle *h, unsigned int blk)
+-{
+- if (blk >= h->qh_info.u.v2_mdqi.dqi_qtree.dqi_blocks)
+- log_err("Illegal reference (%u >= %u) in %s quota file. "
+- "Quota file is probably corrupted.\n"
+- "Please run e2fsck (8) to fix it.",
+- blk,
+- h->qh_info.u.v2_mdqi.dqi_qtree.dqi_blocks,
+- quota_type2name(h->qh_type));
+-}
+-
+ static int report_tree(struct dquot *dquot, unsigned int blk, int depth,
+ char *bitmap,
+ int (*process_dquot) (struct dquot *, void *),
+ void *data)
+ {
+- int entries = 0, i;
++ int entries = 0, ret, i;
+ dqbuf_t buf = getdqbuf();
+ __le32 *ref = (__le32 *) buf;
+
+@@ -607,22 +607,40 @@ static int report_tree(struct dquot *dquot, unsigned int
blk, int depth,
+ if (depth == QT_TREEDEPTH - 1) {
+ for (i = 0; i < QT_BLKSIZE >> 2; i++) {
+ blk = ext2fs_le32_to_cpu(ref[i]);
+- check_reference(dquot->dq_h, blk);
+- if (blk && !get_bit(bitmap, blk))
+- entries += report_block(dquot, blk, bitmap,
+- process_dquot, data);
++ if (check_reference(dquot->dq_h, blk)) {
++ entries = -1;
++ goto errout;
++ }
++ if (blk && !get_bit(bitmap, blk)) {
++ ret = report_block(dquot, blk, bitmap,
++ process_dquot, data);
++ if (ret < 0) {
++
Re: [OE-core] Failed to build zImage-initramfs
Thanks Ferry and Khem,
Finally built the zImage-initramfs, but it does not bundle the rootfs,
how can I included the rootfs to the zImage?
There is n old style link in kernel.bbclass:
use_alternate_initrd=CONFIG_INITRAMFS_SOURCE=${B}/usr/${INITRAMFS_IMAGE_NAME}.cpio
I think there is some new way to do it, what relevent kernel setup
variables need be defined?
Thank you.
Kind regards,
- jh
On 10/13/19, Ferry Toth wrote:
> Hi
>
> Op 13-10-19 om 11:10 schreef JH:
>> On 10/13/19, Khem Raj wrote:
>>
$ vi local.conf
IMAGE_ROOTFS += " core-image-minimal-initramfs"
>>>
>>> INITRAMFS_IMAGE should be an image name. Like core-image-minimal or
>>> somesuch
>>
>> Hmm, change it to my image, the name is solar-image.bb (bitbake
>> solar-image), is it correct to change it in my local.conf as per your
>> instruction?
>>
>> $ vi local.conf
>> INITRAMFS_IMAGE = "solar-image"
>>
>> That caused circular dependecies. Without specifying INITRAMFS_IMAGE,
>> my build was all fine, as soon as add INITRAMFS_IMAGE, it's first
>> error was "Nothing RPROVIDES", I must miss things here.
>>
>> ERROR: These are usually caused by circular dependencies and any
>> circular dependency chains found will be printed below. Increase the
>> debug level to see a list of unbuildable tasks.
>> ERROR:
>> Dependency loop #1 found:
>>Task
>> /build/Ramdisk/oe-core/../meta-solar/recipes-core/images/solar-image.bb:do_image_complete
>> (dependent Tasks ['solar-image.bb:do_image_cpio',
>> 'solar-image.bb:do_image_wic', 'solar-image.bb:do_image',
>> 'solar-image.bb:do_image_tar'])
>>Task
>> /build/Ramdisk/oe-core/../meta-solar/recipes-kernel/linux/linux-solar_4.19.bb:do_bundle_initramfs
>> (dependent Tasks ['solar-image.bb:do_image_complete',
>> 'linux-solar_4.19.bb:do_install'])
>>Task
>> /build/Ramdisk/oe-core/../meta-solar/recipes-kernel/linux/linux-solar_4.19.bb:do_deploy
>> (dependent Tasks ['linux-solar_4.19.bb:do_packagedata',
>> 'depmodwrapper-cross_1.0.bb:do_populate_sysroot',
>> 'linux-solar_4.19.bb:do_bundle_initramfs',
>> 'linux-solar_4.19.bb:do_populate_sysroot',
>> 'linux-solar_4.19.bb:do_assemble_fitimage_initramfs'])
>>Task
>> /build/Ramdisk/oe-core/../meta-solar/recipes-core/images/solar-image.bb:do_image_wic
>> (dependent Tasks ['linux-solar_4.19.bb:do_deploy',
>> 'u-boot-imx_2017.03.bb:do_deploy',
>> 'gptfdisk_1.0.4.bb:do_populate_sysroot',
>> 'dosfstools_4.1.bb:do_populate_sysroot',
>> 'mtools_4.0.18.bb:do_populate_sysroot',
>> 'solar-image.bb:do_rootfs_wicenv', 'solar-image.bb:do_image',
>> 'parted_3.2.bb:do_populate_sysroot'])
>>
>>
>> ERROR: Command execution failed: 1
>
> As an example you might want to look at my repo, I have 2 images minimal
> and initramfs:
> https://github.com/edison-fw/meta-intel-edison/tree/master/meta-intel-edison-distro/recipes-core/images
>
>
>>
>> Thank you very much Khem,
>>
>> Kind regards,
>>
>> - jh
>>
>
>
> --
> ___
> 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 16/19] meson: update to 0.52.0
On Sun, 2019-10-20 at 06:51 +0530, Khem Raj wrote: > > > On Sat, Oct 19, 2019 at 2:56 AM > wrote: > > On Fri, 2019-10-18 at 20:49 +0200, Alexander Kanavin wrote: > > > I certainly don't mean to ignore those reports, it's just that > > due to > > > my ongoing health problems, and having to dedicate most of my > > energy > > > to the day job (https://mbition.io/en/home/), I am not currently > > able > > > to work on the upstream issues in a timely manner the way I used > > to > > > when maintaining core was actually my day job (at Intel). > > > > > > The question of how much effort people who update things in core > > > should allocate to fixing 'other' layers has been a conflict > > point > > > for a long time. I'd prefer to see more aggressive > > > blacklisting/removal of recipes that no one has an interest in > > fixing > > > and updating. > > > > If anything this would be my fault for merging things despite there > > being concerns raised. I have to admit I'd seen other patches and > > therefore erroneously thought the issues we mostly resolved. > > > > Should OE-Core block on all issues being resolved before merging? > > I'm torn on that, I realise there are pros and cons. > > If an issue is there and gets reported after it’s merged I think it’s > fine to do whatever is needed after the fact however if testing > master-next from oe-core and reported against it I think this will > help you in longer run if these master-next issues are looked into > and blocked on. We should not run Oe-core so fast that other layers > fall way back behind where they start supporting just releases and > you have lost free integration testing that other layers would offer > > If there are too many reports then it would be questionable to block > on it but I don’t think that’s the case As I said, I understand the desire and from some perspectives it makes a lot of sense. From a human resource perspective I have concerns. Following this through: This means we should make meta-oe testing a default part of full builds, maybe even quick? We're then effectively highlighting any issues and blocking patches on testing with meta-oe. We should then really update the maintainer guidelines to highlight they should be testing with meta-oe as well? world builds of it? Should we include other layers too? We're actually at the point where project members want their layers tested so they get to know ASAP about failures. We (as in the TSC) did discuss this and basically said that a heads up warning of problems was what we could realistically achieve, not blocking. meta-oe is special in some ways, is it that special? I suspect a more realistic take away is we figure out what set of tests are missing for oe-core and add them, such that changes don't break layers. In this case we're clearly missing some meson usecase tests? Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 16/19] meson: update to 0.52.0
On Sun, 2019-10-20 at 06:51 +0530, Khem Raj wrote: > > > On Sat, Oct 19, 2019 at 2:56 AM > wrote: > > On Fri, 2019-10-18 at 20:49 +0200, Alexander Kanavin wrote: > > > I certainly don't mean to ignore those reports, it's just that > > due to > > > my ongoing health problems, and having to dedicate most of my > > energy > > > to the day job (https://mbition.io/en/home/), I am not currently > > able > > > to work on the upstream issues in a timely manner the way I used > > to > > > when maintaining core was actually my day job (at Intel). > > > > > > The question of how much effort people who update things in core > > > should allocate to fixing 'other' layers has been a conflict > > point > > > for a long time. I'd prefer to see more aggressive > > > blacklisting/removal of recipes that no one has an interest in > > fixing > > > and updating. > > > > If anything this would be my fault for merging things despite there > > being concerns raised. I have to admit I'd seen other patches and > > therefore erroneously thought the issues we mostly resolved. > > > > Should OE-Core block on all issues being resolved before merging? > > I'm > > torn on that, I realise there are pros and cons. > > If an issue is there and gets reported after it’s merged I think it’s > fine to do whatever is needed after the fact however if testing > master-next from oe-core and reported against it I think this will > help you in longer run if these master-next issues are looked into > and blocked on. We should not run Oe-core so fast that other layers > fall way back behind where they start supporting just releases and > you have lost free integration testing that other layers would offer > > If there are too many reports then it would be questionable to block > on it but I don’t think that’s the case Feeling suitably responsible for this breakage, I looked into it. The following two patches, one for meson in OE-Core and the other for dconf in meta-oe seem to address the problem. I'm not entirely sure they're correct but they don't actually change the library binary so its probably fine whilst upstream sorts it out. If they look ok to you I'll submit them "properly". Cheers, Richard From 7ebd50f90b3b7f4e1dc56f07ae7e8e02275d41c8 Mon Sep 17 00:00:00 2001 From: Richard Purdie Date: Sun, 20 Oct 2019 13:27:07 +0100 Subject: [PATCH] dconf: Fix build with meson 0.52 Signed-off-by: Richard Purdie --- .../dconf/dconf/fix-meson-0.52.patch | 25 +++ .../recipes-gnome/dconf/dconf_0.32.0.bb | 1 + 2 files changed, 26 insertions(+) create mode 100644 meta-gnome/recipes-gnome/dconf/dconf/fix-meson-0.52.patch diff --git a/meta-gnome/recipes-gnome/dconf/dconf/fix-meson-0.52.patch b/meta-gnome/recipes-gnome/dconf/dconf/fix-meson-0.52.patch new file mode 100644 index 0..bca021347 --- /dev/null +++ b/meta-gnome/recipes-gnome/dconf/dconf/fix-meson-0.52.patch @@ -0,0 +1,25 @@ +With meson 0.52 the build fails due to duplicate symbols. There is a fix +to meson but the dconf build also needs tweaking. + +https://gitlab.gnome.org/GNOME/dconf/issues/59 +https://github.com/mesonbuild/meson/pull/5936 + +Despite the comments there about this being incorrect, libdconf is unchanged +between 0.51 and 0.52 and this patch. + +Upstream-Status: Pending [under discussion, see above links] +Signed-off-by: Richard Purdie + +Index: dconf-0.32.0/client/meson.build +=== +--- dconf-0.32.0.orig/client/meson.build dconf-0.32.0/client/meson.build +@@ -28,7 +28,7 @@ libdconf_client = static_library( + + libdconf_client_dep = declare_dependency( + dependencies: gio_dep, +- link_whole: libdconf_client, ++ link_with: libdconf_client, + ) + + libdconf = shared_library( diff --git a/meta-gnome/recipes-gnome/dconf/dconf_0.32.0.bb b/meta-gnome/recipes-gnome/dconf/dconf_0.32.0.bb index 8d1bbdfd1..fec04079e 100644 --- a/meta-gnome/recipes-gnome/dconf/dconf_0.32.0.bb +++ b/meta-gnome/recipes-gnome/dconf/dconf_0.32.0.bb @@ -3,6 +3,7 @@ LICENSE = "LGPLv2.1" LIC_FILES_CHKSUM = "file://COPYING;md5=2d5025d4aa3495befef8f17206a5b0a1" SECTION = "x11/gnome" +SRC_URI += "file://fix-meson-0.52.patch" SRC_URI[archive.md5sum] = "e1ac0b6285abefeed69ca9e380e44f5a" SRC_URI[archive.sha256sum] = "68bce78b19bc94cb2c3bb8587e37f9e5e338568c3a674f86edde9c9f1624ffab" -- 2.17.1 From f52194e9806002e66235f63184a2eea0b15c19a1 Mon Sep 17 00:00:00 2001 From: Richard Purdie Date: Sun, 20 Oct 2019 13:12:32 +0100 Subject: [PATCH] meson: Backport fix to assist meta-oe breakage Add a backported commit from upstream which helps fix build failures in meta-oe. Signed-off-by: Richard Purdie --- meta/recipes-devtools/meson/meson.inc | 1 + ...e971bd320f3df15c1ee74f54858e6792b183.patch | 95 +++ 2 files changed, 96 insertions(+) create mode 100644 meta/recipes-devtools/meson/meson/dbc9e971bd320f3df15c1ee74f54858e6792b183.patch diff --git
[OE-core] Help with intermittent autobuilder exposed bugs
We have a situation brewing on the autobuilder. Each run there are some bugs which sometimes can appear. Law of averages says one or more of the issues below will now appear as we have so many of them. The project's standard processes aren't helping to capture the issues or track them down. With the release mostly sorted out from my perspective I can look at some of the other health aspects of the project. In theory SWAT should have filed bugs for these. In most cases they haven't. If they did, we'd discuss them at triage, decide they looked hard and then there wouldn't be anyone to "assign" to them so they'd most likely end up on my plate anyway. I find it hard to know what to do with these. I already have a load in my bug backlog which I've not gotten sorted out so adding more probably won't help. To summarise the issues [just from the last few builds]: https://autobuilder.yoctoproject.org/typhoon/#/builders/56/builds/756 oe-selftest recipetool.RecipetoolTests.test_recipetool_load_plugin RP has a long standing bug: https://bugzilla.yoctoproject.org/show_bug.cgi?id=13070 https://autobuilder.yoctoproject.org/typhoon/#/builders/72/builds/1177 qa-extras2 step2c testimage logrotate.LogrotateTest.test_2_logrotate for core-image-sato [no open bug?] https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/441 oe-selftest devtool.DevtoolExtractTests.test_devtool_deploy_target [no open bug, unhelpful backtrace from tinfoil] https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/440 oe-sefltest signing.LockedSignatures.test_locked_signatures [no open bug or any idea why it failed] https://autobuilder.yoctoproject.org/typhoon/#/builders/80/builds/440 oe-selftest distrodata.Distrodata.test_maintainer [no open bug, same unhelpful backtrace from tinfoil] https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/440 oe-selftest reproducible.ReproducibleTests.test_reproducible_builds [no open bug?, fedora specific perldoc reproducibility issue] https://autobuilder.yoctoproject.org/typhoon/#/builders/110/builds/52 qemuarm systemd timeout parselogs error """Central error: Oct 19 11:21:48 qemuarm login[228]: pam_systemd(login:session): Failed to create session: Connection timed out""" [no open bug] Some of these are with master-next but I don't believe are related to any issue specific to -next, its just because -next has had more test runs. I'm not sure what we do about this. The SWAT process really needs to pay more attention, equally the people are volunteers and therefore I try to be grateful for any help. These issues are becoming more frequent and mean we lose confidence in the builds which delays patch merging. People often ask me how they can help, ideas on how we can move forward with this would be welcome... I also know Armin has a difficult to debug selftest issue with warrior which is blocking its release build right now. Cheers, Richard -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
