Re: [OE-core] [PATCH] dhcp: fix build issue with libxml2 support
ping! BR, Awais From: Belal, Awais Sent: Wednesday, October 25, 2017 9:03 PM To: openembedded-core@lists.openembedded.org Cc: Belal, Awais Subject: [PATCH] dhcp: fix build issue with libxml2 support A missing case breaks the build when libxml2 is required and found appropriately. The third argument to the function AC_SEARCH_LIB is action-if-found which was mistakenly been used for the case where the library is not found and hence breaks the configure phase where it shoud actually pass. We now pass on silently when action-if-found is executed. Signed-off-by: Awais Belal --- ...correct-the-intention-for-xml2-lib-search.patch | 35 ++ meta/recipes-connectivity/dhcp/dhcp_4.3.6.bb | 1 + 2 files changed, 36 insertions(+) create mode 100644 meta/recipes-connectivity/dhcp/dhcp/0012-dhcp-correct-the-intention-for-xml2-lib-search.patch diff --git a/meta/recipes-connectivity/dhcp/dhcp/0012-dhcp-correct-the-intention-for-xml2-lib-search.patch b/meta/recipes-connectivity/dhcp/dhcp/0012-dhcp-correct-the-intention-for-xml2-lib-search.patch new file mode 100644 index 00..6ded764d0e --- /dev/null +++ b/meta/recipes-connectivity/dhcp/dhcp/0012-dhcp-correct-the-intention-for-xml2-lib-search.patch @@ -0,0 +1,35 @@ +From 501543b3ef715488a142e3d301ff2733aa33eec7 Mon Sep 17 00:00:00 2001 +From: Awais Belal +Date: Wed, 25 Oct 2017 21:00:05 +0500 +Subject: [PATCH] dhcp: correct the intention for xml2 lib search + +A missing case breaks the build when libxml2 is +required and found appropriately. The third argument +to the function AC_SEARCH_LIB is action-if-found which +was mistakenly been used for the case where the library +is not found and hence breaks the configure phase +where it shoud actually pass. +We now pass on silently when action-if-found is +executed. + +Signed-off-by: Awais Belal +--- + configure.ac | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/configure.ac b/configure.ac +index bfe988a..f0459e6 100644 +--- a/configure.ac b/configure.ac +@@ -608,7 +608,7 @@ AC_ARG_WITH(libxml2, + with_libxml2="$withval", with_libxml2="no") + + if test x$with_libxml2 != xno; then +- AC_SEARCH_LIBS(xmlTextWriterStartElement, [xml2], ++ AC_SEARCH_LIBS(xmlTextWriterStartElement, [xml2],, + [if test x$with_libxml2 != xauto; then + AC_MSG_FAILURE([*** Cannot find xmlTextWriterStartElement with -lxml2 and libxml2 was requested]) + fi]) +-- +2.11.1 + diff --git a/meta/recipes-connectivity/dhcp/dhcp_4.3.6.bb b/meta/recipes-connectivity/dhcp/dhcp_4.3.6.bb index 4634a01b04..6615ae2555 100644 --- a/meta/recipes-connectivity/dhcp/dhcp_4.3.6.bb +++ b/meta/recipes-connectivity/dhcp/dhcp_4.3.6.bb @@ -11,6 +11,7 @@ SRC_URI += "file://0001-define-macro-_PATH_DHCPD_CONF-and-_PATH_DHCLIENT_CON.pat file://0009-remove-dhclient-script-bash-dependency.patch \ file://0010-build-shared-libs.patch \ file://0011-Moved-the-call-to-isc_app_ctxstart-to-not-get-signal.patch \ +file://0012-dhcp-correct-the-intention-for-xml2-lib-search.patch \ " SRC_URI[md5sum] = "afa6e9b3eb7539ea048421a82c668adc" -- 2.11.1 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] wic: When using --use-uuid make sure that we update the fstab with PARTUUID
On Fri, Nov 03, 2017 at 08:51:50AM -0400, Tom Rini wrote: > On Fri, Oct 20, 2017 at 09:15:05AM -0400, Tom Rini wrote: > > On Tue, Oct 10, 2017 at 05:01:49PM -0400, Tom Rini wrote: > > > On Thu, Sep 21, 2017 at 01:46:16PM -0400, Tom Rini wrote: > > > > When we have been told to use the UUID we should also update the fstab > > > > to make use of PARTUUID instead of hard-coding the device in question. > > > > This will make the resulting image much more portable. > > > > > > > > Signed-off-by: Tom Rini > > > > --- > > > > scripts/lib/wic/plugins/imager/direct.py | 9 ++--- > > > > 1 file changed, 6 insertions(+), 3 deletions(-) > > > > > > Where we did we end up with this? Ed pointed out that you can tell wic > > > to use a specific UUID, so reproducible images are not a problem. And > > > making images that are readily portable is why other distros use > > > UUID/LABEL and not device names as much as possible. I personally enjoy > > > being able to put an image on uSD for minnow and have it work :) > > > Thanks! > > > > ping? > > I was just reminded about the real problems this solves (swap isn't > /dev/sda3, boot is being excessively slow), so, ping? > I'm generally ok with the patchset. The only thing I'm thinking of is if busybox mount supports PARTUUID syntax in fstab. Can you check this, please? I'd like to see Otavio's confirmation that --uuid option solves his reproducible builds concern. Can you rebase your patchset on top of current master? It would be also nice to get this functionality covered by tests. -- Regards, Ed -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] python-mako: Add back the python2 version.
On 11/05/2017 02:25 AM, Moritz Fischer wrote: Add back the recipe for the python2 version. Signed-off-by: Moritz Fischer --- Is it possible to get that backported into rocko? I somehow didn't see the patch that removed it go out on the list. You need to explain why, as we're actively trying to remove everything python2 from oe-core. Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Releases of BitBake to package for Fedora?
On 11/05/2017 05:09 PM, Neal Gompa wrote: Apologies if this is the wrong mailing list for this, but I'm looking reintroduce BitBake into Fedora, but it seems like there hasn't been releases in two years. I also cannot identify anywhere that provides tarballs of BitBake to package. The correct place to ask is probably bitbake-devel list. Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 2/2] lib/oe/package_manager.py (rpm): Allow use of non-signed feeds
On 11/06/2017 07:04 AM, Neal Gompa wrote: This logic is kind of dumb, but basically, this is how this works: gpgcheck - controls pkg_gpgcheck and repo_gpgcheck. With gpgcheck=1, DNF defaults to pkg_gpgcheck=1 and repo_gpgcheck=0, but if gpgcheck=0, repo_gpgcheck is forced off. pkg_gpgcheck (not currently working) repo_gpgcheck - enable repo_gpgcheck, this is default to 0 (thus, disabled) At some point, this needs to be fixed in libdnf and dnf so that the options are saner... Dnf documentation claims otherwise: gpgcheck is for package signing and repo_gpgcheck is for feed signing, one is not dependent on the other. I looked at the code, and couldn't find any spot where one overrides or controls the other. Can you point it out please? Until then, I think the current code is correct. Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Releases of BitBake to package for Fedora?
The bitbake API isn't really stable and has a reasonable amount of change, so if you were to package it then there's a good chance it would be out of date within six months and people who wanted to use the latest oe-core release against the packaged bitbake would hit API version errors. The recommended usage is to bundle in some way bitbake and the metadata (combo-layer, submodules, repo, whatever). As such there are no tarballs. There are branches for each version and commits where the version is bumped, if you're really determined to package a snapshot. Ross On 5 November 2017 at 15:09, Neal Gompa wrote: > Hey all, > > Apologies if this is the wrong mailing list for this, but I'm looking > reintroduce BitBake into Fedora, but it seems like there hasn't been > releases in two years. I also cannot identify anywhere that provides > tarballs of BitBake to package. > > Am I not looking in the right place? > > I looked in the following locations: > > * GitHub: https://github.com/openembedded/bitbake > * OE Git: http://git.openembedded.org/bitbake/ > * Yocto downloads page: https://www.yoctoproject.org/downloads/tools > > The Fedora package previously referenced snapshot tarballs generated > by tagged releases in OE Git, but there haven't been new tagged > releases in two years. > > I'd appreciate any help here. > > Thanks in advance and best regards! > > -- > 真実はいつも一つ！/ Always, there's only one truth! > -- > ___ > 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 1/2] wic: When using --use-uuid make sure that we update the fstab with PARTUUID
On Mon, Nov 6, 2017 at 8:08 AM, Ed Bartosh wrote: > On Fri, Nov 03, 2017 at 08:51:50AM -0400, Tom Rini wrote: >> On Fri, Oct 20, 2017 at 09:15:05AM -0400, Tom Rini wrote: >> > On Tue, Oct 10, 2017 at 05:01:49PM -0400, Tom Rini wrote: >> > > On Thu, Sep 21, 2017 at 01:46:16PM -0400, Tom Rini wrote: >> > > > When we have been told to use the UUID we should also update the fstab >> > > > to make use of PARTUUID instead of hard-coding the device in question. >> > > > This will make the resulting image much more portable. >> > > > >> > > > Signed-off-by: Tom Rini >> > > > --- >> > > > scripts/lib/wic/plugins/imager/direct.py | 9 ++--- >> > > > 1 file changed, 6 insertions(+), 3 deletions(-) >> > > >> > > Where we did we end up with this? Ed pointed out that you can tell wic >> > > to use a specific UUID, so reproducible images are not a problem. And >> > > making images that are readily portable is why other distros use >> > > UUID/LABEL and not device names as much as possible. I personally enjoy >> > > being able to put an image on uSD for minnow and have it work :) >> > > Thanks! >> > >> > ping? >> >> I was just reminded about the real problems this solves (swap isn't >> /dev/sda3, boot is being excessively slow), so, ping? >> > > I'm generally ok with the patchset. The only thing I'm thinking of is if > busybox mount > supports PARTUUID syntax in fstab. Can you check this, please? It does. > I'd like to see Otavio's confirmation that --uuid option solves > his reproducible builds concern. I am not against it if the no-fstab-update consider this too. Using uuid when making a fstab makes more sense but the possibility to not touch the fstab must be kept. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] automatic recipe upgrades - making them better and sweeter
Hello, I've been asked by RP to look into making automatic package upgrades work better, so here's what I'd like to improve: 1) when using 'devtool upgrade', remove the need to specify version and source revision on the command line, if we want to upgrade to the latest release. There is now distrodata/checkpkg code in place to determine both, so 'devtool upgrade ' could simply default to that. 2) help with LICENSE checksum changes a bit more; both devtool and AUH have some code for this, so I want to review what they do, and consolidate it in a single place. Maintainers should be able to see a diff of what the changes are. 3) 'devtool finish' currently does not handle the recipe upgrade situation well: the new recipe and patches are placed side by side with the current recipe. The old stuff should be removed, and a tentative commit should be created. So maybe add a 'devtool finish-upgrade'. 4) AUH should be stripped to its core business: sending useful emails to maintainers, and leave the rest to devtool. If 'devtool upgrade' succeeded, then corresponding patches should be attached, otherwise (if patch rebase failed, or a fetch issue), at least it could tell what happened and suggest a devtool upgrade command to get started. Any duplicate functionality for upgrading (stuff that is also in devtool) should be removed. Anything I missed? Comments? Thanks, Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] wic: When using --use-uuid make sure that we update the fstab with PARTUUID
On Mon, Nov 06, 2017 at 12:08:29PM +0200, Ed Bartosh wrote: > On Fri, Nov 03, 2017 at 08:51:50AM -0400, Tom Rini wrote: > > On Fri, Oct 20, 2017 at 09:15:05AM -0400, Tom Rini wrote: > > > On Tue, Oct 10, 2017 at 05:01:49PM -0400, Tom Rini wrote: > > > > On Thu, Sep 21, 2017 at 01:46:16PM -0400, Tom Rini wrote: > > > > > When we have been told to use the UUID we should also update the fstab > > > > > to make use of PARTUUID instead of hard-coding the device in question. > > > > > This will make the resulting image much more portable. > > > > > > > > > > Signed-off-by: Tom Rini > > > > > --- > > > > > scripts/lib/wic/plugins/imager/direct.py | 9 ++--- > > > > > 1 file changed, 6 insertions(+), 3 deletions(-) > > > > > > > > Where we did we end up with this? Ed pointed out that you can tell wic > > > > to use a specific UUID, so reproducible images are not a problem. And > > > > making images that are readily portable is why other distros use > > > > UUID/LABEL and not device names as much as possible. I personally enjoy > > > > being able to put an image on uSD for minnow and have it work :) > > > > Thanks! > > > > > > ping? > > > > I was just reminded about the real problems this solves (swap isn't > > /dev/sda3, boot is being excessively slow), so, ping? > > > > I'm generally ok with the patchset. The only thing I'm thinking of is if > busybox mount > supports PARTUUID syntax in fstab. Can you check this, please? > > I'd like to see Otavio's confirmation that --uuid option solves > his reproducible builds concern. > > Can you rebase your patchset on top of current master? Yes, OK. > It would be also nice to get this functionality covered by tests. OK, but what part of oe-selftest, and how exactly? Can one easily check the resulting fstab? -- Tom signature.asc Description: PGP signature -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] wic: When using --use-uuid make sure that we update the fstab with PARTUUID
On Mon, Nov 06, 2017 at 09:36:20AM -0200, Otavio Salvador wrote: > On Mon, Nov 6, 2017 at 8:08 AM, Ed Bartosh wrote: > > On Fri, Nov 03, 2017 at 08:51:50AM -0400, Tom Rini wrote: > >> On Fri, Oct 20, 2017 at 09:15:05AM -0400, Tom Rini wrote: > >> > On Tue, Oct 10, 2017 at 05:01:49PM -0400, Tom Rini wrote: > >> > > On Thu, Sep 21, 2017 at 01:46:16PM -0400, Tom Rini wrote: > >> > > > When we have been told to use the UUID we should also update the > >> > > > fstab > >> > > > to make use of PARTUUID instead of hard-coding the device in > >> > > > question. > >> > > > This will make the resulting image much more portable. > >> > > > > >> > > > Signed-off-by: Tom Rini > >> > > > --- > >> > > > scripts/lib/wic/plugins/imager/direct.py | 9 ++--- > >> > > > 1 file changed, 6 insertions(+), 3 deletions(-) > >> > > > >> > > Where we did we end up with this? Ed pointed out that you can tell wic > >> > > to use a specific UUID, so reproducible images are not a problem. And > >> > > making images that are readily portable is why other distros use > >> > > UUID/LABEL and not device names as much as possible. I personally > >> > > enjoy > >> > > being able to put an image on uSD for minnow and have it work :) > >> > > Thanks! > >> > > >> > ping? > >> > >> I was just reminded about the real problems this solves (swap isn't > >> /dev/sda3, boot is being excessively slow), so, ping? > >> > > > > I'm generally ok with the patchset. The only thing I'm thinking of is if > > busybox mount > > supports PARTUUID syntax in fstab. Can you check this, please? > > It does. It doesn't, you need util-linux for a mount that figures these out (or, it did when I wrote the patch set). That's why 2/2 only updates the systemd canned wks as that _will_ have full mount. But please note that you can already make a wks file that doesn't work with busybox mount by using the --use-uuid flag for non-root partitions :) > > I'd like to see Otavio's confirmation that --uuid option solves > > his reproducible builds concern. > > I am not against it if the no-fstab-update consider this too. Using > uuid when making a fstab makes more sense but the possibility to not > touch the fstab must be kept. Right. I'm only updating the systemd wks file to use this. Nothing forces this option to be globally used. -- Tom signature.asc Description: PGP signature -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] wic: When using --use-uuid make sure that we update the fstab with PARTUUID
On Mon, Nov 6, 2017 at 10:44 AM, Tom Rini wrote: > On Mon, Nov 06, 2017 at 09:36:20AM -0200, Otavio Salvador wrote: >> On Mon, Nov 6, 2017 at 8:08 AM, Ed Bartosh >> wrote: >> > On Fri, Nov 03, 2017 at 08:51:50AM -0400, Tom Rini wrote: >> >> On Fri, Oct 20, 2017 at 09:15:05AM -0400, Tom Rini wrote: >> >> > On Tue, Oct 10, 2017 at 05:01:49PM -0400, Tom Rini wrote: >> >> > > On Thu, Sep 21, 2017 at 01:46:16PM -0400, Tom Rini wrote: >> >> > > > When we have been told to use the UUID we should also update the >> >> > > > fstab >> >> > > > to make use of PARTUUID instead of hard-coding the device in >> >> > > > question. >> >> > > > This will make the resulting image much more portable. >> >> > > > >> >> > > > Signed-off-by: Tom Rini >> >> > > > --- >> >> > > > scripts/lib/wic/plugins/imager/direct.py | 9 ++--- >> >> > > > 1 file changed, 6 insertions(+), 3 deletions(-) >> >> > > >> >> > > Where we did we end up with this? Ed pointed out that you can tell >> >> > > wic >> >> > > to use a specific UUID, so reproducible images are not a problem. And >> >> > > making images that are readily portable is why other distros use >> >> > > UUID/LABEL and not device names as much as possible. I personally >> >> > > enjoy >> >> > > being able to put an image on uSD for minnow and have it work :) >> >> > > Thanks! >> >> > >> >> > ping? >> >> >> >> I was just reminded about the real problems this solves (swap isn't >> >> /dev/sda3, boot is being excessively slow), so, ping? >> >> >> > >> > I'm generally ok with the patchset. The only thing I'm thinking of is if >> > busybox mount >> > supports PARTUUID syntax in fstab. Can you check this, please? >> >> It does. > > It doesn't, you need util-linux for a mount that figures these out (or, > it did when I wrote the patch set). That's why 2/2 only updates the > systemd canned wks as that _will_ have full mount. But please note that > you can already make a wks file that doesn't work with busybox mount by > using the --use-uuid flag for non-root partitions :) For the root, why you don't use U-Boot to figure the uuid and pass it as cmdline, in root=? It is just a question as this is how we fixed this for meta-freescale. -- Otavio Salvador O.S. Systems http://www.ossystems.com.brhttp://code.ossystems.com.br Mobile: +55 (53) 9981-7854Mobile: +1 (347) 903-9750 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH 1/2] wic: When using --use-uuid make sure that we update the fstab with PARTUUID
On Mon, Nov 06, 2017 at 10:51:56AM -0200, Otavio Salvador wrote: > On Mon, Nov 6, 2017 at 10:44 AM, Tom Rini wrote: > > On Mon, Nov 06, 2017 at 09:36:20AM -0200, Otavio Salvador wrote: > >> On Mon, Nov 6, 2017 at 8:08 AM, Ed Bartosh > >> wrote: > >> > On Fri, Nov 03, 2017 at 08:51:50AM -0400, Tom Rini wrote: > >> >> On Fri, Oct 20, 2017 at 09:15:05AM -0400, Tom Rini wrote: > >> >> > On Tue, Oct 10, 2017 at 05:01:49PM -0400, Tom Rini wrote: > >> >> > > On Thu, Sep 21, 2017 at 01:46:16PM -0400, Tom Rini wrote: > >> >> > > > When we have been told to use the UUID we should also update the > >> >> > > > fstab > >> >> > > > to make use of PARTUUID instead of hard-coding the device in > >> >> > > > question. > >> >> > > > This will make the resulting image much more portable. > >> >> > > > > >> >> > > > Signed-off-by: Tom Rini > >> >> > > > --- > >> >> > > > scripts/lib/wic/plugins/imager/direct.py | 9 ++--- > >> >> > > > 1 file changed, 6 insertions(+), 3 deletions(-) > >> >> > > > >> >> > > Where we did we end up with this? Ed pointed out that you can tell > >> >> > > wic > >> >> > > to use a specific UUID, so reproducible images are not a problem. > >> >> > > And > >> >> > > making images that are readily portable is why other distros use > >> >> > > UUID/LABEL and not device names as much as possible. I personally > >> >> > > enjoy > >> >> > > being able to put an image on uSD for minnow and have it work :) > >> >> > > Thanks! > >> >> > > >> >> > ping? > >> >> > >> >> I was just reminded about the real problems this solves (swap isn't > >> >> /dev/sda3, boot is being excessively slow), so, ping? > >> >> > >> > > >> > I'm generally ok with the patchset. The only thing I'm thinking of is if > >> > busybox mount > >> > supports PARTUUID syntax in fstab. Can you check this, please? > >> > >> It does. > > > > It doesn't, you need util-linux for a mount that figures these out (or, > > it did when I wrote the patch set). That's why 2/2 only updates the > > systemd canned wks as that _will_ have full mount. But please note that > > you can already make a wks file that doesn't work with busybox mount by > > using the --use-uuid flag for non-root partitions :) > > For the root, why you don't use U-Boot to figure the uuid and pass it > as cmdline, in root=? It is just a question as this is how we fixed > this for meta-freescale. We already, globally, use uuid in WIC for root. And in the case since the kernel does it not mount, busybox isn't a concern. We need to use UUID more widely however for platforms such as minnowboard where we might put the same image on SD card or USB (or SSD) where swap won't always be /dev/sda3 :) -- Tom signature.asc Description: PGP signature -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] Yocto Project Status WW45’17
Current Dev Position: YP 2.5 Planning and M1 development Next Deadline: YP 2.5 M1 cut off of 12/4/17 SWAT team rotation: Ross -> Leo on Nov. 3, 2017. SWAT team rotation: Leo -> Juro on Nov. 10, 2017. https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team Key Status/Updates: ·Master has started taking patches for 2.5. We are struggling with a raft of different build failures that keep occurring on the autobuilders. Currently open issues are: o qemux86-64 appears to have an early boot hang (bug 12301) o ftp urls are having proxy/firewall issues o oe-selftest log duplication causes failures (or maybe failures cause duplicate logging, hard to tell) (bug 12127) o qemuppc has random hangs (had hoped rng fix would help but hasn’t) o nfs inode count for the sstate share appears to break periodically causing the disk monitor to halt the builds (bug 12267) o a perf build race (bug 12302) o also bugs 12303 and 12304 (not gotten to look into these yet) ·Until we resolve these issues, patches are going to be slow to merge. This also blocks several core developers from doing *any* feature work at this point in time (e.g. layer setup tool is on hold, again). ·We plan to drop the remaining ftp urls from OE-Core as most of the remaining ftp servers are likely being decommissioned anyway (e.g. see https://ftp.gnu.org) ·ross/mut is known to cause further oe-selftest and nightly-qa-target failures so patches there are on hold whilst we try and further isolate which patches are causing these. ·We can only continue to stress that unless others step up and help to try and root cause these issues, things will stall with the project. Planned upcoming dot releases: YP 2.2.3 is planned and should be out in the next few weeks. YP 2.3.3 is planned, but date TBD during YP 2.5 planning. YP 2.4.1 is planned, but date TBD during YP 2.5 planning. Key YP 2.5 Dates are: YP 2.5 M1 cut off of 12/4/17 YP 2.5 M1 release of 12/15/17 YP 2.5 M2 cut off of 1/15/18 YP 2.5 M2 release of 1/26/18 YP 2.5 M3 cut off of 2/19/18 YP 2.5 M3 release of 3/2/18 YP 2.5 M4 cut off of 4/2/18 YP 2.5 M4 release of 4/27/18 Tracking Metrics: WDD 2633 (last week 2623) (https://wiki.yoctoproject.org/charts/combo.html) Key Status Links for YP: https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.5_Status https://wiki.yoctoproject.org/wiki/Yocto_2.5_Schedule https://wiki.yoctoproject.org/wiki/Yocto_2.5_Features [If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!] Thanks, Stephen K. Jolley Yocto Project Program Manager INTEL, MS JF1-255, 2111 N.E. 25th Avenue, Hillsboro, OR 97124 • Work Telephone:(503) 712-0534 •Cell: (208) 244-4460 • Email:stephen.k.jol...@intel.com -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] rpm: update to 4.14.0
On 11/03/2017 07:58 PM, Mark Hatle wrote: Unfortunately, this also breaks grub and grub-efi: x86_64-poky-linux-musl-objcopy: /home/ak/development/poky/build-64/tmp/work/core2-64-poky-linux-musl/grub-efi/2.02-r0/package/usr/lib/grub/x86_64-efi/lvm.module(.debug_aranges): relocation 1 has invalid symbol index 2053731167 x86_64-poky-linux-musl-objcopy: /home/ak/development/poky/build-64/tmp/work/core2-64-poky-linux-musl/grub-efi/2.02-r0/package/usr/lib/grub/x86_64-efi/lvm.module: invalid relocation type 69 x86_64-poky-linux-musl-objcopy: BFD (GNU Binutils) 2.29.0.20170912 assertion fail ../../bfd/elf64-x86-64.c:351 x86_64-poky-linux-musl-objcopy: /home/ak/development/poky/build-64/tmp/work/core2-64-poky-linux-musl/grub-efi/2.02-r0/package/usr/lib/grub/x86_64-efi/lvm.module(.debug_info): relocation 0 has invalid symbol index 1634754402 Look at debugedit. This is the program used to adjust some of the debug references. Thanks, this is the offending commit: https://github.com/rpm-software-management/rpm/commit/88989572fff1f31e0c4f972a6895585e4742ef4b Looks like they added sophisticated in-place processing/rewriting of the actual binary (that is not possible to switch off). And it fails in case of grub modules. We, on the other hand, only need to extract the list of debug source code files. Any hint on how to do that without the use of rpm/debugedit? Perhaps something from binutils/elfutils? Alex -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] rpm: update to 4.14.0
On 11/6/17 10:00 AM, Alexander Kanavin wrote: > On 11/03/2017 07:58 PM, Mark Hatle wrote: >>> Unfortunately, this also breaks grub and grub-efi: >>> >>> x86_64-poky-linux-musl-objcopy: >>> /home/ak/development/poky/build-64/tmp/work/core2-64-poky-linux-musl/grub-efi/2.02-r0/package/usr/lib/grub/x86_64-efi/lvm.module(.debug_aranges): >>> relocation 1 has invalid symbol index 2053731167 >>> x86_64-poky-linux-musl-objcopy: >>> /home/ak/development/poky/build-64/tmp/work/core2-64-poky-linux-musl/grub-efi/2.02-r0/package/usr/lib/grub/x86_64-efi/lvm.module: >>> invalid relocation type 69 >>> x86_64-poky-linux-musl-objcopy: BFD (GNU Binutils) 2.29.0.20170912 >>> assertion fail ../../bfd/elf64-x86-64.c:351 >>> x86_64-poky-linux-musl-objcopy: >>> /home/ak/development/poky/build-64/tmp/work/core2-64-poky-linux-musl/grub-efi/2.02-r0/package/usr/lib/grub/x86_64-efi/lvm.module(.debug_info): >>> relocation 0 has invalid symbol index 1634754402 >>> >> >> Look at debugedit. This is the program used to adjust some of the debug >> references. > > Thanks, this is the offending commit: > > https://github.com/rpm-software-management/rpm/commit/88989572fff1f31e0c4f972a6895585e4742ef4b > > Looks like they added sophisticated in-place processing/rewriting of the > actual binary (that is not possible to switch off). And it fails in case > of grub modules. > > We, on the other hand, only need to extract the list of debug source > code files. Any hint on how to do that without the use of rpm/debugedit? > Perhaps something from binutils/elfutils? You would need to interpret the dwarf symbols and find all of the referenced files. I can certainly be done with the libelf (libdwarf?), but I don't know if it can be done with binutils or elfutils directly. They may not have the necessary translation to be able to assembly the pieces. (A lot of the filenames are listed related to a directory.. and the entries are stored in different places and have to be assembled to get a similar output to what debugedit gave us.) Writing a small standalone tool to give us this information may be very useful to us though -- and would let us break the 'rpm' dependency for deb/ipkg builds.. (probably) --Mark > Alex > -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] oeqa/selftest/runtime_test: fix postinst_rootfs_and_boot
This test overrides IMAGE_FEATURES but failed to include package-management,
which is essential for postinsts to work under dpkg.
Also rewrite the file existence check to use a console login not SSH for
simplicity.
Signed-off-by: Ross Burton
---
meta/lib/oeqa/selftest/cases/runtime_test.py | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/meta/lib/oeqa/selftest/cases/runtime_test.py
b/meta/lib/oeqa/selftest/cases/runtime_test.py
index 7ce81c3ff0f..25270b7535b 100644
--- a/meta/lib/oeqa/selftest/cases/runtime_test.py
+++ b/meta/lib/oeqa/selftest/cases/runtime_test.py
@@ -244,7 +244,7 @@ postinst-delayed-t \
with self.subTest(init_manager=init_manager,
package_class=classes):
features = 'MACHINE = "qemux86"\n'
features += 'CORE_IMAGE_EXTRA_INSTALL += "%s %s "\n'%
(rootfs_pkg, boot_pkg)
-features += 'IMAGE_FEATURES += "empty-root-password
ssh-server-openssh"\n'
+features += 'IMAGE_FEATURES += "package-management
empty-root-password"\n'
features += 'PACKAGE_CLASSES = "%s"\n' % classes
if init_manager == "systemd":
features += 'DISTRO_FEATURES_append = " systemd"\n'
@@ -263,6 +263,5 @@ postinst-delayed-t \
testcommand = 'ls /etc/' + fileboot_name
with runqemu('core-image-minimal') as qemu:
-ssh = SSHControl(ip=qemu.ip, logfile=qemu.sshlog)
-status, output = ssh.run(testcommand)
+status, output = qemu.run_serial("-f /etc/" +
fileboot_name)
self.assertEqual(status, 0, 'File %s was not created
at first boot (%s)' % (fileboot_name, output))
--
2.11.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v6 1/3] mesa: Upgrade to 17.2.2 release
Upgrade to a new stable release and drop patches applied on upstream.
For a full release notes, please see:
https://mesa3d.org/relnotes/17.2.0.html
https://mesa3d.org/relnotes/17.2.1.html
https://mesa3d.org/relnotes/17.2.2.html
https://mesa3d.org/relnotes/17.2.3.html
https://mesa3d.org/relnotes/17.2.4.html
Signed-off-by: Fabio Berton
Signed-off-by: Otavio Salvador
---
Changes in v6:
- update to 17.2.4
Changes in v5:
- rebase on top of master
Changes in v4:
- update to 17.2.2
Changes in v3:
- fix build for wayland
Changes in v2:
- update to 17.2.1
...1-ac-fix-build-after-LLVM-5.0-SVN-r300718.patch | 40 --
...allivm-Fix-build-against-LLVM-SVN-r302589.patch | 49 --
.../mesa/{mesa-gl_17.1.7.bb => mesa-gl_17.2.4.bb} | 0
meta/recipes-graphics/mesa/mesa.inc| 2 +-
.../mesa/{mesa_17.1.7.bb => mesa_17.2.4.bb}| 7 ++--
5 files changed, 4 insertions(+), 94 deletions(-)
delete mode 100644
meta/recipes-graphics/mesa/files/0001-ac-fix-build-after-LLVM-5.0-SVN-r300718.patch
delete mode 100644
meta/recipes-graphics/mesa/files/0002-gallivm-Fix-build-against-LLVM-SVN-r302589.patch
rename meta/recipes-graphics/mesa/{mesa-gl_17.1.7.bb => mesa-gl_17.2.4.bb}
(100%)
rename meta/recipes-graphics/mesa/{mesa_17.1.7.bb => mesa_17.2.4.bb} (78%)
diff --git
a/meta/recipes-graphics/mesa/files/0001-ac-fix-build-after-LLVM-5.0-SVN-r300718.patch
b/meta/recipes-graphics/mesa/files/0001-ac-fix-build-after-LLVM-5.0-SVN-r300718.patch
deleted file mode 100644
index b27a3bc8e4..00
---
a/meta/recipes-graphics/mesa/files/0001-ac-fix-build-after-LLVM-5.0-SVN-r300718.patch
+++ /dev/null
@@ -1,40 +0,0 @@
-From 9861437e58fdd0de01193a102608d34e5952953f Mon Sep 17 00:00:00 2001
-From: Christoph Haag
-Date: Thu, 20 Apr 2017 10:34:18 +0200
-Subject: [PATCH 1/2] ac: fix build after LLVM 5.0 SVN r300718
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-v2: previously getWithDereferenceableBytes() exists, but addAttr() doesn't
take that type
-
-Signed-off-by: Christoph Haag
-Reviewed-by: Nicolai Hähnle
-Tested-and-reviewed-by: Mike Lothian
-Upstream-Status: Backport
-
- src/amd/common/ac_llvm_helper.cpp | 4
- 1 file changed, 4 insertions(+)
-
-diff --git a/src/amd/common/ac_llvm_helper.cpp
b/src/amd/common/ac_llvm_helper.cpp
-index d9ea4b1..11fa809 100644
a/src/amd/common/ac_llvm_helper.cpp
-+++ b/src/amd/common/ac_llvm_helper.cpp
-@@ -44,9 +44,13 @@ typedef AttributeSet AttributeList;
- void ac_add_attr_dereferenceable(LLVMValueRef val, uint64_t bytes)
- {
-llvm::Argument *A = llvm::unwrap(val);
-+#if HAVE_LLVM < 0x0500
-llvm::AttrBuilder B;
-B.addDereferenceableAttr(bytes);
-A->addAttr(llvm::AttributeList::get(A->getContext(), A->getArgNo() + 1,
B));
-+#else
-+ A->addAttr(llvm::Attribute::getWithDereferenceableBytes(A->getContext(),
bytes));
-+#endif
- }
-
- bool ac_is_sgpr_param(LLVMValueRef arg)
---
-2.13.3
-
diff --git
a/meta/recipes-graphics/mesa/files/0002-gallivm-Fix-build-against-LLVM-SVN-r302589.patch
b/meta/recipes-graphics/mesa/files/0002-gallivm-Fix-build-against-LLVM-SVN-r302589.patch
deleted file mode 100644
index ac8caec74d..00
---
a/meta/recipes-graphics/mesa/files/0002-gallivm-Fix-build-against-LLVM-SVN-r302589.patch
+++ /dev/null
@@ -1,49 +0,0 @@
-From a02a0dfda2712d30ad62b8f0421ec7b8244ba2cb Mon Sep 17 00:00:00 2001
-From: =?UTF-8?q?Michel=20D=C3=A4nzer?=
-Date: Wed, 10 May 2017 17:26:07 +0900
-Subject: [PATCH 2/2] gallivm: Fix build against LLVM SVN >= r302589
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-deregisterEHFrames doesn't take any parameters anymore.
-
-Reviewed-by: Vedran Miletić
-Reviewed-by: Marek Olšák
-Upstream-Status: Backport
-
- src/gallium/auxiliary/gallivm/lp_bld_misc.cpp | 12 +---
- 1 file changed, 9 insertions(+), 3 deletions(-)
-
-diff --git a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
-index 2a388cb..0e4a531 100644
a/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
-+++ b/src/gallium/auxiliary/gallivm/lp_bld_misc.cpp
-@@ -342,14 +342,20 @@ class DelegatingJITMemoryManager : public
BaseMemoryManager {
- virtual void registerEHFrames(uint8_t *Addr, uint64_t LoadAddr, size_t
Size) {
- mgr()->registerEHFrames(Addr, LoadAddr, Size);
- }
-- virtual void deregisterEHFrames(uint8_t *Addr, uint64_t LoadAddr,
size_t Size) {
-- mgr()->deregisterEHFrames(Addr, LoadAddr, Size);
-- }
- #else
- virtual void registerEHFrames(llvm::StringRef SectionData) {
- mgr()->registerEHFrames(SectionData);
- }
- #endif
-+#if HAVE_LLVM >= 0x0500
-+ virtual void deregisterEHFrames() {
-+ mgr()->deregisterEHFrames();
-+ }
-+#elif HAVE_LLVM >= 0x0304
-+ virtual void deregisterEHFrames(uint8_t *Addr, uint64_t LoadAddr,
size_t Size) {
-+
[OE-core] [PATCH 4/4] sshcontrol.py: in copy_to() always use scp
From: Erik Botö
The current implementation is broken when the localpath is a link.
Then only a symlink would be created on the target, instead of copying
the actual file.
[YOCTO #11524]
Signed-off-by: Erik Botö
Signed-off-by: Stephano Cetola
---
meta/lib/oeqa/utils/sshcontrol.py | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/meta/lib/oeqa/utils/sshcontrol.py
b/meta/lib/oeqa/utils/sshcontrol.py
index 05d6502550..d292893c08 100644
--- a/meta/lib/oeqa/utils/sshcontrol.py
+++ b/meta/lib/oeqa/utils/sshcontrol.py
@@ -150,12 +150,9 @@ class SSHControl(object):
def copy_to(self, localpath, remotepath):
if os.path.islink(localpath):
-link = os.readlink(localpath)
-dst_dir, dst_base = os.path.split(remotepath)
-return self.run("cd %s; ln -s %s %s" % (dst_dir, link, dst_base))
-else:
-command = self.scp + [localpath, '%s@%s:%s' % (self.user, self.ip,
remotepath)]
-return self._internal_run(command, ignore_status=False)
+localpath = os.path.dirname(localpath) + "/" +
os.readlink(localpath)
+command = self.scp + [localpath, '%s@%s:%s' % (self.user, self.ip,
remotepath)]
+return self._internal_run(command, ignore_status=False)
def copy_from(self, remotepath, localpath):
command = self.scp + ['%s@%s:%s' % (self.user, self.ip, remotepath),
localpath]
--
2.14.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 1/4] masterimage.py: fix issue with calling reboot on masterimage/DUT
From: Erik Botö
On systemd systems calling reboot over an ssh connection doesn't
return as expected causing an exception, therefore wrap the call
to reboot in order to avoid this issue.
Also sync the filesystems before rebooting cause otherwise, it will be
done as part of the reboot and could take a very long time and testimage
will fail to access the machine. This issue was observed consistently with
one of our rootfs at Pelagicore.
[YOCTO #11524]
Signed-off-by: Erik Botö
Signed-off-by: Stephano Cetola
---
meta/lib/oeqa/controllers/masterimage.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/lib/oeqa/controllers/masterimage.py
b/meta/lib/oeqa/controllers/masterimage.py
index 07418fcda1..fe90967923 100644
--- a/meta/lib/oeqa/controllers/masterimage.py
+++ b/meta/lib/oeqa/controllers/masterimage.py
@@ -108,7 +108,7 @@ class
MasterImageHardwareTarget(oeqa.targetcontrol.BaseTarget, metaclass=ABCMeta
time.sleep(10)
self.power_ctl("cycle")
else:
-status, output = conn.run("reboot")
+status, output = conn.run("sync; { sleep 1; reboot; } > /dev/null
&")
if status != 0:
bb.error("Failed rebooting target and no power control command
defined. You need to manually reset the device.\n%s" % output)
--
2.14.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 0/4] fix runtime tests with systemd-boot
These patches fell through the cracks of 2.4. I've checked with the QA team and they are still relevant. Ping me with any questions. I will be backporting these to rocko as well. This fixes [YOCTO #11524] Erik Botö (4): masterimage.py: fix issue with calling reboot on masterimage/DUT masterimage.py: fix stop() masterimage.py: rename parameter "params" in start() to "extra_bootparams" sshcontrol.py: in copy_to() always use scp meta/lib/oeqa/controllers/masterimage.py | 6 +++--- meta/lib/oeqa/utils/sshcontrol.py| 9 +++-- 2 files changed, 6 insertions(+), 9 deletions(-) -- 2.14.2 -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 3/4] masterimage.py: rename parameter "params" in start() to "extra_bootparams"
From: Erik Botö
This matches how it is called, and how it is named in qmeu target.
[YOCTO #11524]
Signed-off-by: Erik Botö
Signed-off-by: Stephano Cetola
---
meta/lib/oeqa/controllers/masterimage.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/lib/oeqa/controllers/masterimage.py
b/meta/lib/oeqa/controllers/masterimage.py
index e2ff3f12c2..a2912fc568 100644
--- a/meta/lib/oeqa/controllers/masterimage.py
+++ b/meta/lib/oeqa/controllers/masterimage.py
@@ -143,7 +143,7 @@ class
MasterImageHardwareTarget(oeqa.targetcontrol.BaseTarget, metaclass=ABCMeta
def _deploy(self):
pass
-def start(self, params=None):
+def start(self, extra_bootparams=None):
bb.plain("%s - boot test image on target" % self.pn)
self._start()
# set the ssh object for the target/test image
--
2.14.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH 2/4] masterimage.py: fix stop()
From: Erik Botö
The stop() function is called in the context of the masterimage,
so self.master should be used instead of self.connection which is
undefined at that time.
[YOCTO #11524]
Signed-off-by: Erik Botö
Signed-off-by: Stephano Cetola
---
meta/lib/oeqa/controllers/masterimage.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/lib/oeqa/controllers/masterimage.py
b/meta/lib/oeqa/controllers/masterimage.py
index fe90967923..e2ff3f12c2 100644
--- a/meta/lib/oeqa/controllers/masterimage.py
+++ b/meta/lib/oeqa/controllers/masterimage.py
@@ -156,7 +156,7 @@ class
MasterImageHardwareTarget(oeqa.targetcontrol.BaseTarget, metaclass=ABCMeta
def stop(self):
bb.plain("%s - reboot/powercycle target" % self.pn)
-self.power_cycle(self.connection)
+self.power_cycle(self.master)
class SystemdbootTarget(MasterImageHardwareTarget):
--
2.14.2
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v6 0/3] Queued changes since rocko
Those are the patches we have queued here for master. We took the
patch version 6 so we keep the change history on the patches, about
its previous versions.
Changes in v6:
- update to 17.2.4
Changes in v5:
- rebase on top of master
- new patch
Changes in v4:
- update to 17.2.2
Changes in v3:
- fix build for wayland
Changes in v2:
- update to 17.2.1
- add a note about checksum change of WHENCE file.
Otavio Salvador (3):
mesa: Upgrade to 17.2.2 release
libdrm: upgrade to 2.4.84
linux-firmware: Bump to bf04291 revision
.../drm/{libdrm_2.4.83.bb => libdrm_2.4.84.bb} | 4 +-
...1-ac-fix-build-after-LLVM-5.0-SVN-r300718.patch | 40 --
...allivm-Fix-build-against-LLVM-SVN-r302589.patch | 49 --
.../mesa/{mesa-gl_17.1.7.bb => mesa-gl_17.2.4.bb} | 0
meta/recipes-graphics/mesa/mesa.inc| 2 +-
.../mesa/{mesa_17.1.7.bb => mesa_17.2.4.bb}| 7 ++--
.../linux-firmware/linux-firmware_git.bb | 4 +-
7 files changed, 8 insertions(+), 98 deletions(-)
rename meta/recipes-graphics/drm/{libdrm_2.4.83.bb => libdrm_2.4.84.bb} (93%)
delete mode 100644
meta/recipes-graphics/mesa/files/0001-ac-fix-build-after-LLVM-5.0-SVN-r300718.patch
delete mode 100644
meta/recipes-graphics/mesa/files/0002-gallivm-Fix-build-against-LLVM-SVN-r302589.patch
rename meta/recipes-graphics/mesa/{mesa-gl_17.1.7.bb => mesa-gl_17.2.4.bb}
(100%)
rename meta/recipes-graphics/mesa/{mesa_17.1.7.bb => mesa_17.2.4.bb} (78%)
--
2.15.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v6 2/3] libdrm: upgrade to 2.4.84
Signed-off-by: Otavio Salvador
---
Changes in v6: None
Changes in v5:
- new patch
Changes in v4: None
Changes in v3: None
Changes in v2: None
meta/recipes-graphics/drm/{libdrm_2.4.83.bb => libdrm_2.4.84.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-graphics/drm/{libdrm_2.4.83.bb => libdrm_2.4.84.bb} (93%)
diff --git a/meta/recipes-graphics/drm/libdrm_2.4.83.bb
b/meta/recipes-graphics/drm/libdrm_2.4.84.bb
similarity index 93%
rename from meta/recipes-graphics/drm/libdrm_2.4.83.bb
rename to meta/recipes-graphics/drm/libdrm_2.4.84.bb
index a5cb75c266..95f72adae5 100644
--- a/meta/recipes-graphics/drm/libdrm_2.4.83.bb
+++ b/meta/recipes-graphics/drm/libdrm_2.4.84.bb
@@ -16,8 +16,8 @@ SRC_URI = "http://dri.freedesktop.org/libdrm/${BP}.tar.bz2 \
file://0001-configure.ac-Allow-explicit-enabling-of-cunit-tests.patch \
"
-SRC_URI[md5sum] = "23800953ed7564988872e1e8c61fde31"
-SRC_URI[sha256sum] =
"03a52669da60ead62548a35bc430aafb6c2d8dd21ec9dba3a90f96eff5fe36d6"
+SRC_URI[md5sum] = "35b9544bc2ad864acd1abaa1a2b99092"
+SRC_URI[sha256sum] =
"7ae9c24d91139ac9a2cdee06fe46dbe1c401a1eda1c0bd2a6d1ecf72f479e0aa"
inherit autotools pkgconfig manpages
--
2.15.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH v6 3/3] linux-firmware: Bump to bf04291 revision
This includes following changes:
bf04291 WHENCE: Add new qed firmware
d8fc990 WHENCE: Add new radeon firmware
7245319 WHENCE: Fix syntax error for iwlwifi-8265-31.ucode entry
18d71a8 Revert "ath10k: QCA988X hw2.0: update firmware to 10.2.4.70.63-2"
4ebfab3 ath10k: QCA6174 hw3.0: update board-2.bin
96a7402 ath10k: QCA6174 hw3.0: update firmware-6.bin to
WLAN.RM.4.4.1-00051-QCARMSWP-1
59bf7e2 cxgb4: update firmware to revision 1.16.63.0
The MD5 checksum of WHENCE license file was due the changes above as
the firmware versions are listed there. It had no license term
changes.
Signed-off-by: Otavio Salvador
---
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None
Changes in v2:
- add a note about checksum change of WHENCE file.
meta/recipes-kernel/linux-firmware/linux-firmware_git.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
index 020c8579f8..ddad491c15 100644
--- a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
+++ b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
@@ -116,7 +116,7 @@ LIC_FILES_CHKSUM = "\
file://LICENCE.xc4000;md5=0ff51d2dc49fce04814c9155081092f0 \
file://LICENCE.xc5000;md5=1e170c13175323c32c7f4d0998d53f66 \
file://LICENCE.xc5000c;md5=12b02efa3049db65d524aeb418dd87ca \
-file://WHENCE;md5=08f6d4371353cac5f6fc271d5407c63e \
+file://WHENCE;md5=038edbc9e744171d8b6235e0224028ba \
"
# These are not common licenses, set NO_GENERIC_LICENSE for them
@@ -178,7 +178,7 @@ NO_GENERIC_LICENSE[Firmware-xc5000] = "LICENCE.xc5000"
NO_GENERIC_LICENSE[Firmware-xc5000c] = "LICENCE.xc5000c"
NO_GENERIC_LICENSE[WHENCE] = "WHENCE"
-SRCREV = "a61ac5cf8374edbfe692d12f805a1b194f7fead2"
+SRCREV = "bf04291309d3169c0ad3b8db52564235bbd08e30"
PE = "1"
PV = "0.0+git${SRCPV}"
--
2.15.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Releases of BitBake to package for Fedora?
On Mon, Nov 6, 2017 at 3:33 AM, Burton, Ross wrote: > The bitbake API isn't really stable and has a reasonable amount of change, > so if you were to package it then there's a good chance it would be out of > date within six months and people who wanted to use the latest oe-core > release against the packaged bitbake would hit API version errors. The > recommended usage is to bundle in some way bitbake and the metadata > (combo-layer, submodules, repo, whatever). > > As such there are no tarballs. There are branches for each version and > commits where the version is bumped, if you're really determined to package > a snapshot. If there's no realistic hope of (or need for) using bitbake standalone then maybe it's time to move bitbake into oe-core? -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Releases of BitBake to package for Fedora?
On Tuesday, 7 November 2017 8:16:06 AM NZDT Andre McCurdy wrote: > On Mon, Nov 6, 2017 at 3:33 AM, Burton, Ross wrote: > > The bitbake API isn't really stable and has a reasonable amount of change, > > so if you were to package it then there's a good chance it would be out of > > date within six months and people who wanted to use the latest oe-core > > release against the packaged bitbake would hit API version errors. The > > recommended usage is to bundle in some way bitbake and the metadata > > (combo-layer, submodules, repo, whatever). > > > > As such there are no tarballs. There are branches for each version and > > commits where the version is bumped, if you're really determined to > > package a snapshot. > > If there's no realistic hope of (or need for) using bitbake standalone > then maybe it's time to move bitbake into oe-core? Well, there are folks out there using bitbake with their own (non-OE) metadata, and that is absolutely supported, so even in the absence of stable releases of BitBake that distros could pick up the separation does still have a purpose. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] automatic recipe upgrades - making them better and sweeter
Hi Alex, On Tuesday, 7 November 2017 12:50:05 AM NZDT Alexander Kanavin wrote: > I've been asked by RP to look into making automatic package upgrades > work better, so here's what I'd like to improve: > > 1) when using 'devtool upgrade', remove the need to specify version and > source revision on the command line, if we want to upgrade to the latest > release. There is now distrodata/checkpkg code in place to determine > both, so 'devtool upgrade ' could simply default to that. You could certainly have it dynamically inherit distrodata for the recipe (via the workspace bbappend) and then use that to get the required information. I'd avoided that extra complexity earlier but it may be that now it's actually easier than it was before. The only thing I would say is we need to produce clear error messages if we don't have the needed information to automatically figure out what the upgrade version should be. > 2) help with LICENSE checksum changes a bit more; both devtool and AUH > have some code for this, so I want to review what they do, and > consolidate it in a single place. Maintainers should be able to see a > diff of what the changes are. Agreed. For everyone else's benefit, Alex filed a bug for this a while ago: https://bugzilla.yoctoproject.org/show_bug.cgi?id=10801 I am keeping an eye on this one. > 3) 'devtool finish' currently does not handle the recipe upgrade > situation well: the new recipe and patches are placed side by side with > the current recipe. The old stuff should be removed, and a tentative > commit should be created. So maybe add a 'devtool finish-upgrade'. That's not what's supposed to happen - it should already be deleting the original files (it takes a record of the copied files when you run devtool upgrade, and then when you run devtool finish it deletes those and moves the new ones across from the workspace). If that's not working it's a bug and I would appreciate a reproducer. I'd certainly prefer that we keep to one finish command that does its best to "do the right thing" depending on the situation. > 4) AUH should be stripped to its core business: sending useful emails to > maintainers, and leave the rest to devtool. If 'devtool upgrade' > succeeded, then corresponding patches should be attached, otherwise (if > patch rebase failed, or a fetch issue), at least it could tell what > happened and suggest a devtool upgrade command to get started. Any > duplicate functionality for upgrading (stuff that is also in devtool) > should be removed. Agreed. There's a bug open for this one too: https://bugzilla.yoctoproject.org/show_bug.cgi?id=10598 BTW, you have impeccable timing as I am currently in the middle of preparing a fairly substantial changeset for devtool including implementing a dry-run mode for devtool finish (so you can see what it's going to do) and fixing the following bugs, among others: https://bugzilla.yoctoproject.org/show_bug.cgi?id=10939 https://bugzilla.yoctoproject.org/show_bug.cgi?id=11948 https://bugzilla.yoctoproject.org/show_bug.cgi?id=11516 Current WIP is on paule/devtool31 in poky-contrib. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [meta][PATCH] openssh-sshd: regenerate zero-size keys on start
sometimes the first time a machine boots power gets pull out and the content of
the
key files doesn't get sync leading to zero-size keys which permanently prevents
ssh access. it's safer to assume that zero-sized files are equivalent to
non-existant
keys and generate them again.
Signed-off-by: Alejandro Mery
---
meta/recipes-connectivity/openssh/openssh/sshd_check_keys | 8
meta/recipes-connectivity/openssh/openssh_7.5p1.bb| 2 ++
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/meta/recipes-connectivity/openssh/openssh/sshd_check_keys
b/meta/recipes-connectivity/openssh/openssh/sshd_check_keys
index 5463b1a4cb..8cc31c339a 100644
--- a/meta/recipes-connectivity/openssh/openssh/sshd_check_keys
+++ b/meta/recipes-connectivity/openssh/openssh/sshd_check_keys
@@ -71,19 +71,19 @@ HOST_KEY_ED25519=$(grep ^HostKey "${sshd_config}" | grep
_ed25519_ | tail -1 | a
[ -z "${HOST_KEY_ED25519}" ] &&
HOST_KEY_ED25519=$SYSCONFDIR/ssh_host_ed25519_key
# create keys if necessary
-if [ ! -f $HOST_KEY_RSA ]; then
+if [ ! -s $HOST_KEY_RSA ]; then
echo " generating ssh RSA key..."
generate_key $HOST_KEY_RSA rsa
fi
-if [ ! -f $HOST_KEY_ECDSA ]; then
+if [ ! -s $HOST_KEY_ECDSA ]; then
echo " generating ssh ECDSA key..."
generate_key $HOST_KEY_ECDSA ecdsa
fi
-if [ ! -f $HOST_KEY_DSA ]; then
+if [ ! -s $HOST_KEY_DSA ]; then
echo " generating ssh DSA key..."
generate_key $HOST_KEY_DSA dsa
fi
-if [ ! -f $HOST_KEY_ED25519 ]; then
+if [ ! -s $HOST_KEY_ED25519 ]; then
echo " generating ssh ED25519 key..."
generate_key $HOST_KEY_ED25519 ed25519
fi
diff --git a/meta/recipes-connectivity/openssh/openssh_7.5p1.bb
b/meta/recipes-connectivity/openssh/openssh_7.5p1.bb
index 86ca6ff372..2f178b26d8 100644
--- a/meta/recipes-connectivity/openssh/openssh_7.5p1.bb
+++ b/meta/recipes-connectivity/openssh/openssh_7.5p1.bb
@@ -8,6 +8,8 @@ SECTION = "console/network"
LICENSE = "BSD"
LIC_FILES_CHKSUM = "file://LICENCE;md5=e326045657e842541d3f35aada442507"
+PR = "r1"
+
# openssl 1.1 patches are proposed at
https://github.com/openssh/openssh-portable/pull/48
DEPENDS = "zlib openssl10"
DEPENDS += "${@bb.utils.contains('DISTRO_FEATURES', 'pam', 'libpam', '', d)}"
--
2.15.0
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] Releases of BitBake to package for Fedora?
On Mon, Nov 6, 2017 at 11:18 AM, Paul Eggleton wrote: > On Tuesday, 7 November 2017 8:16:06 AM NZDT Andre McCurdy wrote: >> On Mon, Nov 6, 2017 at 3:33 AM, Burton, Ross wrote: >> > The bitbake API isn't really stable and has a reasonable amount of change, >> > so if you were to package it then there's a good chance it would be out of >> > date within six months and people who wanted to use the latest oe-core >> > release against the packaged bitbake would hit API version errors. The >> > recommended usage is to bundle in some way bitbake and the metadata >> > (combo-layer, submodules, repo, whatever). >> > >> > As such there are no tarballs. There are branches for each version and >> > commits where the version is bumped, if you're really determined to >> > package a snapshot. >> >> If there's no realistic hope of (or need for) using bitbake standalone >> then maybe it's time to move bitbake into oe-core? > > Well, there are folks out there using bitbake with their own (non-OE) > metadata, Are any of those projects public? I'd be interested to see how that's being done. > and that is absolutely supported, so even in the absence of stable > releases of BitBake that distros could pick up the separation does still have > a purpose. > > Cheers, > Paul > > -- > > Paul Eggleton > Intel Open Source Technology Centre -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
Re: [OE-core] [PATCH] lib/oe/terminal.py: use an absolute path to execute oe-gnome-terminal-phonehome
On Fri, Oct 13, 2017 at 4:26 AM, wrote:
> From: Ming Liu
>
> A flaw was found on my Ubuntu 14.04.5 LTS, on which that gnome-terminal is
> the default terminal, when I run any of the tasks:
> bitbake busybox -c menuconfig/devshell/devpyshell
> bitbake virtual/kernel -c menuconfig/devshell/devpyshell
>
> I got a error as follows:
> "Failed to execute child process "oe-gnome-terminal-phonehome" (No such file
> or directory)"
>
> Seems the environment of the process calling Popen is not passed to the
> child process, this behaviour is a known issue in Python bug tracker:
> http://bugs.python.org/issue8557
>
> It could be fixed by using an absolute path instead per test.
Ping.
A similar fix is also needed in pyro and morty (where Ubuntu 14.04 is
still an officially supported host).
Using an absolute path here seems like a reasonable thing to be doing
anyway, so unless there's an obvious problem with this change, I
suggest merging to master first and then backporting rather than
making the fix morty specific.
> Signed-off-by: Ming Liu
> ---
> meta/lib/oe/terminal.py | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/lib/oe/terminal.py b/meta/lib/oe/terminal.py
> index 9eb19a2..94afe39 100644
> --- a/meta/lib/oe/terminal.py
> +++ b/meta/lib/oe/terminal.py
> @@ -224,7 +224,7 @@ def spawn(name, sh_cmd, title=None, env=None, d=None):
> import time
> pidfile = tempfile.NamedTemporaryFile(delete = False).name
> try:
> -sh_cmd = "oe-gnome-terminal-phonehome " + pidfile + " " + sh_cmd
> +sh_cmd = bb.utils.which(os.getenv('PATH'),
> "oe-gnome-terminal-phonehome") + " " + pidfile + " " + sh_cmd
> pipe = terminal(sh_cmd, title, env, d)
> output = pipe.communicate()[0]
> if output:
> --
> 2.7.4
>
> --
> ___
> 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] Releases of BitBake to package for Fedora?
On Tuesday, 7 November 2017 12:27:07 PM NZDT Andre McCurdy wrote: > On Mon, Nov 6, 2017 at 11:18 AM, Paul Eggleton > wrote: > > On Tuesday, 7 November 2017 8:16:06 AM NZDT Andre McCurdy wrote: > >> On Mon, Nov 6, 2017 at 3:33 AM, Burton, Ross wrote: > >> > The bitbake API isn't really stable and has a reasonable amount of change, > >> > so if you were to package it then there's a good chance it would be out of > >> > date within six months and people who wanted to use the latest oe-core > >> > release against the packaged bitbake would hit API version errors. The > >> > recommended usage is to bundle in some way bitbake and the metadata > >> > (combo-layer, submodules, repo, whatever). > >> > > >> > As such there are no tarballs. There are branches for each version and > >> > commits where the version is bumped, if you're really determined to > >> > package a snapshot. > >> > >> If there's no realistic hope of (or need for) using bitbake standalone > >> then maybe it's time to move bitbake into oe-core? > > > > Well, there are folks out there using bitbake with their own (non-OE) > > metadata, > > Are any of those projects public? I'd be interested to see how that's > being done. The main one I am aware of being active in recent times is Isar: https://github.com/ilbers/isar https://www.youtube.com/watch?v=GHHOxrtYBMc There have been others mentioned on the bitbake mailing list over time but I don't recall any others that were public. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre -- ___ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
[OE-core] [PATCH] glib-2.0: Update to glib 2.53.7
Update to Glib version 2.53.7.
Signed-off-by: Alistair Francis
---
...evert-meson-Substitute-the-Python-shebang.patch | 54 ++
.../glib-2.0/glib-2.0/configure-libtool.patch | 34 +++---
.../{glib-2.0_2.52.3.bb => glib-2.0_2.53.7.bb} | 6 +--
meta/recipes-core/glib-2.0/glib.inc| 8 ++--
4 files changed, 67 insertions(+), 35 deletions(-)
create mode 100644
meta/recipes-core/glib-2.0/glib-2.0/0001-Partially-Revert-meson-Substitute-the-Python-shebang.patch
rename meta/recipes-core/glib-2.0/{glib-2.0_2.52.3.bb => glib-2.0_2.53.7.bb}
(76%)
diff --git
a/meta/recipes-core/glib-2.0/glib-2.0/0001-Partially-Revert-meson-Substitute-the-Python-shebang.patch
b/meta/recipes-core/glib-2.0/glib-2.0/0001-Partially-Revert-meson-Substitute-the-Python-shebang.patch
new file mode 100644
index 00..979247cbba
--- /dev/null
+++
b/meta/recipes-core/glib-2.0/glib-2.0/0001-Partially-Revert-meson-Substitute-the-Python-shebang.patch
@@ -0,0 +1,54 @@
+From be007b2e6fbe93904e36ccddc707f96b30ad8300 Mon Sep 17 00:00:00 2001
+From: Alistair Francis
+Date: Mon, 6 Nov 2017 15:23:16 -0800
+Subject: [PATCH] Partially Revert: meson: Substitute the Python shebang
+
+Partially revert this patch:
+commit 0f18a2ebda4ec0440ec545542f9fc2f60cd54c5d
+Author: Emmanuele Bassi
+Date: Fri Jul 14 20:43:19 2017 +0100
+
+meson: Substitute the Python shebang
+
+Just like we do with Autotools. This allows building glib-mkenums and
+glib-genmarshal on older platforms that only have Python 2.
+
+The above patch stops using the hardcoded python3 enviroment to run
+Python scripts and instead uses the PYTHON variable used from configure.
+
+This patch casues QA issues when building Glib and results in the env
+string being too long (resulting in clipping) which results in build
+failures.
+
+As we always have Python 3 we don't need a workaround for Python 2.
+
+Signed-off-by: Alistair Francis
+Upstream-Status: Inappropriate [OE specific]
+---
+ gobject/glib-genmarshal.in | 2 +-
+ gobject/glib-mkenums.in| 2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/gobject/glib-genmarshal.in b/gobject/glib-genmarshal.in
+index ed6de0ae8..ec30410bd 100755
+--- a/gobject/glib-genmarshal.in
b/gobject/glib-genmarshal.in
+@@ -1,4 +1,4 @@
+-#!/usr/bin/env @PYTHON@
++#!/usr/bin/env python3
+
+ # pylint: disable=too-many-lines, missing-docstring, invalid-name
+
+diff --git a/gobject/glib-mkenums.in b/gobject/glib-mkenums.in
+index d4bfd11c3..051fce4ca 100755
+--- a/gobject/glib-mkenums.in
b/gobject/glib-mkenums.in
+@@ -1,4 +1,4 @@
+-#!/usr/bin/env @PYTHON@
++#!/usr/bin/env python3
+
+ # If the code below looks horrible and unpythonic, do not panic.
+ #
+--
+2.11.0
+
diff --git a/meta/recipes-core/glib-2.0/glib-2.0/configure-libtool.patch
b/meta/recipes-core/glib-2.0/glib-2.0/configure-libtool.patch
index aa5de27d12..d759ea1d7f 100644
--- a/meta/recipes-core/glib-2.0/glib-2.0/configure-libtool.patch
+++ b/meta/recipes-core/glib-2.0/glib-2.0/configure-libtool.patch
@@ -14,28 +14,20 @@ from PATH though
Rebased to glib-2.27.3 by Dongxiao Xu
Rebased to glib-2.32.1 by Martin Jansa
Rebased to glib-2.31.20+ by Andre McCurdy
+Rebased to glib-2.53.4+ by Alistair Francis
Upstream-Status: Inappropriate [configuration]
Signed-off-by: Martin Jansa
---
- configure.ac | 10 +-
- 1 file changed, 5 insertions(+), 5 deletions(-)
+ configure.ac | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
-index 1af90c5..f6b7a73 100644
+index f322edfea..7cf86c2fa 100644
--- a/configure.ac
+++ b/configure.ac
-@@ -1378,7 +1378,7 @@ if test x"$glib_native_win32" = xyes; then
- G_MODULE_LDFLAGS=
- else
- export SED
-- G_MODULE_LDFLAGS=`(./libtool --config; echo eval echo
\\$export_dynamic_flag_spec) | sh`
-+ G_MODULE_LDFLAGS=`(./$host_alias-libtool --config; echo eval echo
\\$export_dynamic_flag_spec) | sh`
- fi
- dnl G_MODULE_IMPL= don't reset, so cmd-line can override
- G_MODULE_NEED_USCORE=0
-@@ -1427,13 +1427,13 @@ AS_IF([ test "$G_MODULE_IMPL" = "G_MODULE_IMPL_DL" ], [
+@@ -1428,9 +1428,9 @@ AS_IF([ test "$G_MODULE_IMPL" = "G_MODULE_IMPL_DL" ], [
LDFLAGS="$LDFLAGS $G_MODULE_LDFLAGS"
dnl *** check for OSF1/5.0 RTLD_GLOBAL brokenness
echo "void glib_plugin_test(void) { }" > plugin.c
@@ -47,20 +39,6 @@ index 1af90c5..f6b7a73 100644
${LDFLAGS} -module -o plugin.la -export-dynamic \
-shrext ".o" -avoid-version plugin.lo \
-rpath /dont/care >/dev/null 2>&1
-- eval `./libtool --config | grep ^objdir`
-+ eval `./$host_alias-libtool --config | grep ^objdir`
- AC_CACHE_CHECK([for RTLD_GLOBAL brokenness],
- glib_cv_rtldglobal_broken,[
- AC_TRY_RUN([
-@@ -1506,7 +1506,7 @@ fi
-
- AC_MSG_CHECKING(for the suffix of module shared libraries)
- export SED
--shrext_cmds=`./libtool --config | grep '^shrext_cmds='
Re: [OE-core] [PATCH] glib-2.0: Update to glib 2.53.7
On Mon, Nov 6, 2017 at 4:17 PM, Alistair Francis
wrote:
> Update to Glib version 2.53.7.
>
> Signed-off-by: Alistair Francis
> ---
> ...evert-meson-Substitute-the-Python-shebang.patch | 54
> ++
> .../glib-2.0/glib-2.0/configure-libtool.patch | 34 +++---
> .../{glib-2.0_2.52.3.bb => glib-2.0_2.53.7.bb} | 6 +--
> meta/recipes-core/glib-2.0/glib.inc| 8 ++--
> 4 files changed, 67 insertions(+), 35 deletions(-)
> create mode 100644
> meta/recipes-core/glib-2.0/glib-2.0/0001-Partially-Revert-meson-Substitute-the-Python-shebang.patch
> rename meta/recipes-core/glib-2.0/{glib-2.0_2.52.3.bb => glib-2.0_2.53.7.bb}
> (76%)
>
> diff --git
> a/meta/recipes-core/glib-2.0/glib-2.0/0001-Partially-Revert-meson-Substitute-the-Python-shebang.patch
>
> b/meta/recipes-core/glib-2.0/glib-2.0/0001-Partially-Revert-meson-Substitute-the-Python-shebang.patch
> new file mode 100644
> index 00..979247cbba
> --- /dev/null
> +++
> b/meta/recipes-core/glib-2.0/glib-2.0/0001-Partially-Revert-meson-Substitute-the-Python-shebang.patch
> @@ -0,0 +1,54 @@
> +From be007b2e6fbe93904e36ccddc707f96b30ad8300 Mon Sep 17 00:00:00 2001
> +From: Alistair Francis
> +Date: Mon, 6 Nov 2017 15:23:16 -0800
> +Subject: [PATCH] Partially Revert: meson: Substitute the Python shebang
> +
> +Partially revert this patch:
> +commit 0f18a2ebda4ec0440ec545542f9fc2f60cd54c5d
> +Author: Emmanuele Bassi
> +Date: Fri Jul 14 20:43:19 2017 +0100
> +
> +meson: Substitute the Python shebang
> +
> +Just like we do with Autotools. This allows building glib-mkenums and
> +glib-genmarshal on older platforms that only have Python 2.
> +
> +The above patch stops using the hardcoded python3 enviroment to run
> +Python scripts and instead uses the PYTHON variable used from configure.
> +
> +This patch casues QA issues when building Glib and results in the env
> +string being too long (resulting in clipping) which results in build
> +failures.
> +
> +As we always have Python 3 we don't need a workaround for Python 2.
> +
> +Signed-off-by: Alistair Francis
> +Upstream-Status: Inappropriate [OE specific]
> +---
> + gobject/glib-genmarshal.in | 2 +-
> + gobject/glib-mkenums.in| 2 +-
> + 2 files changed, 2 insertions(+), 2 deletions(-)
> +
> +diff --git a/gobject/glib-genmarshal.in b/gobject/glib-genmarshal.in
> +index ed6de0ae8..ec30410bd 100755
> +--- a/gobject/glib-genmarshal.in
> b/gobject/glib-genmarshal.in
> +@@ -1,4 +1,4 @@
> +-#!/usr/bin/env @PYTHON@
> ++#!/usr/bin/env python3
> +
> + # pylint: disable=too-many-lines, missing-docstring, invalid-name
> +
> +diff --git a/gobject/glib-mkenums.in b/gobject/glib-mkenums.in
> +index d4bfd11c3..051fce4ca 100755
> +--- a/gobject/glib-mkenums.in
> b/gobject/glib-mkenums.in
> +@@ -1,4 +1,4 @@
> +-#!/usr/bin/env @PYTHON@
> ++#!/usr/bin/env python3
> +
> + # If the code below looks horrible and unpythonic, do not panic.
> + #
> +--
> +2.11.0
> +
> diff --git a/meta/recipes-core/glib-2.0/glib-2.0/configure-libtool.patch
> b/meta/recipes-core/glib-2.0/glib-2.0/configure-libtool.patch
> index aa5de27d12..d759ea1d7f 100644
> --- a/meta/recipes-core/glib-2.0/glib-2.0/configure-libtool.patch
> +++ b/meta/recipes-core/glib-2.0/glib-2.0/configure-libtool.patch
> @@ -14,28 +14,20 @@ from PATH though
> Rebased to glib-2.27.3 by Dongxiao Xu
> Rebased to glib-2.32.1 by Martin Jansa
> Rebased to glib-2.31.20+ by Andre McCurdy
> +Rebased to glib-2.53.4+ by Alistair Francis
>
> Upstream-Status: Inappropriate [configuration]
>
> Signed-off-by: Martin Jansa
> ---
> - configure.ac | 10 +-
> - 1 file changed, 5 insertions(+), 5 deletions(-)
> + configure.ac | 4 ++--
> + 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> -index 1af90c5..f6b7a73 100644
> +index f322edfea..7cf86c2fa 100644
> --- a/configure.ac
> +++ b/configure.ac
> -@@ -1378,7 +1378,7 @@ if test x"$glib_native_win32" = xyes; then
> - G_MODULE_LDFLAGS=
> - else
> - export SED
> -- G_MODULE_LDFLAGS=`(./libtool --config; echo eval echo
> \\$export_dynamic_flag_spec) | sh`
> -+ G_MODULE_LDFLAGS=`(./$host_alias-libtool --config; echo eval echo
> \\$export_dynamic_flag_spec) | sh`
> - fi
> - dnl G_MODULE_IMPL= don't reset, so cmd-line can override
> - G_MODULE_NEED_USCORE=0
> -@@ -1427,13 +1427,13 @@ AS_IF([ test "$G_MODULE_IMPL" = "G_MODULE_IMPL_DL"
> ], [
> +@@ -1428,9 +1428,9 @@ AS_IF([ test "$G_MODULE_IMPL" = "G_MODULE_IMPL_DL" ], [
> LDFLAGS="$LDFLAGS $G_MODULE_LDFLAGS"
> dnl *** check for OSF1/5.0 RTLD_GLOBAL brokenness
> echo "void glib_plugin_test(void) { }" > plugin.c
> @@ -47,20 +39,6 @@ index 1af90c5..f6b7a73 100644
> ${LDFLAGS} -module -o plugin.la -export-dynamic \
> -shrext ".o" -avoid-version plugin.lo \
> -rpath /dont/care >/dev/null 2>&1
> -- eval `./libtool --config | grep ^objdir`
> -+ eval `./$host_alias-libtool --config
[OE-core] [PATCH] maintainers.inc: update maintainership
Reassign Dengke's recipes to Yi Zhao. Signed-off-by: Yi Zhao --- meta/conf/distro/include/maintainers.inc | 42 1 file changed, 21 insertions(+), 21 deletions(-) diff --git a/meta/conf/distro/include/maintainers.inc b/meta/conf/distro/include/maintainers.inc index cc857e0..36b8983 100644 --- a/meta/conf/distro/include/maintainers.inc +++ b/meta/conf/distro/include/maintainers.inc @@ -44,7 +44,7 @@ RECIPE_MAINTAINER_pn-apr-util = "Hongxu Jia " RECIPE_MAINTAINER_pn-apt = "Aníbal Limón " RECIPE_MAINTAINER_pn-apt-native = "Aníbal Limón " RECIPE_MAINTAINER_pn-argp-standalone = "Khem Raj " -RECIPE_MAINTAINER_pn-asciidoc = "Dengke Du " +RECIPE_MAINTAINER_pn-asciidoc = "Yi Zhao " RECIPE_MAINTAINER_pn-aspell = "Jose Lamego " RECIPE_MAINTAINER_pn-assimp = "Jussi Kukkonen " RECIPE_MAINTAINER_pn-at = "Chen Qi " @@ -56,8 +56,8 @@ RECIPE_MAINTAINER_pn-autoconf = "Robert Yang " RECIPE_MAINTAINER_pn-autoconf-archive = "Robert Yang " RECIPE_MAINTAINER_pn-autogen-native = "Robert Yang " RECIPE_MAINTAINER_pn-automake = "Robert Yang " -RECIPE_MAINTAINER_pn-avahi = "Dengke Du " -RECIPE_MAINTAINER_pn-avahi-ui = "Dengke Du " +RECIPE_MAINTAINER_pn-avahi = "Yi Zhao " +RECIPE_MAINTAINER_pn-avahi-ui = "Yi Zhao " RECIPE_MAINTAINER_pn-babeltrace = "Alexander Kanavin " RECIPE_MAINTAINER_pn-base-files = "Ross Burton " RECIPE_MAINTAINER_pn-base-passwd = "Ross Burton " @@ -74,7 +74,7 @@ RECIPE_MAINTAINER_pn-binutils-cross-canadian = "Khem Raj " RECIPE_MAINTAINER_pn-binutils-crosssdk = "Khem Raj " RECIPE_MAINTAINER_pn-bison = "Chen Qi " RECIPE_MAINTAINER_pn-bjam-native = "Alexander Kanavin " -RECIPE_MAINTAINER_pn-blktool = "Dengke Du " +RECIPE_MAINTAINER_pn-blktool = "Yi Zhao " RECIPE_MAINTAINER_pn-blktrace = "Alexander Kanavin " RECIPE_MAINTAINER_pn-bluez5 = "Maxin B. John " RECIPE_MAINTAINER_pn-bmap-tools = "Ed Bartosh " @@ -95,10 +95,10 @@ RECIPE_MAINTAINER_pn-cairo = "Jussi Kukkonen " RECIPE_MAINTAINER_pn-calibrateproto = "Armin Kuster " RECIPE_MAINTAINER_pn-cantarell-fonts = "Alexander Kanavin " RECIPE_MAINTAINER_pn-ccache = "Robert Yang " -RECIPE_MAINTAINER_pn-cdrtools-native = "Dengke Du " -RECIPE_MAINTAINER_pn-chkconfig = "Dengke Du " -RECIPE_MAINTAINER_pn-chkconfig-alternatives-native = "Dengke Du " -RECIPE_MAINTAINER_pn-chrpath = "Dengke Du " +RECIPE_MAINTAINER_pn-cdrtools-native = "Yi Zhao " +RECIPE_MAINTAINER_pn-chkconfig = "Yi Zhao " +RECIPE_MAINTAINER_pn-chkconfig-alternatives-native = "Yi Zhao " +RECIPE_MAINTAINER_pn-chrpath = "Yi Zhao " RECIPE_MAINTAINER_pn-clutter-1.0 = "Jussi Kukkonen " RECIPE_MAINTAINER_pn-clutter-gst-3.0 = "Jussi Kukkonen " RECIPE_MAINTAINER_pn-clutter-gtk-1.0 = "Jussi Kukkonen " @@ -139,17 +139,17 @@ RECIPE_MAINTAINER_pn-diffutils = "Chen Qi " RECIPE_MAINTAINER_pn-directfb = "Hongxu Jia " RECIPE_MAINTAINER_pn-directfb-examples = "Hongxu Jia " RECIPE_MAINTAINER_pn-distcc = "Hongxu Jia " -RECIPE_MAINTAINER_pn-distcc-config = "Dengke Du " +RECIPE_MAINTAINER_pn-distcc-config = "Yi Zhao " RECIPE_MAINTAINER_pn-dmidecode = "Alexander Kanavin " RECIPE_MAINTAINER_pn-dmxproto = "Armin Kuster " RECIPE_MAINTAINER_pn-dnf = "Alexander Kanavin " -RECIPE_MAINTAINER_pn-docbook-xml-dtd4 = "Dengke Du " -RECIPE_MAINTAINER_pn-docbook-xsl-stylesheets = "Dengke Du " -RECIPE_MAINTAINER_pn-dosfstools = "Dengke Du " +RECIPE_MAINTAINER_pn-docbook-xml-dtd4 = "Yi Zhao " +RECIPE_MAINTAINER_pn-docbook-xsl-stylesheets = "Yi Zhao " +RECIPE_MAINTAINER_pn-dosfstools = "Yi Zhao " RECIPE_MAINTAINER_pn-dpkg = "Aníbal Limón " RECIPE_MAINTAINER_pn-dri2proto = "Armin Kuster " RECIPE_MAINTAINER_pn-dri3proto = "Armin Kuster " -RECIPE_MAINTAINER_pn-dropbear = "Dengke Du " +RECIPE_MAINTAINER_pn-dropbear = "Yi Zhao " RECIPE_MAINTAINER_pn-dtc = "Alexander Kanavin " RECIPE_MAINTAINER_pn-e2fsprogs = "Robert Yang " RECIPE_MAINTAINER_pn-ed = "Alexander Kanavin " @@ -164,7 +164,7 @@ RECIPE_MAINTAINER_pn-encodings = "Armin Kuster " RECIPE_MAINTAINER_pn-epiphany = "Alexander Kanavin " RECIPE_MAINTAINER_pn-ethtool = "Changhyeok Bae " RECIPE_MAINTAINER_pn-eudev = "Alejandro Hernandez " -RECIPE_MAINTAINER_pn-expat = "Dengke Du " +RECIPE_MAINTAINER_pn-expat = "Yi Zhao " RECIPE_MAINTAINER_pn-expect = "Alexander Kanavin " RECIPE_MAINTAINER_pn-ffmpeg = "Alexander Kanavin " RECIPE_MAINTAINER_pn-file = "Robert Yang " @@ -287,8 +287,8 @@ RECIPE_MAINTAINER_pn-irda-utils = "Changhyeok Bae " RECIPE_MAINTAINER_pn-iso-codes = "Alexander Kanavin " RECIPE_MAINTAINER_pn-iw = "Changhyeok Bae " RECIPE_MAINTAINER_pn-libjpeg-turbo = "Maxin B. John " -RECIPE_MAINTAINER_pn-json-c = "Dengke Du " -RECIPE_MAINTAINER_pn-json-glib = "Dengke Du " +RECIPE_MAINTAINER_pn-json-c = "Yi Zhao " +RECIPE_MAINTAINER_pn-json-glib = "Yi Zhao " RECIPE_MAINTAINER_pn-kbd = "Alexander Kanavin " RECIPE_MAINTAINER_pn-kbproto = "Armin Kuster " RECIPE_MAINTAINER_pn-kconfig-frontends = "Alexander Kanavin " @@ -463,9 +463,9 @@ RECIPE_MAINTAINER_pn-logrotate = "Robert Yang " RECIPE_MAINTAINER_pn-l
