Re: [OE-core] [PATCH 16/19] meson: update to 0.52.0
On Sun, Oct 20, 2019 at 5:53 PM Andreas Müller wrote: > > > > 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 > 15K build tasks later: Have build my images with both patches (meson/dconf): No fallout but more interesting: The do_rootfs [1] issue is gone and the meson patch was the only change I applied. Have no idea how meson affects qemu (did not build from scratch and qemu-native was rebuild due to dependencies). Whatever: Have a full build again \o/ [1] http://lists.openembedded.org/pipermail/openembedded-core/2019-October/288091.html Andreas -- ___ 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
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] [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
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 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 > > It takes most of my time/energy to track the issues with core without > trying to remember that patch X breaks layer Y and that I need a report > back on that combination before I then find a patch and merge it. > > So sorry, I probably shouldn't have taken this :/. > > There is a fundamental issue with having enough people to help work on > these things though and requiring more work for changes to be merged > isn't going to help. I wish I knew what would help. > > 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 Sat, 2019-10-19 at 00:01 +0200, Andreas Müller wrote: > On Fri, Oct 18, 2019 at 8:50 PM 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. > > > > Alex > > > First and most important: Wish you the very best to get back full > health > Second: If I read meson github issues correctly, there are chances > that meson 0.52.1 fixes (works around) static library fallout as seen > on dconf > Third: Taking this in was sub-optimal but: We are close to release > which is btw the most smooth I've ever seen since I follow this > project. > > We're back to dirty master where sh*t happens... Just to be clear for those not following close, this is only on master and not on the release branch which did not get this change. 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 Fri, Oct 18, 2019 at 8:50 PM 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. > > Alex > First and most important: Wish you the very best to get back full health Second: If I read meson github issues correctly, there are chances that meson 0.52.1 fixes (works around) static library fallout as seen on dconf Third: Taking this in was sub-optimal but: We are close to release which is btw the most smooth I've ever seen since I follow this project. We're back to dirty master where sh*t happens... Andreas -- ___ 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 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. It takes most of my time/energy to track the issues with core without trying to remember that patch X breaks layer Y and that I need a report back on that combination before I then find a patch and merge it. So sorry, I probably shouldn't have taken this :/. There is a fundamental issue with having enough people to help work on these things though and requiring more work for changes to be merged isn't going to help. I wish I knew what would help. 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
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.
Alex
On Thu, 17 Oct 2019 at 15:15, Khem Raj wrote:
> On Sat, Oct 12, 2019 at 5:20 PM Khem Raj wrote:
> >
> > On Fri, 2019-10-11 at 13:47 +0200, Alexander Kanavin wrote:
> > > Drop backported patches.
> > >
> > > Signed-off-by: Alexander Kanavin
> > > ---
> > > meta/recipes-devtools/meson/meson.inc | 7 +--
> > > ...efined-by-the-existance-of-a-cross-f.patch | 28 ---
> > > .../0001-Make-CPU-family-warnings-fatal.patch | 8 +--
> > > ...etect-windows-also-if-the-system-str.patch | 29 ---
> > > ...sues-that-arise-when-cross-compiling.patch | 8 +--
> > > ...pport-building-allarch-recipes-again.patch | 4 +-
> > > .../meson/meson/0003-native_bindir.patch | 20
> > > .../meson/meson/vala-cross-compile.patch | 50 ---
> >
> > meson 0.52.x seems to be exposing the dconf build issue.
> >
> > https://errors.yoctoproject.org/Errors/Details/273492/
> >
> > also reported here
> > https://gitlab.gnome.org/GNOME/dconf/issues/59
> >
>
>
> Regardless of this report, this is now merged and I don't see any
> resolution either of a followup
> from the submitter or any other developer. This is quite disheartening
> since it takes a lot of effort to find
> these issues and reports. we should try to be considerate of the
> layers who are trying to keep up with
> OE-Core, like this we won't be able to improve the quality of these
> layers. I understand that there are no breakages seen in OE-cor but we
> should encourage more
> of other layers to test master and especially if there are reports
> than it would be good to heed to them.
>
>
> > >
> > > .../{meson_0.51.2.bb => meson_0.52.0.bb} | 1 -
> > > ...on_0.51.2.bb => nativesdk-meson_0.52.0.bb} | 0
> > > 10 files changed, 22 insertions(+), 133 deletions(-)
> > > delete mode 100644 meta/recipes-devtools/meson/meson/0001-Cross-
> > > build-is-defined-by-the-existance-of-a-cross-f.patch
> > > delete mode 100644 meta/recipes-devtools/meson/meson/0001-
> > > environment.py-detect-windows-also-if-the-system-str.patch
> > > delete mode 100644 meta/recipes-devtools/meson/meson/vala-cross-
> > > compile.patch
> > > rename meta/recipes-devtools/meson/{meson_0.51.2.bb =>
> > > meson_0.52.0.bb} (97%)
> > > rename meta/recipes-devtools/meson/{nativesdk-meson_0.51.2.bb =>
> > > nativesdk-meson_0.52.0.bb} (100%)
> > >
> > > diff --git a/meta/recipes-devtools/meson/meson.inc b/meta/recipes-
> > > devtools/meson/meson.inc
> > > index 8219d87c741..ae0091c051c 100644
> > > --- a/meta/recipes-devtools/meson/meson.inc
> > > +++ b/meta/recipes-devtools/meson/meson.inc
> > > @@ -14,14 +14,11 @@ SRC_URI = "
> > > https://github.com/mesonbuild/meson/releases/download/${PV}/meson-${P
> > > file://0001-python-module-do-not-manipulate-the-
> > > environment-when.patch \
> > > file://disable-rpath-handling.patch \
> > > file://cross-prop-default.patch \
> > > - file://0001-environment.py-detect-windows-also-if-the-
> > > system-str.patch \
> > > - file://0001-Cross-build-is-defined-by-the-existance-of-a-
> > > cross-f.patch \
> > > file://0001-mesonbuild-environment.py-check-environment-
> > > for-vari.patch \
> > > file://0001-modules-python.py-do-not-substitute-python-s-
> > > install.patch \
> > > - file://vala-cross-compile.patch \
> > > "
> > > -SRC_URI[sha256sum] =
> > > "23688f0fc90be623d98e80e1defeea92bbb7103bf9336a5f5b9865d36e892d76"
> > > -SRC_URI[md5sum] = "d46c4a8e3cfd27f90e2c6fe4a69e574b"
> > > +SRC_URI[sha256sum] =
> > > "d60f75f0dedcc4fd249dbc7519d6f3ce6df490033d276ef1cf27453ef4938d32"
> > > +SRC_URI[md5sum] = "7ea7772414dda8ae11072244bf7ba991"
> > >
> > > SRC_URI_append_class-native = " \
> > > file://0001-Make-CPU-family-warnings-fatal.patch \
> > > diff --git a/meta/recipes-devtools/meson/meson/0001-Cross-build-is-
> > > defined-by-the-existance-of-a-cross-f.patch b/meta/recipes-
> > > devtools/meson/meson/0001-Cross-build-is-defined-by-the-existance-of-
> > > a-cross-f.patch
> > > deleted file mode 100644
> > > index a5dbb81b088..000
> > > --- a/meta/recipes-devtools/meson/meson/0001-Cross-build-is-defined-
> > > by-the-existance-of-a-cross-f.patch
> > > +++ /dev/null
> > > @@ -1,28 +0,0 @@
> > > -Upstream-Status: Backport
> > > -Signed-off-by: Ross Burton
> > > -
> > > -From
Re: [OE-core] [PATCH 16/19] meson: update to 0.52.0
On Thu, Oct 17, 2019 at 3:15 PM Khem Raj wrote: > > meson 0.52.x seems to be exposing the dconf build issue. > > > > https://errors.yoctoproject.org/Errors/Details/273492/ > > > > also reported here > > https://gitlab.gnome.org/GNOME/dconf/issues/59 > > > > > Regardless of this report, this is now merged and I don't see any > resolution either of a followup > from the submitter or any other developer. This is quite disheartening > since it takes a lot of effort to find > these issues and reports. we should try to be considerate of the > layers who are trying to keep up with > OE-Core, like this we won't be able to improve the quality of these > layers. I understand that there are no breakages seen in OE-cor but we > should encourage more > of other layers to test master and especially if there are reports > than it would be good to heed to them. > https://github.com/mesonbuild/meson/pull/6030 looks seems to address. Cannot test currently - am in 48h build from scratch currently (with this patch reverted) Andreas -- ___ 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 Sat, Oct 12, 2019 at 5:20 PM Khem Raj wrote:
>
> On Fri, 2019-10-11 at 13:47 +0200, Alexander Kanavin wrote:
> > Drop backported patches.
> >
> > Signed-off-by: Alexander Kanavin
> > ---
> > meta/recipes-devtools/meson/meson.inc | 7 +--
> > ...efined-by-the-existance-of-a-cross-f.patch | 28 ---
> > .../0001-Make-CPU-family-warnings-fatal.patch | 8 +--
> > ...etect-windows-also-if-the-system-str.patch | 29 ---
> > ...sues-that-arise-when-cross-compiling.patch | 8 +--
> > ...pport-building-allarch-recipes-again.patch | 4 +-
> > .../meson/meson/0003-native_bindir.patch | 20
> > .../meson/meson/vala-cross-compile.patch | 50 ---
>
> meson 0.52.x seems to be exposing the dconf build issue.
>
> https://errors.yoctoproject.org/Errors/Details/273492/
>
> also reported here
> https://gitlab.gnome.org/GNOME/dconf/issues/59
>
Regardless of this report, this is now merged and I don't see any
resolution either of a followup
from the submitter or any other developer. This is quite disheartening
since it takes a lot of effort to find
these issues and reports. we should try to be considerate of the
layers who are trying to keep up with
OE-Core, like this we won't be able to improve the quality of these
layers. I understand that there are no breakages seen in OE-cor but we
should encourage more
of other layers to test master and especially if there are reports
than it would be good to heed to them.
> >
> > .../{meson_0.51.2.bb => meson_0.52.0.bb} | 1 -
> > ...on_0.51.2.bb => nativesdk-meson_0.52.0.bb} | 0
> > 10 files changed, 22 insertions(+), 133 deletions(-)
> > delete mode 100644 meta/recipes-devtools/meson/meson/0001-Cross-
> > build-is-defined-by-the-existance-of-a-cross-f.patch
> > delete mode 100644 meta/recipes-devtools/meson/meson/0001-
> > environment.py-detect-windows-also-if-the-system-str.patch
> > delete mode 100644 meta/recipes-devtools/meson/meson/vala-cross-
> > compile.patch
> > rename meta/recipes-devtools/meson/{meson_0.51.2.bb =>
> > meson_0.52.0.bb} (97%)
> > rename meta/recipes-devtools/meson/{nativesdk-meson_0.51.2.bb =>
> > nativesdk-meson_0.52.0.bb} (100%)
> >
> > diff --git a/meta/recipes-devtools/meson/meson.inc b/meta/recipes-
> > devtools/meson/meson.inc
> > index 8219d87c741..ae0091c051c 100644
> > --- a/meta/recipes-devtools/meson/meson.inc
> > +++ b/meta/recipes-devtools/meson/meson.inc
> > @@ -14,14 +14,11 @@ SRC_URI = "
> > https://github.com/mesonbuild/meson/releases/download/${PV}/meson-${P
> > file://0001-python-module-do-not-manipulate-the-
> > environment-when.patch \
> > file://disable-rpath-handling.patch \
> > file://cross-prop-default.patch \
> > - file://0001-environment.py-detect-windows-also-if-the-
> > system-str.patch \
> > - file://0001-Cross-build-is-defined-by-the-existance-of-a-
> > cross-f.patch \
> > file://0001-mesonbuild-environment.py-check-environment-
> > for-vari.patch \
> > file://0001-modules-python.py-do-not-substitute-python-s-
> > install.patch \
> > - file://vala-cross-compile.patch \
> > "
> > -SRC_URI[sha256sum] =
> > "23688f0fc90be623d98e80e1defeea92bbb7103bf9336a5f5b9865d36e892d76"
> > -SRC_URI[md5sum] = "d46c4a8e3cfd27f90e2c6fe4a69e574b"
> > +SRC_URI[sha256sum] =
> > "d60f75f0dedcc4fd249dbc7519d6f3ce6df490033d276ef1cf27453ef4938d32"
> > +SRC_URI[md5sum] = "7ea7772414dda8ae11072244bf7ba991"
> >
> > SRC_URI_append_class-native = " \
> > file://0001-Make-CPU-family-warnings-fatal.patch \
> > diff --git a/meta/recipes-devtools/meson/meson/0001-Cross-build-is-
> > defined-by-the-existance-of-a-cross-f.patch b/meta/recipes-
> > devtools/meson/meson/0001-Cross-build-is-defined-by-the-existance-of-
> > a-cross-f.patch
> > deleted file mode 100644
> > index a5dbb81b088..000
> > --- a/meta/recipes-devtools/meson/meson/0001-Cross-build-is-defined-
> > by-the-existance-of-a-cross-f.patch
> > +++ /dev/null
> > @@ -1,28 +0,0 @@
> > -Upstream-Status: Backport
> > -Signed-off-by: Ross Burton
> > -
> > -From 0b4d1e8afd5428a495f8624ee061f63977b4c268 Mon Sep 17 00:00:00
> > 2001
> > -From: Jussi Pakkanen
> > -Date: Sun, 6 Oct 2019 15:17:32 +0300
> > -Subject: [PATCH] Cross build is defined by the existance of a cross
> > file.
> > -
> >
> > - mesonbuild/environment.py | 2 +-
> > - 2 files changed, 2 insertions(+), 2 deletions(-)
> > -
> > -diff --git a/mesonbuild/environment.py b/mesonbuild/environment.py
> > -index e5d041b4..03c65688 100644
> > a/mesonbuild/environment.py
> > -+++ b/mesonbuild/environment.py
> > -@@ -611,7 +611,7 @@ class Environment:
> > - self.first_invocation = True
> > -
> > - def is_cross_build(self) -> bool:
> > --return not
> > self.machines.matches_build_machine(MachineChoice.HOST)
> > -+return self.coredata.is_cross_build()
> > -
> > - def dump_coredata(self):
> > - return
Re: [OE-core] [PATCH 16/19] meson: update to 0.52.0
On Fri, 2019-10-11 at 13:47 +0200, Alexander Kanavin wrote:
> Drop backported patches.
>
> Signed-off-by: Alexander Kanavin
> ---
> meta/recipes-devtools/meson/meson.inc | 7 +--
> ...efined-by-the-existance-of-a-cross-f.patch | 28 ---
> .../0001-Make-CPU-family-warnings-fatal.patch | 8 +--
> ...etect-windows-also-if-the-system-str.patch | 29 ---
> ...sues-that-arise-when-cross-compiling.patch | 8 +--
> ...pport-building-allarch-recipes-again.patch | 4 +-
> .../meson/meson/0003-native_bindir.patch | 20
> .../meson/meson/vala-cross-compile.patch | 50 ---
meson 0.52.x seems to be exposing the dconf build issue.
https://errors.yoctoproject.org/Errors/Details/273492/
also reported here
https://gitlab.gnome.org/GNOME/dconf/issues/59
>
> .../{meson_0.51.2.bb => meson_0.52.0.bb} | 1 -
> ...on_0.51.2.bb => nativesdk-meson_0.52.0.bb} | 0
> 10 files changed, 22 insertions(+), 133 deletions(-)
> delete mode 100644 meta/recipes-devtools/meson/meson/0001-Cross-
> build-is-defined-by-the-existance-of-a-cross-f.patch
> delete mode 100644 meta/recipes-devtools/meson/meson/0001-
> environment.py-detect-windows-also-if-the-system-str.patch
> delete mode 100644 meta/recipes-devtools/meson/meson/vala-cross-
> compile.patch
> rename meta/recipes-devtools/meson/{meson_0.51.2.bb =>
> meson_0.52.0.bb} (97%)
> rename meta/recipes-devtools/meson/{nativesdk-meson_0.51.2.bb =>
> nativesdk-meson_0.52.0.bb} (100%)
>
> diff --git a/meta/recipes-devtools/meson/meson.inc b/meta/recipes-
> devtools/meson/meson.inc
> index 8219d87c741..ae0091c051c 100644
> --- a/meta/recipes-devtools/meson/meson.inc
> +++ b/meta/recipes-devtools/meson/meson.inc
> @@ -14,14 +14,11 @@ SRC_URI = "
> https://github.com/mesonbuild/meson/releases/download/${PV}/meson-${P
> file://0001-python-module-do-not-manipulate-the-
> environment-when.patch \
> file://disable-rpath-handling.patch \
> file://cross-prop-default.patch \
> - file://0001-environment.py-detect-windows-also-if-the-
> system-str.patch \
> - file://0001-Cross-build-is-defined-by-the-existance-of-a-
> cross-f.patch \
> file://0001-mesonbuild-environment.py-check-environment-
> for-vari.patch \
> file://0001-modules-python.py-do-not-substitute-python-s-
> install.patch \
> - file://vala-cross-compile.patch \
> "
> -SRC_URI[sha256sum] =
> "23688f0fc90be623d98e80e1defeea92bbb7103bf9336a5f5b9865d36e892d76"
> -SRC_URI[md5sum] = "d46c4a8e3cfd27f90e2c6fe4a69e574b"
> +SRC_URI[sha256sum] =
> "d60f75f0dedcc4fd249dbc7519d6f3ce6df490033d276ef1cf27453ef4938d32"
> +SRC_URI[md5sum] = "7ea7772414dda8ae11072244bf7ba991"
>
> SRC_URI_append_class-native = " \
> file://0001-Make-CPU-family-warnings-fatal.patch \
> diff --git a/meta/recipes-devtools/meson/meson/0001-Cross-build-is-
> defined-by-the-existance-of-a-cross-f.patch b/meta/recipes-
> devtools/meson/meson/0001-Cross-build-is-defined-by-the-existance-of-
> a-cross-f.patch
> deleted file mode 100644
> index a5dbb81b088..000
> --- a/meta/recipes-devtools/meson/meson/0001-Cross-build-is-defined-
> by-the-existance-of-a-cross-f.patch
> +++ /dev/null
> @@ -1,28 +0,0 @@
> -Upstream-Status: Backport
> -Signed-off-by: Ross Burton
> -
> -From 0b4d1e8afd5428a495f8624ee061f63977b4c268 Mon Sep 17 00:00:00
> 2001
> -From: Jussi Pakkanen
> -Date: Sun, 6 Oct 2019 15:17:32 +0300
> -Subject: [PATCH] Cross build is defined by the existance of a cross
> file.
> -
>
> - mesonbuild/environment.py | 2 +-
> - 2 files changed, 2 insertions(+), 2 deletions(-)
> -
> -diff --git a/mesonbuild/environment.py b/mesonbuild/environment.py
> -index e5d041b4..03c65688 100644
> a/mesonbuild/environment.py
> -+++ b/mesonbuild/environment.py
> -@@ -611,7 +611,7 @@ class Environment:
> - self.first_invocation = True
> -
> - def is_cross_build(self) -> bool:
> --return not
> self.machines.matches_build_machine(MachineChoice.HOST)
> -+return self.coredata.is_cross_build()
> -
> - def dump_coredata(self):
> - return coredata.save(self.coredata, self.get_build_dir())
> ---
> -2.20.1
> -
> diff --git a/meta/recipes-devtools/meson/meson/0001-Make-CPU-family-
> warnings-fatal.patch b/meta/recipes-devtools/meson/meson/0001-Make-
> CPU-family-warnings-fatal.patch
> index 444fc081686..fc55dcacf6d 100644
> --- a/meta/recipes-devtools/meson/meson/0001-Make-CPU-family-
> warnings-fatal.patch
> +++ b/meta/recipes-devtools/meson/meson/0001-Make-CPU-family-
> warnings-fatal.patch
> @@ -1,4 +1,4 @@
> -From f70fee13e4dbc757cd8153cd42d92fa9394fb542 Mon Sep 17 00:00:00
> 2001
> +From c07d29b715209cd5d75b142a00a540d45b00c36d Mon Sep 17 00:00:00
> 2001
> From: Ross Burton
> Date: Tue, 3 Jul 2018 13:59:09 +0100
> Subject: [PATCH] Make CPU family warnings fatal
> @@ -12,7 +12,7 @@ Signed-off-by: Ross Burton
> 2 files changed, 2 insertions(+), 4
[OE-core] [PATCH 16/19] meson: update to 0.52.0
Drop backported patches.
Signed-off-by: Alexander Kanavin
---
meta/recipes-devtools/meson/meson.inc | 7 +--
...efined-by-the-existance-of-a-cross-f.patch | 28 ---
.../0001-Make-CPU-family-warnings-fatal.patch | 8 +--
...etect-windows-also-if-the-system-str.patch | 29 ---
...sues-that-arise-when-cross-compiling.patch | 8 +--
...pport-building-allarch-recipes-again.patch | 4 +-
.../meson/meson/0003-native_bindir.patch | 20
.../meson/meson/vala-cross-compile.patch | 50 ---
.../{meson_0.51.2.bb => meson_0.52.0.bb} | 1 -
...on_0.51.2.bb => nativesdk-meson_0.52.0.bb} | 0
10 files changed, 22 insertions(+), 133 deletions(-)
delete mode 100644
meta/recipes-devtools/meson/meson/0001-Cross-build-is-defined-by-the-existance-of-a-cross-f.patch
delete mode 100644
meta/recipes-devtools/meson/meson/0001-environment.py-detect-windows-also-if-the-system-str.patch
delete mode 100644 meta/recipes-devtools/meson/meson/vala-cross-compile.patch
rename meta/recipes-devtools/meson/{meson_0.51.2.bb => meson_0.52.0.bb} (97%)
rename meta/recipes-devtools/meson/{nativesdk-meson_0.51.2.bb =>
nativesdk-meson_0.52.0.bb} (100%)
diff --git a/meta/recipes-devtools/meson/meson.inc
b/meta/recipes-devtools/meson/meson.inc
index 8219d87c741..ae0091c051c 100644
--- a/meta/recipes-devtools/meson/meson.inc
+++ b/meta/recipes-devtools/meson/meson.inc
@@ -14,14 +14,11 @@ SRC_URI =
"https://github.com/mesonbuild/meson/releases/download/${PV}/meson-${P
file://0001-python-module-do-not-manipulate-the-environment-when.patch \
file://disable-rpath-handling.patch \
file://cross-prop-default.patch \
-
file://0001-environment.py-detect-windows-also-if-the-system-str.patch \
-
file://0001-Cross-build-is-defined-by-the-existance-of-a-cross-f.patch \
file://0001-mesonbuild-environment.py-check-environment-for-vari.patch \
file://0001-modules-python.py-do-not-substitute-python-s-install.patch \
- file://vala-cross-compile.patch \
"
-SRC_URI[sha256sum] =
"23688f0fc90be623d98e80e1defeea92bbb7103bf9336a5f5b9865d36e892d76"
-SRC_URI[md5sum] = "d46c4a8e3cfd27f90e2c6fe4a69e574b"
+SRC_URI[sha256sum] =
"d60f75f0dedcc4fd249dbc7519d6f3ce6df490033d276ef1cf27453ef4938d32"
+SRC_URI[md5sum] = "7ea7772414dda8ae11072244bf7ba991"
SRC_URI_append_class-native = " \
file://0001-Make-CPU-family-warnings-fatal.patch \
diff --git
a/meta/recipes-devtools/meson/meson/0001-Cross-build-is-defined-by-the-existance-of-a-cross-f.patch
b/meta/recipes-devtools/meson/meson/0001-Cross-build-is-defined-by-the-existance-of-a-cross-f.patch
deleted file mode 100644
index a5dbb81b088..000
---
a/meta/recipes-devtools/meson/meson/0001-Cross-build-is-defined-by-the-existance-of-a-cross-f.patch
+++ /dev/null
@@ -1,28 +0,0 @@
-Upstream-Status: Backport
-Signed-off-by: Ross Burton
-
-From 0b4d1e8afd5428a495f8624ee061f63977b4c268 Mon Sep 17 00:00:00 2001
-From: Jussi Pakkanen
-Date: Sun, 6 Oct 2019 15:17:32 +0300
-Subject: [PATCH] Cross build is defined by the existance of a cross file.
-
- mesonbuild/environment.py | 2 +-
- 2 files changed, 2 insertions(+), 2 deletions(-)
-
-diff --git a/mesonbuild/environment.py b/mesonbuild/environment.py
-index e5d041b4..03c65688 100644
a/mesonbuild/environment.py
-+++ b/mesonbuild/environment.py
-@@ -611,7 +611,7 @@ class Environment:
- self.first_invocation = True
-
- def is_cross_build(self) -> bool:
--return not self.machines.matches_build_machine(MachineChoice.HOST)
-+return self.coredata.is_cross_build()
-
- def dump_coredata(self):
- return coredata.save(self.coredata, self.get_build_dir())
---
-2.20.1
-
diff --git
a/meta/recipes-devtools/meson/meson/0001-Make-CPU-family-warnings-fatal.patch
b/meta/recipes-devtools/meson/meson/0001-Make-CPU-family-warnings-fatal.patch
index 444fc081686..fc55dcacf6d 100644
---
a/meta/recipes-devtools/meson/meson/0001-Make-CPU-family-warnings-fatal.patch
+++
b/meta/recipes-devtools/meson/meson/0001-Make-CPU-family-warnings-fatal.patch
@@ -1,4 +1,4 @@
-From f70fee13e4dbc757cd8153cd42d92fa9394fb542 Mon Sep 17 00:00:00 2001
+From c07d29b715209cd5d75b142a00a540d45b00c36d Mon Sep 17 00:00:00 2001
From: Ross Burton
Date: Tue, 3 Jul 2018 13:59:09 +0100
Subject: [PATCH] Make CPU family warnings fatal
@@ -12,7 +12,7 @@ Signed-off-by: Ross Burton
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/mesonbuild/envconfig.py b/mesonbuild/envconfig.py
-index 03c6346..86b350b 100644
+index a59cd89..17de654 100644
--- a/mesonbuild/envconfig.py
+++ b/mesonbuild/envconfig.py
@@ -186,7 +186,7 @@ class MachineInfo:
@@ -25,10 +25,10 @@ index 03c6346..86b350b 100644
endian = literal['endian']
if endian not in ('little', 'big'):
diff --git a/mesonbuild/environment.py b/mesonbuild/environment.py
-index 0cfdf9c..40aa189 100644
+index
